Red Blue Review

---
name: red-blue-review
description: 中文紅藍對抗——對任何命題做對抗式壓力測試（挑戰假設、找邏輯弱點，非效能/負載壓測），找出弱點再強化。當使用者說「紅藍對抗」、「攻擊這個」、「找弱點」、「壓力測試」、「挑戰這個決策」、「這個決策/方案/設計會出什麼問題」、「幫我戳破」、「魔鬼代言人」、「對抗審查」、「盲點」、「挑毛病」、「站得住腳嗎」、「打臉這個提案」、「有什麼沒想到的風險」、「反方論點」、「red team」、「red-team」、「stress test」、「pressure test」、「poke holes」、「devil's advocate」時觸發。適用決策/架構/計畫/策略/投資/安全/程式碼/plugin 配置/文件等多面向。Red 攻、Blue 守、修，**持續迴圈直到紅方攻不出新弱點**（預設實作模式自動修；分析模式首輪攻守後給確認清單再修）。（純漏洞掃描用 security-review、純程式碼規範審查用 code-reviewer；本 skill 是對抗式論證，非漏洞掃描器。）
---

# red-blue-review — 中文紅藍對抗

> 在現實攻擊你之前，先自己把弱點攻出來。

對任何命題（決策、架構、計畫、策略、程式碼、plugin/skill 配置、文件…）做**對抗式壓力測試**：紅方用「最強化」的攻擊找弱點，藍方防禦/強化，循環到收斂，產出一個經得起攻擊的強化版 + go/no-go 建議。

## 何時用 / 何時不用

**該用**：高風險決策、架構/策略定案前、計畫審查、發布前審核、安全姿態、投資評估、**plugin/skill/agent 配置稽核**、文件與實況一致性。

**不該用**（反模式）：低風險瑣事（直接做就好）、緊急救火（先滅火再復盤）、已定案無法回頭（對抗只會製造衝突）、想法還在成形期（過早攻擊）、走形式的「確認劇場」（沒有真心對抗就別做）。

> ⚠️ **觸發後先判斷輕重（防誤觸發成重型流程）**：本 skill 的觸發詞很廣（「找弱點」「壓力測試」「盲點」「有什麼風險」…），這些詞在日常輕量提問中也常出現。**若使用者像是隨口問「這段有沒有問題 / 有什麼風險」而非要求正式對抗審查**，別直接進「建 TaskList + 多輪迴圈」的重型流程——先用一句話確認：「你要的是快速看一眼給意見，還是完整的紅藍對抗（多輪攻守、會建追蹤清單）？」。使用者要輕量就輕量答，明確要對抗才進完整流程。這一步是防「把隨口一問放大成多輪燒 token」。（「壓力測試」在中文也常指效能/負載壓測——本 skill 不做那個，遇到時確認清楚。）

**分工讓位**：本 skill 做的是對抗式壓力測試（找最強攻擊 → 強化），不取代一般 code-review（風格/規範）與 git-commit 內建審查。純依專案架構/資安規範逐條審查程式碼（DDD/CQRS、AI 痕跡、CS1591 等）→ 用 code-reviewer；純掃 PR 安全漏洞 → 用 security-review；要對抗式找弱點、戳破假設才用本 skill。code 面向若使用者意圖偏向逐項漏洞掃描而非思辨對抗，先反問一句確認再決定是否轉介。

## ⛔ Quota 節流（MANDATORY，hook 強制）——啟動任何多 agent 對抗前先讀

**鐵則：平行可以，但必須「分波派發＋撞牆熔斷＋resume 不重灑」。** 完整規則與 `runWaves` 骨架見 `references/quota-throttling.md`。

- 多 agent fan-out 一律經 `runWaves()` 分波（每波併發 ≤ 6，重型讀碼/審查 agent ≤ 4）——任何時刻在飛的 token 曝險 ≤ 一波。
- **熔斷**：任一 agent 因 quota / API 終止（回 `null`）→ 立即停止派下一波、保留已完成結果、回報使用者。禁止自動重試。
- **Resume 不重灑**：quota 恢復後以 `resumeFromRunId` 續跑——已完成走 cache，未完成仍分波，最多再曝險一波、不會二次全滅。
- 大艦隊（>15 agents 或估算 >1M tokens）啟動前先報預算給使用者同意。
- plugin 附 PreToolUse hook（`hooks/quota-guard.js`）：Workflow script 用 `parallel()`/`pipeline()` 包 `agent()` 而**沒有** `runWaves(` 時攔下；例外整批派須使用者同意後於 script 首行加 `// quota-user-approved:`（未經同意禁止自行加）。
- 事故背景：曾兩次把整支艦隊一次灑出（5 紅攻＋30+ 藍驗同飛）→ 撞 5h quota 全滅 → reset 後 resume 又整隊灑 → 再撞。根因是無界派發與不熔斷，不是平行本身。

## 第一步：確認對抗標的與面向

問使用者（或從上下文判斷）：

1. **標的**：要對抗什麼？（一段程式碼 / 一個架構決策 / 一份計畫 / 一個 plugin 配置…）
2. **面向 type**（決定攻擊角度，可多選）：

| type | 用在 | 預設攻擊面向 |
|------|------|------|
| `decision` | 決策審查 | 假設、替代方案、可逆性、後果、時機 |
| `architecture` | 架構強化 | 擴展性、安全、依賴、維運、邊界案例 |
| `plan` | 計畫審查 | 可行性、資源、時程、依賴、風險 |
| `strategy` | 策略驗證 | 競爭、市場、執行、依賴、時程 |
| `investment` | 投資評估 | 經濟、市場、執行、競爭、假設 |
| `security` | 安全姿態 | 攻擊面、漏洞、依賴、維運 |
| `code` | 程式碼審核 | 崩潰、注入/資安、邏輯錯誤、邊界、跨平台、錯誤處理 |
| `config` | plugin/skill/agent 配置稽核 | 觸發詞衝突、權限過寬、路徑逃逸、敏感外洩、與實況不符 |
| `docs` | 文件一致性 | 文件聲稱 vs 實際、殘留過時、版號/清單不符、斷鏈 |

> 上表為常見起點，非窮舉；流程/用人/產品/合規等其他命題，可挑最接近的 type 並自由借用通用面向（attack-catalog 的 ASSUMPTIONS/DEPENDENCIES/ORGANIZATIONAL/TEMPORAL/SECOND_ORDER/FALSIFIABILITY 對任何命題皆適用）。

3. **模式**：

   - **實作模式（預設）**：紅攻 → 藍守 → **修** → **持續迴圈**，直到某輪紅方攻不出新的真弱點才停（見第四步收斂）。全自動、中途不停——**唯一例外**：修改涉及**高風險（刪檔 / 跨 repo / 改設定檔 / 不可逆操作）**時，停下來先問使用者，其餘自動修。拿不準算不算高風險時，傾向停下問（偏安全）。限 `code`/`config`/`docs`（有實檔可改的）面向。標的大可接 Workflow spawn 獨立 agent，小標的對話內跑——**兩者皆受頂部「Quota 節流」約束（序列優先，併發須使用者同意）**。
     - **首次動手改檔前，先講一句告知**：「本次為實作模式，會在收斂過程中自動修改檔案（高風險改動仍會停下問你）」——讓使用者知道即將自動改檔，不是靜默動手。這是告知、不是等回覆，講完就繼續。
   - **分析模式**：紅攻 → 藍守後**停，給使用者確認清單**；使用者確認後才修，然後**一樣持續迴圈**到紅方攻不出新弱點。**但後續迴圈的修正範圍鎖定在第一輪使用者確認的範圍內**——「範圍」= 第一輪確認清單所涉及的**檔案集 + 底層顧慮集**；後續迴圈新冒出的弱點若其修正會動到清單外的檔、或屬於清單外的新顧慮，就算超出 → **先提醒使用者**、不擅自擴大。適用 decision/architecture/plan/strategy/investment 等沒有單一實檔可改、需人拍板的命題；也可用在使用者只要報告不要自動修的 code/config/docs。
   - **怎麼選**：面向是 code/config/docs 且要實際修 → 實作模式（預設）。要先看清單人工把關、或命題沒實檔可改 → 分析模式。意圖不明且面向可改 → 走實作模式（預設）；高風險改檔時自會停下問。

4. **收斂準則**：兩模式**都迴圈到「某輪紅方 0 個新的真弱點」才停**（唯一輪 0 新即收斂）。詳見 `references/convergence.md`。

## 第二步：Red 攻擊（steel-manning，要攻得最強）

依面向從**攻擊向量目錄**（`references/attack-catalog.md`）選類別，每個攻擊用**三遍強化**確保是最強版、不是稻草人：

- **遍 1**：基本攻擊「會失敗因為 X 當 Y 觸發」
- **遍 2**：強化——加具體細節、因果機制、證據/前例、影響範圍、機率（base rate）
- **遍 3**：最強版——真正的對手（競爭者/批評者/攻擊者）會不會覺得這攻擊強？不會就再強化

每個攻擊標**嚴重度**：

| 嚴重度 | 準則 |
|------|------|
| CRITICAL | 承重（命題成敗繫於此）且信心 < 50% |
| HIGH | 承重 或 信心 < 50% |
| MEDIUM | 影響效率 / 體驗 / 可維護性，但命題仍可行 |
| LOW | **為真但拿掉它，命題的可行性 / 正確性 / 安全性都不變**——純可有可無的潤飾 |

> 由高至低依序套用，命中即定級（先測 CRITICAL，不符再測 HIGH…）；CRITICAL/HIGH 重疊區取較嚴重者。

**LOW vs MEDIUM 邊界（機械閘命門，務必照對照表判，別憑感覺）**：LOW 與 MEDIUM 的分界直接決定迴圈跑幾輪（見第四步：只有 ≥MEDIUM 真弱點才計入「新弱點」、才驅動下一輪）。判準一句話：**「拿掉這個 finding，命題還站得住嗎？站得住 = LOW。」** 為消除詮釋空間，用對照表錨死（仿 git-commit 豁免規則的手法）：

| 判 LOW（不計入迴圈、只記錄，第五步列給使用者） | 判 MEDIUM 起（計入迴圈、會修） |
|---|---|
| 變數 / 命名可更清楚 | 影響效率但功能仍可行 |
| 可選的效能微優化 | 邊界情況處理不全 |
| 措辭 / 註解風格偏好 | 可維護性實質下降 |
| 「未來也許要考慮」的純推測 | 真實會觸發的錯誤路徑 |

> ⚠️ 此定義仍有殘縫：「站不站得住」終究是判斷。對照表是把抽象定義錨死的手段，遇到模糊案例**靠表上最接近的列歸類**，不要自己另立標準——拿不準時偏向 LOW（寧可少修，不要為了續圈硬升級）。

**關鍵紀律（本專案實戰經驗）**：攻擊要有**證據**，假攻擊（false finding）扣分，寧可少報不要報假的。但「證據」依面向有兩套標準，別把 code 標準誤套到非技術命題：

- **實作面向（code/config/docs）**：攻擊要可重現/附 PoC，理論性的零分。
- **論證面向（decision/architecture/plan/strategy/investment）**：攻擊須附**外部錨點**（base rate / 前例 / 因果機制，見 attack-catalog 假設段與 COMPETITIVE 段範例），可以是對未來/市場/人性的推測，但禁止的是「無錨點的空泛質疑」而非「不可重現的推測」。

## 第三步：Blue 防禦（四類回應，要守得實在）

每個攻擊用決策樹分類回應，**不可打哈哈、不可否認式防禦**：

```
攻擊事實錯了？ → REFUTE（用證據駁斥）
攻擊有效？
  能改命題消除它？ → HARDEN（強化命題）
  能降低風險？     → MITIGATE（緩解：應變/監控/風險轉移/分階段/kill switch）
  都不行？         → ACCEPT（誠實記錄殘餘風險，不假裝沒事）
```

**獨立驗證防假陽性**：藍方對每個紅方 finding 都要**獨立驗證真偽**，不直接相信紅方——這是過濾 false finding 的關鍵。依模式採對應手段：

- **實作模式（code/config/docs）**：獨立**讀實際檔案/重現**比對 ground truth。
- **分析模式（decision/architecture/plan/strategy/investment）**：獨立**事實核查/反論證**——檢查紅方攻擊本身的事實前提是否成立、base rate / 引用數據是否正確、是否為稻草人或過度外推；用此判定真偽，而非「有沒有檔案可讀」。

此驗證在實作模式（spawn 獨立 agent）下最有效；對話內單實例自我紅藍時是較弱的近似（見「重要限制」）。

**「不信自述、驗產出」是雙向鐵則**：本步是藍方不信紅方（驗 finding 真偽）；反方向同樣成立——**修方/藍方宣稱的產出（「已修好」、REFUTE 附的證據）一律不可採信自述**，由第四步「修復複驗」強制驗收。任何一方「說做了」都不等於「做了」，真偽只認 ground truth（實檔/來源），不認對話裡的宣稱。

## 第四步：收斂（迴圈到攻不破）

**核心收斂條件（兩模式共用）**：紅攻 → 藍守 →（修）→ 再跑一輪紅攻……**直到某一輪紅方 0 個新的真弱點**才停。「新的真弱點」= 藍方驗證為真（非假陽性）、且去重後非變體的攻擊。一輪 0 新即收斂。

- **實作模式**：每輪修完立刻再攻，自動迴圈到 0 新（高風險改檔才停下問使用者）。
- **分析模式**：第一輪攻守後停給確認清單；確認後修，再自動迴圈到 0 新，但修正鎖第一輪範圍（超出先提醒）。

**修正門檻（防紅方鑽牛角尖）**：只有藍方確認為真**且嚴重度 ≥ MEDIUM** 的弱點才修；**LOW 一律只記錄、不修**（即使為真）。對應地，迴圈的「新真弱點」只算 ≥ MEDIUM 的——某輪只冒出 LOW、或全是 LOW，視同 0 新、收斂。這道門檻斷掉「為了讓迴圈繼續而硬找 LOW 級雞毛蒜皮」的誘因；LOW 全列在第五步報告供使用者參考，要不要修由使用者決定。

**修復複驗（MANDATORY，防「宣稱修好其實沒修」）**：每輪修完、宣告該輪結束前，對「本輪宣稱已修」的每個 finding **複驗產出——禁止採信「我修好了」的自述**（實戰多次被「宣稱完成但實際沒落地」搞過）。逐項驗三件事：

1. **落地**：實讀改後檔案/diff，確認修改真的存在——不是看修方的回報文字。
2. **有效**：拿原攻擊的重現步驟/攻擊路徑對改後版本再打一次，確認打不穿。
3. **無副作用**：順看修改處有沒有引入新問題（並把「上輪修改處」列入下一輪紅攻必攻面）。
4. **衍生同步**：修的標的若存在同源多格式衍生檔（.md/.html/.pptx/.pdf…），逐份確認**全部重生成且含本次修正**——只補其中一份＝複驗不過（實案：紅隊修正只更新 HTML，Markdown 停舊版流通到被人抓到）。mtime 比對可快速找出停舊版的那份。

複驗手段依模式：實作模式 **spawn 獨立 fresh-context agent 複驗（修的人不得驗自己）**；對話內至少重新 Read 改後檔案逐項比對，不可憑記憶或對話中的修復敘述。**複驗不過 = 該 finding 未處理**：不得計入「已修」，且其 root_concern **必須從去重集合移除**——否則去重閘（閘3）會把下一輪紅方重提當「變體」吞掉，「沒修好」就此隱形（這正是本機制要堵的洞）；存在複驗不過項時，收斂判定不得放行。

**面向覆蓋閘**：宣告收斂前須先確認該 type 全部「預設攻擊面向」每項都至少認真攻過一輪——未涵蓋不得收斂，否則退化成只攻淺面向就停的「確認劇場」。

**硬上限**：迴圈受 round 上限保護（預設 5 輪）避免極端情況攻不完——到上限即強制停並回報殘餘弱點。其餘可調參數見 `references/convergence.md`。

**去重**：對「**所有已提出過的攻擊（含已被藍方剔除的假陽性）**」比，只看底層顧慮（root concern），與嚴重度/措辭無關；變體不算「新攻擊」。否則被剔除的假陽性會每輪重現、永不收斂。

## 第四步補：強制收斂追蹤（MANDATORY）—— 把迴圈狀態 externalize 到 TaskList

> **本段是收斂能不能被遵守的關鍵。** 收斂迴圈若只活在模型腦中（「我覺得攻夠了」），模型會在累的時候提早喊停——這是結構性弱點，不是某輪不認真。緩解方式：**把「跑到第幾輪、收斂了沒」externalize 成 harness 持有的 TaskList**，讓模型每一輪都被沒關的 task 盯著，降低遺忘與提早喊停。
>
> ⚠️ **保證等級要誠實**：對話內模式的這套追蹤是「**自律強化版**」，不是真機械閘。TaskList 的開關、`is_real`/`corrected_severity` 的賦值全由**同一個模型**自己填、自己判——沒有外部腳本在旁攔截。這與 git-commit 的關鍵差異在於：git-commit 的 BLOCK 由 **hook/腳本外部強制**（模型無法繞過），而這裡沒有等價的外部攔截點。**真機械閘只存在於接 Workflow 跑的路徑**（`references/loop-runner.md` 的 JS `filter` 是真的程式在算）。所以：**高風險命題，優先走 Workflow 路徑**（見 README「接 Workflow」段），別倚賴對話內追蹤當硬保證。

**對話內跑紅藍對抗時，開跑前必須先 `TaskCreate` 建立追蹤清單，不可跳過**（接 Workflow 跑時，迴圈由 `references/loop-runner.md` 的腳本控制流強制，本 TaskList 紀律是對話內的等價物）。

初始任務（每輪紅藍 = 兩個 task，外加一個收斂判定 task）：

```
#1 R1 紅攻（steel-manning，覆蓋本 type 預設攻擊面向）   [in_progress]
#2 R1 藍驗 + 修 + 修復複驗（逐 finding 獨立驗證 is_real → ≥MEDIUM 才修 → 實讀改後檔複驗落地/有效）  [pending]
#3 收斂判定（數本輪新真弱點 → 0 新、過覆蓋閘、無複驗不過項才收斂）  [pending]
```

**執行規則（不可違反）：**

- **每輪開始**把該輪 `紅攻` task 標 `in_progress`；該輪攻、守、修、**修復複驗**全部完成，才把 `紅攻`/`藍驗+修+複驗` 標 `completed`——**修完但沒複驗，task 不得關**。
- **收斂判定 task（#3）只有在「最近 `dry_rounds` 輪皆 0 新 ≥MEDIUM 真弱點」、覆蓋閘已過、**且**所有已修 finding 皆通過修復複驗時，才准標 `completed`。** 否則**必須** `TaskCreate` 新一輪（`#4 R2 紅攻`、`#5 R2 藍驗+修`），把 #3 退回 `pending`，繼續迴圈。
- **#3 還 pending（= 尚未確認收斂）時，禁止輸出第五步 GO / 產出**——比照 git-commit「任一軌 BLOCK 絕不自動 commit」。模型不得在收斂 task 未關時宣告完成。
- **達 `round_cap`（預設 5）強制停**：把 #3 標 `completed` 並在產出註明「達 round_cap 強制停，殘餘弱點如下」。
- **「新真弱點」的計數規則**（見 `references/convergence.md`）：只數「藍方 `is_real:true` 且 `corrected_severity ≥ MEDIUM` 且去重後非變體」的 finding。`is_real:false`、LOW、變體**一律不計入** → 某輪只冒這些 = 0 新 = 該輪收斂。此規則讓「要不要再跑一輪」盡量由 finding 資料而非心情決定。**但注意（對話內模式）**：`is_real`/`corrected_severity` 由模型自填，模型若想收斂可把邊界 finding 自評成 LOW 來湊「0 新」——這是自律版的先天限制，Workflow 路徑的 JS filter 才是真的擋。故對話內模式請對「自己把 finding 降級」保持警覺，有疑慮時傾向保留為 ≥MEDIUM 再跑一輪。

**🧹 結束時 MANDATORY 清理**（同 git-commit 結尾）：收斂並產出第五步後，把所有 task 逐一 `TaskUpdate status=deleted` 清空，並在產出末尾確認「收斂追蹤清單已清空」。禁止留 `completed`/`in_progress` 殘條混入下次對抗。

## 第四步半：常識/第一性原理終檢（產出前必過，刻意不靠對抗）

收斂後、產出前，把**強化後命題**拉回現實掂量一遍——這道**不靠紅藍對抗**（對抗的集體盲點正是要補的對象），靠常識與第一性原理問：

- 這結論違反明顯常識嗎？（例：「延後建立 = 省成本」→ 其實是技術債利滾利；「小規模可不做、大了再補」→ 規模會長大、回溯成本爆炸）
- 有沒有把問題「標成 open question / 待議 / 建議性」其實是**卸責**？（方法論該給答案，不是把沒想清楚的丟給使用者）
- 「建議做 X」這種軟性規範，現實中會不會根本沒人執行？該硬性就別軟性。
- ground truth 裡被當「已知」的關鍵事實（尤其 X 等價/取代 Y），真的查證過嗎？沒查就回頭補驗。

任一項中招 → 結論不算數，回頭修命題再產出。**這是本專案實戰補上的一步：多次「對抗全綠但結論違反常識」，都在這關（或被人類）才攔下。**

## 第五步：產出

```
== 紅藍對抗結果 ==
標的：<...>  面向：<type>  輪數：N
攻擊覆蓋：<已攻 N/總 M 面向>（未攻：…）
- 確認的弱點（藍方驗證為真）：
    [CRITICAL] <...> → 處置：HARDEN/MITIGATE/ACCEPT
    [HIGH] ...
- 假陽性（藍方驗證為假，已剔除）：<...>
- 修復複驗：N/N 過（未過：<finding> → 已退回重修 / 達 round_cap 列為殘餘）
- 殘餘風險（ACCEPT 的）：<...>
- LOW 級（為真但 < MEDIUM，只記錄不修，供使用者參考）：<...>
強化後命題：<...>
建議：✅ GO（critical/high 已處理）/ ⚠️ BLOCK（尚有未解 critical/high）
       承重面向有「未攻到」時 → GO 須降級為「GO（覆蓋不全，N 面向未攻）」
```

## 實作模式（程式碼 / config / docs 面向）

當面向是 `code`/`config`/`docs` 且使用者要「實際修」而非只分析，可接 Workflow（本專案已驗證的紅藍對抗 pattern）：

- pipeline：每個標的 → 紅方稽核（找 finding）→ 藍方獨立驗證（讀實際檔案判真偽）
- **實作模式的藍方做真偽過濾（is_real）+ 順手校正紅方嚴重度（corrected_severity，紅方常高估），但不在 verdict 內做四類處置分類**；第三步的 REFUTE/HARDEN/MITIGATE/ACCEPT 與第五步的「處置 / 殘餘風險」，由主 Agent 在收斂階段對「確認為真」的 finding 收斂時補上（REFUTE = is_real:false 已剔除，其餘三類在修復決策時定）。下游收斂/產出計數優先採 corrected_severity，無則 fallback 紅方 severity。
- 確認為真的 finding → 修 → **修復複驗（獨立 agent 實讀改後檔案驗落地/有效，修的 agent 不得自驗；不過 → 退回重修，並把該 root_concern 移出去重集合）** → 可選 Codex 複審 → publish
- **單輪 pipeline 骨架**詳見 `references/workflow-pattern.md`（紅攻→藍驗的單次 fan-out）
- **要「迴圈到 0 新發現才收斂」**（loop-until-dry）詳見 `references/loop-runner.md`——含外層 `while (dry < dry_rounds)` 的完整可跨腳本，把「要不要再跑一輪」交給腳本的去重計數判定（機械閘驅動），而非模型自律。**這是收斂能真正做到而非被模型提早喊停的關鍵**；workflow-pattern 是它的單輪內核，loop-runner 是外層驅動器。
  - ⚠️ **接駁鍵 `root_concern`**：外層迴圈的去重靠 FINDING 的 `root_concern` 欄位。兩檔 schema 已同步含此欄（即插即用）；自訂 FINDING schema 餵進 loop-runner 時**務必保留 `root_concern`**，否則去重鍵為 `undefined` → 每輪都被當「無新弱點」→ 第一輪假收斂（病 A 以新形式復發）。

## 重要限制（誠實告知）
- **預設實作模式會自動改檔並迴圈到攻不破**；只有高風險改（刪檔/跨 repo/改設定）才停下問。不想自動修 → 明說走分析模式（首輪先給確認清單）。
- 分析模式確認後也會修並續迴圈，但**修正鎖第一輪確認範圍**，超出先提醒——避免自動迴圈擴張到你沒同意的改動。
- steel-manning 是為了**求真不是求贏**——攻擊強化到最強，藍方守住才證明真的穩。
- 嚴重度與 go/no-go 是**輔助判斷**，最終決策仍由使用者拍板。
- **對話內單實例自我紅藍時，藍方獨立性有限**（同一模型推理鏈，confirmation/anchoring 偏誤無法靠「叫自己當藍方」根除），防假陽性效果弱於實作模式 spawn 獨立 agent。高風險命題建議走實作模式（`references/workflow-pattern.md`）或請第二個實例/人複核。
- **🔴 對抗無法發現 ground truth 內的假前提**（本專案實戰最大教訓）：紅藍同拿一份 ground truth，若其中含假事實（尤其「X 等價 Y / X 可取代 Y」這類斷言），雙方都會引用它、裁判基於它定讞——**對抗機制反而精緻地論證一個錯誤結論，且因雙方都「言之有據」而更難察覺**。故 ground truth 的關鍵事實前提，動對抗前必須**獨立實讀來源驗證**（不可把「聽說等價」當已知餵進去）。曾連判兩次錯，皆因 ground truth 含未驗證的「X 可取代 Y」假設，最後靠人類一句常識戳破——對抗本身抓不到。
- **🟠 收斂≠結論正確：須過「常識/第一性原理終檢」**（見第五步前）。對抗只驗「有沒有人攻得破」，驗不出「這結論本身合不合常理」。一個全員沒攻破、但違反常識的結論（如「延後建立=省成本」其實是技術債利滾利、「列為 open question」其實是卸責、「建議性」規範其實沒人執行）照樣能收斂。產出前須把強化後命題拉回現實掂量一遍——這道刻意不靠對抗（對抗的集體盲點正是問題），靠常識。