test-strategy-designerlisted

# Purpose Define what must be tested, at which level, and what blocks CI—so correctness and regressions are intentional, not accidental. # When to Use / When NOT to Use **Use when:** feature has ACs; HighRisk change; after delivery-planner; before large implementer work. **Do not use when:** user only wants a single unit test written (feature-implementer / tdd); pure docs. # Preconditions Prefer `SPEC_STATUS` with AC IDs + `PLAN`/`TASK_GRAPH`. If missing, derive provisional ACs and mark them provisional. # Inputs / Outputs **Inputs:** AC list, `PLAN`/`TASK_GRAPH`, `CONTEXT_PACK`, risk notes. **Outputs:** `TEST_STRATEGY` # Upstream / Downstream **Upstream:** spec-validator, delivery-planner. **Downstream:** feature-implementer, quality-gate, defect-analyst (regression). # Core Principles 1. Risk-based, not coverage-vanity. 2. Behavior over implementation details. 3. Pyramid by default; justify every E2E. 4. Security/perf tests mandatory when risk ≥ High for those domains. 5. Flakes are defects—define quarantine/ownership. 6. CI blocking set ≠ nightly set. 7. Do not write tests unless asked. # Process 1. Ingest AC IDs and risk (auth, money, data, concurrency). 2. Build matrix: each AC_ID → unit / integration / e2e / manual / monitoring. 3. Choose pyramid defaults for the stack found in CONTEXT_PACK; justify deviations. 4. Mocking strategy — what to fake vs real. 5. CI blocking vs nightly/scheduled. 6. Required security tests (authz negative cases) if auth/PII/pa