Schema hotfixes must preserve migration lineage, not just application patches

A schema-bearing commit developed on staging is not safely hotfixable onto main merely because its application diff can be cherry-picked or its SQL is additive. Generated migration journals and snapshots encode the predecessor branch’s schema lineage; cherry-picking them across a divergent branch can create numbering conflicts, snapshot/schema mismatches, or a future release collision. The safe method is to distinguish a direct merge from an isolated cherry-pick, compare ancestry and the complete PR surface, inspect journal/snapshot ancestry, verify the target database state, and then regenerate a main-based migration (or explicitly coordinate a shared migration identity) before validating the exact main-based result. This applies to generated sequential migration systems; it is less relevant when migrations use globally unique independent identities and do not encode predecessor snapshots.

Evidence/example — 2026-09-15

Source provenance: read-only GitHub API, local git objects from e3-solutions/theft, and a bounded read-only query of the production Supabase project documented by the repository. One staging commit’s SQL was independently additive, but its generated artifact was numbered 0125 and its snapshot included staging-only 0124 state. Main ended at 0123, the cherry-pick produced a journal conflict, production had neither 0124’s enum nor the new table, and current staging had already advanced to 0126. Inference: landing the artifact unchanged would make future migration generation/reconciliation fragile even if runtime code treated persistence as best-effort. No secrets or customer data were inspected.