# FR-114 交接日誌（LOG，append-only） > 每棒結束追加一個 block：commits／決策／教訓／推翻了什麼。現況看 `FR-114-STATE.md`。 --- ## 第 1 棒：派工首腦（2026-09-21 晚 ～ 09-22 上午，Fable） **做了什麼** - 讀 `_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 停下來問的那兩件，夜跑會直接停整批——規格品質決定夜跑能跑多遠。 --- ## 第 2 棒：派工首腦（2026-09-22 下午，Fable） **做了什麼** - 接手盤點：夜跑第一輪三張（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。 --- ## 第 3 棒（2026-09-23）首腦：第五輪驗收＋CM-2042 裁定改向＋第六輪備清單 **第五輪自動跑結果**：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 ` 讀完整張卡，卡是自足的；卡尾兩段「首腦裁定」（第 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 的「特別盯」段。 ## 第 4 棒（2026-09-23 下午～晚，Fable）首腦：5A-1／5A-2／X-3 三張收完，程式面第 1～5 批全 Done，合回前整理稿 **做了什麼** - **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 早上驗收，接手者讀完盤點完停下，等他一項一項發令。 --- ## 第 5 棒（2026-09-24，Sonnet）首腦：決策者七項裁決全裁完、掃描線插單四件、套件發版、188 本體 1.21.0b1 出包 **做了什麼** - **決策者 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 棒（2026-09-25～26，補記）首腦：第 7 批全收＋FR-120 高風險追加＋第 8 批開卡 - 第 6 棒只更新了 STATE 未寫 LOG block，第 7 棒補一行：決策脈絡與教訓見 STATE「第 6 棒」四節（09-25 午／晚、09-26 傍晚／晚），不在此重複。 ## 第 7 棒（2026-09-26，Fable→Opus）首腦：第 8 批驗收全收、全量差集、分類改常駐服務開卡 **做了什麼** - 第 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。 ## 第 8 棒（2026-09-26～27，Fable）首腦：分類改常駐服務落地、M07 五件收口、b3 出包全新裝 190 **做了什麼** - 接手時發現 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。 ## 第 9 棒（2026-09-27，Fable；context 爆掉，由第 10 棒從 jsonl 補記）首腦：b3 總測收報 30 則、b4 第 9 批 21 張＋FR-121 六張全收、Nexus 帳密輪換、agent 裝 190 **做了什麼** - 收決策者 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 或後。 ## 第 10 棒（2026-09-27，Fable）首腦：接爆掉的第 9 棒、b4 程式面收口、出包四步做到 190 升級完成 **做了什麼** - 從第 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、不發正式版。 ## 第 11 棒（2026-09-27 晚～09-28 凌晨，Fable）首腦：147 條驗證卡開跑、收 b4 回報七則、b5 候選四張開＋核 **做了什麼** - 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，基線要重產。 ## 第 12 棒（2026-09-28 凌晨，Fable）首腦：合回四 repo、1.21.0 正式版進版出包、190＋188 STG 升級 **做了什麼** - 核 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 收尾與回歸測試重整派工；不要在決策者驗收前動任何環境。 ## 第 12 棒補記（2026-09-28 早）：更正「STG Agent 待裁」 **推翻了什麼**：昨晚 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 個待裁。 ## 第 12 棒補記（2026-09-28 午）：POC 升級、六台 Agent、與第 11 棒平行修 bug 的收攏 **做了什麼** - 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 與文件整理」。 ## 第 13 棒（2026-09-28 午後，Fable）首腦：接手、裁四件、開收口五張＋尾巴一張＋1.21.1 hotfix 母卡 **做了什麼** - 接手 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）。 ## 第 13 棒補記（2026-09-28 晚）：收口五卡全收、尾巴合回、hotfix 延後 **做了什麼**：派 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。