acceptance-review-criterialisted

# Acceptance Review Criteria ## Overview Formal gate definitions and verdict rubric for the `acceptance-designer-reviewer`. Applied across 4 lenses (coverage, business-alignment, testability, boundary-enforcement). --- ## Gate Definitions (G1–G11) ### Lens 1: coverage-lens | Gate | ID | Definition | Pass condition | Fail severity | |---|---|---|---|---| | AC–Scenario bijection | G1 | Every AC in `ac-draft-{story}.md` maps to ≥1 scenario. No scenario exists without a traceable AC. | All ACs covered, no orphan scenarios. | BLOCKER | | Edge case representation | G2 | Boundary conditions and negative cases from the domain examples in the story are represented as scenarios. | ≥1 edge case or boundary condition scenario per business rule. | HIGH | **Checking G1:** 1. List all ACs from `ac-draft-{story}.md` 2. List all scenarios from `*.feature` 3. Build a trace matrix: AC → scenario(s) 4. Flag any AC with no scenario (missing) and any scenario with no AC (orphan) --- ### Lens 2: business-alignment-lens | Gate | ID | Definition | Pass condition | Fail severity | |---|---|---|---|---| | Business vocabulary | G3 | All nouns, verbs, and adjectives in Given/When/Then steps appear in the domain vocabulary of the stories or the business lexicon. No class names, method names, HTTP verbs, or framework names. | Zero technical identifiers in `.feature` files. | HIGH | | No technical jargon | G4 | Given/When/Then steps contain zero implementation details: no HTTP status codes, no ORM