Spec-to-Code Compliance

Two artifacts disagree, and the job is to find where. The documentation says what the system does; the code decides what it actually does. Every gap between them is either a bug or a documentation fix, and which one it is is the finding.

When to Use

You have both documentation describing intended behavior and the code that should implement it. A whitepaper against a protocol, a design note against a service, a README's stated guarantees against the functions behind them.

Most useful when the document is authoritative, something a client wrote, published, or is audited against, because then a divergence is a defect rather than stale prose.

When NOT to Use

Not for code with no documentation of intended behavior. There is nothing to check against, and a requirement inferred from the code is checked against itself. Build the system model first with audit-context-building.

Not for finding bugs in general. This finds one class: where the code and the document disagree. A bug both artifacts are silent about is out of scope, and a bug the document endorses is a finding against the document.

Not for writing or improving documentation, though it produces the list of what needs fixing.

Do not check requirements in this context

Run /spec-to-code-compliance:spec-compliance <path>. The slash command takes a path; to name the specification directly or widen the fan-out, ask for the run with those values, "run spec-compliance on ./contracts against SPEC.md, checking 20 requirements", and they reach the script as {path, spec, limit}. Typing the object literally after the slash command does not work; it arrives as a string and becomes the path.