上線前檢查

PR 裡有新欄位，不代表正式資料庫也準備好了。

一個服務準備上線，Drizzle snapshot 多了一個欄位；但正式環境可能有手動修正或延後的 migration。先把兩邊差異攤開，才知道 deployment 要不要停。

這次要確認的事：團隊把 model 變更放進 release，但沒有人能只靠檔名保證 production 長什麼樣。這裡要回答的是：差在哪裡？是預期中的差異，還是漏掉的 migration？

上線前的比對紀錄

先取一份可對照的正式結構

先檢查黑名單，再讀完整 schema。這份結果是比對基準；它也避免 Agent 根據 model 名稱猜資料庫欄位。

dbcli blacklist list
dbcli schema --format json

把 snapshot 和目前資料庫直接比

指定支援的 ORM schema 或 snapshot，報告會列出具體差異。看到「少欄位」或「型別不同」時，團隊可以回到 migration 與版本紀錄，而不是猜是哪一次部署留下的。

dbcli diff --against-orm ./drizzle/meta/0000_snapshot.json --format markdown

讓報告進審查，不讓它直接變 DDL

把 drift 報告帶進 migration review。dbcli 幫忙整理結構事實；是否建立、修改或執行 DDL，仍由有權限的人依團隊流程決定。

dbcli skill tasks plan migration-review \
  --param "table=<精確資料表名稱>" \
  --param "ddl=<已擷取的 dry-run DDL>"