---
globs: **/*.test.*,**/*.spec.*,**/tests/**,**/__tests__/**,**/test_*.py,**/*_test.go,**/*Test.java,**/*Tests.cs
alwaysApply: false
---

# Verification standards

**A passing command is evidence only for what it actually covers.** Name the command and what it proves; a green suite that never exercised the changed path proves the suite ran, nothing more. Never infer correctness from a builder's summary, and never claim success from reading code.

**Write the test that would have failed before the fix.** For a bug, that means reproducing first: a fix landed without a reproduction is a guess with a green checkmark.

**Test behavior at its boundary,** not the implementation's shape. Assert on observable outcomes so the test survives a refactor. Error paths, empty states, and concurrency are where the real defects sit — the happy path is usually already covered by someone using the feature.

**A test that cannot fail is worse than no test:** it costs runtime and buys false confidence. Deleting one is a legitimate change; say so in the handoff.

**Failures derived from real incidents belong in `docs/EVALS.md`** with the lesson they prevent, so the check outlives the memory of the bug.

## Who verifies

The `verifier` subagent is independent by construction — it did not build the thing and cannot edit it, so it can run concurrently with review at almost no wall-clock cost. Use it after every substantial implementation. If a check cannot run in this environment, say which one and what evidence is therefore still missing; a stated gap is fine, a silent one is not.