test-plan-generatorlisted

# test-plan-generator Produces a test plan that says what to test *first*, what to test *where* (unit vs integration vs e2e), and — the part most plans omit — what is deliberately not tested and why. Downstream of `user-story-splitter` (its ACs map straight into the coverage table); sibling of `feature-implement-loop` (which writes the tests this plan prioritizes). ## How to respond 1. **Ingest the change.** Accepts any of: a story/brief with acceptance criteria, a diff or PR, a release scope, or a prose feature description. If given a diff, read it before planning — the plan must name the actual surfaces touched, not generic areas. Ask at most 2 clarifying questions; tag every other unknown `[assumption]`. 2. **Rank risks before writing a single test case.** Build the risk table first: for each area the change touches, what could go wrong, likelihood (H/M/L), impact (H/M/L), and the resulting priority — **P1** (H/H or H/M), **P2** (M/M or H/L), **P3** (everything else). Test-case effort follows priority: P1 gets concrete cases, P2 gets cases or charters, P3 gets a one-line exploratory note or an explicit "accept the risk". 3. **Push each test to the lowest pyramid level that can catch the failure.** Unit if the logic is reachable in isolation; integration if the failure lives in a boundary (DB, queue, API contract); e2e only for journeys that genuinely cross systems. ✅ *"Discount rounding — unit test on the pricing function"* — ❌ *"Discount rounding — e2e checkout test"