idd-verify scope 盲點：implementation 的 diff 外寫入（cross-issue notes / sister issues）不在 ensemble 視野內

[kiki830621]

Problem

Follow-up finding surfaced during PsychQuant/macdoc#143 的 6-AI verify（Devil's Advocate DA-3.3，master report finding G）：
「verify 的 scope 定義為 diff，但 implementation 對 ooxml-swift#98 與 macdoc#142 都做了外部寫入。沒有任何 lens 有機會看到它們。這不是誰失職，是 review 設計的邊界問題。」

具體事故形狀：idd-implement 的 sister sweep / cross-issue note 會對 diff 之外的表面寫入（別的 issue 的 comment、別的 repo 的新 issue）。idd-verify 的 input source 是 diff（PR diff / commit range），reviewer prompts 只拿得到 diff + issue body——implementation 的外部寫入完全不在 ensemble 視野內。macdoc#143 那次，實作筆記的一個事實錯誤（styles「append-only」）被原樣擴散到 #142 的參照 note；4 個 lens 都只評了文件內的措辭問題，唯有 DA 越出 scope 讀了 Implementation Complete comment 的 blast radius 記錄才抓到擴散。靠 DA 個人發揮不是機制。

Type

feature

Expected

評估並擇一落地：

1. 最小版：idd-verify 讀 Implementation Complete comment 的 ### Sister Bugs Filed / 外部寫入記錄，把清單塞進 reviewer prompts 作為「diff 外 blast radius」context（reviewer 至少知道存在）
2. 較完整版：verify 的 scope 解析新增「external writes manifest」——implement 階段把每次 cross-issue/cross-repo egress 記進 manifest（機械可讀），verify 對 manifest 內每筆寫入做內容一致性抽查
3. 不做的話明文記錄理由與殘餘風險

Actual

verify scope = diff only；外部寫入零可見性。macdoc#143 的擴散靠 DA 越界偶然抓到。

Impact

sister sweep / cross-reference notes 是 IDD 的常規產出——它們的內容錯誤目前逃逸於 6-AI 驗證之外。

---

Source: surfaced during macdoc#143 /idd-verify Step 5b follow-up triage（master report: PsychQuant/macdoc#143 (comment) finding G）

[kiki830621]

Closing Summary

Problem

idd-verify 的 scope 是 diff，但 idd-implement 的 sister sweep / cross-reference note 會寫到 diff 以外的表面 —— 別的 issue 的 comment、別的 repo 的新 issue。reviewer prompt 只拿得到 diff + issue body，所以那些寫入完全不在 ensemble 視野內。

macdoc#143 的實例：實作筆記裡一個事實錯誤（styles「append-only」）被原樣擴散到 #142 的參照 note。四個 lens 都只評了文件內的措辭問題，是 devil's advocate 越出自己的 scope 去讀 Implementation Complete 的 blast radius 紀錄才抓到。

Root Cause

不是誰失職，是 review 設計的邊界問題：verify 的輸入源定義為「diff」，而 implement 的產出大於 diff。兩者之間沒有任何一段程式碼負責把差額補進來，所以補不補完全取決於某個 reviewer 當下有沒有自己越界。

Solution — 採選項 1（最小版）

把 implement 自己記下的外部寫入清單（最新 ## Implementation Complete comment 的 ### Sister Bugs Filed / Blast Radius / Cross-reference 區段）塞進 reviewer context，並明確要求核對它們與 diff 實際做的事是否一致。

三個設計決定：

1. 兩個 backend 都給。 pai 走 CONTEXT_BLOCK，manual fan-out 走五個 lens prompt。給不同 context 會讓一個 finding 取決於當時解析到哪個 backend，而 skill 自己的契約說 Step 3 之後兩者可互換。
2. 沒有紀錄時報 UNKNOWN，不報「沒有外部寫入」。 漏跑的 sister sweep 與跑了但沒找到的 sister sweep，留下的痕跡一模一樣 —— 把前者讀成後者，正是這張 issue 在講的那種安靜失效。
3. 不做選項 2。 machine-readable manifest（implement 寫、verify 逐筆抽查內容）是兩個 skill 之間的新契約。這一輪 post-merge audit 的核心發現就是「沒經過自己那輪 review 的新契約，正是缺陷住的地方」—— 三個被記為「已實作」的修法其實不會執行，全都是這個形狀。選項 2 值得做，但值得它自己的 diagnose → plan → verify，不該搭這班車。殘餘風險：清單本身的正確性沒有被驗證，implement 漏記就等於 verify 看不到，這一層目前仍靠 implement 端的紀律。

選項 3（不做並記錄理由）因此只適用於選項 2，已如上記錄。

Verification

新增 scripts/tests/verify-external-writes/（7 assertions）：

• Step 0 有 collect_external_writes task、來源是 Implementation Complete comment
• Tier 1 經 CONTEXT_BLOCK 拿到
• 每一個 manual fan-out lens prompt 都帶到 —— 用數的：annotated 數必須等於 prompt 數，且 prompt 數 ≥4（防 0 == 0 的空洞相等）
• 空紀錄的措辭是 UNKNOWN 而非「沒有」，兩個 backend 都斷言

那條「數的」斷言不是裝飾：第一版插入點鎖在只有 requirements prompt 才有的 attachment 行，五個 prompt 只改到一個、另外四個靜靜留著舊 context。那正是本輪一直在抓的「改了被點到的那行、留下隔壁」，而且是我自己犯的。改成鎖每個 prompt 都有的 Diff path: 行才補齊。

全 suite 51/51（merged main e90bae0 上實測）。

Changes

• plugins/issue-driven-dev/skills/idd-verify/SKILL.md — Step 0 新 task、CONTEXT_BLOCK 追加段、五個 lens prompt
• plugins/issue-driven-dev/scripts/tests/verify-external-writes/test.sh — 新增（第 51 個 suite）
• plugins/issue-driven-dev/CHANGELOG.md — 2.110.0 條目（含不做選項 2 的理由與殘餘風險）

commit f3e3a75，隨 PR #320 squash 進 main（e90bae0）。

---

誠實揭露：本修法沒有經過 ensemble 驗證 —— 而它改的正是 ensemble 自己的輸入組裝。這是一個真實的自我指涉缺口：新的 context 段落是否真的讓 reviewer 抓到 diff 外的錯誤，要等下一次真的有外部寫入的 verify 才知道。測試只證明了 context 有被傳進去，沒有證明它有用。

[kiki830621]

Verify (via PR #320) — FAIL, reopening

Full report: #320 (comment)

選項 1 的實作沒有達成它自己宣稱的範圍。六條 lens 各自從不同角度打到同一批缺陷：

#	缺陷	severity
1	收集用的變數是 $N，在那個 scope 未定義（應為 $NUMBER）——而新測試只 grep 靜態文字，對這段抓取有零執行權重	HIGH
2	抓取用 gh issue view --json comments —— 正是這個 PR 自己指認為七輪根因、並刻意讓 gate 繞開的那條「只回最舊 100 則」通道。最新的 Implementation Complete comment 可能永遠看不到	HIGH
3	「兩個 backend 都給」不成立：canonical pai 端的 devil's advocate 拿不到 —— 而 DA 正是當初在 macdoc#143 抓到擴散的那一個	HIGH
4	抓取寫在標著「Tier 1 專用」的區塊內，所以 manual fan-out 可能每次都拿到 (none recorded)	MEDIUM
5	Codex lens 也沒拿到 —— 兩個 backend 各自以互補的方式不完整，CHANGELOG 的「both backends」兩個方向都不成立	MEDIUM
6	extractor 列了四個 section 名，實際上任何 skill 會寫的只有 Sister Bugs Filed —— 所以當初促成這張 issue 的 cross-reference 那一類永遠回報 UNKNOWN	MEDIUM
7	^ 錨在整個 comment 字串而非每行	MEDIUM
8	cluster verify 的 CONTEXT_BLOCK 會 loop 過每個 ref'd issue，這段抓取只讀一個	MEDIUM
9	把 issue comment 的文字逐字灌進五個 manual fan-out prompt，那個 backend 上沒有 data guard	HIGH

第 10 項最難堪，也最能說明問題：我寫來證明兩個 backend 對等的那條 count-equality 斷言，現在反過來鎖住了不對等 —— 若把 context 補進 Codex prompt，verify-external-writes 會變紅。

殘餘風險那段（清單本身的正確性沒被驗證）仍然成立，而且現在多了一層：清單根本抓不到。

重開。修的時候順帶處理 issue #3 的根本問題 —— 「兩個 backend 都給」這種宣稱要有能執行的斷言，不是 grep 註解。