prooflisted

# Proof ## Iron Law `NO ENGINEERING CLAIM WITHOUT A NAMED PROOF.` A proof is a named check that would fail if the claim were false. "The tests pass" does not count until you can say which test would break if you were wrong. ## When to Use - As the completion gate before any reply that says or implies the work is done, fixed, ready to commit, ready for a PR, or passing. - Writing or reviewing behavior tests for any change or flaky test. - Turning an agreed spec, model, contract, or root cause into Proof Contracts and runnable checks. ## When NOT to Use - Edits with no behavior surface: formatting, typos, comments, renames and moves that tooling already confirms. - A bug whose cause is not pinned down: `debugging` first. - Design, naming, structure: `code-review`. Benchmarks: `performance`. Test runner setup: `scaffolding`. ## Rules 1. Every non-trivial claim owes a check. If you cannot point to one, mark the claim `unproven` and say which evidence is missing. Silence is not proof. 2. Match the proof to the claim: a behavior change needs a runnable check at the boundary, a new endpoint a contract test, a bug fix a regression test that fails before and passes after, a refactor the same behavior before and after, a data claim an invariant. 3. Test at boundaries, in the caller's words: where the data's shape, value, state, or error visibly changes, and always at the outermost boundary the caller sees (endpoint, CLI, UI, public API). Boundary test