plan-changelisted

# Plan the change before writing code Implementing without a plan is how a ticket drifts: you discover scope mid-edit, touch files the ticket never asked about, and finish with a diff no one can map back to the ACs. A short, written plan fixes the target *before* you move — you commit to a scope and a verification path, then execute against it (and later self-review against it). The plan is a tool, not a deliverable. Keep it tight: a few lines per AC, not a design doc. Its only job is to make scope and proof explicit before the first edit. ## Steps 1. **Re-read the ticket and its ACs.** Call `get_ticket` (Dispatch MCP). The acceptance criteria — not your sense of the task — define what "done" means. Hold each one. 2. **Consult memory so the plan respects conventions.** Call `search_lore` (Memory MCP) for relevant conventions, ADRs, test commands, naming rules, and ownership boundaries. A plan that ignores an existing convention produces a correct-but-rejected PR. 3. **Map each AC to a concrete change.** For every acceptance criterion, write a line or two: - **which files** you will edit or add (real paths — locate them now, not mid-edit); - **what the edit is** in one phrase (the actual change, not "implement the feature"); - **what test proves it** — the specific test you'll add or run, and the command that runs it. Every AC needs a verification path before you start, not after. 4. **Name what's out of scope — explicitly.** List the tempting-but-ex