FR-167 LOG（append-only）

• 母卡 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 張；子卡開頭的母卡號佔位要建完再補。

---

角色：首腦（開卡那位接續）。工作坊 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。

---

角色：首腦（冷接，讀 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 分鐘收不到事件。

角色：首腦（決策者開的 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 的計數。
• 對決策者回報要全程中文，本棒多次混英文被點名。

角色：首腦（決策者開的 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），決策者說「晚點一起修」時才拆得出卡；不要等測完憑記憶補。

角色：首腦（決策者開的 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 不重建容器。

角色：首腦（決策者開的 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 給什麼、怎麼認證）每題都要對回程式碼那一行，不能憑簡報措辭。

角色：首腦（決策者開的 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）。

角色：同一個首腦 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 配色只有淺色，頁面支援深色時圖會看不見；給主管的頁直接定亮色單主題。

角色：首腦（冷接第 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 一次）。