verify

# Verify **Localize → red → minimal approved change → same command green.** “Verified” without this turn's tool output is a failure. A verification request is not authorization to change code: diagnose and report unless implementation was separately requested or approved. ## Fail first (before production edits) 1. Name **1–3 files**. `grep`/`find` the symptom. Do not dump the tree. 2. A command that is **red for the right reason**: - Bug: existing test, type error, repro script, or curl that shows the bug. - Feature: a **new** test that fails because the feature is missing (allowed). 3. Show that red (first failure). If you cannot get red, you do not understand the task — do not guess a patch. Skip fail-first only when the user named a copy/docs hunk, already pasted this turn's red stack, or the target state cannot meaningfully fail first (for example, a read-only environment check). State the reason and use the narrowest direct proof. ## Patch Only after implementation is separately authorized: make the smallest change that addresses the demonstrated cause. Re-run **the same command**; it must go green. If a cheap regression check exists for the affected file or package, run it. Do not stack another fix on a broken attempt: revert a regressing patch before trying a new hypothesis. ## Tests (two directions — do not conflate) - You MAY add tests that would fail without your change. - You MUST NOT weaken, skip, delete, or rewrite existing assertions to get green. - You MUST NOT change production to match a wrong test. - You MUST NOT hide the real test in `/tmp`. - If a test blocks you and you think the test is wrong: stop. Tell the user. Do not edit it unless they changed the spec this turn. ## Revert test One line: which assertion or type error goes red if this diff is undone. If you cannot name it, you are not testing the change — add a test (allowed) or say untested. ## Command selection 1. Project `AGENTS.md` verification instruction. 2. The narrowest behavior-level command (`pytest path::name`, `go test ./pkg -count=1`, `cargo test name`, `npm test -- path`). 3. The documented project command from `package.json`, Makefile, justfile, or README. Run the smallest command that proves the requested behavior, then the cheapest relevant regression check. Lint, type-check, formatting, screenshots, and health checks are complementary evidence, not interchangeable proof. ## Run 1. State the command. 2. `bash` it. 3. First failure + summary. Not a wall. 4. Red after a patch: one cause, change the code or the hypothesis. Same command + args twice max. 5. Cannot run → `blocked` + the command. Do not claim done. 6. Flake: re-run once. Still red/green flip → report flake, not pass. ## Close Report: exact command and exit code; red and green evidence (or stated exception); what behavior the check covers; revert test; and untested risk. UI/CSS needs visual evidence at the relevant viewport. Docs/JSON need the written region read plus a parser or schema check when available. A passing command may not prove a deployment, migration, external integration, or security property; name that limit.