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 又整隊灑 → 再撞。根因是無界派發與不熔斷，不是平行本身。

## 第一步：面向提案 → 使用者核可 → 才開打（MANDATORY）

> **為什麼有這步**：紅方若只拿「找 bug / 不一致」的通用指令，會挑最好證明的東西打——數字對不上、版號不符、極端情境下程式不匹配——而不是使用者真正在乎的問題（方向對不對、這設計划不划算、會不會沒人用）。紅方該攻什麼，**由使用者拍板，不由 type 表自動決定**。

**未經使用者核可面向提案，不得開始任何紅攻**（不論實作/分析模式、不論對話內或 Workflow）。唯一例外：使用者明說「直接跑 / 用你的判斷」——仍要列出提案，但列完即開打（見 1-3 末條）。實作模式的「全自動、中途不停」從核可（或上述例外的提案列出）之後才開始算。

### 1-1 先讀、再定題

- 讀標的本身，加上快速掃背景：專案 `CLAUDE.md`、memory、使用者提到或附上的檔案（找 2-3 份能讓攻擊落地的就好，不要全讀）。
- 寫出**定題**三行：
  1. **標的**：要對抗什麼（檔案 / 決策 / 計畫…）
  2. **要回答的問題**：這次對抗是為了做什麼決定（例：「這版能不能發」「該選 A 還是 B」「這設計值不值得繼續」）
  3. **利害**：判錯的代價是什麼——這決定了哪些面向是承重的

  使用者話裡看不出 2 或 3 時，在提案裡**直接寫出你的推測並標「推測」**，讓使用者一眼改，不要另開一輪問答。

### 1-2 提出面向提案（面向數量不設限，依標的需要；每個面向＝一個紅方）

用下面的格式提給使用者，**提完就停，等回覆**：

```
== 紅藍對抗：面向提案 ==
標的：<...>
要回答的問題：<...>（推測則標「推測」）
利害：<判錯的代價>
建議模式：實作模式 / 分析模式（理由一句）

| # | 面向 | 這個紅方要攻什麼（具體到本標的） | 為什麼承重（連到利害） | 證據標準 | 不歸它管 |
|---|------|------|------|------|------|
| 1 | ... | ... | ... | 可重現 / 外部錨點 | ... |

建議不攻（除非你要）：<例：數字/版號一致性、極端輸入下的行為、措辭>——理由：<與要回答的問題無關 / 不改變決定>

請確認：增刪面向、改「要攻什麼」，或回「照提案」開打。
```

**填表規則**：
- **「要攻什麼」必須具體到本標的**——寫「X 流程在 Y 情況下是否根本不需要」，不要寫「邏輯錯誤」「邊界案例」這種類別名。類別名等於沒定題，紅方會退回找雞毛蒜皮。
- **「為什麼承重」答不出來的面向不要提**——它不會改變使用者的決定。
- **「證據標準」逐面向定，不是逐 type 定**：攻的是「程式/文件會不會實際出錯」→ 可重現（附重現步驟）；攻的是「方向、取捨、會不會有人用、值不值得」→ 外部錨點（base rate / 前例 / 因果機制，見第二步）。同一個 code 標的可以同時有兩種面向。
- **「不歸它管」寫明鄰近但排除的東西**，防止各紅方重疊、也防止滑向細節。
- **一致性類（數字、版號、清單、斷鏈）與極端情境類預設放「建議不攻」**——除非它們正是本次要回答的問題（例：使用者就是要做發布前文件核對），才列為面向。
- 面向的候選來源（**只是素材，不是預設清單**）：下方 type 表與 `references/attack-catalog.md`；加上四個「視角型」面向，常能打到類別清單打不到的地方：
  - **問錯問題**：拋開表面問題，問「真正要解決的是什麼」，這個標的是不是在解錯的題
  - **局外人**：沒有背景知識的人看得懂、用得起來嗎（抓「對作者顯而易見、對別人不明」）
  - **執行者**：明天就要照做，第一步卡在哪、哪一步其實做不到
  - **致命缺陷**：假設這東西三個月後失敗了，最可能是哪個原因（pre-mortem）

### 1-3 核可後

- 使用者有增刪或改寫面向時，**先把提案表重新編號、整理成定稿，回給使用者一次**（不必再等回覆）——這份定稿就是第五步最終回報要逐列對標的那張表，編號以它為準。
- 使用者核可的面向清單＝本次對抗的**範圍**：覆蓋閘（第四步）以它為準；每個紅方只攻自己的面向。
- 紅方的每個 finding 必須掛在某個核可面向下；紅方被要求**面向外的東西原則上不報**，只有重大到會改變使用者決定的才報、並標 `out_of_scope:true`（Workflow 範本的 schema 與紅方 prompt 都這樣寫），所以「範圍外觀察」通常很短或是「無」。標了 `out_of_scope` 的 finding，以及主 agent 過程中自己注意到的面向外問題 → 記入報告的「範圍外觀察」，**不計入迴圈、不修**，使用者要修再另外說。
- 使用者若一開始就說「直接跑 / 用你的判斷」：仍要把面向提案**列出來**（一份表），但不必等回覆，列完即開打——讓使用者事後看得到你攻了什麼、沒攻什麼。

### 1-4 面向候選素材：type 表

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

> 上表只是**提案時的候選素材**，不是自動套用的預設清單——表上的類別名（「邊界」「錯誤處理」「版號/清單不符」）要轉寫成「具體到本標的的攻擊」才能進提案（見 1-2 填表規則）。流程/用人/產品/合規等其他命題，可挑最接近的 type 並自由借用通用面向（attack-catalog 的 ASSUMPTIONS/DEPENDENCIES/ORGANIZATIONAL/TEMPORAL/SECOND_ORDER/FALSIFIABILITY 對任何命題皆適用）。

### 1-5 模式與收斂（提案時一併建議，核可時一併確認）

1. **模式**：

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

2. **收斂準則**：兩模式**都迴圈到「某輪紅方 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）扣分，寧可少報不要報假的。但「證據」有兩套標準，**依第一步提案表該面向的「證據標準」欄**（不是依 type）——同一個 code 標的，「會不會實際出錯」的面向用可重現，「方向/取捨值不值得」的面向用外部錨點：

- **可重現**（攻的是程式/設定/文件會不會實際出錯）：攻擊要可重現/附 PoC，理論性的零分。
- **外部錨點**（攻的是方向、取捨、採用、值不值得）：攻擊須附**外部錨點**（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）會把下一輪紅方重提當「變體」吞掉，「沒修好」就此隱形（這正是本機制要堵的洞）；存在複驗不過項時，收斂判定不得放行。

**面向覆蓋閘**：宣告收斂前須先確認第一步**使用者核可的每個面向**都至少認真攻過一輪——未涵蓋不得收斂，否則退化成只攻淺面向就停的「確認劇場」。

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

**去重**：計數只對「**已確認過的**」底層顧慮（root concern）比，與嚴重度/措辭無關；已確認項的變體不算「新攻擊」。先前判假或 LOW 的顧慮，這次被藍方驗為真且 ≥MEDIUM → **升格為新真弱點**，照算、要修（不可當變體吞掉）。紅方另拿一份「所有提過的顧慮（含假陽性）」清單，只是讓它別重刷；重刷的假 finding 由藍方再判假擋掉，不會讓迴圈不收斂。詳見 `references/convergence.md`。

## 第四步補：強制收斂追蹤（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，每個核可面向各一個紅方）   [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），真的查證過嗎？沒查就回頭補驗。

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

## 第五步：最終回報（逐面向對標第一步核可的提案）

最終回報的骨架**就是第一步核可的面向提案表**：使用者核可了哪些面向，回報就逐一交代哪些面向——讓使用者拿著當初的提案就能逐列對帳「我要你攻的，你攻了什麼、結果如何」。

```
== 紅藍對抗：最終回報 ==
標的：<...>
要回答的問題：<與第一步核可版本逐字一致>
結論：✅ GO / ⚠️ BLOCK / ⚠️ BLOCK（中斷，第 N 輪起未跑完）/ ⚠️ BLOCK（未驗證，N 項）/ ⚠️ BLOCK（覆蓋不全，N 個面向未攻）——<一句話直接回答「要回答的問題」>
輪數：N（自然收斂 / 達 round_cap 強制停）　修復複驗：N/N 過

### 逐面向總覽（列數、編號、面向名、「要攻什麼」與核可提案表一致）
| # | 面向 | 當初要攻什麼（照抄核可提案） | 覆蓋 | 結果 |
|---|------|------|------|------|
| 1 | <...> | <...> | 已攻（R1–R3） | 確認弱點 2（HIGH 已修、MEDIUM ACCEPT） |
| 2 | <...> | <...> | 已攻（R1–R2） | 攻過無弱點 |
| 3 | <...> | <...> | 未攻到 | <原因：紅方 quota 中斷 / 達 round_cap…> |

### 面向 1：<面向名>
- [HIGH] <弱點> — 證據：<重現步驟或外部錨點> → 處置：HARDEN（改了 <檔案:行號>）；修復複驗：過
- [MEDIUM] <弱點> — 證據：<...> → 處置：ACCEPT；殘餘風險：<帶著什麼風險上路>
- 假陽性（藍方驗證為假，已剔除）：<攻擊> — 判假理由：<...>
- LOW（為真但不修，供參考）：<...>

### 面向 2：<面向名>
- 攻過無弱點。最強的一次攻擊：<...>；站不住的原因：<證據>

### 面向 3：<面向名>
- 未攻到。原因：<...>；影響：<這個面向沒攻，哪部分結論沒有證據> → 結論因此為「BLOCK（覆蓋不全）」，補攻後才能 GO

### 不屬任何核可面向
- 範圍外觀察（不計入迴圈、未修）：<...>（無則寫「無」）

### 強化後命題
<...>
```

**對標規則（不可違反）：**
- **一列不少、一列不多**：逐面向總覽的列與「面向 N」小節，必須和核可提案表一對一——編號、面向名、「要攻什麼」照抄。核可時使用者增刪或改寫過面向 → 以**核可後版本**為準，不是你最初的草案。
- **每個面向都要有結論**，三選一：有確認弱點 / 攻過無弱點 / 未攻到。
  - 「攻過無弱點」不可只寫「無」——要寫出最強的那次攻擊、以及它為什麼站不住，否則使用者無法分辨「真的穩」和「沒認真攻」。
  - 「未攻到」要寫原因與影響。**任一核可面向未攻到 → 結論一律為「BLOCK（覆蓋不全）」**，補攻該面向且無未解 CRITICAL/HIGH 後才能改判 GO。核可面向在第一步就必須答得出「為什麼承重」，所以每個核可面向都是承重的，沒有「不承重可以略過」的例外。
- **每個 finding 只放在它所屬面向的小節**（含假陽性、LOW、先前誤判後升格的弱點）；不屬任何核可面向的一律放「不屬任何核可面向」，不得塞進某個面向湊數。走 Workflow 時，照 `loop-runner.md` 回傳的 `ledger` 依 `facet` 分組填；`uncovered` 非空即「未攻到」。
- **結論那一句必須回答「要回答的問題」**——例如問題是「這版能不能發」，就回答能或不能、帶什麼條件；不要只寫「發現 N 個弱點」。
- GO / BLOCK 判準：對抗有跑完（自然收斂或達 round_cap，不是因 agent 回 null 中斷）、所有核可面向都攻過、沒有未驗證的 ≥MEDIUM finding，且所有 CRITICAL/HIGH 都 REFUTE/HARDEN/MITIGATE → GO；因任一 agent 回 null（quota/API 終止）而中途停下 → 一律 BLOCK（中斷），不論已完成的部分多乾淨，補跑完才能重判；還有未解的 CRITICAL/HIGH → BLOCK；有 ≥MEDIUM 的 finding 藍方沒驗到（Workflow 的 `unverified`）→ BLOCK（未驗證）；有核可面向未攻到 → BLOCK（覆蓋不全）。多種 BLOCK 同時成立時原因都寫。
- 「攻過無弱點」的最強攻擊：對話內跑時照實寫；走 Workflow 時取 `attempts`（紅方自報的最強嘗試）與該面向 `false_positive`（藍方判假理由）中較強的一個。

## 實作模式（程式碼 / 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`**，否則去重鍵是空的 → 同一個顧慮每輪都被當成新弱點、重複確認，迴圈收斂不了，一路跑到 round_cap。

## 重要限制（誠實告知）
- **開打前一定先給面向提案、等你核可**（你說「直接跑」則列出提案後即開打）；核可後，**預設實作模式會自動改檔並迴圈到攻不破**；只有高風險改（刪檔/跨 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」其實是卸責、「建議性」規範其實沒人執行）照樣能收斂。產出前須把強化後命題拉回現實掂量一遍——這道刻意不靠對抗（對抗的集體盲點正是問題），靠常識。