本卡屬 FR-120 母案（CM-2152）。只讀、只產出一份分類文件，不改程式碼、不改總表、不改
docs/security-report/、不開修正卡。建議 model：opus／effort：high（要跨三個來源核對現況，還要判斷「修了會不會改變產品行為」）。
掃描已經全部告一段落。決策者要一次看清楚「還有哪些沒修」，分好類、逐類拍板，然後一批交給修正線（FR-114），而不是零零碎碎一直往版本裡加（每加一次就要重新出包＋測試，太花時間）。
這份就是修正線在等的交接清單：FR-114 首腦已暫停 1.21.0b3 的 build，等掃描線把剩下的整理好、決策者逐項裁完，開成第 8 批一起修再出一次包（見 最末節）。決策者裁完後，首腦會照本文件轉成 FR-119 那種格式交出去——所以每一項的檔:行與修法要寫到修正線可以直接開卡的程度。
總表 §7 開頭已有一張「目前真的還要決策者裁的（7 項）」短清單（CM-2206 剛整理完，commit ）——那是「方向類」待裁（例：系統日誌要不要做客戶隔離），本卡的丙類是「具體某一項修了會改變行為」。兩者重疊的直接引用那張清單的編號，不要重寫一份。
這一棒要產出一份分類文件：把所有還沒修好的資安項目列出來，每一項標清楚「現在真的是什麼狀態」「決策者裁過沒」「修了會不會改變產品行為」，再按修法分組。決策者看完這份就能一次拍板。
目前「哪些還沒修」沒有一個可信的單一來源，三份紀錄互相不一致，直接照任何一份列都會錯：
docs/security-report/SUMMARY.md（198 件）：只回寫了第 7 批的修正狀態。第 1～6 批修好的，主線這份還寫著未修——主線版看起來有約 110 件未修／部分修，實際遠少於此。.claude/worktrees/wt-fix-security/docs/security-report/SUMMARY.md（145 件）：第 1～6 批 runner 修完都在這份改狀態，所以前 145 件的狀態以這份為準（首腦數過：只剩約 13 件未修、3 件部分修）。但它沒有第 146～198 件（那是 09-25 掃描線回寫進主線的）。docs/features/security-scan-consolidated/README.md §3.1：第 1～117 項的狀態欄多半沒維護（修正線是照 PM 報告編號派工，不回寫總表）；第 181～218 項（FR-120 主專案掃描）從沒寫進 PM 總報告，決策者只逐項裁過其中 8 項。M06-flow-engine.md 第 17～22 條仍全標未修，但其中對應總表第 155～158 項的已由 CM-2191 修掉（總表那邊已標已修）。三段範圍，每段用不同的來源判斷現況：
docs/features/FR-114-2609-security-fix-dispatch/cards/made-b7*.json（每張卡標題寫了總表項次），卡狀態用 python scripts/notion_case.py get CM-xxxx 查。主線 SUMMARY 寫未修、但第 7 批有 Done 卡涵蓋的，以卡為準。docs/features/FR-120-2609-host-residual-security-scan/scan-U*.md，首腦驗收結論在同目錄 handoff-acceptance-brief.md。不確定就查修正線程式碼（.claude/worktrees/wt-fix-security/ 與套件修正線 ~/Projects/Jedicogy/module/jedi-python-package/.claude/worktrees/jedi-wt-fix-security/），不要只信文件。
docs/features/FR-119-2609-security-scan-closeout/decision-draft.md 末尾裁定表。