acceptance-auditlisted

# Acceptance Audit The acceptance criteria are a **contract you did not write**. They came from a ticket, and someone else — a reviewer, a PM, whoever filed it — is relying on them meaning what they say. Your job is to report whether the branch satisfies them, not to make them satisfiable. Two independent checks. An item passes only if it survives both. ## Check 1 — Is it satisfied? For every item in the list, find the code that implements it and the evidence that it works. - **Cite location and evidence.** `path:line` for the implementation, plus how you confirmed it — the test that covers it, or the command you ran and its output. - **Exercise the real path where you can.** A criterion is written from the user's point of view; a passing unit test on a handler is weaker evidence than driving the actual route, CLI, or UI. See `broken-window-check`. - **No partial credit.** "Mostly done", "works except for empty input", "the happy path is covered" — all of those are **not satisfied**. Say so plainly. - **Absent is not satisfied.** If you cannot find the implementation, the item fails. Do not infer it from an adjacent feature or from intent in the diff. ## Check 2 — Does it semantically match? This is the check that gets skipped, and it catches the expensive failures. Code can satisfy the *letter* of a criterion while doing something the author did not ask for. Compare what the criterion **means** against what the implementation **does**: | Divergence | Examp