證據合約 (Evidence Contract)
建立可測試、且紮根於實際儲存庫的計劃，而非看似合理的猜測。
觸發條件
當任務需要非瑣碎的實作計劃或計劃審閱時，自動套用此技能。無需等待使用者明確喚起。
對於目標、行為與驗證方式已十分明顯的瑣碎變更，則跳過完整合約，直接陳述簡單的檢查方式。
此技能僅用於規劃。除非使用者同時要求執行計劃，否則請勿編輯實作檔案。
工作流程
1. 確認意圖與成功標準
用一句話重述預期的成果。從請求中提取具體的驗收行為。若措辭模稜兩可，應先調查儲存庫，再詢問使用者。僅在調查後仍存在實質不同的結果時，才向使用者提問。
2. 收集最低限度的足夠證據
在提出架構或命名受影響檔案之前：
- 若存在
PROJECT_CONTEXT.md，則先閱讀該檔案。 - 透過有目標的搜尋，定位功能進入點。
- 閱讀最小量的相關實作、設定與測試檔案。
- 追蹤重要的呼叫者、依賴關係、持久化邊界與公開介面。
- 記錄文件與程式碼之間的矛盾。將程式碼與可執行行為視為更強力的證據。
當有目標的證據已足夠時，避免進行廣泛的儲存庫掃描。
3. 為每個重要主張進行分類
內部使用下列標籤，並在必要時揭露：
- 已觀察 (Observed)：直接由某個檔案、符號、命令結果、測試或執行時期觀測支持。
- 推論 (Inferred)：由已觀察到的證據強烈暗示，但未直接證明。
- 未知 (Unknown)：尚未確立的重要資訊。
切勿將推論或未知的主張當作事實呈現。對於重要的已觀察主張，應附上程式碼位置或工具觀測結果。不要憑空捏造檔案路徑、API、依賴關係或既有行為。
4. 解決阻礙性的未知事項
調查可能影響架構、範圍、資料流程、相容性或驗收行為的未知事項。若某項未知無法在本地端解決，則：
- 明確陳述之，
- 說明其重要性，
- 提出最安全的有限假設，且
- 僅在若繼續前進可能導致錯誤結果時，才詢問使用者。
5. 產出以證據為門檻的計劃
每個非瑣碎的計劃項目必須包含：
- 變更：最小的連貫實作步驟。
- 證據：證明該步驟合理的觀察到儲存庫事實，並附上相關路徑或符號。
- 受影響範圍：可能變更的檔案、介面、資料、呼叫者、依賴關係或工作流程。
- 成功檢查：可執行的測試、建置、lint、執行時期或驗收觀測。
- 風險或假設：僅在重大時加入，並標註為推論或未知。
偏好一個需求對應一個可觀察檢查的計劃。對於錯誤修復與相容性敏感的變更，應包含迴歸測試覆蓋。
6. 執行計劃閘門
在呈現計劃之前，請驗證：
- 每個要求的成果至少對應一個計劃項目。
- 每個計劃項目都有證據與具體的成功檢查。
- 命名的檔案與符號是觀察到的，而非猜測的。
- 重大的假設是可見且已分類的。
- 依賴關係與整合邊界已涵蓋。
- 計劃採用了能滿足請求的最小變更。
- 未加入任何推測性的功能或無關的重構。
若閘門檢查失敗，請先調查或修訂計劃，再回傳。
輸出格式
除非任務複雜，否則保持結果簡潔。
## 證據合約
- 已觀察: `path/to/file` 確立了 ...
- 推論: ... 因為 ...
- 未知: ...；有限假設或需要的決策 ...
## 計劃
1. **變更** ...
- 證據: ...
- 受影響: ...
- 驗證: ...
- 風險/假設: ...
## 完成閘門
- [ ] 需求到檢查的對應完整
- [ ] 無未標註的假設殘留
- [ ] 驗收檢查是可執行的
省略空的推論或未知章節。對於小型計劃，可將每個項目壓縮為一行，同時保留證據與驗證資訊。
不良模式
請勿：
- 僅從檔案名稱推測計劃，
- 使用「可能」、「大概」或「應該」而不標註為推論，
- 未執行測試就聲稱測試通過，
- 以模擬檢查取代可用的真實驗收路徑，
- 用可從儲存庫回答的問題來困擾使用者，
- 對瑣碎變更將合約變成文書作業，
- 僅因計劃完成就開始實作。