FR-172 交接紀錄（LOG，append-only）

每棒追加一個 block，寫完不改。發現舊 block 有誤，在新 block「推翻了什麼」欄寫明。現況看 FR-172-STATE.md。

角色：首腦（分析決策人員）。決策者開場五點需求＋要求「爬之前留的訊息統整」「與 171 一起分析分工」。

時序

1. 讀 FR-167 STATE（待辦 6／25／26／42／54／58～64、§4-3 建議 FR-172、§5 裁示）、requirement-notes（原 docs/draft_requirement_spec/2026-11-01-agent-independent-update.md）、agent-rollout-spec §1／§6／§7／§11／§13、update-site-schema-spec、release-signing-spec、release-runbook Agent 段；FR-171 STATE／LOG／discussion 全文、memory feedback_no_heartbeat_piggyback_messaging。
2. 探脈程式碼：BE build_bundle.sh ⑧、publish_draft.sh、.gitlab-ci.yml package 段；update-center releases.ts（r2Key、releaseAdoption）、routes/client.ts 三端點；evidence-agent 無 CI、build_compose_bundle.sh 產物、update_sync.py 進度三形狀、outbox.py kind、CONSOLE_SCOPES 六項、console ops_routes.py；FE console router.js 九頁、agentRolloutState.js 八格已改讀 agent.progress。
3. 白話複述需求＋四題請裁 → 決策者：不要 Agent 連外、主控台發動＝主系統幫這台、171／172 一起看、要雛形。
4. 登記 FR-172-2611-agent-independent-update、git mv 需求草稿進來、寫 discussion.md v1（§0 概述五階段、§2 現況十環節、§3 目標設計 P1～P4、§4 與 171 分工、D1～D12）、雛形十頁（抄 FR-167 雛形 v2 與 Agent 主控台版面）。
5. 決策者中途貼 189 Demo 三問題：派工等 3 分 15 秒（＝171 主題 A 實證，寫進 171 v2）、CSP 擋 8444、CINC 報告格式對不上（後兩者不屬 171／172，記 STATE §3 等令開卡）。
6. FR-171 討論稿改 v2：主題 B 從「心跳帶 config_versions」改「設定變了直推 POST /config/notify、Agent 來 GET /agents/config?versions 拉、心跳只剩存活與回執」；D9 擴大成 token 多把並存；新增 D13（備援期）；§7.5 與 172 分工；§1 加 189 實證；§2.2 加 v2 裁示段；§6 相容矩陣改寫。
7. README／STATE／LOG、build 兩站、commit。

決策（本棒提、決策者未拍板，全部進 discussion §5 D1～D12）

• 更新站加 product 欄不另開表；Agent 章用另一個 payload_type=agent_release_manifest；相容只擋「Agent 要求的主系統最低版沒到」；Agent CI 在 188 runner、主控台前端在 node 容器 build；Agent 包帶 release-keys/；新能力點 update；本機目錄 agent-bundles/<Agent 版>/ 留兩份；失敗 detail ≤ 4 KB；Agent 區對齊成「預先下載→更新」兩步；1.28 第 7 步搬包＋更新站補登 1.4.8；待辦 61／62 不併。

推翻了什麼

• FR-171 v1 主題 B「心跳帶版本號」——與 11-01 裁示衝突，v2 改通知＋拉（171 第 1 棒 STATE §3 已預告）。
• FR-167 design「Agent 單獨更新第二期不做」——決策者 11-01 改判要做，本案就是它。

教訓

• 決策者中途貼進來的 Demo 問題要當場分流：屬本案的寫進討論稿當實證，不屬的記 STATE 等令，不混進範圍。
• 兩個同週期 FR 的分工要寫在兩份討論稿裡各一節（171 §7.5、172 §4），只寫一邊另一邊接手的人看不到。

commits：BE 本棒一個 commit（登記＋172 四檔＋雛形＋171 v2＋兩站 build）。未 push。本棒不動 Agent／jedi／FE／update-center。

交給下一棒：STATE §3——等決策者裁兩案 D 項；裁完兩份 design＋cards.py＋兩張母卡。

時序

1. 決策者分三批裁 25 項（第一批 1～5 照建議；第二批 6 照 C 並要畫圖、7～11 照建議、12 不做過渡；第三批 13～15 照建議、16 取消、17 納入、18 照建議、19 文案改「連線：正常／僅單向／離線」、20 補「驗章只用現行版公鑰」、21 照建議、22 加全量 log 回傳、23 待辦 61 開一張、24 照建議、25 併修）。決策者中途裁「出貨前無客戶，所有舊版相容與備援全拿掉」，回頭改掉 7、8、12、16 與相容矩陣。
2. 決策者追問 mTLS／DPoP 各守哪條、工作 queue 在哪、token 搶註怎麼辦 → 答案寫進 171 design §2、§4、§5。
3. 決策者問 CI 自動簽章、GitLab／Cloudflare 有沒有金庫 → 查業界四組資料（Sigstore、GitLab＋Vault 官方、minisign 社群、SLSA）→ 決策者選自架 Vault、三 repo CI 分開、update-center 不進管線、排最後、Vault 與 runner 自己架。
4. 寫三份 handoff/cards.py（171：21 張 8 批；172：19 張 10 批；173：6 張 3 批）各跑驗批；新增 scripts/deliverables/cards_to_md.py 把表印成 design §6。
5. 寫三份 design.md、FR-173 README、登記 FR-173；更新 171／172 README 三段與 STATE。

決策（全部已拍板，見三份 design §1）

推翻了什麼

• 本棒上午討論稿 v1 的 D10「1.28 搬包＋補登 1.4.8」、D7／D13 備援、相容矩陣——決策者裁無客戶全拿掉。
• 首腦第一輪建議「簽章放 update-center Worker 零成本先上」——查業界後改建議 Vault／KMS，決策者選自架 Vault。
• FR-167 已定裁示「印章私鑰只在決策者 Mac、CI 沒有私鑰」——由 FR-173 D1／D2 正式推翻。

教訓

• 決策者說「看不懂」時不是要更多術語，是要「現在是什麼、哪裡痛、選了畫面上會怎樣」三欄；第三批重列一次才過。
• 「舊版相容」是預設反射，要在開場就問「有沒有客戶在跑舊版」，沒有就整批拿掉，省掉四個 D 項。
• 金庫題不要先給「零成本過渡」方案，決策者要的是正解；先查業界再提。

commits：BE 本棒第二個 commit（三 design、三 cards.py、cards_to_md.py、FR-173 資料夾、README 登記、三站 build）。未 push。

交給下一棒：三案 STATE §3——開 Notion 卡（171、172 同時；173 等收口）。

時序

1. 雛形定稿（決策者看過）：文案「開始更新／有新版本」、Agent 列表加連線欄、④ 加下載升級紀錄鈕、Agent 進度改成與主系統同一套 .steplist、新增 ⑪⑫ FR-171 金鑰登記簿兩頁；E-5／G-3 卡 append 首腦補充（7ac0f8f1e）。
2. 推 feature/FR-172；決策者開工作坊 31（171）、32（172），皆 auto。開跑前首腦檢查卡片四欄、repo 登記、分支、埠、Nexus 可達；預先把 CM-3411／3412 改暫緩擋住跨案依賴（17dc14107）。
3. 決策者回答密碼雜湊問題（Agent 本機用 argon2id、主系統舊帳號 bcrypt，鹽都嵌在雜湊字串裡）、Agent 主控台按更新與離線上傳的流程、主機 systemd 接手換版。SQLite 檔案加密裁延後（memory project_agent_sqlite_encryption_deferred）。
4. 決策者指派本 session 改當輔助首腦（工作坊首腦不能決定時由這裡接）。
5. 協助決策者在 172 架 Vault（FR-173，見該案 LOG）。
6. 交接時實查：工作坊 31 在批 2、32 在批 4；172 已驗收通過待確認 9 張；CM-3410 H-5 被工作坊首腦回報範圍超出（要改 jedi-detection 不變式＋約束），決策者裁暫緩另開新案、方向 A。

推翻了什麼

• 本案 D11「待辦 61 開一張主系統小卡同批」→ 實作時發現要動套件與資料庫約束，CM-3410 暫緩、移出本案另開新案。

教訓

• 跨案依賴在 auto 模式下要開跑前就用「暫緩」擋，不能等跑到才擋。
• 「開一張小卡」前要查清楚改的是主 repo 還是套件：H-5 寫「改 BE」但邏輯在 jedi-detection，小弟開工才發現。

commits：7ac0f8f1e、17dc14107，與本棒交接 commit。全部已推。

交給下一棒：STATE §3——輔助首腦待命；唯一主動事項是 171 批 3 合回後放行 CM-3411／3412。

時序

1. 決策者問工作坊進度與「兩張中斷的卡」→ 查 workshop.db 的 attention 與 events：CM-3410（卡片寫改 BE 但邏輯在 jedi-detection、被不變式與約束擋）、CM-3383（小弟做完沒改狀態）兩筆，決策者 20:45 已處理；CM-3383 後來驗收通過合回。CM-3391 跑很久 → 查 session 與 worktree mtime，確認活著、正在跑全量測試。
2. 決策者裁 CM-3410 另開 FR → 登記 FR-174-2611-url-profile-snapshot-sync，寫 requirement-notes.md（三處阻擋帶檔案行號、A 案、被排除的 B 案、預估三張卡、兩個待確認題）、README、STATE。未寫討論稿、未開卡。
3. context 將滿，交接。

教訓

• 查工作坊「中斷」先看 attention 表的 acked_at：有值就是決策者已處理，別再重報一次。
• 判斷小弟是否卡死，看 worktree 內檔案 mtime 與 pgrep，不要只看事件時間；大卡（CM-3391）長時間沒事件是正常的。

交給下一棒：STATE §3（輔助首腦待命；171 批 3 合回後放行 CM-3411／3412）。FR-174 由下一個首腦照其 STATE §3 開始討論，等決策者發令才開工。

時序

1. 接手實查 workshop.db 與 Notion：31 批 2、32 批 5；發現 FR-171 多一張 CM-3421 K-1b（決策者加開）、STATE §3 的「合回查法」查不到東西——工作坊的卡只合回自己的 ws-<母卡> 分支，不會進 feature/FR-172，兩個工作坊互相看不到。
2. 決策者令開 FR-174：探脈（套件三處阻擋、BE 接線、Agent 同步與下拉、DEV／189 資料、安裝包種子）→ 白話複述三題建議（沿用 url 欄、dev-sec 範例改隨套件帶檔、從 1.7.3b1 長）→「開吧」→ design D1～D10、cards.py 7 張 4 批、Notion CM-3422～3429、CM-3410 append 指向。略過討論稿與雛形。
3. 決策者問「172 撞到 171 批 3 要怎麼解、能不能先發」→ 查依賴圖：172 剩 9 張全鏈在 171 批 3 或批 2，無可先發；工作坊 32 首腦已把 3411～3414 改暫緩。答：等。
4. 決策者問「174 也要等嗎」→ 答只要 171 批 1 的套件（已驗收），選項 1：把 jedi-packages ws-CM-3379 ff 合進 feature/FR-172（5 commits，F-1＋F-3）並推。測試：detection 251 綠、protocol 42 綠、remote-agent 450 綠 1 紅（心跳 schema 多鍵，屬 K-1b 範圍、合前就紅）。
5. 順手重啟 DEV BE 8000 與 FE 5180（決策者要求）。

決策

• FR-174 三題照輔助首腦建議（STATE §2）。
• 跨工作坊分支合併由輔助首腦做（決策者選項 1 等同授權這一次；BE／Agent 那兩個 repo 等 171 批 3 後再合，屆時再確認一次）。

推翻了什麼

• FR-172 STATE §3「合回後 grep feature/FR-172 的 commit」查法：合回的落點是 ws-CM-3379 不是 feature 分支，查法改成看 Notion 狀態＋事件表 card_merge。
• FR-174 需求紀錄「原網址另存新欄」→ 改沿用既有 url 欄（D2）。

教訓

• 兩個工作坊各自的 ws-<母卡> 分支是孤島：跨案依賴的卡，前置「驗收通過」不等於「在我的工作區裡」，中間要有人把 ws 分支合進共同的 feature 分支。auto 模式下這步沒人做，下一個工作坊就會派出去撞「前置沒做」（3413／3414 實踩）。
• 套件 repo 自己的 .venv 會過期（jedi-remote-agent 的缺 jedi_agent_protocol、jedi_common 新模組），30 個 collection error 不是程式壞；改用 BE venv 跑才看得到真結果。
• 系統 python 起 BE 會靜默死掉且 log 沒寫到；一律用 .venv/bin/python（就是 poetry 的環境）。

commits：BE 70df7a26a（FR-174 設計與開卡）、本棒 STATE／LOG commit；jedi-packages a960e479（ff，已推 origin/feature/FR-172，遠端分支由本次 push 建立）。

交給下一棒：FR-172 STATE §3——等 171 批 3 四張合回 ws 後，合 BE／Agent 的 ws-CM-3379 進 feature/FR-172、跑守衛、放行 3411～3414。FR-174 等決策者開工作坊。

時序

1. 驗收批 1～5：U-1、U-2、A-0、B-0（2 輪）、S-1、S-2（2 輪）、S-3、H-3、H-1（2 輪）、H-2、H-4 全部驗收通過待確認。退回的三張：B-0 漏改 runbook 下游段；S-2 新內部端點沒登記豁免清單；H-1 保留規則會刪掉正在推送的那份包（補「推送中版號」注入）。
2. H-5 卡住：網址型存檔要推翻 jedi-detection 不變式＋改約束＋環境卡。決策者裁暫緩、另開 FR-174、方向 A。
3. E-5 派出後發現前置 E-4 沒做（E-3／E-4 暫緩不擋下一批）→ 決策者裁批 11 以後五張也暫緩。
4. 2026-11-02 FR-171 結案合回：手動把 feature/FR-172 合進 BE ws-CM-3401，解 6 處衝突；發現 E-3／E-4 缺契約 kind，補開 CM-3439 P-1（批 9，jedi-packages）；七張改回 Not started；待辦併 S-4。

決策

• 背景下載（H-2）走 background_jobs，不在請求內下 1.8 GB。
• AGENT_BUNDLE_DOWNLOAD 6249 → 6251（171 先佔）。
• 契約發版獨立成卡（一張卡一個 repo），BE .venv 由首腦驗收後代裝。
• 主系統 release_json 補 product、出貨基線重產、手冊三句、H-4 補點 → 併 S-4。

推翻了什麼

• design.md §6 寫 FE i18n 在 src/locales/、Agent 公鑰在 BE scripts/build/release-keys/：實際分別是 src/config/locales/i18n/ 與 scripts/installer/release-keys/（小弟照實際改，首腦確認）。
• 卡片寫 E-3／E-4 只依賴 171 的 send_event／分派器：還要契約 EVENT_KINDS 有升級三種，否則分派器拒收。

教訓

• 「暫緩」不擋下一批：前置卡暫緩時，依賴它的後續批要一起暫緩，不然 auto 會派出去撞空（E-5 實踩）。
• 跨工作坊依賴除了程式碼，還要查「共用契約清單」有沒有新項目（事件 kind、事件碼號段）。
• 事件碼是登記型檔，兩案平行時同號碰撞只有合併時才看得到，合完要跑 test_event_code_agent_contract。
• Notion 腳本在本機偶發 SSL 憑證錯，SSL_CERT_FILE=/etc/ssl/cert.pem 即可。

commits：BE 367c0bde7（合 feature/FR-172 解衝突）、本棒 STATE／LOG commit。

時序

1. 172 產出檢查（決策者懷疑品質）：實查 11 張已合回卡。BE 核心 agent_release_service.py 讀完、114 測試綠、三道防線突變（相容判定、保留規則、payload_type）皆紅；更新站主鍵 migration 在舊表塞資料實跑，19 欄完整搬過、新約束擋得住；releases.ts 每條 SQL 都過濾 product；更新站 188 測試綠（兩套 vitest config）；FE CSP 未放寬、/internal/agent-origins 三層防護。結論無須退回。
2. Agent API 規格：FR-171 站加 agent-api-spec.md（照 Stripe／GitHub 寫法，每端點欄位表＋範例）與 agent-api.openapi.yaml（OpenAPI 3.1，openapi-spec-validator OK）。發現指令端點錯誤格式 {error} 與他處 {error_code,msg} 不一致，記入規格。
3. 174 放行：探脈發現兩個擋點——套件分支落後 171 正式版（jedi-detection/pyproject.toml 版號衝突）、Agent profile_cache.CACHE_ROOT 寫死 /data（Mac 寫不進）。決策者選 B 案：補開 E-1 CM-3434、A-2 CM-3435 於批 4，H-1 挪批 5、Z-1 挪批 6。工作坊派 E-1 前先撞版號衝突，輔助首腦照卡上裁示解（4fa2db4a）。174 九張全做完，實查 DEV dev-sec 兩版轉 file 型、sha 一致、Agent 快取有兩支完整解壓內容；合回四 repo。
4. 環境救援：①共用 .venv 被 171 E-0b 小弟升 b3，8000 與 174 受影響 → 另開 .venv-fr174 給 174 與 8000；②171 合回後 .venv 升正式版、8000 改回 .venv；③174 Z-1 又在卡工作區 poetry update 把共用 .venv 的 detection 升到 1.8.0，174 合回後才對齊；④本機 Agent 舊程式碼不會簽 DPoP 每跳 401，主線合到 171 後重起恢復，Agent 執行環境手動裝 protocol 0.2.0。
5. 171 收尾：CM-3400 合回被拒（工作區留 FR-132 站產物未 commit）→ 輔助首腦補 commit f2a4e37bb；「合回主線」要求全卡 Done，前次「現在就能合、不用等」建議錯誤，已更正並建議收尾卡另開母卡；171 首腦開 CM-3436 底下 Z-3～Z-6，工作坊 31 結案。工作坊 34 合回時 poetry.lock content-hash 衝突，提供 prompt 由 171 首腦收（b893f9a9c）。
6. 硬碟救援：硬碟 100%（剩 3.4 GB）。①本機 Agent 弱點庫下載殘骸 4.5 GB（輔助首腦早上 kill Agent 時中斷解壓）刪；②~/.claude*/jobs/*/tmp（小弟草稿紙，其中 15 個放整份 repo 副本）10/30 前已結束的 798 組刪，29 GB；③pypoetry 確定無主的 8 個環境刪；④Docker 12:28 硬碟滿時虛擬磁碟寫入中斷、引擎掛死，舊後端程式卡 2 天不退出擋住重開，決策者 kill 後恢復；清孤兒 Postgres 匿名卷 8 個（出包排練臨時庫）、build 快取、無用 image、14 個舊容器，約 26 GB。本機 DEV PostgreSQL 是 Homebrew 的，不在 Docker，未受影響。結果可用空間 3.4 → 37 GB（Docker 內部另回收 26 GB 待 Docker 自己還給 Mac）。
7. 設計版本模式：決策者要「不同版本放左邊、不同連結」留稽核紀錄 → 171、174 各開 design-v1.1.md，v1.0 原樣保留並加指向新版的一行；寫進 doc-site-build（規範全文）與 big-feature-workflow（Step 3 一行指路）兩個 skill。
8. 172 放行前準備：七張暫緩（不只四張）；BE 合主線 6 檔衝突，決策者裁交 172 首腦，給了含解法的 prompt。

決策

• 172 品質檢查：通過，不退回。
• 174 補卡 B 案；174 套件基底改從 feature/FR-172 長（因 171 批 1 套件已先合回）。
• .venv-fr174 作為 174 與 8000 的隔離環境（事後 174 合回、8000 改回 .venv）。
• 172 合主線衝突交 172 首腦；出貨基線等三案全部做完；SPEC 暫不寫。
• 設計異動開新版檔、舊版不動（新規範）。

推翻了什麼

• 本棒早上判斷「174 不用等 171」→ 只查了程式碼依賴、沒查執行期依賴（174 要一台活的 Agent，171 正在改通訊規則），錯；改成「等 171 批 3 合回」。
• 「171 現在就能合回、兩張小卡不用等」→ 工作坊合回要全部子卡 Done，錯；改建議收尾卡另開母卡。
• 「Docker 裡 0 個容器、可以直接清」→ 是引擎沒起來不是真的空；停手等決策者重開 Docker 再清。

教訓

• 跨案依賴要同時看三層：程式碼、套件環境、執行中的服務。只看第一層會誤判「可以平行」。
• 共用 .venv 是工作坊最大的環境地雷：卡工作區 symlink 到主資料夾那份，任何 poetry update 都改到所有人與 8000。今天踩兩次。
• 工作坊的合回與結案都要「全部子卡 Done」；收尾類的新卡另開母卡，才不會拖住主案合回。
• 硬碟滿的連鎖反應：Docker 虛擬磁碟寫入中斷 → 引擎掛死 → 舊後端不退出擋新後端。症狀是「Docker 看起來 0 容器」，清理前一定要先確認引擎真的起來了。
• 小弟把整份 repo 複製進 session 暫存做比對、做完不刪，是 jobs 資料夾爆量主因；應改用 git worktree add／remove（建議寫進 runner 紀律，未做）。
• 清 Docker 資料卷不可用 prune 一網打盡：Docker 的「可回收」只代表沒容器掛著，E2E 黃金庫、別專案的 mongo 卷都會被算進去；要逐個指名刪。

commits（BE feature/FR-172，皆未推）：70df7a26a（174 設計開卡）、d16948662（jedi ws-CM-3379 先合回）、5ceb1a725（Agent API 規格）、b6b219aa5（174 補卡）、f5b043ce0（174 STATE）、本棒交接 commit。BE 卡工作區 f2a4e37bb（FR-132 站產物）、jedi 4fa2db4a（174 版號衝突）。

交給下一棒：§3——172 首腦解衝突後放行；174、171 收尾結案；出貨基線與 SPEC 等三案做完。

• .venv-fr174 刪除（決策者裁）：確認無程式使用、無工作區 symlink、174 工作區已收，回收 1.1 GB；8000 不受影響。
• closing-and-handoff skill 加「runner 環境紀律」兩條：①做改前改後比對用 git worktree add/remove，禁整份複製 repo 進 session 暫存區；②不在卡工作區跑會改共用 .venv 的指令，要換套件版本先回寫等首腦。上一個 block「教訓」裡「建議寫進 runner 紀律（未做）」即此，已完成。
• .claude/rules/workshop.md 由 agent-workshop 範本產生、標明勿手改，未動；若要讓所有專案的 runner 都吃到這兩條，要改 agent-workshop 的範本。

• 決策者完成：工作坊 33（174）、34（171 收尾）結案；172 七張改回 Not started。
• 172 首腦解 BE 6 處衝突（367c0bde7），輔助首腦抽驗：兩個 mount 都在、未加回心跳函式、事件碼無撞號。
• 交接給下一棒輔助首腦：172 待按「繼續派工」開跑；畫面總驗等 172 做完一起。

• CM-3439 P-1 驗收通過：契約 6 種 kind、三組 payload 白名單、Nexus 兩庫都有 0.3.0；套件鏡像測試 1 紅（P-1 前就紅）。首腦把 BE 主資料夾 .venv 的 protocol 換成 0.3.0（--no-deps，8000 未重啟），BE 事件相關測試 136 綠。
• 工作坊派 E-4 前自動合 feature/FR-172 進 ws-CM-3401，撞 STATE／LOG：172 首腦（f09c3a13e）與輔助首腦（90e8e4e71）同一分鐘各改了一份。解法：STATE 取主線版、補進 172 首腦的批 9／.venv／§4 待辦；LOG 兩個 block 都留。

教訓：同一份 STATE 兩個首腦同時寫一定撞；FR-172 的 STATE 以後只由 172 首腦寫進 ws-CM-3401，輔助首腦要記的事寫進 feature/FR-172 前先看 ws 有沒有新 commit。

時序

1. 接手盤點：工作坊 32 已核准到批 11，_next 會把批數 ≤ 已核准的卡全部同時派（每工作坊上限 4）；按繼續後 P-1、E-3、E-4、E-5、G-1 一起派出，E-5／G-1 前置沒到又停（第二次）。
2. 決策者令「看後面的卡會不會有問題」→ 實查 G-1 回寫的四個缺口：cloud_http、update_sync.trigger 已隨 171 進來；稽核事件碼契約沒有；release-keys/ 只在安裝包、映像建完刪掉 /tmp/bundle 且 compose 沒掛，容器內讀不到；驗章 helper 只認編譯進去的 LC 公鑰。
3. 決策者「照你建議」：E-5／G-1 → 批 12、G-2 → 13、G-3 → 14、S-4 → 15；補開 CM-3441（原定 P-2，與 172 首腦同時開的 CM-3440 撞號，改名 P-3）批 11；裁示 append 五張卡；3413／3414 改回 Not started。

決策

• G-1 公鑰落點 /opt/guidant-agent/current/release-keys/（跟版本走），do_image_prepare 落位＋Dockerfile 斷言；映像內實驗證放 S-4 開包。
• 驗章擴充 common/integrity/verify.py 加公鑰來源參數，三道檢查照主系統 _verified_payload。
• 主控台更新稽核碼 6252／6253（兩邊皆未占用），進 REPORTED_EVENT_CODES、不進 LEGACY_ACTIONS；BE 事件碼表與改釘由 G-2 做，.venv 首腦代換。
• E-5 讀 E-4 實際形狀：update_event、log_file_uid（不是卡上的 log_file_id）、下載走既有 /file/download，不加 api.js 常數。

推翻了什麼

• 上一棒 STATE「主線之後只多 3 個文件 commit，再合不會衝突」——172 首腦同時改 STATE／LOG，已撞（172 首腦 3bb5b11e1 解）。

教訓

• auto 模式補卡或解暫緩時，要對照 approved_stage：已核准範圍內有依賴鏈的卡會同時派出，只能把卡往已核准批數之後挪。
• 開卡前先 fetch 母卡底下最新的子卡清單：同一天兩個首腦都在開卡，代號會撞（P-2）。

commits：本棒一個 commit（cards.py／gen_notion_cards.py／STATE 批次表／本 block）於 ws-CM-3401。Notion：CM-3441 新建；3413／3414／3415／3416／3420 改 Stage。

時序

1. 開工查到兩個擋出包的前置：正式章沒產（~/.guidant-release/ 不存在）、出貨基線沒重產。停下回報。
2. 決策者在自己 Mac 跑 update-center 的 npm run cli -- init-keys：主力 7997f5e514258936、備用 bf821e5980c439e6。
3. 三 repo 進版並 commit：BE c48ba6c1f（1.28.0、三把公鑰＋PROD_KIDS、product: host、鎖檔、手冊三句、FR-167 CM-3378 標取代）、Agent 2aacdcc（1.5.0、版本說明定稿）、FE be93c861（1.28.0）。
4. 本機驗：臨時 PG16 從 1.27.10 那版 init＋migration 裝出舊庫、升到 1.28.0 0 錯；用現在的 scripts/init 新裝，migrate 停在 packages/jedi_detection/004-detection-profiles-seed.sql（dev-sec 兩列 file_id 為 null 撞 chk_dpv_source_exclusive）；本機 wrangler dev register-draft 帶 product: host 回 201、不帶回 400。
5. 決策者轉請主首腦重產出貨基線；S-4 等基線好了再到 188 出兩包。

決策

• PROD_KIDS＝主力、備用、Vault 三把；測試章 b91819f86eb4b4f8 的 .pub 留在 release-keys/ 但不列——建議 1.28.0 用測試章簽（188／189／190 只認測試章），包內帶正式章當換鑰過渡，1.29 起改正式章或 Vault（待決策者裁）。
• 鎖檔 jedi-remote-agent 以 P-5 實釘 1.13.1 為準（卡上寫 1.13.0）。

教訓

• 「新裝」與「升級」要分開驗：這次升級全綠、新裝卻壞，差別全在基線。只驗升級會以為能出包。
• 工作坊 session 帶 VIRTUAL_ENV（agent-workshop 的 venv），跑 BE 的 poetry 要 env -u VIRTUAL_ENV。

等誰：主首腦重產基線（主線 7 支＋dev-sec 兩列 upload_files＋套件 detection 014、remote-agent 017／018）；決策者裁 1.28.0 用哪把章簽。基線好了之後本卡接著做：新裝重驗、H-4 兩態點畫面、188 出兩包＋開包驗。

時序

1. 調批避免 auto 同批派出未備前置的卡（E-5／G-1 → 12，後順延）；補開 CM-3441 P-3；裁 G-1 公鑰落點、驗章擴充、E-5 照 E-4 實際形狀。
2. 決策者驗 171／174：重起 8000／worker／本機 Agent，123 Agent 從 feature/FR-139 換到 feature/FR-172（推 Agent 遠端分支）。
3. 驗出問題，決策者令「開卡直接修」，掛 172 母卡、Stage 留空不給工作坊派，已全部 Done：B-2 CM-3443 心跳補推重啟不清旗標（BE 2d2aadfb1）、B-3 CM-3444 測試連線更新連線欄（BE 04b2ab975）、B-4 CM-3445 單台進度條＋掃描頁預覽（FE 9f90a82e）、B-6／B-7 CM-3449／3450 授權範圍 version=None 顯示未收到＋立即同步（Agent 3ce8931、FE 74f7f7c8）、B-8 CM-3451 SonarQube 上傳原始碼模式（FE 7737581f）、B-9／B-10 CM-3455／3456 上次同步時間＋「檔案」（Agent 1ab5e80、FE 383c40df）、B-11 CM-3457 執行中「返回」（FE 12f368e7、415bf0af）、B-12 CM-3458 授權範圍查看清單（FE edbd76ef）、B-13 CM-3459 選檔自動上傳不重傳（FE a7e98096）、B-14 CM-3460 信任錨用途中文（FE 2a269adc）、B-15 CM-3461 ZAP 每次新 session＋同 Agent 一次一張（Agent 62e4769）。另開工作坊卡 P-4／E-6／B-5（CM-3446～3448）同步失敗寫稽核。
4. 環境：DEV SeaweedFS 補回 TWGCB 8 支（決策者桌面原檔，sha256 與 DB 一致；twgcb-01-014.tar.gz 無原檔仍缺）；123 裝 syft／trivy／grype／osv（照 tools-manifest、sha256 核過，~/guidant-agent-dev/scan-tools/bin＋AGENT_SCAN_TOOLS_DIR）；Mac／123 開發腳本加結束碼 75 自動重起。
5. 123 實掃：InSpec、GCB、Nmap、OpenSCAP（.151）、OpenVAS、SonarQube 上傳 皆成功；OpenSCAP 掃 123 自己失敗（Ubuntu 26.04 無 SSG）；ZAP 失敗為 123 自架 ZAP heap 爆（session 累積 2.6 GB），B-15 修 connector，123 未重驗（決策者裁不影響出版）；SBOM 未實跑。
6. 合回：B-2～B-15 都在三 repo feature/FR-172；Agent ws-CM-3401 手動補合 ZAP（c6b88e0），三 repo ws 皆含 feature 全部。

決策：13 張直接修的卡由決策者裁 Done；1.28.0 Mac 手簽先出、FR-173 跟 1.29、包內先放 Vault 公鑰（S-4 已做）；123 換主控台靜態檔不必先問，重起 Agent 仍先查有無掃描在跑。

推翻了什麼：上一棒「主線之後只多 3 個文件 commit 再合不衝突」——172 首腦同時寫 STATE／LOG 已撞；「下一張 Agent 卡會自動帶 ZAP」——E-6 已先跑完，改手動補合。

教訓

• auto 模式補卡或解暫緩要對 approved_stage：已核准範圍內有依賴鏈的卡會同時派出空轉。
• 開卡前 fetch 母卡最新子卡，兩個首腦同日開卡會撞代號（P-2）。
• 171 結案時整條流程沒人實走過，畫面一驗冒出十幾項；大案結案前要有一棒在像客戶的環境（123）逐工具逐模式跑一次。
• 換 Agent 主控台靜態檔後，開著的分頁點選單會 404（chunk 換名），重新整理即可；產品升級也會遇到，未開卡（決策者裁不用）。
• 重起 Agent 前先查有無掃描在跑（曾中斷一張 OpenVAS）。

交給下一棒：發版。見本 block 之後的交接提示詞（對話內給決策者）；STATE 由 172 首腦／S-4 小弟寫在 ws（adf2813ec「S-4 結案進度」節）。

時序

1. 基線重產（決策者裁由首腦做）：188 基線庫實查只少 5 支主線（S-4 回寫說 7 支多算了），依 manifest 行序套、補 dev-sec 兩列 upload_files，02／04／99 重產（142e327a4）；gen_seed_sql.sh 系統檔數量檢查 10→12（不改新裝在 04 直接 RAISE）。臨時 PG16 新裝實跑 0 錯。
2. 測試章公鑰移出 release-keys/（285c2eb5b）：PROD_KIDS 只是守門清單，出包帶走資料夾內所有 .pub。fr132 對照表補 P-5 能力點（51e6e43f4）。
3. 本機 8003＋假更新站實打 H-4 兩態（可下載／已下載）；更新紀錄 Agent 列來源欄 DEV 無資料沒點到。
4. 五個 repo 工作坊分支合回 feature/FR-172（BE 只撞 LOG，兩邊都留）並推；188 三資料夾切 feature/FR-172。
5. 出包撞三個坑都修了：Agent RELEASE_NOTES.md 被 S-4 取代字串吃掉 ## 1.5.0 標題、說明 0 條（6760914，壞包改名 .BAD-notes0）；開機補登金鑰登記簿不在 app context、新裝第一次開機留 Traceback，smoke 擋（088ca2b75，臨時庫重現與驗修）；幽靈選單比對表缺 agent-keys（96d4e23e7）。另外首腦自寫的出包腳本取 Bugsink 密碼寫錯一次。
6. 更新站部署：D1 備份後套 0005、wrangler deploy。npm run deploy 的 predeploy 會掃到 .worktrees/ 與 node_modules 的測試而紅，改成排除後跑主樹測試（121＋67 綠）再直接 wrangler deploy。
7. 190：guidantai upgrade 離線升 1.28.0（八步 0）；Agent 1.4.7 對 1.28.0 心跳 401→重註冊循環，guidant-agent-compose upgrade 手動升 1.5.0 後不需重註冊即恢復。重啟 api 讓開機檢查跑：看到 1.28.1 與 Agent 1.5.1、驗章過。
8. 出 1.28.1（沿用映像只換版號）、Agent 1.5.1、1.5.2；1.28.1 與 1.5.1 測試章簽發布，1.5.2 草稿；1.5.2 離線檔放 Mac。

決策：1.28.0 測試章簽、包內只帶三把正式章；173 共用 feature/FR-172 先開卡不派；更新站照設計部署（188／189 升 1.28.0 前檢查新版會失敗）；S-4 首腦接手不派回；1.5.2 等決策者主系統端測完再發。

推翻了什麼：首腦曾說「1.4.7 Agent 收得到 1.28.0 推送」——錯，1.28.0 只走 /update 直推、1.4.x 沒有這端點，每台 Agent 要手動升一次。S-4 回寫「主線待補 7 支、套件 014／017／018 要進基線」——實查 5 支，套件 migration 不進基線。

教訓

• 驗章規則「只認本機公鑰」讓換鑰與首次上版都要算到每台機器現在裝了什麼；新版更新站「product 必填」也讓舊主系統查不到新版——部署前先列「現有機器各會怎樣」。
• smoke「啟動 log 無 Traceback」抓到 DEV 永遠撞不到的路徑（只有空表第一次開機才走）；新裝要用真的空庫開一次機。
• 出包腳本裡取祕密的寫法，第一次跑前先單獨 --check 一次。

時序

1. 決策者在 190 測 1.28.1／Agent 1.5.1／1.5.2（三條線上升級都成功），陸續提 24 條回饋；首腦逐條開檔核對位置、現況、建議用字，寫進 190-test-feedback.md。
2. 查到三個不是文案的問題：Agent 主控台「立即檢查」不會真的查更新站（只讀主系統上次結果）；Agent 升級沒有維護狀態、升完 session 在記憶體必被登出；SeaweedFS 健康檢查每 10 秒留一個 ssl_client 殭屍（PID 1 是 weed 不收），1.5.0 加 pids_limit 後 3 小時撞頂——就是 compose 註解「根因未查」那個洩漏。190 當天重啟兩次（10:10、12:44）。
3. 開 FR-172.1：母卡 CM-3469、7 張 2 批。第一版把 CM-3469 掛在 CM-3401 底下，工作坊只派「母卡欄為空」的卡，選不到；改成獨立母卡。
4. 工作坊 35 全程 auto：批 1（F-1～F-4）、批 2（F-5～F-7）七張一輪全過，各自合回 feature/FR-172。
5. 進版 1.28.2（1.28.1 沒進 pyproject）／FE 1.28.2／Agent 1.5.3；188 完整出包、開包驗過；1.28.2 發布、1.5.3 草稿。
6. 188 磁碟 95%：清打包骨架 bundle/stage/（每版 2.1 GB 從沒清）、兩邊 dist、主系統解開目錄、/home 舊檔、三版舊映像，回到 73%；各版 .tar.gz 成品都留。

決策（決策者）：#14 主系統成功也能下載升級 log（與 Agent 統一）；#20 只指 Agent 區；Agent 區推翻 D9 改一步完成；1.5.3 先草稿；舊包照首腦建議清。

推翻了什麼：首腦先說 Agent 主機 agent-staging 4 GB 是殘留——實際是升級進行中，升完自清；#23 Agent 側沒問題。首腦先說主系統更新包升級成功後沒人用——retry（退回／跳過後重試）會用同一包，所以只在成功時刪、退回照留。

教訓

• 升級流程的「過程資料」（包、步驟清單、殭屍行程）在測試機跑一兩輪才看得出堆積；每版出包後要看一眼 188／190 的磁碟與容器健康，不能只看 build 綠。
• 工作坊母卡不能掛在別的母卡底下，修正案要開獨立母卡、關係寫內文。
• 殭屍行程不占資源、監控看不到；容器 PID 1 不是 init 類程式時一律 init: true，不要靠 pids_limit 救。

時序

1. 1.28.2（發布）／Agent 1.5.3（草稿）出包上站；188 清磁碟 84 GB。
2. 決策者：190 升到最新後每次看新版升級畫面都得再出一版 → 要「測試機同版可更新」。首腦查四層擋同版（更新站只回新版、主系統驗章 <=0 拒、主機預檢同版擋但有 --force、Agent trigger 同版當重複），開 FR-172.1 批 3 三張（CM-3477～3479）。決策者改令「不外派，首腦直接改、改完出版交接」。
3. T-1 BE（1f48bebc7、c72c208e5）、T-2 Agent（3a96ab5）、T-3 FE（d084f74e）寫完、測試＋突變驗過、推上 feature/FR-172。沒出版（context 用盡，交下一棒）。

決策：兩端各自 env 開關、預設關、不進出貨範本；主機另讀同一 guidant.env 的鍵，單上 force 單獨無效；更新站不動，重套用本機留的 release.json＋以現行版重拿下載網址；Agent 不加降版閘（原本就沒有，主系統只推新版／同版）；Agent 區重套不走勾選；契約不改。

推翻了什麼：卡上寫 Agent「比現行舊仍拒」——Agent trigger 本來就不判降版，那是主系統的事。

教訓

• 同版單會撞上「現行版＝目標版就當成功」的捷徑：Agent _order_outcome 要排除同版單，否則一寫單就回報成功、主機根本沒跑。只在開關開時排除，關時行為不能變（既有 /tasks 測試靠它）。

• macOS bash 3.2 set -u 下空陣列展開會炸，bats 在 Mac 跑會抓到；shell 加參數用 launch+=() 不要另開空陣列。

• Agent 測試要用 protocol 0.3.2 的 venv（evidence-agent-z8S7lqoJ-py3.13），記憶裡的 knWYPLiu 是舊的。

• 2026-11-03 14:24：依決策者令把更新站 Agent 1.5.3 由草稿改發布（D1 UPDATE product_releases SET status='published'）。190 Agent 升 1.5.3 後 SeaweedFS 殭屍行程根治，不必再定期重啟。

時序

1. 補 Agent 主控台「重新套用」按鈕（FE 6c06b016），三 repo 進版 1.28.3／1.5.4。
2. 第一次 build 停掉：Agent compose 沒把 AGENT_UPDATE_ALLOW_SAME_VERSION 轉進容器（Agent 9359fe6）。
3. 決策者回報 190 Agent 推不出去：主系統手上留著 1.5.2 包、只看「有沒有包」就拿舊包推，回「沒有落後」；Agent 主控台同根因說「已是最新」。修 BE 2260d22b5（更新中心）、e8bb97f27（主控台先下載再推、then_push 帶 actor）、3eac1d7d4（下載中再按改併入、不覆蓋，自動資安檢查抓到）；FE b4463557 鎖定寬限 10 分。
4. 決策者回報 Command+Shift+R 後主控台沒 CSS：190 重現「一條不握手的連線卡住 8444 整台」，握手移到每連線執行緒（Agent a51f865）。
5. 第三次 build 完整出 1.28.3／1.5.4；190 指令升級 1.28.3（6 分 42 秒）；1.5.4、1.28.3 上站；190 開兩個同版開關。
6. 決策者測 Agent 同版重套失敗：主機 upgrade_order.sh 預檢對同版一律擋（T-2 漏改，卡上有列）。修 Agent f932701，出 1.5.5（首次 --internal-test，15 分 52 秒，比 1.5.4 快 3.6 分）上站。
7. 決策者實測通過：1.5.4→1.5.5 不預先下載直接推、自動下載；同版重套 1.5.5 成功。
8. 出包加速：內部測試包略過 SBOM／弱點掃描（BE 09308ef5d、Agent 70ec3d2）、主系統封包 pigz（BE 09308ef5d）、釘版 image 匯出檔以 image ID 快取（BE 9c1539491、Agent cd3a1f9）。查證 Nuitka 在 188 本來就沒開 LTO，--lto=no 無效。
9. 決策者裁 171～174 是一組、直接往 173 走，172 相關卡全收 Done（CM-3401、CM-3420、CM-3469、CM-3470～3479）。

決策：同版重套開關只在 190；測試包略過 SBOM 綁在 --skip-prod-key-check／--internal-test，正式包不能單獨關掃描；主控台由主系統發動最慢 30 秒才鎖，先這樣；Nuitka 不升版、不加 --lto=no；正式版不在 1.28.x 出，跟 173 用 Vault 簽 1.29。

推翻了什麼：上一棒 F-2「沒包先下載再推」只做了「完全沒包」一種，留著舊包的機器從沒生效（CM-3469 卡上 F-5 驗收時已記，未修就出版）；T-2「主機 runner 不用改 shell」錯，預檢在 runner 之前就擋。

教訓

• 「有沒有」不等於「是不是最新」：凡是拿本機快取當答案的判斷（包、檢查結果），都要跟來源的最新版比。
• 卡上列的「改哪些檔」沒改到，回寫要說明為什麼；這次兩個漏洞都是卡上明列、實作時判斷「不用改」。
• 改完先在測試機驗再出包：今天前兩次 build 白跑約 40 分鐘，都是改完沒先驗就出包、出了才發現。
• 主機腳本住在 Agent 映像裡，測試機只改 .sh 也得出版；這類修正要算進出版時間。
• 突變測試斷言要「確實做了正確的事」（升級指令被呼叫），不要寫「沒有某個錯誤字串」：後者在別的原因失敗時一樣會過。