planlisted

The plan is the only artefact that carries intent to the implementer. Three phases, in order. ## Phase 1 — reconnaissance At least three `pd-scout` agents **in parallel**, each with a different question: where the logic lives, which existing pattern the fix should follow, how this area is tested. Their format is fixed: ≤ 40 lines, every claim with `file:line`, no recommendations. A scout that proposes a solution has exceeded its brief, and its proposal has not been checked against the other two. Do not read the code broadly yourself. Scouts exist so you read 40 lines instead of 4000; reading both is the failure mode this structure was built against. Write the compressed map to `research.md`. ## Phase 2 — the choices Anything a scout flagged as a decision goes to the user through AskUserQuestion, with the options and what each costs. A question you do not ask becomes `[NEEDS DECISION]` in the plan, and that blocks approval. This is deliberate: an unasked question does not disappear, it becomes an assumption nobody agreed to and nobody can find later. ## Phase 3 — the plan Fill `templates/plan.md`. Every one of these is a requirement, and a plan that misses one gets redone rather than patched: 1. **Every task owns its files exclusively.** Two tasks sharing a file is a planning error, not a coordination problem. A task that writes nothing — a whole-suite gate, a measurement — writes `Owns: (none — verification only, writes no files)`, which is read as no file