verification-before-completionlisted

# Verification before completion **Trigger.** You are about to write *done*, *fixed*, *working*, *should work*, *ready*, *that's it*, *all set*, or to mark a task complete — or a human asked whether something is finished. > **Reference material** (the full claim→evidence table, the rationalization > catalogue with counter-moves, and worked pass/fail transcripts): see > `reference.md` in this directory. This file is the gate and the loop. ## The rule > **A claim you have not observed is a guess. Report it as one, or go and > observe it.** This is not about being slow or hedging. It is about the difference between *I ran it and saw X* and *it should do X*. The first is a report. The second is a prediction wearing a report's clothes, and it is the single most common way agent work goes wrong: not a bad edit, but a **correct-looking edit reported as verified when nobody looked**. ## The loop Run this before every completion claim. It is four questions, in order. ### 1. What exactly am I claiming? Write the claim as one sentence, in the form a reader will act on. Vague claims cannot be verified, so sharpen first: | Vague | Sharp | | --- | --- | | "the tests pass" | "`pytest tests/` exited 0 with 214 passed, 0 failed" | | "I fixed the bug" | "the reported input now returns 3 instead of raising" | | "it builds" | "`cargo build --all-features` exited 0 with no warnings" | | "the API works" | "`GET /health` returned 200 with `{\"ok\":true}`" | ### 2. What observation would