verified-donelisted

# Verified done **Iron Law: no completion claims without fresh verification evidence.** "Fresh" means you ran the check in THIS state of the code and read its output — not that it passed earlier, not that the edit looked right. ## The gate (IDENTIFY → RUN → READ → THEN CLAIM) 1. **Identify** the command that would prove the claim (test file, full suite, the actual CLI invocation, the hook fed a real payload). 2. **Run it now.** For a slice: the full suite — this repo's ship ritual runs it for you: ``` py scripts/ship.py "<msg>" <explicit paths> --learn-exp <name> --tried "..." --result "..." ``` (gate: boundaries + doc-freshness + full pytest → commit+push with EXPLICIT paths → lesson → snapshot; any failure aborts before anything is committed). 3. **Read the output** — the count, the exit, the rendered artifact. Eyeball one REAL render of anything user-facing (a boot screen, a draft, a hook injection), not just its unit test. 4. **Then claim, with the evidence in the same breath** ("suite 578 passed; pushed as abc123"). ## Red-flag phrases (each one means STOP and verify) - "Should work now" · "Probably passes" · "Done!" (before running anything) - "The tests should still pass" (run them) - "I've made the change" (an accepted Edit is not a working change) ## Repo-specific truths - Dogfood through the real CLI against canonical-shaped data; unit fixtures verify units, dogfooding verifies the seam. - Report failures faithfully: if the gate fails,