先決定拿哪個現況當基準
要看已知的資料庫樣子，就選 schema cache；要看 application model，就指定 ORM artifact。一次只選一種，報告才知道自己在和誰比較。
dbcli impact assess --design ./dbcli.design.json --against-cache --output ./impact.json --format json --fail-on warn變更審查
要刪欄位時，先問「誰還在靠它做事？」
產品想拿掉一個舊欄位，migration 還沒寫。這時最有用的不是一句「看起來沒人在用」，而是把本機已知證據整理出來，也把不知道的地方明白標出來。
這次要審的變更：團隊準備刪欄位、改型別或調整關聯。release reviewer 想在討論 DDL 前先看：目前 schema 或 ORM 定義下，哪些 contract、saved query 名稱與驗證紀錄可能相關？
一份不假裝全知的影響報告
有宣告過的 workload 證據時才帶進來
明確指定的本機 events 檔可以補上近期、經 redaction-first 投影的資料表 metadata。它始終是可選證據；缺少、過期、格式錯誤、讀不到或被隱藏的 workload 資料都會留在報告裡成為 coverage gap。
dbcli impact assess --design ./dbcli.design.json --against-orm ./prisma/schema.prisma --events ./.dbcli/proxy/events.jsonl --output ./impact.md --format markdown --fail-on neverfindings 與 gaps 要一起看
把報告和設計變更一起放進 migration review。semantic contracts、saved-query 名稱、verification metadata 與已審閱的 data-access metadata 都能補強已知的依賴，但 gap 同樣是結果的一部分。