本卡屬 FR-167（母卡 CM-3241），卡 P1-9a，階段 P1 升級變安全、批 1。只改 BE（主 repo，Repo 欄空著）。依賴：無。

這張卡做什麼（白話）

出包時順便產一份 release.json（版號、主版號、雜湊、大小、最低可直升版、有沒有安全修正），還沒簽章，之後決策者在自己電腦蓋章。最低可直升版不用人算，從 migration 清單的「必經」標記自動算。

為什麼切這一張

release.json 是更新站、CLI、BE 三邊共同契約，先定

reuse／extend／new

extend：build_bundle.sh 的 bundle-info 段加 release.json；必經標記讀 scripts/sql/manifest.tsv 新欄（D17 三種情況由人標、腳本算）

在哪裡

repo：~/Projects/Billows/Audit-Manager/compliance-manager-be
改既有：scripts/build/build_bundle.sh 408–430
改既有：scripts/sql/manifest.tsv（加 min_base 欄說明列）
新開：scripts/build/release_json.sh

怎麼做

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

• scripts/build/release_json.sh <bundle目錄>：讀 VERSION、算 tar.gz sha256 與大小、主版號取第一段、has_security_fix 讀環境變數 RELEASE_HAS_SECURITY_FIX（預設 false）、issued_at 留空（決策者 publish 時填）。
• min_base_version：scripts/sql/manifest.tsv 加第五欄 min_base（空＝無；值＝該支 migration 所屬版號，代表「必經」），腳本取最大的那個；沒有就 1.0.0。在 manifest 檔頭註解寫清楚 D17 三種情況才標。
• build_bundle.sh 408–430 的 bundle-info 段加一行呼叫；bundle-info.txt 的「1.0.0 以上」改印算出來的值；包內 agent/ 放 Agent compose 交付包（grep build 鏈現有 agent 包落點，reuse）。
• 本機用一個假 bundle 目錄（幾個小檔）跑通；不在 188 出包。

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

本機對一個假的 bundle 目錄跑 release_json.sh：欄位齊、sha256 與 .sha256 檔一致；manifest.tsv 標一支必經後 min_base_version 變那版、沒標時是 1.0.0；bundle-info.txt 的「1.0.0 以上」改成算出來的值；shellcheck 綠。不在 188 出包

測試期（不是你做）：這張卡在 190 的真實情境是「188 跑 build_bundle 後包內有 release.json，sha256 與 .sha256 檔一致，包內有 Agent compose 交付包」，由首腦在測試期操作、決策者看畫面。你只要確保上面的本機驗收全過、程式對這個情境沒有寫死假設。

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

紀律