Day 25 整理了公開資訊與回報入口。今天把回報接到維護流程：收到一份 PR，不是測試全綠就能合併。還要知道它改了哪個承諾、誰有權確認來源，以及文件是否跟著更新。

以下延續 ticket-source-guard 的教學設計，不表示已經建立正式 repository、維護團隊或實際合併流程。

先分清楚修改的種類

相同的程式碼行數，可能有完全不同的風險。修錯字、改狀態契約、替 registry 新增來源，不應使用同一份驗收清單。

修改種類       最小證據
文件修正       指向同版程式與契約，不擴大能力宣稱
分類器修正     原本失敗的 fixture、修正後結果、既有回歸結果
狀態契約變更   新舊輸出差異、使用者影響、遷移與回退方式
registry 更新  來源證據、範圍、有效日期、審核角色

這是本範例的建議規則，不是 Agent Skills 格式規格強制要求的流程。規格定義檔案與結構；專案仍要自己定義變更責任。

registry 的修改不是一般資料輸入

如果 registry 會影響「已登錄來源」的判斷，它就是決策資料。貢獻者可以提出候選項目，但不能靠一句「這是官方網站」直接取得可信狀態。

候選更新
→ 附可檢查的來源與範圍
→ 確認 host 邊界、日期與撤銷條件
→ 由指定角色審核
→ 重跑相關 fixture
→ 留下版本與審核紀錄

角色名稱要對應實際的人與權限，不要寫「安全團隊審核」卻沒有這個團隊。審核者也不能只看網域名稱；要確認證據支持的是哪個活動、哪段時間、哪種用途。

PR 要回答的是行為，不只是檔案

GitHub 的 PR 模板可以把必要問題放在提交入口。模板不會替維護者判斷，也不代表填滿欄位就可以合併。

這次改了哪個契約或風險？
最小失敗輸入是什麼？
修正前後的狀態有何不同？
在哪個 commit、環境與 eval 版本驗證？
哪些部分尚未驗證？
需要更新 README、CHANGELOG 或 registry 嗎？

不要求貼整份私人對話、token 或 cookie。可用合成 fixture 重現，就提交最小案例；不能公開的來源，先走實際可用的私人管道，不放進公開 PR。

文件也要能被驗收

CONTRIBUTING.md 應讓新貢獻者知道怎麼開始、要跑什麼、哪些變更需先討論。GitHub 支援把貢獻指南放在根目錄、docs 或 .github，並在 issue 與 PR 入口顯示連結。

但「有這個檔案」不等於流程有效。安裝命令、fixture 路徑與測試名稱都可能過期。每次改動這些介面，要核對指南的步驟；示範命令要能對應同版內容，不把尚未存在的工具寫成可執行命令。

把責任交接留下來

維護者離開、來源過期、測試環境停用，都可能讓原本的流程失去依據。先留下可檢查的交接表，而不是承諾永遠有人處理。

項目：registry 的 freshness policy
負責角色：實際指定的維護者
檢查依據：規格版本與相關 fixture
觸發重驗：到期、來源變更、撤銷或衝突
無人處理時：維持 UNCONFIRMED，不自動延長有效期

這裡的 UNCONFIRMED 是本教學範例的狀態，不是通用標準。重點是失去維護能力時不要默默沿用可信結果。

今天完成的驗收標準

[ ] 不同修改種類有不同證據要求
[ ] registry 更新保留來源、範圍、日期與審核紀錄
[ ] PR 說明行為差異與未驗證部分
[ ] 貢獻指南的路徑與命令對應同版內容
[ ] 無人維護時有明確、保守的退回狀態

參考資料
https://agentskills.io/specification
https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors
https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/about-issue-and-pull-request-templates

明天預告

Day 27 處理證據到期與外部依賴變更：什麼時候重驗、如何留下版本差異，以及何時停止宣稱相容。