昨日回顧

Day 24 把發行包、文件與驗證證據綁在一起。今天準備讓外部讀者找到專案，並且在有問題時能有效回報。先把產品與證據做完整，再考慮宣傳；索引、目錄或 awesome list 都不是安全認證。

本文只是對外資訊與回報流程的設計，不表示已向任何維護者投稿、聯絡或取得收錄。

先做一張不誇大的公開資訊卡

名稱：ticket-source-guard（教學範例）
任務：依 registry 證據與日期分類購票 URL
版本：對應已驗證的 release / commit
驗證：script、任務路徑與最終輸出的測試範圍
限制：不驗證票券真偽、不授權交易、不付款
入口：README、安裝說明、契約、問題回報

把「支援」拆成具體層級：格式檢查、檔案引用、script 執行、原生 agent 執行、端到端任務。哪一層真的做過，就說哪一層；未做過的不要藏在相容性標章後面。

索引前先讀該索引的規則

不同目錄可能要求授權、README、版本、demo 或一定的 repository 結構。先讀當前 contribution guide 與 issue/PR 模板，再準備符合範圍的資料。不要因為看到別人被收錄，就猜自己的專案也符合。

投稿前檢查
- 目前接受什麼類型的專案？
- 要用 issue、PR、表單，還是其他路徑？
- 有沒有禁止推廣或重複提交？
- 哪些欄位需要事實證據？

這一步是研究與準備，不等於允許自動代表作者發送。對外投稿會讓別人收到訊息、形成公開紀錄；內容與收件對象應由作者確認。

回報入口比漂亮宣傳更重要

GitHub 支援 issue 模板與表單，也支援 PR 模板。模板可以讓回報包含必要欄位，但不能代替維護者判斷。

錯誤回報
Skill 版本 / commit：
執行環境與依賴版本：
最小輸入（不可貼 token、cookie 或私人原文）：
預期狀態與契約依據：
實際狀態與錯誤訊息：
能否用合成 fixture 重現：

不要要求使用者上傳完整聊天、所有工具紀錄或私人 registry。報告缺資訊時先要求最小補充，而不是把存取範圍越擴越大。

把回報變成可驗證的修正

回報
→ 確認版本與最小重現
→ 新增失敗 fixture
→ 連到變更請求
→ 修正 script / Skill 路徑
→ 重跑舊案例與新案例
→ 更新 CHANGELOG 與發行版本

若無法重現，標成待釐清，不要說已修好。若來源證據已過期，應更新來源判斷，不一定是程式 bug；若實際行為符合契約但使用者預期不同，先檢查 README 是否讓人誤解。

安全問題要有不同的入口

公開 issue 不適合直接貼可利用細節、秘密或私人資料。專案應清楚寫出可用的安全回報方式、需要的最小資訊與處理界線。沒有實際可用的私人回報管道，就不要在文件中承諾已有保密流程或固定回應時間。

不要把維護者回覆當成背書

被索引、收到建議或取得一個 issue 回覆，只代表那個互動本身。不能改寫成「官方認證」「全面相容」或「安全保證」。真正的相容性主張仍要附環境、版本與測試範圍。

這也是工程文件和宣傳的分界：我們可以清楚說明已完成什麼，但不替未驗證的部分加上看起來可信的標籤。

今天完成的驗收標準

[ ] 公開資訊卡區分已驗證與未驗證範圍
[ ] 索引規則與投稿方式已讀，不擅自發送
[ ] 回報模板要求最小資訊，不收秘密或私人原文
[ ] 每次修正能追到 fixture、變更請求與發行紀錄
[ ] 安全回報管道與承諾符合實際能力
[ ] 收錄或回覆不被寫成認證或保證

參考資料
https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-readmes
https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/about-issue-and-pull-request-templates

明天預告

Day 26 定義維護與貢獻的邊界：哪些修改需要新測試、誰能改來源 registry，以及如何避免貢獻指南成為另一份失效文件。