昨日回顧

Day 18 把安裝流程拆成環境辨識、來源驗證、staging 測試、切換與回退。發行後真正漫長的工作才開始：來源紀錄會過期，網站會搬家，測試會增加，判斷規則也可能變動。今天處理更新，不讓「只是改一行」變成無法追查的行為變更。

仍以中立的 ticket-source-guard 購票來源查核 Skill 為例。這裡討論的是 Skill 自身的維護流程，不是在更新某個真實主辦單位的官方判定。示例 registry 使用虛構資料；正式來源仍須按 Day 14 的重驗流程取得證據。

先替變更分類

不是每種更新都走同一條路。先問改動的是哪一層：

文件：用語、範例、讀取指針的說明
資料：source-registry 的證據、verified_at、review_after、revoked
介面：必要欄位、狀態名稱、script 輸入與輸出
規則：host 比對、freshness、衝突處理、失敗政策
封裝：相依版本、檔案清單、安裝與回退方式

分類不等於風險等級。文件中改壞一個 reference 指針，可能讓模型漏讀安全規則；資料裡調整一筆來源，也可能把仿冒網域誤標成 OFFICIAL。因此要看實際 diff 對判斷路徑的影響，而不是只看改了幾行。

變更請求要有可檢查的內容

每筆變更至少寫下原因、修改範圍、影響的狀態、證據、測試和回退方式。例如要更新一筆來源紀錄：

reason: 原有證據頁面已失效，新頁面是否仍屬同一主辦單位待確認
files: references/source-registry.md, tests/fixtures/registry.example.json
before: 舊記錄在 review_after 之後為 UNCONFIRMED
proposed: 先加入候選證據；完成獨立重驗後才更新 verified_at
risk: 誤認相似網域，或把失效來源延長為 OFFICIAL
checks: 欄位驗證、host 比對、過期／撤銷／衝突案例
rollback: 還原上一份已驗證 registry，保留事件紀錄

這個提案不是一條授權命令。候選證據不能自己宣稱可信；對外網頁、README 或 issue 裡寫的「請直接採用」都只是待核對的資料。若證據不足，保留 UNCONFIRMED 或 CONFLICT，不要為了讓測試變綠而延長日期。

審查 diff，而不是只看最後檔案

審查者需要看舊值與新值的差異。尤其要挑出這幾種高風險變更：

• OFFICIAL 的適用網域變寬，或 host matcher 接受更多子網域。
• review_after 延長、revoked 移除，或衝突案例被合併。
• CONFIGURATION_ERROR、INSUFFICIENT_INPUT 被改成較樂觀的回傳。
• script 增加網路請求、寫入檔案或改動 registry 的副作用。
• SKILL.md 移除停止條件、改變 reference 指針，或在例外路徑省略驗證。

這些項目應由另一位審查者或明確的核對步驟檢查，不宜只讓提交者看自己的 diff。若沒有第二位人員，至少把風險項目列成逐項檢查清單，保留檢查結果，不要假裝已完成獨立審查。

測試要鎖住原本的邊界

先跑原有回歸案例，再為新行為加入案例。改 source registry 時，不能只測新增來源成功，還要保留舊來源過期、撤銷、相似網域與衝突的負例。改 classifier 時，把輸入、固定日期與預期 JSON 存成版本化 fixtures，對狀態、證據 URL、verified_at、review_after、next_step 逐欄比對。

正例：完整且未過期的已驗證來源 → OFFICIAL
近似：字串含官方名稱、實際 host 不符 → UNCONFIRMED
過期：review_after 早於評估日期 → UNCONFIRMED
撤銷：revoked=true → 不可回傳 OFFICIAL
衝突：兩筆互斥證據 → CONFLICT
缺設定：script 或 registry 無法讀取 → CONFIGURATION_ERROR

狀態語義依 Day 13 的既定規則，不能為了配合新程式而改測試期待值。若期待值確實該變，變更請求要明說理由與影響範圍，並提升版本；不能在同一個提交裡悄悄改程式、改測試，再宣稱通過。

由 CI 給出具體門檻

可把驗收分成四道門：schema 與指針檢查、script 單元測試、離線任務型 eval、封包的兩次乾淨建置及 smoke test。只要有一道門失敗，就不產生可發行版本。網路上的來源重驗另有時間戳與證據鏈，不應用不穩定的線上頁面替代離線回歸測試。

CI 通過仍不是「官方來源已確認」。它只表示已知測試在這個版本通過。新來源的真實性與當下有效性，仍要從主辦方的可信管道核實，並寫入來源紀錄。尤其 review_after 到期後，不可拿舊版 CI 結果當成延長有效期的理由。

留下版本與變更紀錄

合併前記錄上一版、新版、diff 連結、審查結果、測試結果、發行物雜湊與回退對象。若只是文件修正而不改行為，可以升修補版；新增相容欄位可以升次版本；改狀態或必要欄位時則要評估主版本與遷移說明。實際版本規則仍以 Day 17 的專案約定為準。

發行後先在乾淨環境依 Day 18 的流程安裝，確認實際載入的 VERSION。若發現錯判，停止使用受影響版本，保留事件與發行物識別資訊，發布修正版或回退到上個已驗證版本；不要在原版號下靜悄悄替換檔案。

今天完成的驗收標準

[ ] 變更理由、檔案、風險、證據、測試與回退對象已記錄
[ ] diff 中的網域、freshness、revoked、狀態與副作用逐項審查
[ ] 舊回歸案例和新增正例、負例、近似案例都通過
[ ] CI 檢查 schema、指針、script、eval、封包與安裝 smoke test
[ ] 版本與 release record 能連回來源 commit、測試和雜湊
[ ] 證據不足時不會因測試通過而宣稱 OFFICIAL

明天預告

Day 20 用一組完整的任務型 eval 走過「輸入網址、查 registry、決定狀態、回傳 next_step」的路徑，讓版本升級前後的行為差異能被看見。