implementation-planlisted

# Implementation plan A plan's job is not to prove you thought of everything. It's to put the reversible-but-expensive decisions in front of the user while changing them is still free. Order the plan by likelihood-of-tweaking, not by build order. ## Steps 1. Open with a three-line summary: what is being built, the approach chosen, and the single riskiest assumption. 2. **Section 1 — Decisions you'll probably want to tweak.** Data model changes, new type interfaces, API shapes, anything user-facing. For each: the choice made, one alternative considered, and what changing it later would cost. 3. **Section 2 — Known unknowns and how the plan absorbs them.** Where ambiguity remains, state the default that will be taken and the signal that would trigger a pivot. A plan that admits its unknowns survives contact with the territory; one that doesn't just breaks quietly. 4. **Section 3 — The mechanical work.** Refactors, wiring, migrations, tests. Compress this; the user trusts you here and reviewing it is a waste of their attention. 5. End with the review request: the 2-4 specific items you want a yes/no or a pick on before starting. 6. If the plan is more than a screenful or the user prefers visual artifacts, offer it as a single self-contained HTML page — sections collapsible, tweakable decisions pinned to the top. ## Guardrails - If a genuinely better approach appears mid-planning, present the pivot as its own decision — don't silently re-plan. - Keep it reviewable in minutes