write-testslisted

Author a complete, passing test suite for one user story, covering every layer the QA plan prescribes for that story's risk profile. Non-autonomous: identify the target, propose cases, get approval, write, then prove green. Never use real secrets or live network calls in tests. ## Phases 1. **Load context** — read `docs/specs/qa-plan.md` to understand the pyramid and conventions; read `docs/specs/prd.md` to list available stories. Ask the user which story or feature to target. If `qa-plan.md` is missing, stop and direct to `/qa-plan`; if the test scaffold is absent (no `vitest.config.ts`), stop and direct to `/test-setup`. 2. **Propose cases** — for the chosen story, enumerate the specific test cases at each layer: (a) unit tests for pure functions/helpers; (b) integration tests for server actions, route handlers, and API routes (using mocked DB/Stripe calls); (c) e2e tests for the critical user path in Playwright; (d) RLS policy tests asserting that other-tenant rows are inaccessible; (e) Stripe webhook tests using `stripe.webhooks.generateTestHeaderString` (or the Stripe CLI `stripe trigger`) with a signed test payload — never real keys. Present the list with a note on what each case catches. Under `full`, confirm each layer separately; under `lean`, one confirmation for the full list; under `solo`, proceed and summarize. Get explicit approval before writing any test code. 3. **Write** — on approval, author the test files in the locations prescribed by the QA plan (e.g. `s