list_images 只列 relationship 層，看不見 body 引用——孤兒圖片被誤報為存在（sister concern from macdoc#175）

[kiki830621]

Problem

list_images 回報的是 relationship/media 的存在，不是 body 有引用——macdoc#175 的實測中，body 缺 4 張圖的文件被 list_images 回報「7 張全在」，成為三個測不到靜默遺失的驗證管道之一。

即使 macdoc#175 的 root cause（appendParagraph payload 投影丟 drawing）修復，這個語意缺口獨立存在：任何來源的「rels 有、body 無」孤兒 payload（含 genoffice 研究註記過的同款狀態）都會被 list_images 誤報為存在。

Type

feature（tool 語意強化）

Expected

擇一或並行：

1. list_images 輸出區分「has relationship」與「referenced in body」兩個欄位；或
2. 直接以 body <w:drawing> 引用為準，孤兒 rels 另列 warning 欄

Actual

list_images 列 relationship/media 層，body 引用狀態不可見。

---

Source: surfaced during macdoc#175 /idd-diagnose sister concern surfacing (Step 3.6)

Parent context: PsychQuant/macdoc#175（append 圖片靜默遺失）——本 issue 是其驗證管道側的獨立旁支，root-cause 修復不涵蓋

---

Current Status

Phase: needs-fix
Last updated: 2026-09-04 by idd-verify (R3) — unattended loop stopped

Key Decisions

• Verify R3 FAIL，無人值守迴圈到此停止（https://github.com/PsychQuant/che-word-mcp/pull/218#issuecomment-5538385180）。fix round 2（74e3eec + 68a3e8a）確認收掉 R2 的 B2′/B4′(三個 inspector 呼叫點)/DA-1(list 側)/I-a…I-f；殘留為同一族（R3-B1 CRLF 折疊、R3-B2 gate 端重複 id 預檢與文案、R3-B3 declaredDocumentImageIds 自帶 regex、R3-B4 guard 範圍＋空 baseline 讓合法文件拒存、R3-B5 拒絕訊息未跳脫、R3-B6 nested+換行）
• 待決（使用者）：A 根因修在 ooxml-swift（PackageInspector 改 XMLParser 解析 rels／引用、暴露每 part 宣告清單與重複診斷、線性 stripper、merge 不 trap → 3.7.0 → che-word-mcp 刪除模擬層 → R4；建議）／B 續修 che-word-mcp 模擬層（預期第四種形狀）／C 收窄 PR、殘留列為已知限制
• Verify R2 FAIL（見 PR feat: list_images reports body references — orphans are named, not listed as present (#199) #218 Verify (R2) comment）：fix round 1 收掉 B2 與 B5 算術半邊、I1/I2/I4/I5/I8/I9；B1/B3/B4 各剩第二種形狀（listing 與 gate 兩套正規形、長字元參照／屬性空白正規化、guard 順序繞過＋open/revert/reload 三個呼叫點無 guard）、B2′（guard 錯誤路徑回射 part 名、C1 controls）、B5′（body 有引用但 media 缺的 rel 不對帳、chart-only 文件自相矛盾回覆）、新 DA-1（重複 rel id 讓 Session list 觸發 writer fatalError）。超過 idd-all 預設 MAX_ROUND=2，依使用者「七張全部走完 IDD 到 close」的既定指示續做 fix round 2 → R3
• 修法定調：canonicalization 只做在 gate 端一處（(part, id) tuple，字元參照無長度上限＋屬性空白正規化），listing 消費 gate 的判定；guard 改線性前向配對並套到三個 inspector 呼叫點；failure reason 整段跳脫、跳脫依 general category；從 rels 位元組做完整對帳；序列化前預檢重複 rel id
• Follow-ups R2 → ooxml-swift#139（merge fatalError）、Direct Mode（source_path）的 resolveDocument 從不呼叫 doc.close()——每次呼叫漏一個解壓 tempDir（follow-up finding from #199 verify R2） #221（Direct Mode 不 close）
• Verify R1 FAIL（https://github.com/PsychQuant/che-word-mcp/pull/218#issuecomment-5537006645）：5 blocking 全 in-scope——B1 save 預告對 baseline 孤兒錯誤（new-vs-pre-existing 標示）、B2 未轉義回射可偽造列（atoms 加引號＋跳脫）、B3 entity 解碼不對稱（Direct）、B4 原始位元組暴露於二次退化 regex（線性預掃拒檢）、B5 兩母體計數與早退順序（列與 inspection 對帳、inspection 先於早退）；另 9 項 in-scope（Direct 單次讀取、鑑別性 fixture、措辭、快照斷言、reason 遮蔽路徑、docs 鏡像、混合案例、helper throw）。unattended fix round 1/2 進行中
• Implemented 2026-09-04：branch idd/199-list-images-body-reference-semantics，commits b82b505（feat）+ c22ef74（docs）；392 tests 綠；PR 已開（見 Implementation Complete comment）
• 新增 ImageListingInspection（從 ImageConsistencyReport 轉入；後者 memberwise init 在 ooxml-swift 是 internal）與純排版函式 imageListing，讓 unknown / other-part 分支可離線測
• Diagnosis：list_images 只列 relationship 層，看不見 body 引用——孤兒圖片被誤報為存在（sister concern from macdoc#175） #199 (comment)
• Complexity Plan（Layer P decision-heavy：位元組層 inspector vs typed-model 走訪）；/idd-all unattended → 直送 implement，Plan deliberation skipped
• 選 A：讀側與 save gate 讀同一份位元組（PackageInspector.imageConsistencyReport，ooxml-swift ≥ 3.6.0）；Session 走 DocxWriter.writeData、Direct 讀磁碟位元組
• 輸出同時滿足 Expected 1+2：每列 referenced: yes|NO (orphan)|unknown + 標題列計數 + ⚠ 孤兒區塊（具名 rId、env-gated cross-check tests need version-alignment guards after dependency bumps #175 訊號、save gate 預告）；檢查失敗 → unknown，不退回「全部視為存在」；不設 isError（列出成功、孤兒是內容）
• Conflict Class B_resource_serialize：Sources/CheWordMCP/Server.swift
• Sister concerns → che-word-mcp#217（get_document_info imagesCount 同根）、ooxml-swift#136（getImages() 尺寸查找漏表格）

Scope Changes

• header/footer 圖片不進 list_images 的列（本來就不在 document.images）；只在它們有孤兒時具名 part:rId

Blocking

• Verify R3 FAIL；等使用者在 A／B／C 之間拍板（見 Key Decisions）。PR feat: list_images reports body references — orphans are named, not listed as present (#199) #218 保留、不 merge；branch idd/199-list-images-body-reference-semantics @ 68a3e8a

Tasks

• listImages：inspector + referenced 欄位 + 標題列計數 + ⚠ 區塊 + Package: 行；檢查失敗 → unknown
• list_images tool description
• Issue199ListImagesBodyReferenceTests（Session 孤兒 / Direct 孤兒 / 一致 / 無圖 / isError != true）
• CHANGELOG 4.0.11 Added + README 工具表
• swift test 全綠（含 RefusalIsErrorSweepTests）

Commits

• b82b505 feat: list_images reports body references — orphans are named, not listed as present (list_images 只列 relationship 層，看不見 body 引用——孤兒圖片被誤報為存在（sister concern from macdoc#175） #199)
• c22ef74 docs: CHANGELOG 4.0.11 + README — list_images body-reference semantics (list_images 只列 relationship 層，看不見 body 引用——孤兒圖片被誤報為存在（sister concern from macdoc#175） #199)

[kiki830621]

Diagnosis

Type

feature（tool 語意強化；讀側，不改寫側）

Root Cause / Analysis

現況（為什麼 rels 有、body 無的孤兒會被報成「存在」）

list_images（Sources/CheWordMCP/Server.swift:8832 listImages）只做一件事：迭代 doc.getImages() 並逐列印 id / file / size。而 ooxml-swift 的 Document.getImages()（Models/Document.swift:1896）迭代的是 images——由 DocxReader.extractImages 從 relationships.imageRelationships 建出的 rels 驅動清單（v0.13.1 起「relationship 是權威來源」）。body 只被用來查尺寸：走 body.children 的頂層段落找 run.drawing.imageId == image.id，找不到就 0x0 照列。所以：

• 一個 rels 有、word/document.xml 沒有 <w:drawing> 引用的孤兒，會以 size: 0x0px 的形式出現在「Found N image(s)」裡——0x0 是唯一的線索，沒有任何文件說它代表「不在 body」，macdoc#175 的實測就是這樣把缺 4 張的文件讀成「7 張全在」。
• Direct Mode（source_path）與 Session Mode 走同一條路（resolveDocument → 同一個 getImages()），兩邊一樣盲。

權威訊號已經存在，只是 list_images 沒接上

macdoc#175 Stage 1 在 ooxml-swift 3.6.0 加了 PackageInspector.imageConsistencyReport(of: Data)（本 repo pin from: "3.6.4"），對序列化後的 package 做 part-level 掃描，回 ImageConsistencyReport：
bodyDrawingCount / imageRelationshipCount / mediaEntryCount / orphanImageRelationshipIds（document part 的裸 rId）/ orphanImageRelationshipRefs（全 parts 的 part+id）。本 repo 的 save gate（imageConsistencySaveRefusal，Server.swift:6936）已經用它擋 E_IMAGE_CONSISTENCY。同一份文件，save 會拒、list 卻說全在——這是 #199 真正要收掉的不一致：讀側與寫側必須讀同一個訊號。

兩種做法（決策點）

	A. 位元組層：把 package 交給 PackageInspector	B. typed-model 走訪：body → runs → drawing.imageId 集合
訊號來源	Session：DocxWriter.writeData(doc)；Direct：直接讀磁碟位元組	記憶體中的 typed view
與 save gate 一致	是（同一函式、同一位元組）	否——typed view 正是 #175 裡「有圖」而序列化後沒有的那一層
覆蓋	全 parts（header/footer/raw channel 都在 orphanImageRelationshipRefs）	只有 document body，且 getImages() 現行走訪漏掉表格內段落
成本	每次呼叫序列化一次（與一次 save 同量級；無圖文件在 images.isEmpty 早退，不付這筆）	零序列化

選 A。理由：list_images 的職責是告訴呼叫者「檔案裡實際有什麼」，而不是「記憶體裡以為有什麼」；Direct Mode 讀磁碟位元組更是直接對檔案本身做判定。B 的省成本換來的是與 save gate 分家的第二個真相來源，#175 已經示範過那條路的代價。

輸出設計（同時滿足 Expected 的 1 與 2）

• 每列加 referenced: yes / referenced: NO (orphan)（依 orphanImageRelationshipIds 判定 document part）。
• 標題列改為 Found N image(s) — K referenced in body, M orphan (relationship declared, no <w:drawing> reference in word/document.xml):。
• 有孤兒時附 ⚠ 區塊：具名 rId、指出這是 macdoc#175 的訊號、並預告 save_document 會以 E_IMAGE_CONSISTENCY 拒絕（除非 allow_orphan_images: true），讓「list 之後 save」的行為可預期。
• 其他 parts（header/footer）若有孤兒，另一行列出 part:rId——這些不在 list_images 的列裡（document.images 本來就不含 header/footer 圖），但不能因此沉默。
• 附 Package: bodyDrawings= / imageRelationships= / mediaEntries= 一行（與 save 拒絕訊息同格式）。
• 檢查本身跑不動（序列化或 inspector 失敗）→ 每列 referenced: unknown + 明確的 ⚠ body-reference check unavailable: <reason>。這是讀工具，不阻擋列出；但絕不在檢查失敗時退回「全部視為存在」的舊行為（那正是本 issue 的病）。不設 isError：列出成功、孤兒是內容不是失敗（與 拒絕／錯誤以 return "Error: …" 字串回傳時 MCP isError 未設——協定層仍是成功（repo-wide 慣例） #202 的拒絕語意一致：只有拒絕才是 error）。
• 無圖文件維持 No images in document，逐位元組不變。

Impact

• 影響的檔案：Sources/CheWordMCP/Server.swift（listImages + list_images tool description）、新測試檔、CHANGELOG.md、README.md（工具表一行）。
• 影響的使用者流程：任何「插圖 → list_images 核對 → save」的自動化；env-gated cross-check tests need version-alignment guards after dependency bumps #175 的三個盲管道之一由此可測。既有呼叫者：標題列與每列尾端多了欄位，Found N image(s) 前綴與 id/file/size 欄位順序不變。
• 不影響：export_image / export_all_images（匯出 media 本來就以 rels 為準，孤兒的 media 仍可匯出）；save gate 行為不變。

Strategy

• Server.swift listImages：取 package 位元組（Direct → source_path 磁碟位元組；Session → DocxWriter.writeData）→ PackageInspector.imageConsistencyReport → 每列 referenced: yes|NO (orphan)|unknown、標題列計數、⚠ 孤兒區塊（rId + env-gated cross-check tests need version-alignment guards after dependency bumps #175 訊號 + save gate 預告）、其他 parts 孤兒一行、Package: 計數行；檢查失敗 → unknown + 明確警告，不設 isError
• Server.swift list_images tool description：說明 referenced 欄位語意與孤兒警告（Direct/Session 皆適用）
• 新增 Tests/CheWordMCPTests/Issue199ListImagesBodyReferenceTests.swift：(a) Session 孤兒（重用 Issue175R2SaveGateTests.orphanSession 的造孤兒方式）→ 該列 referenced: NO (orphan) + ⚠ 區塊具名 rId；(b) Direct Mode 對磁碟上含孤兒的 package → 同樣判定（證明讀的是磁碟位元組）；(c) 一致文件 → 全 yes、無 ⚠；(d) 無圖文件 → 輸出逐位元組仍是 No images in document；(e) 協定層：孤兒存在時 isError != true
• CHANGELOG.md 4.0.11 加 ### Added 條目（list_images 只列 relationship 層，看不見 body 引用——孤兒圖片被誤報為存在（sister concern from macdoc#175） #199）；README.md 工具表 list_images 一行補「含 body 引用狀態」
• swift test 全綠（含 RefusalIsErrorSweepTests——新字串不得以 Error: 開頭）

Conflict Class

B_resource_serialize — 共享資源是 Sources/CheWordMCP/Server.swift（單一 ~16k 行檔；#201/#202 同鏈剛改過、使用者的 idd/189 WIP 也動它），只能序列編輯、不交錯。

Complexity

Plan

Layer 1 未命中（code deliverable）。Layer 2 未命中：改的是既有 tool 的輸出文字（加欄位），沒有新的 published surface 需要 frozen spec。Hard-gate: not triggered — 估計觸及 Server.swift（listImages + description）、新測試、CHANGELOG.md、README.md 共 4 檔，且只消費 PackageInspector.imageConsistencyReport、不改任何被 ≥2 檔引用的抽象。Layer P 命中「decision-heavy with 2+ valid approaches」：A（位元組層 inspector）vs B（typed-model 走訪）會改變 code shape，上面已做出選擇並記錄理由。

Risks

• Session Mode 每次 list_images 多一次序列化：與一次 save 同量級，且無圖文件早退；若日後有超大文件的反饋再談快取。
• DocxWriter.writeData 是純函式（save gate 已在不動 dirty 狀態下呼叫），不會弄髒 session——測試 (a) 順帶斷言 isDocumentDirtyForTesting 不變。
• 既有以整行文字比對 list_images 輸出的外部腳本會因新欄位而不匹配；Found N image(s) 前綴保留，CHANGELOG 升級注意會寫明。
• header/footer 圖片本來就不在 list_images 的列裡（document.images 不含它們），本案只在孤兒時具名它們的 part:rId，不擴大 list_images 的列舉範圍——那是另一個 feature。

Residue

issue 的 horizon 是「任何驗證管道都不再誤報孤兒為存在」。本案收掉 list_images 這一條；get_document_info 的 imagesCount（Server.swift:8663，同樣是 rels 計數）是同根的另一條管道，Step 3.6 另立 issue 而不併入。ooxml-swift getImages() 走訪漏表格內段落（尺寸 0x0 假陰性）同樣另立。

Vagueness Pre-check

• V1: 2 — WHAT 明確：issue 具名 tool（list_images）、具名缺口（relationship 層 vs body 引用）、具名證據（macdoc#175 實測 7 vs 3）
• V4: 3 — 驗收給了兩個可選形狀（雙欄位 / body 為準 + 孤兒 warning），未指定輸出格式；diagnosis 已鎖定同時滿足兩者的一種輸出
• Triggered: no — both axes ≤ 3

Sister Concerns Filed (mid-diagnose, v2.47.0+ #528)

• Filed: get_document_info 的 imagesCount 是 relationship 計數，不是 body 引用數——孤兒圖片被計入「存在」（sister concern from #199） #217 — get_document_info 的 imagesCount 同樣是 relationship 計數（Server.swift:8663），同根不同出口（spawn_kind: sister-concern, same_file: yes）
• Filed: Document.getImages() 的尺寸查找只走頂層 body 段落——表格內圖片回 0x0（sister concern from che-word-mcp#199） ooxml-swift#136 — Document.getImages() 尺寸查找漏表格內段落，0x0 假陰性與孤兒訊號在輸出上混淆（spawn_kind: sister-concern, same_file: no）
• Skipped: (none)

[kiki830621]

Dashboard

現況：verify R3 FAIL，無人值守迴圈已停止（2026-09-04；R1 → fix 1 → R2 → fix 2 → R3，https://github.com/PsychQuant/che-word-mcp/pull/218#issuecomment-5538385180）。核心需求早已成立且從未退回（document part 孤兒不再被列成存在；六路每輪都確認 Strategy FULLY），兩輪修補也真的收掉大半（注入、guard DoS 三處呼叫點、計數對帳、chart／header 呈現、Direct 資源釋放、標籤語意、docs）。沒收掉的全是同一族：在 che-word-mcp 端逐字模擬 libxml2 的屬性正規化與 ooxml-swift inspector 的 regex 語意——每輪在更窄的邊界長出新形狀（entity → 長參照／空白 → CRLF 折疊；regex DoS → 順序繞過 → nested＋換行、第二個 regex）。根因在 ooxml-swift：#137（inspector 不解碼）、#138（stripper 二次退化）、#139（writer 對重複 id trap）。

你該做什麼（拍板一項）：

• A（建議）：根因修在 ooxml-swift——PackageInspector 改用 XMLParser 解析 rels 與引用（NSXML 語意、線性）、暴露每 part 的宣告清單與重複診斷、RelationshipsOverlay.merge 不 trap → 發 3.7.0 → che-word-mcp fix round 3 刪除模擬層（canonicalAttributeValue／guard／declaredDocumentImageIds／預檢），只留 gate 端消費與 refusal 跳脫 → R4。
• B：繼續在 che-word-mcp 修 R3-B1…B6（可做；預期第四輪仍是同族邊界）。
• C：收窄 PR feat: list_images reports body references — orphans are named, not listed as present (#199) #218——保留已 FIXED 的部分、R3 殘留明列為已知限制＋follow-up，merge 後另案。

PR #218 與 branch idd/199-…（68a3e8a，407 tests 綠）保留、不 merge。

[kiki830621]

Implementation Plan

Complexity = Plan；本次由 /idd-all 以 unattended 模式呼叫 → Plan tier deliberation skipped under unattended mode（無 EnterPlanMode 閘門可過；決策點「位元組層 inspector vs typed-model 走訪」已在 Diagnosis 選定 A 並記錄理由）。

• 修改 Sources/CheWordMCP/Server.swift listImages — 取 package 位元組（Direct → source_path 磁碟位元組；Session → DocxWriter.writeData(doc)）→ PackageInspector.imageConsistencyReport → 每列尾端 referenced: yes / referenced: NO (orphan) / referenced: unknown；標題列 Found N image(s) — K referenced in body, M orphan (…)；有孤兒時 ⚠ 區塊具名 rId、指出 macdoc#175 訊號、預告 save_document 的 E_IMAGE_CONSISTENCY／allow_orphan_images；其他 parts（header/footer）孤兒另一行 part:rId；Package: bodyDrawings= imageRelationships= mediaEntries=；檢查失敗 → 全列 unknown + ⚠ body-reference check unavailable: <reason>；不設 isError；無圖仍回 No images in document
• 修改 Sources/CheWordMCP/Server.swift list_images tool description — 說明 referenced 欄位語意、孤兒警告、Direct/Session 皆適用
• 新增 Tests/CheWordMCPTests/Issue199ListImagesBodyReferenceTests.swift — (a) Session 孤兒（open → insert_image_from_path → delete_paragraph，同 Issue175R2SaveGateTests.orphanSession）→ 該列 referenced: NO (orphan)、⚠ 具名該 rId、session dirty 狀態不因 list 而改變；(b) Direct Mode 對磁碟上含孤兒的 package（用 allow_orphan_images: true 存出）→ 同判定；(c) 一致文件（插圖後直接 list）→ 全 yes、無 ⚠；(d) 無圖文件 → 逐位元組仍是 No images in document；(e) 協定層 handleToolCall：孤兒存在時 isError != true
• 修改 CHANGELOG.md 4.0.11 — ### Added 條目（list_images 只列 relationship 層，看不見 body 引用——孤兒圖片被誤報為存在（sister concern from macdoc#175） #199）+ 升級注意（輸出多欄位、Found N image(s) 前綴保留）；修改 README.md 工具表 list_images 一行
• swift test 全綠（含 RefusalIsErrorSweepTests：新字串不得以 Error: 開頭）

Extra Requirements

• 每個 commit 訊息尾端 (#199)；不用 Closes/Fixes/Resolves。
• Conflict Class B：只序列編輯 Server.swift，不與其他分支交錯。

[kiki830621]

Implementation Complete

Plan tier deliberation skipped under unattended mode（/idd-all 直送 implement；決策點「位元組層 inspector vs typed-model 走訪」依 Diagnosis 選 A）。

Checklist

• 修改 Sources/CheWordMCP/Server.swift listImages — Direct 讀磁碟位元組 / Session DocxWriter.writeData → PackageInspector.imageConsistencyReport → ImageListingInspection（本 repo 的小型轉入型別）→ 純排版函式 imageListing(rows:inspection:inspectionFailure:)：每列 referenced: yes | NO (orphan) | unknown、標題列計數、⚠ 孤兒區塊（rId、macdoc#175 訊號、E_IMAGE_CONSISTENCY / allow_orphan_images 預告）、其他 parts 孤兒一行、Package: 行；檢查失敗 → 全列 unknown + ⚠ body-reference check unavailable: <reason>；不設 isError；無圖仍 No images in document（b82b505）
• 修改 Sources/CheWordMCP/Server.swift list_images tool description（b82b505）
• 新增 Tests/CheWordMCPTests/Issue199ListImagesBodyReferenceTests.swift — 7 案例：Session 孤兒（列標 NO、⚠ 具名 rId、Package: 計數、dirty 狀態不變）/ Direct 讀磁碟（先以 allow_orphan_images 存出、PackageInspector 交叉確認）/ 一致文件全 yes 無 ⚠ / 無圖逐位元組不變（Session 與 Direct）/ 協定層 handleToolCall isError != true / 檢查失敗 → unknown（純函式）/ 其他 parts 孤兒具名（純函式）（b82b505）
• 修改 CHANGELOG.md 4.0.11 ### Added + 升級注意；README.md 工具表（c22ef74）
• swift test 全綠：392 tests, 0 failures（含 RefusalIsErrorSweepTests：新字串皆不以 Error: 開頭）

Commits

• b82b505 feat: list_images reports body references — orphans are named, not listed as present (list_images 只列 relationship 層，看不見 body 引用——孤兒圖片被誤報為存在（sister concern from macdoc#175） #199)
• c22ef74 docs: CHANGELOG 4.0.11 + README — list_images body-reference semantics (list_images 只列 relationship 層，看不見 body 引用——孤兒圖片被誤報為存在（sister concern from macdoc#175） #199)

PR

#218

Notes

• ImageConsistencyReport 的 memberwise init 在 ooxml-swift 是 internal，測試無法直接造；故加 ImageListingInspection（含 init(_ report:)）讓排版函式可在無 package 下測到 unknown 與 other-part 分支。
• Direct Mode 讀的是磁碟位元組而非重新序列化：判定的是檔案本身，不是 writer。
• 未觸及：export_image / export_all_images（匯出 media 本來就以 rels 為準）；save gate 行為不變。

Sister Bugs Filed

• Filed: list_images 完全不列 header/footer 圖片——只有頁首圖的文件回 No images in document（sister concern from #199） #219 — list_images 完全不列 header/footer 圖片，只有頁首圖的文件回 No images in document（實作時確認 images.isEmpty 早退在 inspector 之前；Scope Changes 明文排除的那一塊）
• Skipped: (none)

[kiki830621]

Verify (via PR #218)

Result: FAIL — 5 blocking（save 預告對 baseline 孤兒錯誤 / 未轉義回射可偽造列 / entity 解碼不對稱 / 原始位元組暴露於二次退化 regex / 兩母體計數與早退順序），全部 in-scope；進 fix round，R2 重驗。
Full report: #218 (comment)

This issue's findings: see the linked report (single-issue verify).