本卡屬 FR-167（母卡 CM-3241），卡 P1-6，階段 P1 升級變安全、批 4。只改 BE（主 repo，Repo 欄空著）。依賴：P1-4。
複本升級完後：用複本起新版 api／worker，健康檢查過（含實打登入與主要 API）才「換接」——複本轉正、原本那份改名留作快照，最後才重建前端容器讓維護頁撐到最後一刻。
不可退回點前最後一道門；換接順序決定維護頁能撐到最後
extend：health reuse 既有 180 秒 healthcheck 加實打；switch 把現有 upgrade_switch_version 改成「先換 api／worker、最後 fe」
repo：~/Projects/Billows/Audit-Manager/compliance-manager-be
改既有：scripts/installer/lib/upgrade_health.sh（P1-1 空殼）
改既有：scripts/installer/lib/upgrade_switch.sh（P1-1 空殼）
細節在 design.md §5 對應段（~/Projects/Billows/Audit-Manager/compliance-manager-be/docs/features/FR-167-2610-online-update-channel/design.md，開 design.html 看導覽）；本段只列本卡要做到的點：
lib/upgrade_health.sh：GUIDANT_PGDATA_DIR=pgdata-next docker compose up -d api worker socketio（fe 不動）→ reuse 既有 180 秒 healthcheck 迴圈 → curl 登入、/api/1.0/version、三支主要 GET；5 分上限。lib/upgrade_switch.sh：既有 upgrade_switch_version 邏輯搬進來改成：mv pgdata pgdata-prev-<舊版>、mv pgdata-next pgdata、寫 GUIDANT_VERSION、最後 up -d fe；進度檔 succeeded。本機 docker：health 對一個回 500 的假 api 容器 → 非零不換接；對回 200 的假容器 → 過；switch 對假目錄：複本轉正、原份改名 pgdata-prev-<版> 且 mtime 不變；compose 啟動順序 api／worker 先、fe 最後（看 runner 寫的進度檔步驟時間）；shellcheck 綠
測試期（不是你做）：這張卡在 190 的真實情境是「190：故意讓登入 API 壞掉 → 不換接；換接後 pgdata/ 是原複本、pgdata-prev-<舊版>/ 是原本那份且 mtime 不變；維護頁撐到 fe 重建前一刻」，由首腦在測試期操作、決策者看畫面。你只要確保上面的本機驗收全過、程式對這個情境沒有寫死假設。
對照雛形：~/Projects/Billows/Audit-Manager/compliance-manager-be/docs/features/FR-167-2610-online-update-channel/prototype/index.html（上方「跟著走」）。