Write an implementation plan

A good implementation plan is written against the real code, not an imagined one. Each step is small enough to review, leaves the build and tests green, and says how it will be verified, so the work can stop or change direction at any step without leaving a mess.

Plan the implementation of: [GOAL] Only if [CONSTRAINTS] is given: Constraints: [CONSTRAINTS]

1. Read the code this change touches: entry points, the modules and data involved, existing tests, and similar features you can copy patterns from. Do not plan from file names alone.
2. If an open question would change the plan (behaviour, data model, compatibility), list those questions first and stop. Ask only questions the code cannot answer.
3. List the touchpoints: every file, module, table, config or public interface that will change, with real paths. Mark new files as new.
4. Write the steps in order. Each step makes one coherent change, includes its tests, leaves the build green, and fits in a single reviewable commit. Prefer an order that gets a thin end-to-end path working early.
5. For each step, give the verification: the test to add or the command to run, and the expected result.
6. Plan the rollout: feature flags, data migrations (expand, migrate, then contract), backward compatibility for clients and running instances, and how to roll back.

• Plan only. Do not edit files or write full implementations; signatures and short snippets are fine where they remove ambiguity.
• Cite only paths, functions and commands that exist, or mark them as new. Never guess a test command; find it in the repo's scripts or docs.
• Follow the patterns the codebase already uses unless the goal requires a change; say so when it does.
• Read the relevant code before making a claim about it. Do not guess what a file, function or config contains.
• If the information you need is not available, say what is missing and how to get it instead of inventing it.
• Do only what was asked. If you notice something else worth changing, mention it in one line at the end instead of changing it.
• Keep the change as small as it can be while still being correct.

Understanding

Three to five lines: what will change and how it fits the current design.

Touchpoints

Bullets: path — what changes.

Steps

Numbered. Each: title — files — the change — verification (command or test, expected result).

Rollout

Flags, migrations, compatibility, rollback.

Risks

Bullets: risk — mitigation.

Out of scope

Bullets.