verifylisted

# verify — the smith's own gate before handoff A completion claim is a mark, and a mark must be *earned*. The community baseline ("no completion claims without fresh verification evidence") stops at freshness — it accepts any green command as proof. This protocol demands more: **a check that cannot fail proves nothing, and evidence that outlives its tree state proves less than nothing.** A claim is sealed only when all four conditions hold: ## The four conditions ### 1. Named before run State the proving command **before** executing it, next to the claim it proves. Choosing the command after seeing what passes is how a test suite's green becomes "feature works" — the claim-to-command mapping is the verification, the run is just its execution. ### 2. Able to fail Show the check CAN go red. For a bug fix: the reproduction failed before the change (or fails when the change is reverted). For a new test: it was observed failing against the pre-change code. A check that has never been seen red is a counterfeit seal — this is the condition the generic gates skip, and the one that catches assertion-free tests, mocked-away behavior, and wrong-file test runs. #### An absence claim is only as good as the search behind it "There are no callers", "the original has no such branch", "nothing reads this column" — these are claims about the whole tree, and their entire evidence is that one search did not find something. An existence claim comes with a coordinate anyone can open; an a