用途：把 Drizzle 的 schema 变更端到端发布到生产。生产迁移由 Matt 手动执行（ADR 0026）；apps/remote 每次合并都会部署，其构建脚本在检测到生产缺少本次提交的最新迁移时会故意失败，旧部署继续服务。流程是：你合并、Matt 迁移、你再重新部署。
主要能力与用法：
- 生成并合并：修改 packages/core/db/schema.ts 后运行 pnpm db:generate，原样提交生成的 SQL 与 meta/ 文件。迁移必须为增量式（新表、可空列或带默认值的列），可与使用它的代码同一 PR 发布。
- 部署失败与 Matt 迁移：合并提交的 apps/remote 部署会以 production has not applied <tag> 失败，这是预期且无害的。给 Matt 发一条消息，附迁移 tag 和命令：git switch main && git pull --ff-only && pnpm db:migrate，然后等待其确认，期间不要重试或轮询。
- 重新部署并确认：用 npx vercel@latest ls course-video-manager-remote --scope matt-pococks-projects -m githubCommitSha=<merge-sha> --json 找到失败部署的 url，再执行 npx vercel@latest redeploy <url> --scope matt-pococks-projects。若仍报 production has not applied，说明迁移未生效，告知 Matt 并引用 tag，不要循环重部署。确认时用 gh api graphql 查询提交状态上下文，检查 Vercel 为 SUCCESS 且 createdAt 晚于重新部署时间；REST 的 commits/<sha>/statuses 对该仓库返回 HTTP 500。
- 破坏性变更采用先契约后删除：删除或重命名列/表、或把列改为无默认值的 NOT NULL，需分两个 PR：先停止使用并合并部署成功，再生成并合并删除迁移，然后走第 2、3 步。重命名为新增→复制数据→切换代码→删除旧列。
限制：绝不运行 pnpm db:migrate 对生产，也不以其他方式写生产；不要运行 vercel deploy --prod（会上传工作树而非 main）。本地 apps/local 也使用生产数据库，落后时会打印警告，修复命令同第 2 步。vercel redeploy 是否向提交发布新的 Vercel 状态尚未确认，需同时报告 Ready 行和 URL。