A schema edit committed without running the migration generator passes every quality gate and CI, and then deploys a migration set that does not create the columns the app queries. The failure would surface only at runtime in production, as SQL errors on the first query that touches the missing column. The cost of leaving this alone grows with every schema change, because each one is a fresh chance to forget the generate step; the fix costs one additional gate task.
Background: the database schema lives twice, by design of the Drizzle toolkit. packages/db/src/schema.ts and auth-schema.ts are the TypeScript source of truth the app compiles against, and packages/db/drizzle/*.sql are generated migration files that actually create the tables in Postgres. The bridge between them is a manual command (the workspace's drizzle generate script). Nothing verifies the two sides agree: the tests assert against the TypeScript side only, and the migrations are applied only when someone runs them against a database.
Proposed direction, to be decided: a packages/db test or a gate task that runs the generator against a temporary output directory and fails when it produces a non-empty diff versus the committed drizzle/ folder. This touches the quality-gate surface, which AGENTS.md says to propose before changing, hence this issue rather than a direct change.
Found by the delta verification pass on PR #2 (data-integrity lens).
A schema edit committed without running the migration generator passes every quality gate and CI, and then deploys a migration set that does not create the columns the app queries. The failure would surface only at runtime in production, as SQL errors on the first query that touches the missing column. The cost of leaving this alone grows with every schema change, because each one is a fresh chance to forget the generate step; the fix costs one additional gate task.
Background: the database schema lives twice, by design of the Drizzle toolkit. packages/db/src/schema.ts and auth-schema.ts are the TypeScript source of truth the app compiles against, and packages/db/drizzle/*.sql are generated migration files that actually create the tables in Postgres. The bridge between them is a manual command (the workspace's drizzle generate script). Nothing verifies the two sides agree: the tests assert against the TypeScript side only, and the migrations are applied only when someone runs them against a database.
Proposed direction, to be decided: a packages/db test or a gate task that runs the generator against a temporary output directory and fails when it produces a non-empty diff versus the committed drizzle/ folder. This touches the quality-gate surface, which AGENTS.md says to propose before changing, hence this issue rather than a direct change.
Found by the delta verification pass on PR #2 (data-integrity lens).