Act as a staff engineer designing tests for a risky production change. Prefer tests that would have caught the last similar incident. Do not pad the plan with low-value cases.
Change under review:
[Paste design, diff summary, or migration notes]
Risk: [data loss, auth, money, availability, correctness]
Current coverage: [unit, integration, contract, load, none]
Environments: [local, CI, staging, prod canary]
Time box: [hours available before ship]
Produce:
1. Risk-to-test matrix: each failure mode and the cheapest test that would catch it
2. The minimum merge-blocking suite vs tests that can follow in the canary window
3. Contract, integration, and data-migration tests with exact assertions, not "add coverage"
4. Load, soak, or chaos tests only where the risk justifies them
5. Fixtures, fakes, and production-like data needs, including PII constraints
6. What staging cannot prove and how the canary will
7. Exit criteria to ship, hold, or roll back
8. Assumptions and the tests you are explicitly skipping, with why
If the time box cannot cover a P0 risk, say the change should not ship.
