本卡為 FR-167 母案。客戶主系統每天向我們的更新站問新版、管理員確認後下載、有權限的人按更新；升級在資料庫複本上做、每步有時限、失敗自動退回；Agent 先一台再其餘。35 張子卡 8 批。子卡清單在末段。

這系列在做什麼（白話）

現在客戶升級要 IT 自己搬 2.9GB 的包到主機敲指令，失敗了沒人知道怎麼救。做完之後：系統每天自己去問有沒有新版，有就通知管理員；管理員按下載，系統驗過簽章與雜湊後顯示「已就緒」；有「系統更新」權限的人按立即或排程；升級時使用者看到維護頁的進度，不是錯誤頁；升級在資料庫複本上做，任何一步失敗或斷電，開機自動退回舊版，資料一筆不掉；主系統升完 Agent 自動跟著升，先一台成功才推其餘。沒有網路的客戶可以自己上傳包，走同一條驗證。

首腦讀完後的重點

• 版本只有一種（D27）、任何版本都不自動裝（D28）、授權只管「能用什麼」不管「能不能裝」：過期仍可升同主版號最新版、換主版號要新授權（D7）。
• 升級指令先把自己換成新版再跑（D30）；發布清單 90 天有效（D31），更新站沒有私鑰、只轉交決策者簽好的清單。
• 開發期與測試期分開：每張卡的驗收只寫小弟在本機／DEV 8003／本機 docker／wrangler dev 能驗的事，工作坊無人時不會卡；要 190、pipeline、真 Cloudflare 部署、PROD 印章的情境在卡上「測試期」段，由首腦操作、決策者看畫面（design §7）。
• 決策者 2026-10-29 授權：小弟可 push 自己的 ws branch；套件要發就發 beta 版號（P1-3a 發 jedi-remote-agent 1.9.0b1），正式版留結案卡 P5-5。
• 登記型檔先佔位：P1-1 一次開好 lib/ 全部步驟空殼與子命令派送；P3-2a 一次登記模組與 DI；P4-3 是 Agent enroll.py 唯一 owner。
• 更新站是新 repo update-center（TypeScript Worker＋D1＋R2，本機 ~/Projects/Billows/Audit-Manager/update-center、遠端 gitlab.com/auditmanager/update-center、branch main）；R2 bucket guidant-ai-release 已有，物件 key 分主版號資料夾；祕密在該 repo .env。

怎麼拆

• 批 1（7 張，可同時派）：P1-1（BE）、P1-9a（BE）、P1-3a（jedi 套件）、P3-1（BE）、P1-8（FE）、P2-1（update-center（新））、P2-5（License Center）
• 批 2（6 張，可同時派）：E-1（BE）、P1-2（BE）、P1-3c（BE）、P3-2a（BE）、P2-2（update-center（新））、P2-3（update-center（新））
• 批 3（7 張，可同時派）：P1-3b（BE）、P1-4（BE）、P1-5（BE）、P2-4（BE）、P2-6（BE）、P3-2b（BE）、P3-3（FE）
• 批 4（3 張，可同時派）：P1-6（BE）、P3-2c（BE）、P3-4（FE）
• 批 5（4 張，可同時派）：P1-7（BE）、P1-10（BE）、P3-2d（BE）、P4-5（evidence-agent）
• 批 6（2 張，可同時派）：P1-9b（BE）、P4-2（BE）
• 批 7（2 張，可同時派）：P4-3（evidence-agent）、P4-4（FE）
• 批 8（4 張，可同時派）：P5-1（BE）、P5-2（BE）、P5-3（test）、P5-5（BE）

批＝工作坊同時開幾個小弟一起跑的那一組：同批不改同一既有檔、不依賴對方產出。底表 handoff/cards.py 兩個斷言已過。一批全驗完才派下一批。