planning-work
Planning work
Return a plan the caller can execute without re-deriving it: where the change belongs, what it must preserve, the steps in order, and how each step is checked. The plan is the deliverable; do not implement it.
Start from the goal
From the brief, write down what the system does when the work is done, what check would show it is correct (the tests, outputs, or commands the plan ends with), and what must not change. If the brief leaves one of these open, decide it from the code and record the decision.
Read the code first
Do not plan against code you have not read. Find where the change belongs and what pattern to follow: the closest existing analog (a sibling module, a similar endpoint, a comparable test), its callers, its types, and its tests. Use rg for exact symbols and rg --files <dir> for layout; batch independent reads into one shell_command call. Read more when a mistake would cost more: a contained change needs the file and its neighbors; a change to a system other code depends on needs enough context to see why the code is the way it is.
Check facts you can check instead of listing them as open questions. Confirm a dependency's behavior in the version the project uses, not from memory.
Do not modify files or run package managers, builds, or tests; the plan says what to run, the caller runs it.