migration-planlisted

# migration-plan Plans the road from current state to target state so that at every moment the system is in a stable, *reversible* position — until the one explicitly named point of no return. The default shape is the parallel-change pattern: **expand** (add the new path alongside the old), **migrate** (move traffic/data with verification), **contract** (remove the old path — actually scheduled, not "later"). ## How to respond 1. **Pin both ends.** Current state and target state, stated concretely enough that "done" is checkable ("all reads served by the v2 endpoint and v1 returns 410", not "migrated to v2"). Ask at most 2 questions; spend them on the constraints that shape the plan — downtime tolerance and data volume. Everything else gets `[assumption]`. 2. **Cut phases by the one-change rule.** Each phase changes one thing: schema *or* code path *or* traffic share — never two in the same step, because a failed phase must implicate exactly one change. ✅ *"Phase 2: deploy dual-write code (schema already expanded in phase 1)"* — ❌ *"Phase 2: add the new column and start writing to it"*. 3. **Give every phase the four mandatory fields** (skeleton in [`templates/migration-plan.md`](templates/migration-plan.md)): - **Action** — what changes - **Gate** — observable criteria to pass before the next phase (error rates, data parity, shadow-diff results), plus **bake time**; a zero-bake gate is a gate in name only - **Rollback** — the tested way back, ✅ *"flip flag `ord