寫入後驗證

變更已經上了，現在別只在 Slack 回一句「好了」。

資料修正由既有授權流程執行完，審查者還要知道空值是否真的清掉、驗證看到了什麼，以及日後誰能追到這次檢查。這正是回讀和 receipt 的用途。

這次要收尾的事：一張安全 backfill 變更單已在 dbcli 外執行。現在團隊要用同一個條件回讀，保存驗證文物與不含敏感內容的 provenance，而不是把執行紀錄散在聊天訊息裡。

寫入之後，怎麼留下能查的答案

寫入前先把驗收條件跑過一次

驗證指令不會執行 UPDATE 或 DDL。先讓防護檢查目標與回讀條件，並取得精確的 after-write 指令；這樣寫入後不會臨時改驗收標準。

dbcli verify safe-backfill --table users --query "UPDATE users SET status = 'active' WHERE status IS NULL" --verify-query "SELECT count(*)::int AS n FROM users WHERE status IS NULL" --expect "value == 0"

外部寫入完成後，用同一份條件回讀

套用已核准的寫入後，使用同一情境加上 --after-write 執行回讀斷言，再把 verification artifact 和 receipt 留在工作區。

dbcli verify safe-backfill ... --after-write --evidence-receipt .dbcli/evidence/verify-receipt.json

別把 receipt 成功當成資料驗證成功

驗證情境會給 verified、not_verified、indeterminate 或 blocked；receipt 只另記錄 succeeded 或 failed provenance。兩者要一起看，但意思不同。