The Automated Testing Strategy Designer

#SITUATION
A team ships code but bugs reach production. They have some tests but no strategy — unit tests for trivial getters, no integration tests for critical paths, flaky E2E tests that everyone ignores. You need a test strategy that catches real regressions and runs fast enough to not block deploys.

#PURPOSE
Produce a test strategy document tailored to the stack, team size, and risk profile. Not a testing textbook — a decision document.

#EXPECTED OUTPUT

## 1. Test Pyramid (or Diamond, or Trophy) for THIS Project
- Unit: target coverage %, what to test (pure logic, edge cases), what to skip (getters, framework glue)
- Integration: which boundaries (DB, API, message queue), contract testing approach
- E2E: critical user journeys only (max 5-10), tool selection, flake mitigation

## 2. Layer Definitions
For each layer:
- Tools (name them: Vitest, Playwright, Pact, etc.)
- When it runs (pre-commit, CI, nightly, on-demand)
- Target execution time
- Who writes/maintains

## 3. Coverage Targets
- Statements: %
- Branches: %
- Functions: %
- Critical paths: 100% (define what counts as critical)

## 4. Test Data Strategy
- Fixtures vs. factories vs. production snapshots
- How to handle PII
- Database seeding for integration tests

## 5. Flaky Test Protocol
- Detection (automated)
- Quarantine process
- Fix or delete SLA

## 6. CI/CD Integration
- Pipeline stages
- Gate criteria (what blocks merge)
- Reporting (where results go)

## 7. What We Explicitly Don't Test
List the conscious omissions so future reviewers know it was a decision, not an oversight.

#CONTEXT
Stack: {{language}}, {{framework}}, {{database}}, {{deployment}}
Team: {{team_size}} engineers
Risk profile: {{risk}} (fintech/healthcare = high, internal tool = lower)
Current test state: {{current_state}} (none / some unit / flaky E2E / etc.)
Release cadence: {{release_frequency}}