Plan Arbiter
將競爭的計畫轉化為一個可執行的方向。保留最佳構想，拒絕薄弱假設，產出清晰的交接訊息，而非模糊的混合物。
工作流程
- 收集來源計畫。
- 將每個標準化為可比較的主張。
- 進行交叉審查，比對各計畫以及真實的程式碼庫或任務上下文。
- 選擇勝出者、合併出更好的混合方案，或將計畫退回修訂。
- 產出一個帶有驗證關卡和已拒絕替代方案的執行交接訊息。
規劃為唯讀操作，除非使用者明確要求你在決策後執行。
收集來源計畫
接受以貼上文字、本機檔案、Session ID、對話記錄路徑、PR、評論、視覺化計畫連結或聊天歷史等形式提供的計畫。盡可能解析原始工件，以便查看提示變更和假設，這些資訊可能從最終摘要中遺漏。
如果計畫仍在撰寫中且使用者要求你等待，請監控直到計畫完成或被阻擋。如果無法解析計畫，請繼續使用可用的計畫文字，並將缺失的來源標記為風險。
標準化
針對每個計畫，提取：
- 目標和範圍。
- 關鍵假設和未解決的問題。
- 提議的檔案、模組、API、資料形狀、UI 狀態或工作流程。
- 實作順序。
- 驗證策略。
- 回滾或遷移考量。
- 成本、複雜度和預期的執行者適合度。
不要獎勵冗長。偏好具體、基於真實程式碼且誠實面對取捨的計畫。
交叉審查
假設每個計畫是由另一個能幹的代理撰寫，對其進行審查：
- 檢查它是否滿足使用者的實際請求。
- 根據儲存庫、文件、測試、截圖或外部系統驗證相關且可用的主張。
- 識別隱藏的依賴關係、遺漏的測試、有風險的順序、模糊的步驟、不必要的範圍以及難以逆轉的決策。
- 注意互補優勢：一個計畫可能擁有更好的架構，而另一個則有更好的遷移或驗證路徑。
- 區分計畫品質與執行者偏好。當品質可接受時，成本更低/速度更快的執行者可能是實作的合適選擇。
當計畫規模龐大、程式碼庫廣泛，或決策需要獨立的技術和產品審查時，可使用子代理進行獨立審查。
決策
選擇以下三種結果之一：
- 採用： 大致按原樣採納一個計畫。
- 混合： 將特定部分組合成一個更強的執行計畫。
- 優先修訂： 要求進行另一次規劃，因為兩個計畫都遺漏了關鍵限制條件或依賴於未解決的決策。
使用以下優先順序進行決策：
- 正確性以及是否符合使用者的請求。
- 與真實檔案、API、測試、資料和 UI 行為的結合度。
- 不阻礙預期未來的更簡單的首次實作。
- 更好的驗證和回滾方案。
- 品質可接受時較低的執行時間/代幣成本。
交接
產出一個精簡的決策備忘錄：
Decision
- 採用計畫 A / 混合 / 優先修訂。
Why
- 決定性證據和取捨。
Execution Plan
- 有序步驟，附帶需要觸及的檔案或表面。
Borrowed From Other Plans
- 從非勝出計畫中保留的有用部分。
Rejected
- 刻意不採用的想法，附帶原因。
Verification
- 需要的測試、瀏覽器檢查、截圖、CI、審查或部署檢查。
Executor Recommendation
- 哪個代理/模型應負責實作以及原因。
當使用者已經要求執行且選擇的路徑明確時，在簡短報告決策後繼續執行選定的計畫。否則，在交接處停止並請求批准。