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

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

## 第 1 棒｜2026-11-01｜首腦：探脈、登記、討論稿 v1、雛形、FR-171 改 v2

**角色**：首腦（分析決策人員）。決策者開場五點需求＋要求「爬之前留的訊息統整」「與 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 棒（續）｜2026-11-01｜首腦：三案拍板、三份 design、FR-173 開案

**時序**
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 棒（交接）｜2026-11-01 晚｜首腦 → 輔助首腦

**時序**
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 棒｜2026-11-01 晚｜工作坊巡查、FR-174 開立、交接

**時序**
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 開始討論，**等決策者發令才開工**。

## 輔助首腦第 2 棒｜2026-11-01 晚｜接手盤點、FR-174 開卡、172 停住的判定、jedi-packages 先合回

**時序**
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 等決策者開工作坊。

## 工作坊 32 首腦｜2026-11-01～11-02｜驗收批 1～5、171 結案後放行

**時序**
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。

## 輔助首腦第 2 棒（續）｜2026-11-02｜171 結案、174 合回、環境救援、硬碟清理、172 放行前準備

**時序**
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 等三案做完。

## 輔助首腦第 2 棒（交接前補記）｜2026-11-02

- `.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 的範本。

## 輔助首腦第 2 棒（交接）｜2026-11-02 16:xx

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

## 工作坊 32 首腦（續）｜2026-11-02 下午｜P-1 驗收、BE .venv 換 0.3.0、ws 合併撞文件衝突

- 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。

## 輔助首腦第 3 棒｜2026-11-02 傍晚｜後續卡檢查、挪批、補開 P-3

**時序**
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。

## S-4 小弟（CM-3420）第 1 輪｜2026-11-02 晚｜進版、正式章進包、本機驗；188 出包卡基線

**時序**
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 出兩包＋開包驗。

## 輔助首腦第 3 棒（交接）｜2026-11-02 晚｜驗 171／174 畫面、直接修 13 張、123 環境、ZAP；交給發版

**時序**
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 結案進度」節）。

## 發版首腦｜2026-11-02 晚～11-03 凌晨｜基線重產、合回、出包、更新站部署、190 升級測試準備

**時序**
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` 一次。

## 發版首腦（續）｜2026-11-03｜190 測試回饋 24 條 → FR-172.1 → 1.28.2／Agent 1.5.3

**時序**
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 救。

## 發版首腦（再續）｜2026-11-03 下午｜1.28.2／1.5.3 出版、批 3 同版重套直接寫完、交接

**時序**
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 殭屍行程根治，不必再定期重啟。

## 發版首腦（結案）｜2026-11-03 14:1x～17:1x｜1.28.3／Agent 1.5.4、1.5.5 出版、190 實測、FR-172 收 Done

**時序**
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` 也得出版；這類修正要算進出版時間。
- 突變測試斷言要「確實做了正確的事」（升級指令被呼叫），不要寫「沒有某個錯誤字串」：後者在別的原因失敗時一樣會過。