本卡屬 FR-167（母卡 CM-3241），卡 P2-6，階段 P2 更新站、批 3。只改 BE（主 repo，Repo 欄空著）。依賴：P1-1、P2-3。
客戶主機要有我們的公鑰才能驗發布清單。這張卡把 DEV 公鑰檔放進安裝包、新裝與升級都裝到 /etc/guidant/release-keys/，換印章時新公鑰跟著包進來、舊的保留。PROD 公鑰與「缺了就不准出包」留給結案卡。
印樣是客戶端信任的根，裝錯整條驗章失效
extend：填 lib/release_keys.sh；有什麼 .pub 就裝什麼；「PROD 鑰缺就紅」的守門不在這張做（決策者尚未 init-keys），P5-5 補
repo：~/Projects/Billows/Audit-Manager/compliance-manager-be
改既有：scripts/installer/lib/release_keys.sh（P1-1 空殼）
新開：scripts/installer/release-keys/<dev-kid>.pub（用 P2-3 的 CLI 產一組 DEV 鑰，私鑰留本機 600、不入 repo）
細節在 design.md §5 對應段（~/Projects/Billows/Audit-Manager/compliance-manager-be/docs/features/FR-167-2610-online-update-channel/design.md，開 design.html 看導覽）；本段只列本卡要做到的點：
scripts/installer/release-keys/<dev-kid>.pub：用 P2-3 的 guidant-release init-keys 產一組 DEV（私鑰留本機、不入 repo、kid 寫在檔名）。lib/release_keys.sh：install_release_keys <包根> <目標根>：把包內 release-keys/*.pub 複製到 /etc/guidant/release-keys/（644、不覆蓋同名、不刪舊）；verify_release_json <release.json> <sig> <kid> 給 P1-2／self_replace 用。install.sh 新裝路徑與 upgrade 都呼叫。bats：對暫存 root 跑 release_keys.sh → 目錄有檔、權限 644；包內多一把新 kid 時裝完多一把、舊的保留；私鑰 grep 不到進 repo；shellcheck 綠
測試期（不是你做）：這張卡在 190 的真實情境是「190：新裝後 /etc/guidant/release-keys/ 有檔 644；升級包帶新 kid 時裝完多一把、舊的保留」，由首腦在測試期操作、決策者看畫面。你只要確保上面的本機驗收全過、程式對這個情境沒有寫死假設。
對照雛形：~/Projects/Billows/Audit-Manager/compliance-manager-be/docs/features/FR-167-2610-online-update-channel/prototype/index.html（上方「跟著走」）。