outside-in-tddlisted

# Outside-In TDD ## Overview Complete testing methodology for outside-in development. Start from observable behavior (Gherkin), let design emerge from tests. **Core rule:** Real domain objects, mocked external boundaries, fast in-memory tests. ## Double-Loop TDD Architecture - **Outer loop** — Acceptance test (customer view): business requirement. Stays RED while the inner loop cycles. - **Inner loop** — Unit tests (developer view): technical decomposition. RED → GREEN → REFACTOR in minutes. Outer drives **WHAT** to build, inner drives **HOW**. Never build a class not required by an active scenario. ## 4-Phase Cycle (per behavior slice) ### 1. PREPARE (owned by this skill) Identify the **input boundary** (use case / interactor the test enters through) and the **output boundaries** (gateways the test observes: repositories, presenters, external services). Target exactly ONE scenario. ### 2. RED & 3. SYNTHESIZE-GREEN (delegated to `red-synthesize-green`) The mechanics of RED (wishful thinking, behavior failure), the mandatory architectural gate, and SYNTHESIZE-GREEN (clean one-shot synthesis, NOT dirty-then-refactor) live in the `red-synthesize-green` skill. Follow it exactly. ### 4. COMMIT & VERIFY (owned by this skill) - Run the **Post-GREEN Wiring Verification** (see below) to detect Fixture Theater. - Run the `mutation-testing` skill. 100% on business logic; equivalent mutants only accepted survivors. - Commit using conventional commits (`feat(<domain>): <behavior