verification-before-completion

A task is done only once its real output has been observed to be done. Making the change, or liking its odds, closes nothing. The defect this skill stops is the unobserved completion claim, a "fixed" or a "passing" asserted from intent with no evidence behind it. The rule is one line and admits no exception: claimed-done equals observed-done.

Genchi Genbutsu (go and see the real thing) is the same rule applied to the moment before hand-off. The verification method depends on the output type. Evidence means the command plus its result pasted in, and "it should work" is never evidence. Read the verification methods for the method-by-output-type table, the show-me-the-evidence discipline, the cost-appropriate level, the failure modes, red flags, and a worked assumed-vs-verified contrast.

Steps

1. Name the completion claim and its output type. State the exact thing about to be called done ("the test suite passes", "the bug is fixed") and classify its output type: runnable code, a written file, a bug fix, a UI change, or a doc. A claim with no named output type has no defined check, so naming the type is the first artifact. Done when the claim and its output type are both written down.

2. Pick the verification method for that type. Match the output type to its observation in the methods table: code runs or its tests run; a file is read back; a fix reproduces the original failure then confirms the repro is gone; a UI renders and is looked at; a doc has its links and facts checked. The method produces an observation, never an inference. Done when the chosen method names a command or an observation that yields real output.

3. Run it and capture the real output. Execute the method against the actual artifact and capture what came back: the command's stdout and exit status, the file's read-back contents, the rendered screen. Observation means reading the artifact's own output. Done when real output exists to read, not a prediction of what it would say.

4. Read the output against the claim. Compare the captured output to the completion claim: an exit code of 0 and the expected assertions for "tests pass", the awaited content for "file written", the original error absent for "bug fixed". A green-looking run that tested the wrong thing fails this step. Done when the observed output supports the specific claim, or the claim is corrected to match the output.

5. Scale the verification to the cost of being wrong. Set the depth by the blast radius named in the cost-appropriate level: a one-line doc edit warrants a read-back, while a payment path warrants running the suite plus the failure cases. Under-verifying a high-blast change and over-verifying a trivial one are both findings. Done when the verification depth matches the cost of the claim being false.

6. Reject stale or assumed evidence. Confirm the evidence came from the current artifact after its last edit, and that no step rests on "should work" in place of an observation. Evidence from before the change under test is checked against the stale-evidence failure mode. Done when every completion claim traces to fresh output observed after the final change.

7. Report the claim with its evidence attached. Hand back each claim beside the command and the result that prove it, per the evidence discipline; the verdict travels with its proof. A claim that cannot show its evidence returns to step 2. Done when every completion claim in the hand-off is backed by pasted, fresh, output that an outside reader can check.