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.