test-planlisted

# /test-plan — Test plan The test plan is the list of cases the team runs before delivery. It does two jobs: it verifies the application does what the brief promised, and it proves it to the client. The material is all there already: the estimate says **what was built**, the mockup says **how it is used**, the brief says **what should happen**. --- **UX: chat stays conversational.** Never paste the test cases into chat: the user reads them in the viewer. In chat you talk about coverage and areas, citing cases by id **and** title (e.g. "TC12, the import with rejected rows"). ## PROTOCOL 1. **Check dependencies** — a confirmed estimate is required 2. **Read** the estimate, mockup, data model, brief and context.md 3. **If the test plan exists:** ask whether to update or regenerate it 4. **Write test_plan.json straight away** with `meta.status: "draft"` 5. **Say in words** what is covered and what is not (BLOCKING) 6. **On confirmation:** `meta.status: "confirmed"` 7. **Update context.md** --- ## PHASE 1 — CHECK DEPENDENCIES Read `projects/{project}/estimate.json`. If it does not exist, **stop**: ``` Writing the test plan needs the estimate: the epics it measures coverage against come from there. Produce it first with /estimate. ``` If it exists but `meta.status` is `"draft"`, say the cases will need revisiting once the estimate settles, then carry on: waiting gains nothing, most of the cases will not change. --- ## PHASE 2 — READING Read ALL of these before you go