proof-discipline

The iron rule

No completion claim is valid without evidence that is (a) real command or test output, and (b) produced fresh, in direct response to this claim — not reused from an earlier point in the session, and not a description of what the code "should" do.

This rule is mechanical, not a matter of confidence. "I'm sure this works" is not evidence at any confidence level. A passing test run from three turns ago is not evidence for a claim made after further edits. A code walkthrough that explains why the fix is correct is not evidence — it is reasoning, and reasoning about correctness is exactly what unattended sessions get wrong most often without anyone present to catch it.

The gate, step by step

Before writing or emitting any sentence that asserts completion:

1. Identify the specific claim. What exactly is being declared done — the whole task, one subtask, one fix? Evidence must match the scope of the claim; passing one test does not certify an entire feature if the feature has other paths.
2. Identify what evidence would verify this claim. A test suite run, a specific test file, a build command, a lint pass, a manual command that exercises the changed behavior. If no such command or test currently exists, that is itself a finding, not an obstacle to route around.
3. Check freshness. Has the code under this claim changed since the last time this evidence was produced? If yes, any previously-produced output is stale and does not count, however real it was when produced. Re-run.
4. Run the command now, in this turn, in direct response to this claim. Not "I ran this earlier and it passed" — run it again if there is any doubt about freshness, and always run it if no run exists yet for the current state of the code.
5. Read the actual output. Not the exit code alone, not an assumption that "no output means success" — read what the command printed. Distinguish a real pass (explicit pass/fail counts, explicit success indicators) from an ambiguous or empty result.
6. Only then, cite the fresh output verbatim (or its pass/fail summary) alongside the claim. The claim and its evidence travel together — a claim without the evidence attached in the same response is not a satisfied gate.

If step 2 finds no test or command exists for the claimed behavior: either write and run one now, or do not claim completion — report the specific gap ("no test exercises the pagination boundary case; not verified") instead of substituting confidence for verification.

Recognizing disqualified "evidence"

None of the following satisfy the gate, regardless of how detailed or confident they sound:

• A description of what the code does or should do ("this correctly handles the off-by-one case because...").
• A code review / manual trace through the logic, however careful.
• A prior turn's test output, when the code has changed since that run.
• A partial run that didn't reach the relevant case (e.g. a broader test suite that errored before reaching the new test).
• Any hedge that substitutes for a check — treat qualifiers like "should," "I believe," "this looks correct," "in theory" as a signal to stop and go run something, not as acceptable claim language once evidence is otherwise present. The presence of a hedge is a prompt to verify, not a permitted alternative to verifying.

What satisfies the gate

• Fresh command output pasted or summarized in this turn, produced after the last relevant code change, that directly exercises the claimed behavior (test pass/fail counts, explicit build success, explicit lint clean, or equivalent).
• An explicit not-done report naming the specific missing verification, when no evidence can yet be produced — this is a valid, gate-satisfying outcome. The gate does not require every claim to be "done"; it requires every "done" claim to be backed, and permits "not done, here is the specific gap" as the honest alternative.

Model-agnosticism

This gate is checked structurally, never stylistically. It asks exactly two mechanical questions: (1) is there cited command/test output, and (2) was it produced fresh for this claim. It never asks how long, how confident, or how detailed the surrounding narration is. A model that says only "Done — tests pass" and cites the actual fresh output satisfies the gate; a model that writes three paragraphs of confident-sounding explanation without citing any fresh output does not. Verbosity is never itself evidence, and terseness is never itself a violation — only the substituting-for-a-check applies equally regardless of model. Only the presence and freshness of the cited evidence decides the gate, regardless of which model or narration style is running.