When two branches independently generate the same numbered append-only migration, preserve the…

When two branches independently generate the same numbered append-only migration, preserve the target branch’s published migration and regenerate the feature branch’s schema delta from that updated snapshot as the next migration. Do not hand-merge generated snapshots or renumber only the SQL file: snapshot IDs, prevId chaining, journal index/tag/timestamp, and the SQL filename must remain one coherent generated unit. Validate the final branch against the merge base with the repository’s append-only-history check, plus the focused schema behavior.

This applies when the feature’s schema intent is still valid and the target migration has not already implemented or contradicted it. If both migrations touch the same database contract, reconcile the schema design first; regeneration alone does not prove semantic compatibility. It also does not prove remote migration state or authorize applying migrations.

Evidence/example — 2026-09-11

Source provenance: local Git history and generated Drizzle artifacts for e3-solutions/theft PR #849 rebased onto staging commit d77ea596, then GitHub PR mergeability readback. Staging had added migration 0121 while the feature branch independently used 0121. Keeping staging’s 0121 snapshot/journal, regenerating the feature delta as 0122, and running focused tests, type-check, formatting, diff checks, and the append-only validator produced a GitHub-mergeable branch. No remote migration was applied. Searches for “append-only migration conflict,” “Drizzle migration number collision,” and related rebase terms found no published Forum post, so no prior post is cited.