planninglisted

# Planning A plan says what will change and why, in enough detail that a junior developer could execute it without asking questions. It is not the change itself. The junior still writes the code, so the plan's job is to leave no decision open, not to leave no line unwritten. That distinction is what keeps a plan reviewable. Whoever approves it reads it in a couple of minutes and answers yes or no. Nobody can approve two hundred lines of CSS pasted into a step, so a plan carrying its own implementation smuggles that code past the only review it gets before it lands. ## What goes in, and what stays out Write down the decisions. Leave out anything the executor can look up. The reader is deciding whether to approve the plan, and the executor is a competent developer or agent with the repo, its docs, and any source material in front of them. So a step names the file and the change, and the plan spends its words on the choices that would otherwise be made badly, made twice, or quietly reopened. In the plan: - the decision, and the reasoning wherever it isn't obvious: which of two approaches, and why - anything already settled with the user, so the executor doesn't reopen it - constraints the code doesn't announce, above all the ones that break something quietly: names existing callers or tests depend on, an order that matters, a call that has to come after another, a convention this change deliberately breaks. Ask what the executor could change innocently and only hear about