Parent: #1936
Problem
src/db/schema.ts (1000+ lines) is a single shared file where two independently-valid PRs can each add a new column to the SAME table — git usually auto-merges this cleanly (non-overlapping lines), producing a schema.ts that compiles and typechecks fine in isolation for each PR, but whose corresponding migration files (numbered independently, guarded by the migration-collision checks in this batch) may not actually match the merged schema.ts state, or two PRs may pick genuinely conflicting semantics for a shared table without git ever flagging a textual conflict. This is the "second half" of the same collision class the migration-numbering/column guards only half-solve — flagged for awareness, not yet a fully-specified build. Lower priority / larger effort than the other merge-race items in this batch; do not start until those ship and their pattern is proven.
Requirements
- Investigate whether
src/db/schema.ts's declared columns can be diffed against the actual migrations/ directory's cumulative effect (e.g. by replaying migrations against a fresh DB and comparing the resulting schema to Drizzle's declared shape) as a CI check.
- Scope a concrete design before implementing — this issue starts as a design/investigation task, not a ready-to-build spec like its siblings in this batch.
Deliverables
- A short design note (in the issue itself, as a comment, or a doc) evaluating feasible approaches: e.g.
drizzle-kit check/drizzle-kit up drift detection, a custom migration-replay-and-diff script, or accepting this is adequately covered by the column-collision check (issue: same-table/same-column collision detection) and closing this as not-needed.
- If a concrete approach is chosen, the actual CI check.
Acceptance criteria
- A design decision is made and documented: either a concrete drift-detection mechanism ships, or this is explicitly closed as subsumed by the column-collision check with reasoning.
Expected outcome
Either a genuine schema-vs-migrations drift guard closes the remaining half of the migration-collision problem class, or the team explicitly confirms the column-collision check already covers the practical risk and this is closed with that reasoning documented.
Parent: #1936
Problem
src/db/schema.ts(1000+ lines) is a single shared file where two independently-valid PRs can each add a new column to the SAME table — git usually auto-merges this cleanly (non-overlapping lines), producing aschema.tsthat compiles and typechecks fine in isolation for each PR, but whose corresponding migration files (numbered independently, guarded by the migration-collision checks in this batch) may not actually match the mergedschema.tsstate, or two PRs may pick genuinely conflicting semantics for a shared table without git ever flagging a textual conflict. This is the "second half" of the same collision class the migration-numbering/column guards only half-solve — flagged for awareness, not yet a fully-specified build. Lower priority / larger effort than the other merge-race items in this batch; do not start until those ship and their pattern is proven.Requirements
src/db/schema.ts's declared columns can be diffed against the actualmigrations/directory's cumulative effect (e.g. by replaying migrations against a fresh DB and comparing the resulting schema to Drizzle's declared shape) as a CI check.Deliverables
drizzle-kit check/drizzle-kit updrift detection, a custom migration-replay-and-diff script, or accepting this is adequately covered by the column-collision check (issue: same-table/same-column collision detection) and closing this as not-needed.Acceptance criteria
Expected outcome
Either a genuine schema-vs-migrations drift guard closes the remaining half of the migration-collision problem class, or the team explicitly confirms the column-collision check already covers the practical risk and this is closed with that reasoning documented.