Day 27 處理證據到期與相容性重驗。今天遇到一筆真正不符合契約的結果：先不要急著寫「已修好」，也不要直接把所有錯誤都歸因於模型。把失敗縮成可重現的輸入，才能知道修正改了什麼。

以下是 ticket-source-guard 的合成事件案例，不是真實事故紀錄，也不表示下面的測試已在公開專案執行。

先保存最小事件紀錄

事件紀錄不是把整份聊天存進 repository。需要的是版本、輸入、預期、實際結果，以及缺少哪些資訊。

事件：額外 host suffix 被誤判為已登錄來源
Skill / script：固定 commit
registry：固定版本與有效日期
輸入：tickets.example.test.other.test
預期：UNCONFIRMED
實際：REGISTERED_SOURCE
環境：執行方式、依賴版本、評估日期
狀態：可重現，原因尚未確認

兩個狀態名稱都是本範例的契約。REGISTERED_SOURCE 也不代表票券真偽或交易授權。原始輸入若帶私人活動、token 或 cookie，先改成仍能重現 host 邊界問題的合成 fixture。

縮小案例，不改寫事實

先確認失敗發生在哪一層：URL 解析、host 正規化、registry loader、分類器，還是 agent 最後的文字解讀。script 正確、agent 卻寫錯結論，和 script 本身錯誤，需要不同測試。

同一個輸入與 registry
→ 直接呼叫 script
→ 核對 JSON 與退出碼
→ 再走完整任務路徑
→ 比對最後文字是否保留狀態與限制

保留能造成失敗的最小條件。不能為了讓案例簡單，把額外 suffix 刪掉；也不能把預期結果改成程式目前輸出的值，讓紅燈看起來消失。

先寫會失敗的測試

pytest 可以用一般 assert 比對預期值，並在失敗時顯示差異。下面只是一個介面示意；實際函式名稱與參數要對應專案。

def test_extra_host_suffix_is_not_registered():
    result = classify_host(
        "tickets.example.test.other.test",
        registered_hosts={"tickets.example.test"},
    )
    assert result["status"] == "UNCONFIRMED"

這個示例不要寫成「已通過」。真正修正前，要在舊版本看見同一個斷言失敗；如果舊版本也通過，測試可能沒有走到出問題的分支，或案例還缺條件。

修正後要跑鄰近邊界

修好一個相似網域，不表示所有 host 規則都正確。補上鄰近案例，避免把錯誤從一邊推到另一邊。

精確相同 host：依證據狀態判斷
額外 suffix：不可當成精確相同 host
合法子網域：只有契約允許時才接受
大小寫與尾端點：依既定正規化規則
過期或撤銷來源：不能因 host 相同恢復可信

再重跑既有 schema、script 與任務型 eval。記錄 case_id 的結果，不只留下「全部綠燈」的截圖。仍未驗證的環境，要明確保留未測狀態。

回退不是刪掉問題紀錄

若新版本造成重大行為改變，可以準備回退到已知版本，但先核對那個版本是否仍適用。過期或撤銷的來源不能因程式回退就重新有效。

GitHub 的比較檢視可以比較分支、tag 與 commit，幫助核對變更範圍；diff 本身不會證明安全或測試成功。

回退前
- 固定來源與目標版本
- 確認資料與契約相容性
- 保留事件紀錄與失敗 fixture
- 記錄回退理由及尚未修正的限制
- 核對回退後實際內容與結果

不要讓「恢復服務」變成「根因已修好」。停止影響、找到原因、修正並驗證，是不同里程碑。

用證據寫結案，而不是用語氣

結案紀錄要能連到失敗案例、變更、驗證版本與發布內容。不能重現時寫待釐清；修正只在 script 通過時，不能宣稱完整 agent 路徑也通過。

今天完成的驗收標準

[ ] 事件紀錄保留版本、最小輸入、預期與實際結果
[ ] 合成 fixture 沒有移除真正的失敗邊界
[ ] 回歸測試在舊版本失敗、修正版本通過
[ ] 鄰近案例與既有 eval 有逐筆結果
[ ] 回退不復活失效證據，也不刪掉事件紀錄
[ ] 結案區分止血、根因、修正與完整驗證

參考資料
https://docs.pytest.org/en/stable/how-to/assert.html
https://docs.github.com/en/pull-requests/committing-changes-to-your-project/viewing-and-comparing-commits/comparing-commits

明天預告

Day 29 從需求到安裝與任務結果，整理發布前的最後驗收，確認讀者拿到的是同一份經過驗證的內容。