TestBot Anti-Drift Strategy¶
概念概覽
Anti-Drift 的正確起點¶
核心知識¶
Anti-Drift 的正確起點¶
不能先寫宣告性 metadata（如 Step.Covers），因為此時沒有可信基線，文件會比實作樂觀。
正確三階段順序：
1. 先觀測：讓 bot suite 穩定跑通，收集 all_calls.jsonl（實際 RPC 呼叫記錄）
2. 再宣告：基於 all_calls.jsonl 建立 coverage_manifest.yaml（有事實支撐）
3. 最後機械化：才引入 Step.Covers codegen 或其他自動化 metadata
最小防線組合¶
coverage_manifest.yaml ← 可信 RPC 覆蓋基線
migration_lint_test.go ← 防止違規 DDL 進入主幹
bootstrap_test.go ← 驗 fresh DB + upgrade path
Bot Scratch State 的型別安全¶
每個 Step 的臨時狀態應使用 typed StepContext/Scratch（生命週期限單步驟），**不能**用 map[string]interface{} 替換 typed god object。後者犧牲型別安全換來的「靈活性」實際上是 anti-drift 的溫床。
Subagent 驗證原則¶
「確認檔案存在 ≠ 確認內容正確」。Subagent 回報的 code review 結論必須透過直接讀取檔案驗證，不能盲目信任。
經驗教訓¶
-
anti-drift 起點是觀測（all_calls.jsonl），不是宣告（Step.Covers）
-
Bot scratch 要用 typed struct，map[string]interface{} 是 anti-drift 溫床
-
Subagent 輸出需要直接驗證，不能只信回報
常見陷阱¶
-
先寫 Step.Covers 宣告性 metadata，導致文件比實作樂觀
-
用 map[string]interface{} 當 step scratch，失去型別安全
-
接受 subagent 的「確認存在」作為「內容正確」的證明
最佳實踐¶
-
先讓 bot suite 穩定跑通收集基線，再建立 coverage_manifest.yaml
-
coverage_manifest 建立在 all_calls.jsonl 可觀測事實上
-
bootstrap test 同時跑 fresh DB 和 upgrade path
相關概念¶
- e2e-test-coverage----dangling---
- golang-migrate Transaction Safety Contract
- Release Gate Layering
來源 Sessions¶
| 日期 | Session | 貢獻摘要 |
|---|---|---|
| 2026-03-30 | 45cbfb38-30e4-4de0-9d9c-1ea02a62e945 | 確立「先觀測，再宣告，最後機械化」的 anti-drift 建立順序，避免先寫宣告性 metadata 導致文件比實作樂觀的問題 |