本卡屬 FR-167（母卡 CM-3241），卡 P1-2，階段 P1 升級變安全、批 2。只改 BE（主 repo，Repo 欄空著）。依賴：P1-1、P1-9a。
升級前的體檢：磁碟夠不夠（包、資料庫複本、映像加保留）、這一版能不能直升（對 release.json 的最低可直升版）、資料庫連不連得上、簽章與雜湊對不對。任何一項不過就列出來、什麼都不動。
預檢是「什麼都不動就擋下」的唯一機會，項目要全
extend：upgrade_check_preconditions 既有檢查搬進 lib/upgrade_preflight.sh 再加項；簽章驗證用 openssl pkeyutl Ed25519 對 /etc/guidant/release-keys/<kid>.pub
repo：~/Projects/Billows/Audit-Manager/compliance-manager-be
改既有：scripts/installer/lib/upgrade_preflight.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 看導覽）；本段只列本卡要做到的點：
install.sh upgrade_check_preconditions 既有檢查搬進 lib/upgrade_preflight.sh（搬不是重寫，diff 看得出來源），原處改一行呼叫。du pgdata×1.2＋映像＋2GB；min_base_version > 現行版就印必經路徑並拒；psql 連線；簽章 openssl pkeyutl -verify -pubin -inkey /etc/guidant/release-keys/<kid>.pub -rawin；雜湊；停機預估＝資料夾大小÷實測複製速率（dd 100MB 量）×3。preflight=ok＋detail（空間、預估）。bats 用假 df／假 du 函式覆寫。bats 用假的 df 與假包：空間不足印需要多少與可清多少、回非零；min_base_version 高於現行版時印路徑並拒絕；改一位元組的 release.json 用 openssl pkeyutl 驗章失敗；全過時進度檔 preflight=ok 含停機預估；shellcheck 綠
測試期（不是你做）：這張卡在 190 的真實情境是「190：空間不足印需要多少與可清多少、回非零不動；從 1.25.1 升需要必經 1.26.0 時印路徑並拒絕」，由首腦在測試期操作、決策者看畫面。你只要確保上面的本機驗收全過、程式對這個情境沒有寫死假設。
對照雛形：~/Projects/Billows/Audit-Manager/compliance-manager-be/docs/features/FR-167-2610-online-update-channel/prototype/index.html（上方「跟著走」）。