verification-before-completionlisted

# Verification Before Completion The failure this prevents is not laziness — it is the confident report. Code compiles, tests are green, the diff looks right, and the claim "done" gets made without anyone running the thing. This package has a name for that shape: **claiming versus doing**, and it is the failure mode it exists to find in other people's codebases. ## The rule **A pin becomes `resolved` when the behavior was observed, not when the code was written.** Everything else — green CI, a clean typecheck, a passing suite — is evidence *about* the change, not evidence *of* the outcome. They are necessary and they are not sufficient, because every one of them can pass while the feature is unreachable, unwired, or wired to the wrong thing. On AI-generated code the inversion is sharper: a suite that is *fully* green is a reason to **look**, not to stop. The tests were usually generated with the code and encode the same misunderstanding, so a 100% pass is a **suspect** signal until you have exercised the real path yourself — once you have observed the behavior, the green is discharged and you stop. It is a question observation answers, not a permanent doubt. ## What counts as verification | claim | insufficient | sufficient | |---|---|---| | an endpoint works | the handler has a test | called it, saw the response and status | | a migration is safe | it applied locally | applied, read the data back, ran the down-path | | a UI change landed | the component renders in a t