run-migrationlisted

Runs the forward-only Drift/SQLite schema-migration ritual — the most dangerous deterministic operation in an offline-first app: a bad migration silently destroys on-device rows that exist nowhere else. Enforces the exact ordered sequence: take a pre-migration file snapshot before the database is opened, bump schemaVersion by exactly one, write an append-only stepByStep forward step (never edit a shipped step, never write a down migration), commit the drift_dev make-migrations schema snapshot, regenerate, then prove it with tests covering every from→to path (incl. multi-version jumps), a write-at-v(n)/read-at-v(n+1) content test, PRAGMA integrity_check + foreign_key_check, and a forced mid-migration throw that restores the snapshot. Manual, side-effecting workflow. Use when adding or altering a Drift table, column, index, or CHECK; bumping schemaVersion; editing onUpgrade/stepByStep; or writing migration tests.
zakariaf/CatchLaw · ★ 0 · API & Backend · score 58

Install: claude install-skill zakariaf/CatchLaw

# Run migration (forward-only Drift schema migration) Apply a schema change to a local Drift/SQLite database by following the exact ordered ritual below. In an offline-first app there is no server and no re-sync path, so the on-device DB is the single source of truth: a migration that drops or corrupts a column permanently destroys hand-entered records that exist nowhere else, and with no telemetry nobody ever reports it — the user just uninstalls. This is a **manual, low-freedom, human-run** workflow. Execute the steps in order; do not improvise, reorder, or skip. ## Non-negotiable rules 1. **Take the pre-migration snapshot FIRST — before the database is opened.** Do it at the composition boundary that opens `AppDatabase`, never inside `onUpgrade`: `PRAGMA wal_checkpoint(TRUNCATE)` any live handle so the `-wal` is folded into the main file, then copy the DB file **and its `-wal`/`-shm` sidecars** while nothing holds the file open. Opening the database is what triggers the migration. Never copy or overwrite bytes under a live connection. The snapshot is the only "rollback" SQLite has; restore it on any failure. 2. **Forward-only. Never write a down migration.** SQLite has no true down migration and you must not pretend to. "Rollback" means restore the snapshot, nothing else. 3. **Steps are append-only — NEVER edit a shipped step.** Editing a released step corrupts data for every user who skips versions. To fix a bug in a prior step, add a *