# FR-167 LOG（append-only）

## 2026-10-29 開卡（首腦）

- 母卡 CM-3241；子卡 CM-3242～CM-3276（35 張 8 批），工作坊四欄（母卡／Stage／Model／Effort／Repo）已填，開頭引用已回填母卡號。
- 開卡前決策：CRA 兩題先不管；開發期（小弟本機驗）與測試期（首腦操作 190）分開；小弟可 push ws branch、套件發 beta；更新站改 TypeScript；R2 既有 bucket `guidant-ai-release` 分主版號資料夾；新 repo `update-center` 建好並完成工作坊登記；Cloudflare 權杖與 R2 金鑰實打驗過。
- 產卡：`handoff/gen_notion_cards.py` → `notion-cards.json` → `scripts/notion_create_case.py` → `patch_workshop_fields.py`。
- 踩坑：頁面 API 的 relation 欄預設只回 25 筆（`has_more: true`），要用 `/pages/{id}/properties/{prop_id}` 分頁查才看得到 35 張；子卡開頭的母卡號佔位要建完再補。

| 批 | 卡 | Case No | 標題 |
|---|---|---|---|
| 1 | P1-1 | CM-3242 | 升級骨架：guidantai 加 upgrade／recover 子命令、先換成新版的自己 |
| 1 | P1-3a | CM-3244 | jedi-remote-agent 心跳契約一次改完：dispatch_gate port |
| 1 | P1-8 | CM-3246 | 前門維護頁：nginx 後端連不上改送 maintenance.html，頁面每 3 秒讀唯讀掛進來的進度檔畫步驟與時限 |
| 1 | P1-9a | CM-3243 | 出包：產未簽的 release.json |
| 1 | P2-1 | CM-3247 | 更新站 repo 骨架：TypeScript Worker |
| 1 | P2-5 | CM-3248 | 授權檔 payload 加 product_major |
| 1 | P3-1 | CM-3245 | 能力點 system.product-update.read／update、更新中心選單路由、預設角色授權 |
| 2 | E-1 | CM-3249 | 環境卡：主 repo 改釘 jedi-remote-agent beta 版 |
| 2 | P1-2 | CM-3250 | 預檢：空間 |
| 2 | P1-3c | CM-3251 | 停接新工作、等做完：寫 draining 旗標檔、psql 輪詢進行中數、30 分提醒寫進度檔、時段結束放棄並清旗標 |
| 2 | P2-2 | CM-3253 | 更新站後台：Cloudflare Access 守門的管理端點 |
| 2 | P2-3 | CM-3254 | 發布 CLI guidant-release |
| 2 | P3-2a | CM-3252 | 主系統更新模組骨架：product_update_jobs 表、domain／infra／app service、狀態與 |
| 3 | P1-3b | CM-3255 | 主系統接 draining：core/maintenance_gate 讀旗標檔、worker 不撿新單、心跳不派新任務 |
| 3 | P1-4 | CM-3256 | 停服務、複製資料庫到複本、讓升級接複本跑：lib/upgrade_db_copy、compose 資料庫目錄改吃變數、f |
| 3 | P1-5 | CM-3257 | 在複本上升級：載映像驗雜湊、init image migrate 模式對複本、migrate.sh 每支印進度行、run |
| 3 | P2-4 | CM-3258 | CI 出包後登記草稿：先打更新站 register-draft 拿到 R2 目標 key，再上傳包、release.js |
| 3 | P2-6 | CM-3259 | 發布印樣進產品：DEV 公鑰檔放 scripts/installer/release-keys/、install 與 u |
| 3 | P3-2b | CM-3260 | 發現新版與下載：更新站 client、每日排程 |
| 3 | P3-3 | CM-3261 | 更新中心頁：目前版本、最新版本、版本說明、預檢、下載、下載中、已就緒 |
| 4 | P1-6 | CM-3262 | 啟動新版、健康檢查、開放使用：新版接複本起、180 秒＋登入與主要 API 實打、換接 |
| 4 | P3-2c | CM-3263 | 更新單：立即／排程／取消／重試端點寫 upgrade-order.json；systemd path＋service 單 |
| 4 | P3-4 | CM-3264 | 有新版橫幅 |
| 5 | P1-10 | CM-3266 | 收尾與診斷：保留上一版映像、更新包保留到下次成功、清掉更早的；diag 併進度檔與更新單並遮罩；下載診斷包走更新單 |
| 5 | P1-7 | CM-3265 | 自動退回、開機檢查、guidantai recover：丟棄複本、改接原份、啟動保留的舊映像、健康檢查；systemd  |
| 5 | P3-2d | CM-3267 | 跨版兩段：更新站回路徑 |
| 5 | P4-5 | CM-3268 | Agent 升級指令比照主系統：每步時限、進度檔、失敗自動退回 |
| 6 | P1-9b | CM-3269 | CI 跨版排練：e2e 目標先裝舊版＋灌真實舊庫，再用新包 guidantai upgrade；失敗擋 package |
| 6 | P4-2 | CM-3270 | Agent 跟進 |
| 7 | P4-3 | CM-3271 | Agent 跟進 |
| 7 | P4-4 | CM-3272 | 更新中心 Agent 跟進區：批次表、暫停／繼續、推選定、只升 Agent 說明 |
| 8 | P5-1 | CM-3273 | 手冊與安裝文件：升級一章改寫 |
| 8 | P5-2 | CM-3274 | SPEC：更新中心頁新頁 |
| 8 | P5-3 | CM-3275 | e2e：更新中心頁 |
| 8 | P5-5 | CM-3276 | 結案卡：jedi-remote-agent 發正式版 |

---

## 第 2 棒｜2026-10-30｜首腦：工作坊 25 跑完後的盤點與交接

**角色**：首腦（開卡那位接續）。工作坊 25 的驗收由工作坊自己開的「CM-3241-首腦-2」做，本棒只盤點與交接，沒有重驗。

**結果**
- 34 張卡 `驗收通過待確認`；CM-3276 結案卡 `In progress`，小弟停在四題等決策者（版號 1.10.0 非 1.9.0、套件清單確認、PROD 印樣怎麼分辨、更新站網域）。
- CM-3273 手冊卡合回 `ws-CM-3241` 失敗兩次：卡工作區有 34 支 security-report 產物未 commit（小弟重跑 render_index 連帶改到），不是本卡內容。
- 各 repo `ws-CM-3241` 領先 feature 分支：BE 54、FE 10、update-center 6、agent 4、jedi 3、LC 2、test 2；全部未 push。jedi-remote-agent `1.10.0b1` 已在 Nexus。
- 新開 `fr167-STATE.md`；README 狀態改「開發期完成，待決策者裁結案事項」。

**決策（本棒無新裁示；待裁清單收進 STATE §4-1，共 11 項）**

**推翻了什麼**
- 第 1 棒文件寫 jedi-remote-agent beta 為 `1.9.0b1`：1.9.0 已被 FR-166.1 占用，實際發 `1.10.0b1`，正式版應為 `1.10.0`。design／README／cards.py 已改。
- P2-4 卡上 R2 路徑 `releases/<版>/` 是筆誤，正確是 `v<主版號>/<版>/`（design §5.4 原本就對）；cards.py e2e 欄已改。
- design §5.1「`mv pgdata pgdata-prev-<舊版>`」做不到：第一次升級前資料庫在 named volume。落地契約見 STATE §3，design 原文不回改（設計稿凍結），測試期照 STATE。

**教訓**
- 連撈 35 張 Notion 卡會 429，中間七張撈成錯誤頁卻沒報錯，差點把「沒撈到」當「沒復核」寫進交接。撈卡要隔幾秒、撈完 grep 429。
- 兩張相鄰的卡各測自己那一半（P3-3 只用假 route、P3-2b 只測 BE），端到端缺口（離線上傳 400）到 e2e 卡才現形。整合點的卡驗收要拿對方真實端點打一次。
- 小弟在 docs 類卡裡重跑整站 build 會把不相干產物弄髒工作區、擋住合回；docs 卡要寫明「只 build 自己那個資料夾、只 add 自己的檔」。

**環境實況（當時）**
- BE 主資料夾 `pyproject.toml` 釘 `jedi-remote-agent==1.9.0`、共用 `.venv` 1.9.0；`ws-CM-3241` 釘 `1.10.0b1`。190 跑 1.26.0。工作坊 daemon 7777／8011；決策者 DEV BE 8000。

---

## 第 3 棒｜2026-10-30｜首腦：11 項待裁拍板、CM-3273 合回、結案卡重派

**角色**：首腦（冷接，讀 STATE／LOG／母卡交接段後 pre-flight，與 STATE 全部相符）。

**結果**
- 決策者對 §4-1 全部 11 項「都照建議」：正式版 `1.10.0`；套件清單可發；PROD 印樣 `PROD-<kid>.pub` 檔名；網域測試期 `*.workers.dev`、`UPDATE_SITE_URL` 出包預設原廠網域；`.venv` 現在換；基線合回後一次重產；版本說明三段放更新站後台（另開卡）；備用章命令第一版不做；送更新站改只送編號加簽章片段（另開卡）；DEV 殘留清掉；34 張 Done。裁示整段回寫 CM-3276，並併入「正式包缺 Agent 交付包就紅」。
- 決策者 10:17 在狀態頁按完 34 張 Done。
- CM-3273 合回：在卡工作區 `git stash push -u -- docs/security-report/` 把 34 支產物移走（留 BE repo `stash@{0}`），`POST /api/workshops/25/resume` 後 10:20 merged；工作坊隨即把 CM-3276 舊卡工作區重建、重派小弟（ccy3，sonnet／low）。
- 共用 `.venv` 的 jedi-remote-agent 1.9.0 → `1.10.0b1`（pip 直裝、Nexus 認證取自 keychain `poetry-repository-nexus`；poetry 的 auth.toml 只有帳號沒有密碼）。主資料夾 pyproject／lock 不改，隨合回帶入。
- DEV 清掉 `background_jobs` 937（`fr167_drain_probe`）與 `product_update_jobs` 4～9（都是 1.27.0 的驗收假單）。表在 `public` schema，不是 `compliance`。
- 35 張卡的「首腦復核」段全部撈過一遍（隔 4 秒撈、grep 429 無命中），把「留給後面」的事收進 STATE §4-3／§4-4。

**決策**：見上，全部是決策者裁示，本棒沒有自行加判。

**推翻了什麼**：無。

**教訓**
- pip 直連 Nexus 要帳密，`--no-input` 沒給會 EOFError 停在互動問帳號；poetry 的 `auth.toml` 只存 username，密碼在 macOS keychain（service `poetry-repository-nexus`），要 `security find-generic-password -w` 取。輸出要 sed 遮掉再印。
- 工作坊的 `/api/workshops/<id>/resume` 一次解兩件事：合回被拒的卡重新檢查再合，anomaly 的卡沿用（或重建）卡工作區重派。不用分別按。
- Notion 母卡的 relation 欄最多回 25 筆，母卡屬性摘要列的子卡數不是全部，看卡數要靠 STATE §2 或工作坊狀態頁。

**環境實況（當時）**
- `.venv` 1.10.0b1；決策者 8000 的 DEV BE 是 1.9.0 時代起的，重啟後才吃新版。BE `ws-CM-3241` 領先 feature 57 commits；其餘六 repo 不變（FE 10、update-center 6、agent 4、jedi 3、LC 2、test 2）。全部未 push。工作坊 28（FR-170）同時卡在 CM-3236 合回 `jedi-password/poetry.lock`，與本案無關。

### 第 3 棒續記（11:40）：批 9、10 收完；決策者裁 A 案、工作坊首腦擴卡
- CM-3276 第 2 輪過、合回；批 9（3293／3295／3299）、批 10（3294／3296／3297）全過全合回。
- CM-3293 小弟做完卻把「本機驗不到」當卡住留 In progress，工作坊 anomaly 暫停一次；首腦判打折送驗後過。小弟自述誤用 `git checkout` 還原自己檔案，已請工作坊首腦核 reflog。
- **推翻了什麼**：我開的 P6-5「簽章片段」在簽章上做不到（驗片段需客戶端私鑰，主系統沒有）。CM-3297 小弟給 A／B／C，決策者在工作坊裁 A：授權中心另簽不含客戶名稱的 `update_ticket`。工作坊首腦據此開 CM-3300～3302、改寫 CM-3298 到批 13。這是決策者直接在 runner 視窗裁示，首腦事後驗收不回頭質疑授權（LOG 記一行）。
- **教訓**：① 開「改身分格式」這類卡前，要先問「驗證端拿什麼驗」——片段驗章需要私鑰，我沒想到這層就開卡；② Monitor 管線尾端接 `cut` 會吃緩衝，兩次 30 分鐘零事件都是這原因，log 其實一直在動；③ 工作坊首腦會在首腦不在時直接開卡，`cards.py` 底表會落後 Notion，收尾要補回。

### 第 3 棒續記（12:00）：開發期全部收完
- 批 11（3300／3301）、批 12（3302：jedi-license-runtime `1.1.7b1`＋套件 migration 005）、批 13（3298：BE 有票送票、無票退回送原文並 warning；釘 1.1.7b1、lock 只動該套件；手冊三處改回）全過全合回。首腦抽核 3302 Nexus 有包、3298 lock／manifest／DEV 欄位三件屬實。
- 工作坊 25 `waiting_approval`，十張等 Done。CM-3298 卡工作區 remove 失敗留殘骨（41,934 追蹤檔已刪、剩 dotfile），不自己清。
- 七 repo `ws-CM-3241` 領先：BE 67／FE 14／update-center 11／agent 4／jedi 7／LC 4／test 5，全未 push。
- **教訓**：套件 migration 是 build 期從 site-packages 攤平、不入版控——核「manifest 沒變」不是漏，是對的；要核的是 DEV 欄位在不在。

### 第 3 棒續記（12:20）：七 repo 合回 feature 分支
- 決策者按完十張 Done 後下令合回。工作坊 `/merge` API 要主資料夾乾淨且會在衝突停住，改手動 `merge --no-ff`。BE 四處、FE 一處衝突，皆為 ws 從 10/29 開出後 feature 又收了 FR-166.1／FR-169，雙方在同一登記型檔各加一段。
- **推翻了什麼**：FR-167 事件碼 `AGENT_UPDATE_BUNDLE_FETCH`／`AGENT_UPDATE_ROLLOUT_CHANGED` 原占 6229／6230，FR-166.1 已先占到 6236，合回時重編 6237／6238（程式只以符號名引用、無字面值，FE 無對應 i18n）。
- lock 以 feature 為底只重解兩支；`.venv` 順帶補齊 FR-169 五支（lock 早有、venv 落後）。
- **教訓**：① 平行 arc 各自在 `event_code.py` 挑號，合回才撞——下次開卡時事件碼先在母卡佔號段；② zsh 把 `$T:path` 的 `:c` 當修飾子吃掉，用 `git cat-file -p "${T}:path"` 繞；③ 工作坊 merge API 的「主資料夾乾淨」前提在 LC／test 有不相干髒檔時過不了，手動 merge 不受影響。

### 第 3 棒收（14:35）：DEV 看畫面、雛形 v2 套上、開批 14～17、交接
**結果**
- 七 repo push（決策者授權當次）。DEV 起測試環境：BE／worker 指本機假更新站（test repo `update-site-stub.js`）、LC DEV 5062；DEV 授權換成本機 LC 簽、綁本機 Mac 指紋的落地版照（id 5087，帶身分票），決策者裁維持不還原。
- 決策者逐點改更新中心：iOS 式一張卡 → 另一 session 出雛形 v2（`d2c7c81a6`）決策者「OK 就這樣」→ 首腦照 v2 套 FE。之後決策者連續微調：儀表板橫幅字級／位置／間距、展開區不要灰卡、停機不寫分鐘、按鈕說明改 hover、版本說明加框、失敗改主卡內警示區、Agent 全部最新只留清單、跟主系統一起更新時可選台。FE 13 個 commit 見 STATE §2。
- `version-bump` skill 加「更新中心顯示文字」段（`83115a96f`）。
- 開批 14～17 八張卡 CM-3306～3313（`a47658200`），決策者 14:10 按開始；工作坊 25 開了新首腦「CM-3241-首腦-3」，CM-3309 已合回、CM-3308 第 1 輪不通過修正中、CM-3307 送驗中。

**推翻了什麼**
- 首腦先把雛形 v2 讀成「推翻 D16、Agent 一律分開」並照此開了 CM-3306／3313；決策者更正為「**可選**跟主系統一起或分開，一起時可選台」。兩張卡改標題、改卡尾模型理由段、append 三段首腦更正；cards.py 同步。
- CM-3306 卡上寫「apply schema unknown=EXCLUDE、FE 先送新欄位會被略過」是錯的：apply schema 拒收未知欄位，決策者 DEV 實測 400。FE 加 `SEND_AGENT_FOLLOW=false` 先不送，卡上更正。
- 第 2 棒 STATE 說「影響範圍顯示預設文字是資料源沒欄位」：真因是 e2e 假站只回 `notes`，假站已補（test `18fa48a`）。

**教訓**
- 查 schema 寬鬆度要看**那支端點用的 schema**，同檔別的 schema 是 EXCLUDE 不代表全部都是；最穩是實打一次。
- 起測試環境時 API 與 worker 是兩支程序，環境變數要兩邊一起帶；worker 漏帶 `GUIDANT_RELEASE_KEYS_DIR` 讓下載驗章失敗，頁面跳出「上次更新沒有開始」，決策者看不懂以為是 UI 問題。
- 決策者說「Agent 跟主系統分開」時要追問是「一律分開」還是「也可以分開」；雛形畫的是兩條路徑之一，不代表另一條要拿掉。
- 拆成多張卡的說明區塊只露出最後一張時會失去脈絡；狀態類訊息放在它所屬的那張卡裡，不要獨立浮在頁首。
- Monitor 管線尾端別接會緩衝的指令（`cut`），否則 30 分鐘收不到事件。

## 第 4 棒｜2026-10-30｜首腦：批 14～17 收完、合回 feature、DEV 重啟到新程式

**角色**：首腦（決策者開的 session，冷接）。pre-flight 與 STATE 相符，差異只有批 14 進度比 STATE 寫的更前面。

**結果**
- 批 14～17 十張功能卡全過驗、全合進 ws；工作坊首腦-3 另補開 CM-3316（更新站 `min_agent_version` 斷在 register-draft／publish 這段）、CM-3317（Agent compose 包旁產 `.notes.json`，即第 3 棒在 CM-3310 卡上預告要補開的那半）。決策者 16:10 按完 Done。
- CM-3312（test e2e 綁 v2）兩次 anomaly 暫停工作坊：小弟程式寫完 commit，但卡上要求「本機 8003＋FE dev＋假站實跑全綠」做不到（本機沒服務、`.env.e2e` 指 190 禁碰）；重派後又停下等人回答。決策者裁暫緩，留 190 測試期實跑。
- 四 repo `merge --no-ff ws-CM-3241`（BE／FE／update-center／agent）零衝突（merge-tree 先試）。BE 登記型檔只有 `product_update_error_code.py` 加三碼、`manifest.tsv` 加一行。
- `fr167-dev/` 從第 3 棒 scratchpad 複製到 `~/Projects/Billows/Audit-Manager/.fr167-dev/`；kill 核過的兩個 PID 後以三個更新站變數重啟 BE 8000 與 worker，status 端點 401（守門在）、假站 health 的 kid 與公鑰一致。
- FR-170 首腦通知 Agent repo 結構已換（`core/` 凍結、背景工作一律 WorkerComponent、六支守衛、venv 換 knWYPLiu）。盤過：FR-167 碰 agent 的卡只有 P4-5／P4-3／P7-4／P7-10，全做完，都不碰 CM-3314 的兩支檔；agent HEAD 五支守衛紅是 FR-167 `update_sync` 舊寫法，由 FR-170 CM-3314 改。

**決策**：CM-3312 暫緩（決策者）；BE 守衛兩紅判為 FR-170 範圍不擋本案（合回前同一 commit 跑一樣紅）。

**推翻了什麼**：無。

**教訓**
- 「本機驗不到」的 e2e 卡在開發期會反覆觸發工作坊 anomaly（CM-3293、CM-3312 兩次）；e2e 卡的驗收條件該寫成「dry-run 無未定義 step」，實跑放測試期，不然每張都要人介入。
- 工作坊首腦會自行補開卡（CM-3316／3317），STATE §2 與 cards.py 都會落後；接手先看 workshop.log 的「派工」行而不是只看 STATE 的卡表。
- 合回前先 `merge-tree --write-tree` 試合，零衝突再真合，四 repo 一次做完；判「既有紅」要拿合回前那個 commit 開 detach worktree 跑同一支測試對照，不憑印象。

### 第 4 棒續記（17:40）：進測試期——套件發版、清漏洞、換測試章、pipeline 跑 190
**結果**
- 決策者要測真的更新。190 現在 1.26.0 沒有 `guidantai upgrade`，第一次只能走 pipeline 排練（清 190、裝舊版、灌 STG dump、install.sh --upgrade）；之後再出 1.27.1 用離線檔在更新中心真換版。
- 第一次 pipeline 3007700648 擋在 verify：pip-audit 81 項新 CVE（12 支第三方）。決策者裁「升版這 12 支」，並要求「套件有要發的都要發，用最新套件包版」。發六支套件、BE 改釘、版號進 1.27.0（細節見 STATE §1「測試期第一步」）。
- 原 DEV 發布印樣私鑰遺失，換新測試章 `b91819f86eb4b4f8`（決策者選「我產新測試章」）。
- 188 jedi clone `main` → `feature/FR-139`（決策者授權）。pipeline 3007809601 開跑。

**推翻了什麼**
- STATE 寫「jedi-remote-agent 1.10.0 已發正式版」屬實，但事件碼 6230～6236 的 commit 晚於 release commit，1.10.0 不含；補發 1.10.1。
- 第 2 棒說 jedi-ldap 0.1.0 之後有未發改動：核 Nexus wheel，0.1.0 已是新分層、雜湊與 lock 一致，不需發。

**教訓**
- 看 Nexus 版本清單別用 `tail -N`：1.10.0 照字母排在 1.6.0 前面，被截掉後誤判「Nexus 沒有」。要 `sort -V` 列全部。
- 升一支漏洞套件可能把另一支壓回有洞的版本（litellm 1.104.0 加 filelock<4）；每次 poetry update 後看 Downgrading 行，再跑一次 audit。
- 分類沙箱有自己的鎖檔（pip-compile、帶 hash、在 amd64 image 內解析），BE poetry update 清不到它；pip-compile 不帶 --upgrade-package 不會升版。
- 188 的 BE／FE／jedi 三個 clone branch 要一致：CI 只 pull 不切，jedi 停在 main 會讓 build_classifier_image 版號不符而停。
- 出包前先核「這次會不會跨版」：rehearse 要求新舊版號不同，同版號的 pipeline 就算 verify 綠也會在 rehearse 停。
- glab 登入過期時 `glab auth login` 在 Claude 內跑不了（要互動），請決策者開一般終端機跑。

### 第 4 棒續記（18:55）：排練連三紅、修兩支 migration、190 清空
**結果**
- pipeline 3007825867 紅在 verify：被取消的 3007809601 在 188 留下孤兒 build_release.sh／nuitka（掛到 PID 1），CI 的 pgrep 守門以為有人手跑。只 kill 那三個確切 PID。
- pipeline 3007846452 紅在 build-be 的 smoke：從 STG 1.26.0 升級停在 `2026-10-24-fr162-seed-iec62443-reference-framework.sql`（寫套件 012 才加的 language_code；migrate.sh 先主線後套件）。修：主線改空操作，資料由 jedi-oscal-v2 025 同 uid 冪等提供（`b3e9a0821`，同 fr135 先例）。
- pipeline 3007940374 紅在 rehearse ⑤：**1.26.0 舊包本身在全新機器裝不起來**（`2026-09-22-fr114-asset-read-capability-backfill` 查能力點，但能力點在第三輪才建）。已出貨的舊包改不了，所以「CI 排練從零重灌 1.26.0」在 190 必紅。
- 改走全新安裝 1.27.0 前，用出貨 1.27.0 init image 在空庫 init＋照 migrate.sh 順序逐支套（不中斷）：只有 `2026-10-17-fr144-project-task-menu-order.sql` 失敗（驗證段整串比對選單，FR-161 後來在同群組加了 pre-engagement=25）。修：只驗本檔管的六項（`7b3918a65`，**未 push**：git 對 gitlab.com 的憑證過期，`could not read Username`）。修後新裝 148／0、從 1.26.0 升級 164 支＋能力點 243 皆 0 錯誤；突變驗證段仍會擋錯。
- 決策者裁：190 的 Guidant 主系統＋Agent＋安裝包全部移除、清空間；sentry／glitchtip／bugsink／repos／jenkins／e2e-env／舊備份一律不動。已清：兩個 compose 專案與全部 guidant／agent volume、/srv/guidant-ai(-agent)、/etc/guidant-ai(-agent)、/usr/local/bin 三支、home 下 1.25.1／1.26.0／1.27.0 包與解開目錄、Guidant 與 classifier 映像。磁碟 106G → 45G。設定與祕密先備份在 190 `/home/jedi/guidant-config-backup-20261030-185327.tar.gz`（600）。

**推翻了什麼**
- 第 4 棒前段說「排練段只有 package 會紅」：排練段自己也會打包，PROD 印章與 Agent 交付包守門在那裡就擋。已加 CI input `internal_test`（`0de0d3ca2`）。
- 「從 1.26.0 重灌再升」不可行（舊包缺陷），測試起點改「全新安裝 1.27.0」；升級路徑改以 STG dump＋migrate.sh 在本機驗。

**教訓**
- seed 類 migration 在全新安裝必重放；驗證段寫死「整個群組現在長怎樣」，之後任何功能往同群組加東西都會讓新裝失敗。驗證只驗本檔自己改的那幾列。
- 主線 migration 不可寫套件 migration 才建的表或欄位（先主線後套件）；要寫就放進套件。
- 驗「新裝」與「升級」是兩條路：STG dump 只驗得到升級；新裝要拿出貨的 init image 在空庫跑 init＋migrate。
- 取消 pipeline 後先在 188 查 pgrep 孤兒 build，否則下一條 verify 直接紅。
- 一次掃完所有失敗再修（不中斷逐支套），不要修一支、跑一輪 pipeline、撞下一支。

### 第 4 棒收（22:35）：190 線上更新第一次實測，第 0 步逾時；交接
**結果**
- Agent 兩版：1.4.3 裝 190（已核准、心跳正常）、1.4.4 收進 1.27.1。Agent build 一路撞三個 FR-166／FR-170 後過時的檢查（LDAP 收錄路徑、smoke 用 http、就緒判定寫死舊名）與 Go 工具 CVE，全修。
- 189 LC 更新到 feature（product_major＋身分票），決策者授權。
- 更新站部署到 Cloudflare、改掛 `guidantai-update.jedicotech.com`（決策者不要個人名稱）、Access＋R2 設好；1.27.1 直接寫進 D1 發布（決策者裁，略過 Access／內部先裝）。190 指向更新站。
- 決策者實測：檢查更新 → 預先下載（成功）→ 更新到 1.27.1 → **第 0 步 self_replace 60 秒逾時，系統未動**。
- 依決策者「一天太久」改檢查更新每 6 小時＋啟動先問一次（`7774e7345`），順修 GUARDED_TICKS 漏列 `_agent_rollout_tick`。

**推翻了什麼**
- 以為只有 package 段會紅：排練段自己也打包，PROD 印章與 Agent 包守門在那就擋（加 `internal_test`）。
- 以為更新中心「立即」會先提醒 5 分鐘：FE 文案如此，後端與 design 都是立刻開始，文案錯。

**教訓**
- 每步時限要依「這版包多大」估，不能沿用小包時代的數字；gzip 包抽單一檔也得讀完整包。Agent 包收進主系統後包大 1.8G，第 0 步就爆。
- 出包流程第一次真機跑會把所有跨 FR 的過時檢查一次壓出來：開發期只在 DEV／本機驗，全鏈從沒跑過。
- 監看 log 的 pgrep 會抓到自己的 ssh 指令列，判「還在跑」要看確切進程，不要信 pgrep -f 的計數。
- 對決策者回報要全程中文，本棒多次混英文被點名。

## 第 5 棒｜2026-10-30～31｜首腦：190 四次實測、P8 九張卡、夜間無人值守出 1.27.2

**角色**：首腦（決策者開的 session，冷接；中途決策者授權 push／套件發版為常態、交付無人值守）。

**結果**
- 190 線上更新實測四次：①第 0 步 60 秒逾時（systemd 繞道 600 秒）②第 4 步 bugsink 變數未設、自動退回成功 ③第 4 步 vulndb 因 redis unhealthy、**自動退回也失敗**、`guidantai recover` 救回 ④成功 1.27.0→1.27.1。Agent 1.4.3→1.4.4 推送成功（心跳等 4 分、解包無進度 3 分）。
- 首腦當場修並 commit：bugsink 每段 `ensure_bugsink_env`、退回換設定改原目錄覆寫（`dbc_restore_item`）、重試跳第 0 步、退回起 bugsink、診斷包 644；同 patch 手套 190。
- 待辦 1～27 拆 P8 九張卡 CM-3336～3344（批 18～21），工作坊 30 auto 模式自跑全過全合回（CM-3339 驗不過一輪、CM-3343 因卡含 FE 檔停下問，首腦縮範圍 resume）。
- 夜間：合回三 repo 並 push、FE 補 14 個錯誤碼翻譯、Agent 升 1.4.5、188 出 Agent 1.4.5 與 BE 1.27.2、測試章簽、R2、D1 發布。

**推翻了什麼**
- 第 4 棒 STATE 待辦 11 寫「對 failed 按更新到 X 會重下載 5.25GB」：錯，下載前會重驗 incoming 包、驗過直接 ready（190 實測 26 秒）。
- CM-3343 卡寫「13 個錯誤碼」、小弟報 16：用 Python AST 實數為 14（grep 會把跨行定義算錯）。
- P8-9 原卡要小弟去 188 出包：會打出不含修正的包（188 pull 的是 feature/FR-139，修正只在 ws 分支），派工前改由首腦接手。

**教訓**
- **188 手跑出包有三道只寫在 CI 的前提**：PATH 加 BE `.venv/bin`（pip-audit）；DB 斷言 rc 3 走 `smoke_tempdb.sh`（`build_all.sh` 沒這條分流，手跑永遠出不了包；絕不升 STG）；export `GUIDANT_BUGSINK_ADMIN_PASSWORD`。另 Agent build 要 `FE_CONSOLE_DIST` 指**當下 FE** 建的主控台產物（沿用舊暫存會帶舊前端）。
- 退回換「被常駐容器 bind mount 的目錄」不可 `rm -rf`＋`cp`：inode 變了容器看到空目錄，退回自己也起不來。
- 「先換自己再跑」的設計：修在升級過程中執行之程式（主機 lib、前端跳轉）的東西，要裝了那版之後**下一次**升級才生效。
- Mac git 對 gitlab.com 憑證失效時，用 `-c credential.helper='!glab auth git-credential'` 借 glab 既有登入，不存新憑證。
- i18n JSON 補翻譯要文字插入，`json.dumps` 整檔寫回會重排數百行（今晚又犯一次，已還原）。
- Agent 程式有改就要升版號，同號重出會被更新中心判「已是最新」而送不到。

### 第 5 棒續記（11:05）：190 升 1.27.2 成功、P9 九張開卡、交接
**結果**
- 10:04 決策者按更新到 1.27.2，10:19:41 完成（7 分 40 秒）；第 4 步以正式包過錯誤追蹤站與弱點庫兩關、redis 全程 healthy；清理刪 1.27.0 映像與首次升級 named volume。190 繞道 `fr167-self-replace-timeout.conf` 已刪。`role-manage` 已被第三輪清掉；`tool-plugin-manage` 仍在（待辦 28 未修）。
- 決策者點出結構性痛點：每修一次升級流程要出兩包升兩次才看得到、一包一兩小時。裁 A（維護頁隨第 0 步換新）＋B（第 0 步秒級）＋D（快速出包），C 同版重升不做；本體與 Agent 各出兩包（1.27.3／1.4.6、1.27.4／1.4.7）驗收。
- 開 P9 九張 CM-3346～3354（批 22～24）；決策者同意升級後刪解開目錄只留安裝包；eml／msg 待裁。
- 決策者授權 push 與套件發版為常態（CLAUDE.md、memory 已改）；定調朝向無人值守自動化。

**推翻了什麼**
- 第 5 棒先前說「待辦 17 已修」：只對維護頁成立，更新中心頁 `STEP_NAMES` 到 1.27.2 仍漏第 0 步（待辦 31 補）。
- 第 5 棒先前說「190 升 1.27.2 時會一起清 tool-plugin-manage」：錯，那是待辦 28 未修的部分，1.27.3 才會。

**教訓**
- 修在「升級過程中執行之物」（主機 lib 第 0 步、維護頁、更新中心升級中畫面）的東西，第一次升級跑的是舊版，要再升一次才看得到。回報「這次升級會看到 X」前先分清 X 是升級前就在跑的、還是升級中才用到的。
- 升級流程停服務前前門仍是舊版，所以「自動跳維護頁」這類前端修正天生晚一版；A 的做法（維護頁靜態檔隨 ops.tar 在第 0 步換到前門掛載目錄）把它拉回當次。
- 190 實測的回饋要邊看邊記進 STATE 編號（本棒記到 34），決策者說「晚點一起修」時才拆得出卡；不要等測完憑記憶補。


## 第 6 棒｜2026-10-31｜首腦：P9 批 22～23 驗收合回、兩張改拉、補兩張卡、188 清磁碟

**角色**：首腦（決策者開的 session，冷接第 5 棒）。

**結果**
- 決策者裁 CM-3349／3351「不要靠心跳、不要等 Agent 回報」：改成 Agent 開唯讀 `GET /update/progress`（守門沿用 `/update`）、主系統 overview 對下發中那幾台並行拉、記憶體快取；不加表不加 migration，心跳與 `enroll.py` 零 diff。
- 補開 CM-3355 P9-10（fe，批 23：Agent 8 格展開＋五個證據上傳入口 accept 讀白名單端點＋錯誤碼翻譯）、CM-3356 P9-11（fe，批 22：Dockerfile npm install 獨立層、.dockerignore 不排 .git；另一 session 清 188 時發現，派工單核過三處修正後開）。
- 批 22～23 十張全過工作坊首腦驗收（P9-1 退一輪：維護頁 js/css 多一層；P9-9 退一輪：關卡掛在共用 adapter 會擋掃描結果 .spdx；P9-7 退兩輪），出版首腦開檔抽查全對得上卡。四 repo `--no-ff` 合回 `feature/FR-139` 並 push：BE `742787553`（含 CM-3353 的 1.27.3、pyasn1 0.6.5）、FE `a51fabaf`（1.27.3）、agent `58793ac`（1.4.6＋RELEASE_NOTES）、jedi `47050878`（iam 1.11.1／detection 1.7.1／file-upload 1.6.0b1 已在 Nexus）。
- 188 磁碟 98%→79%（83G 可用）：只刪自家舊包（1.25.1／1.26.0／1.27.0、1.27.1 解開目錄、fr167-bundle-old、fr167-offline、home 的 guidant-ai-1.26.0）、Agent compose 1.4.1～1.4.3、自家映像 1.27.0／1.27.1、Agent 1.4.1～1.4.4；第三方映像、dist、build cache、Prompt Guard 不清（決策者明示）。kill 兩個 FR-133 留下 21 天的 `until pgrep build_all` 等待迴圈。

**推翻了什麼**
- 第 5 棒 P9-4／P9-6 設計（心跳帶進度、升級中 5 秒一跳、rollout 加 progress 欄）：決策者裁改拉，整張改寫。
- 「先清三週前那 9G build cache」：實跑 `builder prune --filter until=168h` 回收 0B，104 筆舊快取全是被現存 image（STG 現役 1.26.0、Harbor 1.26.0 副本、LibreOffice／Prompt Guard 層）引用的 shared 層，刪不掉；根治改寫進 P9-7 的 `--keep-storage 20G`。
- prune 先 append 到 P9-2，但小弟 11:50 已做完、12:40 才追加沒看到——移到 P9-7（CM-3352）才做進去。

**教訓**
- 卡派出後再 append 的修正 runner 看不到（memory 早有）；這次自己又犯。追加前先看工作坊 log 那張是否已判 done。
- `pgrep -f` 守門會抓到自己的命令列（含關鍵字的 `bash -c`），遠端跑要用腳本檔或 `[x]` 字元類技巧；FR-133 的兩個等待迴圈就是這樣互相卡 21 天。
- Nexus 私庫 pip index／pip download 都探不到版本，要用該套件目錄下 `poetry search`。
- CM-3353 小弟判斷正確：首腦還沒合回 feature 時，188 pull 到的是舊 HEAD，出包會白跑；結案卡的前置是「首腦先合回 push」，下次開結案卡寫明依賴首腦動作、或把合回放進結案卡前一批。

### 第 6 棒續記（18:20）：五版發布、190 熱換、188／189 核心重開、交接
**結果**
- 發更新站：1.27.3（P9）→ 1.27.4（版號）→ 1.27.5（FE 三修正）→ 1.27.6（版號）→ 1.27.7（FE 輪詢看單不看畫面＋Agent 無本輪紀錄不畫格）。update-center 部署 ops 支援（`8e6ea6e`）。
- 190：1.27.2→1.27.3→1.27.4→1.27.5→1.27.6 四次線上升級全成功（第 0 步 1 秒、自動跳維護頁、亮色都驗到）；18:00 熱換前端 image 為修正版；正在升 1.27.7。
- 188 STG／189 POC：seccomp errno 524 根因＝核心沒重開（跑 -187／-171、已裝 -202），兩台重開後全 healthy；189 磁碟 90%→61%、188 98%→82%。188 STG api 三容器起回、資料完好。
- FE 修正四個 commit：`a4126e2b`（Agent 成功收合）、`13ef3ecc`（目標版號不被舊單蓋）、`30addad1`（遮罩＋scheduled 已到＝submitted）、`e1849538`（輪詢看未結束更新單）。

**推翻了什麼**
- 第 6 棒自己先後三次（待辦 13／19／37 延伸）在「問到狀態後怎麼畫」上補格，決策者點名「一直在原本的機制上找答案」。access log 一看才發現是輪詢停了（`ready` 不在 ACTIVE_VIEWS）。正解是輪詢看「有沒有未結束的單」。
- 第 6 棒先判 seccomp 524 是 runc bug、升了 189 的 containerd（無效）。對照 190（同軟體版本、核心 -198 正常）才指到核心沒重開。
- 第 6 棒 12:xx 誤刪 188 `/home/jedi/guidant-ai-1.26.0`（以為是解開的舊包，實為 STG compose 工作目錄）；從 tar.gz 重建救回。

**教訓**
- **修畫面問題先看 access log 有沒有在問**，再看問到什麼。輪詢條件綁畫面狀態＝每多一個狀態就漏一格；綁「單結束了沒」才是機制層的修。
- **錯誤訊息指到的那層不一定是壞的那層**：errno 524 在 runc 報，壞的是核心；先找「同軟體版本但正常」的對照機。
- **刪目錄前 `docker inspect` 全部容器 working_dir／mount**（memory 已立）。
- 驗 minified JS 有沒有某段程式，不能 grep 變數名（被改名），要 grep 字面值序列（字串常數順序不變）。
- 熱換單一容器：compose 檔要用資料目錄那份，容器標籤的 working_dir 可能已被清理刪掉；`guidantai restart` 不重建容器。

## 第 7 棒｜2026-10-31～11-01｜首腦：升 188／189、P10 八張、1.27.8 發布三台線上升、Agent 1.4.7、PM 簡報與機制報告、P11 七張

**角色**：首腦（決策者開的 session，冷接第 6 棒）。

**結果**
- 188 STG 18:33→18:39、189 POC 19:21→19:33 用 1.27.7 `install.sh --upgrade` 升（第一次、1.26.0 無升級程式），各 164 支 migration、資料完好；兩台加 `UPDATE_SITE_URL`、`guidantai start` 套用；刪 1.26.0 解開目錄（核零引用）。
- 決策者升級後三問 → 待辦 45（側欄 localStorage）、46（能力點翻譯）、47（CRA PDF 沒進包：188 `.build/storage-seed` 8/21 殘留＋build_bundle「已存在不動」）；另 44（下載完 37 秒空窗：ready 當中途狀態、寫單前重算雜湊）、48（決策者裁拿掉 90 天）、49（主系統沒打 report）、51（Agent 目標版空判「已是最新」）、52（CRA 繁中 deprecated 列升級路徑留下）。開 P10 八張 CM-3358～3365（批 25～28，衝突檢查抓到 P10-1／P10-3 同撞 error_code 登記檔，移批）。
- 工作坊跑完 P10-1～7；結案小弟被決策者停，首腦 188 接手出包（22:16→22:52，smoke 9 PASS），`publish-1278.sh` 23:01 發布；190 apply → **P10-3 新預檢擋「核心沒重開」**→ reboot → retry 23:19 成功；188／189 同時 apply 23:34 成功（兩台第一次走線上）。更新站回報表三台 `succeeded`（P10-6 真環境驗過）。
- 189 兩台 Agent 1.4.2 手動升 1.4.7（1.4.2 無遠端更新能力；主機間無免密 SSH 經 mac 中轉 1.8G 兩趟）。
- 三台 bucket 補灌 CRA PDF（照 install.sh `load_storage_seed` 同路）。
- PM 簡報 10 張（決策者逐頁改：拿掉現況與對象句、簽章頁改一張圖、第 7 頁流程圖、第 8 頁狀態中文、第 10 頁架構圖、刪 11／12 頁）；PM 會議 23 條分類 → A 類開 P11 七張 CM-3366～3372、B 類先不討論、Q5＋20 查為備份機制缺口 → 機制問答報告。
- 本機 BE／worker／FE 重啟到合回後程式。

**推翻了什麼**
- STATE 寫「188／189 沒裝 Agent」→ 189 有兩台 Agent 在別機器報心跳；「update-center 在 main」→ 本機在 feature/FR-139 且 8e6ea6e 未 push。
- 第 6 棒待辦 42「文案把被刪說成沒附」只是表象，根因是 `install.sh --upgrade` 路徑 `bundles/` 不存在 → 目標版空 → `is_lagging` 回 False。
- 簡報初稿「不信任更新站」「六道驗證含 90 天」「CI 傳 R2 登記草稿」三處被決策者點名：用語像罵自己、90 天已裁拿掉、CI 段從沒跑過要據實。
- 「Q5 backup 目錄檔案不見」→ 不是不見，是舊流程 pg_dump 停更、新流程只留一代快照，沒有備份機制。

**教訓**
- **修畫面問題先對時間軸**：待辦 44 用檔案 mtime＋DB 列＋journal 三方對出 37 秒落在哪一段，才知道洞在「寫單前重算 5G 雜湊」不在輪詢。
- **mac 沒有 `setsid`**：`nohup setsid …` 在 mac 靜默失敗、服務沒起；188（Linux）可用。本機起服務用純 nohup 加子 shell。
- **開包 grep 整顆 3G image 太慢**（`grep -r /` 超過 3 分），改用實升驗證或 grep dist 目錄字串。
- **新預檢第一次就擋到真狀況**：190 跑 -198 已裝 -202 卻正常，是運氣；P10-3 擋下後重開再升才乾淨。預檢擋的是「會不會炸」不是「現在有沒有炸」。
- **同範本複製的 VM 指紋會相同**（待辦 54），更新站按指紋統計與封鎖會互相干擾。
- **卡上寫「已存在就不動」的快取邏輯要配守門**：storage-seed 殘留讓 CRA PDF 漏包，守門「map 筆數 ≠ 檔數就擋」比「每次重建」更早抓到。
- **決策者追問機制時，一題一答、先結論再事實**；他連問九題（min_base、release.json 欄位、90 天、兩把章、公鑰放哪、簽名在哪、UC 存什麼、check 給什麼、怎麼認證）每題都要對回程式碼那一行，不能憑簡報措辭。


## 第 8 棒｜2026-11-01｜首腦：P11 七張驗收合回、UC 0004 部署、基線重產 1.27.9、出 1.27.9 包並發布（三台升級留決策者）

**角色**：首腦（決策者開的 session，冷接第 7 棒）。決策者 01:2x 令「他出完包你幫我跑發佈腳本、我要自己測試一次升版」「交給你囉我明天早上來看、允許 push 跟發套件包」，之後無人值守。

**結果**
- 工作坊 30 在決策者 01:11 按完 P10 Done 後自動派 P11 批 29（01:14）→ 批 30（01:29）→ 批 31（01:40），工作坊自己開的首腦 session 逐張驗收通過；本棒做合回／部署／基線／出包。
- update-center：合回 `9cd76ea`、Worker 測試 97＋CLI 48 綠、push、`d1 migrations apply --remote` 0004、`wrangler deploy` a24b6d26。
- FE：合回 `88cb65b4`、版號 1.27.9 `fb0b3e7f`、push。BE：合回 `38889a128`（3369／3370／3371）、DEV 套 reported-at、基線重產 `aef74c6b0`、版號合回 `55c8d574d`、push。
- 188 02:02 `fr167-build-1279.sh` 出包；發布結果見下一行（出完補）。
- 出包 02:02→02:35（Nuitka＋smoke 9 PASS＋8 顆 image＋封包），開包：storage-seed 11 檔含 CRA PDF、`lib/diag_upgrade_stage.sh` 含 upgrade_log、ops.tar 22 項、Agent 1.4.7 包在、BE 執行檔含 `PRODUCT_UPDATE_STEP_SELF_REPLACE`／`agent_fingerprint`／`upgrade_log`／`last-switch.json`。`publish-1279.sh 1.27.9` 02:42→02:46：測試章簽（含 ops 兩欄）、R2 `v1/1.27.9/` 五檔、D1 一列 published（18:46Z）、說明四條。包 sha256 `6810fdfd…`、5,262,333,964 bytes。三台未升（決策者自己按）。

**推翻了什麼**
- STATE 寫「P11 等決策者在工作坊派」→ 工作坊 30 是 auto 模式，P10 全 Done 後自動往下派，首腦接手時批 29 已在跑。
- STATE §6 註解的套件版號（jedi-remote-agent 1.10.0／jedi-license-runtime 1.1.7b1）過期，實際 1.11.0／1.1.7。
- 第 7 棒待辦 44 修法「主機撿單與預檢兩次可併一次」未做，只做了寫單前不重算；非本棒範圍，記著。

**教訓**
- **結案卡要寫「首腦先合回才能出包」而且 stamp gate 會擋新 migration**：CM-3372 小弟正確地停在「188 出包會被 stamp 檢查擋下」並建議基線重產，首腦照 8206f1788 流程做（備份→套→重產→三張 diff）。下次 P-結案卡前一批若有主線 migration，首腦在合回時就順手重產，不要等結案小弟報。
- **`gen_stamp_sql.sh` 版號來自 pyproject**：前兩次重產時 pyproject 還是 1.26.0 所以標記沒動；這次會跳到 1.27.9。`init.sh` 用 `LIKE '__init_baseline_v%'` 判斷，版號只是標籤，但 diff 會看到 289 行全換，要用「檔名集合 diff」而不是行 diff 判斷有沒有掉列。
- **update-center `npm test` 會把 `.worktrees/` 底下的 node_modules 測試一起跑**（30 紅全是 blake3／zod 套件自己的測試與 worktree 副本），要 `--exclude '**/.worktrees/**'`。
- **`tail -F` 監看工作坊 log 收不到事件**（log 檔被整檔重寫），改成每 20 秒比行數的輪詢才可靠。
- **等 build 的 `until grep` 不能只抓 `FAILED`**：smoke 輸出含 `FAIL=0`／`FAILED` 字樣會提前跳出，要錨定 build 腳本自己印的 `^[time] DONE|build_all FAILED|build_bundle FAILED`。
- **Agent 回報更新站（P11-1／6）沒有新 Agent 版就驗不到真環境**（待辦 57）。

## 第 8 棒（後半）｜2026-11-01 09:00～12:50｜首腦：Office 預覽與 Profile 下拉、jedi-detection 1.7.2、1.27.10＋Agent 1.4.8、189 升級、決策者兩項裁示

**角色**：同一個首腦 session，決策者在場即時下令。機制問答另交給 QA session（`qa-session-handoff.md`）。

**結果**
- 決策者回報 189 證據 Word 預覽 500（存在遠端 Agent 121 上的 docx）。根因兩層：Agent 從沒接 jedi-file-upload 的設定讀取 port（`settings.configure`），`LIBREOFFICE_CMD` 設了也沒人讀，退回 PATH 找 `soffice`；容器 PATH 只有 `guidant-soffice`。另一份外部分析只看到「容器版漏設 env」，只加 env 不會好。
- demo 應急（決策者令「直接改」）：121 容器內 `ln -s guidant-soffice soffice`，免重啟生效；12:31 換 1.4.8 新容器後消失、由正式修正接手。
- 正式修正：evidence-agent `ab3a5b6`（接線＋Dockerfile ENV＋守衛測試、兩條突變紅）。
- 決策者問 Agent 主控台 CINC 為何不能選 Profile：主控台從 FR-166 P2-3 起把 Profile 庫欄退成文字；但 Profile 早由心跳同步到 Agent 本機（121 有 8 支 TWGCB）。加主控台下拉：evidence-agent `3215a8c`（`/console/api/scan/profiles`）、FE `bd8ce295`；再依決策者要求補「依工具過濾、名稱同主系統」：jedi-detection `7aed6d2a` 1.7.2（心跳清單帶 `tool`、`name`，已發 Nexus）、BE `0643d95b7` 改釘、evidence-agent `6a184d3`、FE `a156ea01`。
- 出包：Agent 1.4.8（`67bc162`）、BE／FE 1.27.10（`ee7d1a807`／`23b700fb`）；188 先刪 1.27.5～1.27.7 本機包騰空間（R2 已有、無容器引用）；主控台前端在本機 build 後 scp 到 188（188 沒 node）。11:06→12:01 出完，開包核 Agent env／BE `tool_code`／主控台字串；`publish-12710.sh` 發布，用 Worker `planPath` 以 vitest 實跑確認 1.27.9／1.27.8 都直選 1.27.10。
- 189：決策者 12:14 升 1.27.10 八步全成功；12:22 推 Agent。121 12:31:50 升完、12:36:30 主系統收成功、12:37:07 回報更新站；60.167 12:27:36 失敗「無法讀取新映像」並回報更新站（**P11-1／P11-6 第一次真環境驗過**）。
- 支援頁診斷包說明只列「包含什麼」（決策者令）：FE `f0a2e29b`。
- 機制問答報告加升級接力圖（改了四版：泳道→時間軸→mermaid flowchart→sequenceDiagram＋autonumber，再改亮色單主題），拿掉 Q8 打折段。
- 決策者裁示：①主系統與 Agent 分開更新（取代「第二期先不討論」）②不再用心跳帶訊息（「雷到一個不行」）。需求紀錄 `docs/draft_requirement_spec/2026-11-01-agent-independent-update.md`、memory `feedback_no_heartbeat_piggyback_messaging`。

**推翻了什麼**
- 「8 格之前是好的」→ 從 P9-6／P9-10 起 BE 放 `item.progress`、FE 讀 `rollout.progress` 就沒對上；成功時 FE 全打勾不看進度，10-31 在 190 看結果才沒發現（待辦 60）。
- 「121 沒收到進度請求＝主系統沒拉」→ 錯，`docker logs` 只看得到新容器；舊容器那段 log 跟著被換掉。查升級中 Agent 行為不能只看現容器 log。
- 「預覽 PDF 只存儲存區、不寫 DB」→ 錯，jedi-file-upload `convert_to_pdf` 另寫一列 `upload_files`（`file_name`＝存檔 ID、scope 預設 customer），Agent 主控台照列（待辦 58）。
- 「主系統完全不用動、只升 Agent 就好」→ Office 預覽確實只靠 Agent；但現行 Agent 只能隨主系統包送達，且依工具過濾要主系統帶新欄位，所以仍得出 1.27.10。

**教訓**
- **背景等待的 grep 不能抓 `FAIL`**：smoke 輸出含 `FAIL=0`，兩次被誤觸提前結束；一律錨定自己腳本印的 `^[時間] ALL DONE|... FAILED` 並加「腳本已不在跑」退出條件。
- **兩張同批平行卡寫同一份契約（BE 產、FE 讀），開卡要附 JSON 形狀範例**；驗收要看「途中」而不是「結果」，結果畫面常用捷徑蓋掉資料。
- **Agent 升級會換容器**：任何「升級中 Agent 狀態」的判讀都要跨新舊容器看，或看主機層檔案（`/srv/guidant-ai-agent/upgrade/`）。
- **心跳當訊息通道，延遲就是心跳間隔本身**：新容器啟動那一跳早於主機收尾，結果晚 5 分鐘回；決策者裁不再用。
- **artifact 只存在 claude.ai、scratchpad 會清**：產出要給 PM／主管的頁，做完就拉一份進 FR `briefing/`。
- **mermaid 的 init 配色只有淺色**，頁面支援深色時圖會看不見；給主管的頁直接定亮色單主題。

## 第 9 棒｜2026-11-01 12:5x～15:3x｜首腦：60.167 真因、兩台清磁碟、P12 收口卡、批 32 合回、技術文件站、重試 412 修、母卡收 Done

**角色**：首腦（冷接第 8 棒，決策者在場即時下令）。決策者此棒明令：收口卡現在開、文案改立刻開始、合回 main 但不跑出版流程、Agent 獨立更新放下一個 FR 與 FR-171 一起、技術文件「一主題一份、分類做好」、重試 bug 直接修且允許 subagent、最後「都幫我收 Done」。

**結果**
- 60.167 推 1.4.8 失敗真因＝磁碟滿（dockerd journal `no space left on device`，`upgrade_order.sh:305` 吞 stderr），不是 docker／核心。清舊 1.4.2 映像、1.4.7 包副本、舊 compose 專案 0230 三個 volume → 13G→31G。
- 188 build 機 6.7G→100G：24 個無容器引用的舊 tag、build cache 74G→36G、解開的 1.27.8／1.27.9 目錄、Agent 舊包、`/home/jedi/seaweedfs` 獨立實驗組、0.2.28 孤兒 seaweedfs＋volume（決策者逐項裁）。**沒刪 `/home/jedi/guidant-ai-1.27.7`**：redis／seaweedfs／bugsink 標籤仍指它（待辦 62）。
- P12 收口開五張 CM-3374～3378（`6d58890eb`）；CM-3377 Bugsink 密碼決策者裁不做（`596cbdbbb`）；CM-3378 結案出包裁等 FR-171／172。批 32 三張工作坊 30 自動跑完、決策者 13:47 Done；首腦合回 FE `d18e98a2`、Agent `2b78d00`（RELEASE_NOTES 衝突：ws 基底只到 1.4.4，以主線為底加「下一版」段），bats 51 綠、vitest 27 綠、push。
- 技術文件站（`d03ab084c`）：四棒 subagent（決策者明令允許）寫 FINAL-SPEC、九份技術規格、發版手冊、SPEC 與兩份手冊對 1.27.10；首腦自做 PM 簡報靜態頁（claude.ai Slides 專案轉單檔）、README 重寫、側欄分類（三支改名 `-spec`、QA 交接搬 handoff/、design／discussion h1 改名、render_index 登記 briefing／prototype）、build 與截圖驗 mermaid。
- 重試 412 修（決策者「直接修掉」）：BE `38ce72ad2` 進度檔 `failed／timeout＋unchanged` 同步成 `skipped`；FE `78e4f535` `canRetry` 只認 rolled_back／skipped。BE 213 綠、FE 79 綠。
- 收 Done：P11 七張、母卡 CM-3241（append 收口段）。analysis `docs/analysis/2026-11-01-fr167-online-update-four-decisions.md`（先換自己、輪詢看單、無有效期、不用心跳）；memory `feedback_agent_upgrade_image_unreadable_means_disk_full`。

**推翻了什麼**
- 第 7 棒「三台指紋相同會被更新站算成一台」→ 錯，主鍵含 license_id，三列都在；真正會撞的是 LC（範本 VM machine-id 相同）。
- 第 8 棒「60.167 疑 docker／核心」→ 磁碟滿。
- 首腦自己把待辦 39（Bugsink 密碼）當「要修的缺口」開卡 → 決策者問「為什麼會跳出這項」，它只是記下的疑慮，關卡。
- 待辦 2「立即」文案 → P8-3 `933aa083` 早已修，不必開卡。
- 文件棒查到 design 與程式碼不同：七張表非六張、客戶端無 90 天、身分改身分票、正式 publish 不帶 ops 兩欄、第 5 步不起 worker、時限數字；後台 Agent 三欄永遠 0（待辦 63，等 FR-172）；`failed＋unchanged` 重試 412（待辦 65，已修）。

**教訓**
- 「記下的疑慮」與「裁定要修的缺口」要分開列，開收口卡前先問決策者哪些是後者。
- 刪遠端目錄前的防呆（容器 working_dir／config_files／mount）這次擋下一次：線上升級不重建的服務標籤仍指舊目錄。
- claude.ai Slides 匯出的 deck.json＋slide 片段本地開不了，要給站用就轉成單檔靜態頁。
- build script 的底線規則只對資料夾生效，檔名加底線藏不住；交接類文件放 handoff/。
- 同一份 `RELEASE_NOTES.md` 工作坊基底過舊必衝突，解法固定：主線為底、ws 的段落放最上。

### 第 9 棒收（15:5x）：雜檔整理、worktree 清除、交接

- 決策者把七 repo `feature/FR-139` 合回 `main`（首腦未切 branch，接手時 `git branch --show-current` 皆為 main）。
- 七 repo 雜檔：BE FR-170 `unattended-rules.md`＋站頁入版控（`89d270e8b`、`4f9cc336d`）；LC 工作坊規則入版控＋`.gitignore` 比照主專案（`4cfa423`）；test／update-center／jedi 各補 `.gitignore` 排產物（`80e8087`、`f4d2cd0`、`7842c01b`）。PyCharm 顯示的三個「Changes」與 HEAD 無差，是狀態沒刷新。
- 七 repo `.worktrees/CM-3241` 與 `ws-CM-3241` 全刪（決策者令「worktree 跟 branch 都刪掉」）：每個先核 ws 對 feature ahead 0、工作樹乾淨，`branch -d` 安全模式全放行；遠端本來就沒這個 branch。
- 教訓：build script 的底線規則只對資料夾生效；站重 build 後要 `git status` 看連帶變動的 html（這次漏了 design.html 與新頁 html 一次）。