FR-167 線上更新

需求分成兩層。第一層是讓升級指令絕不出事：guidantai upgrade 改成在資料庫複本上升級、每步有時限、寫進度檔，失敗、卡住、斷電都自動退回更新前，現在那份資料庫從頭到尾沒動過，所以退回不需要還原、一筆資料也不掉；停機期間前門直接顯示進度頁。第二層是把搬檔與敲指令拿掉：系統每天向我們的更新站問一次有沒有新版，有就通知管理員；管理員確認後才下載（跟 iPhone 一樣）、驗簽名，就緒後有「系統更新」權限的人按「立即更新」或選排程時間，主系統只在主機上寫一張更新單，主機的 systemd 看到才呼叫 guidantai upgrade；連不到外網的客戶自己上傳更新包。每次更新都記錄誰按的下載、誰按的更新。服務停掉之後沒有取消鈕，每步有時限，失敗自動退回。客戶主機上不多任何常駐程式、不開任何新的埠；真要人出手走客戶本來就有的主機登入（guidantai recover）。只升 Agent 走同一套機制。版本只有一種：每版都是修正加功能混著出，安全修正就是發下一版，只維護最新版，每版包留 10 年；任何版本都不自動裝，一律人按，客戶不更新是客戶的事。授權管能用什麼、不管能不能裝：授權過期仍可升到同主版號（1.x）最新版，升上去是唯讀、功能鎖著；換主版號（2.0）要重新授權。五年支援靠「永遠可以免費升到最新版」達成；受不受 CRA 管、這種寫法過不過，兩題要找懂 CRA 的人確認。更新站跑在 Cloudflare Worker、檔案放 R2，先用免費方案；發版的最後一步在決策者電腦蓋章（發布印章一正一備、備用封存、跟授權中心的印章分開），CI 只能登記草稿；草稿可以指定給 STG、POC 先裝，不做頻道；停權客戶由決策者在後台手動加拒絕名單。開放使用是唯一的不可退回點，之後有問題發修正版。Agent 在主系統升完後跟進，先升 1 台，正常再推其他台。更新站與授權中心分開，互不持有對方憑證。

不做：救援頁、常駐更新助手、更新頻道、只換單顆容器（每版整包）、服務停掉後的取消鈕、強制中斷進行中的工作、任何形式的自動安裝、分安全修補版與功能版、維護舊版本線、每年一個長期支援版、升完之後的回滾、差異更新包、作業系統更新、買 Replicated（只支援 Kubernetes）。

交接現況看 handoff/fr167-STATE.md，每棒紀錄看 handoff/fr167-LOG.md。

• 2026-10-26 決策者：人力有限，想請客戶開對外白名單、由我們提供更新服務；要成熟穩定、不要技術債。
• 2026-10-27 決策者：更新來源要與授權中心分開——授權中心可能不開放客戶連線，且合在一起「一被攻破兩個都被攻破」。
• 2026-10-27 決策者：討論卡在技術面、沒有一條真的更新流程；要先講流程。首腦改以九步流程為主軸，技術選擇掛在步驟底下。
• 2026-10-27 決策者：程式大改版與內容熱更新分開，本案只管程式大改版；每版出整包、跨多版靠 migration 補套。
• 2026-10-27 決策者：主軸是「按下 accept 後自動化更新、顯示進度、不可以卡住、卡住也要能復原、可以反悔中斷與重啟、資料絕對不可以掉、不能靠人到現場（客戶在俄羅斯怎辦）」。首腦把升級改成在複本上做，加上獨立救援頁與開機自動退回。其餘四項（開放使用後不退回、預設排程、Agent 先推一台、必經版本規則）照建議定案。
• 2026-10-27 首腦實查：STG、POC 都是 1.26.0，跟主線同版，跨版排練要另外在測試機做；Agent 送不出的結果現在會直接丟掉，排進第一期補。
• 2026-10-27 決策者：客製化版本客戶的更新路徑這輪先不談。
• 2026-10-27 決策者：更新包不該讓使用者上傳，要由我們幫客戶抓；管理員確認要更新之後才下載（像 iPhone）；離線更新才自己上傳；要記錄是誰更新的。首腦把更新站從第四期提到第二期，流程改成「發現新版 → 確認 → 下載 → 升級」，加 D22–D24。
• 2026-10-29 決策者：進行中的工作永遠不強制停；救援頁「感覺像後門」；問「業界是不是這樣做、有沒有現成工具（Ansible、runner）可以用」，並點名首腦「順著話跑」要求重新分析。首腦回頭查安裝腳本：主機本來就有 guidantai 指令與 systemd，企業自架軟體的常態是「IT 敲一道絕不出事的指令」。結論：拿掉救援頁與常駐助手，執行者就是 guidantai upgrade，排程靠系統定時器（D26 裁放哪期）；服務停掉之後不接受取消（D25）；停機期間畫面由前門維護頁讀進度檔顯示。D19 改定案、D20／D21 改為不做，新增 D25、D26。
• 2026-10-29 決策者：D25「不能取消」要先講清楚失敗怎麼判、炸了怎麼復原——首腦補每步時限表（複製三倍預估、映像 5 分、每支 migration 10 分無進度、健康檢查 5 分、總上限 60 分），失敗一律自動退回不用人按；服務停掉後不給取消鈕照建議定案。D26「沒有輸入指令這件事，就是讓有權限的人按」——改成按鈕觸發：加「系統更新」權限，主系統寫更新單，主機 systemd 觸發器呼叫 guidantai upgrade，指令退成備援。追問「只更新 Agent 能不能用一樣的機制」——能，更新站發 Agent 修正版，主系統不停服務直接推。
• 2026-10-29 決策者：CRA 四項照建議——D7 改為安全修補版支援期內照給、功能版看授權；D27 維護最新加最近 2 個功能版、五年支援靠免費升級路徑、先找懂 CRA 的人確認；D28 安全修補版預設在維護時段自動裝、可關可延後、功能版照舊要人按；D29 修補包留 10 年。D15 補例外。
• 2026-10-29 決策者：盤點更新站那一組，問 D2a「不是已經改成客戶那邊自己處理」、D3「簽名是什麼」——首腦釐清 D2a 是我們這邊對客戶開放的更新站（跟客戶主機上誰執行升級無關），D3 的簽名是「發版最後一步要不要決策者親自蓋章」；並盤出 D8、D9、D10、D11 早已在流程與安全原則裡寫定、D3 與 D5 是同一題。決策者逐項：D1 OK；D3 蓋章放決策者電腦、一正一備、跟授權印章分開；D6 不做頻道改草稿指定內部機器；D12 拒絕名單手動加；D2a 選 Cloudflare Worker、先用免費方案試、再考慮要不要自己維護。待裁項清空。
• 2026-10-29 決策者：安全修補版也整包出去，不做只換有洞那顆容器，太麻煩，未來看產品走向再決定。首腦查 188 實包 2.9GB，討論稿原寫 1.7GB 已改正。
• 2026-10-29 決策者：看雛形問「安全修補自動安裝開關有什麼用，現在不是都一大包」，裁「絕對不要自動裝，通通手動確認，客戶不更新是他的事」；再指出「我們沒有分安全性更新，都是發新版本」。首腦確認整包加手動之後兩種版本在技術與安裝方式上已無差別，建議連分類一起拆。決策者問授權過期剩什麼、是否要對每版做安全更新、能不能用範圍版本——定案：不分安全修補版與功能版，安全修正就是發下一版、只維護最新版；授權管能用什麼不管能不能裝，過期仍可升同主版號最新版（唯讀、功能鎖），換主版號要重新授權。D7、D27、D28、D29 改寫，§10 重寫，雛形拆掉自動安裝區塊、⑥b 安全修補頁、更新站的種類欄與版本線表。CRA 功課改成兩題：受不受管、這種寫法過不過。
• 2026-10-29 決策者：雛形更新中心頁的「升級指令 guidantai 1.24.1 相容」不對。首腦確認：主機上的指令是裝機時複製的舊版，新版升級流程寫在新版指令裡，舊指令不會做。定案 D30：升級指令開跑第一步先從已驗簽名的新包取出新版指令換掉自己，再用新版跑剩下的步驟；畫面上不顯示指令版本。
• 2026-10-29 決策者：「往後面進行吧」。首腦落 design.md v1 與 handoff/cards.py（35 張卡 8 批，依賴與撞檔斷言過）。探脈補兩件：Agent 送不出的結果 FR-166 outbox 已做、本案不開卡；討論稿「回應 24 小時內」做不到（更新站無私鑰），改 D31 發布清單 90 天有效。卡等決策者看過 design 再開。
• 2026-10-29 決策者：CRA 兩題先不管；要放著工作坊自動跑，問「有沒有環節會卡住、哪裡要我介入」。首腦逐卡盤點出 16 張卡的驗收要 190 獨佔、pipeline、真 Cloudflare 或 PROD 印章；決策者裁「先把功能開發好，測試我跟你互動」——卡片驗收改成只寫小弟本機能驗的事，190 情境另欄給測試期。
• 2026-10-29 決策者：授權小弟在工作坊可 push 自己的 ws branch、套件要發就發 beta 版號（jedi-remote-agent 1.10.0b1），正式版留結案卡。環境卡改釘 beta，不再 path 安裝。
• 2026-10-29 決策者：Cloudflare 已有 R2 bucket guidant-ai-release，要分大版本資料夾存——首腦定物件 key v<主版號>/<完整版號>/…、只在 Worker 拼，客戶端與 CI 不寫死路徑。決策者備妥 API 權杖（D1／Workers／R2／Access 編輯）與 R2 金鑰，首腦實打驗過；網域出貨前再定。
• 2026-10-29 決策者：Worker 用 TypeScript 寫（原討論稿選 Python Worker）；新 repo 放 ~/Projects/Billows/Audit-Manager/update-center、遠端 gitlab.com/auditmanager/update-center；後台 Access 只放行決策者信箱。首腦完成工作坊登記、Notion Repo 選項、新 repo CLAUDE.md 與祕密搬家；「開新 repo 固定五步」寫進 big-feature-workflow skill，不另開 skill。
• 2026-10-30 工作坊 25 跑完：34 張卡驗收通過；結案卡停在版號（1.10.0 非 1.9.0）、套件清單、PROD 印樣、網域四題；離線上傳端到端 400 列修正卡；授權檔原文含客戶名稱要不要改送法、UPDATE_SITE_URL 怎麼帶進客戶機、出貨基線重產時機，等決策者。
• 2026-10-31 決策者：推送 Agent 要主動通知、不等心跳（「這太蠢了，後來是有通道可以進去的」）；Agent 跟進改可選（預設勾、可選台），取代 D16「一律自動」。
• 2026-11-01 決策者：主系統與 Agent 要分開更新（取代「第二期先不討論」）；不再用心跳帶訊息（「雷到一個不行」）。兩題走新 FR 與 FR-171 同一討論週期。
• 2026-11-01 決策者：收口修正合回但先不出 1.27.11，等 FR-171／172 做完一起出；Bugsink 密碼每台隨機那張先不做；更新站後台 Agent 三欄為 0 的 bug 等 FR-172。
• 2026-11-01 決策者：技術文件要很詳細、一主題一份、結構化分開靠左側選單導航；簡報與問答要放進 FR 站；循序圖架構圖流程圖都要；更新站 Worker 規格架構 schema 要寫。

以下全部由 build 掃資料夾產生，新增檔案重 build 即自動出現。標題連結指向渲染後的 HTML，md 連向源檔。

定版交付

說明與手冊

需求與討論

設計

簡報與問答（給 PM／主管）（2 份）

其他文件

互動雛形（1 份）

其他文件

交接與收口時間軸（handoff/，3 份）

由新到舊。每份是某一棒次交接當下的完整現況快照，看某個時間點「當時知道什麼」請從這裡進。

資產子資料夾（無文件，不建頁）：diagrams/（4 個檔）、prototype/（1 個檔）

卡片內容（決策紀錄、驗收條件）以 Notion 為準，本頁只記座標。

相關需求：

• FR-062 — license-management
• FR-064 — tamper-detection
• FR-065 — onprem-installer
• FR-066 — agent-native-installer
• FR-134 — source-code-sbom-scan
• FR-156 — agent-side-sbom-scan-and-vulndb-sync