custom (.envdoctor.yaml checks)
| Field | Value |
|---|---|
| Probe ID | custom |
| Category | custom |
| Severity | error |
| Inferred from | .envdoctor.yaml#checks |
What it means
custom isn’t a “real” probe — it’s the meta-probe that runs the declarative checks a maintainer added to .envdoctor.yaml to extend envdoctor’s inference. Each finding’s evidence names which check produced it.
The four supported check types:
| Type | Asserts |
|---|---|
tool_version | A named tool is on PATH at a version satisfying a semver constraint. |
port_free | A TCP port is free to bind. |
env_required | One or more env var names are set in the process env or .env. |
command_present | A command is on PATH. |
See Config (.envdoctor.yaml) for the full reference.
How it’s detected
.envdoctor.yamlis loaded byinternal/config(returns nil if the file is absent — config is optional).- Each
checksentry is dispatched to its handler by the discriminatortype:field. - Each failing check produces one finding with
Probe = customand evidence pointing at the originating check.
The custom probe has no automated recipe — the finding’s evidence explains what’s wrong and the maintainer’s documentation should explain how to fix it. Future probes may attach recipes for the curated check types.
Common causes
- A check was added to
.envdoctor.yamlfor a tool/version the contributor doesn’t have. - A
port_freecheck trips because the contributor is running a different stack locally. - An
env_requiredcheck covers a new env var that was never documented in.env.example.
Recipes
The custom probe has no automated recipe today. The Config schema page is the primary remediation reference; repository maintainers should document expected setup in their own README.
No recipes today — open an issue with a debug bundle so a recipe can be authored.