tdd-speclisted

# TDD from SPEC Test-driven development guided by the approved SPEC SDD. The SPEC is the single source of truth. Every test is derived from a numbered requirement or acceptance criterion. Internal reasoning and commands are in English. All questions and explanations to the user are in **Portuguese (pt-BR)**. ## When to Use - A `.specs/SPEC-{YYYYMMDD}-{feature}.md` exists with `Status: Approved`. - The user asks to implement a feature, change, or bugfix. - Before writing implementation code. ## When NOT to Use - Do not use when the SPEC is missing or still in `Draft`. - Do not use when the user only wants a code review or fix without tests. - Do not use when the SPEC explicitly declines a requirement (marked `[A DEFINIR]`). ## Core Principles 1. **The SPEC is the oracle.** Every test must map to a requirement or acceptance criterion. 2. **One vertical slice at a time.** One failing test, one passing test, one refactor. 3. **No speculative code.** Write only the minimum code to make the current test pass. 4. **No refactor in RED.** Refactor only when the suite is green. 5. **Re-validate after every change.** Run the full suite before moving to the next slice. ## Process ### 1. Read the SPEC Load `.specs/SPEC-{YYYYMMDD}-{feature}.md` and identify: - Section 4 — numbered requirements (`RF-001`, `RF-002`, ...). - Section 6 — acceptance criteria in BDD `Given...when...then`. - Section 7 — task plan and validation strategy. - Section 3 — files to create or modify. If th