verification-before-completion

# Verify before you claim it's done Saying "done" without checking is the most common way an agent ships a broken change. Before you report a coding task as finished, fixed, or working, VERIFY it — do not assume. ## Checklist (do it, don't narrate it) 1. **Build / compile** what you changed. If it doesn't build, it isn't done. 2. **Run the relevant tests** with the project's own command (a `Taskfile`/ `Makefile` target, `go test`, `npm test`, …). Run the narrowest command that covers your change first, then the fuller suite if it's cheap. If the area you changed has no test and the change is non-trivial, add one. 3. **Run the linter/formatter** the project uses and fix what it flags. 4. **Re-read the request** and confirm EVERY part is addressed — not just the easy part. Check the edge cases and error paths you touched. 5. **Look for regressions** — did the change break a caller, a contract, a test, or a neighbouring feature? ## Reporting - Report what you actually ran and its result ("`go test ./...` green, `task lint` 0 issues"), never "should work". - If something failed, or you could not verify a part, SAY SO plainly — never paper over a failure or a skipped step. - If a test fails, fix the code (or the test, if the test was wrong) before claiming done — don't hand back a red build. A task is "done" only when you have evidence it works, not when the code looks right.