adversarial-review

name	adversarial-review
description	多方抗辯——對重大結論/架構決策/bug根因判定/安全判斷，平行派出 skeptic、red-team、simplifier 三個反方子代理獨立審查，過半存活才採信。觸發詞：「抗辯」「adversarial review」「多方審查」「/adversarial-review」，或 FABLE-PROTOCOL 第 2 節規定的觸發時機（架構決策、根因判定、影響生產的結論）。不適用於：瑣碎修改、純問答。

多方抗辯流程（adversarial-review）

目的

防止「聽起來合理但其實是錯的」結論被採信。單一模型的自我檢查會系統性偏袒自己的結論，所以用三個獨立、不同鏡頭、預設立場為推翻的子代理交叉審。

執行步驟

1. 整理待審包：把待審結論寫成一段自足的陳述，包含：

   • 結論本身（一句話）
   • 依據的證據（file:line、測試輸出、量測值）
   • 影響範圍（改了什麼、誰依賴它）
   • 待審對象若是多條獨立發現（如審查報告的 N 條 findings）：逐條各自抗辯、不得打包成一個總結論——打包會稀釋每條的審查解析度。

2. 同一則訊息平行派出三個反方（必須用 Agent 工具、subagent_type 分別為 skeptic、red-team、simplifier，一次三發不得串行）。 委派抗辯三反方（skeptic/red-team/simplifier）一律明指 model: opus；唯一例外：主迴圈模型 ID 含 opus 或 fable 時可不指定 model（繼承主迴圈）；無法判斷主迴圈是誰→用 opus。（抗辯裁決由主迴圈自做，不受此限。）每個 agent 的 prompt = 待審包原文 + 該鏡頭的任務指示。逐條抗辯時每條發現固定耗 3 個子代理（三鏡頭），單輪平行子代理總數上限 6＝一輪最多 2 條發現；更多條就分批送審，批與批的結論分開回報、不合併。

3. 裁決（過半存活制）：

   • 3 票 SURVIVED → confirmed，可直接採信
   • 2 票 SURVIVED → confirmed，但必須把那 1 票 REFUTED 的理由列入風險清單回報用戶
   • ≤1 票 SURVIVED → 結論擋回，依 REFUTED 理由修正後重新送審

4. Loop-until-dry 與規模校準：影響生產/全域佈署/資料安全的重大結論——修正後重審，直到連續 2 輪無新 REFUTED 理由才收工；其餘結論一輪三鏡頭即收工。無法明確排除上述影響者，視同重大。每輪把「已審過的理由」附進 prompt 避免重複發現。

5. 回報格式（給用戶的最終訊息必含）：

   鏡頭	verdict	關鍵理由
   skeptic	...	...
   red-team	...	...
   simplifier	...	...

   加一行結論：抗辯結果：N/3 存活 → confirmed / 擋回（原因）。

禁止事項

• 不得因為趕時間跳過任何一個鏡頭。
• 不得把三個鏡頭合併成一個 agent 跑（獨立性是抗辯的前提）。
• REFUTED 理由不得默默吞掉，必須回報或修正。