FR-114 交接日誌（LOG，append-only）

每棒結束追加一個 block：commits／決策／教訓／推翻了什麼。現況看 FR-114-STATE.md。

---

做了什麼

• 讀 _handoff-internalize-5.md 與 SUMMARY.md，盤點 145 件按批分布，回報決策者。
• 掃描總表 §2.2／§2.3 的 17 張舊修正卡標作廢＋16 張 Notion 卡貼作廢說明（CM-1559／1788 已 Done 跳過；CM-1998 保留沿用）。
• 寫 dispatch-plan.md（總覽）＋七份 batches/plan-b*.md（分批逐卡計畫）；22 處待補程式座標派兩支 opus 唯讀實查補齊。
• 開 BE／套件兩個 worktree（fix/security-b1）。
• 建 48 張子卡 CM-2021～2068 連號＋第 6 批兩張 CM-2071／2072。
• 寫夜跑 workflow.js／cards.json／HANDOFF.md，手動派工 DISPATCH-PROMPTS.md，看板 BOARD.md。
• 派 CM-2023（1-3）手動 runner，裁定其停手事項，驗收通過。

commits（BE feature/review）：c61254ddc、379cb2396、2a8115bf0、84d217ba7、c57fbfbc7、2ad1a1a04、b40c3b00e、00c60d1de、＋本棒收尾一筆。未 push。

決策者裁定（本棒）

• 41 張舊卡作廢，CM-1998 沿用；CM-2020 密碼換發問題依原則九當已換（後被實查推翻，見下）。
• 12 項待裁全「照建議」。
• 依序做不平行；只開兩個常駐工作區。
• 先手動派一張看樣子，再放夜跑；夜跑先試三張。
• CM-2023：#109 退回（開 CM-2072）、#41 用稽核輪次鏈（後實測不通，開 CM-2071）、#110 照確認修。

推翻了什麼

• 原則九「所有憑證已換發」——第 4 批實查三把（DB 管理員、系統管理員、Google AI）與現行 .env 一致，看起來沒換。列為 D-b4-2 待決策者確認。
• 首腦給 CM-2023 的反查鏈——flow_control_job_repo_impl.py:332 註解明寫永遠對不到；runner 實測 12,573 筆 0 筆。首腦錯，runner 對。
• 原計畫「今天能同時開約 26 個 worktree」——決策者裁不平行。
• #121 members 表「整塊移除」——表被指派負責人活用，只拆入口。
• M07 舊線退役——已有 CM-1849 在管，第 3 批不再開。

教訓

• 一支 subagent 吞 145 件爆 context 兩次零產出；改三層（材料檔記憶庫 → 分批 subagent → 本體總裝）後一次過。
• sonnet 對「抄不到就標待補」的理解是「查到為止」，34 分鐘沒落盤；prompt 要明寫 tool call 上限與落盤時限。
• 首腦給修法前要開檔查，不憑表名推鏈路。
• 建卡 spec 格式（items vs text）要先跟腳本對過再讓 subagent 產。
• 套件卡 pytest 帶 PYTHONPATH。
• 手動派第一張的價值：runner 停下來問的那兩件，夜跑會直接停整批——規格品質決定夜跑能跑多遠。

---

做了什麼

• 接手盤點：夜跑第一輪三張（1-4b CM-2025／1-4a CM-2024／1-8 CM-2031）已全部到「修正待驗證」，母卡 CM-2019 尚無夜跑總結。
• 驗收三張：開 diff 核座標、grep 報告、DEV 查 schema、套件卡帶 PYTHONPATH 重跑 354 過、BE 卡三支測試 13 過＋3 個既有錯誤（主線同樣有）。三張都通過，回寫「首腦驗收」段，BOARD 標「待決策者批」（連 1-3 共 4 張攢著）。
• 決策者已派 1-9 CM-2032，BOARD 標派工中。

首腦裁定

• CM-2032 權限補授權 migration envs=dev 維持、客戶庫不自動補（三環境實查：缺的都是客戶自建「稽核人員」、八顆全缺，屬建角色沒勾到；但升級自動補權限與 #43 方向矛盾）。改走 1-6 「403 不可安靜變空」＋升級手冊提示。
• CM-2031 runner 自訂的 XML 長度上限 35 萬字：接受。
• CM-2024 沒做管理者代刪路徑：認可為卡外，要做另開卡。

發現的連帶

• CM-2032 runner 把套件 commit 打在 monorepo 主 checkout 而非工作區，首腦 cherry-pick 補進 fix/security-b1。第二輪 runner prompt 已寫明套件工作區路徑，若再發生要看 runner 是不是沒讀「工作區」段。
• CM-2031 兩個新違規碼 FE 缺 i18n key（flow-engine-banner.json），合回前併 FE 小修補。
• CM-2025 migration → 出貨基線待重產。

教訓

• 1-9 驗收：三環境唯讀查一次（ssh … docker exec … psql）才裁得出「客戶庫要不要補」，光看 DEV 不夠。
• 驗收 BE 卡跑測試前先在主線跑同檔對照，才分得出既有錯誤與本卡弄壞的；runner 這次自己做了，首腦照樣重驗一次。
• runner 加「卡上沒寫的上限」要看有沒有實測依據再裁，不是一律退回。

第二輪自動跑驗收（同棒，2026-09-22 晚）

• 13 張：10 過、2 程式對但報告 build 壞（CM-2045 表格多一格、CM-2027 頁面壞掉但已被後一張重 build 蓋回正常）、1 需裁（CM-2047 i18n 共用檔）。三個主 checkout 乾淨。
• 逐張開 diff：1-1 守門分層（判定在 authz、解析在新檔）正確且「無 context 不守」有註明原因；1-5a 沒部門→空清單不是 None、單筆 404 不 403、更新沒帶 org_units 不清空；1-7 歸屬檢查在關外部 issue 之前、mine 取不到身分用哨兵；1-6 is_active 預設 None 收掉靜默重新啟用。
• 測試：六支套件帶 PYTHONPATH 重跑，兩個紅燈（task-platform RLS、bulletin migrations dir）主線同樣紅。BE 側抓到 runner 沒跑的兩處：① 1-2 改了 BE 方法名，test_detection_orchestration.py 假物件沒跟上，19 個炸；② 1-1 新錯誤碼沒複製進套件鏡像。派 sonnet 補，順手把 FR-112 漏登的兩支 FORCE_START 收掉。
• 機械類 4 張（3-2／3-4／3-1／4-3）直接 Done；第 1 批 12 張全部驗過待批。

首腦裁定（第二輪）

• CM-2047 選項 1：i18n 檔整支保留，只拆路由／元件／menu 字串。
• RUN-2-LESSONS 建議 B 採納：報告狀態改與重 build 收回首腦批次做。

教訓

• runner 改「BE 給套件呼叫的方法名」時，BE 測試的假物件不會自己跟上；驗收 BE 卡要跑「呼叫端所在模組」的測試，不只 runner 說跑過的那檔。
• 「主線同樣紅」的既有紅燈要在第一輪就消掉，不然每張卡驗證 agent 都要重確認一次。
• 卡上「零引用」查證要含 i18n key 與 FE 字串，不只元件與路由。

第三輪自動跑驗收（同棒，2026-09-22 深夜）

• 12 張全過，零需裁、零失敗、主 checkout 乾淨。CM-2059 首腦親驗（決策者問「是不是只看公版就好」——是；四份公版 seed 跑新上限零違規），其餘 11 張派 opus 獨立抽 diff＋帶 PYTHONPATH 重跑，零退回。
• 首腦補修一處：CM-2054 api_log.py 守門包法順序與 docstring 相反（能力點該先於總部層級），一行調整 a25933de8。
• 報告 36 條狀態由 sonnet 批次改＋重 build（runner 本輪不動報告的新規則第一次跑，沒再出現表格多格／頁面壞掉）。
• 機械類 3-5 Done；第 5 批 11 張待批。累計 29/50 驗過。

首腦裁定（第三輪）

• CM-2059 改掉「草稿不驗」既有測試：接受。#88 後半另開小卡到 jedi-compliance-audit。
• 三輪累計要決策者的四件攢在 STATE「待決策者」欄，不即時問。

教訓

• 「不擋正常客戶」的判準是出貨公版 seed，不是 DEV 資料；DEV 樣本多適合做回歸比對，兩件事分開講。
• 驗證 agent 判過的卡，首腦再派一支獨立 opus 抽一次還是抓得到東西（CM-2054 順序、三個 AI 錯誤碼 FE 缺文案）——雙驗值得。
• 報告收回首腦做之後，runner 回寫「該改哪一列」那段品質參差，下一輪 runner prompt 可給固定格式。

收尾（同棒，2026-09-22 深夜）

• 決策者四項裁定：密碼不換（DB／系統管理員 PRD 前換、Google AI 已換）→ 4-1／4-2／4-4 解鎖照卡清殘留；基線重產「開卡做掉」→ 排第四輪跑完後開；Bifrost 逾時決策者自改；合回發版＝最後全部改完測完再做 → 第 2 批不等合回，10 張卡上解鎖。
• 開連帶卡 CM-2082（合回前 FE 小修：七個錯誤碼文案／設備選單 403 提示／意見回饋 scope）、CM-2083（#88 後半起輪次要求已發布）。
• 第四輪 cards.json 15 張：第 2 批 10 → 4-1／4-2／4-4 → X-2 → X-1。
• 抓到 manifest 漏登 1-4b、1-5b 兩支 migration（STG/POC 升級不會套），補 1b52aa24b。
• 第三輪 36 條報告由 sonnet 批次改＋重 build c87d2eea5，首腦驗：36 條狀態對、html 無壞路徑、欄數異常全是主線既有第二張表。

commits（BE feature/review，本棒）：74a3e6710、8c1d3acba、95d3069b3、5174b119d、eb70c4d7a、618c19557、3d68d7595、f12eeab05、＋本筆。未 push。 commits（BE 工作區 fix/security-b1，本棒首腦親手或派工）：f6398b680、1825bbda2、ca7619dd4、a25933de8、1b52aa24b、c87d2eea5。套件工作區：e98fea2（cherry-pick）、7a8c3da。

給第 3 棒的一句話：三輪下來 runner 品質穩定（29 張零退回），驗收真正抓到的東西都在「runner 沒跑到的測試」與「跨 repo 連帶」——驗收時多花時間在跑呼叫端模組的測試與 grep FE i18n，少花在重讀 diff 本體。

第四輪自動跑驗收（同棒，2026-09-23）

• 15 張：驗證 agent 判 10 過／1 需裁／4 不過。首腦核實 4 張不過屬實；派 opus 獨立抽 10 張過的，再抓出 2 張要退：CM-2035 三支新錯誤碼與 jedi-log 撞號（BE 唯一性測試掃不到套件）、CM-2042 選單掛的能力點公版只給 Administrator 會擋專案成員。
• 🔴 CM-2049 事故：runner 把剛清掉的密碼真值寫進 commit message 與 Notion。首腦重寫 commit、gc 懸空物件、刪 Notion block；未 push 沒外洩。
• CM-2033 三件裁通過（軟刪除另開卡、孤兒檔例外口維持、前端呼叫點列手測）。
• 三張往超標檔加邏輯放行記待拆；CM-2041＋CM-2054 錯誤碼補鏡像與基準表（616577422／5156e8ab）。
• 第五輪 5 張：2048 重做、2035 重編號、2042 放寬選單、2037 補兩處、2082 補 catch＋七個文案。

教訓

• 自動跑的驗證 agent 過的卡，首腦再派獨立 opus 抽一次，第三、四輪各抓到真問題（守門順序、錯誤碼撞號、擋正常客戶）——雙驗是固定程序不是選配。
• 新錯誤碼要跨 monorepo 全部 common 目錄 grep 號碼，不能只信 BE 的唯一性測試。
• 掛能力點前要看公版 seed 把那顆給了誰，只給 Administrator 的能力點掛在專案成員會用的端點上就是擋正常客戶。
• 清憑證的卡，驗收第一件事是拿 .env 值 grep commit message 與 Notion。

收尾交接（同棒，2026-09-23）

• 決策者裁：驗過直接 Done、不逐卡批；最後從安裝到功能整個重測，邏輯問題到時調。32 張攢著的全部改 Done，累計 39／52。
• 第五輪 5 張清單備好；第 3 棒接手後照 STATE「第 3 棒接手後做什麼」。
• 本棒 BE feature/review commits：74a3e6710、8c1d3acba、95d3069b3、5174b119d、eb70c4d7a、618c19557、3d68d7595、f12eeab05、5d1588060、7c21a6bf6、＋本筆。未 push。

---

第五輪自動跑結果：5 張退回重派卡全跑完，3 過（CM-2035 重編號／CM-2037 分頁列表歸屬／CM-2082 第二個 catch＋七文案）、1 沒過（CM-2048 差 import os 與 features-site 鏡像重同步；憑證面首腦核過零真值）、1 需裁（CM-2042）。首腦每張落地時先做唯讀預檢（新號跨 monorepo 唯一／分頁列表真有過濾／五個 catch 全補），與驗證 agent 結論一致。

首腦裁定

• CM-2042 改向：第 2 棒要 runner 對齊「任務規劃能力點」，runner 查證該路徑用的是專案角色守門、能力點不存在——runner 對。改走第三案「守門不動、補權限資料」：新 migration 補 detection-profile.read 給缺的角色（DEV 5 個角色缺，全部都有 device.read，證明是資料漏發不是守門錯）。FE 兩處打選單的 catch 順手補 403 提示。
• 決策者新裁（推翻第 2 棒 CM-2032 的保守標記）：補權限的 migration 一律 envs=* 隨出貨，STG／POC 由 init image migrate 模式帶到、不手動套；客戶庫管理員刻意拿掉的權限會被補回，決策者明知接受。CM-2032 那支從 envs=dev 改 *，併進 CM-2042 第六輪做。
• 同類問題盤點（決策者問「是不是很多都要這樣」）：本 arc 新掛的守門逐顆對照 DEV 角色持有狀況——只有兩顆讀取權限要補資料（掃描設定檔、設備／資訊系統）；流程範本 runner 已寫「或有建專案權限」避開；AI 儀表板／建立資源庫／工具管理頁屬「看角色決定看到多少」或寫入端或管理員頁，缺被擋是正確行為，不補。原則兩條：①只補一般專案成員正常流程會打到的讀取端；②補權限 migration 一律隨出貨。
• 47 檔過期 JWT token（conversation-history）併進 CM-2048 第六輪，不另開卡。
• Bifrost 逾時待決策項劃掉（決策者已自改 600 並從 config.db 確認）。

攢著合回前做的：CM-2035 新三號 FE 文案缺三條；三張過的卡各有「CM-xxxx 重派」施工日誌型註解要刪；升級手冊「升級前檢查角色讀取權限」要多列掃描設定檔那顆。

另開卡建議（不在本 arc）：公版 seed 只有 Administrator 一個角色、118 條授權全給它，客戶自建角色從零勾，以後每加一顆讀取守門都可能踩「安靜變空」；長期正解是公版內建幾個一般角色範本預勾讀取類權限。

教訓

• 首腦給 runner 的「對齊 X」指令，X 要先開檔確認存在。第 2 棒憑「有能力點守門」的印象寫下「任務規劃能力點」，那條路實際是專案角色守門，runner 停下來問是正確反應。
• 「擋正常客戶」的裁法先分「守門錯」還是「資料漏」：缺權限的角色若同時擁有同類已補過的權限，是資料漏，補資料比改守門便宜且不發明新東西。
• 補權限 migration 的環境標記是決策者裁的事，runner 標 dev 保守沒錯，但要在卡上明列讓首腦攢去問，不能一直停在 dev。

commits（BE feature/review，本棒）：24343ae6e（Bifrost 劃掉）、＋本筆（第五輪驗收／裁定／第六輪清單）。工作區無首腦親手 commit。

第六輪事故（同棒，2026-09-23）

• 兩張零改動：runner 收到的第一段是「觸發 Workflow 的原話」（寫給執行首腦的「你只要跑 Workflow 腳本」），harness 明講原話優先於腳本任務，runner 沒 Workflow 工具便停。第四輪 CM-2048 零改動是同病，第 2 棒判「派工鏈路接錯」沒追到根。
• 修：night-run/HANDOFF.md 貼給執行首腦的 code block 主體改寫成「做卡」，執行首腦操作細節另立一節不進被轉發的主體；code block 尾加「沒有 Workflow 工具就是 runner、直接做卡」的分流句。cards.json 不變，第六輪原清單重派。
• 教訓：Workflow 的觸發原話是 runner 看到的第一段且優先，貼的 prompt 必須以 runner 的視角寫；給首腦的操作說明要放在不會被轉發的地方。同一種「零改動」出現第二次就要開 journal 看 runner 實際收到什麼，不能再判「鏈路接錯」帶過。

第六輪重跑驗收（同棒，2026-09-23 下午）

• 2 張都過。CM-2042：新 migration envs=* 補 detection-profile.read、DEV 已套（14 角色零缺、schema_migrations 有登）、CM-2032 改 envs=*、FE 三處 403 提示；Done。CM-2048：憑證面三道門全過（.env 15 值 grep commit／diff／Notion 零命中、47 檔 JWT 零命中、import os 補了）。
• CM-2048 退回拆 commit：runner 為讓 mkdocs --strict 過，把 sync_features.py 白名單改 --all，8497acee3 夾帶 242 檔（FR-069～114 共 46 個 FR）＋mkdocs.yml 291 行導覽，文件站 74→120 個 FR。決策者裁「要分開，不要混在一起」。第七輪只拆：疊反向 commit 刪 484 個新增檔、mkdocs.yml 還原、白名單重跑 sync＋build（不帶 strict）。文件站擴容＋architecture-handbook 斷鏈另開卡給文件線，不在 FR-114。
• 第七輪 4 張：2048 拆 commit＋5C-2／5C-6／5C-8 三張「先查證」卡解鎖（只查不改，回寫 NEEDS_DECISION）。
• 決策者要求：權限守門兩種流程（能力點／資源歸屬）的說明要落成資安報告「怎麼修」的正式文件並加連結，收尾時做（桌面已有 HTML 草稿）。

教訓

• runner 為了讓某個 build 檢查過而放寬工具的範圍參數，會把另一條線的決策夾進本卡 commit。卡上「紀律」段要多一條：不改任何腳本的範圍／模式參數，build 過不了就回寫原因，不自己放寬。
• 出貨基線待重產清單要在每張 envs=* migration Done 當下就加，不要等收尾才盤。

第五輪三張正式驗收（同棒，2026-09-23 下午）

• 派三支 opus 並行獨立抽終態，全過，改 Done：CM-2035（11 入口全改、新號三邊一致、套件 147 綠、BE 5 紅為主線既有）、CM-2037（16 入口全改、分頁列表零參與回空不漏過濾、歷史列表沒帶 uid 回 400、BE 351 綠、套件 147 綠）、CM-2082（七位置全改、兩面板各補 2／4 catch 餘為儲存刪除路徑、七文案中英齊、build 過）。累計 43／52。
• 開 CM-2084 給文件站線（掛 CM-1185）：features-site 回灌 FR-069～114＋architecture-handbook 斷鏈處置。母卡 CM-1185 補指引。
• 三支 agent 都提到 BE 主 checkout 有 50 個 docs HTML 改動——第 3 棒接手時就在、是文件站 build 產物，非本 arc 造成，未動。

攢著的（已寫進 STATE「合回前清理清單」與 BOARD「另開卡候選」）：FE 三條新文案、施工日誌註解五處、CM-2037 套件側守門收攏、兩支死方法、進度查詢非成員可讀、list_ap_parties 放行寫法、公版 seed 一般角色範本。

教訓

• 驗收 agent 回報「主 checkout 不乾淨」時要先對照接手時的 git status 快照，再判是不是本輪造成。三支都因同一批 docs 產物多寫一段，下一輪 verifier prompt 可先給「已知既有髒檔清單」。
• 「fail-open 候選」要分「程式路徑上走得到」與「只有繞過 HTTP 直呼 service 才走到」，後者記著但不判不過。

第七輪驗收＋裁定（同棒，2026-09-23 傍晚）

• 4 張：CM-2048 拆 commit 過（白名單回 74、憑證清理保留、.env 值零命中；多帶進 FR-062 新檔屬白名單正確行為）→ Done，累計 44／52。三張查證卡照裁定只查不改、回寫 NEEDS_DECISION，零失敗——決策者問「只有一張通過好像不太對」，首腦說明這是預期形態。
• 決策者裁：#101 Nexus https 不修（內網）；#137 兩份副本刪。首腦裁：#124 SeaweedFS secure 預設比照 #101 不修；CM-2063 #14 五步驟不依賴 TLS、下一輪做。
• 第八輪 3 張：2068 刪副本、2067 lock 納版控、2063 五步驟（BE＋FE）。
• 決策者問「Nexus 憑證在 git 還是 build 機」——兩邊都沒有，Nexus 服務本身沒設 TLS；git 裡只有 28 行 http URL。

教訓

• 查證卡的回寫格式（①證據②若要做要動哪些③不依賴前提可先做的）讓首腦一輪就能裁完，不用再問；下次同類卡沿用。
• 「內建服務要不要加密」這類決策者一句話能定的事，第 2 棒卡上寫「先查證再裁」是對的，但首腦應在查證前就先問決策者原則（內網算不算要修），可省一輪。

第八輪驗收（同棒，2026-09-23 晚）

• 3 張全過 Done：CM-2068 兩份副本刪（monorepo 只剩 iam 一處定義、零呼叫）；CM-2067 lock 17 支入版控（沒動 pyproject、沒跑 poetry lock）；CM-2063 #14 五步驟（首腦派 opus 獨立抽：FE 沒改不送欄位＋BE 三種空值都沿用原值，「改別欄位洗掉密碼」不會發生；回應走單一出口改 has_secret；內部上傳服務專用 reveal service 只注入一處；#124 原封）。BE 81 紅為 detection 五支主線既有。
• CM-2084 文件站回灌 Done（主線 a96497d28，74→121，兩支腳本只加資料清單）。決策者裁 handbook 納站。
• 累計 47／52。自動跑階段結束（八輪、含一次零改動重跑）。
• 剩 5 張全是「不能自動跑」的：5A-1／5A-2 跨 repo 手動、5B-5 等外部、第 6 批等合回。

教訓

• 「先查證再裁」卡的 runner 回寫如果照「①證據②要動什麼③不依賴前提可先做的」格式，首腦一輪就能裁完並拆出可做的部分——CM-2063 五步驟因此沒被 TLS 前提卡住。
• 密鑰類「不回傳真值」的驗收要對照前後端兩邊的「空值形態」（不送／空字串／null）是否對得上，單看一邊會漏最大風險。

收尾交接（同棒，2026-09-23 晚）

• 報告狀態批次更新 264b42262（工作區）：35 條改狀態（33 已修、#124 裁不修、#101 部分修）＋11 個 M 檔 20 列，首腦核欄數與主線一致、抽七條對、範圍只在 security-report。順帶抓到第四輪 Done 的第 2 批 10 張狀態也沒改（第 2 棒交接時漏），一併補。剩 21 條未修，其中 5 條（#9／66／67／96／97）要對批外清單，留第 4 棒。
• 5A-1 CM-2052 決策者派出（opus），第 4 棒驗。5A-2 prompt 形狀同 5A-1，改卡號與套件名。
• 決策者問 context，首腦判自動跑結束是換棒點。

本棒 BE feature/review commits：24343ae6e、908712ae0、81be299b0、8a5c3837f、4ed143ac2、e87a5b2c8、f0cf8385d、a96497d28（CM-2084 runner）、＋本筆。未 push。 本棒工作區 commits（runner）：BE 8497acee3／5de8faeec／b047d16e3／0f3ef0e4a／3a651140e／7c904eb6e／264b42262；套件 c69d3e97／0f0baf9c／09cbb7cf；FE bbf0f68／4f1e501／45b3d7c／756783b。

5A-1 派工 prompt（給第 4 棒改 5A-2 用）

做 CM-2052：讓代理程式每次打進來都要證明身分，並讓「撤銷」真的斷得乾淨（SUMMARY #1，全案最嚴重）
https://app.notion.com/p/FR-114-5A-1-SUMMARY-1-3e2346da4cd08135ba63d89e24cfbd8b
model：opus／effort：high／理由：跨 jedi-remote-agent 與 evidence-agent 兩個 repo、要設計短效通行證簽發驗證，方向已裁但實作有判斷

工作目錄：/Users/chouraymond/Projects/Billows/Audit-Manager/compliance-manager-be
先 `python scripts/notion_case.py get <URL>` 讀完整張卡，卡是自足的；卡尾兩段「首腦裁定」（第 2 棒＋第 3 棒）是最新指令。
卡上「工作區」段指定的目錄才是你改碼的地方，絕不碰任何主 checkout。兩個 repo 同一棒做完。
卡上「在哪裡」每個 file:line 都要改到；「怎麼修」照順序；「紀律」段是完整規則。
做到一半發現既有工具形狀對不上、或要動客戶機房設備，停下回寫「🔴 需首腦裁」等令。
做完：各 repo 分開 commit → Notion append 白話補充（commit hash、測試、手測清單、SUMMARY 該改成什麼）→ 狀態改「修正待驗證」→ 停下等驗收。
不 push、不切 branch、不發版、不動 docs/security-report/、pyproject.toml 的 path 改動不 add。

給第 4 棒的一句話：八輪下來驗收真正抓到東西的地方都在「runner 沒跑的呼叫端測試」「跨 repo 的連帶（錯誤碼撞號、FE 文案、鏡像同步）」「為了讓某個檢查過而放寬範圍」——5A-1／5A-2 是全案最重的兩張，驗收派 opus 時把這三類寫進 prompt 的「特別盯」段。

做了什麼

• CM-2052（5A-1，SUMMARY #1 全案最嚴重）Done：runner 開工卡「通行證由誰簽」提三案。首腦第一版憑 runner 描述裁「agent 用憑證自簽 1 分鐘票」，決策者追問三次「你查清楚了嗎」，改派 fable 唯讀查證，三個前提全被推翻（證不是「有遞沒看」而是落地版 httpx 0.28.1 根本沒載入 cert；08-20 拆的 nginx 守反方向、agent→雲端從第一天沒人驗；憑證 CN＝device_uuid 無 agent_uid、DB 無憑證指紋欄，從憑證讀身分沒東西可讀）。改裁「雲端用既有 AGENT_JWT_PRIVATE_KEY 發長效通行證、每請求驗簽＋查 DB 撤銷」，取代 D-b5A-1「短效」；決策者確認並要求對齊業界（首腦查 kubelet／SPIFFE／Wazuh／Fleet：共同模式＝啟用碼只用一次換這台專屬長效憑據、每請求帶、中央每次核對、撤銷＝中央作廢）。runner 一棒中途壞掉零改動、重派做完。opus 抽 12 條過 11：持有舊私鑰證明可被「先讓 CA 簽出 CN＝受害機指紋的真憑證」繞過（ca.py 照抄 CSR subject、_register 簽前沒驗 CN）→ 退回補 CSR CN＝device_uuid 檢查＋兩條測試 → 第二輪過。終態：套件 c4acc687＋9c049540、agent ecdc9f3、BE 7a3bdf1ec。analysis：docs/analysis/2026-09-23-agent-control-plane-identity-token.md。
• CM-2053（5A-2，#17／18／90／91／133）Done：opus 抽五條過四。#18 不過：開機查 DB 鎖定紀錄的邏輯對，但閘門先拿無簽章的 unlock-receipt.json 排除事件、排程再拿它 mark_unlocked 不驗 nonce——有權刪標記檔者手寫一張回執即繞過且洗掉 DB 鎖 → 退回「回執帶原廠 unlock token、閘門與回填都重驗四樣」＋三條測試（runner 做了突變驗證）→ 第二輪過。#17 邏輯鏈成立（相依集合扣 cryptography → 不複製、不列 thirdparty、顯式編進 core，斷言無旗標可跳），三點只能等 188 全量 build 證。cffi 順手補進安全關鍵清單。終態：套件 953697c9＋ba129ca1、BE 0dda326b8＋b64995ac9。
• CM-2085（X-3，新開）Done：5A-1 分析順帶查到資料面 60 秒票在主機時鐘偏差下全拒（t71 Windows 真機案例），決策者裁「檢查並警告、不強制」。雲端 register／heartbeat 回應加 server_time_utc，agent 算偏差 >60s 警告（心跳節流 600s）、install.sh 只 warn。首腦親抽，套件 150／agent 720 綠。終態：套件 bad15b7d、agent 9edda49。
• 決策者裁：SaaS TLS 終結點不開卡、記合回前清理一行。
• 合回前整理稿派 opus 寫 handoff/2026-09-23-merge-readiness.md（首腦抽驗後 commit，見本 block 末）。

首腦裁定

• D-b5A-1 短效→長效（理由：撤銷靠 DB，TTL 無額外安全價值；短效反造成斷線失聯，違原則十一）。
• 5A-2 回執修法走「帶 token 重驗」不走「閘門內寫 DB」（後者與開機期無 DB 寫入設計衝突）。
• boot_db_lock.py:30 except 範圍比「連不上」大（表不存在／權限不足也放行並警示）→ 本卡不改，攢問決策者。

推翻了什麼

• 第 1～3 棒與 M01 部分敘述沿用的「原本靠 nginx 把關、08-20 拆掉後真空」——實況是控制面身分驗證從來就是真空，那台 nginx 守的是反方向。
• 第 2 棒 dispatch-plan D-b5A-1「短效通行證」→ 長效。

教訓

• 信任鏈類裁定，現況事實先由獨立 agent 開檔核對再裁。首腦第一版信了 runner 的問題描述（三個前提全錯）就選方案，若決策者沒追問就會讓 runner 做出「看似有驗其實對不上」的門。runner 的問題描述是它的視角，不是事實。
• 決策者一句「我以為是連上就發一個 key 永久用、中央可以撤銷」正是業界模式；首腦繞了三案才回到這裡。先問「業界怎麼做」再看 runner 的三案，會少一輪。
• opus 抽查兩張重卡都在「驗證鏈的上游」抓到洞（CA 照抄 CSR subject、回執無簽章）：驗「有驗」不夠，要問「驗的材料是誰產的、產的時候有沒有驗」。下次 verifier prompt 固定加這句。
• runner 報的測試數要自己重跑且對照「不帶 PYTHONPATH」：CM-2052 BE 三檔帶工作區 53 綠、不帶 16 紅，證明測到新版；detection 既有失敗 runner 先報 4 檔 24 條、opus 跑 6 檔 87、runner 更正 20 檔 104——三個數字三個範圍，要對齊範圍才能比。
• agent 測試要用 evidence-agent 自己的 poetry venv（poetry env info -p），用 BE venv 會 11 個 collection error 誤判。
• macOS 沒 timeout 指令，驗收腳本別用。

commits（BE feature/review，本棒）：ae6eb652b（CM-2052 裁定＋analysis）、f80b9f682（CM-2085 開卡）、e05d1a8ab（2052 退回）、d90177999（2052 Done）、6557db361（2053 退回）、9abe5e64e（2053 Done）、44870fb9f（2085 Done）、＋整理稿與本 block。未 push。 工作區 commits（runner）：套件 c4acc687／9c049540／953697c9／ba129ca1／bad15b7d；agent ecdc9f3／9edda49；BE 7a3bdf1ec／0dda326b8／b64995ac9。

給第 5 棒的一句話：程式面收完，接下來全是「決策者拍板後才動」的事（合回、發版、188 全量 build、總測、出貨基線重產）。整理稿 2026-09-23-merge-readiness.md 末段是裁決清單；決策者 09-24 早上驗收，接手者讀完盤點完停下，等他一項一項發令。

---

做了什麼

• 決策者 09-24 早上驗收，逐項裁完整理稿 2026-09-23-merge-readiness.md 的七項裁決清單：①現在合回（不等 5B-5／第 6 批）→ 開合回前清理卡 CM-2109，首腦驗收過改 Done；②發版在工作區做（只發套件不發本體、BE 工作區建獨立 venv、188 放行）→ 開發版卡 CM-2110、四 repo fix/security-b1 已推 GitLab；③#96／#97＋CM-1605 郵件憑證驗證（A 案：既有設定升級不變、新建預設驗憑證、可貼內部 CA）→ 開 CM-2111，Done；④開機查 DB 只收窄「權限不足」（A 案）→ 開 CM-2112，Done；⑤出貨基線整包重產（合回後、188 build 前）→ 決策者放行（先備份舊基線），首腦實查 5 支 active migration 完成、A 段過；⑥另開卡三張（CM-2116 角色範本、CM-2117 儲存密鑰後端擋、CM-2118 進度查詢補成員檢查）→ 全 Done；⑦monorepo 缺 lock（4 支在用的合回時順手補）→ 已補。
• 掃描線 CM-2108 插單四件同批（決策者裁）：CM-2113 從「CM-2039 任務歸屬回歸」擴成「全系統唯一任務歸屬判斷」＋接 W8-1 強制開始（Done，f52a53f1e）；CM-2114 jedi-survey 改注入判斷（Done，套件 034eef0e／BE 49cbe0b7b）；CM-2115 我的任務 view 重建（Done，f709823ad，主線 migration，算進出貨基線重產）；CM-2119 其餘四處改接唯一歸屬判斷（Done）。CM-2113 範圍外六處（workflow_execution_service 等）評估後攢給決策者作另開卡候選。
• CM-2116（角色範本）決策者裁定：改走 jedi-iam 建租戶服務注入三範本（只給新租戶、不做升級 migration、名字不加標記），首腦追加：管理員角色不可刪（role_domain_service.py:127 原本直接 delete 無擋）。Done，套件變動進 iam 1.4.1（後續補到 1.4.3）。FR-050 旁路一併拿掉，開 CM-2120，Done（838599358）。
• 套件發版（CM-2110 第三段）：18 支套件一次推 Nexus（清單見 STATE §1）。過程中發現 BE 依賴 jedi-iam 未夾帶的 RoleTemplate（CM-2116 改動漏進 Nexus 1.4.0）→ 決策者裁補發 1.4.1；BE pin 18 支新版（0be9aa24a）推上後、DEV 手測「我的任務」差集為 0，第四段過。
• 出貨基線重產（A 段）：先備份舊基線（~/backup/guidant_ai_baseline_20260924_1249_before_CM-2110.*）再重產，過。
• 188 build（B 段）：甲案新裝流程首次實跑被 CM-2053 補的 cffi 安全守門誤擋 → 開 CM-2132，Done（919432229），退回一輪重跑；重跑又撞 jedi-iam 1.4.0／1.4.1 缺 .mo（套件庫 .gitignore 排除 *.mo、worktree 從 git 開出沒有）→ 補發 1.4.2。決策者裁「不再零碎補發，剩餘小修全收進 CM-2134 總清理，驗收後只發一次」——CM-2121（CM-2085 漏改的既有測試）、CM-2133 併入 CM-2134。CM-2134 Done，最終只需再發 jedi-iam 1.4.3（.mo 入版控）＋jedi-integrity 1.2.1（刪死方法），其餘只動 lock／tests 不發。BE 最終 pin 99b0721c3。
• 188 全量 build 首次跑完（run5）：探針⑥ FAIL。決策者質疑「連撞四次沒先比對上次成功的打包」→ 首腦派唯讀 agent 整批盤點 v1.20.0↔︎fix/security-b1 打包差異，證明探針⑥是假警報（產品開機本來就走同一 import 路徑）；找出兩件真壞：產物權限 700／600（build run2 起 umask 077 造成，會出壞 image）、188 FE repo 停在 main 未含前端資安修正；另發現版號仍 1.20.0 會覆蓋已出貨 image／bundle。開 CM-2135（打包鏈一次修完，含 umask 斷言）、CM-2136（驗證 CM-2053 驗收②③成立），決策者裁版號改 1.21.0b1（預發版）→ CM-2137。三張皆 Done。
• 188 本體最終出包：決策者放行 chown 三個 build 目錄（8/27～28 有人用 root 操作 git，擁有者被改成 root，FE 26／BE 16829／agent 130 檔非 jedi）→ build 全綠（三顆 image，FE 確認含新版前端修正、容器探針過）；封包遇「jedi-license-runtime 無 PROD 公鑰」擋，決策者裁 --skip-prod-key-check 出內部測試包（歷來包皆如此做法）。本體 1.21.0b1 出包完成：/opt/guidant-ai-be/.build/bundle/guidant-ai-1.21.0b1.tar.gz（944MB）；image be／fe／init:1.21.0b1。
• 190 e2e 專機：本棒最後派 subagent 移除本體 1.20.0＋agent 1.0.0、全新安裝本體 1.21.0b1（agent 保留不重裝）。
• 開 CM-2121（CM-2085 漏改的心跳測試）併入 CM-2134 一起收。

首腦裁定

• CM-2113 前提改變後重新評估：原本規劃的 CM-2071（任務表補 project_id）前提可能被 CM-2113 解決，待重評（列入第 6 棒待辦，非本棒裁定）。
• 決策者裁「不再零碎補發套件」後，首腦把所有剩餘小修（CM-2121／2133）收進單一總清理卡 CM-2134，避免第三次補發。
• 188 build 機禁止用 sudo 做 git 操作——首腦記為待補進 scripts/build/README.md 的規則，非本棒完成（留給第 6 棒收尾文件階段）。

推翻了什麼

• 「三環境全套發版一次到位」的隱性假設——實際踩了三次補發（1.4.1→1.4.2→1.4.3）才學到「同一支套件改動全做完、驗完才發」。
• 探針⑥ FAIL 一開始被當真壞，唯讀盤點後確認是假警報（本體開機路徑本就走同一段 import）。

教訓

• 發版與改碼並行會一直補發——同一支套件改動全做完、驗完才發（本輪教訓，已寫進 STATE「已知的坑」）。
• 從 worktree 發版會漏不入版控的資產（.mo 檔）——發前要比對 wheel 內非 .py 檔與上一版差異，不能只看 .py。
• 動打包方式的卡（CM-2053）驗收時要比對上一次成功 build，不要邊 build 邊撞——本輪連撞四次才學到（cffi 守門、.mo 缺失、umask 產物權限、版號覆蓋）。
• 188 build 機曾有人用 root 操作 git，build 目錄擁有者被改成 root，導致切分支靜默漏檔——已 chown 修復，README 待補這條禁令。
• 跑 build 的 shell umask 077 會出 700／600 產物，裝機才炸——CM-2135 已加斷言。
• 驗收環境打折要當場講明：驗收環境的限制（如 188 dist 目錄測出的差異在正式 image 不成立）要在回報明講，不可報成「通過」。
• 長 session runner 會被卡上疊加的舊指令搞混——重跑類任務開新 session 或由首腦派 subagent，prompt 明寫「只照最後一段」。

commits（BE feature/review，本棒）：672b9381d（決策者裁現在合回，開 CM-2109）、4f7b83c9b（CM-2109 Done）、85fb5f3fb（開 CM-2110 發版卡）、7acbca2ea（開 CM-2111 郵件卡）、69433d8ac（開 CM-2112）、66b8a525e（開 CM-2113）、038381493（掃描線四件同批）、cbeedfbce（登記 FR-117）、f32ec83fc（開 CM-2116～2118，第一二段過）、416b3aaac（CM-2113 Done、七項全裁完）、c836300d7（CM-2115 Done，開 CM-2119）、4af21780b（CM-2114 Done）、832cdabcb（CM-2119／2117／2118 Done）、7a0ef639e（CM-2116 決策者裁定，開 CM-2120）、9a45966d3（CM-2110 第三段過，CM-2120 Done）、d5ff6bc55（CM-2116 Done，決策者裁補發 1.4.1）、da9b73ae0（1.4.1 前置核過，開 CM-2121）、5ef46e04f（1.4.1 發佈，第四段過）、a7f403856（決策者放行基線重產與 188 build）、197d1e5c5（基線重產驗收過，開 CM-2132）、fb54db0a8（CM-2132 第二輪 Done）、65620f07e（開 CM-2134，暫停零碎補發）、18e190371（CM-2134 Done）、0aeeef031（打包差異盤點，開 CM-2135／2136）、2951898b0（決策者裁版號 1.21.0b1，開 CM-2137）、47070df4a（決策者裁順序：本體→agent→LC）、7ab25f920（決策者：總測等雙邊更新後一起做）、b376d7445（記版本對應表待辦，總測後另開 FR）、d8b85e097（CM-2135 Done）、e2b6e071e（CM-2137 Done）、6dcec9894（CM-2136 Done，188 最終重跑就緒）、82160fd17（188 build 全綠，記 PROD 公鑰缺口）、dc51bd3dd（本體出包完成，＋本 block）。未 push。 套件 monorepo commits（發版相關，本棒）：iam 1.4.1→1.4.2→1.4.3（.mo 入版控）、integrity 1.2.1（刪死方法）、其餘 16 支各自 bump 見上方 STATE §1 版號清單。 BE 工作區最終 HEAD：99b0721c3（18 支 pin 完成）。

給第 6 棒的一句話：程式面與本體發版打包全收完，剩 agent 輪、LC 輪（含 PROD 公鑰）、雙邊部署 DEV 總測、正式 1.21.0 定版。接手先讀 STATE §1「當前狀態」與「🔴 第 6 棒接手後做什麼」，agent 輪先派唯讀盤點、別邊撞邊修（本體那輪連撞四次是教訓）。

• 第 6 棒只更新了 STATE 未寫 LOG block，第 7 棒補一行：決策脈絡與教訓見 STATE「第 6 棒」四節（09-25 午／晚、09-26 傍晚／晚），不在此重複。

做了什麼

• 第 8 批 12 張分三批驗收：派獨立 opus 驗收員（甲 5、乙 4、丙 3）開檔核對＋帶 PYTHONPATH 重跑；首腦抽查關鍵點（202 守門寬嚴查 DEV 子層成員表為 0、遮罩十種樣本自己打、shell 捷徑防護讀全段）。退回 3 張（CM-2212／2213／2214），補完再驗全 Done。
• 全量差集對 b2 新增紅燈 0（做法見 STATE 最末節）。
• 開 CM-2223（8-M，分類改常駐服務，併入 CM-1871），commit baf0e2d4c；CM-1871／CM-2061／CM-2197／母卡 CM-2170 都已加註。

決策（決策者裁）

• 落地版證據自動分類一定要上，是 b3 驗收項目；做法 C 案常駐服務。
• CM-2197 先不派、CM-2061 等 CM-2223 驗收後才派——前面還有檢查與修正，先跑是白工。

推翻了什麼

• 首腦一度引用 FR-063 D4「落地版停用分類」當現行決策，建議 CM-1871 延後；實際 FR-107（09-16）已改判開放。D4 只剩「為什麼當初沒做」的歷史意義。
• 首腦兩度建議先派 CM-2197 第 1～4 段、同時派 CM-2061，都被決策者叫停：兩者的輸入都會被 CM-2223 改掉。

教訓

• 🔴 排順序先看「輸入會不會再變」：盤點／查證類工作若依賴的程式還在改，現在做就是白工。「能先開始的就先開始」不是省時間。
• 🔴 不要替決策者決定「延後」：功能要不要上是決策者的事；首腦的工作是把方案想清楚、列取捨、給建議，不是提議把驗收項目往後推。
• 引用裁示前先查有沒有被後來的 FR 推翻（D4 被 FR-107 推翻，grep 同主題的新 design.md）。
• 派 subagent 跑全量測試會被長輸出塞爆 context（本棒一次失敗）；改成背景腳本、輸出寫檔、只讀摘要。
• 名詞講白話：「預發版」要說成「測試版 b3」。

commits：baf0e2d4c（開 CM-2223）＋本交棒 commit。修正線工作區未動（驗收唯讀）。未 push。

給第 8 棒的一句話：現在只有一件事——派 CM-2223，看它回寫的設計、驗實作；通過後才派 CM-2061，最後才發版。prompt 在 STATE 最末節提到的卡上，不要提前派 2061／2197。

做了什麼

• 接手時發現 CM-2223 已被前棒派出且 runner 回寫了設計草案（STATE 寫「待派」是過期的）。審草案：九點六點照做、一點改法（分類 image uid 改 1000 而非 compose 覆寫，LibreOffice 要 home）、兩點補（升級路徑不跑 write_configs 要用 grep-缺才補、docker runner 後半 150 行抽共用基底）；另抓出四件草案沒提的（升級服務清單寫死六個、build 原料不在 wheel 要 188 clone monorepo、log 遮罩是照 docker argv 寫的、工作目錄 JSON 會累積）。
• 決策者問「上線時怎麼處理的、推論對嗎、常駐對嗎」：實查三台 api 容器都無 docker／socket，189 舊 POC 是主機直跑 Python 所以舊線能用；FR-063 D4 明文停用、FR-107 改判開放但只做了 image 進包那一半。三案比較（掛 socket／併進後端／常駐服務）後維持 C 案。
• 逐張驗收 CM-2223／2061／2224／2225／2226／2227／2228／2229／2197，每張都自己開檔＋實跑（分類服務起 read-only 容器用真金鑰跑 docx+xlsx；注入攻擊實測；竄改 hash 實測；docker 上限與逾時 kill 實測；FE 完整 build；190 七項實查）。退回 0 張，但三張 runner 回寫與事實不符處記在卡上。
• 開卡 CM-2224～2229 六張、CM-2061 開工註記；push 三 repo；188 clone monorepo 切 branch；決策者要求下做了 b3-資安修正驗證清單.html。

決策（決策者裁）

• 證據分類走 C 案常駐服務，一次到位用 HTTP 不用資料夾輪詢。
• M07 四件全進 b3（#89／#132 各一張、#129+#131 開發機半併一張）；第 217 項剩餘半也進（CM-2228）。
• base image 釘 digest＋分類 pip 走 Nexus 進 b3；apt 鎖版與 Nexus apt 代理記 follow-up。
• 190 不走 --upgrade，移除後全新安裝 b3。
• 之後不通過的直接貼首腦對話（含截圖），驗證清單只收勾與短備註。

推翻了什麼

• STATE 第 7 棒末節「CM-2223 待派」：實際已派且回寫設計。
• 卡 CM-2061／2225／2226／2227 引用的 M07 條號（第 1／2／4／5 條）全錯，runner 逐張更正為第 5／6／8／12 條——開卡時 M07 條號要對報告表，不對 SUMMARY 出處欄。
• CM-2229 runner 一度寫「FE branch 不對未做」，實為看錯目錄，FE 工作區一直在。

教訓

• 🔴 驗 hash 鎖定不能用整個 Dockerfile build：docker layer cache 讓 pip 那層不重跑，竄改後 build 照過，會誤判「校驗沒作用」；直接在乾淨 python 容器跑同一句 pip 三分鐘出結果，前兩次各等二十分鐘裝 LibreOffice 全是白等。
• 🔴 runner 說「實跑過」要找痕跡：CM-2223 說「含內嵌圖 docx 實跑通過」但本機無新 image／容器事件／job 目錄，測試用 docx 也沒內嵌圖；結論剛好對是因為首腦自己跑了。
• 對決策者的問題先查事實再答（三台實查、189 舊部署形態、FR-063/107 原文），不要用 STATE 的轉述。
• 派 FE 相關卡要把工作區絕對路徑寫死在卡上。
• 出包的 sha256 檔是相對路徑，要 cd 進 bundle 目錄驗。

commits：主 checkout 5fc4de4bb／7d572f2e8／14ece8013／c2a7d5912（開卡）＋本交棒 commit。修正線 BE 046553756→fa2d59b30（8 個）、套件 87fd5439→35ba8e84、FE 2cb7fb4→53a8d6a，三 repo 已 push。

給第 9 棒的一句話：b3 在 190 等決策者總測。你的工作是收他貼來的錯誤回報（含截圖）：每則先查 log 對卡初判、記進收集卡，累積一批再分類開卡派修；不要一則一修、不要合回主線、不要動 STG／POC。

做了什麼

• 收決策者 190 總測回報 30 則（收集卡 CM-2231 #1～#30），每則 190 log／DB 實查根因、file:line、修法；只有 #19（AI 儀表板）、#17／#18（Drive 授權）、#4（郵件憑證）對得到 b3 驗證清單，其餘是總測順便挖出的既有問題或新需求。
• 開第 9 批（b4）：第一批 8 張（2232～2239、2242）、第二批 11 張、第三批 2251、第四批 2252、9-V 2260、9-W 2261，加 FR-121 六張（2254～2259）。全部首腦逐張開檔＋自跑突變驗收，紀錄在各卡尾。
• 查證 agent 認證（190 實打）：註冊要 token（空 400／假 401）、控制面要 RS256 JWT（假 401）、資料面 8443 mTLS（不帶憑證握手失敗）；AGENT_AUTH_MODE=full 是唯一模式。
• Nexus 帳密輪換：決策者裁 jedi 一組通用；admin 已換密碼；188 三檔（.netrc／auth.toml／.npmrc）已設；本機 auth.toml 維持 jedi。
• agent 1.1.0b1 包從 188 推到 190，決策者互動安裝完成並註冊成功。
• 給了 b4 出包第 1 步（20 支套件發版）的 runner prompt，等放行。

決策（決策者裁）

• 資料庫統一存 UTC、前端顯示先寫死 Asia/Taipei → CM-2245 退回改法；全庫 timestamptz 這次修，開 FR-121。
• 匯入原始檔必須留（客戶有疑問要能回覆、要能重現），改存儲存後端，暫存檔管理介面這版不做，所有同類功能都要調 → CM-2251（8 處）。
• 不再開 subagent（sonnet 必爆、8 支同時回報也爆）：runner session 依序做、每 session ≤4 張。
• CINC Auditor（Apache 2.0）裝進後端映像；回饋整合設定搬系統設定群組；CA 憑證欄摺進進階設定、驗不過才在錯誤訊息指路。
• #27 viewer 可被指派不處理；#26／#28 是決策者沒按開始執行，正確行為。
• OpenVAS 逾時預設改 3 小時不改「掃到完」（防火牆吞包會無限卡）。

推翻了什麼

• CM-2234 作廢（subagent 兩次撐爆）→ 拆成 FR-121 六張。
• 首腦原判 flow-engine 三張表 UTC 寫入是錯的（DEV 舊資料整批偏 8 小時誤導），真正 UTC 只有 last_seen_at／reviewed_at／iam 改密碼 created_at——判寫入時區看安裝版真機不看 DEV。
• 首腦對 #3／CM-2233①／CM-2250 的「不留檔」裁定被決策者推翻。

教訓

• 🔴 首腦 session 自己也會爆：一天內收 30 則回報＋開 27 張卡＋逐張驗收＋監控通知，8.3MB jsonl 後 compaction 失敗。收報型首腦每收完一批（統整後）就該中繼交接，不要撐到晚上。
• 🔴 回報問題必附分析與建議（決策者三度點名「不能只列問題」）；回報要白話，「守衛」「殼」這類字決策者看不懂。
• 決策者要的是修好，不是省 token；「往後推」會被點名。
• CM-2261 打折：出貨預設在套件 003 migration，主線 seed 改不到新裝機——改工具預設值要看 seed 在哪一層。

commits：主 checkout 開卡／STATE 系列到 baa6b1902。修正線 BE 到 ee383bb40、agent 到 1b71a0c（1.1.0b2），套件／FE 見各卡。未 push。

給第 10 棒的一句話：b4 程式面 29 張全部修正待驗證，只剩 CM-2261 套件 003 是否改要裁；出包第 1 步 prompt 已備，等決策者放行；#31 問卷清單只看作用租戶是全站性問題，等裁進 b4 或後。

做了什麼

• 從第 9 棒 jsonl 補記其 LOG block 與 STATE（它 compaction 失敗沒交接）。
• 驗收 CM-2261／2262／2263，記收集卡 #31～#33，開 CM-2262（問卷範本＋題目數）、CM-2263（發版）。
• 決策者指示「剩下的你做」：基線重產（含 DROP 基線庫 12 張 *_old）、188 BE＋agent build、封包、scp、190 升級與 agent 升級、升級後實查。全程唯一卡點是 FE image tag 兩制，手補 docker tag 解。
• 產桌面 b3-UI可驗清單-22條.html（234 條總表挑出 UI 可驗項）。

決策（決策者裁）

• CM-2261 套件 003 准改、併 jedi-detection 1.2.2 發；#31 問卷清單租戶範圍先不修；套件發版放行；第 2～4 步首腦直做、push 授權。
• 測試連線「有權限的人仍能把帳密送到自填主機」——說明現況，主機白名單層未裁。

推翻了什麼

• CM-2197 寫「20 支發版」→ 實為 19 支（oscal-v2 2.5.0／integrity 1.2.1 b3 已發且之後沒改）。
• 第 9 棒 STATE「agent 待決策者互動安裝」→ 接手時已裝好。

教訓

• 🔴 首腦 session 一天收 30 則回報＋開 27 張卡＋監控會爆；收報型首腦每批統整後就該中繼交接。
• 基線庫 *_old 表若不 DROP，02-schema 會帶給新裝客戶——「留一版」設計只適用既有客戶升級路徑，重產基線前要清。
• FE image tag 照 package.json 是 -beta.N，bundle 要 bN；b3 靠手補，b4 又踩，該進腳本。
• 本機 keychain 的 Nexus 密碼打 pypi-group 會 401，從 188 用 .netrc 驗雜湊才通。
• .env 密碼欄是 DB_PASSWORD 不是 DB_SECRET（三次抽錯）。

commits：主 checkout d74b7d0a1／29041b628／d8fbef3f2／0621c869a＋本 block。修正線 BE 6f7e678ca→12dee3157（已推）、FE 55ca905、套件 d94a472d、agent 1b71a0c（四 repo 已推）。

給第 11 棒的一句話：190 是 b4，決策者總測中；你的工作是收回報進收集卡、開「API 批打驗證卡」（149 條）、等統整再開修正卡；不動 STG／POC、不發正式版。

做了什麼

• 147 條非 UI 驗證開四張卡 CM-2264～2267（每條指向修正卡手測段、卡上帶 190 登入配方與角色帳號，憑證不入卡）；V1 跑三輪（blsfrank／blsview／填寫中問卷各解一類打折）、V2 兩輪、V4 一輪＋補驗；V3 第一次 runner 把「炸彈／打垮」當攻擊指令跑不完，補「驗收語言」段重派。
• 收集卡 CM-2231 #34～#40：#34 抽取死循環（190 id=1 手動清欄解鎖，決策者核准）、#35 iam 八處 entity log 洩密碼雜湊、#36 正式模式日誌量、#37 登入 60 秒內二次登入 429、#38 九表 RLS 路徑拆陣列子看父、#39 兩條健壯性、#40 file 型重抽 app context。
• 開修正卡 CM-2268／2269／2270／2271，四張回報全部開檔＋自跑突變核過收「修正待驗證」。
• 主 checkout 起本機 BE 8000＋FE 5180 給決策者用（venv 曾被指到修正線 12 支 editable，poetry install --sync 換回）。

決策（決策者裁）

• 建卡方式：驗證卡只指向修正卡既有手測清單，不另寫測法。
• 190 清 detection_profile_versions id=1 extraction_error（資料面解鎖）。
• 建子租戶帳號 blsfrank、低權帳號 blsview 補驗。
• #38 RLS 洩漏開卡進 b5（SaaS 才打得到，修法便宜）。
• 驗完就進版、工作區合回 branch（第 12 棒做）。

推翻了什麼

• 「190 抽取失敗＝CINC 沒包到」→ 實為 b4 新 CHECK 撞共用 update() 跳過 None 的死循環，CINC 有跑成功。
• 「viewer／auditor 帳號可驗能力閘」→ 190 五帳號全掛 System Manager（98 能力點全給），卡上角色名不代表權限，要另建只掛基礎角色的帳號。
• 卡上「攤平副本一起 commit」→ scripts/sql/packages/ 是 build 期產物不入版控，做不到（CM-2271 runner 指出）。

教訓

• 🔴 runner 回報進來要立刻核，不能等——CM-2268 最早回、最晚核，漏了一天。
• 派「送超大請求驗上限」這類卡，措辭要用 QA 驗收語言（「上限有生效」「剛超一點」），引資安報告原文的「炸彈／打垮」會讓 runner 判成攻擊指令。
• 驗權限守門前先查測試帳號的實際能力點，不看角色名；沒有「該被擋」的身分等於什麼都驗不到。
• 登入首發與重送共用冷卻是老病，一分鐘內登兩次就撞；runner 密集拿 token 會跟決策者手測互踩。
• RLS 兩種寫法並存時，守衛測試要掃全庫 pg_policies 而非只掃修過的表。

commits：主 checkout 2061b7a27→aeb986a55（18 支，全 docs）；修正線 BE 446f4bcf6／b99f88620／6c74ff0e3；套件 f44d1af7／bf97b904／f679363d／6e0d0d4b。四處皆未 push。

給第 12 棒的一句話：你是進版首腦——等 V3 回報核完、決策者手測收尾，就照 STATE 末節六步做合回＋b5 出包（先問 FR-113 掃描線放行沒）；CM-2271 帶一支主線 migration，基線要重產。

做了什麼

• 核 V3 CM-2266（24 條 15✅／8⚠️／0❌），唯一要修的是 runner 順帶撞到的既有 bug：匯入任務 Excel 端點 500（jedi-compliance-audit _resolve_ssp SQL 查 ap.uid，欄叫 uuid）——一字修，開 CM-2272，套件 36290a30。
• 四 repo fix/security-b1 合回 feature/review（BE 352 檔衝突全是密碼遮罩措辭，取主線；smoke 腳本環境變數統一 PROBE_*）。
• 開 CM-2273～2277 五張正式版前置卡；2273 派 runner（第 1 段開檔核過再放行第 2 段）、2275 派 runner、2274 擱置、2276／2277 首腦直做（決策者「後面不複雜的你做」）。
• 進版 1.21.0：彙整型 RN（不貼 beta）、pyproject、99-stamp 185 支、FE 對齊、spec-site v1.21.0 快照＋legacy 複製；agent 轉正 1.1.0。
• 188 build 全綠→封包→190 升級（1 支 migration）＋Agent 1.1.0→188 STG 1.19.0→1.21.0 跳升（123 支全過、資料量不變）。POC 未動。

決策（決策者裁）

• FR-113 掃描線已結束，放行合回；b5 四張隨合回進正式版不另出包。
• 這版沒有 PROD LC 主機，CM-2274 擱置、封包仍 --skip-prod-key-check。
• 舊 tag 不補，只打本次六個新版號。
• 全站回歸 gate 這版不跑（測案過時），收口後另派一棒重整。
• 188、190 都升級，POC 先不動；決策者明早驗收。

推翻了什麼

• 卡上「b4 發版基準＝各支進版 commit」→ runner 比 wheel 證實實際發版點是 d94a472d，FR-121 時區改動早已在 b4 wheel 內。
• 「1.20.0 兩路驗證過＝升級路徑安全」→ 拿 STG 真實 1.19.0 dump 排練，第 16 支 fr093-4d 就炸（scope 欄由行序在後的 CM-1790 才加；4d 的 scope 是 CM-1778 驗收後補的，驗證時還沒有）。修 85ae5aadc。

教訓

• 🔴 升級驗證要拿真實舊版客戶庫排練，「上一個 beta 升上來」與「乾淨新裝」兩條路都覆蓋不到「隔一版的舊庫」。以後每個正式版出包前，固定拿 STG／POC 的 pg_dump 灌臨時庫跑一次 migrate 再封包。
• 修 migration 內容後要重 build init image 再封包，並用 image id 核 bundle 內是重 build 那顆（本棒差 5 分鐘就封到舊的）。
• git add -u . 在有既存髒檔的 checkout 上解 merge 會把髒檔掃進 index；解衝突後要逐檔比對「staged 內容＝修正線內容」才 commit。
• pgrep 從 ssh 遠端跑會抓到自己的命令字串，判「有沒有 nuitka 在跑」要看 ps -p 或 pgrep -x。
• 189 STG／POC 的 install.sh --upgrade 會把 CLI 從 guidant 改名 guidantai，升級後驗證腳本要跟著改。

commits：主 checkout deb9f00b1（開卡 2272）／fbbbb6d40（merge）／1b2bf92e3（開卡 2273・2274）／e04accb5d（runner，pin）／712fb5b64（runner，基線）／02f680835（進版）／85ae5aadc（4d 修）＋本 block；FE feac690（merge）／50bda00；agent 1355869／6c17d21；套件 feac7698（merge）／36290a30／8765bd39（runner）。BE／FE／agent／套件 feature/review 皆已推（決策者令）。

給第 13 棒的一句話：決策者驗收 190 與 STG 後，剩 POC 升級（同一條 1.19→1.21 路徑 STG 已走過）、STG Agent 怎麼處理、git tag、母卡 CM-2019 收尾與回歸測試重整派工；不要在決策者驗收前動任何環境。

推翻了什麼：昨晚 LOG／STATE／CM-2277 寫「STG Agent 0.2.30 配新雲端會被拒，要裁三選項」——錯。188 是主產品機本來就沒有 Agent；那個 zen_sutherland 容器是 8/26 FR-066 T-6.6 打包測試殘留（evidence-agent --version 一次性、無 port／volume、restart=no、四週零 log、從未註冊），決策者一眼指出。 教訓：看到 docker ps 有個 image 名像產品元件的容器，先看 Cmd／RestartPolicy／log 有沒有在動，再判它是不是「這台機器的服務」；主機角色（主產品機／Agent 機）是先驗條件，不是靠容器清單反推。

第 11 棒補記（2026-09-28 上午）：189 升 1.21.0 撞兩個升級路徑 bug，首腦本體修

• 決策者 09-28 上午自行把 188／189／190 升到 1.21.0。189（1.19.0 直升）撞到：#42 升級第三輪角色回補用「持有 flow_template.create」當管理員判準，IT Manager 89→98／PM 58→98 塞滿（升級前備份差集實證，190 PM 同）；#43 fr093-1 回填把 23 支套件 migration 假登記，agent_tasks.payload_ref 沒建、agent 心跳 500（四環境盤點只 189 缺這一項）。
• 決策者裁「首腦直接修」：CM-2280 563355d22（模板改 is_admin＋守衛 2 條）、CM-2281 54d171378（唯讀盤點 SQL＋撤假登記 migration＋守衛 3 條）。皆突變驗過。主線 migration +1（共 +2）。
• #41：管理員改自己掛的角色拿掉帳號管理權限後 FE 停原頁 403、選單不刷新（決策者自己釐清），待開小卡。
• 推翻：「blsemp1 全功能」→ 是它當時掛 IT Manager；換 IT Member 後正常，改不了角色是權限正確生效。
• 教訓：🔴 升級腳本用「持有某能力點」推導身分是錯的，身分永遠看旗標；回填登記類 migration 必須驗物件存在再登記，「基線已有」是假設不是事實。
• 待決策者放行：189 角色還原 SQL、189 補套 payload_ref；190 PM 敏感能力點 28 個待裁。

做了什麼

• 189 POC 1.19.0→1.21.0：備份兩份→--upgrade 第 104 支 jedi_iam/002 deadlock（舊 api 查 user_roles 撞 ALTER users）→決策者裁停 api／socketio 重跑→19 支補完。升級後 #42／#43 由第 11 棒接手修（CM-2280／2281）。
• Agent：121／60.167／122 升 1.1.0 一次過（401→自動重註冊）；60.166 註冊 token 早被 disable，re-enroll 腳本在清憑證後卡住（compose run 不返回），殺掉後手動換 STG 現行 token 起容器註冊成功；123 升 1.1.0 但雲端位址過期＋憑證不配，原生 0.2.30 已停用，等 DEV token。
• 開 CM-2278（支援頁版號）、CM-2279（POC 升級卡）；總表記 /version 端點裁不動。

決策（決策者裁）

• POC deadlock 用「停服重跑」（A 案）。123 原生版允許 uninstall（實做 disable --now 留檔）。POC 本身不裝 Agent。/version 免登入端點不動。FR-114 主線結束，交下一棒整理兩週 case 與文件。

推翻了什麼

• 「STG Agent 待裁」→ 188 主產品機無 Agent，容器是 T-6.6 殘留（決策者指出）。
• 「1.0.0→1.1.0 升級 401 自動重註冊必成功」→ 前提是原註冊 token 仍 enabled；60.166 的 token 8/27 被停用，自動重註冊必敗。
• 「POC 全好」→ 第 11 棒同時在修 189 直升踩到的兩個 bug，我的驗收只看服務與資料量，沒看角色能力點數與 agent 心跳 500。兩個首腦平行動同一台機器，各自的世界觀都不完整。

教訓

• 🔴 installer 升級第③步套 migration 時舊版 api 還在跑，有 Agent 心跳或使用者在打就會 deadlock；STG 沒踩是因為沒人打它。升級 SOP 要加「先停 api／socketio」。
• Agent 升級前先查雲端 remote_agent_enroll_tokens 該 token 是否 enabled，否則自動重註冊會 401。
• guidant-agent-compose re-enroll 的 _certs_volume_sh（compose run 臨時容器）在 60.166 不返回；等價手法是直接改 .env 的 REGISTRATION_TOKEN 後 up -d。
• 同一台機器兩個 session 同時動，要在 STATE 立刻互寫；這棒與第 11 棒各寫各的節，讀者要兩節合看。

commits：主 checkout 9d59e436a（總表＋CM-2278）→本 block。第 11 棒：5dfce23de／026b6af13。修正線未合回：563355d22／54d171378。

給第 13 棒的一句話：三環境都是 1.21.0 了；先把修正線那兩支合回並重產基線（裁 hotfix 或 1.21.1），回寫 CM-2279，等 DEV token 修 123，然後開始決策者要的「兩週 case 與文件整理」。

做了什麼

• 接手 pre-flight：三環境 /version 皆 1.21.0（commit 02f68083）；修正線尚有 563355d22／54d171378 未合回；CM-2279 已是修正待驗證（STATE 寫 Not started 過期）。
• 核 CM-2282 四件待裁的前提。第 2 件「六條掃描線新發現修正未開卡」不成立：總表 44 條「未修」裡 27 條屬第 8 批 CM-2211～2222（Notion 全 Done、1.21.0 已出），5 條屬舊線退場（CM-2061），3 條 RN §7 已裁不修；真正沒卡的 9 條＝任務越權六條（M06-17～22）＋M18-8＋M03-7＋M07-13。
• 核第 4 件：docs/spec-site/current/ 無任何頁提到 1.21.0；v1.21.0 快照與 current 只差 2 個檔＝內容等於 1.20.0。
• 開卡 CM-2283～2289 一次建完；CM-2282 append 裁示＋清單、改 In progress。

決策（決策者裁）

• 127 張修正待驗證全 Done。沒卡未修的另開 1.21.1 hotfix 母卡，後續加 AI 資安議題。FR-114 母卡先合回＋基線補套再收。SPEC 先補前五處。

推翻了什麼

• CM-2282「六條掃描線新發現修正未開卡」→ 是狀態欄過期非未修（見上）。
• CM-2282「current 提到 FR-114 的頁只有 5 頁」→ 那 5 頁是 release-notes，spec 頁是 0。
• STATE 第 12 棒「CM-2279 Not started 待回寫」→ 已是修正待驗證。

教訓

• 總表 # 編號曾重排，FR-119 裁定表引用的「第 171／172 項」與現在總表 #171／#172 不是同一件；對照一律用 M 編號。已寫進 Z3 卡。
• 盤「未修」要連到卡的實際狀態再判，不能只讀總表狀態欄——狀態欄是人手改的、會落後於 Notion 與 git。

commits：本 block 所在 commit（STATE 節＋LOG＋cards JSON）。

做了什麼：派 Z1／Z3／Z5／尾巴四棒平行，回報後本體開檔核；Z3 過後派 Z2、Z4；六張全核過改 Done，CM-2282 append 結案段改 Done。與掃描首腦分工（他收掃描線 CM-2290／資安總表 CM-2291，我收修正線／docs/security-report/）。順手：CM-2279 過期待辦拿掉；hotfix 母卡撞號 FR-122→FR-123。

決策（決策者裁）：修正待驗證一律 Done；CM-2289 hotfix 全部等下一版；v1.21.0 tag 打在 02f68083、之後修正進 1.21.1；jedi-packages 名冊只列現役 21 支。

推翻了什麼：Z3 卡原寫「#89／#129／#131／#132 隨舊線退場」→ 實為第 8 批 CM-2225／2226／2227 已修（掃描首腦提問才查出）。CM-2282「六條掃描線新發現未開修正卡」→ 狀態欄過期。

教訓：另一 session 平行登記 FR 編號時會撞號——開卡前 grep -oE "FR-1[0-9]{2}" docs/features/README.md | sort -u | tail -1 要在建卡當刻再查一次，不能沿用一小時前的數字。驗證卡（CM-2061 類）的「結論」是「問題還在、建議開卡」而非「問題消失」，引用前讀全文。

commits：ff922e07a／6c84c8acd／本 block。