ears-acceptance-verificationlisted

# EARS acceptance verification Verification is an adversarial evidence exercise, not a read-through. The verifier judges one task's diff against its EARS criteria and returns a verdict; it **never edits code** — a failing criterion bounces back to the author. ## 1. Criterion-by-criterion evidence table Build a table with one row per EARS acceptance criterion. Nothing is left unchecked; "looks fine" is not evidence. | Criterion (EARS clause) | Evidence | Verdict | |---|---|---| | WHEN … THE SYSTEM SHALL … | test name / command output / observed behavior | met / unmet | Evidence is one of: a named test that exercises the clause and passes, captured command output, or a concrete observation from running the code. A criterion with no evidence column is treated as **unmet** — absence of proof is not proof. ## 2. Adversarial re-derivation — don't just re-run the author's tests For each criterion, construct at least one scenario the clause *implies* that the diff might NOT handle, then check it: - boundary/empty/zero cases the happy-path test skipped, - the unwanted-behavior branch (`IF <condition>, THEN …`) when the criterion has one — verify the error path fires, not just the success path, - concurrent/repeated invocation, malformed input, the state the criterion names being false. Re-running the author's own green tests confirms only what they already thought to test. Derive the missing scenario yourself and exercise it. ## 3. Gate pass and criteria pass are two dis