Skip to main content

Module doctor

Module doctor 

Source
Expand description

fz doctor (issue #8): harness validity, lockfile consistency and the portable-SQL lint. It re-asserts the contract-version rule (issue #17) and the production abuse-port rules (issues #13/#102/#133) — the same checks Harness::build enforces at initialization, kept visible here for operator tooling.

Output comes in two disciplines (harness #140). Without --json the doctor is prose: warnings on stderr, every failure joined into one message, byte-for-byte as it has always been. With --json it prints exactly one JSON object to stdout — schema, ok and the failures, each with its stable code from crate::codes — and nothing else, so an agent can parse the verdict without screen-scraping.

Structs§

DoctorFailure
One failed doctor check: its stable code from the catalogue (crate::codes) plus the human message, which is byte-identical to the prose path’s.
DoctorReport
The outcome of a doctor run: every failed check, in check order.

Constants§

REPORT_SCHEMA
The schema field of the fz doctor --json object (harness #140): consumers branch on it, so it only ever grows.

Functions§

doctor
Runs every doctor check. allow_no_captcha downgrades the production-captcha failure to a printed warning for the stated reason (issue #13).
doctor_json
Runs every doctor check under --json discipline (harness #140): prints exactly one JSON object to stdout — schema, ok, failures with their stable codes — and nothing else, then reports the verdict as the exit code.
doctor_report_json
The doctor’s checks under --json discipline, without printing — the exact report doctor_json serializes, for tests and future consumers. Operator warnings are suppressed, as --json promises.
shipped_sql_files
The sqlite migration files a crate directory ships, sorted: migrations/sqlite/*.sql when that set exists, else the flat migrations/*.sql — but only when it carries no .harness-lock.json (the lock file fz migrations collect writes), which marks another venture’s collected output rather than a module’s own SQL. migrations/postgres/ is never read: a crate that ships a postgres set has declared where its SQL differs, the same rule the in-crate lint check applies to a module. Public because the cli-acceptance migration test reads module crates and resolved dependencies with the same rule, so the two cannot drift.
venture_dependency_dirs
The local crate directories a venture’s dependencies resolve to, for the venture whose migrations dir this is — the directory the migrations dir sits in, canonicalized so a --out reached through .. or a symlink still walks up to the real workspace root. A path dependency resolves relative to the venture; a workspace = true one through the nearest ancestor manifest with a [workspace] table and its [workspace.dependencies] entry (by the member’s dependency key, as Cargo itself looks it up). Dev and build dependencies are not mounted in the harness, crates.io and git dependencies ship no directory to read, and a workspace dependency whose table never names a path is skipped with them. Sorted and deduped, because the failures reported over them are.