verification-before-completion

# Verification Before Completion ## The Iron Law ``` NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE ``` If you have not run the verification command in **this turn**, you cannot claim it passes. The superpowers-evaluator reads narration and runs commands independently — your unverified "done" can be waved through unless it self-evidences. **Violating the letter of this rule is violating the spirit of this rule.** ## The Gate Function Run this before claiming any status, expressing satisfaction, or returning a PASS-shaped verdict to the coordinator: 1. **IDENTIFY** — What command proves this claim? (the task file's `## Verification Commands`) 2. **RUN** — Execute the FULL command, fresh, in this turn. Not a previous run, not "should pass". 3. **READ** — Full output, check exit code, count failures. Last 20-30 lines pasted into your return. 4. **VERIFY** — Does the output confirm the claim? - NO → state the actual status with evidence (exit code, failure count) - YES → state the claim WITH evidence (exit 0, N/N pass) 5. **ONLY THEN** make the claim. Skipping any step is lying, not verifying. ## Common Failures | Claim | Requires | Not Sufficient | |-------|----------|----------------| | Tests pass | Test command output: 0 failures | Previous run, "should pass" | | Linter clean | Linter output: 0 errors | Partial check, extrapolation | | Build succeeds | Build command: exit 0 | Linter passing, logs look good | | Bug fixed | Original-symptom test passes | Code changed, assumed fixed | | Regression test works | Red-green cycle verified | Test passes once | | Sub-agent completed | VCS diff shows changes + your re-run | Sub-agent reports "success" | | Requirements met | Line-by-line checklist vs spec | Tests passing alone | ## Red Flags — STOP - Using "should", "probably", "seems to" - Expressing satisfaction before verification ("Done!", "Great!", "Perfect!") - About to commit, push, or return a PASS verdict without verification - Trusting a sub-agent's success report without re-running verification yourself - Relying on partial verification (only one of several test files) - Thinking "just this once" - **ANY wording implying success without having run verification this turn** ## Rationalization Prevention | Excuse | Reality | |--------|---------| | "Should work now" | RUN the verification | | "I'm confident" | Confidence is not evidence | | "Just this once" | No exceptions | | "Linter passed" | Linter is not the test runner | | "The sub-agent said success" | Verify independently — sub-agents hallucinate done | | "Partial check is enough" | Partial proves nothing | | "Different words so the rule doesn't apply" | Spirit over letter | | "The evaluator will catch it anyway" | The evaluator reads narration; an unverified "done" can slip past. Self-verify first. | ## Relationship to the superpowers-evaluator This skill is the **implementer-side** pre-gate. The superpowers-evaluator is the independent read-only post-gate that re-runs verification commands itself. They do not overlap: - You (implementer) self-prove with this skill **before** returning a done verdict to the coordinator. - The evaluator independently re-verifies **after** the batch passes the Verification Gate. An unverified "done" from you can be waved through by the evaluator (it reads narration, not always files). Self-evidence closes that gap. Do not lean on the evaluator as a safety net — produce the evidence yourself first. ## The Bottom Line Run the command. Read the output. Paste the evidence. THEN claim the result. This is non-negotiable.