acceptance-driven-developmentlisted

# Acceptance-Driven Development Execute code changes against explicit acceptance criteria, then loop until every criterion has a settled outcome. **Completion layers:** Agent implementation work is done only when no `[ ]` or `[~]` remain. The project is complete only when every AC is `[x]`, `[>]`, or `[-]` — no `[ ]`, `[~]`, or `[!]`. ## 🚨 FIRST RULE — Check Before You Code <EXTREMELY-IMPORTANT> Every code change enters **Phase 3.5** before Phase 4. Announce the phase and the chosen implementation mode before editing code. - Approved `[ ]` / `[~]` backlog → **Phase 3.5A** → Mode A. - New feature or behavior change → **Phase 3.5B** → update AC → discuss → explicit approval → Phase 4. - Bug restoring intended behavior → **Phase 3.5B** impact analysis → fast lane → Phase 4. - Refactor, build/config change, or pure cosmetic change → Phase 3.5B impact analysis → fast lane. Describing a desired change is not approval of an approach. A fast-lane bug fix skips approach discussion, not impact analysis, review, or verification. </EXTREMELY-IMPORTANT> Announce: `Phase 0`, `Gate 1`, `Gate 2`, `Phase 3.5A` or `3.5B`, `Phase 4 Mode A` or `B`, `Phase 4.8`, `Phase 5`, and `Phase 6` when each begins. For rationale, common rationalizations, worked scenarios, extended red flags, and the compact phase map, read `references/guardrails-and-examples.md`. ## Capabilities and Scope ADD is self-contained: AC parsing, impact analysis, review, verification, and completion checks must work eve