test-design-mandateslisted

# Test Design Mandates ## Overview Five mandatory rules that govern how tests are designed in a Clean Architecture context. Applied after Gherkin scenarios are written, before any implementation starts. **Core principle:** Tests enter through a use case boundary and assert at the next visible boundary. Never test internal classes directly. --- ## Mandate 1 — Layer Boundary Enforcement **Rule:** Every AC names its **use case boundary** — the Application layer entry point the test enters through. All tests at the Application layer enter through that use case. Assertions are made via application interfaces (repositories, gateways) or the use case return value. Never instantiate an internal domain class directly in a test that is exercising Application behaviour. **Why:** Prevents TBU (Tested But Unwired) defects — production code that works in isolation but is never called through the real composition root. **Application:** - Acceptance test → enters through `{UseCaseName}` use case / command handler - Domain unit test (when extracted) → enters through the domain function or policy's public signature - Infrastructure test → enters through the application interface (repository contract) **TBU detection checklist (run after GREEN):** - [ ] Can I delete the production implementation and still have the test pass? → Wired? YES = TBU - [ ] Is the use case wired in the DI container? → Not tested if no integration test exercises the wiring - [ ] Does the acceptance test use an