[NewWorldVenture]

supabase_migrations.schema_migrations has a PRIMARY KEY on version, so it physically cannot hold two rows for 0010. This repo carried 17 duplicate version numbers, which made that table unusable for it:

ERROR: duplicate key value violates unique constraint "schema_migrations_pkey"
Key (version)=(0010) already exists.

That blocked Supabase branching outright, and it sits directly in the path of the production ledger repair (LB-016 §4), which replays the history into the same table. The duplicates were dormant only while nothing tried to record them.

The rename

Every colliding group gets a unique version preserving apply order — the scheme scripts/ci-dedupe-migration-versions.mjs already used in the disposable CI checkout and proves order-preserving:

0010_blog_posts.sql                  → 00100_blog_posts.sql
0010_support_tickets_admin_users.sql → 00101_support_tickets_admin_users.sql

"00100" < "00101" < "0011" and > "0009", so nothing moves relative to its neighbours. 35 files across 17 groups; 291 migrations, contents unchanged.

Why now, and not later

The audit warned that renaming risks drift against a production database that "records applied versions by that prefix". Production's ledger holds only 0001–0003, so none of these 17 versions is recorded anywhere — there is nothing to drift from. Once the ledger is repaired that stops being true, so the rename had to come first. This was the free window.

Guardrails

KNOWN_DUPLICATE_MIGRATIONS is now empty and stays exported — the collision check still runs, so a new duplicate fails the audit instead of being absorbed. migration-version-safety now asserts there are no duplicates at all, that the escape hatch is empty, and that every version is unique, replacing the test that asserted collisions matched an approved list.

nextVersion needed fixing to survive this: it took Math.max over Number(version), and Number('01421') is 1421 — which would have pointed the next migration at 1422. It now reads the first four digits (the generation), so the 5th digit that orders files within a generation doesn't leak into numbering. Audit now reports 0276.

Ledger repair (the other half)

Adds docs/audit/migration-ledger-state.sql — a read-only pre-flight — and rewrites LB-016 §4 from "repair the ledger baseline" into an actual procedure:

• What the repair is: not stamping. Every migration is additive and idempotent (migrations-are-additive.test.ts), and CI replays all 291 against real Postgres, so letting db push run from 0004 repairs the ledger by doing the work. Writing rows by hand asserts work was done without doing it, and a migration wrongly marked applied is skipped forever.
• A window nobody had flagged: a replay runs 0006's is_family_member finance policies before 0267 narrows them and 0275 sweeps. End state correct; intermediate state briefly open. Maintenance window, not live traffic.

Verification

tsc --noEmit clean · 900 files / 7,700 tests pass · migration audit reports next version 0276 · dedupe script now finds 0 files to rename.

Two tests opened a renamed migration by name and failed to load; both fixed. Swept for other hardcoded paths — the remaining misses are synthetic fixtures and three stale references in production-migration-contract that predate this change on main.

🤖 Generated with Claude Code

https://claude.ai/code/session_01TRY21ZKsFrfB3qtoP972A4

---

Generated by Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
bubaly	Ready	Preview	Sep 7, 2026 6:43pm UTC