本卡屬 FR-167（母卡 CM-3241），卡 P3-2d，階段 P3 更新中心、批 5。只改 BE（主 repo，Repo 欄空著）。依賴：P3-2c、P2-1。

這張卡做什麼（白話）

客戶版本太舊要經過必經版本時，更新站回一條路徑（例如先到 1.26.0 再到 1.27.0），主系統把兩包都下好，更新單帶序列，主機逐段跑，每段各自複本與健康檢查；第二段失敗就停在中間版可用。

為什麼切這一張

多段串接，邊界在「第二段失敗停哪」

reuse／extend／new

extend：check 回應的 path[] 由更新站算；BE 下載迴圈；lib/upgrade_order.sh 讀序列逐段呼叫 runner

在哪裡

repo：~/Projects/Billows/Audit-Manager/compliance-manager-be
改既有：app/product_update/service/product_update_app_service.py
改既有：app/product_update/service/package_downloader.py
改既有：scripts/installer/lib/upgrade_order.sh

怎麼做

細節在 design.md §5 對應段（~/Projects/Billows/Audit-Manager/compliance-manager-be/docs/features/FR-167-2610-online-update-channel/design.md，開 design.html 看導覽）；本段只列本卡要做到的點：

• 更新站（P2-1 已回 path[]）；BE package_downloader 迴圈下載每段並各自驗；product_update_jobs.path 存序列；更新單 path[]。
• lib/upgrade_order.sh 讀序列逐段呼叫 runner（每段各自複本與健康檢查）；第二段失敗停在中間版、進度檔記哪段失敗。單段行為不變（既有 test 綠）。

怎麼驗（開發期：你在本機／DEV 就要能做完）

DEV 8003 對本機 wrangler dev：更新站標一版必經 → check 回 path[] 兩段、BE 兩包都下、更新單帶序列；upgrade_order.sh --dry-run 逐段呼叫 runner（看 log 兩次）；單段情境行為不變（既有 test 綠）

測試期（不是你做）：這張卡在 190 的真實情境是「190：1.25.1 裝機、1.26.0 標必經 → 兩包都下、兩段跑完；第二段 kill → 停在 1.26.0 可用」，由首腦在測試期操作、決策者看畫面。你只要確保上面的本機驗收全過、程式對這個情境沒有寫死假設。

對照雛形：~/Projects/Billows/Audit-Manager/compliance-manager-be/docs/features/FR-167-2610-online-update-channel/prototype/index.html（上方「跟著走」）。

紀律

• 🔴 這張卡的驗收只寫你在本機／DEV 就能做完的事（開發期無人盯）。要 190 主機、跑 pipeline、真 Cloudflare 部署、PROD 印章的情境不在你這張卡，那是測試期首腦做。卡上「怎麼驗」列的每一條你都要親手跑過、把結果貼回寫；做不到的寫明做不到，不要為了驗而去碰 190／STG／POC／真帳號部署。
• 🔴 不重複造輪子：寫任何新函式／元件／service 之前先按行為 grep 真實程式碼，再查 docs/claude/domain-capabilities.md。三擇一、預設不新增：reuse → extend 加參數 → 都沒有才新增。回寫列出 reuse 了哪些、新增了哪些、為什麼不能 reuse。