plan-authoringlisted

# Plan Authoring The implementer shares none of your conversation context. It sees the plan file and nothing else. Every ambiguity you leave becomes a decision it makes alone, confidently, and applies to disk. A plan you cannot finish writing means the decision is not formed yet. Form it, or ask the user the open question — *before* dispatching. ## The six sections Five always, plus Decisions when a debate produced the design. ### 1. Objective The outcome in one paragraph, and **the evidence that the problem is real**. Not "the model pin seems broken" — paste the proof: ``` `--show` reports model=gpt-5.6-sol effort=xhigh, while `status --json` for job task-ms4vc08s-vbccvp records "request": { "model": null, "effort": null }. ``` Evidence in the Objective is what stops the implementer from re-litigating whether to do the work. State what is **out** of scope here too, especially the adjacent thing a reasonable engineer would bundle. "A separate plan handles the streaming channel; do not implement it here." ### 2. Files Exact absolute paths, and an explicit **do-not-touch list**. The negative list does more work than the positive one — it names the files a helpful implementer would otherwise improve. ### 3. Steps Ordered, concrete, with the design decisions already made. Reference real line numbers and quote the current code you are changing. If a step says "refactor appropriately," it is not a step. Where a step has a failure mode that a plausible implementation walk