最後更新：2026-09-28 第二十四任（交棒）：🏁 掃描線收尾完成。 掃描線 09-28 階段性結束後的四件收尾都做完：①掃描線 Notion 全部收 Done（103 張子卡＋22 張母卡／早期修正卡／作廢卡＋非掃描線 19 張決策者裁關）；②資安總表
docs/features/security-scan-consolidated/README.md改成 1.21.0 出貨後終局（CM-2291，「未合回」0 處、§3.1 181～218 逐項有狀態）；③PM 總報告docs/security-report/由 FR-114 首腦 CM-2285 改（commit887758ac7）；④148 個掃描 run 目錄歸檔到security-scan-consolidated/runs/、411MB 流水帳清掉、三 repo.gitignore擋新產物（CM-2292）。規則已入 skill 第五節第 8 步、scan-card 樣板、memory。 🔴 本 arc 沒有待辦了。 後續若有新掃描需求另開新 FR，不延續本 arc；接手者讀本檔只為了解歷史座標與判準，不需要再做任何收尾動作。 📌 還開著但不屬本線的 Notion 卡（決策者 09-28 裁留）：CM-1995 分頁條件「或」不「且」、CM-1886 FR-107 端到端回歸、CM-984／1110／1111／1274／1452／1479／1510／1574／1992／2198 各線 follow-up。其中 CM-1452（188 build venv 殘留 jedi-oscal 舊版、Nuitka 吃那個 venv）建議優先看。資安總表 §3.2 第 39／40 項（雲端硬碟金鑰換掉同步靜默失敗、診斷包匯出稽核不記成敗）無卡，等決策者裁是否併 1.21.1 hotfix CM-2289。 ⏭ 等令：push（BE 本線 commit75b8150e4／85dd9d1e5／72dfe0128／decd97089／2d058eb52，jedi18b52e50，LCec911e41；決策者說要回 main 一版）。
角色鐵則見 CLAUDE.md「分析決策人員」條與 security-scan-lead skill。接手後照 closing-and-handoff skill 的接手側紀律：讀完、盤點完、回報「①自檢 ②現況 ③待辦已就緒等發令」即止。
決策者原話：「目前每一次的報告都看不懂，都是 AI 文言文版，這個要寫到記憶或是 skill 裡面，不然每次產出都要在多整理一次。」
讀者有兩種，兩種都要看得懂：PM（不懂程式）與新手工程師（懂程式但不熟這個 codebase）。這條同時管掃描報告、SUMMARY 總報告、runner 回報、Notion 回寫與修正卡內容。
.claude/skills/security-scan-lead/SKILL.md 第十節——術語對照表、報告骨架、runner 回報規則、交件前自檢三問。寫報告前讀那一節，不要憑印象。docs/claude/memory/feedback_security_report_plain_language.mddocs/features/FR-081-2609-issue-tracking-security-scan/（六份 scan-I*.md ＋ SUMMARY.md，2026-09-10 依新規則全部重寫過）兩個最常犯的：① 把「工具跑了什麼」（派了幾個 agent、幾票、幾分鐘）放在報告最前面——PM 不在乎，他在乎「有沒有事、要不要現在修」；② 用嚴重度標籤代替說明——寫「MEDIUM」不等於解釋了嚴重度，要寫「為什麼是中不是高」。
SUMMARY 要有「預計怎麼修復」段（2026-09-10 決策者補充要求）：每張修正卡都要寫具體修法、分幾步、哪一步要決策者放行、做完怎麼驗。
冷接自檢三題（答得出來才算讀懂）：
.env 環境變數，但這是客戶自助的功能設定不是基礎設施設定，判準見「教訓」段第①條，退回後改成設定頁欄位 verify_cert/ca_cert_pem）verification.status: unverified，覆蓋率無法宣稱（FR-077 R1）；後者＝工具把死掉的 verifier 記進 adversarialCasualties、額度重置後用完整三人面板重投，票數自洽（FR-078 N2）。判準是看 stamp 的 verification.status 與 verification_runs，不是看有沒有出現額度錯誤。第三種型態（FR-095 P1，2026-09-14）：unverified 但 reason_kind: findings-refused＝面板完整跑完、票全投，只是渲染器把研究員路徑寫錯（多一層套件前綴）的那幾條退掉，正式產物 .jsonl／.sarif 少了幾條。這種以 runner 手寫報告為準、被退的那幾條人工補回即可，不算面板失敗。所以看到 unverified 先看 reason_kind，三種型態處置完全不同）| FR | 棒 | 卡 | 狀態 | 首腦驗收 |
|---|---|---|---|---|
| 075 | S1 認證與外部身分 | CM-1547 | ✅ Done，8 條 5H3M | ✅ 已驗，開 5 張 |
| 075 | S2 授權守門 | CM-1548 | ✅ Done，0 條 | ✅ 已驗，首腦加開 CM-1559 |
| 075 | S3 MFA＋Turnstile | CM-1549 | ✅ Done，2 條 1H1M | ✅ 已驗，開 2 張 |
| 075 | S4 使用者與密碼 | CM-1553 | ✅ Done，5 條 2C1H2M | ✅ 已驗，開 4 張 |
| 075 | S5 角色與權限 | CM-1554 | ✅ Done，2 條 MEDIUM | ✅ 已驗，開 CM-1585／1586 |
| 075 | S6 租戶與組織 | CM-1555 | ✅ Done——2026-09-07 已用 Opus 1M 重跑成功（commit 0a1e6f86），26 agent 全回報、8 候選投完 24 票、stamp verified；結果 1 條 MEDIUM（部門讀端點無守門） |
✅ 已驗，開 CM-1588／1589 |
| 075 | S7 登入態／middleware（重跑） | CM-1556 | ✅ 重跑完成並驗收（2026-09-10 跑、09-11 驗）。範圍收窄 74→29 檔後4 條候選零越界，stamp verified、12 票全投；1 條 MEDIUM（3/3）＋人工 2 條 |
✅ 已驗。runner 未交付報告，首腦補寫；⚠️ 派 2 研究員只回 1（另一個 stalled 重試六次未救回），「只有這一條」不可宣稱 |
| 076 | L1 驗章核心 | CM-1567 | ✅ Done，3 條（1 範圍內 HIGH） | ✅ 已驗，開 2 張 |
| 076 | L2 授權狀態 API | CM-1568 | ✅ Done，1 條 LOW＋人工發現 1 HIGH | ✅ 已驗，開 2 張 |
| 076 | L3 LC 簽發核心 | CM-1569 | ✅ Done，2 條範圍內（序號 32 bits／log 遮蔽整串印）＋3 條越界重複 L4 | ✅ 已驗，併入 CM-1583 |
| 076 | L4 LC 網頁後台 | CM-1571 | ✅ Done，4 條 MEDIUM | ✅ 已驗，開 2 張 |
| 077 | R1 agent 身分與註冊（42 檔，jedi monorepo） | CM-1592 | ✅ 掃完 7 條（面板未跑成，runner 逐條核對） | ✅ 已驗（09-08），開 4 張修正＋1 補掃 |
| 077 | R1b 補掃密碼學核心（10 檔，common/agent_auth/） |
CM-1599 | ✅ 掃完並驗收（09-16 20:40）：2 研究員全回、15 票全投、stamp unverified＋findings-refused（第三種型態，F2 檔在 git 歷史不在樹裡被渲染器退件，面板完整）、版本 3cc966f8、1h53m；通過 2 皆 MEDIUM——F1 enroll token 無到期＝重複 CM-1597（四層無到期欄由引用變實證）、F2 越界新發現：jedi-issue 歷史第二把寫死 GitLab token，首腦雜湊比對確認與 CM-1573 那把不同、無撤銷紀錄（總表第 83 項、§7 第 26 項要決策者去後台撤銷）；駁回 3（ca.py 沿用 CSR subject／SAN 自自報 base_url／3650 天，屬實但被 enroll token 門擋住，與 F1 互相倚靠）；四支未被提及檔首腦人工補查乾淨。**runner 四件全未交，首腦補（第九次） |
✅ 已驗。回答 R1 留下的問題：密碼學核心是「讀過」** |
| 077 | R2a 任務下發與狀態機＋控制面 route／守門殼（30 檔，jedi-remote-agent） | CM-1593 | ✅ 掃完並驗收（09-17 09:15）：stamp verified、2 研究員全回、15 票全投全 3:0——remote-agent 第一次真正跑完面板；通過 5（3H 1M 1L）淨新增 0 全併 CM-1595／1596；F3「任務租戶由呼叫者給的 uid 決定」3:0 坐實首腦 09-16 推翻降級的判斷；補完 CM-1595 攻擊鏈四點（唯讀授權豁免 /agents/／宿主主動 fetch 攻擊者 blob／可選租戶的鍵三種／管理面回傳指紋）；七重點工具碰三個首腦補四個（守門殼缺注入＝意外 fail loudly／狀態機無鎖後果 409／payload 不落 log）。runner 四件全未交首腦補（第十次） |
✅ 已驗 |
| 077 | R2b 檔案取用與 agent 連線（13 檔，jedi monorepo） | CM-1601 | ✅ 掃完並驗收（09-17 09:15）：2 研究員全回、15 票全投、stamp unverified＋findings-refused（F1 歷史檔退件，面板完整）；通過 4 皆 MEDIUM：F2／F3 檔案下載租戶由攻擊者給的 agent 編號決定，同租戶與跨租戶都成立（第五個裸奔控制面端點，首腦裁併 CM-1595）、F4＝R2a 同 sink、F1 越界＝CM-1573 同把（雜湊比對）；七重點工具碰三個 runner 補四個；🔴 runner 順手更正第 47 項：upload_files 已於 09-16 a48b41cc 補租戶欄＋4 條 RLS，首腦 DEV 重查 2,718 筆全帶租戶屬實。交付四件齊全（第十五次做滿） |
✅ 已驗 |
| 077 | R3 主專案宿主接線（16 檔，BE repo） | CM-1594 | ✅ 掃完並驗收（09-17 11:50）：stamp verified、2 研究員全回、21 票全投、版本 4bf687c0、1h41m；通過 6（3H 3M）範圍內淨新增 0（F2＝CM-1595 宿主側終點、F4/F5＝第五端點）；越界 F1＝CM-1629 同把、F3 公開文件站洩 cmmgr＋blsadmin／blsit（首腦親 fetch 確認）→ 總表第 84 項 HIGH，已通報決策者換密碼、F6＝第 3 項；八重點工具碰兩個首腦補六項全乾淨。runner 四件全未交首腦補（第十一次）。FR-077 五棒收口 |
✅ 已驗 |
| 078 | N1 套件本體（30 檔，jedi monorepo） | CM-1603 | ✅ 掃完 2 條 MEDIUM，面板完整跑完 | ✅ 已驗（09-08），併入 CM-1606 |
| 078 | N2 宿主接線（18 檔，BE repo） | CM-1604 | ✅ 掃完 6 條（2H 3M 1L），面板完整跑完（含一次撞額度後續跑） | ✅ 已驗（09-08），開 3 張 |
| 079 | B2 宿主接線（33 檔，BE repo） | CM-1610 | ✅ 掃完 10 條（8M 2L，其中 6 條範圍外），**面板完整跑完（兩輪＋一次 resumeFromRunId 續跑） | ✅ 已驗（09-09），修正卡待開**（F12 降級併 CM-1607、F15 暫不開卡） |
| 079 | B1 套件本體（29 檔，jedi monorepo） | CM-1611 | ✅ 掃完，工具零發現（2 候選皆 0/3 否決），面板完整跑完；runner 人工補 3 條 | ✅ 已驗（09-08） |
| 081 | I1 第三方整合與憑證（25 檔） | CM-1613 | ✅ 掃完 3 條（2 範圍內），面板完整（9 票全投） | ✅ 已驗（09-10），開 CM-1632 |
| 081 | I2 宿主接線（31 檔，BE repo） | CM-1614 | ✅ 掃完 10 條（1 HIGH），stamp verified、30 票全投 |
✅ 已驗（09-10），開 CM-1629／1630／1631 |
| 081 | I3 附件上傳下載（14 檔） | CM-1615 | ✅ 掃完，工具範圍內 0 新增（兩條重複） | ✅ 已驗（09-10），首腦補查開 CM-1633 |
| 081 | I4 對外面與插件契約（20 檔） | CM-1616 | ✅ 掃完，工具範圍內 0 新增；兩項指定查證由首腦補做 | ✅ 已驗（09-10），fail-closed 確認為真 |
| 081 | I5 app 與 domain（40 檔，邊界測試） | CM-1617 | ✅ 掃完，面板完整（15 票全投、零漏投）；新增 1 條（明文套件庫） | ✅ 已驗（09-10），開 CM-1634 |
| 081 | I6 持久層（28 檔） | CM-1618 | ✅ 掃完，工具範圍內 0 新增；首腦查出六張表完全無 RLS | ✅ 已驗（09-10），併入 CM-1630 背景 |
| 082 | **A1 AI 聊天機器人（14 檔） | CM-1637 | ✅ 掃完 1 條 MEDIUM，stamp verified 無拒收原因（最乾淨一次）** |
✅ 已驗（09-10），開 CM-1638 |
| 083 | **D2 AI 儀表板宿主接線（18 檔，BE repo） | CM-1640 | ✅ 掃完 11 條（2H 9M），stamp verified、33 票全投 |
✅ 已驗（09-10），決策者裁不開卡**，登記總表 §3.1 |
| 083 | D1 AI 儀表板套件本體（34 檔） | CM-1641 | ✅ 掃完 2 條（1H 1M），stamp verified、6 票全投 |
✅ 已驗（09-10），決策者裁不開卡，登記總表 §3.1 |
| 084 | **T1 防竄改機制 jedi-integrity 套件本體（21 檔） | CM-1645 | ✅ 掃完，stamp verified 6 票全投，工具正式 0 條、runner 人工 6 條** |
✅ 已驗（09-10），T1-3 降 MEDIUM；決策者裁不開卡，登記總表 §3.1 第 13～18 項 |
| 084 | **T1b 本機實測 T1-2（驗章器掉包 PoC，非掃描棒） | CM-1650 | ✅ 實測完成，T1-2 確認成立**（閘門＋抽查同時被騙過，無警示） | ✅ 已驗（09-10），首腦另跑 build 腳本 closure 複核；維持 HIGH |
| 085 | **C1 jedi-common 授權鏈核心（29 檔） | CM-1647 | ✅ 掃完，stamp verified、24 票全投**（8 候選×3）；工具 3 條（2H 1M）＋人工 2 條 |
✅ 已驗（09-10）。runner 未交付報告與回寫，首腦補做；2H 即 CM-1559，新增 C1-3 SQL 錯誤外洩、C1-4 Redis 漏網 |
| 085 | **C2 jedi-common log 全鏈（32 檔） | CM-1648 | ✅ 掃完，stamp verified、12 票全投；工具 0 條、runner 人工 7 條（1H 4M 2L）** |
✅ 已驗（09-11）。HIGH 是密碼與 JWT 原文進 log；首腦 DEV 實查複核 system_logs 無隔離六個數字全對 |
| 086 | **B1 檔案上傳下載 HTTP 邊界與契約（35 檔） | CM-1652 | ✅ 掃完，stamp verified、18 票全投**；4 條（3H 1M）＋人工 1L |
✅ 已驗（09-11）。交付四件齊全。四條同病（只驗身分不驗歸屬）共用一道修法；卡片最重要那條（路徑穿越）經查不成立，但屬執行順序意外擋住 |
| 086 | **B2 宿主接線：儲存解析與租戶憑證（10 檔，BE repo） | CM-1653 | ✅ 掃完，stamp verified、36 票全投；範圍內 1 HIGH ＋人工 4 條**，9 條範圍外為舊案重複 |
✅ 已驗（09-11）。runner 未交付報告，首腦補寫（第三次）。證實四層全空；人工另追出「任何登入者可取本租戶物件儲存帳密明文」（HIGH） |
| 087 | **T1 租戶隔離破洞盤點（13 表＋4 view＋1 API） | CM-1663 | ✅ 盤完，交付三件齊全**（commit d51249d7）。逐表五問全答、分七組修法 |
✅ 已驗（09-11）。首腦複核五項屬實（含 DEV 實查 191 筆無主資料、兩支排程行號、平台管理員判定同源）。查證更正交接檔一處推測；另查出「兩支背景排程與 CM-1559 相依」 |
| 086 | **B1b 儲存後端實作與持久層（26 檔） | CM-1654 | ✅ 掃完，stamp verified、6 票全投；工具達標 0 條**，人工 5 條（1H 2M 2L）＋3 條證偽 |
✅ 已驗（09-12），交付四件齊全。資料庫實查坐實四層全空的最後一層（upload_files RLS=false、0 規則、無 tenant 欄、2,690 筆）。FR-086 arc 收口 |
| 088 | **H2 flow-engine 宿主：任務完成／回退／留言／證明（23 檔，BE repo） | CM-1670 | ✅ 掃完，stamp verified、30 票全投；範圍內 3 條（1H 2M）＋人工 1 條（併 P1）＋證偽 1 項；6 條範圍外全舊案 |
✅ 已驗（09-12）。交付四件齊全**（commit e9507d29）。三條逐條開檔＋DEV 三筆數複核全對；F9 維持 MEDIUM（釣魚面可升，交決策者）；登記總表 §3.1 第 49～51 |
| 088 | **H1 稽核階段推進與回退（21 檔，BE repo） | CM-1671 | ✅ 掃完，stamp verified、33 票全投；範圍內 4 條（3M 1L）；卡片兩大疑點：跨專案推進「讀成立寫不成立」、force 雙版本 0:3 否決；4 條範圍外全舊案 |
✅ 已驗（09-12）。交付四件齊全**（commit 1e95823b）。四條逐條開檔、七條寫入路徑第二道檢查逐一核對、DEV 五張表 RLS 複核；無改判；登記總表 §3.1 第 52～54＋§3.2 第 13 |
| 088 | **P1 流程圖範本與 BPMN 解析（30 檔，jedi） | CM-1672 | ✅ 掃完，stamp verified、9 票全投皆 3:0；範圍內 2 條 MEDIUM**（runner 報 3，F2 首腦判範圍外＝CM-1634）；八項疑點五證偽；密鑰專項零撈獲；耗時 7h15m |
✅ 已驗（09-13）。交付四件齊全（commit ebd3b1e1）。兩條逐條開檔、五項證偽首腦重跑實測、DEV workflow_templates 複核；改判 F2 範圍外；登記總表 §3.1 第 55～56＋§3.2 第 14、§2.9 新增 🅹 資源耗盡組 |
| 088 | **H3 流程範本管理（13 檔，BE repo） | CM-1673 | ✅ 掃完，stamp verified、30 票全投全 3:0、5 條降級；範圍內 2 條（1M 1L）**：validate 端點任何登入者打一次卡住工作程序／範本讀取無 .read 能力點；8 條範圍外全舊案（1 新位置併 CM-1608） |
✅ 已驗（09-13）。⚠️ runner 未交付四件，首腦補寫報告（本 arc 第一次、全計畫第四次）；兩條開檔＋gunicorn／body／limiter 核對；七項疑點首腦自答；DEV 實查修正 FR-087 戊組：191 筆裡只 5 筆快照、186 筆母版；登記總表 §3.1 第 57～58 |
| 088 | **H4 流程執行宿主服務與接線（21 檔，BE repo） | CM-1674 | ✅ 掃完，stamp verified、27 票全投 8 條 3:0；runner 報範圍內 3 條、範圍外 6 條 |
✅ 已驗（09-13）。交付四件齊全**（commit c6c12e68）。首腦改判：1 條新（viewer 可完成別人任務，第 59 條，先問決策者）＋2 條重複（留言零守門＝H2 第 51、檔不在 scope；projects RLS 關＝第 43／5／10）；八項疑點全答、卡片兩處猜測被修正；範圍外 1 條新型態併 CM-1607 |
| 088 | **P2 流程執行核心（49 檔，jedi） | CM-1675 | ✅ 掃完，stamp verified、6 票全投（1 條 3:0、1 條 0:3）；runner 報 1 條自標重複第 51 |
✅ 已驗（09-14）。0 條新**；對照表證實宿主沒 import 套件 WorkflowExecutionService、JobExecutionService 接了沒人用（§3.2 第 16）。FR-088 六棒收口，SUMMARY 等令 |
| 095 | **P1 專案成員新增／移除／角色指派＋守門入口＋掛載契約（39 檔，jedi） | CM-1780 | ✅ 掃完，stamp unverified 但 reason_kind: findings-refused（面板 12 票全投 4 條全 3:0，只是渲染器退掉兩條路徑帶前綴的），範圍內 2 條（1H 1M，工具 4 條去重）＋人工 3 條（2M 1L～M）＋排除卡片疑點 1 項**；密鑰專項零撈獲、無範圍外 |
✅ 已驗（09-14）。交付四件齊全（報告 commit 437fc9a9、README fa87a524、Notion append 含 hash 與 run ID wf_b2dc8f24-2f9、狀態「修正待驗證」）。五條逐條開檔無改判；P1-1 首腦維持 HIGH（面板取 MEDIUM，但門檻只要登入、不需編號、空請求全表跨客戶 751 筆，依「可利用門檻」判準應為高）；登記總表 §3.1 第 60～64＋§3.2 第 17～19＋§2.9 🅰 一列＋§3.4 一條＋§6 A 組一條待裁（「有注入才守門」要不要整組改） |
| 095 | **H1 專案 CRUD＋成員同步＋接線 plugin／DI（35 檔，BE repo） | CM-1781 | ✅ 掃完，stamp verified、24 票全投 8 條全 3:0、無拒收；工具 8 條＝範圍內 4 條新（全 MEDIUM）＋2 條鏡像＋3 條舊案重複（第 3／第 10／CM-1608） |
✅ 掃完＋已驗（09-14），runner 未交付四件首腦補寫**（全計畫第五次）。四條逐條開檔＋DEV 唯讀實查四張表 RLS；首腦改判 F1＋F2 HIGH→MEDIUM：掃描版本 739a0a61（15:03）時摘要報告兩張表 RLS 未開、CM-1800（18:52，aac15d06）掃後補開，跨客戶已擋、同客戶跨專案仍可讀；卡片七項疑點工具只碰 ③ 一半、其餘首腦自答（module_frame_service.py:242 的 enforce_role=False 有 route 能力點守門，不是漏洞）；登記總表 §3.1 第 65～67＋§3.2 第 20＋§2.9 🅰🅱 各一列＋§1 一列＋§3.4 一條；run ID wf_9b402a56-704；無新增待裁 |
| 095 | **P2 任務指派＋六張參與者表資料存取＋migration（35 檔，jedi） | CM-1782 | ✅ 掃完，stamp verified、6 票全投 2 條全 3:0、無退件；範圍內 2 條（工具 4 條去重）＋人工 4 條（P2-3～P2-6） |
✅ 掃完＋已驗（09-15），交付四件齊全。首腦改判：P2-3「六張表隔離全關」改記為事實變更**（掃描後 4 小時 FR-094 CM-1800 已開六張表 RLS）；更正首腦開卡誤判（P2-6 批次指派端點其實有 FE 呼叫者）；登記總表 §3.1 第 68～71＋§3.2 第 21～23＋§6 A 組第 15 項待裁（共用底層根因第三次撞到） |
| 095 | H2 任務 CRUD／匯入匯出／批次完成／執行查詢（19 檔，BE repo） | CM-1783 | 🛑 決策者 2026-09-15 裁停掃，不再派（卡留「未開始」不動）。理由：剩三棒要問的問題前三棒已答完，同型根因第三次出現，時間換去掃別支更值得 | — |
| 095 | P3 任務留言／匯入匯出 route／執行啟動＋三道守門殼（32 檔，jedi） | CM-1784 | 🛑 隨 H2 一併停掃（同上裁定） | — |
| 095 | P4 任務領域模型＋任務型別登記簿＋四張 job_execution_ 表（20 檔，jedi）* | CM-1785 | 🛑 隨 H2 一併停掃（同上裁定） | — |
| 095 | P5 專案 CRUD＋人員指派剩餘領域層（37 檔，jedi） | CM-1786 | 🛑 隨 H2 一併停掃（同上裁定） | — |
| 085 | **C3 jedi-common 輸出面與打包（30 檔） | CM-1649 | ✅ 掃完，stamp verified、18 票全投**；工具 4 條（3M 1L）＋人工 6 條（4 條查證無問題） |
✅ 已驗（09-11）。交付四件齊全（本 arc 第二個做滿的）。C3-1 與既有 CM-1634 同一件事，標重複不另計 |
| 096 | **P1 設定表全鏈：讀寫設定／遮罩／物件儲存憑證（24 檔，jedi） | CM-1804 | ✅ 掃完，stamp verified、候選 4／去重 4、12 票全投**（2 通過皆 3:0、2 否決皆 0:3）、研究員 1 派 1 回、零漏投、耗時 2h39m、掃描版本套件 327c283 且 dirty: false、run ID wf_881b24e3-df3；**範圍內 2 條（1H 1L） |
✅ 已驗（09-15）。runner 未交付四件，首腦補 commit／Notion／狀態**（全計畫第六次）。兩條逐條開檔核對全屬實、無改判；F1（HIGH）讀設定三入口只驗登入→任何登入帳號可取物件儲存帳密（套件 system_config_route.py:41／:56 ＋主專案 api/system_config/routes/system_config_route.py:131，三處都要補）；F2（LOW）遮罩名單漏物件儲存欄位（plugin/contract.py:61／:65，該檔自陳名單「凍結」故屬契約變更）。首腦 DEV 實查補強：租戶 1（FACTORY_DEFAULT）與租戶 102（CONFIG）的 secret_key md5 完全相同→「同一組帳密複製給新客戶」由推測變實證；DEV 另四個租戶該列為空是 seeder「失敗不擋建立」，正式環境每套安裝都會寫入。登記總表 §3.1 第 72／73、§1 一列、§0 數字 88→90、§0.5 與 §4 system-core 改「部分掃過」、§2.9 F1 入 🅰 組 F2 入 🅲 組 |
| 096 | **H1 主專案宿主接線（25 檔，BE repo） | CM-1805 | ✅ 掃完，stamp verified、候選 2／去重 2、6 票全投**（2 條皆 3:0 通過）、零漏投零降級、研究員 1 派 1 回、耗時 13m10s、掃描版本 2b11bd54 且 dirty: false、scan_id b9ae4ba8；工具報 2 條皆 HIGH |
✅ 已驗（09-15）。runner 未交付四件，首腦全補（全計畫第七次）。淨新增 1 條：F1 判為 §3.1 第 72 項重複（同一支 system_config_route.py:131，P1 已登記；工具寫 :134 是呼叫行，行號以 :131 為準），僅帶回兩個新細節補進第 72 項；F2 為新，首腦把信心 medium→high——檢查員卡在「新客戶預設管理員是否持有該權限」這個部署前提，首腦 DEV 唯讀實查坐實（security-policy.update／ldap-config.update／smtp-config.update 三者皆 is_platform=f、8 個非總部租戶管理員角色實際持有；RUNTIME_CONFIG 僅 7 筆全屬 tenant 1；tenant_provisioning_service.py:120-131 開通時自動發放所有非平台層能力）。LDAP／SMTP 那一半比主打更嚴重（驗證來源可被掉包）。⚠️ 卡上八點：工具四點完全沒碰（含卡片自標「最重要」的①繞過守門版服務）、三點只碰一半。登記總表 §3.1 第 74、§1 一列、§0 與 §3 數字 90→91、§0.5 與 §4 覆蓋率、§2.9 入 🅷 組、第 72 項補兩細節 |
| 096 | **P2 選單字典（33 檔，jedi） | CM-1806 | ✅ 掃完，stamp verified、候選 1／去重 1、3 票全投（0 通過／1 否決，一致票）、零漏投零中斷、研究員 1 派 1 回、耗時 10m38s、掃描版本 8bc5d27 且 dirty:false、run ID wf_97ccbfe7-532；零發現** |
✅ 已驗（09-15）。交付四件齊全——本 arc 唯一做滿的一棒。首腦復核否決：四個來源自核（出貨 seed 74 筆全 public、欄位預設三處皆 1、寫入端兩支皆 @platform_admin_required、DEV 重查 74 筆 private=0）→ 同意否決。🔵 記一筆（不列發現）：前台 system_menu_route.py:39 只濾 enable 未濾 public，而管理端 system_menu_service.py:38 寫死 _filter.public=1——擋住它的是「現在沒有 private 資料」不是程式，平台管理員一旦標 private 即刻外曝，修法一行。六個重點 runner 全追完（守門順序／排序白名單／錯誤訊息不外洩／SQL 冪等）。⚠️ 本輪工具未回報逐檔覆蓋率，20 支實質檔的逐檔覆蓋無保證；零發現≠乾淨（該半檔案 docstring 大量自陳「刻意設計」，正是工具已知盲點）。FR-096 三棒收尾，總表 §0 進度句／§0.5 已掃完 12 支／§1 一列／§4 覆蓋率同步 |
| 097 | **L1 日誌轉送全鏈（39 檔，jedi） | CM-1811 | ✅ 掃完，stamp verified、候選 2／去重 2、6 票全投**、零漏投零中斷零降級、研究員 1 派 1 回、耗時 1h31m、掃描版本 9b35885 且 dirty:false；工具報 2 條皆 MEDIUM |
✅ 已驗（09-15）。交付四件齊全（第九次做滿）。工具兩條逐條開檔核對屬實、維持中等不改判（F1 沒加密 2:1 通過、F2 換行注入 3:0 且有檢查員實測）；🔴 首腦補查另得 1 條 HIGH——工單重點①工具完全沒碰：log-forwarding.update 是客戶層級（DEV 實查 8 個非總部租戶管理員角色持有），但 log_forwarding_app_service.py:64 把 tenant_id 寫死 None 交 save_global()、repo_impl.py:29 固定撈 NULL 那列、DEV 表僅 1 筆且 tenant_id 為空 → 客戶管理員可把全公司日誌導去自己機器，與第 74 項同病第二例。三條合成完整攻擊鏈（改得動目的地→路上沒加密→可塞假紀錄），與第 22 項（密碼原文進日誌）相扣。🔵 首腦另查出報告未寫的細節：修 F2 不能只改 syslog 半，gelf 的 full_message 仍原樣帶出。登記總表 §3.1 第 75／76／77、§0 與 §3 計數 91→94、§1 一列、§0.5 部分掃過新增 jedi-log、§2.9 入 🅳 與 🅷 組 |
| 097 | **L2 API 操作記錄全鏈（43 檔，jedi） | CM-1812 | ✅ 掃完，stamp verified、候選 1／去重 1、3 票全投三位一致通過**、零漏投零中斷零降級、耗時 1h14m、掃描版本 cdb0d0f4 且 dirty:false（與 L1 的 9b35885 不同版，首腦比對兩版間唯一 commit 未動本棒範圍，零漂移） |
✅ 已驗（09-16）。交付四件齊全（第十次做滿）。F1 公式注入屬實維持 HIGH——api_log_service.py:89 寫 Excel 前只過 clean_invalid_characters（僅清 \x00-\x1F）、主專案 app_mw.py:40-42 的 before_request 確在守門之前（種公式不需登入）；🔵 首腦補充報告未寫的事實：ApiLogExportDTO 17 欄中 6 欄吃外部輸入（url／params／request／response／message／user_agent），佐證「修在出口不逐欄補」。🔴 首腦 DEV 實查推翻報告一處時間點：報告稱「9 月分區已建好、10 月才發作」，實際 api_logs 與 system_logs 皆無 9 月分區，api_logs_default 已堆 20,959 筆全為 9 月、system_logs_default 87,471 筆從 8/31 起——早已發作半個月，方向對時間錯且低估急迫性。該條非新發現（已登記 known-pits-remediation-tracker.md 的 user-log#6），本棒價值在資安脈絡下確認仍成立＋更正時間點；與第 22 項相扣（保存期限失效＝密碼原文無限期留存）。runner 五項人工補查首腦全數覆核通過，僅③時間點被推翻。登記總表 §3.1 第 78／79、§0 與 §3 計數 94→96、§1 一列、§0.5 與 §4 覆蓋率（jedi-log 移入已掃完＝13 支）、§2.9 🅳 組。FR-097 兩棒收尾 |
| 098 | **A1 設備全鏈＋套件共用骨架（45 檔，jedi） | CM-1814 | ✅ 掃完，stamp verified、候選 2／去重 2、6 票全投**、零漏投零中斷、研究員 1 派 1 回、掃描版本 dirty:false；工具 1 條中等（另 1 條候選三票一致駁回） |
✅ 已驗（09-16）。交付四件齊全（第十一次做滿）。工具那條屬實——設備清冊四支讀取功能（device_route.py:37／:56／:68／:106）只驗登入不驗權限，寫入兩支都有能力點檢查；🔴 首腦改判性質為產品決策題不是漏掉：套件 jedi_asset/plugin/contract.py:27 自陳「read 兩項 BE route 不守（守門只在寫入類）」，首腦已開檔核對該句確實存在——要問決策者「這個決定還算數嗎」。登記總表第 80 項（中），入 🅷 產品決策組 |
| 101 | **J1 意見回饋全鏈＋對外 route 與守門殼（31 檔，jedi-issue） | CM-1826 | ✅ 掃完並驗收（09-16 15:50），stamp verified、4 候選 12 票全投全 3:0、版本 4c208d4、55 分；淨新增 1 條中（第 82 項匯出公式注入），F1／F2 併 CM-1630 位置更新、F3 併 CM-1632（越界 J3）；runner 補查成員名冊端點回全表（表無租戶欄）歸第 7 項、建議補進 CM-1630；工具七重點碰三個、runner 補四個、三項證偽首腦同意 |
✅ 已驗。交付四件齊全（第十二次做滿）** |
| 101 | **J2 插件骨架＋標籤鏈＋隨包 migration＋共用（37 檔，jedi-issue） | CM-1827 | ⚠️ 掃完並驗收（09-16 18:40）：stamp verified 12 票全投，但四條全越界重複 J1、37 檔內零產出**；runner 人工六重點查出 1 條真 bug（§3.2 第 18 項：無部門使用者送回饋被 insert policy 靜默擋，首腦 DEV 重查三事實全對）、更正第 7 項（labels 是碼表剔除）；能力點題入 §7 第 16 項。首腦裁不重掃（骨架六重點已涵蓋） |
✅ 已驗。交付四件齊全（第十三次做滿） |
| 101 | **J3 有改動的整合與附件層回歸（25 檔，jedi-issue） | CM-1828 | ✅ 掃完並驗收（09-16 21:20）：18 票全投、stamp unverified＋findings-refused（第三種型態）、版本 3cc966f8、2h15m；淨新增 0**（範圍內 1 條＝CM-1632 行號更新，3 條越界重複 J1）；🔴 回歸確認四張舊卡一張沒修（CM-1632／1630／1633 一行未改，工具兩次都沒報／1607）；GitLab 側無 ssl_verify=False 同款；附件靜默跳過入 §7 第 18 項待裁。交付四件齊全（第十四次做滿）。FR-101 三棒收尾 |
✅ 已驗 |
| 108 | D1 工具目錄＋租戶憑證＋守門殼＋插件骨架與五支 migration（36 檔，jedi-detection） | CM-1873 | ✅ 掃完並驗收（09-17 13:45）：驗證章無法出示（前一支被砍 session 誤刪產物目錄，非平行掃描所致；首腦改從工作流結果檔獨立核完 6 條候選、18 票）、版本 6119da5、42 分；通過 4 條（工具 F4／F5 併為一條）＝1 高 3 中，淨新增 4 條→總表第 85～88 項。F1 正中卡片重點①；F3 是全系統同寫法的 9 條資料庫隔離規則（含 agent_tasks 與三張授權表），DEV 實查確認母子單位結構真的存在、資料全在子單位，資安與功能兩面都在發作；卡片八個重點工具只碰三個、runner 補五個，首腦推翻其中一項（解密函式在主專案宿主側有呼叫者、不是功能缺口）；交付四件齊全（第十六次做滿） |
✅ 已驗 |
| 108 | D3 執行編排：派工／憑證下發／結果回收／狀態機（17 檔） | CM-1875 | ✅ 五小棒全部掃完並驗收：原 ⛔ 第 5 次（D3b 16 檔 low 單獨跑）也失敗、零產出（09-18 10:38～18:40，十棒研究員全被砍）——「單獨跑」被否定。首腦查工作流日誌坐實死因：工具停滯判定＝研究員 180 秒無工具呼叫即砍，研究員 effort 寫死 xhigh，上下文 25～30 萬 token 時單次思考破 3 分鐘；前四個假設（keep-waiting／並行／檔數／亂讀）全收掉，medium 也無效。決策者裁改切四小棒、每棒 ≤2,000 行含接縫檔：D3-1 結果回收 4 檔 859 行／D3-2 任務綁定 5 檔 1,328 行／D3-3 狀態機存取層 11 檔 707 行／D3-4a·4b 編排服務同檔分上下半各跑一次。啟動指令在 CM-1875 卡尾。D3-1 結果回收 ✅ 掃完並驗收（09-18 20:56）——stamp verified、3 候選 9 票全投、研究員 1 派 1 回零重試（D3 六次嘗試第一次過）、62 分、版本 3ddd7218；通過 1 條（中，agent 自報檔名原樣存成證據、預覽端當網頁執行）→總表第 101 項、駁回 2 條首腦同意；③ 四小項人工查證齊、safe_http_fetch 五道 SSRF 防線是正面案例；交付齊（第十九次做滿）。D3-2 任務綁定 ✅ 掃完並驗收（09-19）——stamp verified、3 候選 6 票全投、研究員 1 派 1 回零重試（與 FR-111 E1 刻意平行跑、兩支皆零重試，「一次只跑一棒」是否放寬仍待決策者裁示）、版本 955e409；通過 1 條（中，換工具時「要掃哪些機器」不重新檢查台數上限，舊超大網段留著跟到新工具、執行時逐台展開吃爆記憶體）→總表第 105 項，首腦補查同一個洞的第二個發生點（換工具連派工清單都不送，同一道檢查一樣被繞過，修法要一併涵蓋）；駁回 1 條（0:3 首腦同意，留作體質改善建議：綁定寫入沒濾掉內部欄位）；「每棒 ≤2,000 行」判準在 D 這條線第二次實證有效；交付齊（第二十次做滿）。D3-3 狀態機與存取層 ✅ 掃完並驗收（09-19 10:16～11:52，run wf_0d92c667-51b）——stamp verified、1 候選 3 票全投、研究員 1 派 1 回零重試、版本 955e409 乾淨；淨新增 0——工具唯一那條落在範圍外（orchestration_service.py:1667），且是總表第 88 項同一缺口，只補行號（不計新發現）；卡片重點④三件人工查證皆無問題，留一條體質改善建議不計數；這棒與 E1、D2-1 三線同時在跑，三線並行首次成立、零重試——「每棒 ≤2,000 行」判準第三次實證有效；交付齊（第二十一次做滿）。D3-4a 編排前半（派工／取消／刪除）✅ 掃完並驗收（09-19，run CLAUDE-SECURITY-20260919-041735）——stamp verified、3 候選 9 票全投、研究員 1 派 1 回零重試、版本 955e409 乾淨、103 分鐘；通過 1 條（中，解密帳密明文另存一份進 agent_tasks.params、無讀取端、無清理機制）→總表第 107 項，另兩條為重複第 88／105 項不計數；首腦三 repo 交叉核對確認刪掉不影響代理程式、且查出 agent_tasks 無清理機制；卡片重點①九支端點守門人工查證皆無缺口；交付齊（第二十二次做滿）。D3-4b 編排後半（回收／狀態／排程）✅ 掃完並驗收（09-19，run CLAUDE-SECURITY-20260919-064027）——stamp verified、3 候選 9 票全投、研究員 1 派 1 回零重試、版本 955e409 乾淨（與 4a 同一份未 commit 變更）、77 分鐘；淨新增 0——工具三條全是舊帳（解密帳密明文落工單表＝第 107 項、換工具繞過台數上限＝第 105 項、改狀態端點守門太寬＝第 59 項＋第 88 項）；唯一實質產出是第 59 項影響面回寫：檢測模組八支改狀態端點（:196／:871／:925／:1007／:1032／:1097／:1127／:1470）吃同一道「任何角色都放行」的守門，viewer 也能發動帶帳密的掃描與刪紀錄；卡片三重點人工查證皆無問題（逾時排程走具名系統身分、列表與通知共用同一份剝除實作、四種回呼競態各有防護）；同檔第二次掃高度重疊，坐實工具端不吃行號範圍；交付齊（第二十三次做滿）。✅ 五小棒全收口（09-19） |
✅ 全已驗 |
| 108 | D2 掃描基準全鏈：上傳／解析／公版 scope／SSRF（30 檔 6,398 行→改切四小棒＋D2-2 再拆兩半） | CM-1874 | 🔵 09-20 D2-1a／D2-3 已驗收、D2-2 改判失敗重切：卡尾 30 檔合計 6,398 行是門檻三倍，依 import 接縫切成 D2-1 上傳入口與封存（5 檔 1,480）／D2-2 基準服務主幹（5 檔 1,632）／D2-3 解析與外抓（4 檔 1,677）／D2-4 分類與版本存取層（16 檔 1,609）。D2-1 拆成 D2-1a（route＋serializer＋dto，1,058 行）／D2-1b（archive＋ref，422 行）——兩支皆已驗收：D2-1b ✅ 09-19（→總表第 112 項；同棒推翻卡片「route 零能力點」前提），D2-1a ✅ 09-20（→總表第 113／114 項）。D2-3 ✅ 已驗收 09-20（→總表第 115 高／116 中，第 115 項是本 arc 第二條高風險：規則包被 cinc-auditor 當 Ruby 樣板執行→後端 RCE）。D2-2（5 檔 1,632）打 17 小時、25 次派研究員零產出，判定看門狗誤殺自動壓縮，已改切 D2-2a（單檔 1,133 行，必須單獨跑）＋D2-2b（4 檔 499 行，待派）。D2-2a ✅ 09-20 驗收→第 117 項（1 條中風險：填網址建掃描基準放行明文 http 且不記指紋）。D2-4（16 檔 1,609）改切兩半——D2-4a（8 檔 772 行）✅ 09-20 驗收（範圍內 0 條，記體質項§3.2 第 30 項）／D2-4b（8 檔 837 行）待派。D2-2b（4 檔 499 行）✅ 09-20 驗收（範圍內 0 條，記體質項§3.2 第 31 項＋§7 第 18b 項補套件 RLS 腳本零 SHARED）。D2-4b（8 檔 837 行）✅ 09-20 驗收（範圍內 0 條，與第 105 項同鏈、獨立重現，記體質項§3.2 第 32／33 項）。D2 八小棒全部收完，CM-1874 改「修正待驗證」。啟動指令在 CM-1874 卡尾「改切四小棒」段（上方版本作廢） |
✅ 已驗 |
| 108 | CM-1876 | ⛔ 作廢（2026-09-16 決策者裁重縮；併入 D1） | — | |
| 109 | V2 填答全鏈：任務問卷／填答／歷史還原／socketio／FR-048 補洞驗證（31 檔，jedi-survey） | CM-1881 | ✅ 掃完並驗收（09-17 15:30）：stamp verified、8 候選 24 票全投、7 通過（六條 3:0、F5 為 2:1）1 駁回、研究員 1 派 1 回（中途停滯重派一次）、版本 90f0ce3、124 分；淨新增 7 條（2 高 5 中）→總表第 89～95 項，無一與既有清單重複。七條同一個病根：FR-048 那道守門只裝在寫入路徑，填答側 6 條寫入全有守門、8 條讀取一條都沒有（0/8）——是 🅰「只驗身分不驗歸屬」這組最乾淨的一次實證。八個重點工具只碰五個、runner 補三個；runner 用 DEV 唯讀實測推翻卡上「join 鏈斷」的懷疑（首腦認同），首腦另查安裝程式確認正式環境服務走受隔離帳號 cm_app（scripts/installer/install.sh:1386），影響範圍確定限同一客戶內部；交付四件齊全（第十七次做滿） |
✅ 已驗 |
| 109 | V1 建題全鏈：問卷／資料夾／分頁／題目／討論＋Excel 匯入＋守門殼與插件（50 檔） | CM-1882 | ✅ 掃完並驗收（09-18 01:30）：50 檔單輪跑四小時、研究員七次被停滯偵測砍掉零產出→決策者裁拆兩輪各 25 檔（73 分／199 分）皆 verified、24 票全投（第一輪 5 候選 15 票、第二輪 3 候選 9 票，每輪各 1 研究員派回）；通過 7 條＝5 新＋2 越界（越界兩條＝總表第 89／90 項重複，不計）→3M 2L 淨新增 5，登記總表第 96～100 項＋§3.2 第 24 項（Excel 匯入暫存檔洩漏）。新根因＝四 route apply=False 關掉驗證（mass assignment）。七重點工具碰 2 個、runner 補 5 個；runner 人工推翻卡上三個懷疑（Excel 匯入 folder_uid 跨租戶／快照跨租戶／守門殼缺 auth_required 靜默），首腦復核維持；⑦ DEV 唯讀實查四張 *_trans 表 RLS 只驗父列存在、靠父表 policy 遞迴擋——鏈通但依賴父表前提（設計陷阱，已寫進總表 §4 🅱）。交付四件齊全（第十八次做滿）。FR-109 兩棒收口 |
✅ 已驗 |
| 111 | E1 容器執行鏈：docker 命令組裝／金鑰下發／容器端程式／log 遮蔽（7 檔 1,476 行） | CM-1947 | ✅ 掃完並驗收（09-19）：stamp verified、4 候選去重 3、9 票全投（三條皆 2:1，反對票一致＝出貨落地版沒裝 docker 跑不到）、研究員 2 派 2 回、版本 955e409 乾淨、135 分、run wf_8dd82c7a-9c9；3 條（1 中 2 低）→總表第 102～104 項；首腦開檔核對三條行號無誤、無改判。runner 首次掃完就停（第九次），催一次後四件補齊。§3.4 兩項「遮蔽只靠字串比對／白名單擋不擋」改「已補查、用詞更正」（真缺口是容器畫面輸出原文落地）。每棒 ≤2,000 行判準第二次實證（零重試）。待決策者裁：①證據內文對 AI 下指令算不算資安題 ②落地版分類功能停用（D4）是否維持——這決定第 103／104 的權重 |
✅ 已驗 |
| 111 | E2 批次分類主幹：上傳／封口／分類／審核／歸檔／清理（2 檔 1,900 行） | CM-1948 | ✅ 掃完並驗收（09-19）：stamp verified、3 候選 9 票全投（1 通過 3:0＝越界 pyproject.toml Nexus 明文＝CM-1634 第四次、不計；2 駁回 0:3）、研究員 2 派 2 回、版本 955e409 乾淨、155 分、run wf_8541a72f-a9b；範圍內零發現。runner 又是掃完就停（第十次），催後補齊且七項人工核扎實——十五支守門逐支對無漏、list_batches 強制帶範圍、state 覆寫塞不進、背景執行緒身分完整；人工三項首腦抽核屬實→第 106 項＋§3.2 第 25＋第 103 補影響面。2 檔 1,900 行 155 分 > E1 7 檔 135 分：行數比檔數準 |
✅ 已驗 |
| 111 | E3 舊 Drive 線：觸發／job 狀態／Drive 讀寫／正解匯入（4 檔 1,781 行） | CM-1949 | ✅ 掃完並驗收（09-19）：stamp verified、9 候選去重 6、18 票全投、4 通過全 3:0、2 駁回、研究員 2 派 2 回、955e409（-dirty 來自套件工作區未版控 .claude/，不在 scope）、91 分、run wf_ef63d0b1-127；4 條（1 高 3 中）→第 108～111，同一條鏈四環節。第 108 本 arc 首條高風險：舊線預覽端點任何登入帳號可讀客戶整個雲端硬碟（首腦核 auth/drive 完整權限、get_file_preview:696-730 零守門、route 只掛登入）。runner 第三次掃完就停（第十一次）催後補齊 0c413f57，七項人工核扎實：單一 job 狀態端點零守門（併 111）、正解匯入零內容驗證（§3.2 26）、上傳客戶硬碟前無二次遮蔽（§3.4）、⑤查無 DB 退回直接讀 Drive 且用呼叫者租戶鑰匙。舊線 legacy 路由仍掛，可裁「刪路由」一次消四條。runner 建議 108 不等 arc 掃完先處理，首腦同意 |
✅ 已驗 |
| 111 | E4 設定與插件殼：分類設定 CRUD／模型碼表／plugin 契約／守門殼（16 檔 1,850 行） | CM-1950 | ✅ 掃完並驗收（09-19）：stamp verified、2 候選去重 1、3 票全投、唯一候選 0:3 駁回（可選型號端點只驗登入——回的是廠商名字不含金鑰、租戶取自登入脈絡、前端專案成員畫面依賴它；首腦核 ai_provider_key_resolver.py:184-199 屬實）、研究員 2 派 2 回零重試、955e409（-dirty 同前）、69 分、run wf_ea23b9f1-1a0；範圍內零資安發現。runner 首次四件一次做齊（連總表 §1／§0.5／§8 都自登，首腦核無誤）；七項人工核：四支 CRUD 全掛 _require_settings_manager（首腦核 :154/:168/:199/:216）、25 支 add_resource 全經 R() 包裹（首腦 grep 核）、RLS 讀放行 ROOT 寫不放行、apply=False 0 命中、金鑰入口 7 處無 log。首腦另登 §3.2 第 27（provider_default／model_default 寫入不讀，_resolve_run_params:1315 核實）。金鑰解析鏈本體在主專案，本棒答不了「解析鏈守不守」 |
✅ 已驗 |
| 111 | E5 邊界層：request schema／查詢預設／repo 過濾／RLS policy（12 檔 842 行） | CM-1951 | ✅ 掃完並驗收（09-20）：stamp verified、6 候選 18 票全投、4 通過 2 駁回、研究員 2 派 2 回、955e409、run wf_9073608f-905、5h32m（五棒最久，研究員追出範圍去主專案搜呼叫者被停滯偵測砍五次）；範圍內零發現——4 通過全越界＝E3 第 108～110 重複（第二組獨立面板重現、反證 E3 可信）、範圍內唯一 F6 0:3 駁回（首腦復核 batch_id 建立即填）。runner 四件齊、六項人工核扎實（RLS 子表自帶 tenant_id NOT NULL、apply=False 0 命中、21 查詢欄位全空、分頁 200）。FR-111 五棒全部掃完，2026-09-20 arc 收口（SUMMARY 已出、母卡 Done）。教訓：本體小接縫發散的棒，接縫事實先查好寫進卡而非再切小 |
✅ 已驗 |
| 098 | **A2 資訊系統全鏈（42 檔，jedi） | CM-1815 | ✅ 掃完並驗收（09-16），3 條→淨新增第 81 項（低）；runner 四件未交首腦補（第八次）。FR-098 兩棒收尾** |
— ⚠️ 驗收重點：① 工具有沒有碰卡片五個重點（A1 那棒工具只碰一個）② A1 已查完的四件有沒有被重報。卡尾啟動指令原為舊版 30 檔清單、首腦裁用 42 檔版並已在卡尾貼更正說明（少掉的 12 支裡 plugin/assembly.py 與 plugin/runtime.py 不能少，本卡重點⑤共用骨架守門殼就在 assembly 那支） |
FR-077 母卡 CM-1591（2026-09-07 建）。2026-09-08 決策者裁：FR-077 暫停，改從其他 jedi- 套件開始掃。 R1 已完成並驗收（7 條，4 張修正卡＋1 補掃棒已開），其餘四棒（R1b／R2a／R2b／R3）卡都開好了、範圍與重點都寫死在卡裡，隨時可以續*，但目前不派。修正卡 CM-1595～1598 已隨修正線處理（見下方修正卡表）。
FR-078 母卡 CM-1602（2026-09-08 建）。兩棒都已完成並驗收，報告在 docs/features/FR-078-2609-notification-security-scan/。
FR-079 母卡 CM-1609（2026-09-08 建，決策者指定下一支掃 jedi-bulletin）。兩棒已掃完並驗收（2026-09-09）。文件在 docs/features/FR-079-2609-bulletin-security-scan/。
🔴 FR-079 的規劃修正了排名表對 jedi-bulletin 的低估：排名表把它列在「讀取展示型、攻擊面小」（29 檔／847 行），但那個評估只看了套件那半邊。首腦讀碼後發現套件本體確實只有無守門的 CRUD，而「誰能看到哪一則公告」的判定整個在主專案宿主接線的 33 檔裡（route 守門、部門過濾、動態查詢組裝、tenant scope、dashboard 旁路），且邏輯繞——十個重點有八個落在宿主側，故建議先跑 B2。這與 FR-077 R3 的形狀相同（套件把安全決策外包給宿主）。接手者的教訓：排名表的檔數與風險評估都只涵蓋套件本身，不含宿主接線；排下一支時要先問「這支有沒有宿主那一半」。
FR-081 母卡 CM-1612（2026-09-09 建，決策者指定掃 jedi-issue）。⚠️ 本 arc 原編為 FR-080，2026-09-09 因與「jedi-* 套件整併與服務化路線」同日撞號而改為 FR-081（決策者裁：整併 arc 先開且已有 design／STATE／LOG，保留 FR-080；本 arc 當時只有一支 README，依登記表「最大整數號 +1」規則改號）。七張卡的卡號未變（CM-1612～1618），只改標題前綴；Notion 連結中的 FR-080 只是網址 slug。六棒已全部掃完並驗收（2026-09-10）。文件在 docs/features/FR-081-2609-issue-tracking-security-scan/。
🔴 FR-081 規劃時證偽了套件檔頭的一句自陳，這件事會影響往後每一棒：jedi_issue/api/__init__.py:11-13 自稱「GitLab／GitHub 整合目前產品沒有在用，約佔套件 58%」——首腦從宿主端查證是錯的（app/feedback/service/feedback_service.py 156／171／210／222／246／252 六處實際呼叫，IssueProviderCode 統計 LOCAL 9／GITLAB 4／GITHUB 3）。這是工具已知盲點二（會被程式碼註解說服）的教科書形狀——研究員讀到那段 docstring 就會跳過 58% 的程式碼，而那半邊恰好是風險最高的（外部連線＋憑證）。六張子卡每張都帶了這個警告。
首腦讀碼時已看到一個現成的洞（未經面板驗證，寫進 I1 卡當錨點）：jedi_issue/infra/github.py:22 與 infra/issue/adapter/github/github_issue_adapter.py:43 兩處都是 Github(auth=auth, per_page=100, timeout=10, verify=False)——帶著存取權杖走不驗憑證的 TLS，而這個模組的 PAT 外洩過一次（CM-1573 已 Done）。首腦初判 HIGH。本專案同款病第四處（前三：CM-1560 LDAP／CM-1565 Redis／CM-1606 SMTP）。
🔴 決策者裁：FR-081 一次只派一棒（09-09），理由是避免長跑中途撞額度導致結果不完整（FR-079 B2 跑 14 小時、撞兩次額度、還踩到併檔陷阱）。每棒獨立驗收完才派下一棒。合理停損點在 I3 之後（I1+I2+I3 共 70 檔已涵蓋絕大部分風險面），但沒跑完六棒不能宣稱「jedi-issue 掃過了」。
⚠️ I5（40 檔）是刻意的邊界測試：每棒 ≤30 檔是實測邊界，I5 略超是因為 app/ 與 domain/ 拆開會把「用例編排」與「業務規則」切在接縫上（手冊第一節「不要按 DDD 分層水平切」）。若面板沒跑完，不要重跑整棒——回報首腦決定是否拆成 app(22)＋domain(18)。這一輪的數字會決定往後 30～40 檔區間的切棒尺。
🔴 FR-081 已收口（2026-09-10）：六棒全數掃完並驗收，面板六棒全部完整跑完、零漏投、零不完整、一次都沒撞額度——這是本專案六個掃描 arc 以來第一次。19 條發現去重歸成 6 張修正卡 CM-1629～1634（1 HIGH／4 MEDIUM／1 LOW），另 3 條併入 CM-1607。原六張卡當時歸檔，09-21 起改照 SUMMARY 派工，現已處理（CM-1629→總表 CM-2049、CM-1630→FR-114.1-7、CM-1631→CM-2051、CM-1632／1633→CM-2066、CM-1634→鎖定檔入版控）。 決策者要看的總結在 docs/features/FR-081-2609-issue-tracking-security-scan/SUMMARY.md。
三件待決策者裁：① CM-1629（DB＋Redis 密碼散 249 檔）判 HIGH 不降，要不要換密碼？STG／POC 屬環境異動要明示放行；② Google OAuth 用戶端密鑰要不要現在轉（這把不是每套安裝各自產生的，與 JWT／DB 密碼不同）；③ Nexus 上 jedi_issue 0.0.14／0.0.15 兩個 wheel 是否已下架（CM-1573 的尾巴，程式碼查不到）。
FR-075 母卡 CM-1546、FR-076 母卡 CM-1566 本身狀態都還是「Not started」——那是母卡自己的狀態欄，不代表子卡沒做；子卡才是實際進度。母卡收 Done 的時機是全部子卡（含 S6/S7 重跑、CM-1559）都收尾之後。
掃描 prompt 見 skill 第六節，換卡號與檔數。
docs/security-report/SUMMARY.md 為準）| 卡 | 修什麼 | 嚴重度 | 狀態 | commit |
|---|---|---|---|---|
| CM-1575 | 忘記密碼端點外洩重設憑證 | 🔴 CRITICAL | ✅ Done | jedi-iam a9edf1d |
| CM-1557 | MFA 驗證碼無次數限制 | HIGH | ✅ Done | jedi-iam b51b914, FE d3283e5 |
| CM-1560 | LDAP 三洞（bind／filter escape／TLS） | HIGH | ✅ Done（TLS 項退回重做過一次） | jedi-iam 9b353ee→20c6713, BE 3ad876ae→f503fba3, FE 78903b2 |
| CM-1562 | 綁定外部身分無本人檢查 | HIGH | ✅ Done | jedi-iam 76a8c2d |
| CM-1561 | Google 登入殼 | HIGH | ✅ Done（決策者改裁：關閉不拔除） | jedi-iam d28e364, BE d08bc34c |
| CM-1576 | 自助 profile 自我提權 | HIGH | ✅ Done | jedi-iam 7cf3cf2 |
| CM-1572 | 驗章前無界解壓縮 | HIGH | ✅ Done（③ MAX_CONTENT_LENGTH 由 CM-1587 承接，已裁 50MB） | jedi-integrity 同款兩處一併修 |
| CM-1579 | 停權可被換照解除 | HIGH（SaaS） | ✅ Done（方案 A） | jedi 8f9155a, BE a039aa28 |
| CM-1558 | Turnstile 缺金鑰 fail-open | MEDIUM | ✅ Done | jedi-iam 2bf2003, FE 52a40c4 |
| CM-1559 | RLS fail-open | MEDIUM，影響面最廣 | ✅ 已修（卡拆 CM-1787／1788，FR-094 CM-1788 無身分進 session_scope 改 fail-closed；總表 M04-2，1.21.0 出貨） | — |
| CM-1563 | 帳號枚舉統一 401 | MEDIUM | ✅ Done | jedi-iam 6a13d96 |
| CM-1564 | LDAP 連線測試改位址強制重輸密碼 | MEDIUM | ✅ Done | BE d4d1b0e4, FE 0f1d0ed |
| CM-1565 | Redis TLS 不驗憑證 | MEDIUM | ✅ Done | jedi-iam 4c7579c, BE 83c5b118 |
| CM-1573 | jedi-issue PAT 外洩處置 | MEDIUM | ✅ Done（決策者裁 token 早已註銷，跳過後台再確認） | jedi monorepo ed62d8a |
| CM-1577 | update_user 改密碼不驗強度 | MEDIUM | ✅ Done | jedi-iam eaa8de7, BE b67e9cdd |
| CM-1578 | Excel 上傳目錄用未驗證 login_name | MEDIUM | ✅ Done | jedi-iam 608d077 |
| CM-1580 | 跨租戶重複用照部分唯一索引 | LOW | ✅ Done（DEV 已建索引；STG/POC 套 migration 等上版） | — |
| CM-1581 | build 守門路徑 bug | 小 fix | ✅ Done | 4b527704 |
| CM-1582 | 客戶包公鑰白名單 | — | 📋 裁定記錄不修（總表 M18-7：交付首位客戶前，出貨版改只認正式簽發站公鑰；原卡作廢） | — |
| CM-1583 | LC 開通端點防猜＋計數表＋log 遮蔽＋補發復活（七項） | HIGH | ✅ Done（⑦ 補發語意採 B 案：產新碼作廢舊碼） | LC a68200c |
| CM-1584 | LC 登入 next 開放導轉 | MEDIUM | ✅ Done | license_center 58c0e98 |
| CM-1585 | 角色讀取端點無守門（S5 F1） | MEDIUM 偏 HIGH | ✅ Done | jedi-iam 4984e1e, FE 2268571 |
| CM-1586 | 失效角色算成有效（S5 F2） | MEDIUM | ✅ Done | jedi-iam dbb96aa, BE 7097774 |
| CM-1587 | 全站請求 body 上限（CM-1572③ 衍生） | MEDIUM | ✅ Done（決策者裁 50MB） | BE f867540f+2ea76ef7, FE 21157820 |
| CM-1588 | 租戶／部門部分更新清空上層歸屬＋建部門漏記 created_user（S6 衍生） | MEDIUM | ✅ Done | jedi 1a33307 |
| CM-1589 | 部門／租戶／使用者讀端點補 .read 守門（S6 F1）；UserRoute.get 本人放行被擋時改回 403 |
MEDIUM | ✅ Done | jedi 09c8e54、8aa6f06 |
| CM-1595 | FR-077：agent 控制面四端點不驗身分（F1+F2+F3+F5）＋nginx 連帶 | 🔴 CRITICAL（2026-09-16 曾裁降 HIGH、同日撤銷回到 CRITICAL——第十四任首腦開檔比對 fc1cadb 前後：舊版也從未採信自報租戶，兩版都是拿請求裡的 agent 編號查列、該列租戶是什麼就用什麼；那筆修改收緊的是「執行身分」（超級管理員→該租戶機器身分），冒充別家 agent 的路一樣走得通，三個升級條件一個都沒消失） |
✅ 已修（CM-2052，總表第 1 項，1.21.0 出貨；原卡 09-21 作廢） | — |
| CM-1596 | FR-077：健康檢查 SSRF（F4） | MEDIUM | ✅ 已修（1.21.1 CM-2370，總表 M01-2；原卡作廢） | — |
| CM-1597 | FR-077：enroll token 永久有效＋重註冊接管（F6） | MEDIUM | 🚫 裁定不修（決策者 10-01，總表 M01-3；SaaS 上線前再評估到期或一機一碼；原卡作廢） | — |
| CM-1598 | FR-077：jedi-common/.env 受版控（F7 越界） |
LOW | ✅ 已修（jedi 套件庫 f6459efd 撤出版控，總表 M01-4；原卡作廢） |
— |
| CM-1605 | FR-078：測試信端點把平台 SMTP 密碼送到呼叫端指定的主機（N2 F1） | 🔴 HIGH | 🚫 裁定不修權限面、程式面已加強（CM-2111：位址或埠與存著的不同時不沿用密碼，總表 M16-1；Discord 部分 1.21.1 CM-2371） | — |
| CM-1606 | FR-078：SMTP adapter 兩洞——密碼寫進 log ＋ starttls 不驗憑證（N1 兩條） | MEDIUM×2 | ✅ 已修（CM-2111，總表 M16-2／M16-3） | — |
| CM-1607 | FR-078：清掉版控內殘留的已撤銷金鑰（conversation-history 13 檔＋Trivy 報告 2 檔）；並評估 CI 加秘密掃描 | 清理 | ✅ 已修（CM-2048，commit e8e134a4e，版控殘留字串已清） |
— |
| CM-1608 | FR-078：拔掉腳本內硬編的 POC DB 密碼與 blsadmin 密碼（N2 F4／F8）。決策者裁測試機專用、密碼不需更換，只做程式碼衛生 | 衛生（原判 MEDIUM×2） | ✅ 已修（CM-2048，總表 M16-7／M16-8；密碼已換發） | — |
FR-078 四張（CM-1605～1608）終局：當時刻意不派（PM 統一安排），09-21 起改照 SUMMARY 派工，現已全數處理（見上表）。
修正 prompt 見 skill 第六節。修正卡 runner 用 Sonnet 5 即可（S5/S6/S7 掃描棒本身才需要 Opus 1M）。
🔴 **報告與回報一律寫白話**（決策者 2026-09-10 要求，硬規則）：
讀者有兩種——PM（不懂程式）與新手工程師（懂程式但不熟這個 codebase），
兩種都要看得懂。規則在 .claude/skills/security-scan-lead/SKILL.md 第十節，
動手寫之前先讀那一節。範例抄 docs/features/FR-081-2609-issue-tracking-security-scan/。
每條發現必須回答五個問題：
① 這是什麼問題（一句話，不帶術語）
② 出事會怎樣（具體後果，不是「可能有安全風險」）
③ 要先有什麼才打得到（讓人判斷急不急）
④ 在哪裡（檔名:行號，照著就能打開）
⑤ 怎麼修（具體到函式，不是「加強驗證」）
報告順序不可調換：一句話結論 → 這棒在檢查什麼 → 總覽表 → 每條詳述
→ 可信度分兩層 → 執行概況放最後（那是數字，不是結論）。
術語不是禁用，是出現時必須當場解釋，寫成
「RLS（就是「每個客戶只能看自己資料」的資料庫隔離機制）」。
你的回報也一樣：開頭先講「掃完了，找到 N 個問題，最嚴重的是 X」，
不要先講派了幾個 agent、跑了多久。| 事項 | 裁決 | 日期 |
|---|---|---|
| 掃描工具 | 用 claude-security plugin，不改人工審 | 09-05 |
| 切棒方式 | 按業務模組垂直切，不按 DDD 分層 | 09-05 |
| 模型 | runner 主 session Opus 1M（限 S4 以上檔數多的棒） | 09-06 |
| Google 登入殼（CM-1561） | 改裁：關閉不拔除（原裁拔除，第二任首腦改） | 09-06 |
| 停權繞過（CM-1579） | 改裁：現在做，方案 A（原裁綁 SaaS 上線暫緩，第二任首腦改） | 09-06 |
| 三環境硬編公鑰（CM-1582） | 維持暫緩，綁正式 LC；守門 bug 先修（CM-1581，已 Done） | 09-06 |
| CM-1575 上版時機 | 不做 nginx 臨時節流；等 CM-1583 完成後與 LC 修正一起上版 | 09-06 |
| CM-1583 ⑦ 補發語意 | B 案：補發產新序號、舊碼作廢 | 09-06 |
| CM-1587 body 上限 | 50MB（因 CM-1583 簽章 manifest 近 1MB，runner 由 64KB 改 16MB 再由決策者定 50MB） | 09-06 |
| CM-1560 TLS 設定放哪 | 改裁：設定頁欄位（verify_cert/ca_cert_pem），不用 .env 變數（原第一輪做成 .env，退回重做） | 09-06 |
| CM-1573 撤銷確認 | 決策者裁 token 早已註銷，跳過後台再確認，直接處理 dist/Nexus 殘留 | 09-06 |
| 產品時程 | 第一版是落地版，SaaS 預留。修正優先序判準見 docs/claude/memory/project_first_release_is_host_saas_reserved.md |
09-06 |
| Memory 共享 | 搬進 docs/claude/memory/ 入版控 |
09-06 |
| FR-077 切棒 | 三棒（R1 身分 42 檔／R2 任務＋檔案 29 檔／R3 主專案宿主接線 17 檔）。切三棒而非兩棒，是因為 agent 鏈被 repo 邊界切成三段而 scanRoot 只能指一個目錄；R3 檔少（17 檔 881 行）但密度最高——套件把所有安全決策外包給宿主，真正的答案在那 17 檔裡 | 09-07 |
| FR-077 STATE | 共用本檔，不另開 | 09-07 |
| FR-077 F1 嚴重度 | 升 CRITICAL（原 runner 判 HIGH）——無認證＋跨租戶＋洩漏客戶第三方憑證三條件全中 | 09-08 |
| FR-077 修正卡切法 | F1+F2+F3+F5 併一張（CM-1595，同一套 agent 認證機制）；nginx 併進當「連帶」不另開卡（它不能當唯一防線） | 09-08 |
| 每棒檔數上限 | 09-08 | |
| 報告格式 | 開頭必須是白話總覽表（# / 嚴重度 / 這是什麼問題（白話）/ 出事會怎樣 / 要先有什麼才打得到 / 位置 / 修正卡）＋「這份結果的可信度」段。R1 報告已改成此格式可抄 |
09-08 |
| 🔴 FR-077 暫停 | 改從其他 jedi- 套件開始掃*。理由：決策者判定「掃出來都不能用」——面板全滅使工具正式產出為空、覆蓋率無法宣稱，靠人工補核不可持續 | 09-08 |
| FR-077 F1 嚴重度 | 升 CRITICAL（無認證＋跨租戶＋洩漏第三方憑證三條件全中；UUID 業界從不當秘密） | 09-08 |
| FR-077 A／B 併卡 | F1+F2+F3+F5 併一張（CM-1595），同一套 agent 認證機制、共用測試，避免兩個 runner 各寫一套 | 09-08 |
| FR-077 nginx | 併進 CM-1595 當連帶，不另開卡——加分項非主修法，獨立開卡會誤以為補了 nginx 就算修好；驗收條件明寫應用層 fail closed 為必要 | 09-08 |
| FR-077 補掃 | 開 R1b（CM-1599）——密碼學核心（CA／JWT）零發現在面板未跑下不可信 | 09-08 |
| FR-077 R2／R3 | 現在就派——掃不同檔與本批決策無關，R3 結果回饋到 CM-1595 | 09-08 |
| FR-078 選 jedi-notification 起頭 | 決策者裁「先從真的獨立的開始掃」——不從排名第一的 jedi-common 起頭，先拿一支耦合少、範圍天然乾淨的套件把方法跑順 | 09-08 |
| 🔴 修正卡全部先不派 | PM 打算收集所有掃描結果再統一安排修正。FR-078 四張（CM-1605～1608）開卡是歸檔不是派工；FR-077 四張同理維持待派 | 09-08 |
| FR-079 F12（JWT 金鑰外洩） | 降為衛生類、併入 CM-1607，DEV 金鑰不更換。決策者問「安裝時是不是動態產生」，查證 install.sh:1252 每套安裝各自 openssl rand -base64 32——外流的只是開發機那把，不是客戶的。首腦原主張升 HIGH 作廢 |
09-09 |
| FR-079 F15（installer 原廠密碼） | 維持記錄、暫不調整。現況確認每套安裝種同一組 super admin 密碼且不強制首登改密；本 arc 不開卡不派工，留待日後一併處理安裝期憑證策略 | 09-09 |
| 🔴 不重寫 git 歷史 | .env.test 事件的處置。金鑰撤銷是有效處置；重寫歷史會改動所有 commit hash、影響每一個有 clone 的人，而對已散出六個月的內容毫無補救效果。理由詳見 commit 5746cef1 |
09-08 |
| 🛑 FR-095 停在三輪 | H2（CM-1783）不掃了，P3～P5 一併停，卡留「未開始」不動。理由：剩下三棒要問的問題前三棒已答完（同型根因第三次出現），同樣時間換去掃別支套件更有價值。被排除的：照原計畫跑完七棒——邊際收益遞減，不是範圍畫錯 | 09-15 |
| 🔴 空條件回全表要在共用底層擋，但分兩步 | 第一步先盤點全站哪些地方是刻意要查全表的（碼表、排程、管理員總覽），把這些地方改成明確標記；第二步才動共用底層。兩步之間可以隔很久，第一步先做不浪費。 被排除的：直接改底層——不知道哪些呼叫者是刻意送空條件，直接改會打壞正常功能。第一步的起點已備妥：首腦本棒做完的 17 支盤點清單（見下「空條件回全表：全域盤點第一版」段） | 09-15 |
| detection／remote-agent 解除暫緩 | 原暫緩理由是「套件整併討論還沒定」，現已不再是阻礙。連帶 CM-1595（全計畫唯一一張 CRITICAL）可排進計畫、四張補掃卡隨時可派。⚠️ 總表 §6 第 12 項尚未改，下一任補 | 09-15 |
| 下一支掃 jedi-system-core（＝FR-096） | 不掃遠端代理程式補掃。決策者原話「先從小的開始掃」 | 09-15 |
| FR-096 三棒一次只派一棒 | P1 → H1 → P2 按順序，每棒獨立驗收完才派下一棒（沿用 FR-081 起的串行紀律） | 09-15 |
| 🔴 第 74／75 項新增第四個修法方向 | 決策者在另一個 session 補的：只給客戶自己的第一層租戶（總部）改，客戶底下的子公司／部門不給；root 租戶維持不開放。首腦已同步到總表與問題總表兩份文件，並註明該案套到日誌轉送表同樣要先改表結構（那張表也只有全域一列，tenant_id 寫死 NULL） |
09-16 |
| 掃描不能排程無人值守 | 啟動指令的成本承認句只認使用者本人在該 session 打的字，排程送派工 prompt 後 runner 會停在「檔數已對上」等人，半夜排程等於白排。要無人值守得連啟動兩行一起排、且在 runner 回報之後送——目前不做 | 09-16 |
| **平行派工（兩帳號各一棒） | 決策者 2026-09-16 裁可：範圍不重疊、不同 scanRoot、各用不同帳號**（額度分開）才並行；同帳號仍一次一棒；R2a／R2b 刻意重疊不可並行。首派 J1（runner）＋R1b（runner2） | 09-16 |
| 🔴 修正卡一律不開，等全部掃完分類分析後統一開 | 決策者 2026-09-17 重申並加理由：類似問題分散開卡會各修一半、修了又長回來；先把 102 項按同型根因分類分析，再統一開修正卡。FR-077 四張既有卡（CM-1595～1598）維持待派、不再新開；第 84 項公開站洩密屬「動作」（換密碼清檔）不屬開卡 | 09-17 |
| 🔴 修正卡全部不開、只記錄 | 決策者 2026-09-16 重申，與既有裁定一致（PM 收集完所有掃描結果再統一安排修正）。接手者不要把未開卡的問題當成「漏派的待辦」 | 09-16 |
| 🔴 掃描一次只跑一支、不再兩帳號並行 | V1／D3 兩案實證：並行時研究員被停滯偵測砍掉重開、零產出（V1 50 檔單輪七次全滅，D3 第 3／4 次同死法；D3 停掃讓 V1 單獨跑後，V1 拆兩輪都順利完成）。覆蓋 09-16「平行派工（兩帳號各一棒）」那條裁定 | 09-17 |
| **🔴 三條線並行（三個帳號各一支） | 決策者 2026-09-19 裁：D3-2 與 FR-111 E1 幾乎全程並行（重疊近兩小時）兩支都 verified、D3-2 零重試，「並行」不是死因；下午加開第三個帳號，D 線兩條（D3 小棒＋D2 小棒）＋E 線一條同時掃**。前提：①每支都在 2,000 行門檻內 ②各線用不同帳號（額度分開）、同帳號仍一次一支 ③範圍不重疊。覆蓋 09-17「一次只跑一支」裁定。樣本仍少，再撞停滯砍掉就退回一次一支 |
09-19 |
| 修正一律等全部掃完再統一開卡，三個例外（RUN_ENV=prod／第 39 條設定 API 吐帳密／第 84 項公開站洩密）也不先做 | 決策者 2026-09-19 裁：快掃完了，不分批。⚠️ 09-20 續記：掃描已於同日收口，「快掃完了」的前提已消失，待決策者重新確認 | 09-19 |
| **🛑 D 線做完就停，其餘套件不再掃（09-20 決策者裁） | 上游 bug #92424 讓大範圍掃不完。D 線（FR-108）剩四小棒照派收完**（D2-2a 跑中、D2-2b／D2-4a／D2-4b 待派，指令在 CM-1874 卡尾），FR-108 收口後掃描 arc 結束——jedi-oscal-v2 兩半、三支小接線、jedi-compliance-audit 全部不開卡不掃。接手者不要把 §5「下一批」當待辦；剩下的工作是分類與開修正卡（決策者 09-17 裁「全掃完統一開」，「全掃完」現在＝D 線收完）→ 09-21 決策者改裁重啟掃描，此列作廢 | 09-20 |
| **🔄 掃描重啟（09-21 決策者裁） | 範圍決策者未指定。首腦建議順序：① jedi-oscal-v2 主專案側接線 191 檔（122 支入口只驗登入零功能權限、含 Word／Excel 上傳匯出，讀碼就看得到問題）→ ② 三支小接線合一棒（問卷 10／檢測 14／日誌資產議題約 21）→ ③ jedi-compliance-audit 166 檔＋接線 → ④ jedi-oscal-v2 套件本體 364 檔（無入口、風險型態不同，排最後）。task-platform 剩餘 108 檔維持 09-15 裁停不動。切棒判準照手冊第一節（安全線約 1,000 行或單檔 60KB、單檔棒優先、三帳號各一支）。開卡前先派 sonnet subagent 盤點：切棒＋每棒 wc -l／KB＋每棒重點看什麼，首腦核完再 scripts/notion_create_case.py 一次建母卡＋子卡；沒卡不派**。plugin 升不升 0.11.0 等決策者裁（09-20 記錄：新版只改報告格式與發現 ID，看門狗未動） |
09-21 |
| 同一掃描範圍失敗一次就換變數，不重試同一設定 | D3 同一招試四次零產出（09-17）；每步只改一個變數（範圍→強度→工具），最多四輪就有結論 | 09-18 |
| 🔴 研究員死因更正：看門狗誤殺「自動壓縮」，上游 bug #92424 | 決策者 2026-09-20 問「為什麼一直掛、是不是掃描方式不對」，首腦查社群坐實：anthropics/claude-code#92424——研究員上下文到 18～35 萬 token 自動壓縮、壓縮 150～205 秒零輸出、看門狗 180 秒沒輸出就砍。掃描方式沒錯，是工具 bug，無設定可調。 行數只是 token 的粗略代理：D2-2 1,632 行（主檔 docstring 23%、中文 4,600 字）25 隻研究員 17 小時零產出，D3-4 2,498 行單檔卻跑完。新規則：這類套件安全線約 1,000 行或單檔 60KB；單檔棒優先於多檔跨層；單檔大棒跑時別並行；看 journal failed 數第二個就停。完整表在首腦手冊第一節。09-20 續查：issue 仍 Open、無 PR、Anthropic 零回覆；本機 Claude Code 2.1.278 仍重現（D2-2 就是在這版死的）；plugin 官方已出 0.11.0（我們裝 0.10.2.3），diff 29 檔只動報告格式／SARIF／發現 ID，研究員與看門狗一行沒動、升級無助，D 線收完前不升。回報者提的 CLAUDE_CODE_AUTO_COMPACT_WINDOW 可推後壓縮點（無官方文件）——D2-2a 先不加，若再死才當下一輪唯一變數 |
09-20 |
| 每棒總行數 ≤2,000（含接縫檔），不只數檔 | 工具停滯判定＝研究員 180 秒無工具呼叫即砍（寫死改不了）、研究員 effort 固定 xhigh；上下文 25～30 萬 token 時單次思考破 3 分鐘。D3 五次失敗坐實。開卡時每棒先 wc -l。D2-1 1,480 行五檔六次被砍，D3-4 2,498 行單檔跑完：跨檔數可能比總行數更關鍵，樣本不足待累積 |
09-18 |
現況（2026-10-01）：下列 9 項皆為歷史當下的待裁清單，已全數結案——CM-1559 已修（FR-094 CM-1788）、S7 已重跑驗收、jedi-iam 修正已隨 1.21.0 出貨（上版時機已過）；掃描線 09-28 收尾，本 arc 無待辦。
POC 資料庫密碼與 blsadmin 管理員密碼需更換 → 已裁決（2026-09-08）：不需更換。決策者裁「那是自己的測試機，密碼跟部署的無關」。原本判為「憑證還活著、最急」的推論作廢，CM-1608 降為衛生類、優先序低（仍要把硬編改成無 default 的環境變數，理由是那兩支 os.getenv(..., "<真密碼>") 的 pattern 本身錯誤，會靜默使用寫死值）。接手者不要再拿這件事去問決策者
下一支掃哪個套件 → FR-079（jedi-bulletin）兩棒已完成並驗收；FR-081（jedi-issue）六棒已開卡待派（CM-1613～1618，決策者 2026-09-09 指定、裁一次只派一棒）。再下一支仍看排名表：首腦建議 jedi-common（92 檔，全套件地基，至今無算數掃描）或 jedi-integrity（20 檔，CP 值最高）
CM-1559 修法方向——盤點已回寫完整（見下方「CM-1559 盤點結果」段），等裁「先下第二刀再下第一刀」這個順序可不可以、以及三類分流的範圍
S7 要不要重跑（核心範圍 middleware／domain service／plugin.py 預設值／login_log／ui_route 從未被真正掃到；重跑要收窄掉 infra/adapter/authenticate_adapter/ 與 user_auth_provider_service.py 避免再度越界重複 S1）
上版時機：jedi-iam 已累積 13 張 Done 修正卡待發版，何時把 jedi-iam／jedi-license-runtime／license_center 一起發版上 STG/POC
CI 加秘密掃描——N2 報告的建議（gitleaks／trufflehog 之類擋在 pre-commit 或 CI）。已寫進 CM-1607 要求 runner 評估後回報，但新增基礎設施要決策者裁才動
detection／remote-agent 要不要繼續暫緩 → 已裁（2026-09-15）：解除暫緩。原暫緩理由「套件整併討論還沒定」已不再是阻礙。連帶 CM-1595（全計畫唯一 CRITICAL）可以排進計畫、四張補掃卡隨時可派。總表 §7 第 12 項已同步標「已裁」。
共用底層「送空條件就回整張表」要不要在底層擋 → 已裁（2026-09-15）：要擋，但分兩步。第一步先盤點「刻意要查全表」的地方並改成明確標記，第二步才動底層；兩步之間可以隔很久。第一步的起點是下面「空條件回全表：全域盤點第一版」那 17 支清單，可以直接用。
（原第 5 條「CM-1595 要不要跟著停」與原第 6 條「下一批掃哪些套件」已由決策者用行動回答：改掃其他套件、修正卡一律不派由 PM 統一安排。）
這是上面第 8 條裁定「第一步盤點」的成果，做完了但還沒正式登記。下一任可以直接拿來用，不必重掃。
project_participants、task_assignees、以及控制項層那批參與者表（RLS 全關、0 條規則）。TenantScopedMixinModel，所以在 model 檔案裡 grep 不到 tenant_id，但隔離是有的。不要因為 grep 不到就判定沒隔離。system_menus 查過確定不是漏洞：DEV 實查 74 筆全是碼表（USER_STATUS／ENABLE_STATUS／ANS_TYPE 這類下拉選項），沒有客戶資料也沒有個資，沒有隔離是正確的。盤點做完了，卡內容比本段詳細（三類分流修法、逐處清單），這裡只留首腦要決策者看的三件事：
not tenant_id 這個條件）再下第一刀（elif is_pg 改成 fail-closed）。理由是第二刀的爆炸面只有 signed_token 一條路徑，改壞了立刻看得出來、範圍可控；第一刀動的是全站 session 進入點，要在第二刀確認無事之後才敢下。X-Tenant-ID: 0 這條路已經被 FR-069.16 擋死了——context.py 當時加了隸屬檢查。根因（fail-open）仍然在，但已不是可利用的漏洞，因此 CM-1559 的優先級可以降。這件事會改變決策者對「要不要現在動全站 session 進入點」的判斷，所以放在這裡。compliance.projects、workflow_executions、workflow_templates 三張表有 RLS policy 但 RLS 沒啟用，而且 projects 的 policy 沒有 super admin 分支。現在不會出事（policy 沒生效），但哪天有人打開 RLS 會直接壞——是顆定時炸彈，與 CM-1559 主題不同，建議獨立開卡。被排除的三個方案也記在卡內，接手者要改方向前先讀，不要重走。
.env.test 事件（2026-09-08，不屬掃描棒次但與 N2 的 F2／F3 直接相關）決策者自己發現 .env.test 進了版控，同一天工具在 N2 的密鑰專項也獨立掃到同一件事（見「收穫三」）。
查證結果：不是 .gitignore 沒設好，是 .gitignore 裡的 !.env.test 例外刻意放行的。當初立論是「這是不含真實憑證的範本」——但這個立論從 2026-03-08 首次進版控那一刻起就不成立，檔內一直有真值。2026-07-24 的 99ff37af 曾清理過一次，但只換掉 Telegram／Discord 兩項，其餘留著。工具另查出該檔存在於 origin/main 與另外十一個推送過的分支。
處置：
git rm --cached（本機檔保留，測試照跑）.gitignore 的 !.env.test 例外.env.test」，實際上全 repo 沒有任何程式碼載入它5746cef1／56c1dc43，已 push判準已寫進 .gitignore 註解（給未來的人看）：檔名長得像範本不代表內容是範本，看的是這一刻裡面的值。
pyproject.toml pin → 重出 image → 部署 STG → 部署 POC判斷「.env 變數」還是「設定頁欄位」，看誰要調它、調的頻率：客戶自助能改的功能設定（如 LDAP 是否驗憑證、憑證內容）走設定頁欄位，跟著 tenant/連線設定走；只有部署階段定死、客戶不該碰的基礎設施設定才走 .env。CM-1560 的 TLS 項第一輪做成 .env 環境變數，被退回重做——原因是「要不要驗 LDAP 憑證」與「憑證內容」屬於客戶會依自己 LDAP 伺服器狀況調整的功能設定，硬編進 .env 意味著改一次要重啟服務甚至要工程師介入，不符合這類設定該有的自助性。跟現有 LDAP 連線設定（host/port/bind DN 等）擺在一起，就知道判準。
驗收要親自跑測試，不能信 runner 自述：CM-1587 的驗收就是這樣抓到問題的——runner 回報已完成，但沒有把新 error code 登記進「凍結 error code 基準表」，這件事只有實際去比對基準表才會發現，光看 commit message 或 runner 的文字描述看不出來。往後每張修正卡驗收，除了看 diff，還要跑一次卡片要求的測試指令，不能只信 runner 的「已驗證」宣稱。
面板全滅時「結果能不能用」要分兩層答，不要籠統說「不能用」：「這幾條存在嗎」與「只有這幾條嗎」是兩個問題。前者靠人工開檔核對就能回答得比面板還可靠（打開檔案那幾行就是那樣寫的，是事實陳述不是推論）；後者只有工具跑完面板才答得出來。FR-077 R1 就是前者成立、後者不成立——修正卡照開沒問題，但不能宣稱這個套件掃過了。交接與報告時要把這兩層分開寫，否則接手者會誤以為七條也不可信而重掃（浪費）或誤以為套件乾淨（危險）。
報告開頭必須是白話總覽表，這是硬規則不是風格偏好：R1 報告第一版把「執行概況（agent 數／token 數）」與「面板為什麼全滅」放在最前面，要捲到第 150 行才看得到第一條發現在講什麼，決策者的評語是「連工程師都不想看」。改成開頭一張表（# / 嚴重度 / 這是什麼問題（白話）/ 出事會怎樣 / 要先有什麼才打得到 / 位置 / 修正卡）＋「這份結果的可信度」段之後才可用。新開的掃描卡都要把這條寫進「交付什麼」，R1 報告可直接抄格式。
runner 自行偏離卡片建議時，要看理由合不合理，不是照卡硬套：CM-1583 的卡片原本建議 body 上限 64KB，runner 實際做的時候發現簽章 manifest 檔案本身可能接近 1MB，因此改成 16MB 才不會誤傷正常流程，首腦驗收時認同這個調整，最終決策者再定案 50MB（考慮到 CM-1572 也有共用需求）。這類「runner 發現卡片給的數字/範圍不切實際而自行調整」不是違規，只要理由站得住腳、有具體證據（如「簽章檔案實測大小」），首腦應該認同並往上呈報決策者定案，而不是要求 runner 機械照卡片原始數字做。
🔴 判密鑰外洩的嚴重度，第一問是「客戶端用的是不是同一把」，不是「這把是不是活的」：FR-079 B2 的 F12（JWT 簽章金鑰散在版控 31 個檔、已上 origin/main）——首腦驗收時查了「與現行 .env 一致」（是）、「散佈範圍」（30／31 檔、14 個 commit），據此把面板判的 MEDIUM 升到 HIGH，理由是「拿到就能偽造任何人的登入憑證，RLS 一併失效」。這個推理漏了一步：決策者當場問「這個值安裝時是不是動態產生？如果是就不用修」——查 scripts/installer/install.sh:1252 確認每套安裝各自跑 openssl rand -base64 32，外流的只是我們開發機那把，影響從「所有客戶安裝」縮成「我們自己的 DEV」，判級應為衛生類（與 CM-1608「自己的測試機」同判準）。判準固化：遇到任何硬編／外洩的憑證，先查 installer 或部署流程有沒有為每套安裝動態產生；沒查這一步就談嚴重度，會系統性高估。 反向情形同樣要查——同一棒的 F15（installer 原廠 super admin 密碼）正好是「每套都一樣」，那才是真的要處理的形狀。
🔴 「每棒 ≤30 檔」這把尺應改寫為「40 檔可行，前提是一次只跑一棒」（FR-081 換來）：FR-077 R1 的 42 檔面板全滅（105 個 verifier 全死、21 票 0 投）曾讓尺收到 15、後放寬到 30。FR-081 的 I5 是 40 檔，面板 15 票全投、零漏投、零不完整、一輪跑完。兩者差別不在檔數而在額度競爭：R1 那次是連續跑、與其他棒搶額度；FR-081 是決策者裁「分開來跑，避免每次都發生中斷不完整狀況」，六棒一次都沒撞額度，對照 FR-079 B2 那棒撞兩次、跑 14 小時、還踩到 save_result.py 同 shard 靜默擇一的併檔陷阱。判準改成：範圍大小仍是槓桿，但「一次只跑一棒」比壓縮檔數更有效。 排計畫時可按 40 檔一棒推算，前提是串行派工、每棒獨立驗收完才派下一棒。
工具在小範圍棒次會空轉，卡片指定必答的項目要靠人補查（FR-081 換來）：FR-081 的 I3（14 檔）、I4（20 檔）、I6（28 檔）三棒，工具範圍內淨新增都是 0——它反覆撈同一個 scope 外的舊發現（verify=False 被六棒撈了五次），而卡片「重點看什麼」列的項目一項都沒答。這三棒真正的產出全是首腦補查的：I4 查出 plugin.py:222-233 的 fail-closed 是真的（自陳成立）、那條 route 不是漏掛能力點而是能力點從未定義；I6 查出套件的六張表（issues／labels／members＋三張 mapping）完全沒有 RLS、連 tenant_id 欄位都沒有，比 FR-079 的 bulletin_org_units（有欄位無 policy）更徹底。紀律：卡片的「重點看什麼」要在交付要求裡明寫「工具沒答的自己開檔查了再寫，標明（工具未報，人工查證）」，否則報告會留白，接手者誤以為那些點乾淨。另一半的教訓：面板的「當前不可達」結論可信，但它的推論停在可達性，不會告訴你這段程式碼本身是不是寫錯的——I3 那條被 0/3 否決的候選，首腦核對後發現面板可達性論證全對，但漏看了同一函式第 92 行與第 99 行用了不同變數（算了交集卻只用一半）。被面板否決的重點，首腦仍要自己看一眼。
🔴 報告寫給誰看，決定了它有沒有用（2026-09-10 決策者要求，已入 skill 第十節與 memory）：決策者評「每一次的報告都看不懂，都是 AI 文言文版，每次產出都要在多整理一次」。問題不是內容錯，是預設讀者錯——首腦與 runner 寫報告時的預設讀者是「懂這個 arc 脈絡的工程師」，於是大量使用 TLS／MITM／RLS／capability／fail-open 這類縮寫，還把「工具跑了什麼」（agent 數、票數、耗時）放最前面。結果是產出沒有真正完成，只是把整理成本轉嫁給讀者。 判準：PM（不懂程式）與新手工程師（懂程式但不熟 codebase）兩種人都要看得懂。每條發現必須回答五個問題（是什麼／出事會怎樣／要先有什麼／在哪裡（檔:行）／怎麼修），報告骨架順序固定（結論 → 檢查什麼 → 總覽表 → 詳述 → 可信度 → 執行概況放最後），術語出現時必須當場解釋。SUMMARY 還要有「預計怎麼修復」段：每張卡分幾步、哪步要決策者放行、做完怎麼驗。這條同時管 runner 回報與 Notion 回寫，且派工時要寫進 runner 的 prompt（runner 不會自己去讀 skill）。FR-081 六份報告已於 2026-09-10 依此重寫，可直接抄。
🔴 開錯檔給決策者看，會害他以為報告沒寫問題清單（2026-09-15 換來）：首腦把 FR-095 的 README.html（索引頁）當成掃描報告開給決策者，決策者回「沒有掃描出來的問題清單以及建議修復方式」。清單一直都在，在 scan-*.md 的第 3 節。 判準固化：決策者要看「掃出什麼」時開 scan-<棒名>.html，不是 README；README 是「這個掃描在做什麼」的索引頁，兩者用途不同。
🔴 決策者的質疑要當成事實線索去查，不要急著解釋（2026-09-15 換來）：他問「專案成員名冊不是本來就該可以查全公司的人嗎」，首腦去查前端實際呼叫點後發現他是對的——挑人加入專案用的是另一支 API（/users/menu，回全公司帳號是正常設計），有問題的那支是「查某個專案已經有哪些成員」。先前報告的寫法讓這兩件事混淆了。 判準：決策者的質疑通常指向報告的表達缺陷，不是他沒讀懂；先去查事實，查完再回答。
🔴 報告寫「跨客戶的資料也一起回來了」，在驗收時可能已經過期，這是連續第三棒撞到（H1 的 F1、P2 的 P2-3、FR-096 P1 的 F1）：平行的租戶隔離線（FR-094）會在掃描與驗收之間補開隔離。驗收一律重查 DEV 並標時序，判定要寫「掃描版本 X 時未開、CM-xxxx 於 Y 開」，不能只寫「已改判」。
runner 未交付四件已是第六次（C1／S7／B2／H3／H1／FR-096 P1）：派工 prompt 該寫的兩句都寫了仍然會漏，機率降低但不保證。補寫已經是常態成本，排時間時要算進去，不要每次都當成意外。
這個 arc 的風險形狀與前兩個不同，接手時要知道：
ack_task(uid) / receive_result(uid, payload) 參數只有 task uid，沒有 agent_uid、沒有 tenant 檢查——任何 agent 拿到別人的 task uid 就能替它 ack、替它回報成功並塞任意 result_ref。jedi-detection 的 docstring 自己寫了「ack / result 根本不識別身分」，但沒有人判斷過可不可接受。heartbeat() 的身分 fallback get_one_remote_agent(device_fingerprint=device_uuid) 沒帶 tenant_id，而 register() 的同款查詢有帶。兩者都跑在無 user context 的 super admin scope。決策者原話：「掃出來都不能用，我決定從其他套件開始掃。」 接手者要理解這句話指的是什麼、以及它是不是等於「R1 的發現不成立」——不是。
R1（42 檔）跑了 2 小時 21 分、158 萬 token，研究階段完整完成（2/2 研究員回報、8 條候選去重成 7 條），但三人驗證面板全滅——105 個 verifier 全部撞 session 額度上限，21 張票 0 張投出。工具的正式 findings 因此是空陣列，stamp 記 verification.status: unverified。
runner 沒有重跑（正確），改從 workflow journal 撈回候選、七條全部人工開檔核對；首腦再親自複核 F1／F2／F3 的行號、grep BE 與 FE 兩個 repo 確認三個 nginx 設定檔皆無 ssl_verify_client、追明文憑證流向。七條全部屬實。
分兩件事，不要混：
| 可信嗎 | 為什麼 | |
|---|---|---|
| 這七條存在 | ✅ 可信 | 每條都是「打開檔案，那幾行就是那樣寫的」——事實陳述不是推論。人核兩遍（runner 逐條＋首腦複核關鍵條）。修正卡 CM-1595～1598 是照這個開的，依據紮實。 |
| 「只有這七條」 | ❌ 不可信 | 面板沒跑＝沒有「工具背書」的產出；卡片列的八個重點只實質觸及一個；密碼學核心（ca.py／jwt_util.py）零發現但分不出「讀過沒問題」與「根本沒讀」 |
決策者的判斷是針對第二列：一個掃描工具跑完之後，正式產出是空的、覆蓋率無法宣稱、要靠人工補核才有東西，這樣的產出對「證明某個套件掃過了」沒有價值。這個判斷是對的。
首腦建議把每棒壓到 15 檔以內（FR-076 L1 的 10 檔是唯一一次面板跑完的紀錄），並已據此把 R2 拆成 R2a（18 檔）＋R2b（13 檔）。決策者選擇先換套件而非繼續調參數——理由未逐字記錄，但合理推斷是：與其在同一個套件上反覆試工具的極限，不如先去掃風險更高、且範圍天然就小的套件（見下方排名，前段有多支 13～34 檔的套件，天生就在面板撐得住的量級）。
四棒的卡都開好了、範圍與「重點看什麼」都寫死在卡裡，檔數已按新尺（≤15 檔）調過，隨時可續：
| 棒 | 卡 | 檔數 | 備註 |
|---|---|---|---|
| R1b 補掃密碼學核心 | CM-1599 | 10 | 與 FR-076 L1 同量級，最有把握跑完面板的一棒 |
| R2a 任務下發與狀態機 | CM-1593 | 18 | 卡尾有「範圍收窄」段，以那段為準（原卡寫 29 檔） |
| R2b 檔案取用與 agent 連線 | CM-1601 | 13 | 重疊帶入 R2a 兩支檔，刻意的，見下 |
| R3 主專案宿主接線 | CM-1594 | 17 | scanRoot 是 BE repo，與其他棒不同 |
R2a／R2b 的重疊要保留：檔案下載授權判的是「這個檔案是不是該 agent 名下未完成任務引用的」——問題前半在 R2b（agent_file_access_service.py）、後半在 R2a（狀態機與 repo query）。R2b 因此額外帶入 agent_task_domain_service.py 與 agent_task_repo_impl.py。重複報由首腦驗收時挑掉；接縫沒人看才是真的損失。
🔵 2026-09-16 曾裁降 HIGH、同日撤銷回到 CRITICAL（第十四任首腦實查：fc1cadb 只把執行身分從超級管理員收成該租戶機器身分，「你是哪一台」仍由請求自報且不比對，跨租戶冒充路徑未堵，原文判斷仍成立）：CM-1595 是 CRITICAL：不需任何帳號憑證，打一個 HTTP 請求到心跳端點即可拿走該租戶掃描工具的明文客戶憑證（客戶自己的 SonarQube token、SSH／WinRM 帳密），且可跨租戶。決策者裁的是「掃描改從其他套件開始」，沒有明示修正卡也停。首腦建議：掃描停、CM-1595 照派。
兩棒都跑完、面板都完整跑完，換來三個會改變下一任怎麼排計畫的結論。
FR-078 兩棒（30 檔與 18 檔）面板都完整跑完。加上 FR-076 L1 的 10 檔，現在有三次成功紀錄。對照組是 FR-077 R1 的 42 檔——105 個 verifier 全死、21 張票 0 投。
結論：30 檔在 5X 額度下可行，這比原本猜的 15 檔寬鬆得多。切棒時不必再壓到 15，排計畫可以按 30 檔一棒推算（排名表的棒數與時數是按 15 檔算的，會高估）。
N2 第一輪面板驗到候選 C6 時撞額度：三個 verifier 回來兩個，第三個初次派發加四次重試全失敗。工具沒有拿兩票充數——它把死掉的那個記進 adversarialCasualties，交給下一輪；額度重置後用完整三人面板重驗，那一條就是報告裡的 F8。
票數自洽可以驗證這件事：7 個候選 ×3 = 21 票，實際 23 票，多出來的 2 票正是第一輪作廢的部分票。續跑是重投，不是接續舊票。
→ 這與 FR-077 R1 的「面板全滅、findings 空陣列、stamp unverified」是完全不同的狀況，接手者不要混為一談。判準：看 stamp 的 verification.status 與 verification_runs。看到額度錯誤訊息就判定「這棒廢了」是錯的。
N2 六條裡有四條是 scope 外的，全部是密鑰專項掃出來的（工具自己標了 out of scope，沒有假裝在範圍內）。
.env.test 的四把 API 金鑰——與決策者當天稍早自己發現的是同一件事，工具獨立驗證了它，還查出該檔存在於 origin/main 與另外十一個推送過的分支（比人工查得更完整）→ 設 focus 就會跑密鑰專項，這是免費的額外收益，值得每棒都設。
三個都已寫進 .claude/skills/security-scan-lead/SKILL.md 第二節與掃描卡樣板（commit bc1c3381／5e4ea041），細節看 skill，這裡只讓接手者知道有這三件事存在：
disable-model-invocation: true，模型叫不動它；繞路自己叫 Workflow 也被作業書禁止（手工拼出來的報告會宣稱跑過根本沒跑的驗證）/config 的 Dynamic workflows，結果是 true、與此無關，白繞一圈）killed 狀態。與撞額度的處置完全不同：撞額度可續可撈（見收穫二），被砍則無可續無可撈，只能重打檔數為 attack-surface 口徑（已排除 tests／dist／docs）。
🔴 更重要的是：下表的檔數只涵蓋套件本身、不含它在主專案的宿主接線。 FR-079 規劃時發現 jedi-bulletin 除了套件的 29 檔，主專案還有 33 檔宿主接線，而授權判定全在宿主那半邊（FR-077 R3、FR-078 N2 同理）。排下一支時要先問「這支有沒有宿主那一半」，否則會低估工作量、也會掃出一份「乾淨」的假象報告。
⚠️ 下表的棒數與時數是按舊尺（每棒 ≤15 檔）算的，會高估。 FR-078 實測 30 檔面板跑得完（見「FR-078 的三個收穫」收穫一），按 30 檔重算大約是表中的一半。表格數字沒改是為了保留當初的推算依據，重排計畫時自己折半。時數按實測每棒約 70 分鐘。
| # | 套件 | 檔數 | 行數 | 棒 | 預估 | 現況 |
|---|---|---|---|---|---|---|
| 1 | jedi-ai-bot | 13 | 632 | 1 | 1.2h | |
| 2 | jedi-integrity | 20 | 3,178 | 2 | 2.4h | |
| 3 | jedi-bulletin | 29 | 847 | 2 | 2.4h | ✅ FR-079 已掃完（B1 套件 29 檔＋B2 宿主接線 33 檔；排名的 29 檔不含宿主那一半） |
| 4 | jedi-device | 29 | 962 | 2 | 2.4h | |
| 5 | jedi-information-system | 31 | 1,344 | 3 | 3.6h | |
| 6 | jedi-system-config | 31 | 1,176 | 3 | 3.6h | |
| 7 | jedi-log-forwarding | 32 | 2,263 | 3 | 3.6h | |
| 8 | jedi-notification | 32 | 1,011 | 3 | 3.6h | |
| 9 | jedi-ai-dashboard | 33 | 2,296 | 3 | 3.6h | |
| 10 | jedi-system-menu | 34 | 1,199 | 3 | 3.6h | |
| 11 | jedi-log | 41 | 1,305 | 3 | 3.6h | |
| 12 | jedi-evidence-classification | 45 | 3,955 | 3 | 3.6h | |
| 13 | jedi-license-runtime | 49 | 3,963 | 4 | 4.8h | ✅ FR-076 掃完 |
| 14 | jedi-file-upload | 61 | 2,510 | 5 | 6.0h | |
| 15 | jedi-remote-agent | 65 | 3,032 | 5 | 6.0h | 🔄 FR-077 R1 完成，餘暫停 |
| 16 | jedi-flow-engine | 71 | 6,956 | 5 | 6.0h | |
| 17 | jedi-task-platform | 83 | 3,585 | 6 | 7.2h | |
| 18 | jedi-common | 92 | 3,454 | 7 | 8.4h | ⚠️ 只有第一輪未驗證掃描，不算數 |
| 19 | jedi-participant | 103 | 5,391 | 7 | 8.4h | |
| 20 | jedi-issue | 129 | 3,599 | 9 | 10.8h | |
| 21 | jedi-detection | 151 | 17,013 | 11 | 13.2h | 🔄 僅 agent 相關 11 檔借進 FR-077，餘 140 檔未掃 |
| 22 | jedi-survey | 153 | 11,315 | 11 | 13.2h | |
| 23 | jedi-compliance-audit | 168 | 13,733 | 12 | 14.4h | |
| 24 | jedi-iam | 290 | 15,421 | 20 | 24.0h | ✅ FR-075 掃完（S7 已收窄重跑並驗收） |
| 25 | jedi-oscal-v2 | 364 | 15,837 | 25 | 30.0h |
未掃合計約 111 棒、133 小時（純掃描，不含驗收／開卡／修正）。
| 優先 | 套件 | 檔數／時數 | 為什麼 |
|---|---|---|---|
| 1 | jedi-common | 92 / 8.4h | 全部套件都 import 它——session_scope、@transaction、RLS 注入、error handler、response 信封都在這。CM-1559 那條 fail-open 的根就在這裡，而它至今沒有一次算數的掃描（第一輪 medium 半途喊停、未經面板）。它出問題等於 25 支全中 |
| 2 | jedi-integrity | 20 / 2.4h | 檔少但全是簽章驗證與完整性。FR-076 已在它身上撞到 HIGH（無界解壓縮 CM-1572），那還是順手發現的。CP 值最高 |
| 3 | jedi-file-upload | 61 / 6h | 檔案上傳下載、儲存後端切換（local／minio／remote_agent）。路徑穿越與任意檔案讀取的天然溫床 |
| 4 | jedi-detection（agent 以外 140 檔） | 140 / 12h | 客戶憑證解密在這（_resolve_tool_credentials）、掃描參數會變成 agent 端執行的指令 |
| 5 | jedi-participant | 103 / 8.4h | 專案成員與角色——授權判定的資料源。jedi-iam 管「你是誰」，這支管「你在這個專案能幹嘛」 |
可以最後排的（讀取展示型，攻擊面小）：jedi-bulletin／jedi-system-menu／jedi-log／jedi-log-forwarding／jedi-notification／jedi-ai-dashboard／jedi-information-system，約 200 檔、20 小時。
jedi-oscal-v2 建議獨立 arc：364 檔最大一支，但它是文件格式的 parser／serializer，風險形狀不同（XXE、解析炸彈、資源耗盡），與授權鏈掃描的「重點看什麼」完全不同，混在一起會讓卡片失焦。
本 arc 已收尾完成，沒有待辦。接手者做三件事就夠：①讀本檔表頭四則；②要查某棒掃描結果時，報告在
docs/features/<FR>/scan-*.md，工具原始產物在docs/features/security-scan-consolidated/runs/{be,jedi,license-center}/<報告引用的目錄名>/；③要開新掃描一律另開新 FR，開卡前先讀security-scan-leadskill 第一節（切棒判準）與第五節第 8 步（run 目錄歸檔）。
兩處對照口徑（下一任驗收 Notion 或總表時會用到）：
common/authz/workflow.py:15-16 的政策自述。upload_files 加租戶欄位＋開隔離也歸這批，FR-094 不收（決策者同日追裁）。這是「只掃不修、全部掃完再排」裁定的第一個例外，其餘範圍仍維持只掃不修。< >，攻擊者可以把頁面程式截斷、接上自己的程式。落地版前端和後端同網址、登入通行證放在瀏覽器裡，所以已登入的人點到攻擊者寄來的連結，通行證就被拿走，攻擊者連帳號都不需要。首腦本機重現過。修法：錯誤訊息改成固定錯誤碼白名單、不把例外文字回頁面、加內容安全政策。docs/features/security-scan-consolidated/README.md——§0.5 是「哪些套件掃到哪」的唯一來源、§3 是問題清單（97 項未開卡，每項標「開卡素材」成本，開頭有 2026-09-16 的 96 條逐條複查結果）、§4 是可以一起修的分組索引、§5 是下一批怎麼排、§7 是待決策者裁的事項docs/features/security-scan-consolidated/risk-overview.md——1 條最嚴重／35 條高／61 條中／51 條低（2026-09-20 掃描收口後現值），中低風險已改為逐條列表並分群（決策者 2026-09-16 反映「低風險的怎麼沒有列表」）docs/features/FR-075|076|077|078|079|081|082|083|084|085|086|087|088|095|096|097|098-*/docs/features/FR-120-2609-host-residual-security-scan/（README 進度表、scan-U1～U13b.md、di-wiring-audit.md／di-wiring-audit-fixline.md）；驗收結論定稿 handoff-acceptance-brief.md（U2～U13a 各棒照登結論、已裁定、§7 第 51～53 項）。FR-119 交修正線清單 docs/features/FR-119-2609-security-scan-closeout/handoff-to-fix-line.md。scan-methodology.md；首腦手冊 .claude/skills/security-scan-lead/SKILL.mdfix-plan-draft.md＋classification-matrix.md，決策者未裁不排修）、CM-1986（總表數字對齊，§0/§0.5 定稿數字＋六處基準表更正）、FR-075 CM-1546、FR-076 CM-1566、FR-077 CM-1591、FR-078 CM-1602、FR-079 CM-1609、FR-081 CM-1612、FR-082 CM-1636、FR-083 CM-1639、FR-084 CM-1644、FR-085 CM-1646、FR-086 CM-1651、FR-087 CM-1663、FR-088 CM-1669、FR-095 CM-1779、FR-096 CM-1803（子卡 CM-1804 P1／CM-1805 H1／CM-1806 P2 全已驗，三棒收尾）、FR-097 CM-1810（子卡 CM-1811 L1／CM-1812 L2 全已驗，兩棒收尾）、FR-098 CM-1813（子卡 CM-1814 A1 已驗／CM-1815 A2 已派出待驗收）、FR-101 CM-1825（子卡 CM-1826 J1／CM-1827 J2／CM-1828 J3，全待派）<scanRoot>/CLAUDE-SECURITY-<ts>/，stamp 在裡面feature/review（2026-09-23 更正——本段原寫「都在 main」是過期資訊）。不切、不問，commit 一律限定路徑；工作區隨時有平行 session 的未 commit 改動，不碰、不 stash。歷史紀錄：這幾個 repo 曾因決策者的發版線被切到 main（當時記「不要切回 feature/FR-075」）。BE 已進正式版 1.20.0（commit 34d48807），jedi 套件八支進 1.1.2（c92b0d7）。本棒 commit 共 11 顆（依時序）：1afdc931 FR-096 P2 驗收＋三棒收尾／cf29d529 補兩處欠帳／90681b18 FR-097 開卡／207a29ab L1 掃描報告／41dbbad9 L1 驗收／85d33336 L2 掃描報告／6fec99f6 L2 驗收＋FR-097 收尾／40196e8f FR-098 開卡／3344de46 修「部分掃過」三格／0ea83527 A1 掃描報告／f94f4ae4 總表複查落地＋結構重排＋A1 驗收＋中低風險逐條。⚠️ 前五顆（到 41dbbad9 為止）已隨平行發版線的 push 出去了（origin/main 現在在 361db496）；後六顆（85d33336 起）未 push，等令。2026-09-20 第十七任更新：連同 D 線收口（dd288000／12f63826／fcfe834d）與同時間平行進行的資安報告內化整理線（CM-1982／1984／1985／1988 一路到 a3576ca1／6d9ee3db／7560bd0f），目前分支未 push commit 累計約 36 顆，push 時機等令。2026-09-26 第二十二任交棒：未 push 約 220 顆，push 等令git commit -- <明確路徑> 限定路徑。FR-089 線已收尾（9631ab9f）scripts/notion_create_case.py；讀寫卡：scripts/notion_case.py~/Desktop/套件與主專案的分工現況.md＝套件分工白話結論~/.claude-runner2，memory 已由首腦複製過去（257 檔）；skill 與 CLAUDE.md、agent 跟著 repo 走，不用另外處理