verification-before-completionlisted

# Verification Before Completion The gap between "I wrote the code" and "the code works" is where 80% of bugs ship. Closing that gap is non-negotiable. ## Iron Law **A task is not complete until you have executed the verification command, read the output, and confirmed it matches expectations.** Compiling is not verification. Type-checking is not verification. "Looks right" is not verification. ## What counts as verified You must be able to point to: 1. The **command** you ran (or interaction you performed). 2. The **output** you observed. 3. The **expectation** that output satisfied. Missing any of those three? Not verified. ## Red Flags - "It should work." - "I don't think anything else changed." - "The diff looks right." - "Tests probably pass." - "I'll let CI catch it." - Saying "done" without naming the verification step you took. If any of these appear in your reasoning, you are about to ship an unverified change. ## Verification by task type ### Code changes (functions, modules) - Run the relevant unit test(s). Read the green/red output. - If no test exists, write one OR run an integration that exercises the path. - If neither is possible, run the function with a real input in a REPL / script. ### API endpoints - Hit the endpoint with `Invoke-RestMethod` / `curl` / Postman. - Read the actual response body and status code. - Verify both happy path AND at least one error case. ### UI changes - Open the page. See the change with your eyes (or screenshot). -