verifylisted

# Verify: earn the claim before you make it **Triggers:** `done`, `fixed`, `passing`, `working`, `not found`, `no callers`, `nothing uses it`, `safe to change`. Those are the four claim types that go wrong: completion, correctness, absence, and safety. Everything else you say is either a question or an opinion, and neither can be false in the way these can. ## Why this is separate from sitrep `sitrep` governs the report. Evidence beside every claim, confidence named, a gap for anything unverified. It assumes the verification happened and was sound. This skill is about the hour before that. A report can satisfy every rule in `sitrep` and still be wrong, because a scoped test run reported as a pass carries its evidence faithfully and says something false. Reporting discipline cannot catch a check that was never the right check. ## The rules **1. Attribute a result to the state that produced it.** Before writing that a test run, a grep or a build holds at commit X, run `git rev-parse HEAD` in the same shell the check ran in and confirm it is X. Working trees move under you: a rebase, a colleague's push, an agent in another window. The claim is about a state, so name the state you were in. **2. Run the whole suite for what you touched.** Never a scoped module run. A scoped pass hides breakage outside its scope, and the breakage outside its scope is the reason to run tests at all. If the full suite is too slow to run, that is a finding about the suite, and it goes in the r