Verify commands

A verify command is an acceptance test. Before shipping one, answer: if this command were silently doing nothing, what in its output would tell me? If you cannot answer, you have a command, not a check. Fix the command; do not invent a statement for it.

Name the failing direction

Next to every runnable check, write one line naming the observable signal that means failure: non-zero exit, "0 passed" in the summary line, the coverage line is absent, stderr contains "ECONNREFUSED". "The command fails" and "an error occurs" are restatements, not signals. TBD, N/A, and none are refusals. Short is fine; non-zero exit is complete. Prefer the signal the tool actually emits over one you imagine: for a command that already ran, state what you saw; for a new one, take the signal from the tool's documented output. N commands need N statements.

Ground every path

Inherit the command that already worked in this repo, verbatim, before deriving a new one. A cd target or --prefix target must exist, or be created by an earlier step, and must hold the matching manifest (package.json, Makefile, pyproject.toml). Prefer npm --prefix <dir> run <script> over cd <dir> && npm run <script>; it does not depend on the caller's working directory. Do not hand-reason the filesystem: list it. If you cannot ground a path, say so instead of guessing.

Shapes that pass while measuring nothing