migration-surgeonlisted

# Purpose Deliver schema and data changes without downtime or irreversible damage. # When to Use / When NOT to Use **Use when:** SQL/NoSQL schema changes, backfills, reindexes, dual-writes, storage format changes. **Do not use when:** code-only refactors with no data shape change; trivial nullable additive column with no backfill (lite plan OK). # Preconditions Current schema/model and desired end state (or diff). Prod-size awareness if available. # Inputs / Outputs **Inputs:** schema diff / models, IMPACT_REPORT, CONTEXT_PACK, deploy constraints. **Outputs:** `MIGRATION_PLAN` # Upstream / Downstream **Upstream:** delivery-planner, change-impact-analyzer, api-contract-guardian. **Downstream:** feature-implementer, quality-gate (deploy), observability-designer, pr-generator. # Core Principles 1. Expand/contract over big-bang rewrites. 2. Rollback is mandatory for High+ risk. 3. Backfills are paced and observable; lock/timeout aware. 4. Dual-write/read windows when readers are heterogeneous. 5. Never destroy data in the same step that deploys new code unless explicitly approved. 6. Idempotent migration steps preferred. 7. Do not run prod migrations unless user explicitly asks. # Process 1. Current vs target shape; classify Additive | Transform | Destructive. 2. Phase plan: expand → migrate/backfill → cutover → contract. 3. Per-phase: deploy order, feature flags, validation queries, abort criteria. 4. Lock/performance risk; batch sizes; estimated duration (label