Engineering
Schema Migration Dry Run
Make the database change prove itself somewhere safer than the real thing.
Use when
A schema change, backfill, cleanup script, or bulk edit could corrupt data, lock tables, or surprise users if run directly in production.
Advanceddifficulty
Engineeringcategory
Mia daily expansionsource
Cadence
Before production database migrations or bulk data changes
Verification
Migration runs cleanly on a recent snapshot or staging clone, row counts and sample records match expectations, rollback is documented, and production execution remains approval-gated.
Structured loop spec
| Field | Value |
|---|---|
| Name | Schema Migration Dry Run |
| Category | Engineering |
| Trigger | Before production database migrations or bulk data changes |
| Objective | Make the database change prove itself somewhere safer than the real thing. |
| Allowed inputs | Relevant files, source notes, logs, tests, screenshots, metrics, or task state for this loop |
| Allowed actions | State the intended data shape, affected tables, expected row counts, downtime assumptions, and explicit non-goals.; Run the migration or script against a recent snapshot, staging clone, or disposable local copy with production-like constraints.; Compare before/after schema, counts, sampled records, indexes, permissions, and application queries for the touched paths.; Write the rollback or forward-fix plan, including what evidence would trigger it.; Do not run against production, delete data, or change live schedules without explicit approval and a named operator. |
| Verification | Migration runs cleanly on a recent snapshot or staging clone, row counts and sample records match expectations, rollback is documented, and production execution remains approval-gated. |
| Stop condition | Stop when the verifier passes, the budget is exhausted, no progress is made, a blocker appears, or approval is required. |
| Budget | Set a time, turn, token, retry, file, or dollar cap before running the loop. |
| Approval boundary | Human approval required before publishing, sending, deleting, spending, changing accounts, touching production, or making reputational/legal/financial commitments. |
| Safe output | Pull request, patch, report, or evidence log |
| Works with | Claude Code, OpenAI Codex, Cursor, Gemini CLI, any tool-using coding agent |
Steps
- State the intended data shape, affected tables, expected row counts, downtime assumptions, and explicit non-goals.
- Run the migration or script against a recent snapshot, staging clone, or disposable local copy with production-like constraints.
- Compare before/after schema, counts, sampled records, indexes, permissions, and application queries for the touched paths.
- Write the rollback or forward-fix plan, including what evidence would trigger it.
- Do not run against production, delete data, or change live schedules without explicit approval and a named operator.
Prompt
Run the Schema Migration Dry Run loop. Before any production database migration, backfill, cleanup script, or bulk edit, state the target shape, affected tables, expected row counts, risks, and non-goals. Execute against a recent snapshot, staging clone, or disposable local copy first. Compare before/after schema, counts, sampled records, indexes, permissions, and touched application queries. Produce rollback or forward-fix steps and stop for explicit approval before production execution, destructive changes, or live schedule changes.Run in Claude Code
Paste this into Claude Code (or any tool-using agent) to run the loop bounded: one change per round, the same verification every round, durable state files, and explicit stop conditions.
Run the "Schema Migration Dry Run" loop from AI Loop Library (https://ailooplibrary.com/loops/schema-migration-dry-run/) as a bounded loop.
Goal: Make the database change prove itself somewhere safer than the real thing.
Rules: one change per round; run the same verification every round (Migration runs cleanly on a recent snapshot or staging clone, row counts and sample records match expectations, rollback is documented, and production execution remains approval-gated.); append each round to docs/loops/schema-migration-dry-run/progress.md and update docs/loops/schema-migration-dry-run/state.json; stop on verifier pass, 8 rounds, 3 consecutive failed verifications, no progress, a blocker, or anything needing human approval (money, production, outbound, deletion). Finish with a proof report: rounds used, changes made, verification output, remaining risk, and the next human decision.