資安掃描 LOG（append-only，每棒追加一 block）

做了什麼：從零建立兩個掃描 arc，跑出可行的方法，驗收七棒，開 21 張修正卡，把接手需要的東西入版控。

commits（BE repo，feature/FR-075）：f926090f 開 FR-075 → 9a5acc8d 建站 → ed6d70a9 拆六棒 → 4da50a64 改垂直切 → 4b2fb9f6 S2/S3 驗收開 3 卡 → 91c022f7 S1 驗收開 5 卡 → 80428720 CM-1561 裁決 → 854f01c9 S4-S7 全滅判定 → 7bef0159 開 FR-076 → 726b4536 L1 驗收 → 96028e11 S4 驗收含 CRITICAL → 03d169aa L2 驗收 → 97979547 CM-1579 裁決 → d176423e 公鑰議題 → 1fb25e97 L4 驗收 → 7d388a19 memory 入版控 → 本 block 的 commit（skill＋STATE＋建卡腳本）

決策：

• 工具選 claude-security plugin（決策者堅持要工具而非人工，理由「工具出來一定有它的知識在」）
• 第一輪 medium 派 40 agent 手動停掉；第二輪 low 額度耗盡零產出；才定案 low
• 切棒從「6 棒混合切」改成「7 棒按模組垂直切」（決策者指出水平切看不到接縫）
• S4～S7 首輪 Sonnet 全滅後改 Opus 1M，S4 第二輪 3.5 小時跑完含 CRITICAL，方法論定案
• L1（10 檔 55 分）、L2（33 檔 90 分）、L4（43 檔 110 分）三度確認 Opus 1M＋小範圍可行

教訓（已入 skill 第一、二節）：

1. 研究員繼承主 session 模型與 context 上限，effort 管不到這層
2. 工具被註解說服（S2）、越界（S7/L1/L2）、只驗成立不驗範圍——三個固定盲點
3. 工具找 LOW 人找 HIGH（L2）——卡片「重點看什麼」要靠 runner 追
4. 掃描定時檢查不耗 token，驗收才耗；Monitor 不適合（無事件流可掛）
5. 修正與掃描可平行但同套件要錯開，決策者裁「先修 FR-076 再動 FR-075」

推翻了什麼：

• 「主 session 切便宜模型再啟動掃描」（scan-methodology 早先建議）→ 推翻，便宜模型的 context 上限跟著繼承
• 「把 S4-S6 切更細維持 Sonnet」→ 推翻，S7 證明研究員為追脈絡一定往外讀，切小不減量
• 「掃描完再修」→ 推翻，不同套件可平行

未完成交棒：S5 掃描中、S6 狀態不明、S7 核心未掃、L3 未派、CM-1572/1580 待驗、四項待決策者裁。全在 STATE。

接手原因：第一任首腦（Fable 5.1）遇到間歇性 400 錯誤中斷，本任接手繼續驗收與派工。

做了什麼：驗收 S5 掃描棒＋L3 掃描棒；驗收並推動 16 張修正卡從待派到 Done（含兩輪驗收批次）；改裁三項先前決策（CM-1561 拔除→關閉、CM-1579 SaaS 前暫緩→現在做、CM-1560 TLS .env→設定頁欄位）；派出 CM-1559 第一步盤點；收尾更新 STATE/LOG。

commits（各 repo，散落在多輪驗收裡，完整清單見母卡 CM-1546／CM-1566 尾段驗收表）：

• jedi-iam：b51b914（1557）2bf2003（1558）6a13d96（1563）4c7579c（1565）9b353ee→20c6713（1560）4984e1e（1585）dbb96aa（1586）7cf3cf2（1576）76a8c2d（1562）608d077（1578）d28e364（1561）eaa8de7（1577）a9edf1d（1575）
• BE（本 repo，feature/FR-075）：83c5b118（1565）3ad876ae→f503fba3（1560）d08bc34c（1561）d4d1b0e4（1564）f867540f+2ea76ef7（1587）7097774（1586）b67e9cdd（1577）
• FE：d3283e5（1557）52a40c4（1558）78903b2（1560）2268571（1585）0f1d0ed（1564）21157820（1587）
• License Center：a68200c（1583）58c0e98（1584）
• jedi monorepo：ed62d8a（1573）
• 更早已驗但非本任新增：4b527704（1581，前任 runner commit，本任僅驗收）

決策（改裁三項）：

1. CM-1561 Google 登入殼：原裁「從 factory 拔除」，改裁「關閉不拔除」——理由未在 LOG 逐字記錄，但已落地為關閉 provider 白名單而非移除程式碼路徑
2. CM-1579 停權可被換照解除：原裁「綁 SaaS 上線前，方案 A 定案」屬暫緩，改裁「現在做，方案 A」——不再等 SaaS 時程
3. CM-1560 LDAP TLS 設定：第一輪 runner 做成 .env 環境變數（LDAP_CA_CERT_FILE），首腦判定這是客戶自助功能設定不該走基礎設施變數，退回重做成設定頁欄位（verify_cert／ca_cert_pem），對齊既有 LDAP 連線設定的其餘欄位

教訓（已入 STATE「教訓」段）：

1. .env 變數 vs 設定頁欄位的判準——客戶自助頻繁調整的功能設定走設定頁，部署期定死的基礎設施設定才走 .env；CM-1560 TLS 項因此退回重做一次
2. 驗收要親自跑測試不能信 runner 自述——CM-1587 漏登「凍結 error code 基準表」就是這樣抓到的，光看 commit message 看不出來
3. runner 自行偏離卡片建議的數字/範圍時，要看理由是否站得住腳（如具體實測證據）再決定認同或打回；CM-1583 的 64KB→16MB 是合理調整的例子

推翻了什麼：

• CM-1561「拔除」→「關閉」
• CM-1579「暫緩到 SaaS 上線」→「現在做」
• CM-1560 TLS「.env 變數」→「設定頁欄位」

未完成交棒：

• S6（CM-1555）：原掃描是失敗記錄非乾淨結果，待改 Opus 1M 重派
• S7（CM-1556）：核心範圍（middleware／domain service／plugin.py 預設值／login_log／ui_route）從未真正掃過，決策者已裁定重跑，排 2026-09-06 深夜（token 排程）
• CM-1559：已派出做第一步盤點，等回寫後裁第二三步範圍
• 上版：jedi-iam 10 張＋LC 2 張＋BE 1 個 migration 待批次發版部署 STG/POC，細節見 STATE「上版待辦」段
• 兩個母卡（CM-1546／1566）狀態欄仍是「Not started」，等全部子卡收尾才收 Done

這一棒做了什麼：開 FR-077、切棒、開卡、驗收 R1、開修正卡、拆 R2、備妥全套件排名。未派任何後續掃描棒（決策者 09-08 裁暫停）。

開的卡（11 張，CM-1591～1601）

commits（BE repo，feature/FR-075，已 push）

• d58a95fc 開 arc、三棒開卡
• 882782f7 R1 掃描結果（runner 產出）
• eff97fbd R1 驗收＋開六張卡
• 5286f839 彙整進 FR README ＋ build HTML 站（CM-1600 runner 產出，首腦代 commit）
• 87c0e39c README 加「一頁看完」白話總覽
• 2364887f R1 報告開頭加「七條一覽」總覽表
• 8d160984 R2 拆成 R2a／R2b
• （本次交接 commit：STATE ＋ LOG）

決策（決策者 2026-09-08 裁，共 6 項）

1. F1 升 CRITICAL（原 runner 判 HIGH）——無認證＋跨租戶＋洩漏客戶自己基礎設施的憑證，三條件全中
2. F1+F2+F3+F5 併一張修正卡——修法是同一套 agent 認證機制，分卡會讓兩個 runner 各寫一套互相打架
3. nginx 併進 CM-1595 當「連帶」不另開卡——它只驗「是不是我們發的憑證」，驗不出「是不是你宣稱的那台」，不能當唯一防線；獨立開卡會讓人誤以為補了就算修好
4. 補掃 R1b——密碼學核心零發現在面板未跑的前提下不可信
5. R2 拆兩棒＋每棒上限改 15 檔——見教訓
6. 🔴 FR-077 暫停，改從其他套件開始掃——理由見 STATE「FR-077 暫停的來龍去脈」段

推翻了什麼

• 每棒 10～45 檔 → ≤15 檔（skill 第一節的表過時了，STATE 已記，skill 本身尚未改）
• R2 一棒 29 檔 → 拆兩棒 18＋13，且刻意重疊兩支檔（原則不變：垂直切不水平切；但發現「切在接縫上」時要用重疊處理，不是硬切）
• 報告格式：從「執行概況開頭」改成「白話總覽表開頭」（決策者評 R1 首版「連工程師都不想看」）

教訓（已入 STATE「教訓」段第 4～6 條）

1. 面板全滅時要分兩層答「能不能用」——「這幾條存在嗎」（人核可答，比面板可靠）vs「只有這幾條嗎」（只有面板能答）。混在一起講，接手者不是誤重掃就是誤以為乾淨
2. 報告開頭必須白話總覽表——這是硬規則，新卡的「交付什麼」段都要寫進去
3. 卡片不要寫「用瀏覽器開 X 確認」——CM-1600 的 Sonnet runner 因瀏覽器工具 server error 無限退避重試，卡住整棒。改寫成「跑 render 後 grep 關鍵段落存在即可」
4. 面板成本是掃描的真正瓶頸——候選數×3 個 verifier、每個從零讀檔，比研究階段更貴。控制範圍大小是唯一有效的槓桿（effort／模型都已調到極限）

未完成交棒

• FR-077 四棒卡都開好、範圍寫死，隨時可續（CM-1599 10 檔／CM-1593 18 檔・看卡尾收窄段／CM-1601 13 檔／CM-1594 17 檔・scanRoot 是 BE repo）
• CM-1595（CRITICAL）要不要照派，決策者未明示——首腦建議掃描停、修正照做
• 全套件排名已備妥（STATE「全套件掃描排名」段，25 支／111 棒／133 小時），建議第一批 jedi-common 或 jedi-integrity
• security-scan-lead skill 尚未更新：第一節的「每棒 10～45 檔」與第三節的掃描卡必含項（缺「報告開頭白話總覽表」）都過時了，下一任首腦開新 arc 前應先改 skill
• FR-075 的 S6／S7／CM-1559、上版待辦——狀態同前任，未動

這一棒做了什麼：開 FR-078、切兩棒、驗收兩棒、開四張修正卡（歸檔不派工）、處理 .env.test 事件、把三條啟動紀律補進 skill。兩棒的面板都完整跑完——這是本 arc 至今第二、第三次。

開的卡（7 張，CM-1602～1608）

四張修正卡全部 Not started 是決策，不是漏派——決策者裁「PM 打算收集所有掃描結果再統一安排修正」，開卡是歸檔。

commits（BE repo，feature/FR-075）

• 2c5f5ebc 中斷救援紀律（撞額度 vs 被砍，兩者處置不同）
• a8c9c604 開 FR-078 arc
• 55a186e2 建卡（CM-1602～1604）
• bc1c3381 skill 補「只能由決策者親手打指令」
• 5e4ea041 skill 補三個實戰坑
• 79e501c5 build HTML 站
• 5746cef1 .env.test 撤出版控＋移除 gitignore 例外
• 56c1dc43 拿掉使用手冊「範本」說法
• （本次交接 commit：STATE ＋ LOG）

前六個已 push。 另有兩份掃描報告的 commit 由另一 runner 產出（docs/features/FR-078-2609-notification-security-scan/）。

決策（決策者 2026-09-08 裁，共 3 項）

1. FR-078 選 jedi-notification 起頭——決策者原話「先從真的獨立的開始掃」。不從排名第一的 jedi-common 起頭，先拿一支耦合少、範圍天然乾淨的套件把方法跑順
2. 🔴 修正卡全部先不派——PM 打算收集所有掃描結果再統一安排修正。這一條同時追溯適用於 FR-077 的四張（含 CM-1595 那張 CRITICAL），前任「掃描停、修正照做」的建議至此有了答案：不照做，一起等
3. 🔴 不重寫 git 歷史（.env.test 事件）——金鑰撤銷是有效處置；重寫歷史會改動所有 commit hash、影響每一個有 clone 的人，而對已散出六個月的內容毫無補救效果。理由詳見 commit 5746cef1

推翻了什麼

• 「每棒 ≤15 檔」→ 放寬為 ≤30 檔。這條尺是前任因 R1 的 42 檔面板全滅而收緊的，只有一個成功樣本（L1 的 10 檔）撐著。本棒兩次成功（30 檔、18 檔）把樣本補到三個，30 檔在 5X 額度下已實測可行。排名表的棒數與時數是按 15 檔算的，重排計畫時要折半
• 「掃描是 all-or-nothing」→ 錯，工具會自己接住中斷。N2 第一輪撞額度，工具沒有拿兩票充數，而是把死掉的 verifier 記進 adversarialCasualties、額度重置後用完整三人面板重投。票數自洽可以驗證（7 候選 ×3 = 21，實際 23 票，多出的 2 票正是作廢的部分票）。這與 R1 的「面板全滅」是兩件事，前任的教訓不適用於這種情況

教訓

1. 三個啟動坑（已入 skill 第二節與掃描卡樣板）：
   • skill 只能由決策者親手打指令（disable-model-invocation: true），模型叫不動；繞路自己叫 Workflow 也被作業書禁止——手工拼出來的報告會宣稱跑過根本沒跑的驗證
   • 啟動指令必須單次送出，換行會被拆斷。症狀是「什麼都沒發生」，極易誤判成工具故障或環境不支援。本棒實際因此誤查了 /config 的 Dynamic workflows（結果是 true、與此無關），白繞一圈
   • 跑起來後按 Esc／Ctrl+C 會砍掉整個 workflow，留下空殼 run 目錄＋killed 狀態。與撞額度的處置完全不同——撞額度可續可撈，被砍無可續無可撈只能重打
2. 「面板全滅」與「撞額度續跑」要分開判，判準是看 stamp 的 verification.status 與 verification_runs，不是看有沒有出現額度錯誤訊息。看到錯誤就宣告這棒廢了，會白白丟掉一份可用的產出
3. 密鑰專項（secrets pass）是免費的額外收益，值得每棒都設 focus。N2 六條裡四條是 scope 外的、全由密鑰專項掃出。其中 .env.test 那條與決策者當天稍早自己發現的是同一件事——工具獨立驗證了它，還多查出該檔存在於 origin/main 與另外十一個推送過的分支；F4／F8（POC DB 密碼、blsadmin 管理員密碼硬編在腳本裡）則是全新發現
4. .env.test 事件的判準已寫進 .gitignore 註解：檔名長得像範本不代表內容是範本，看的是這一刻裡面的值。 這個洞不是 ignore 沒設好，是 !.env.test 例外刻意放行，而放行的立論（「不含真實憑證的範本」）從 2026-03-08 首次進版控起就不成立

未完成交棒

• 🔴 POC 資料庫密碼與 blsadmin 管理員密碼仍然有效、尚未更換（N2 的 F4／F8）。與已撤銷的四把 API 金鑰不同，這兩組還活著。首腦已當面告知決策者建議儘快更換；CM-1608 只處理程式碼層面（硬編改環境變數），密碼更換是決策者的動作，不在任何卡裡。這是目前最急的一項
• 下一支掃哪個套件未定——排名表仍有效，首腦建議 jedi-common（地基，至今無算數掃描）或 jedi-integrity（CP 值最高）。新資訊：30 檔已驗證可行，切棒可比 15 檔寬鬆
• CM-1559 盤點已完整回寫 Notion，等決策者裁修法方向（三類分流＋「先第二刀再第一刀」的順序）。兩個順帶發現：① X-Tenant-ID: 0 已被 FR-069.16 擋死，根因仍在但已非可利用漏洞，優先級可降；② compliance.projects／workflow_executions／workflow_templates 三表有 policy 但 RLS 未啟用、且 projects 的 policy 無 super admin 分支，建議另開卡
• 所有修正卡（FR-077 四張＋FR-078 四張）維持不派，等 PM 統一安排
• S7 重跑、上版（jedi-iam 累積 13 張 Done 修正卡）——狀態同前任，未動

這一棒做了什麼：接手時 25 支套件掃過 7 支半。交棒時掃完 10 支，另完成 S7 重跑（讓 jedi-iam 七棒全部有效）與一份租戶隔離盤點。九棒掃描驗收、五次開卡、一次本機實測。未開卡發現從 18 項累積到 54 項。

開的卡（14 張）

修正卡一張都沒開——決策者裁定維持「PM 收集完所有掃描結果再統一安排」。

最重要的三個發現

1. 🔴 檔案存取「四層全空」（FR-086 三棒各自坐實）：一個能登入的帳號＋一個檔案編號，就能下載／預覽／永久刪除別家客戶的檔案，還能換發免登入通行證傳到公司外。 網址入口只驗登入／業務邏輯零檢查／查詢無範圍條件／資料表無租戶欄位且隔離關閉（B1b 用 DEV 實查坐實，本 arc 證據等級最高）。五個出口共用一道修法，套件側與宿主側必須同卡一起修。
2. 🔴 切子租戶仍看得到別家資料（FR-087）：13 張表隔離沒生效、4 支 view 繞過隔離。已實測：指向不存在租戶的鑰匙查待辦應 0 筆、實際 39 筆，專案應 0 筆、實際 213 筆。
3. 🔴 換掉驗章函式庫即可讓整套防竄改永久失效（FR-084＋T1b 實測）：驗簽章的 cryptography 落在開機不核對的第三方層。T1b 實測證實：掉包後開機閘門與四小時抽查同時放行被改過的檔案，且無任何警示。

決策（決策者裁，共 6 項）

1. FR-084 T1-2 開卡前先本機實測（→ 實測後確認成立，維持 HIGH）
2. FR-080 併入後，租戶隔離修正歸資安線，與 FR-086 那批一起看；FR-080 其餘收口七項歸 FR-080 首腦
3. 六支套件暫緩：detection／remote-agent（整併討論中）、task-platform／asset／log／system-core（合併套件可能還在調整）
4. 維持只掃不修：全部掃完再一起排修正順序、看哪些可以合併修
5. 修正卡一律不開（延續前任裁定）
6. 兩條可平行：一支掃描搭一件非掃描工作（掃描吃額度、盤點不吃）

推翻／修正了什麼

• 「每棒 ≤30 檔」→ 改寫為「40 檔可行，前提是一次只跑一棒」（FR-081 換來，本棒沿用驗證）。差別不在檔數，在有沒有和別的工作搶額度。
• 🔴 排名表整份失效（FR-080 整併後）：不只檔數過時，套件本身會消失或合併——jedi-participant（原排名第 5 建議）已被 task-platform 吞併；jedi-detection 從 151 檔長到 251 檔。排下一支前一律重跑 git ls-files 並確認套件還在。
• 交接檔的「三支 view」實為四支（FR-087 查證）；平台管理員不受開隔離影響（走的是合法的「上層看下層」，不是靠隔離沒開）——這兩處都是證偽，與找到風險同樣有價值。

教訓

1. 🔴 「交付四件缺一不可」寫進 prompt 才有用。連續兩棒（FR-085 C1、S7）掃完沒交付報告、沒 commit、Notion 沒回寫，由首腦補寫。在派工 prompt 加寫「① 報告 ② commit ③ 回寫 ④ 改狀態，掃描跑完 ≠ 這一棒做完」之後，C2／C3／B1／B1b／T1 五棒全部做滿。 此寫法已驗證有效，往後派工照用。（B2 仍漏一次，是唯一例外。）
2. 🔴 工具產出遠低於人工，已是常態而非例外。本棒九棒中，三棒工具正式發現為 0 條（C2／B1b／S7 部分），而那三棒的產出全是人工查證的——包含本 arc 證據等級最高的那一條（B1b 的資料庫實查）。「工具零發現」絕不可寫成「這個範圍乾淨」。
3. 🔴 開卡時的懷疑清單有一半會被推翻，這是健康的。FR-085 六個疑點三成立三證偽（兩條是死碼、一條分支進不去）；FR-086 五個疑點三成立兩推翻。報告要把「是什麼擋住了」寫清楚——證偽跟證實同樣有價值。
4. 🔴 「靠執行順序意外擋住」不等於安全。FR-086 的路徑穿越兩側各證偽一次，但都是因為先建構後寫入的順序碰巧讓攻擊字串追不上，不是有人刻意防的。重構就會長回來，要補測試釘住。
5. 🔴 平行 session 下 commit 一律用 git commit -- <檔名> 限定路徑。本棒最後 push 前踩到：用 git add 加檔後，對方在 add 與 commit 之間又 stage 了一次，兩支檔案搬移被誤收進 docs commit，重做一次才乾淨。這與 FR-080 交接檔記的「兩個 runner 共用 worktree 撞出訊息對不上的 commit」是同一類事故。
6. 收窄範圍能有效防越界（S7 重跑驗證）：第一輪 74 檔時 9 條發現有 8 條越界重複 S1；收窄成 29 檔並在卡片明寫「不要讀這些路徑」後，4 條候選零越界。
7. 盤點類工作不要用掃描工具（FR-087）：答案在資料庫狀態與 SQL，不在程式碼漏洞模式。人工快又準，而且這樣才能與掃描棒平行跑不搶額度。

commits（BE repo，feature/FR-075，全部已 push 到 b4b62288）

開卡與驗收共 23 顆，涵蓋 FR-084（含 T1b）／FR-085 三棒＋收口／FR-086 三棒＋收口／FR-087／S7 重跑／覆蓋率地圖重算與五支排序。最後一顆 b4b62288 是拆分事故後重做的（見教訓 5）。

未完成交棒

• 下一支已排好順序但未開卡：jedi-flow-engine 第一（XML 解析與授權缺口同時存在、真端點全在宿主、宿主比套件大）。完整排序與分兩個 arc 的建議在跨 arc 總表 §4，接手者直接看那段就能開卡。
• 待決策者裁的事項累積至 §6，其中最該先看的：FR-086／FR-087 那兩批要不要合成同一個修正規劃（同一問題的不同層，分開修容易各補一半）、問卷平台旗標、CM-1559 修法方向（本棒查出兩支背景排程與它相依，修它時會連帶弄斷且不報錯）。
• 兩個平行 session 在同一 repo 工作，交接時有一批未 commit 的授權相關改動（CM-1664，屬 FR-080 線），不要動它。

做了什麼

• 冷接自檢六題答完、唯讀盤點（21 支套件確認、五支候選重數檔數、平行 session 工作區狀態）。
• 讀碼切棒開卡 FR-088：套件 72 檔＋宿主 92 檔（總表估宿主 60-80，實數更多），按業務功能垂直切六棒 150 檔，母子卡一次建完連號 CM-1669～1675。
• DEV 唯讀實查流程相關 10 張表的隔離狀態：只有 flow_templates 開，其餘 9 張關，3 張無租戶欄。FR-087 只盤了 3 張。
• 新建 docs/features/FR-088-2609-flow-engine-security-scan/README.md；登記表、總表（§0.5／§1／§4）、STATE 同步。

首腦讀碼核過的三個疑點（未經面板驗證，寫進子卡當錨點）

1. 推進／回退階段時 project_uid 與 round_uid 各查各的、從不核對（stage_advance_service.py:529-587、stage_rollback_service.py:73-101；輪次表有 project_id 欄但沒人比對）。
2. 流程留言 GET/PUT 與任務證明兩支 GET 只驗登入（flow_engine_route.py:44-121、job_evidence_service.py:43-71）；element_variables／job_evidences 隔離關、零規則、無租戶欄。
3. force 雙版本：service 檢查外層 force（stage_advance_service.py:303），handler 讀 ctx.force（oscal_stage_handlers.py:41），:209 只在 ctx 沒有時才 setdefault。

決策（本棒無新裁決；沿用「只掃不修」「一次只派一棒」「修正卡不開」）

推翻／修正了什麼

• 總表 §4 的 flow-engine 數字：套件 80→72（攻擊面口徑、含 3 個 .bpmn 範例）、宿主「約 60-80」→ 92。
• 手冊第一節表格仍寫「≤15 檔」，與已裁決的 ≤30／40 不一致，未改手冊（手冊改動屬收尾類，等令）。

教訓

• 排序用「可利用門檻」比嚴重度標籤好用（決策者本日在總表 §0 定的判準）——本 arc 第 1 棒選 H2 而非疑點最「大」的 H1，因為 H2 只要登入＋猜編號。
• 先查資料庫再開卡：10 張表一句 SQL 就把「資料庫層有沒有兜底」定下來，六張子卡的「四層全空」檢查清單第四層直接有答案，runner 不必再查。

commits（BE repo，feature/FR-075，未 push）

• 本棒開卡 commit（見 git log docs(FR-088)）。

未完成交棒

• CM-1670 待派，派工 prompt 在 FR-088 README 之外由首腦回報決策者。
• 三件仍待決策者裁（總表 §6）：FR-086／087 合併修正規劃、問卷平台旗標、CM-1559 修法方向（含兩支相依排程）。

H2 驗收（同日追加）

• 交付四件齊全：報告／commit e9507d29（只含報告一檔）／Notion append 含 hash 與 run ID／狀態「修正待驗證」。「交付四件缺一不可」寫法第六次驗證有效。
• stamp verified、候選 11 去重 10、30 票全投、9 條達標、2 研究員全回，耗時 3 小時 10 分。
• 範圍內 3 條（F1 HIGH 證明清單讀／F8 單筆讀靠 bug 擋住／F9 留言讀寫），首腦逐條開檔、DEV 三個筆數（848／11,065／3,236）複核全對。runner 證偽卡片一項（is_admin 是平台超管，common/authz/workflow.py:38 註解錯）、人工補一條（流程定義 GET，併 P1）。
• 首腦裁 F9 維持 MEDIUM，釣魚面可升交決策者。登記總表 §3.1 第 49～51、§2.9 🅰／🅱 各加一列、§3.4 加三條。
• 教訓：範圍外密鑰專項再次吃掉 60% 票數（18/30），與 FR-086 B2 同型；卡片明寫「不要讀已掃過的路徑」對 scope 內有效，對密鑰專項無效（它本來就掃全 repo）。

H1 驗收（同日追加）

• 交付四件齊全：報告／commit 1e95823b（只含報告一檔）／Notion append 含 hash 與 run ID wf_1bb7fb14-b17／狀態「修正待驗證」。「交付四件缺一不可」第七次驗證有效。
• stamp verified、候選 12 去重 11、33 票全投、8 條達標、2 研究員全回、耗時 4 小時。
• 範圍內 4 條（F5＋F6 階段歷程 GET 零守門／F4 階段資訊不核對不擋／F8 署名可自填），首腦逐條開檔、DEV 五張表 RLS 複核（projects 關但 4 規則、project_participants 關 0 規則、project_audit_rounds／round_stage_transitions／stage_objects 關 0 規則）。
• 兩大疑點證偽：跨專案「寫」被 jedi-compliance-audit _check_role(e.project_id, …) 七處擋住（首腦逐一核對 :385/:445/:476/:538/:792/:823/:847）；force 雙版本只能跳過軟提醒（0:3 否決，首腦同意）。
• runner 抓到工具原文一處錯（宣稱 compliance.projects 有 RLS 限縮租戶，實查關），首腦複核屬實。
• 登記總表 §3.1 第 52～54、§3.2 第 13；§2.9 🅰／🅱／🅶／🅘 各加一列；§3.4 加「無租戶欄的表是 FR-087 死角」。
• 教訓：① 「靠下游擋」要單獨記成規劃相依——證偽了「可寫」不代表本層安全，修讀取面時必須連寫入面一起補，否則下一支 handler 就是洞；② 開卡時把「疑點若不成立、是什麼擋住」也列成要答的問題，runner 這棒答得很完整（每條寫入路徑逐一標第二道檢查行號），值得當樣板。

P1 驗收（2026-09-13 追加）

• 交付四件齊全：報告／commit ebd3b1e1（只含報告一檔）／Notion append 含 hash 與 run ID wf_c14982f8-67a／狀態「修正待驗證」。第八次驗證有效。
• stamp verified、候選 4 去重 3、9 票全投皆 3:0、2 研究員全回、耗時 7h15m（本 arc 最久；agent 12 個 1 個出錯）。密鑰專項零撈獲（套件目錄無憑證）。
• 範圍內 2 條（F1 分岔點走訪不記路＋重算翻倍／F3 讀範本無條件解析），首腦逐條開檔；F2（Nexus 明文）首腦改判範圍外＋重複：pyproject.toml 不在 30 檔 scope，且是 CM-1634 第三次撞到（runner 沒對照既有卡）。
• 五項證偽首腦重跑實測：XXE file:///etc/hosts 回 None、50,000 層巢狀正常、三支檔案路徑方法零呼叫者、eval／exec／ET.fromstring 零命中。
• 錨點（流程定義 GET）runner 答得完整：守門責任在宿主、套件 RLS「規則 4 條開關關」等於沒有；併入 §3.1 第 49～51 守門卡與第 43 條戊組，不另計。
• 登記總表 §3.1 第 55～56、§3.2 第 14；§2.9 新增 🅹「資源耗盡」組（55／56／CM-1638／第 31 條同型）；CM-1634 列補第三次確認與 poetry.lock 未入版控。
• 🔴 掃描期間版本漂移咬到下一棒：jedi HEAD 151c5f88→45f14ad9，P1 範圍只動註解與死碼（首腦逐檔核對），但 P2 範圍的 plugin.py 拆成 plugin/ 五檔，P2 scope 由 42 重算為 49，派前必須重寫卡片。
• 教訓：① runner 報的每條都要對 scope 清單與既有卡——F2 兩項都沒過，三棒裡第一次出現（H2／H1 的範圍外都自己標對了）；② 平行 session 動同一套件時，掃描結束要 git diff <掃描版本> HEAD -- <scope> 一次，不只看行號還要看下一棒的 scope 還在不在；③ 證偽要「重跑」不要「重讀」——XXE 三題首腦各跑一次只花一分鐘，比讀 runner 的敘述可靠。

H3 驗收（2026-09-13 追加）

• 🔴 runner 未交付四件（無報告、無 commit、無 Notion 回寫、狀態 Not started），掃描本身完整跑完（stamp verified、30 票全投全 3:0、5 條降級、2h16m）。首腦依手冊第三節第 3 點補寫報告 scan-H3-flow-template-management.md。本 arc 第一次、全計畫第四次（C1／S7／B2／H3）；派工 prompt 已含「交付四件缺一不可」仍漏——推翻「寫了就有效」的結論：五連中之後第六棒失效，此寫法降低機率但不保證。
• 範圍內 2 條（F7 validate 端點任何登入者打一次卡住工作程序／F10 範本讀取無 .read），首腦開檔＋DEV 實查（flow_templates RLS 開、select 規則含 is_builtin）＋gunicorn 4 worker／120s、body 50MB、無 limiter 三項核對。範圍外 8 條全舊案，1 條新位置（docs/claude/memory/reference_dev_login.md:11，memory 入版控帶進來的）併 CM-1608。
• 七項疑點首腦自答：宿主 flow_templates mapper 不解析 XML（壞 XML 讀不炸、發布會擋，與 P1 套件側兩張表兩種行為）；內建範本守門四處無遺漏；DTO 無敏感欄位；凍結副本不帶租戶的機制找到（套件鏈零 tenant_id、靠 jedi-common db_mw.py:64 flush 前自動填），且 DEV 實查修正 FR-087 戊組：191 筆裡只 5 筆快照、186 筆母版（jediadmin 119／blsadmin 72，127 筆連著執行紀錄）。
• 登記總表 §3.1 第 57～58、§2.9 🅹 加 57、🅰 加 58；§0 反覆模式改「第四次」；第 43 條戊組補修正；CM-1608 補新位置。
• 教訓：① 「交付四件」prompt 不保證交付——下棒起在 prompt 加「開掃前先回報四件的落點」，讓 runner 在跑之前就把報告路徑與 commit 指令打好；② 首腦補寫時要自己答卡片疑點，不只核工具那兩條——這棒最有價值的（FR-087 描述修正）是答疑點五時查出來的；③ 密鑰專項持續吃掉 80% 票數（24/30），對 13 檔小範圍尤其明顯。

H4 驗收（2026-09-13 追加）＋第九任首腦交棒

• 交付四件齊全（報告／commit c6c12e68／append 含 hash 與 run ID wf_ba3ef1cb-e96／狀態）——prompt 加「開掃前先回報四件落點」後 H4 做滿，H3 的漏交付沒再發生。
• stamp verified、候選 9、27 票全投、8 條 3:0、1 條 0:3、無降級、2 研究員全回、4h51m；scope 21 檔逐檔相同、掃描版本到 HEAD 零 diff。
• 首腦改判兩條：H4-1 留言零守門＝H2 第 51 條重複且 flow_engine_route.py 不在 scope；H4-3 projects RLS 關＝第 43／5／10 三處已記且首腦 H1 時已 DEV 實查。runner 開檔核對都正確，錯在沒對 scope 與既有卡——與 P1 F2 同型，本 arc 第二次。真正新的一條：viewer 可完成／退回別人任務（第 59 條，政策自陳是 2026-06-05 決策，進 🅷）。
• 八項疑點 runner 全答且修正卡片兩處猜測（儀表板三支不是 **kwargs；範本 XML 回寫對象視呼叫者）。範圍外 1 條新型態（system_configs 整表 dump 含 SMTP／LDAP／MinIO／GitLab）併 CM-1607。
• 登記總表 §3.1 第 59、§3.2 第 15、§2.9 🅰／🅷 各加一列、CM-1607 補四種型態、§3.4 兩條。

第九任首腦交棒（2026-09-13）

• 做了什麼：FR-088 開卡六棒（CM-1669～1675）＋ H2／H1／P1／H3／H4 五棒驗收，範圍內共 12 條登記（§3.1 第 49～59、§3.2 第 13～15），§2.9 新增 🅹 資源耗盡組；修正 FR-087 戊組 191 筆描述；重算 P2 scope（49 檔，已 append 卡尾）。
• commits（BE feature/FR-075，未 push）：d9d057e2（開卡）、306ef445（H2）、60d90cb1（H1）、12d0d06f（P1）、5b2165b5（H3 補寫）、本 commit（H4）。
• 未完成交棒：① P2 CM-1675 待派，prompt 照 H4 版；驗收時注意 P1 的接縫規則（P2 只看餵進 BpmnUtils 的是什麼）與新檔 api/guards.py／domain/ports.py；② P2 驗完即 arc 收口：母卡 append 六棒總表、FR README 一頁看完改終局、總表 §0.5 移到「已掃完」、SUMMARY 等令；③ 三件待決策者裁（總表 §6）未動；④ 手冊第一節「≤15 檔」與已裁決不符未改（收尾類等令）。
• 本棒推翻的結論：「交付四件缺一不可寫了就有效」→ 降低機率不保證（H3 漏），加「開掃前先回報四件落點」後 H4 做滿，往後兩句都寫。
• 本棒教訓：① runner 對 scope 與既有卡的比對是最常漏的一步（P1、H4 各一次），驗收第 3 步「越界檢查」不能省；② 平行 session 重構套件會咬到後續棒的 scope，每棒驗收跑一次 git diff <掃描版本> HEAD -- <下一棒 scope>；③ 首腦補寫報告時自己答卡片疑點，最有價值的發現常在那裡（H3 的 191 筆修正）；④ 密鑰專項在小範圍棒次吃掉 60～80% 票數，是結構性的，不必再記。

P2 驗收（2026-09-14）＋ FR-088 六棒收口 ＋ 第十任首腦交棒

• P2 交付四件齊全（報告／commit 31c0d7f6／append 含 hash 與 run ID wf_ca839a58-ac4／狀態）。stamp verified、候選 3 去重 2、6 票全投（1 條 3:0、1 條 0:3）、2 研究員全回、3h21m；scope 49 檔；掃描版本 ac9c152，掃描期間 jedi HEAD 走到 677f20f 但 jedi_flow_engine/ 零 diff。
• 0 條新：runner 唯一報的留言零守門自標重複第 51 條（本 arc 第三次撞到，這次 runner 自己對了 scope 與既有卡——H4 交棒教訓①生效）。價值在從套件側證實 element_variable_service.py:26/:50 也零檢查，補進第 51 條。
• 首腦獨立 grep 六目錄複核對照表：宿主零 import 套件 WorkflowExecutionService（整支重寫，卡片「宿主包一層」比實況保守）；JobExecutionService 在 DI 容器 :113 建 provider 但零取用 → 登記 §3.2 第 16「接好沒人用的插頭」。plugin/／api/guards.py／domain/ports.py 三支新檔無問題（guards.py 不是守門）。
• 被否決的候選有資訊量：「element_variables 沒掛 mixin 比姊妹表危險」被 0:3 否決，理由是姊妹三張基線隔離也全關——坐實四張流程表資料庫層零隔離；三張 FR-094 已接，element_variables 無租戶欄只能靠程式層。
• 收口動作：母卡 CM-1669 append 六棒總表；母卡＋六子卡改 Done（決策者令）；FR README 檔頭改終局；總表 §0 45 棒／11 支、§0.5 flow-engine 移入已掃完、§1／§3.1 第 51／§3.2 第 16／§3.4／§4；SUMMARY handoff/2026-09-14-FR-088-SUMMARY.md（subagent 寫、首腦核）。
• 本棒另做：記帳決策者 2026-09-13 五項裁定（viewer 唯讀只能留言／問卷不加旗標／FR-086 程式層那批現在開卡、upload_files 歸該批／CM-1559 順序歸 FR-094／51、55、57 升 HIGH），總表 §6 重編 18 項分四組（12 待裁＋6 已裁記帳）；兩份交接 prompt（FR-086 側、FR-094 側）已交決策者。
• commits（BE feature/FR-075）：4a4092f5（§6 重編）、05e81f6e（五項裁定）、bf14cda8（upload_files 歸屬）——這三個已隨平行 session 的 push 出去；17664009（P2 驗收＋收口）與收尾 commit（SUMMARY／STATE／LOG／memory，見 git log）未 push，等令。
• 本棒教訓：① 接手時先確認角色——本棒開頭把自己當 runner 跑了 pre-flight，決策者糾正後才切回首腦；派工 prompt 第一行寫「你是首腦」或「你是 runner」可省一輪。② §6 待裁清單是給決策者看的，每棒驗收完要問「這棒有沒有新增待裁的事」——viewer 那件 H4 驗收時寫在第 59 條末尾「先問決策者」，卻沒進 §6，決策者從清單看不到；同型的還有「三條 MEDIUM 要不要升 HIGH」（三棒報告都寫「PM 可升」但沒進 §6）。③ 決策者看不懂編號——問「要裁什麼」時回了 A1／A2／§3.1 第 59 之類，被打回；改成每題「現況一段＋選 A／選 B」才答得出來。白話規則對待裁清單同樣適用。④ 對照表比發現更有價值：P2 零新發現，但「宿主沒接套件那支」推翻了開卡假設，且揪出一個未來陷阱；掃「零件套件」時卡片要求對照表是對的，往後套件棒都要求。

做了什麼

• 開卡 FR-095：讀碼切棒，套件 163 檔＋宿主 54 檔＝七棒 217 檔，按「可利用門檻」排序 P1 → H1 → P2 → H2 → P3 → P4 → P5；母卡 CM-1779、子卡 CM-1780～1786 一次建完連號。首腦親開檔核六個疑點寫進子卡當錨點；DEV 唯讀實查 11 張表隔離全關、9 張無租戶欄。commit 747bd1be。
• P1（CM-1780）驗收通過：交付四件齊全（報告 commit 437fc9a9 只含報告一檔、README fa87a524、Notion append 含 hash 與 run ID wf_b2dc8f24-2f9、狀態「修正待驗證」）。stamp 首腦親開；範圍內 2 條工具發現（4 條去重）＋3 條人工發現逐條開檔，無改判；卡片七項疑點全答（五成立、一排除、一大致健康）；越界檢查 4 條候選全在 39 檔內、密鑰專項零撈獲。
• 登記：總表 §3.1 第 60～64（P1-1 HIGH／P1-2 MEDIUM／P1-3 MEDIUM／P1-4 MEDIUM／P1-5 LOW～MEDIUM）、§3.2 第 17～19（三條非資安）、§2.9 🅰 一列、§1 一列、§3.4 一條、§0 三格、§6 A 組一條待裁；FR-095 README 加「一頁看完」P1 段＋「P1 驗收」段；STATE 就地更新。
• scope 漂移檢查：掃描版本 df85e350 到套件 HEAD 9a0b489，participant/ 零 diff；H1 scope 自 747bd1be 到 BE HEAD 零 diff，可直接派。

決策

• 決策者 2026-09-14 解除四支合併套件（task-platform／log／asset／system-core）暫緩，理由：整併已收口、21 支 1.0.1 已發版；第一支掃 jedi-task-platform。detection／remote-agent 決策者未提、維持暫緩，要不要一起解凍已列總表 §6 第 12 項。
• 首腦裁 P1-1 維持 HIGH（面板 MEDIUM／HIGH／MEDIUM 取 MEDIUM、runner 升 HIGH）：門檻只要登入、不需任何編號、空請求跨客戶 751 筆含登入帳號與角色，與 FR-086「登入即可跨客戶取檔」同級；面板降級理由「資料敏感度中等」，但依決策者「可利用門檻」判準應為高。
• H1 補一檔：開卡 runner 報 5 支不在 brief 清單的宿主檔，首腦裁 di_containers/flow_engine/workflow_excution_containers.py 補進 H1（DI 接線，H1 變 35 檔、arc 共 217），其餘 4 支不入。
• 新增待裁一條（總表 §6 A 組）：六支成員服務「有注入守門服務才檢查權限」這種寫法要不要整組改掉——「沒注入就拒絕啟動」治本但要動 project_service.py／module_frame_service.py 四處內部呼叫；「維持條件式只補 P1-3 那支注入」最小改動但形狀留著會再長回來。

推翻／修正了什麼

• 開卡 runner 報「5 支漏網宿主檔」→ 首腦裁 1 補入 4 不入（其餘四支不在攻擊面或已由 FR-088 掃過）。
• runner 報 P1-1 比卡片描述更嚴重：卡片寫「知道任一專案編號就能讀走別家名單」，實際連編號都不用給——查詢條件全非必填、repo 層把空條件當不過濾，空請求直接全表。首腦開檔同意，§0「反覆出現的模式」改「第五次，且這次連編號都不用給」。
• 卡片疑點 ⑤「查不到人回空 dict 會不會反向放行」runner 排除，首腦同意：user_directory.py 七處降級只影響顯示欄位，授權走 guard.py，兩者無交集。

教訓

• unverified 有第三種型態，看 reason_kind：findings-refused ＝ 面板完整跑完、票全投，只是渲染器把研究員路徑寫錯（多一層套件前綴）的那幾條退掉，正式產物 .jsonl／.sarif 少幾條。與「面板全滅」（FR-077 R1）、「撞額度續跑」（FR-078 N2）處置完全不同——此型態以 runner 手寫報告為準、被退的人工補回即可。已補進 STATE 自檢第 6 題。
• 「待 runner 核對」標記法有效：子卡把首腦已核的疑點標 ✅、未核的標「待 runner 核對」，runner 只開檔查未核的兩項（一成立列 P1-5、一排除），另自己補了三條人工發現＋交「套件公開方法 vs 宿主守門」對照表。首腦驗收省下一輪重核。
• 工具注意力全集中在鏡像候選，寫入路徑零著墨：12 票全投在讀取端點那 2 個問題的鏡像上（同一問題在 route 與 service 各報一次），六支 service 的新增／修改／刪除路徑工具一票都沒投；該面向的信心全部來自 runner 對照表。已列總表 §3.4。
• FE 契約風險要在開修正卡時再查：修 P1-1 要把 project_id 改必填，首腦 grep FE src/ 找 project-participants 零命中——可能 FE 用別的常數名，「零命中」不可直接當「安全」。

commits（BE repo，feature/FR-075，未 push）

• 747bd1be docs(FR-095) 開卡七棒（首腦）。
• 437fc9a9 P1 報告（runner，只含報告一檔）。
• fa87a524 FR-095 README 進度更新（runner）。
• 本棒驗收回寫（總表／FR-095 README／STATE／LOG／Notion）由首腦抽查後 commit，見 git log docs(FR-095)。

H1 驗收（同日追加）

• H1（CM-1781）掃完但 runner 未交付四件（報告／commit／Notion append／狀態全沒做，stamp 19:05 落地後 session 靜默）——全計畫第五次（C1／S7／B2／H3／H1）。首腦依手冊第三節第 3 點親核 stamp、逐條開檔、DEV 唯讀實查，再派補寫 subagent 落地報告 scan-H1-project-crud-and-wiring.md 並回寫總表／FR-095 README／STATE／LOG／Notion 五處。
• stamp：verified、24 票全投 8 條全 3:0、無拒收、dirty: true（平行 session 未 commit 改動，H1 scope 內 dirty 為零）；掃描版本 739a0a61 到 HEAD 的 scope diff 只有 module_frame_service.py +5 行（assert_scope_writable，只守改 scope 欄位）。
• 結論：範圍內 4 條新（全 MEDIUM）＋2 條鏡像＋3 條舊案重複（第 3／第 10／CM-1608），0 條否決。最嚴重的是摘要報告清單與歷史四支讀取只驗登入（project_summary_report_service.py:53/:73、_history_service.py:26/:31，同檔寫入都有 _require_participant）；稽核輪次選單零守門（project_service.py:487）；租戶管理員可改原廠公版控制項清單（resource_library_app_service.py:403/:411 raw SQL 繞 RLS，oscal.profile_imports／ssp_implemented_requirements 無租戶欄無 RLS）。
• 首腦改判一條：F1＋F2 HIGH→MEDIUM，理由是時序不是工具錯——掃描版本 15:03 時 project_summary_reports／_histories RLS 未開（工具評 HIGH 正確），CM-1800（18:52，commit aac15d06）掃後 4 小時用 EXISTS 繞 projects 補開，DEV 19:23 實查已開 4 條規則；跨客戶已擋、同客戶跨專案仍可讀，門檻不變範圍縮一級。
• 卡片七項疑點工具只碰 ③ 一半，其餘首腦自答：①②③ 成立但都是 P1 第 60／61／62 條的宿主側同一件事，不另計；③ 中 module_frame_service.py:242 的 enforce_role=False 首腦補查上游——route module_frame_route.py:117-118 有 @require_capability("module-frame.create")，開專案者成為 manager 是設計（FR-048 D5），不是漏洞；④ adapter 直接委派無 try/except；⑥ 專案啟動直寫 domain 是設計自陳、記為第五處繞過套件守門，登記 §3.2 第 20；⑦ 兩支 resolver 無新發現。
• 登記：總表 §3.1 第 65～67、§3.2 第 20、§2.9 🅰（65／66，「讀取忘記守門」第六次）＋🅱（第 67 條背後兩張表）各一列、§1 一列、§3.4 一條、§0 數字 77→81 與進度句；FR-095 README「一頁看完」加 H1 段＋「H1 驗收」段＋進度表＋front matter；STATE 棒次表與接手建議第 3 點。無新增待裁（H1-5 與 §6 A 組「有注入才守門要不要整組改」同一決策，已在該條備註六處繞過點）。
• 教訓：① 工具在宿主棒的注意力會被範圍內的 model／repo 檔帶出範圍——35 檔裡放了摘要報告的 model 與 repo，研究員順著追到 service／route 找出本棒最嚴重的一條，但本棒主題（接線與成員同步）24 票裡只有 3 票（F4）真正投在上面；切棒時把「只是資料層」的檔塞進宿主棒，會稀釋主題。② 嚴重度判定要核「掃描版本 vs 現況」的時序——平行 arc（FR-094）在掃描與驗收之間補了 RLS，工具當時的 HIGH 與驗收時的 MEDIUM 都對，報告要把兩個時間點都寫清楚，不然下一棒讀到會以為工具誤判。③ 「交付四件缺一不可」那段派工 prompt 這棒有帶仍然沒做——runner 靜默不是 prompt 沒寫，補寫成本（首腦親核＋一棒 subagent）已成常態成本，派 P2 時照帶不改。
• commit：本棒補寫（報告＋總表＋FR-095 README＋STATE＋LOG）由首腦抽查後 commit，hash 見 git log docs(FR-095)；Notion CM-1781 append 內「commit hash 由首腦 commit 後補」。

P2 驗收（2026-09-15 凌晨，排程觸發）

• P2（CM-1782）掃完，runner 交付四件齊全（報告 scan-P2-task-assignee-and-participant-tables.md、commit ddd52ed9 只含報告＋README 進度列、Notion append 含 hash 與 run ID wf_ae470f56-685、狀態「修正待驗證」）——全計畫第八次「兩句都寫」做滿，首腦不必補寫報告，只做驗收。
• stamp：首腦親開 verified、無拒收，候選 4／去重 2，面板 6 票全投（2 條全 3:0），研究員 2/2、未審 0，耗時 8,107 秒；掃描版本 ca60cfd8 到套件 HEAD 347ce49，participant/＋migrations/ 零 diff；下一棒 H2 scope 自開卡 747bd1be 到 HEAD 零 diff，可派。
• 結論：範圍內 2 條工具發現全屬實（P2-1 查詢清單零守門＋空請求全表 12,494 筆任務指派；P2-2 新增指派驗專案不驗任務歸屬）＋人工追加 4 條（P2-3～P2-6），0 條首腦否決。
• 首腦改判一條：P2-3「六張表隔離全關、基線未含」改記為事實變更——runner 掃描時（2026-09-14 15:08）屬實，但掃完 4 小時後 FR-094 第 9 棒 CM-1800（commit 2487725，18:53；DEV 19:17 套入）已把六張表 RLS 全開。首腦 04:05 DEV 唯讀複核：六張表 relrowsecurity=t、各 4 條 policy。不登記為新發現，改記事實已變更，出貨基線是否重產交 FR-094／FR-093 收口。
• 更正首腦自己開卡時的誤判：P2-6——首腦當時判「批次指派端點 FE 無呼叫者」，runner 重 grep 用對 glob 找到 TaskSetupView.vue:292 實際有呼叫、頁面是活的，後端恆回空是功能靜默失效不是死端點，建議另開卡。
• 登記：總表 §3.1 第 68～71（P2-1／P2-2＋P2-5／P2-4 根因／疑點①）、第 43 條戊組後補一句六張表 CM-1800 已開；§3.2 第 21～23；§2.9 🅰 一列；§3.4 一條；§1 一列；§0 問題累積 81→88；§6 A 組新增第 15 項待裁（共用底層「送空條件就回整張表」要不要在底層改掉，同型根因第三次撞到，升為待裁）、標題與 A 組計數同步 15→16／9→10；FR-095 README 進度表／一頁看完／P2 驗收段／front matter；STATE 棒次表與接手建議第 3／10 點。

教訓（P2 驗收追加）

1. 平行 RLS 線會在掃描與驗收之間改變事實，這是連續第二棒撞到（H1 的 F1／F2、P2 的 P2-3）——首腦驗收時一律要重查 DEV 並標時序（掃描當時 vs 驗收當時），不能只信 runner 掃描當下的實況。
2. 首腦開卡時的核對也會錯：P2-6 是首腦自己 grep 用錯 glob 誤判「FE 無呼叫者」，runner 重查抓到並更正——「首腦核對 ✅」不等於 runner 免檢，runner 對已核項目仍有疑就該重查，這次是對的。
3. 共用底層「不帶條件就回全表」根因第三次撞到（P1 成員名冊、FR-086 檔案清單、P2 任務指派），從「順手記一句」升級為總表 §6 正式待裁項——同型問題重複三次代表逐支補的成本已經超過一次性在底層治本的成本，值得決策者裁一個方向。

第十一任首腦交棒（2026-09-15）

• 做了什麼：FR-095 開卡七棒（母卡 CM-1779、子卡 CM-1780～1786，套件＋宿主共 217 檔）＋P1／H1／P2 三棒驗收（H1 因 runner 未交付四件，首腦補寫報告後驗收）；總表整份白話重寫（決策者點名 PM 看不懂，簡語歸零、套件表加「在產品裡做什麼」欄、未掃疑點標「未經掃描確認」）；OSCAL 權限模型記帳（決策者裁匯入＝建改、匯出＝讀）；21 支套件「一半在主專案」逐檔重盤（前次用 import 數誤算，結論檔在決策者桌面）。
• commits（BE feature/FR-075）：747bd1be 開卡、085f0ba7 P1 驗收、3a8da35e 總表白話重寫、685d9966 §6 第 14 項、d039d5d8 H1 補寫驗收、30b00860 P2 驗收；runner 的 437fc9a9／fa87a524／ddd52ed9。已 push 到 d039d5d8，ddd52ed9＋30b00860 未 push、等令。
• 未完成交棒：H2（CM-1783）待派；P3～P5 要不要跑待裁；總表 §6 第 13／14（半裁）／15 項待裁；P2-6 批次指派端點功能靜默失效待另開卡給 PM；FR-093 要掛回 trg_task_assignees_validate_job 觸發器（§3.2 第 22）。
• 本棒教訓（彙整）：
  1. 決策者看不懂的不是內容、是預設讀者——總表被打回後整份重寫，簡語清單與「未經掃描確認」標記已入交接 brief，往後每棒回寫照這語氣寫。
  2. 用 import 數判「套件功能有多少留在主專案」會同時高估與低估——21 支重盤後真正四支（flow-engine／task-platform／oscal-v2／compliance-audit）比例與前次估算不同，要逐檔開才準。
  3. 平行 RLS 線讓事實在掃描與驗收之間變動，本棒連續兩次遇到（H1 的 F1、P2 的 P2-3）——驗收一律重查 DEV 並標時序，判定寫「掃描版本 X 時未開、CM-xxxx 於 Y 開」。
  4. 首腦自己的開卡判斷也會錯（P2-6 grep glob 寫錯，誤判 FE 無呼叫者）——runner 對已核項目仍有疑就該重查，不能因為首腦標了 ✅ 就跳過。

做了什麼

• 接手第十一任（FR-095 任務平台線），讀完 STATE／LOG／跨 arc 總表／FR-095 README／首腦手冊後做唯讀盤點，未動任何檔即回報等令。
• 記帳決策者五項裁定（見下「決策」節），其中兩項改變了原本排好的路線圖。
• FR-096 開卡外包：首腦只寫派工單，實際開卡由 runner 做（commit 29c04c7f）。母卡 CM-1803、子卡 CM-1804～1806 三張連號。範圍是 jedi-system-core：套件 57 檔＋主專案宿主 25 檔＝82 檔，切三棒——P1 設定表全鏈（24 檔，jedi）→ H1 主專案接線（25 檔，BE repo）→ P2 選單字典（33 檔，jedi）。
• P1（CM-1804）掃完並驗收通過。runner 只補交報告，commit／Notion 回寫／卡片狀態三件由首腦補（未交付四件，全計畫第六次）。
• H1（CM-1805）備妥待派：檔數 25 已核、scope 從開卡 commit 29c04c7f 到 HEAD 零漂移、範圍內工作區乾淨。因決策者本帳號額度用盡、要換新帳號跑，啟動指令已交付決策者，未派出。

P1 驗收結論（無改判）

• stamp verified、候選 4／去重 4、面板 12 票全投、2 條通過（皆 3:0）2 條否決（皆 0:3）、研究員 1 派 1 回、零漏投、耗時 2 小時 39 分、掃描版本套件 327c283 且 dirty: false、run ID wf_881b24e3-df3。
• 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（F1）／73（F2）、§1 一列、§0 問題累積 88→90、§0.5 與 §4 的 system-core 改「部分掃過」、§2.9 F1 入 🅰 組、F2 入 🅲 組。

決策（決策者 2026-09-15 裁，五項）

1. FR-095 任務平台停在三輪（P1／H1／P2），H2（CM-1783）不掃了，卡留「未開始」不動。理由：剩三棒要問的問題前四棒已答完（同型根因第三次出現），同樣時間換去掃別支套件更有價值。被排除的：照原計畫跑完七棒——排除原因是邊際收益遞減，不是範圍畫錯。
2. 「送空條件就回整張表」要在共用底層擋，但分兩步走：第一步先盤點全站哪些地方是刻意要查全表的（碼表、排程、管理員總覽），並把這些地方改成明確標記；第二步才動共用底層。兩步之間可以隔很久，第一步先做不浪費。 被排除的：直接改底層——排除原因是不知道哪些呼叫者是刻意送空條件，直接改會把正常功能打壞。
3. jedi-detection 與 jedi-remote-agent 解除暫緩（原暫緩理由是「整併討論還沒定」，現已不再是阻礙）。連帶 CM-1595（全計畫唯一一張 CRITICAL）可以排進計畫、四張補掃卡隨時可派。本棒只記帳，未動總表 §6 第 12 項。
4. 下一支掃 jedi-system-core（＝FR-096），不掃遠端代理程式補掃。決策者原話「先從小的開始掃」。
5. P1／H1／P2 三棒按既定順序跑，一次只派一棒（沿用 FR-081 起的串行紀律）。

推翻或修正了什麼

• FR-095 H2 從「等令可派」變成「裁定停掃」——第十一任交棒時寫「H2 等令可派、合理停損點在 H2 之後」，決策者本棒直接裁停在 H2 之前。STATE 棒次表該列已改，卡片不動。
• 首腦開錯檔給決策者看：把 FR-095 的 README.html（索引頁）當成掃描報告開給決策者，決策者回「沒有掃描出來的問題清單以及建議修復方式」。清單一直都在，在 scan-*.md 的第 3 節。 不是報告漏寫。
• 決策者對「專案成員名冊本來就該能查全公司的人吧」的質疑是對的——首腦去查前端實際呼叫點後確認：挑人加入專案用的是另一支 API（/users/menu，回全公司帳號是正常設計），有問題的那支是「查某個專案已經有哪些成員」。先前報告的寫法讓這兩件事混淆了。

首腦本棒查出、尚未登記進總表的新事實（交給下一任決定要不要收）

• 「送空條件回全表」的全域盤點第一版已經做完：掃過全部 21 支套件，找出「查詢用的資料格式零必填欄位」共 17 支——任務平台 8（成員名冊 2／控制項層 4／流程參與者 1／任務指派 1）、jedi-iam 4（帳號／角色／部門／客戶）、問卷 2、公告 1、資產 1、系統核心 1（選單）。
• DEV 實查後，真正「程式沒擋、資料庫也沒擋」兩層都空的只有 3 支：project_participants、task_assignees、以及控制項層那批參與者表（RLS 全關、0 條規則）。其餘 13 支的表都已開 RLS、各 4 條規則——它們的隔離欄位繼承自共用母模板 TenantScopedMixinModel，所以在 model 檔案裡 grep 不到 tenant_id，但隔離是有的。這是個容易誤判的陷阱。
• system_menus 查過確定不是漏洞：DEV 實查 74 筆全是碼表（USER_STATUS／ENABLE_STATUS／ANS_TYPE 這類下拉選項），沒有客戶資料也沒有個資，沒有隔離是正確的。
• 判準（與決策者討論後成形）：看這張表的一筆資料有沒有「主人」——有主人（屬於某個客戶／某個專案／某個人）就該拒絕空條件；沒主人（碼表、公版、全站共用字典）回全表是正確的。看表結構就知道：有沒有「這筆屬於誰」的欄位。
• 這份 17 支清單就是決策 2 第一步盤點的起點，下一任可以直接拿來用，不必重掃。

教訓

1. 開錯檔給決策者看，害他以為報告沒有問題清單——判準：決策者要看「掃出什麼」時開 scan-<棒名>.html，不是 README；README 是「這個掃描在做什麼」的索引頁。
2. 決策者的質疑要當成事實線索去查，不要急著解釋——他問「成員名冊不是本來就該可以查全公司的人嗎」，去查前端呼叫點後發現他是對的，先前報告把兩支不同的 API 混在一起寫了。質疑通常指向報告的表達缺陷，不是他沒讀懂。
3. 報告寫「跨客戶的資料也一起回來了」，在驗收時可能已經過期——平行的租戶隔離線（FR-094）會在掃描與驗收之間補開隔離。這是連續第三棒撞到（H1 的 F1、P2 的 P2-3、本棒的 F1）。驗收一律重查 DEV 並標時序。
4. runner 未交付四件是第六次（C1／S7／B2／H3／H1／本棒 P1）。派工 prompt 該寫的兩句都寫了仍然會漏，機率降低但不保證。補寫已經是常態成本，排時間時要算進去。

commits（BE repo，branch main，未 push）

• 29c04c7f FR-096 開卡三棒（開卡 runner）
• d85be38b P1 掃描報告落地（首腦派 subagent）
• e352bb98 P1 驗收結論落地——FR-096 README 驗收段＋跨 arc 總表登記兩條
• 2b11bd54 rebuild FR-096 與跨 arc 總表兩個文件站＋總入口
• （b70cc44a 是平行發版線的 commit，不屬本棒）

未完成交棒

• H1（CM-1805，25 檔，BE repo）等令即可派，三項已核事實見上；要換新帳號（~/.claude-runner2）跑，啟動指令已在決策者手上。
• P2（CM-1806，33 檔，jedi）在 H1 之後。
• 17 支「空條件回全表」盤點清單尚未登記進總表，下一任決定要不要收。
• FR-095 P2-6 批次指派端點功能靜默失效，仍待另開功能卡給 PM。
• 總表 §6 第 12 項（detection／remote-agent 暫緩）本棒已被裁解除，但總表尚未改，下一任補。

留給下一棒：讀完 STATE 的「接手第一件事的建議」十點，等決策者發令派 H1，不要自己動。

做了什麼

• 驗收五棒： | 棒 | 卡 | 結果 | |---|---|---| | FR-096 H1 主專案接線（25 檔） | CM-1805 | 工具 2 條皆 HIGH → 淨新增 1 條（另 1 條是 P1 已登記的第 72 項重複）。runner 四件全未交、首腦全補（全計畫第七次） | | FR-096 P2 選單字典（33 檔） | CM-1806 | 零發現（1 條候選三票一致否決，首腦四個來源復核同意）。交付四件齊全。FR-096 三棒收尾 | | FR-097 L1 日誌轉送（39 檔） | CM-1811 | 工具 2 條中風險 ＋ 首腦補查 1 條 HIGH（工單重點①工具完全沒碰）。交付四件齊全（第九次） | | FR-097 L2 API 操作記錄（43 檔） | CM-1812 | 工具 1 條 HIGH（Excel 公式注入）＋ runner 人工補查命中 1 個已知缺口。首腦實查推翻報告一處時間點。交付四件齊全（第十次）。FR-097 兩棒收尾 | | FR-098 A1 設備全鏈（45 檔） | CM-1814 | 工具 1 條中等（另 1 條候選三票一致駁回）。首腦改判性質為產品決策題。交付四件齊全（第十一次） |
• 開卡兩個 arc：FR-097 jedi-log（母卡 CM-1810、子卡 CM-1811～1812，兩棒 82 檔）；FR-098 jedi-asset（母卡 CM-1813、子卡 CM-1814～1815，兩棒 60 檔去重後，共用骨架 27 檔兩棒重疊帶入）。A2（CM-1815）已於 09-16 派出。
• 五條新發現登記總表第 74～78、80 項（詳見下「推翻或修正了什麼」與「本棒的發現」）。
• 全面文件整頓（本棒最花時間的部分）與96 條逐條複查（本棒最有價值的產出之一），各見下節。
• 問題總表（risk-overview.md）中低風險改為逐條列表：中風險 36 條按「同一種病」分八群、低風險 37 條（§3.1 非高非中 20 條＋§3.2 全部 17 條）分五群加一獨立節。

本棒的發現（登記總表）

• 第 74 項（HIGH）：一個客戶的管理員可以改掉全公司所有人的登入規則。FR-096 H1。
• 第 75 項（HIGH）：一個客戶的管理員可以把全公司的日誌改送到他自己的機器。FR-097 L1，首腦補查、工具完全沒報。與第 74 項是同一種病的第二個實例——客戶層級的權限寫進全系統共用的設定列。
• 第 76／77 項（中）：日誌轉送整條路沒加密／沒過濾換行可塞偽造紀錄。
• 第 78 項（HIGH）：匯出操作記錄的 Excel 可被種公式炸彈，攻擊者不必登入（記錄動作發生在權限檢查之前）。
• 第 79 項（中）：兩張日誌表的按月存放已失效、保存期限完全沒生效。非新發現（已登記 docs/analysis/2026-07-07-known-pits-remediation-tracker.md 的 user-log#6），本棒價值在更正時間點（見下）。
• 第 80 項（中）：設備清冊四支讀取功能只驗登入不驗權限。性質是產品決策題不是漏掉——套件 jedi_asset/plugin/contract.py:27 自陳「read 兩項 BE route 不守（守門只在寫入類）」，首腦已開檔核對該句確實存在。

全面文件整頓

決策者反映跨 arc 總表「超級亂、整理過好多次都沒整好」。首腦掃過全檔後判定問題是結構性的、不是文字問題，派 subagent 重排：

1. §0.5 與 §4 原本都有「哪些套件掃完／沒掃／暫緩」兩份並存且已不同步 → 改成 §0.5 唯一來源、§5 只留「下一批怎麼排」。
2. §2.9 分組索引搬到 §3 之後（它整節引用 §3 的條號，卻排在 §3 前面），章節重編號，全檔 15 處交叉引用跟著改。
3. 標題數字與實列對齊（45 輪／80 項／3 支部分／5 支沒碰；§2 工單數 40→41）。
4. §8 座標整份重寫——補齊 FR-082～098 九個 arc 的連結、修正 FR-077 與 FR-095 兩處過期狀態、母卡行補三張。

96 條逐條複查

決策者問「問題總表是不是很多都已經修掉了」。派 subagent 逐條開檔＋DEV 唯讀實查：

• 8 條已修、4 條變了但沒修乾淨、84 條仍在、0 條查不到。
• 🔴 兩條「看起來修好了」其實沒有（第 34、45 項）——第 34 項的下載／預覽端點確實換上 @file_access_guard，但該守門實作（jedi-iam/jedi_iam/authz/signed_token.py:192-196）沒帶 ?st= 時退回 verify_jwt_in_request()，等於「只要有登入就放行」，歸屬檢查從未存在。首腦追到宿主注入點（core/plugins/file_upload.py:110）覆核屬實。
• 🔴 修正分布極度偏食：8 條已修裡 3 條是資料庫隔離（FR-094 那批）、4 條是套件小 bug 順手帶到。「只驗身分不驗歸屬」那一大組（超過 25 條）一條都沒被碰過——那正是總表自己標「最大一組、最該優先處理」的那組。這段期間補的是資料庫那道牆，應用程式那道門還是敞開的。
• 兩個數字在變大：system_logs 668,813 → 716,918 筆、upload_files 2,690 → 2,704 筆，兩張都是零隔離的表。

決策（決策者裁，本棒記帳兩項）

1. 第 74／75 項新增第四個修法方向（決策者在另一個 session 補的）：只給客戶自己的第一層租戶（總部）改，客戶底下的子公司／部門不給；root 租戶維持不開放。首腦已同步到總表與問題總表兩份文件，並註明該案套到日誌轉送表同樣要先改表結構（那張表也只有全域一列）。
2. 修正卡全部不開、只記錄（2026-09-16 重申，與既有裁定一致）。

首腦自己的裁決（兩項）

1. 第 37 項（永久刪除任何檔案）維持中等、從高風險移除——README 評中等、總表列高風險，是真衝突。它與同組第 34／35 項不同（那兩條是讀走與換發通行證外流，這條是刪除，破壞性大但不造成外洩），且三位檢查員一致評中等，無推翻依據。連帶修正高風險 25→26 條、群一 12→11、群六 3→5。
2. A2 卡片檔數採 42 檔版（見下「一個流程疏漏」）。

推翻或修正了什麼

• 🔴 FR-097 開卡前實查更正總表一處錯誤：§4 排名表原寫「日誌轉送的目標設定裡包含帳密」，逐欄核對建表腳本後確認不成立——只有主機／埠號／協定／開關。
• 🔴 L2 報告的時間點被 DEV 實查推翻：報告寫「9 月分區已建好、10 月才會發作」，實際 api_logs 與 system_logs 都沒有 9 月分區，備用表已堆 20,959 筆與 87,471 筆——早已發作半個月，方向對、時間錯且低估急迫性。
• 🔴 fc1cadb（2026-09-14，FR-094 CM-1788）改掉了 CM-1595 的核心前提：心跳、確認任務、回報結果三支現在都改成「先提權唯讀查出這台機器屬於哪個租戶，再切換成該租戶的機器身分執行」，租戶由伺服器自己查、不採信請求方自報（agent_enrollment_service.py:313-343、agent_task_service.py:87-137）。「跨租戶」那一半已被堵住，剩下的是「同租戶內 agent 之間能否互相冒充」。首腦建議 CM-1595 從 CRITICAL 降為 HIGH，但這要決策者點頭（它是全計畫唯一一張 CRITICAL，降級會改變優先順序）——尚未裁定。
• remote-agent 那條線四張卡不能照原樣派：套件從 42 檔長到 72 檔，四棒檔數全要重驗。R1b（CM-1599，密碼學核心 10 檔）已重驗：檔數仍是 10、零漂移（期間兩筆 commit 只動 logger 名稱與註解），可直接派；R2／R2b／R3 三張需要重寫重點清單。
• 三條總表描述本身寫錯，已更正：第 11 項 27→26 支；第 72 項說反了（原寫「四個租戶欄位為空」，實際 7 列中僅 1 列為空、其餘 6 列雜湊相同，共用密鑰的證據更強）；第 45 項「三支 API 都沒拿專案編號來用」只有查詢那支還成立。
• 第 22 項已實測坐實：複查在 log/app.log 實際看到明文密碼與可冒用憑證，「先花一分鐘實測」那步可刪，直接開工單。

一個流程疏漏

A2（CM-1815）卡尾的啟動指令是舊版——開卡時首腦用目錄結構估算共用骨架為 15 支，實跑 git ls-files 後發現是 27 支，於是把卡片內文檔數從 30 改成 42，但卡尾那條啟動指令的 scope 清單漏改了。runner 驗檔數時發現不一致、停下來回報並提出 A／B 兩版讓決策者裁——這個停下來問的動作是對的。首腦裁用 42 檔版，並在卡尾貼更正說明。少掉的 12 支裡有兩支不能少：plugin/assembly.py 與 plugin/runtime.py——本卡重點⑤（共用骨架的守門殼）就在 assembly 那支。

教訓

1. 🔴 工單的「重點看什麼」必須有人逐項回頭核——FR-097 L1 最嚴重那條（客戶管理員可把全公司日誌改道）是工具完全沒報、首腦補查才撈到的，而它正是工單重點①；L2 的工具只碰五個重點裡的一個。這是快篩模式的固有限制，不是工具壞掉。驗收時要把工單重點逐項打勾，沒碰的自己開檔查並標「（工具未報，人工查證）」。
2. 🔴 驗收時不要只問「有沒有補守門」，要看守門的實作——96 條複查抓到兩條假修，其中一條掛著名為「檔案存取守門」的裝飾器，實作卻是「沒帶通行證就退回只驗登入」。看到 decorator 名字就勾掉，等於被名字騙過去。
3. 🔴 累積式清單要定期複查——96 條裡有 8 條已被其他平行工作修掉，沒人回頭核對過；還有三條描述本身就寫錯（一條甚至說反了）。而且修正分布極度偏食，最大那組一條沒碰。清單只進不出會慢慢變成一份與現實脫節的文件。
4. 🔴 開卡時的估算要實跑驗證——A2 的啟動指令留著舊的 30 檔清單，是因為開卡時用目錄結構估算、後來改了內文卻漏改指令。runner 停下來問是對的；改檔數時要把卡片內文與卡尾啟動指令當成一組一起改。

commits（BE repo，branch main）共 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，等令。

未完成交棒

• A2（CM-1815）已派出，回來要驗收——重點兩件：工具有沒有碰卡片五個重點、A1 已查完的四件有沒有被重報。A2 驗完即 FR-098 兩棒收尾。
• 決策者兩件未表態：① 第 80 項（設備讀取不驗權限）是產品決策題，要問「這個決定還算數嗎」；② CM-1595 是否從 CRITICAL 降為 HIGH。
• remote-agent 四張卡：R1b 可直接派，R2／R2b／R3 要重寫重點清單。
• 修正分布偏食這件事本身沒人處理——「只驗身分不驗歸屬」超過 25 條一條沒碰，是否要單獨向決策者提，下一任決定。

做了什麼

• 驗收 FR-098 A2（CM-1815，42 檔）：驗證章 verified、3 候選 9 票全投、版本 cdb0d0f4 與 A1 相同零漂移。工具 3 條：F1 讀取不驗權限→併第 80 項（同一產品決策，contract.py:27 涵蓋兩張清冊）；F2 修改權限送 is_active:false 達成刪除→新登記第 81 項（低）；F3 page_size 無上限→第 31 項重複（根因 jedi-common PagerSchema）。卡片五個重點工具只碰①，②③④⑤首腦人工查證（兩表隔離差別無副作用／新增少 org 維度不構成跨部門寫入／OSCAL 引用走同一套 RLS／空條件歸第 70）。runner 四件全未交、首腦全補（全計畫第八次）。commit 4648367a。jedi-asset 兩棒收尾，§0.5 已掃完 13→14 支。
• CM-1595 卡片補「修一半」現況說明（決策者要求），隨後因下一項作廢其中一句。
• remote-agent 盤點：套件 76 檔；R1 42 檔清單只少 plugin.py（拆成 plugin/ 五檔＋api/ 拆出 guards／routing／routes／serializers，12 支任何一棒沒掃）；fc1cadb 把心跳／確認／回報／檔案下載四條改兩段式；R1b 10 檔零漂移；出貨 nginx 三檔與 installer 仍零行 ssl_verify_client；DEV 唯讀：remote_agents 1 筆、agent_tasks 79 筆、三張表 RLS 開不 FORCE。
• 🔴 推翻上一任的 CM-1595 降級理由：開檔比對 fc1cadb 前後——舊版 heartbeat :274-279 與新版 :345-350 都是拿 agent_uid 查列、該列租戶是什麼就用什麼，從未採信自報租戶；fc1cadb 收緊的是執行身分（super admin → tenant_context），沒有「憑證對應的機器＝請求宣稱的機器」比對，R1 F3 路徑仍成立。決策者裁：撤銷降級、回到 CRITICAL。 同步 README 10 處、risk-overview 6 處（最嚴重 0→1、高 27→26）、STATE 五處、CM-1595 卡尾。commit c0aedde2。
• 三張卡重寫（決策者裁三項）：①CM-1595 回 CRITICAL；②拆檔 12 支併 R2a（18→30）；③舊派工段留卡標作廢、新段 append 在卡尾「以本段為準」。R2a 30 檔（scanRoot 改 jedi-remote-agent 目錄）、R2b 13 檔（重點①改驗同租戶冒充後半、②改驗提權查詢是否為探測管道）、R3 16 檔（接線收進 core/plugins/remote_agent.py、⑧改驗宿主側有無自開後門）。三卡啟動指令已驗一行、路徑數對上。建議派工順序 R1b → R2a → R2b → R3。

推翻或修正了什麼

• CM-1595 降級理由不成立（見上）。教訓：「改成由伺服器查出租戶」≠「比對呼叫者身分」——前者只決定用誰的身分做事，後者才是擋冒充的那道門。驗收「守門修好了沒」要問的是「有沒有比對」，不是「有沒有查」。
• A2 runner 四件全未交（第八次）。
• 總表 §7 第 12 項指引誤指第 24 項（實為第 19 項），順手改正。

決策（決策者裁，本棒記帳）

1. CM-1595 撤銷降級、回到 CRITICAL（2026-09-16）。
2. 拆檔 12 支併進 R2a，不另開棒。
3. 三張卡直接改寫，舊段標作廢留著。
4. remote-agent 續行，先派 R1b。

未完成交棒

• 第 80 項產品決策題仍等決策者表態（設備與資訊系統兩張清冊只要登入就能看，這個決定還算數嗎）。
• R1b／R2a／R2b／R3 全部待派，一次一棒。
• CM-1595 卡標題仍寫 CRITICAL（未曾改過，維持）。
• 12 支 remote-agent 主專案接線（jedi-log 6＋jedi-asset 12 那棒）仍未開卡。

commits（BE repo，branch feature/review）：4648367a A2 驗收＋jedi-asset 收尾／c0aedde2 CM-1595 升回 CRITICAL／（本 block 之後一顆）FR-077 README＋STATE＋LOG。未 push。

做了什麼

• remote-agent 四棒全部驗收完畢，FR-077 這條線收口：
  • R1b（CM-1599，密碼學核心 10 檔）：09-16 20:40 驗收。通過 2 條皆中等——註冊通行碼沒有到期日（重複既有的 CM-1597，這次從「引用別人說的」變成親眼看到）、以及越界撈到 jedi-issue 歷史檔裡第二把寫死的 GitLab 存取權杖（首腦用雜湊比對確認與先前那把不同、也沒有撤銷紀錄，登記總表第 83 項）。駁回 3 條。答完了 R1 留下的問題：密碼學核心確實被讀過。commit a3813c1f。
  • R2a（CM-1593，任務下發與狀態機 30 檔）：09-17 09:15 驗收。這是 remote-agent 這條線第一次真正把三位檢查員的投票流程完整跑完（15 票全投、每條都 3:0）。通過 5 條範圍內全新問題掛零，全部併進既有的 CM-1595／1596；其中「任務屬於哪個客戶，是由呼叫的人自己給的編號決定」這條 3:0 通過，坐實了 09-16 首腦推翻降級的判斷。
  • R2b（CM-1601，檔案取用與連線 13 檔）：同日驗收。通過 4 條皆中等，檔案下載也是由攻擊者給的代理程式編號決定屬於哪個客戶（同客戶內與跨客戶都成立），成為第五個「不檢查身分的對外端點」，首腦裁定併入 CM-1595。runner 順手更正總表第 47 項（upload_files 已於 09-16 補上客戶欄位與四條隔離規則，首腦到 DEV 重查 2,718 筆全帶客戶編號屬實）。交付四件齊全（第十五次做滿）。commits de170483（掃完）／2d43d46f（R2a＋R2b 驗收落地）。
  • R3（CM-1594，主專案這端的接線 16 檔）：09-17 11:50 驗收。21 票全投、版本 4bf687c0、跑 1 小時 41 分。通過 6 條（3 高 3 中）範圍內全新問題同樣掛零。🔴 但越界撈到一條真的新問題：有一份寫著資料庫帳號密碼的需求文件放在 docs/features/ 底下，而那個目錄每次推上主線就會自動部署成公開網站——首腦親自打開那個公開網址確認過，cmmgr、blsadmin、blsit 三個帳號名與密碼字串就在線上頁面看得到，任何人不用帳號不用內網就看得到。登記總表第 84 項（HIGH），已通報決策者換密碼。八個重點工具只碰到兩個，其餘六項首腦人工補查全乾淨。runner 四件全未交、首腦全補（全計畫第十一次）。
  • FR-077 總結報告落檔（docs/features/FR-077-2609-remote-agent-security-scan/SUMMARY.md）：五次檢查共 99 檔、通過 24 條，去重後併進既有修正卡 22 條、真正全新只有 2 條（而且兩條都是越界撈到的密碼外洩，跟遠端代理程式本身無關）。這條線真正的資安問題只有一個——CM-1595，它是六個檢查案裡唯一被評為「緊急」的，五次檢查有四次各自獨立撞到它，每次補一塊拼圖，現在樣貌已完整到可以直接動工。
• FR-108（jedi-detection 檢測套件）開卡：先按業務鏈垂直切成四棒 149 檔（母卡 CM-1872、子卡 CM-1873～1876，commit f35bfb20），隨後決策者裁重縮——剔掉 66 支「工具讀了不會有產出」的無邏輯檔（空 __init__、資料對映、純資料物件、倉庫介面殼、七支離線工具），縮成三棒 83 檔，原 D4（插件骨架，CM-1876）作廢併進 D1（commit e8adf554）。
• FR-109（jedi-survey 問卷套件）開卡：兩棒 81 檔（母卡 CM-1880、子卡 CM-1881 V2 填答全鏈 31 檔／CM-1882 V1 建題全鏈 50 檔，一次建完連號）。這支從沒掃過，主要目的是驗 2026-07 FR-048 補上去的「只有被指派者或專案管理者能改填答」有沒有涵蓋所有入口——所以建議先派 V2。首腦開卡時已開檔核出四個錨點寫進卡片：填答側的讀取端點完全沒有歸屬守門（任何登入者拿編號就能讀別人的填答與歷史）、討論的修改刪除不驗本人、15 張表雖全開隔離規則但只有 2 張有客戶欄其餘 13 張靠 join 反查（鏈斷了就等於有列就放行）、以及 socketio 廣播房間有沒有驗身分。文件在 docs/features/FR-109-2609-survey-security-scan/。

推翻或修正了什麼

• 🔴 「派出」這件事記早了：09-17 09:26 的 commit 3df8d1c8 把 R3（CM-1594）與 D1（CM-1873）記成「已平行派出」，但 09:30 實查兩處 scanRoot 根本沒有掃描目錄、卡片沒開始跑，只好用 a915d215 改回「待派」。教訓：只有在實際看到掃描目錄出現之後，才可以在 STATE 記「派出」——決策者說要派、或排程設好了，都不等於真的跑起來了。
• 🔴 D1／D3 被記成 09-17 01:49／01:50 起跑，實查沒有產出：本棒到兩處掃描目錄實查——D1 目錄裡只有掃描設定檔（scan-meta）與待掃檔案清單（target-files），沒有任何分析產出；D3 的目錄整個已經消失。決策者據此改判：D1 續跑、D3 整棒重派。這與 09-16 記下的「掃描不能排程無人值守」那條裁定互相印證（commits d047d1bd／ef6125e7）——排程送出派工說明後，runner 會停在「檔數已對上」等人打字確認成本，半夜排程等於白排。
• 跨 arc 總表裡 FR-109 那一列的連結誤指到 FR-108，接手棒已改正。

決策（決策者裁，本棒記帳）

1. 修正卡一律不開、等全部掃完分類分析後統一開（2026-09-17 重申並加理由：類似問題分散開卡會各修一半、修了又長回來）。FR-077 四張既有卡（CM-1595～1598）維持待派、不再新開；第 84 項公開站洩密屬「動作」（換密碼、清檔），不屬開卡。
2. FR-108 重縮成三棒 83 檔，D4 作廢併入 D1。
3. D1（CM-1873）續跑、D3（CM-1875）重派（09-17 12:30 後）。
4. FR-109 兩棒先跑 V2（CM-1881）。

未完成交棒

• D1 續跑中、D3 重派，兩棒回來都要驗收。
• FR-109 的 V2（CM-1881）待派；V1（CM-1882）排第 2 棒。FR-108 的 D2（CM-1874）排第 3 棒。
• FR-077 四張修正卡維持不開（照上面第 1 條，等全部掃完統一分類後再開）。
• 總表第 84 項的換密碼是個「動作」不是卡片——公開文件站上的資料庫超管密碼要換、要清檔，等決策者確認已執行。
• 總表第 80 項仍等決策者表態：設備與資訊系統兩張清冊只要登入就看得到，這是產品決策題，要問「這個決定還算數嗎」。
• session 中斷的事實要留紀錄：2026-09-17 11:57 首腦 session 收到平台回傳的 400 錯誤、內容夾帶二進位亂碼，整條對話無法續接。死前該做的工作都做完了，只差 commit 與回報；接手棒補了三件——改正總表 FR-109 列的連結、build FR-109 的文件站、寫本 block。

commits（BE repo，branch feature/review）：a3813c1f R1b 驗收落地／ac39a828 STATE 記 R2a 派出／a8986327 STATE 記 R2b 派出＋總表更正 jedi-detection 實數（251→155，原把測試檔算進去）／f35bfb20 FR-108 開卡四棒 149 檔／e8adf554 FR-108 重縮三棒 83 檔（D4 作廢併 D1）／d047d1bd＋ef6125e7 D1 排程取消改回待派＋記「掃描不能排程無人值守」裁定／de170483 R2b 掃完／2d43d46f R2a＋R2b 驗收落地／3df8d1c8＋a915d215 記 R3／D1 派出後實查發現沒跑、改回待派／（本 block 之後一顆）R3 報告＋SUMMARY＋FR-109 開卡＋站 build。未 push。

做了什麼

• 接手第十四任因平台回傳亂碼而中斷的 session，先把前一棒未 commit 的東西補完（改正跨 arc 總表裡 FR-109 那一列指錯的連結、build FR-109 的文件站、補寫第十四任的交接紀錄），再往下驗收。
• D1（CM-1873，jedi-detection 工具目錄＋租戶憑證＋守門殼，36 檔）驗收（09-17 13:45）：通過 4 條＝1 高 3 中，全部是新問題，登記跨 arc 總表第 85～88 項。其中第 87 項是跨多個套件的 9 條資料庫隔離規則方向寫反——本意是「母單位看得到子單位」，實際寫成「子單位反而看得到母單位」，首腦到 DEV 實查確認母子單位結構真的存在、資料也全在子單位，資安與功能兩面都在發作。驗證章這棒拿不出來（前一支被砍掉的 session 誤刪了產物目錄，與並行無關），首腦改從工作流的結果檔獨立核完 6 條候選、18 票。交付四件齊全（第十六次做滿）。
• V2（CM-1881，jedi-survey 填答全鏈，31 檔）驗收（09-17 15:30）：驗證章 verified、8 條候選 24 票全投、7 條通過 1 條駁回，淨新增 7 條（2 高 5 中）→總表第 89～95 項，無一條與既有清單重複。七條同一個病根：2026-07 FR-048 補上去的那道守門只裝在「寫入」路徑、沒裝在「讀取」路徑——填答側 6 條寫入全部有守門，8 條讀取一條都沒有（0/8），任何登入者拿到編號就能讀別人的填答與歷史。這是全計畫最大那組病「只驗身分不驗歸屬」最乾淨的一次實證。首腦另查安裝程式確認正式環境的服務是用受隔離規則約束的帳號 cm_app 在跑（scripts/installer/install.sh:1386），所以這七條的影響限同一家客戶內部跨專案／跨部門，不跨客戶。交付四件齊全（第十七次做滿）。
• V1（CM-1882，jedi-survey 建題全鏈，50 檔）驗收（09-18 01:30）＋FR-109 兩棒收口：50 檔單輪跑四小時、研究員七次被工具砍掉零產出，決策者裁拆成兩輪各 25 檔，兩輪都拿到 verified、24 票全投。通過 7 條＝5 條新＋2 條越界（越界兩條與 V2 那批重複、不計），淨新增 5 條（3 中 2 低）→總表第 96～100 項，另加一條到中低風險清單（Excel 匯入的暫存檔外洩）。冒出一個新病根：四支 API 用了 apply=False，等於把欄位驗證關成裝飾品、把整包 JSON 原樣展開進去（外界可以塞不該讓他改的欄位），已列進「下一批盤點建議」。FR-109 兩棒合計淨新增 12 條。
• D3-1（CM-1875 第一小棒，結果回收，4 檔 859 行）驗收（09-18 20:56）：驗證章 verified、3 條候選 9 票全投、研究員一派一回零重試——這是 D3 前後六次嘗試裡第一次順利跑完。通過 1 條（中）→總表第 101 項：裝在客戶機房的代理程式把掃描報告傳回來時，說檔名叫什麼系統就存什麼、完全不檢查，報告若取名 .html 並塞進一段程式碼，稽核人員在畫面上點「預覽」時會被瀏覽器當網頁執行。駁回 2 條首腦同意。四項人工查證齊全，其中 safe_http_fetch 的五道防線是正面案例。交付四件齊全（第十九次做滿）。「每棒不超過兩千行、含跨檔相接處」這個切棒判準第一次得到實證。
• D3 五次失敗的死因坐實、整棒重切：首腦翻工作流日誌拿到直接證據（見下「推翻或修正了什麼」第 4 點），決策者據此裁改切四小棒——D3-1 結果回收 4 檔 859 行／D3-2 任務綁定 5 檔 1,328 行／D3-3 狀態機與存取層 11 檔 707 行／D3-4a·4b 編排服務同一檔分上下半各跑一次。四棒的啟動指令都寫進 CM-1875 卡尾。
• 派 subagent（fable）對 jedi-detection 做一次架構規範檢查：結論是硬性違規掛零、三個軟性違規；最大一項是那支 2,498 行的編排服務該拆成四塊，但排到修正輪一起做（估 6～8 人日）。這份檢查全文沒有落檔，只把重點記進跨 arc 總表「重構待辦」那一段。
• FR-111（jedi-evidence-classification）開卡由平行 session 的首腦完成（commit 920a621b，不是本棒做的）：五棒 41 檔 7,849 行、母卡 CM-1946＋子卡 CM-1947～1951，該 arc 由那位首腦自派自驗，本棒只在 STATE 留一列座標。
• FR-109 母卡 CM-1880 收 Done。

推翻或修正了什麼

1. 推翻 runner 在 D1 的一項判斷——runner 說某支解密函式「沒有任何呼叫者、是功能缺口」，首腦開檔查證：它在主專案宿主那端有呼叫者，不是缺口。
2. 首腦自己前一任的裁定被 runner 的數據推翻、本棒接受：D3 第 3 次失敗時裁「研究員一直追跑出範圍外的接縫、追不完才停滯」，第 4 次 runner 把研究員每個動作攤開來數——32 次讀檔裡只有 9 次出界，而且每次出界後都主動回到清單，方向也都是對的。吃掉額度的不是讀檔，是寫。
3. 「多支掃描並行才害研究員被砍」這個假設也被否定：第 5 次照裁定單獨跑、機器上只有它一支，照樣全滅（09-18 10:38～18:40，十棒研究員全被砍、零產出）。
4. 🔴 最終死因（有日誌證據）：工具判定「停滯」的標準是研究員連續 180 秒沒有呼叫任何工具就砍掉（寫死、改不了）；而研究員的思考強度在工具裡固定寫死在最高檔，當它的上下文累積到 25～30 萬字時，單次思考就會超過 3 分鐘——不是卡住，是在想，想太久就被判死。先前四個假設（等待腳本打斷／多支並行／檔案太多／亂讀）全部收掉；把強度調高也沒用，因為研究員那端的強度不會變，只是多派幾個、每個要讀的一樣多。
5. 首腦自己初判某個函式「有 251 行」是錯的，實查只有 20 行。
6. runner 建議的「換到 jedi-detection 目錄底下開新 session 來跑」作廢——那個目錄讀不到主專案的規範檔與首腦手冊。

決策（決策者裁，本棒記帳）

1. 修正卡一律不開、等全部掃完統一分類後再開（09-17 重申並補理由：類似的問題分散開卡會各修一半、修了又長回來）。
2. 掃描一次只跑一支、不再兩帳號並行（覆蓋 09-16「平行派工」那條裁定）。
3. 同一個掃描範圍失敗一次就換變數，不重試同一設定——每步只改一個變數，最多四輪就有結論。
4. 每棒總行數不超過 2,000 行、含跨檔相接處，不只數檔案支數（09-18）；開卡時每棒先算行數。

未完成交棒

• D3 剩四小棒待派：D3-2（任務綁定，5 檔 1,328 行）／D3-3／D3-4a／D3-4b。 D3-2 的派工指令已交給決策者，但 FR-111 的 E1 正在跑，全機一次只能一支，要等它收完才派。
• D2（CM-1874，掃描基準全鏈 30 檔）待派，排在 D3 之後。
• FR-111 五棒由平行 session 的首腦管，兩邊輪流、一次一支，誰先派要問決策者。
• 100 多項問題的分類與修正還沒開始——決策者 09-17 裁「等全部掃完再統一分類開卡」。
• 總表第 87 項（9 條資料庫隔離規則方向寫反）要動到出貨基線，屬於會改變環境的動作，等決策者放行。
• 總表第 84 項（公開文件站洩漏資料庫帳密）的換密碼與清檔、第 80 項（設備清冊只要登入就看得到，是產品決策題），兩件都仍等決策者表態。
• 主專案這端的接線三塊還沒開卡：問卷 10 檔、日誌與設備與議題 21 檔、檢測 14 檔。
• 全套件搜一遍 apply=False 的盤點還沒做（V1 那棒撈出來的新病根）。
• jedi-detection 的架構檢查全文沒有落檔，只留總表「重構待辦」一段摘要。

commits（BE repo）：3f2775fc 補第十四任中斷前未 commit 的 FR-077 收口＋R3 驗收＋FR-109 開卡／034e25b5 D1 掃完／4c448091 D1 驗收落地／6582757d V2 掃描報告／46ea3eb9 V2 驗收落地／2502effa 記 V1 派出／84cd66d5 記 D3 重派後疑似再中斷／18411db9 D3 第 2 次失敗根因改判／3af0de27 V1 掃描落地／39b3c453 V1 驗收落地＋FR-109 收口＋記「一次只跑一支」裁定／3608a6c3 D3 第 5 次起四步計畫／f082512f D3 死因坐實、改切四小棒／9c194b37 D3-1 掃完／8c360811 D3-1 驗收落地。另 920a621b（FR-111 開卡盤點）是平行 session 的 FR-111 首腦做的、不屬本棒。未 push。

做了什麼

• D3 五小棒全收口（D3-2／D3-3／D3-4a／D3-4b 本棒驗收，D3-1 前任）：淨新增 3 條中——第 105（換工具時掃描範圍不重驗、超大網段逐台展開吃爆記憶體，首腦補查分派列第二落點）、第 107（開始掃描時客戶工具帳密解密後明文寫進 agent_tasks.params、零讀取端、無清理排程；首腦三 repo grep 複核）；D3-3／D3-4b 淨新增 0 但補了第 88 項行號、第 59 項影響面（viewer 能改狀態那道守門，檢測八支寫入端點同吃）。CM-1875 狀態 runner 已改修正待驗證。
• D2 三小棒驗收：D2-1b（第 112：zip 檔數上限在目錄展開後才生效）、D2-1a（第 113：宣告了「檢視掃描設定檔」權限七支讀取不執法、第 114：重抽無併發上限）、D2-3（第 115 🔴 高：上傳規則包被 cinc-auditor 當 Ruby 樣板執行→後端 RCE、一個租戶管理員打下整台主機與全部客戶；首腦開本機 metadata.rb:259 核對一字不差；第 116：網址型來源跳過壓縮檔驗證器）。FR-108 至此 2 高 11 中。
• D2-2 17 小時零產出：5 檔 1,632 行、25 隻研究員、工具自重試四輪；首腦翻 25 支逐字紀錄無一寫出候選、journal 零結果，沒有可撈的。改切 D2-2a（單檔 1,133 行、單跑）＋D2-2b（4 檔 499 行）；D2-4 改切 4a（分類骨幹 8 檔 772 行）＋4b（版本存取層 8 檔 837 行），指令全在 CM-1874 卡尾。
• 三線並行實證四次沒事（D3-3／D3-4a／D3-4b／D2-1b 各與另兩線同跑）——「並行」不是死因；但 D2-2 那 17 小時三線都在跑，單檔大棒仍建議單跑。
• 手冊派工樣板加「掃描跑完≠做完、四件缺一不可」（D3-2／D3-3／D3-4a 連三棒掃完沒交，首腦隔天才發現）；加了之後 D3-4b／D2-1a／D2-1b／D2-3 四棒自交齊。
• 決策者問「總表在哪、怎麼分類」：給了「修一套解一片」七組排序（讀取不驗歸屬 ~45 條最大、RLS 該開沒開、日誌、憑證、輸入不驗、回應夾帶、資源耗盡），並建議全掃完再修——決策者同意，連首腦提的三個例外也不先做。

推翻或修正了什麼

1. 🔴 研究員死因更正：前任坐實「研究員思考超 180 秒被判停滯」，本棒查社群坐實真因是 anthropics/claude-code#92424：研究員上下文 18～35 萬 token 觸發自動壓縮、壓縮 150～205 秒零輸出、看門狗 180 秒無輸出就砍——不是模型想太久、不是並行、不是網路。runner 量到「3 分 12 秒重複五次」就是這條線。掃描方式沒錯，是工具 bug；issue 仍 Open、Claude Code 2.1.278 仍重現、plugin 0.11.0 未動看門狗。
2. 「每棒 ≤2,000 行」不是判準，token 才是：D3-4 2,498 行單檔跑完、D2-1 1,480 行五檔死六次、D2-2 1,632 行（主檔 docstring 23%＋中文 4,600 字）死 25 隻。新規則：本套件安全線約 1,000 行或單檔 60KB；單檔棒優先於多檔跨層；看 journal.jsonl 的 failed 數第二個就停。
3. 推翻 CM-1874 卡片前提「15 條 route 零能力點」：首腦親數 10 支寫入全掛、8 支讀取不掛；第 80 項不撤。再由 D2-1a 更正 D2-1b「讀取不掛是合理設計」——能力點其實宣告了、是漏掛（第 113 項）。
4. 首腦自己：D3-2 驗收時用阻塞等待卡住回覆被決策者問「怎麼這麼久」——subagent 登記本來就要十來分鐘，不該阻塞。

決策（決策者裁，本棒記帳）

1. 三線並行（三帳號各一支）——覆蓋 09-17「一次一支」。
2. 修正一律等全部掃完再統一開卡，三個例外也不先做。
3. plugin 不升級到 0.11.0，D 線收完再升（下一 arc 整批用新版）。
4. 下一支開 jedi-oscal-v2（決策者確認兩半都沒掃）；首腦建議先接線（191 檔、122 支入口零功能權限）後本體（364 檔無入口）。

未完成交棒

• D 線剩四小棒：D2-2a 跑中（09-20 10:32 起、單跑）、D2-2b／D2-4a／D2-4b 待派。D2 全收才改 CM-1874 狀態。
• D2-1a＋D2-3 登記 subagent 尚在跑（第 113～116 項、D2-2 ⛔ 一列）——commit 落地前 STATE 表頭與總表計數是舊的。
• jedi-oscal-v2 未開卡：接線 191 檔照新判準估 10～15 棒，要先派 subagent 盤點切棒＋每棒重點。三支小接線（問卷 10／檢測 14／日誌資產議題 21）可合一棒先填空檔。
• 總表 §1 輪數與實列數曾落差兩輪（E 線平行加列），下一次登記叫 subagent 用實列數校正。

commits（BE repo，本棒）：86437d50 手冊樣板／ec65ee2e＋1ffea899 D3-2 登記／7958b4ce D2 切四小棒＋三線裁定／a75b2b4a D3-3 登記／6eba3585＋aeaf2753 D3-4a 登記／0edba712 D3-4b 登記＋D3 收口／f48d61ba D2-1b 登記／fb3932d0 死因更正／09d9ed60 #92424 續查。runner 側：d2d87902 D3-2／2e73a391 D3-3／e19ecfde D3-4a／8c96541d D3-4b／142a566c D2-1b／d7e75eb8 D2-1a／aa721fb3 D2-3。未 push。

追記（09-20 交棒前）：決策者先裁「全面暫停」、隨即改裁「D 線做完，其餘不做」——上游 bug 讓大範圍掃不完，FR-108 剩四小棒照派收完即掃描 arc 終點；jedi-oscal-v2 等全部不開。D 線收完後的工作轉為分類＋統一開修正卡。

做了什麼

• D 線四小棒全部驗收，FR-108 收口，掃描 arc 結束：D2-2a（1 條中→第 117 項：網址型放行明文 http 且不記指紋→代理程式執行被掉包的 Ruby 規則）、D2-4a（0 條，體質 §3.2 第 30：引用計數註解與 RLS 事實相反）、D2-2b（0 條，體質第 31：領域存取層安全性完全外包 RLS）、D2-4b（0 條，工具那條＝第 105 項獨立重現；體質第 32 規則清單表保護靠約定、第 33 jedi-common 分頁跨欄位 OR）。FR-108 最終 14 棒 83 檔、淨新增 2 高 11 中（高＝第 85、115）。
• 母卡 CM-1872＋三子卡全改「修正待驗證」（Done 等令）。
• 開 CM-1983 分類棒（opus、開 case 新 session）→ 產 security-scan-consolidated/fix-plan-draft.md＋classification-matrix.md：145 條分 44 組、建議 24 張卡，未歸組 0；首腦核過 117＋28 每條有歸屬、未越過已裁決事項。決策者裁：現在是盤點階段，不排修改計畫。
• 開 CM-1986 總表數字對齊（sonnet subagent）：六處對不上全改、§0 三十秒版重寫成定稿（20 arc／73 輪／約 1,894 檔／145 待開＋41 已開／1-35-61-51／已修 11 修一半 10 仍在 124）、STATE 舊風險數字同步；首腦順手切掉 §1 D3-4a 列誤黏的 D3-3 殘骸。
• 新裁定入表：「D 線收完掃描 arc 結束；後續是盤點，不排修改計畫（09-20）」、「監看研究員死活：failed 筆數與同 label 重複 started 兩種都數，任一第二次就停」、「小棒的價值是被砍後重試跑得完，不是不會被砍（D2-4b 837 行仍砍兩次）」。

推翻或修正了什麼

1. 首腦自己給錯：口頭說 FR-108 兩條高是第 87／115，總表實為第 85／115（87 在中風險段），登記 subagent 依總表訂正。
2. runner 說「工具不寫 failed」——不成立：D2-2 舊 journal 確有 4 筆 failed，兩種呈現都存在。

決策（決策者裁，本棒記帳）

1. D 線收完＝掃描 arc 結束，後續轉為分類＋統一開修正卡，現在不排修改計畫。
2. 第 83／84 項（撤銷寫死 GitLab 權杖／清公開站 DB 密碼）要不要立刻做，留待裁（09-19「三例外不先做」前提已消失）。
3. SHARED 值域三處不一致＋套件自帶建表／RLS 腳本零 SHARED（出貨基線待重產）——留 §7 第 18b 待裁。
4. 母卡 CM-1872 改 Done 的時機、36 顆未 push commit 的 push 時機，均留待裁。

未完成交棒

• CM-1983 分類草案未裁：fix-plan-draft.md／classification-matrix.md 只是分組建議，決策者未點頭前不可當修改計畫執行。
• 第 83／84 項、SHARED 值域、母卡 Done、36 顆未 push commit 的 push：四件事都停在「等決策者裁」，見上方決策段。

commits（BE repo，本棒）：dd288000 D2-2a 登記／12f63826 D2-4a＋2b 登記／fcfe834d D2-4b 登記＋FR-108 收口／a3576ca1 總表數字對齊／6d9ee3db D3-4a 殘骸；runner 側：f3774a23 D2-2a／5b2fb753 D2-4a／45ee0cad D2-2b／0656edc8 D2-4b／9ded830d CM-1983。同時段平行的資安報告內化整理線（CM-1982／1984／1985／1988）在同分支持續累積 commit，兩線合計未 push 約 36 顆。未 push。

追記（09-21）：決策者裁掃描重啟（覆蓋 09-20「其餘不掃」），交第十八任規劃；範圍未指定，首腦建議先 oscal-v2 接線 191 檔。

做了什麼

• 決策者裁掃描重啟後選定範圍＝jedi-oscal-v2 主專案側接線（待掃清單第 1 順位）。派 opus 盤點員切棒 → 開卡（母卡 CM-2000、子卡 CM-2001～2009）→ 實測發現兩棒破行數上限 → 拆 O3 成 O3a／O3b（新卡 CM-2010）、共用檔 _common.py 改掛 O9 → 最終十棒，除 O9 外全部 ≤2,000 行。
• 六棒掃完並全部驗收登記：O1（2 中→第 118／119）／O2（1 高 3 中→第 120～122）／O3a（1 高 1 中→第 123／124）／O4（1 高 2 中→第 125～127）／O5（範圍內 0，越界 1 高）／O6（1 高併 O1、1 中新增）。
• 每棒驗收都自己開檔核對高風險（不信 runner 自述），六棒逐條核對全部屬實、無改判，只有一條改嚴重度（O5 那條越界，工具判中、首腦升高）。

決策（決策者裁，本棒記帳）

1. 掃描範圍＝順位 1 的 oscal 主專案側接線；module_frame 不納入、另立獨立棒。
2. Word 解析器 O7a／O7b（7 檔 2,868 行）移出本批，性質屬「檔案解析安全」、與套件本體那批一起掃。
3. 壓縮窗口變數實驗中止不做（見下方「推翻了什麼」）。
4. O6 憑證掃描缺一道，接受缺口不補跑。
5. module_frame 單獨掃這件事先記起來、不現在開棒，手上四棒收完再說。

推翻或修正了什麼

1. 🔴 「122 支入口完全沒有權限檢查」不成立（總表 §0.5 原寫，來自前一任讀碼的疑點）。實查：入口是 89 支不是 122，而且 SSP 那條線權限有守、守在下一層（app service 層 require_manager 33 次＋require_participant 21 次；框架線 require_platform_admin 21 次），是 CLAUDE.md 明文允許的做法。確認零守門的只有 resource_library_app_service.py（530 行、9 段手寫 SQL）與 module_frame_template_ssp_route.py。照抄那句會讓研究員拿「找沒守門的端點」這張錯清單去掃、整棒誤報——已寫進每張卡與每份派工 prompt，總表數字也已更正。
2. 總表「191 檔」是錯的，實數 160 檔範圍界定／92 檔進掃描。191 疑似與 §3.1 第 43 項的「191 筆無歸屬資料」抄串行。已改。
3. 🔴 壓縮窗口變數（CLAUDE_CODE_AUTO_COMPACT_WINDOW）的實驗做不出結論，中止。首腦先誤判方向（設 10 萬＝範圍最低值，導致還沒開掃就先壓縮一次、53 秒）；挖 CLI 二進位確認可設範圍是 10 萬～100 萬、往上調確實吃得到（決策者質疑「加大就好了不是嗎」是對的，首腦原說「只能往下調」有誤）。但這批十棒全刻意切在安全線內、預期本來就會跑完，不論加不加變數結果都一樣，沒有對照組就問不出答案；且窗口拉大＝token 燒更兇，可能把「被看門狗砍」換成「撞額度面板全滅」（FR-077 吃過這個虧）。正確時機是將來某棒在正常設定下被砍、重跑時只加這一個變數，那時才有對照。
4. 兩次誤判「掃描死了」：看到 run 目錄只有設定檔就套手冊「工作流被砍」的形狀——但那形狀說的是最終停在該狀態，正在跑的掃描一開始本來就長這樣（工具先寫設定檔、再叫工作流，報告要跑完才出現）。空目錄不等於死掉，只等於還沒寫出東西，要看目錄有沒有繼續長大或直接問決策者畫面。
5. 登記員三次抓到 runner 的錯誤斷言：① O2 runner 說兩把金鑰不在既有工單內→實為 CM-1631 已涵蓋，它只查了報告點名的兩張卡沒掃整份工單總表；② O4 報告引述的註解行號錯（字串存在但不在它說的方法內）；③ FR-113 站進度表把同一個卡號標在兩列。驗收這層確實在發揮作用，不要省。

教訓

1. 🔴 切棒尺（每棒 ≤2,000 行）六棒實證有效、五棒零重試，壓縮被砍的老問題一次都沒發生。開卡前務必逐檔 wc -l 實算，不要信盤點員轉述——本棒盤點員兩棒都少算（O3 寫 1,853 實為 3,127、O4 寫 1,950 實為 2,570），照它的數字派下去就會重演 D2-2 那種十七小時零產出。
2. 🔴 派工 prompt 帶上前幾棒的收穫，命中率極高。O4 的 prompt 寫明「O3a 剛抓到 Excel 匯入分兩條路只守一條，你這棒的 Word 匯入很可能同型」→ 結果完全命中，而且證據更強（三條路守了兩條）。工具不照卡片清單走，但 runner 會。
3. 拆棒有時拆出價值：O3 拆成 O3a（權限題）／O3b（惡意檔案題）後，O3b 的重點清單才抓到 parser.py:42 用 read_only=False 整份載入記憶體這種只有從「惡意檔案」角度才會問的事。混在權限題裡掃很可能被忽略。
4. 面板沒跑完不等於這棒作廢（O6）：可信度要分兩層答——「這幾條存在嗎」開檔核對即可回答、比面板更可靠（打開那幾行就是事實陳述）；「只有這幾條嗎」只有面板跑完才答得出來，該棒不能記成掃乾淨了。
5. 排除也是結論：O6 runner 主動回報「派工卡要追的那個問題不成立」（合併決定只取三個欄位、其餘丟棄，夾帶不了東西）——寫出來下次不用重查，已登記。

本棒的派工 prompt 樣板（下一任直接改卡號用）

你是資安掃描 runner。這一棒是 FR-113 的 <棒名>。

卡片：CM-XXXX
<卡片 URL>

你這個 session：model 用 Opus 5（1M context），思考檔次用 high。
掃描工具的參數是另一回事——卡片裡寫的 --effort low 是工具的分工方式
（一個研究員完整看過整個範圍，而不是派四十個人各看一小塊），
不是叫你少花力氣，照卡片上的指令原樣打就好。

先把卡片從頭讀完再動手。兩件卡片裡有但我特別再講一次的：

一、你不能自己啟動掃描。驗完檔數後，把該打的那兩行指令回報給我，我自己打。
不要找繞路、不要自己叫 Workflow、不要自己派研究員拼報告。

二、報告和回報一律白話文。讀者是不懂程式的 PM 和不熟這個專案的新手工程師。

★ 前六棒的收穫，這一棒請帶著追：

已掃完六棒，找到三條高風險，全部是同一個病：**有人守了一半**。
資源庫的寫入路徑被三條不同的路打穿（編輯控制項清單、Excel 匯入、Word 匯入），
每一次都是同一支方法裡「這條路有檢查、那條路沒有」。

Word 那條最明顯：同一個判斷式三條分岔，前兩條有完整的權限檢查、旁邊還有
十幾行註解解釋為什麼要這樣守，第三條只有一行註解「驗存在」，就放行了。

還有一條形狀不同但同源：檢查「你管不管網址上那份計畫」，動手刪的卻是
「你另外給的那個編號」，兩者從沒核對過——而根因在套件側
（jedi-compliance-audit 的刪除方法查詢條件只有編號、沒有計畫範圍）。

所以請對每一支公開方法問三件事：呼叫權限檢查了嗎？有沒有用上它的回傳值？
所有分支都守到了嗎，還是只守了其中一條路？

<這裡放本棒特有的線索，例如 O5 那棒寫「你掃的是同一套邏輯複製六份的形狀，
最容易某一份漏掉守門，請六份並排比對」>

另外：掃描跑起來之後不要按 Esc 或 Ctrl+C，也不要掛監看輪詢等它。
啟動後跑一次 /workflows 記下 run ID 就好，工具跑完自己會回。

做完直接 commit 並回寫 Notion，不用等我。

未完成交棒

• FR-113 四棒未跑：O3b（CM-2010）／O8a（CM-2007）／O8b（CM-2008）／O9（CM-2009，2,505 行超標、派前必須再切）。
• O5＋O6 的收尾登記在交棒當下由 subagent 執行中（含 O5 那條越界 HIGH 獨立登記、O6 那條併進第 118／119 項並補「根因在套件側」）。接手者第一件事確認該 commit 是否落地（git log --oneline | head -5 找 O5／O6 登記那顆），沒落地要補。
• 風險總覽 risk-overview.md 尚未重算（首腦裁：整批掃完一次補，每棒改一次不划算，總表已加註記）。
• module_frame 單獨一棒：決策者裁先記著，四棒收完再說。
• 未 push commit 持續累積（本棒加約 10 顆），push 時機仍等令。

commits（BE repo，本棒）：bd19e888 開卡／77a8906d 拆棒修訂／2355006b O1 掃描（runner）／523eca86 O1 登記／f577ed27 O2 掃描（runner）／8feeaf28 O2 登記／8d0bf41c O3a＋O4 登記／905f210d O3b 卡號／b6430246 O6 掃描（runner）／1673a5d5 O5 卡號；O3a／O4／O5 掃描 commit 由各 runner 自行提交。未 push。

交棒後追記（2026-09-21 同日，第十八任）

• O5／O6 登記已落地（0a020c33d）：新增總表第 128 項（O5 越界那條高風險——下載範本端點檢查的是「你能不能讀資源庫」而非「這份計畫是不是你的」，可把別家公司整份系統安全計畫下載成 Excel；工具判中、首腦升高）與第 129 項（O6 淨新增，可把別人的文件掛到自己控制項再讀到檔案編號下載）。第 118／119 項已補上「根因在套件側、修法必須動套件」等三件事。
• 🔴 登記員留的那個待查，首腦已查完，結論是不必改：O6 報告說「跨公司那條被存放檔案那張表的資料庫隔離擋住」，登記員沒實查該規則、提醒若隔離也有缺口則第 129 項要升成跨公司。實查結果：該隔離確實存在（總表第 47 項記載 2026-09-16 已補上，有客戶欄位與擁有者欄位、規則四條、2,718 筆全帶歸屬）。第 129 項維持「同租戶跨專案」，不升級。
• ⚠️ 查證時踩到一個誤讀陷阱，下一任注意：首腦一度判成「隔離不存在、要升級」，原因是第 47 項的標題已加刪節線標示已修，但描述欄前半保留原始登記文字（「連客戶欄位都沒有、規則 0 條」），只讀開頭會得到完全相反的結論。總表裡這種「標題已修、描述留原文」的條目要讀完整列再下判斷。
• 登記員第三次抓到 runner 的錯誤斷言：O6 報告寫掛載位置在 :159／:188，實際是 :157／:184。登記用的是實際行號。三次分別是查錯工單卡、引述行號錯、卡號標錯——驗收這層要保留。

做了什麼

把八棒已交出但尚未登記的掃描結果整理進跨 arc 總表與 FR-113 站：

• FR-113 最後兩棒：O9a（CM-2069，Excel／Word 共用的資料轉換接縫，3 檔 916 行）／O9b（CM-2070，接線總裝與稽核階段掛鉤，17 檔 1,903 行）
• module_frame 那批六棒（母卡 CM-2073）：B1（CM-2078）／B1-item（CM-2079）／B2（CM-2075）／B3（CM-2081）／B4（CM-2076）／B5（CM-2074）

淨新增 16 條＝總表第 134～149 項（13 中、2 低、1 待評，零高風險），全部來自 module_frame 那六棒； O9a／O9b 兩棒淨新增 0——O9a 那三條全落在別棒已登記過的位置（總表第 123／125 項同位置重現），O9b 那一條與總表第 54 項是同一件事。

改到的檔：總表 security-scan-consolidated/README.md（§0 數字與進度一句話／§0.5 新增 module_frame 那批的逐棒表／§1 補八列／§3.1 第 134～149 項＋第 128／54 項就地更新／§4 🅰🅱🅶 三組／§5／§7 第 29 項／§8 座標與母卡）、 security-scan-consolidated/risk-overview.md（只在檔頭加棄用提示，未重算數字）、 FR-113-2609-oscal-host-wiring-security-scan/README.md（進度表補八列、O7a／O7b 改狀態、新增 2026-09-23 六棒驗收定案段）、本檔與 STATE。

決策

1. 第 128 項升級為跨客戶（首腦實查 scripts/init/02-schema.sql 核定）：oscal.system_security_plans 建表只有九個欄位、沒有任何客戶欄位；整個 oscal 區域只有五張表開了隔離，全部是匯入工作紀錄表（ssp_docx_parse_jobs／ssp_excel_parse_jobs／ap_docx_parse_jobs／ar_xlsx_parse_jobs／framework_parse_jobs），SSP 本體與附屬資料一張都沒開。程式這關沒擋、資料庫那關也擋不住，兩關皆空。嚴重度維持高風險，影響範圍從「同租戶跨專案」改成「跨客戶」。不另開項次、就地改第 128 項那一列。
2. B4 runner 自補的那條收低風險（第 149 項）：從框架版本下載空白範本只要求「資源庫可讀」，但產出的空白範本下拉選單附了全公司使用者 email、全部設備名稱與 IP、全部資訊系統清單。不跨客戶（四張來源表都有隔離），但讓只該看範本的人拿到全公司資產與人員清冊，與總表第 113 項同一類（權限粒度過寬）。⚠️ 這條三個檢查員沒提、runner 讀程式後自己判斷補的，登記時已標明未經投票。
3. O7a／O7b 移出本批：這兩棒從來沒開過卡（O7a 原本誤標成 CM-2008、與 O8b 重號，只是登記錯誤），決策者已裁跟 jedi-oscal-v2 套件本體那 364 檔一起掃——理由是內容（Word 內容抽取器、CMMC 轉接器與中介格式）是純解析／格式轉換，檢查重點是檔案解析安全，與本批「權限守門對不對」不是同一套判斷標準。FR-113 站進度表原記「待派」已更正。
4. O9b 那條不另計項次：推進／退回階段時操作者顯示名稱由前端送什麼就記什麼，與總表第 54 項（FR-088 H1 F8）是同一件事，改成在第 54 項那列追記，並補上 O9b 帶來的新資訊（同一包 ctx 還夾帶「強制通過」開關，與 §3.2 第 13 項同一件）。
5. B4 報告裡那條「資料庫密碼寫進版控並隨文件站公開」不另計：是工具「找寫死密碼」專項撿回來的既有案（只要設了 focus 就掃全 repo、與棒次範圍無關），總表早已登記在 §3.1 第 2／84 項與 CM-1629。登記前實際搜過總表與工單清單確認涵蓋，未照 runner 說法直接下斷言。

推翻／修正了什麼

1. 🔴 STATE「座標」段寫「三個 repo 都在 main」是過期資訊 —— 實際在 feature/review。已就地更正，並保留歷史說明（曾因發版線被切到 main）。
2. 🔴 FR-113 站進度表把 O7a／O7b 標成「待派」是錯的 —— 這兩棒從來沒開過卡（O7b 雖有 CM-2009 但從未派），已裁移出本批。表尾那句「O7a 的卡號待確認」也一併處理掉。
3. B3 報告引述的行號需要換位置才對得上：報告在「在哪裡」欄寫 F1＝module_frame_party_route.py:35、F2＝inventory:27、F3＝components:27、F4＝leveraged:38、F5＝system_characteristic:37、F12＝ssp_resources:42——那些行號指的是 get 方法體裡呼叫服務的那一行，不是缺守門的裝飾器位置。實際裝飾器在 party:26-28／inventory:19-20／components:19-20／leveraged:30-31／system_characteristic:29-30／ssp_resources:32-34。登記用的是實際核對到的裝飾器位置，服務呼叫行號另外附註（修的人要加的是裝飾器，寫服務呼叫行會讓他加錯地方）。
4. B3 報告的六條寫入項（F6～F11）行號同理：寫的 party_service.py:116／components:94／inventory:96／leveraged:105／system_characteristic:87／ssp_resources:63 都是方法體內呼叫下層的那一行，方法起點實際在 :86／:72／:77／:84／:66／:60，各自的 _require_mf 在 :172／:134／:137／:143／:115／:80。登記兩者都寫。
5. B1-item 報告把 F2 的引述寫成 :61-67／:84，實際 if scope is not None: 在 :62、assert_scope_writable 在 :65、寫入在 :84。登記用實際行號。
6. 🔵 B1-item 報告標「未驗證」的那段推論，首腦查完可以坐實一半：research 說「改流程圖的內容會落在翻譯表、而翻譯表沒有資料庫隔離」——實查 compliance.workflow_templates_trans 確實沒有任何隔離設定（scripts/init/02-schema.sql 與 scripts/sql/ 全搜零命中），而主表 compliance.workflow_templates:24717 有開。這一半成立，已寫進第 137 項並在 §4 🅱 組補一列。
7. B5 報告寫「save_import 第 329 行」需要補一句：:329 是 _resolve_template_ssp_id() 的呼叫行、也是該補檢查的位置，方法本身起點在 :315；寫入三處 :371／:383／:391 核對無誤。登記時把「方法起點／該補處／寫入處」三個位置分開寫。

教訓

1. 🔴 報告的「在哪裡」欄未必是「要改哪一行」——這批六份報告有三份把行號指向方法體內的呼叫行，而缺的東西在方法簽章上方（裝飾器）或方法開頭。登記時要自己開檔確認「修的人要動的是哪一行」，照抄會讓後面開卡的人加錯地方。這是登記員第四次抓到行號類問題（前三次分別是查錯工單卡、引述行號錯、卡號標在兩列）。
2. 🔴 「整支檔 grep 權限關鍵字零命中」這個紅旗，在這批出現兩次、結局相反（B2 假警報、B5 真洞）。它是值得查的訊號但不是結論——看到零命中要往下追一層看「這層本來該負責什麼」，不能直接當缺口也不能直接放行。
3. 🔴 六棒六種漏法，本身就是對「怎麼判斷一塊地安不安全」的答案：當初裁定 module_frame 不納入 FR-113，靠的是數「25 支入口有 15 支掛了權限檢查」。數字漂亮不代表守對了——B1 是隔四行一守一不守、B3 是六組一起漏、B5 是六支只漏存檔那支。這與第 128 項推翻那次、第 133 項那次是同一個教訓的第三次，應該當成往後排掃描順序的固定判準：不問「有沒有掛」，問「掛的那道問的問題對不對」。
4. 🔵 O9b 留下一條可複用的施工法：「本體小、接縫發散」型的棒次（研究員為了判斷守門有沒有接上會跑去全專案搜呼叫鏈、上下文堆爆），開工前先把接線事實查好寫進卡片（誰呼叫誰、守門在哪、租戶怎麼隔離），讓研究員不必出去挖。實證有效——第一次嘗試跑 12 小時 23 分被砍三次零產出，補了事實後第二次研究階段零重啟一次跑完。

未完成交棒

• module_frame 那批還差兩棒：B6（CM-2077，產生 Excel 檔案的底層七支）與 B1c（CM-2080，範本 YAML 匯入）。建議先派 B6——總表第 148 項（公式注入完整路徑）真正寫進檔案的動作就在它範圍內的 generator.py。
• B1-item 那一棒本身沒跑完（應投 6 票實投 3 票），那四支檔不能視為「掃過了」；第 138 項標「待評」，開卡前要先推完實際影響再定嚴重度。
• 第 135 項有一件要決策者確認才能修：/module-frames/menu 是「建立專案」畫面的下拉選單在用的，若有某個角色該能建專案、不該逛資源庫，加了權限檢查會讓他建不了專案——這屬角色設計，runner 判斷不了。
• 第 145 項有一件要決策者定奪：runner 建議一併補 api/oscal/routes/module_frame_template_ssp_route.py（三人面板沒讓它成案，因為回的只有識別碼沒有實質內容），理由是它回的識別碼正是後續 SSP 端點的入場券、且同批六支讀取入口全要補。
• 第 148 項有一件要決策者定：上游那一半（sheet_handlers.py:64 進來不中和）要不要一併處理——只做匯出端就能斷掉觸發路徑，兩端都做是雙保險。
• risk-overview.md 仍未重算（只加了棄用提示），照既有裁示維持不動。
• 未 push commit 持續累積，push 時機仍等令。

做了什麼

登記員（opus subagent）把 B6（CM-2077，產生 Excel 檔案的底層七支，7 檔 1,656 行） 與 B1c（CM-2080，用檔案整批匯入合規範本，8 檔 925 行） 兩棒登進總表，並把 module_frame 八棒整批收口。兩棒面板都完整：B6 2 候選 6 票全投、B1c 3 候選 9 票全投全確認，章皆 verified。

• 淨新增 4 條＝總表第 150～153 項：第 150 項（B6-1，中，任何登入帳號改暱稱就在全公司範本埋公式）／第 151 項（B1c-2，低，YAML 引用無上限）／第 152 項（B1c-3，低，Excel 檢核比對寫法平方爆炸）／第 153 項（B1c-4，中，⚠️ 未經投票、首腦核實，只要「建立」權限就能用匯入覆蓋既有範本）。
• 追記不另計：第 134 項（B1c-1 第二次獨立命中）／第 137 項（決策者裁 B1-item 不補跑、首腦核實登記、兩位 runner 跨公司推論分歧）／第 138 項（待評→中）／第 148 項（B6-2 寫入端確認、第二寫入點 generator.py:319、修法改 set_text_cell、帳號模組波及、openpyxl 觸發字元只有 =）。
• 數字：總數 179→183（未開卡 177→181）；中 86→89（＋第 150、153 項＋第 138 項待評轉中）；低 53→55；高 39 不變；待評 1→0；輪數 90→92；§3 173→177、§3.1 149→153。
• 改到的檔：總表 README（§0／§0.5／§1／§3.1／§4 🅰🅶🅹／§5／§7 第 29 項＋新增 E 組第 30～32 項／§8）、FR-113 站 README（進度表、兩棒白話結論、八棒收口段、刪掉「還差兩棒」的過期段）、STATE、本檔。

決策

1. B6-1 另立新項次、不併第 148 項：門檻（任何登入帳號）與波及面（全公司每份範本含空白範本）都不同，是新入口。
2. 第 148 項維持中：B6 面板三票判低、B4 那次判中；O3b 證實上傳也能存進公式、第 125 項讓「要先有編輯權」前提失效。
3. 公式中和只放「寫進格子」那一層，用 set_text_cell 不用加單引號：唯一必經之路／入口中和會改使用者原文／範本會被上傳回來。排程依賴 CM-2055 發版（38de2886，fix/security-b1 分支；主專案仍鎖 jedi-common==1.2.0）。
4. B1c-5 不是風險項次：掛在 §5「重建 add_module_frame」待辦上，註明 YAML 匯入須改走子項服務。
5. YAML 會不會執行程式——結案：yaml.safe_load，範圍內無 yaml.load／unsafe_load／pickle。

推翻／修正了什麼

1. 🔴 §4 🅶 組原本寫「第 148 項沿用那支加單引號的中和函式」是錯的——對會被上傳回來的範本不適用。已改寫該列，並把 FR-113 站同一段修法一起改掉。
2. B4 原修法只點 generator.py:578 一處，照做會造出「守了一半」；已把五處（六行）列成驗收項，並寫明 :543 系統自己的公式不能一起改。
3. FR-113 站「這批不能說掃完，還差兩棒」那段已過期，改成只描述 B1-item 打折處的現況段。
4. 行號抽查（登記員開檔核對）：lookup_builder.py:47／:91／:93、generator.py:137／:247／:319／:543／:578、yaml_to_module_frame_parser_adapter.py:14／:16／:35、module_frame_import_service.py:23／:52／:124-131／:169／:274、module_frame_import_route.py:46、module_frame_service.py:98-101、module_frame_item_route.py:64／:79、module_frame_item_service.py:62／:65／:84／:159／:227／:247、user_import_template_app_service.py:97、jedi-iam user_route.py:240／serializers/user.py:53、套件 commit 38de2886 內 export_safety.py 的兩支函式——全部對得上，零更正。

教訓

1. 🔴 同一個修法不一定適用同一種病的每個出口：單向匯出與會被上傳回來的檔，中和方式相反。登記修法時要問「這份檔會不會回來」。
2. 🔴 修法只點一處，自己就會造出「守了一半」：開卡時把所有寫入點逐一列成驗收項，比寫「修共用函式」可靠。
3. 兩位 runner 對同一件事推論相反時（第 137 項跨公司），不裁、不升級，標「開修正卡時實測」。

未完成交棒

• 等決策者發令：更新 docs/security-report/SUMMARY.md、解除 FR-114 對本批的排除。
• 總表 §7 第 30～32 項待裁（匯入覆蓋權限／第 148＋150＋帳號模組合卡／上傳端警告日誌）。
• 待掃順序照舊：三支小接線 → jedi-compliance-audit → jedi-oscal-v2 套件本體（含 O7a／O7b）。
• 本棒未動 Notion、docs/security-report/、FR-114、risk-overview.md；未 push。

做了什麼

• FR-115（母卡 CM-2086）八棒全收：W3／W6／W5／W1 於 09-23 驗收，W2／W4／W7／W8 於 09-24 凌晨驗收，全部通過、事實零改判。盤點範圍 46 檔＋W8 補掃 4 檔（FR-112 強制開始任務，CM-2106）。
• 登記員（opus subagent）登進總表：淨新增 12 條資安＝第 154～165 項（1 高 6 中 5 低）＋§3.2 第 34／35 項。總數 183→197（未開卡 181→195）；高 39→40、中 89→95、低 55→60；§3.1 153→165、§3.2 28→30；輪數 92→100。
• FR-116（jedi-compliance-audit，母卡 CM-2088）盤點驗收、九張掃描子卡 CM-2097～2105 一次建完；CM-2107（出貨基線 RLS 唯讀查證）開卡並結案。
• 改到的檔：總表 README（§0／§0.5／§1／§3.1／§3.2／§4 🅰🅲🅳🅷🅹／§5／§7／§8）、FR-113 站 README（第 130 項修法指路）、FR-115 站 README、STATE、本檔。

決策（決策者 2026-09-23／24 裁）

1. 第 75 項推翻原拍板：「只給總部管理員」擋不住（設定表全系統一列、轉送鏈一程序一條），改裁只給平台管理員改；每家客戶各自轉送是新功能，未採。
2. 第 154 項升高，並與 CM-2065 同批出貨（CM-2065 讓它惡化約 8 倍）。
3. 第 156 項併 FR-114 卡 2-7；第 155＋157＋158 項開「匯入匯出四入口＋清單」新卡與 2-7 同批；第 159＋160 項同卡、修前先查無指派列的卡住任務數。
4. §7 E 組三件已裁：匯入覆蓋要「修改」權限／第 148＋150＋帳號模組合一張卡／上傳端只記警告日誌。
5. W6-3「修好的套件沒發版」不登項次，改在總表 §0 加「已修要打折看」註記（合回時一次發版的設計，不是漏）；套件發版與 BE 合回同一批，不另寫清單。
6. 188／189 缺 8 張表保護不動，等 FR-114 合回、最終版一起升級，升級後必驗。
7. 兩份 IProjectRoleGuard 收成一份登 §5 重構待辦；簽發站鎖死基礎包勾選登 §3.2；AI 儀表板兩小修併 CM-2038 後續。

推翻／修正了什麼

1. 🔴 第 75 項原拍板失效（見上）；docs/security-report/ SUMMARY／M09 已內化舊拍板，待掃描收口後回寫（本棒不動）。
2. 🔴 FR-113 O3b 的錯誤指路：Excel 修法原寫「沿用 core/plugins/detection.py:338-340」，那是死設定；總表與 FR-113 站兩處改指 config/config.py:194-200，並註明那組數字照檢測規則包大小訂。
3. 報告引用的「第 N 項」有兩套編號：W1／W2／W4／W6 報告寫的第 7／43／45／60／63／85 項是 docs/security-report/SUMMARY.md 的編號，總表對應是第 49／80 項、CM-1630、第 11／45／93 項。登記時一律換成總表編號並註明 SUMMARY 編號。
4. 行號抽查：W4 報告 validate_import :197／revalidate_items :314／confirm_import :397／inspect :57 實為 :198／:315／:398／:58（差一行，已照實寫）；W1 引的四支事件處理器是修正分支 worktree 的行號。其餘 app_mw／job_service／repo_impl／detection／config／participant／adapters／resolver／container_runner／login_route 全對。

教訓

1. 🔴 掃描工具的 --scope 不能跨 repo（首腦讀 workflows/scan.js 確認）：只認 scanRoot 那個 repo 追蹤的檔，跨 repo 路徑被靜默丟掉、不報錯。FR-116 改成每棒跑兩次掃描（套件一次、主專案一次）。
2. 🔵 四線並行掃描實證可行：W2／W4／W7／W8 同時跑，零失敗（13～68 分鐘）。
3. 🔴 工具零發現的棒，runner 仍追出主要問題（W3、W5、W7 皆然；第 154 項這條唯一不必登入的高風險就是 W5 runner 追出的）——驗收一定讀兩層：工具清單＋報告本文。
4. 同一個病跨棒出現時，要橫看：W2／W4／W8 三棒各看到一兩個入口，合起來才是五個入口同一形狀；只按棒登記會變成五張各修一半的卡。

未完成交棒

• 等決策者發令：FR-116 九棒派工；jedi-oscal-v2 套件本體盤點；CM-2108 方案裁定；第 154 項轉告 FR-114；回寫 docs/security-report/。
• 本棒未動 Notion、docs/security-report/、FR-114、risk-overview.md；未 push。

做了什麼

• CM-2108（「任務屬於哪個專案」分析）跑完、首腦讀完並在修正分支 worktree 唯讀核對：CM-2039 的 resolve_project_id_for_job()（flow_control_job_repo_impl.py:1072）確實查指派表、三個呼叫點（job_service.py:163/237/313）都經過它。
• 與決策者一件一件裁完四件，打包成兩段 prompt 由決策者轉貼給修正線首腦；修正線已據第一段開 CM-2113（66b8a525e）。
• 登記員兩度被推論 gateway 打斷（500、ECONNRESET），兩次都查過目標檔零改動後接續；第三次改成「每寫完一支檔就 commit」，五支分五個 commit 落地（663433c22～51a827900）。

決策（決策者裁，本棒記帳）

1. CM-2039 合回前必須換判斷來源（否則未軟刪專案 25,891 張任務只有 77 張打得開）→ 轉修正線，CM-2113，且做成全系統唯一的歸屬判斷、開新檔、登記 domain-capabilities。
2. 問卷套件改成「注入判斷」，這次到位：決策者追問「這算沒解耦嗎？能不能像權限判斷一樣注入？」——是。主程式交給套件的是「原料」（task_assignee_domain_service），判斷邏輯留在套件（task_survey_guard.py:_resolve_project_id_by_task），於是套件自己發明了「取指派表第一筆」。改成照 IProjectRoleGuard 模式注入「task→project」判斷；指派表存取服務只留給通知（task_survey_service.py:496）與「是不是被指派人」。首腦原建議放下一批，決策者要趁發版前到位——實查範圍只有一支 84 行守門檔＋六支服務檔建構參數＋三支宿主容器，不大。
3. vw_user_job_queue 專案欄改讀輪次鏈，同一批（主線 migration，出貨基線待重產）。
4. 舊資料：DEV 6,270 張舊測試任務不清只記；188／189 升級後唯讀驗「未軟刪專案卻不在輪次鏈上的任務數＝0」，併 CM-2107 驗收清單。
5. 分析盤點出的其餘六處「任務推專案」決策者沒裁，交修正線順手判斷、做不完列回來。

推翻或修正了什麼

• 首腦原先對第 2 件建議「放下一批」——理由是發版時機，不是範圍；實查範圍後同意決策者「這次到位」，改成交修正線在 CM-2110 前同批做。
• W8 報告說「只有 11% 流程能反查專案」——CM-2108 查清那是指派表的覆蓋率，不是「流程反查專案」本身做不到；輪次鏈在未軟刪專案上 100%。525989b7a 當初「反查會誤擋九成 manager」的前提因此不成立。

教訓

1. 「注入原料」不等於解耦：套件拿到一張表的存取權，就會自己長出查法；要注入的是判斷本身（輸入→答案），這樣全系統只剩一份邏輯。往後審套件接線時，看宿主注入的是 domain service 還是判斷 port。
2. 修正卡的手測要涵蓋「最常見的資料形狀」：CM-2039 手測只驗已指派的任務，而 99.7% 的任務沒有指派列。
3. gateway 不穩時，長寫檔任務改成逐檔 commit，被砍只損失一支。

未完成交棒

• FR-116 九棒待派；jedi-oscal-v2 套件本體待開盤點卡；追 CM-2113 結果並回登總表；總表 §7 F 組三件。
• 未 push commit 持續累積，push 等決策者明示。

commits（本 block）：dd5d71796 FR-115／116 開卡、aa23a6355 FR-115 開七張、0578b384e FR-116 開九張、663433c22～51a827900 FR-115 登記五支、本 block 交棒 commit。Notion：CM-2106（W8）、CM-2107（C6，Done）、CM-2108（分析）由本任建卡。

做了什麼

• 接手盤點：FR-116 九卡與 CM-2113～2115 全 Not started、CM-2108 修正待驗證；jedi-oscal-v2 實數 363 檔／15,852 行（交接寫 364，對得上）。決策者確認新帳號額度夠。
• 出 C3 派工 prompt；決策者問並行 → 依 FR-115 四棒並行零失敗的實證，建議 C3／C2a＋C2b／C1b 三線同開，決策者裁准。
• 決策者問「後續其他套件」→ 查總表 §0.5：18 掃完、1 裁停、1 進行中、只剩 jedi-oscal-v2 本體。裁「開卡」→ 建 FR-118 母卡 CM-2122＋盤點卡 CM-2123（一次建完連號），FR-118 站 README、FR 登記表新列。
• 首腦唯讀實查寫進母卡：套件零支 import xml／lxml／defusedxml／yaml（整份匯入匯出走 oscal_io_service.py 1,660 行、import json）；目錄分布 261 支是宣告檔、68 空檔、判斷邏輯集中 app/service 24＋infra/repository 54＋domain/service 7＋infra/adapter 5；中文最重只有 cmmc PDF 解析器一支（459 字）。

決策（決策者裁，本棒記帳）

1. FR-116 三線並行：C3、C2a→C2b 同 runner、C1b。
2. FR-118（jedi-oscal-v2 本體）開卡，盤點與 FR-116 並行。

推翻或修正了什麼

• 交接文件與總表 §0.5 寫本套件的風險是「XML 解析攻擊」——首腦 grep 沒有任何 XML 解析器 import，盤點卡要求確認後改寫成 JSON 炸彈與大小上限。這條若成立，總表 §0.5 第 4 順位那格的「理由」要改。

未完成交棒

• 三線掃描＋盤點在跑，回「修正待驗證」後驗收七步；FR-116 C5／C1／C4a＋C4b／C1c 待派；追 CM-2113～2115；總表 §7 F 組三件。

做了什麼

• FR-116 九棒＋FR-118 八棒全驗收登記（C1b／C2a／C2b／C3／C1／C5／C1c／C4a／C4b；V2／V1／V8／V4b／W1／W2／V4a／V3），每棒首腦核 stamp、行號、DEV 唯讀重查，派 opus 登記員登總表＋站＋Notion。淨新增資安第 166～180 項（15 條：0 高 3 中 12 低）＋§3.2 第 36／37 項；第 66 項中→高（C3 面板 3:0 評高、同卡取最重）；第 133 項修法前提推翻（V4a：_require_no_references 查基準線指公版、正常流程零筆）。總表 197→214 條、100→126 輪。
• FR-119 收口四棒：盤點 CM-2140（主專案 826 支：380 掃／21 部分／425 沒碰，該掃 119 支切 U1～U12＋U13）、裁決稿 CM-2146（十九件）、打包 CM-2150（handoff-to-fix-line.md）、回寫 CM-2151（第一步差異表核過，第二步進行中）。
• 決策者逐件裁十九件（09-25），首腦每件先給建議與判斷理由。三件查證後改判：第 43 項「重生草稿」查出前端零呼叫、v1.20.0 release note 已點名退役→從「補階段檢查」改「拆網址」；第 46 項釐清「刪公版不傷客戶副本」後仍裁三處同卡換，理由改成「稽核依據可追溯、已引用版本不硬刪」；第 48 項首腦唯讀查三環境，STG／POC 只有總部 admin 帶旗標。
• FR-120 開卡 16 張（sonnet 開卡員，首腦實跑 scope 抽核），U1／U2／U3／DI 腳本四棒 09-25 派出。

決策（決策者裁，本任記帳）

1. 掃描線裁定與修正卡缺口一次打包不零碎轉（09-24）。
2. 主專案要掃、與修正線並行（09-25）。
3. 十九件裁定見 decision-draft.md 裁定表；關鍵：36／43／44 拆網址、37 稽核建議不可動、39 作廢表不清記功能待補、40 舊快照不動、41 套件自擋 frozen、42 退 CM-2037、46 三處同卡、50～54 主專案範圍（U7 掃、U12 併兩塊、DI 腳本先掃描後）。
4. 首腦裁決先給建議與判斷理由再問、不附和（09-25 決策者要求）。

推翻或修正了什麼

• 交接文件「jedi-oscal-v2 風險是 XML 攻擊」→ 套件零 XML 解析器、匯出只 JSON（FR-118 盤點）。
• V3 卡「同 uuid 出現在兩份 SSP」→ Word／Excel 兩路轉接器零 uuid、確認時全 gen_uuid（W2＋V3）。
• 第 133 項總表修法「照叫 _require_no_references」→ 永遠不擋，改查 module_frames.oscal_framework_version_uid（V4a）。
• FR-115 盤點「common/authz/ FR-085 C1 已掃」→ C1 掃的是 jedi-common 套件，主專案 9 支從沒掃（FR-119 盤點）。
• C3 runner「盤點檔 §5.3 錯、poams 有隔離」→ runner 看錯表（compliance.poams 舊表 vs oscal.poams 實存）。
• 首腦自己：C4b 收口報「3 中 5 低」登記員核為 2 中 6 低；CM-2151 卡寫「145→214」兩數字算法不同（runner 停下來問）。

教訓

1. 🔴 零發現棒靠實測：V4b／W1／W2／C4a／C4b 五棒工具零候選或估步數，runner 手做惡意檔實測抓到第 171～174／176／177／179 項；派工 prompt 要寫「讀碼有疑點就實測」。
2. 🔴 「只掃不修」被 runner 誤讀為「不能讀另一 repo」（V2），prompt 加一句就好了。
3. runner 引用編號兩套混用（SUMMARY #N vs 總表第 N 項）四棒寫錯，登記員都抓到；prompt 明寫「一律總表第 N 項」。
4. 登記員每次都抓到首腦一處錯（數字、對應項、行號），這層驗收不能省。
5. 決策者問「這是不是舊流程」時要查不要推：第 43 項首腦原建議「補階段檢查」，查了才知道網址早該退役。
6. 裁決要先給判斷理由：第 51／52 項首腦直接問沒給理由被糾正；第 41／46 項給了理由後決策者追問「這算 OSCAL 邏輯嗎」「刪公版不是不傷客戶嗎」，追問讓理由更正確。

派工 prompt 樣板（十行內，下一任改卡號用）

你是資安掃描 runner。這一棒是 FR-120 的 Ux（<棒名>）。
model：Opus 5（1M context）／effort：high／理由：研究員繼承主 session，Sonnet 會被看門狗砍。
卡片：CM-XXXX（母卡 CM-2152）
<URL>
BE repo ~/Projects/Billows/Audit-Manager/compliance-manager-be，feature/review 不切；工作區有平行線未 commit 改動，不碰不 stash，commit 限定路徑。<同時在跑的棒>，FR-120 README 進度表只改自己那列。
先把卡片從頭讀完。本棒只掃主專案側一次，scanRoot 指 BE repo，指令在卡上。
你不能自己啟動掃描：驗完檔數（N 檔／L 行）就停下回報「檔數已對上，可啟動」，把卡上那兩行指令原樣附上交還給我，我親手打。不要自己叫 Workflow、不要自己派研究員拼報告，這是刻意設計不是故障。
「只掃不修」是不改程式碼，不是不能讀另一個 repo；工具零發現時卡片「重點看什麼」每條逐支開檔答完、範圍檔逐支通讀才算做完；讀碼有疑點就手做惡意檔實測。
<帶著前棒收穫的形狀，一兩句>。runner 引用總表編號一律「第 N 項」。
報告與回報一律白話，讀者是不懂程式的 PM 與不熟專案的新手工程師。
🔴 掃描跑完≠這一棒做完：跑完後立刻交四件——白話報告 scan-Ux.md、FR-120 README 進度表自己那列、卡片 append（run ID＋commit hash）、commit——缺一不可，做完才回報。

登記員派工單樣板：見本任各驗收 Agent 呼叫（model opus／effort medium；先讀報告全文＋總表指定節；首腦驗收結論逐條列「照這個登不改判」；要改的四處 A 總表／B 站 README／C 子卡 append 狀態不改／D 母卡 append；E render_index；回報 15 行內含「對不上的地方」）。兩支登記員並行時要切開各自動的節。

未完成交棒

• CM-2151 第二步回寫驗收；U1／U2／U3／DI 腳本驗收；U5～U12、U10／U11、U13a／b 派工；FR-116／118／119 母卡 Done 等令；handoff-to-fix-line.md 等決策者轉貼 FR-114。
• 未 push 78 顆（038381493..3f6290400＋本 block），push 等令。

commits（本任，時序）：e0e17a5ff 接手＋FR-118 開母卡 → 19925da10 C1b＋FR-118 開八卡 → 8ac028f8c C2a → 7585b065a C2b → 10f3e7a8a V2 → fef21cdb0 C3＋V1 → 036737c86 V8 → 05b20a1c9 裁一次打包 → bf699f2a4 C1 → 7927a5c7e C5 → ecc7bac69 C1c＋V4b → dfe24bbd0 W1＋W2 → 9dc040a7a V4a＋C4a → 3ef11c640 C4b＋FR-116 收口 → fb37107f9 裁套件先做完 → 9929a7b64 FR-119 開母卡＋盤點 → 114c2ba03 V3＋FR-118 收口 → c599e3815 開裁決稿卡 → e31de61b1 盤點 Done → 48c82660c 裁決稿 Done → f974168f4 裁 50～54 → 87084e829 裁完十九件＋開第 3／4 棒 → 0871dd512 打包 Done → 3f6290400 FR-120 開 16 卡 → 本交棒 commit。runner 側 commit 穿插其間。

做了什麼

• 09-25 上午接第二十一任。驗收 DI 腳本卡 CM-2165：原版讀的是修正線 worktree（venv .pth 指修正線套件），退回補主線基準，🔴 7 處收斂為主線 3 處（77ec8e762，加 --package-root、主線／修正線兩份結果表）；驗收 CM-2151 總報告回寫第二步通過（去重後 198 件並列總表 214 項）→ CM-2165／2151 Done、FR-119 母卡 CM-2139 修正待驗證。交修正線清單補 1-8（修正線 DI 必填缺接 AgentTaskService.remote_agent_domain_service，a48a67b79）。
• 需求中心總入口補回 FR-113～120（停在 09-20 只到 FR-112，a73cca515）；doc-site-build skill 5.1 補「開新站也要 --hub-only」。
• FR-120 十四棒＋DI 腳本卡全收：09-25 派完並驗收 U1～U12＋U13a，09-26 驗收 U13b（淨新增 0，四條皆舊帳）。淨新增資安高 3／中 11／低 19（總表第 185～218 項，第 189 項落 §3.2）＋§3.2 第 39／40 項；§1 第 129～139 輪。登記分三次：U1／U3（adc11be5c）、U2～U13a 十一棒（222a13f80，驗收結論定稿 handoff-acceptance-brief.md）、U13b（6b8bb3c48）。
• 三個高：第 188 項 Google 授權回呼頁反射型 XSS（json.dumps 不轉義 < >，6 月 C12 修法不成立；不需帳號；首腦本機 HTML parser 重現）；第 192 項 init-folders 不核專案歸屬＋背景系統身分讀寫（U6 runner DEV 回滾實測 131 身分載出 102 專案並寫入 102 任務證據，首腦重查零殘留）；第 212 項修正線 CM-2054「深度==2 即總部」擋不住另一家客戶總部，寄信／LDAP 全站一列（首腦開修正線檔核判準）。
• 首腦本機重現或開檔核對：第 204 項摘要 PDF 白名單放行 svg 可打內網、第 205 項還原歷史版本不核歸屬（推翻面板 0:3）、第 162 項診斷遮罩六種寫法實測、第 207／209 項遮罩漏、第 217 項 wheel 內刪檔順序、第 218 項能力點缺掛。

決策（決策者裁，本任記帳）

1. 第 192 項要修（09-25）。
2. 第 193 項雲端資料夾分享由 anyone/writer 改 type=domain（或專案成員），root_folder_id 不回給無讀取權限者；既有資料夾一次性撤 anyone 授權（09-25）。
3. 第 194 項連帶：同一 Google 帳號不接兩家，接硬碟時擋（唯一約束 google_account_email＋錯誤訊息）（09-25）。
4. 第 182 項授權總開關改判要修：落地版拿掉 LICENSE_ENFORCEMENT_ENABLED／LICENSE_READONLY_GATE_ENABLED，放行需求走補發測試照；嚴重度低→中（09-25）。
5. 租戶模型結論：落地版是多頂層租戶各自獨立公司，跨頂層即真洞，不因「通常只裝一家」降級（09-25）。
6. 第 188／192／212 項進 FR-114 b3（CM-2200／2201／2202）；第 212 項裁「落地版＝客戶租戶＋能力點、SaaS＝只原廠」（09-26，決策者於 FR-114 裁）。
7. PM 總報告第 181～218 項全收再回寫，與 CM-2151 同型。
8. Google OAuth 出貨待辦 CM-2198 開在 FR-110（申請正式 app＋同意畫面審查＋落地機回呼網址登記 SOP）；決策者要先定原廠 Google 帳號、隱私政策網址、scope 縮不縮。

推翻或修正了什麼

• DI 腳本卡原版「🔴 7 處缺接」→ 主線只 3 處；另 4 處是修正線新加零件被算成主線缺接（基準讀錯樹）。
• 第 205 項面板 0:3 否決 → 首腦開修正線檔推翻：CM-2037 只給讀取加守門、revert 未動，修正線合回後還原成唯一讀取路，立項中。
• U7「批次完成預設把呼叫者當管理員」（決策者點名、§7 第 50 項待核）→ 不成立，零件有接、網址必帶專案；第 59 項「待核對」結案。
• U8「覆核輪承襲來源與目的同源」→ 不成立；盤點檔 §6「task_assignees 無 RLS」已過期（DEV 重查有 RLS、4 條規則）。
• U11 報告把容器紀錄沒遮罩寫成第 173 項（實為 Word 卡死）→ 那條是第 186 項（U2-2 新登）。
• 首腦自己錯兩處：①租戶模型——先判「落地版打不到無關客戶」想降級第 192／194 項，決策者糾正：落地版可建多個頂層租戶，跨頂層就是真洞；②第 74 項引錯——U2 舊帳首腦寫成第 74 項，登記員核為 CM-1631；另派工時把診斷包遮罩誤寫成第 173 項（實為第 162 項）。

教訓

1. 🔴 拿出貨型態推系統邊界會推錯，邊界看程式碼能不能建出來：「落地版通常只裝一家」是營運事實，不是隔離保證；資料模型允許多頂層租戶，就要當多家公司看。
2. 🔴 面板只看掃描當下主線、不看修正線：發現的前提若是「修正線合回後」，面板否決不能採信，要開修正線檔核（第 205 項推翻 0:3）。
3. DI 比對腳本基準要指主線：venv .pth 指修正線時，修正線新加的零件會被算成主線缺接（CM-2165 退回）。
4. runner 報告寫一半 session 斷掉（U6）：prompt 加「先 commit 初版再補細節」後沒再發生。
5. opus 大範圍登記員會死在寫檔前：11 棒 34 項一次登，兩次撞 gateway 500；拆三支 sonnet 分段只暫存不 commit、首腦統一核數字 commit 就過。大登記照這個切。
6. 登記員每次都抓到首腦數字錯（218 vs 219、216 vs 217、U2 舊帳引錯第 74 項），這層不能省。

派工 prompt 樣板補兩行（照第二十一任 block 那份，追加）

報告先 commit 初版（一句話結論＋發現清單）再補細節，session 斷掉也不會白做。
帶著前棒收穫的形狀要寫具體：例「U4 的『問你有沒有買≠問這是不是你的』——授權檢查過了不代表歸屬檢查過了」。

登記員拆法：大範圍（≥5 棒或 ≥15 項）拆三支 sonnet 並行，各自只動自己那段——①總表 §3.1 新項次；②總表其他段（§0／§0.5／§1／§3.2／§3.4／§4／§6／§7＋既有項尾註）；③FR 站 README＋Notion 子卡母卡 append。三支都只 git add 不 commit，回報「對不上的地方」；首腦統一核數字、補跳過的尾註、rebuild、一次 commit。

未完成交棒

• FR-114 首腦 09-26 在主 checkout 回寫第 7 批已修狀態（CM-2199，改 docs/security-report/ 與總表第 1～180 項狀態欄），交棒時未見 commit；下一任先 git log 找 docs(security-report): FR-114 第 7 批已修狀態回寫。
• PM 總報告 docs/security-report/ 回寫第 181～218 項（CM-2151 同型），等 FR-114 那顆進來再開卡派，避免撞檔。
• 總表 §7 待裁：第 51 項（流程圖存檔刪任務 vs FR-112 09-20 裁定）、第 53 項（CM-1605 兩次面板相反）。
• 母卡 FR-116 CM-2088、FR-118 CM-2122、FR-119 CM-2139、FR-120 CM-2152 修正待驗證，Done 等令。
• 未 push 約 220 顆，push 等令。

commits（本任，時序；runner 側 commit 穿插其間不列）：f0010f642 第二十一任交棒收尾 → 9900bbeac DI 腳本卡標派出 → 00712065e DI 腳本初版（runner）→ 33f9cbc08 memory 兩條 feedback → 5f1f1e700 CM-2151 第二步回寫（runner）→ a73cca515 需求中心補回 FR-113～120 → 77ec8e762 DI 腳本分主線／修正線基準（退回後）→ a48a67b79 交修正線清單補 1-8 → fe7c471f3 登記 DI 腳本卡與 FR-119 收口 → adc11be5c U1／U3 驗收登記 → 222a13f80 U2～U13a 十一棒驗收登記 → 6b8bb3c48 U13b 完稿＋進度表 → 本交棒 commit。FR-114 線同期 commit（159a2fff9／0e2258d53／93c57739b／06a073d90／da73f8212）屬修正線首腦，不在本任。

做了什麼

• 09-26 接第二十二任。先跟 FR-114 首腦對齊：第 7 批回寫（CM-2199）三處不能照標——第 215 項 CM-2195 修的是 ap/ar 兩張表不是 ssp 兩張、第 130 項有第五入口（第 198 項）、第 162 項只補一種寫法。FR-114 照改。
• 開四張收尾卡並驗收：CM-2206 總表 §7 清帳（43 項未劃剩 5 待裁＋2 拿不準）、CM-2207 文件與腳本裡兩組測試密碼碼掉（308 檔＋7 支腳本改讀既有 env、文件站建置加 lint_secrets.py）、CM-2209 剩餘 45 項分五類、CM-2210 PM 總報告對齊（補回第 1～6 批 192 格已修＋收進第 181～218 項＋新開 M24）。四張 Done。
• 決策者 09-26 逐項裁完剩餘項目：8 項會改行為的（181／184／187／190／185／200／165 剩餘／218）全照建議修；§7 第 8 項日誌表定位「只給原廠維運看、不隔離」、第 14 項專案 SSP 維持看專案角色、第 18 項暫緩、第 13／18b 照修、第 51 項補「查得到專案就問管理人」；第 53 項（CM-1605）已由 CM-2111 修掉結案；Nexus jedi-issue 0.0.1～0.0.13 夾帶 .env 裁不處理；三組測試密碰不換。
• 交修正線清單 docs/features/FR-120-2609-host-residual-security-scan/handoff-to-fix-line.md（12 組），FR-114 開第 8 批 CM-2211～2222 並於 09-26 全 Done；另補 CM-2223～2230（第 217 項剩餘半、M07 四件、分類常駐服務等）。修正線 09-27 合回主線，1.21.0 正式版 09-28 上三環境。
• 首腦親手核過的：POC／STG 舊線分類資料皆 0 筆（舊線路由可直接刪）；/static/ 內只有上傳檔、下載全走 API、無任何 /static/ 網址引用（關閉不影響功能）；Nexus 24 版 wheel 逐一下載檢查 13 版夾帶同一份 .env；CM-1605 修法在修正線 e3c726896。

決策（決策者裁，本任記帳）：見上；另 09-28 裁「掃描階段性任務結束，後續有需求另開新任務」。

推翻或修正了什麼

• CM-2209 分類文件兩處錯：第 191、215 項寫「修正線已收」實際未修（191 缺能力點、215 是 ssp 兩張表）。
• CM-2206 兩處被決策者後續裁定超越（第 84 項改不換、Nexus 改不處理），首腦另 commit 更正。
• CM-2210 第二段 subagent 推算「約 135 輪／2,375 檔」，改用總表權威值 140 輪。
• 首腦自己錯：接手當天照過期的 §7 清單問了決策者兩件早已裁定／修完的事（Nexus、第 53 項），決策者點名「都不確定就直接來問，做一堆重工」；另兩次在你裁之前就把未裁的項目清單當作可直接派修的東西丟出去。

教訓

1. 🔴 問決策者前先查修正線卡、修正線程式碼、PM 總報告三處——總表 §7 待裁清單只有掃描線在記，修正線一週的裁定與修正不會回寫進去，清單必過期。已寫成 memory feedback_verify_pending_decisions_before_asking。
2. 🔴 「決策者說全部加進 b3」≠「逐項看過」：8 項會改變產品行為的要先列出「修了之後誰會碰到什麼」再問。
3. 兩份報告逐列比對要用「哪張表的第幾號」當 key——SUMMARY 有多張從 1 編號的表（最要緊五件／問題總表／M 頁非資安表），只用條號比對會錯配（第一段清單漏 9 格）。
4. 共用暫存區會被平行 session 的 commit 夾帶：第一段成果進了 FR-114 的 11f9f1a02。派 subagent 改主線文件時要嘛叫它不 git add、要嘛首腦立刻 commit。
5. subagent 讀大檔會爆：sonnet 整份讀 800KB 報告 context 崩；改成首腦預算清單（tsv）＋opus 逐列替換就過。這條在本 repo 已第三次踩到。
6. 邊做邊存：opus 第二段第一次撞 gateway 500 零產出；重派加「每改完一頁就寫回」後 98 次工具呼叫做完。

未完成交棒：文件標已修（PM 報告 199 處、總表 §3.1 第 181～218 項與 §0／§0.5／§6）——首腦盤點到一半決策者叫停，全部未動；CM-1849／CM-1871 Notion 未關與 release note 不一致待核；CM-2221 遺留的前端小卡未追；四張母卡 Done 等令。

commits（本任，時序）：b22f1523f 更正 CM-2206 兩處 → 399932499 Nexus 裁不處理 → e1831a0b8 交修正線清單 → a71b50642 CM-2210 第二段（第一段內容隨 FR-114 11f9f1a02 進版）→ c5276d109 總入口重建 → 本交棒 commit。runner 側：7c5729d44（CM-2206）、cf9169a74／68cff5463（CM-2207）、9f17a406a／baba15196（CM-2209）。

做了什麼

• 接手時與 FR-114 第 13 棒對齊分工：掃描線卡（FR-075～120 掃描 arc 全部）由本線收，修正線與歸屬不明三批（T-x.y／內化修訂／退役棒）由他的 CM-2283 收；docs/security-report/ 全由他的 CM-2285 改，本線只改資安總表。分工原話留在 FR-114 STATE 9909ef2f8。
• 開三張卡：CM-2290（sonnet，Notion 收卡）、CM-2291（opus，資安總表終局化）、CM-2292（sonnet，run 目錄歸檔）。清單檔 handoff/2026-09-28-scan-line-cards-to-close.tsv（103 張）入版控給 runner 讀。
• 驗收三張全過：CM-2290 96 張子卡＋7 張母卡 Done，跳過 7 張首腦逐張開檔後親手改 Done；CM-2291 「未合回」0、§3.1 181～218 逐項有狀態、commit 只帶本線檔；CM-2292 三 repo run 目錄 0 殘留、runs/ 148 個 2.1MB、報告引用 122 個目錄 119 對上、3 個各有正當原因（-s3 後綴／被前 session 誤刪／流程未完成）。
• 首腦親手收的：掃描線 Not started 40 張（15 張母卡補結案段、15 張早期修正卡註「被 FR-114 取代、實際處理在 SUMMARY 第幾條」、10 張作廢／裁停子卡）；決策者裁關的非掃描線 19 張（FR-107 六張、FR-071 三張、FR-099／100 兩張、CM-1204／1069／1463／1279／1329／2274／2278、CM-1030）；CM-2106／1662 兩張早驗收未關的。合計 61 張。
• 規則落地：skill 第五節加第 8 步 run 目錄歸檔、scan-card 樣板紀律段加一條、memory feedback_scan_run_artifacts_archive_to_consolidated_runs（2d058eb52）。

決策（決策者裁，本任記帳）：「修正待驗證一律 Done、母卡直接收」；CM-1204 早退役不處理；CM-1069／1463／1279／1329 先不做；CM-1995／1886 先不動；CM-1030 查證已由總表第 107 項修法（e95465eb）涵蓋。

推翻或修正了什麼

• CM-2291 卡上寫 §3.2 第 39／40 項「補 CM-2215 結果」是首腦寫錯（把 §3.2 序號對到卡名的 M06-16）；runner 實查程式碼後照實標未修，正確。兩條無卡，交決策者裁是否併 CM-2289。
• 第二十三任 STATE 寫 M07 五條「隨舊線退場消失」，FR-114 首腦查證 CM-2061 結論是四件還在、已由 CM-2225／2226／2227 修掉——總表改「已修，1.21.0」。
• CM-1463「拆 is_admin」方向已被 CM-2280 反轉（改回以 is_admin 判管理員），卡關閉。

教訓

1. 首腦開卡前的「對照表」要自己算好放進卡，不要讓 runner 從 800KB 大檔推——CM-2291 的項號→卡號對照是首腦從 20 張卡名抄的，runner 因此零次讀整檔；但其中一格抄錯，runner 靠實查程式碼擋下。對照表要附「來源」讓 runner 能驗。
2. Notion 批次收卡的「跳過」規則要防字面誤判：卡上寫「內文寫卡住就跳過」，runner 把報告裡「比對規則卡住 CPU」也當卡住。判準應改成「最後一段首腦驗收是否通過」，不是全文 grep。
3. 兩個首腦同時收卡先切「誰收哪一線」再動——本次先對齊分工才派，零互踩；靠的是把卡號區間與 FR 前綴寫死，不是靠口頭「掃描線你收」。
4. run 目錄散落是因為工具寫在被掃 repo 根、而三個 repo 都沒 gitignore——git status 看不到未追蹤的目錄，所以四週沒人清。凡工具落地產物都要在第一棒就決定「入版控搬哪、不入就 ignore」。

未完成交棒：無。等令 push。

commits（本任，時序）：75b8150e4 開卡＋清單 → 85dd9d1e5／72dfe0128（CM-2291 runner）→ decd97089（CM-2292 runner，含 jedi 18b52e50、LC ec911e41）→ 2d058eb52 skill／樣板／memory → 本交棒 commit。