這張卡做什麼（白話）

做「一次性建庫容器」：客戶裝機時，installer 起一個專用容器跑 T-2.1/T-2.2 的建庫腳本，跑完就退場，之後才起正式服務。這樣設計的核心理由是最小權限：最高權限帳號（cmmgr）的密碼只存在建庫那一刻，正式服務容器從頭到尾只拿低權限（cm_app）憑證。這個容器形態同時是升級時套 migration 的載體（T-3.4 共用）。

• 母案 CM-1189：https://app.notion.com/p/FR-065-Installer-3bc346da4cd081c4abf3ce74a28ba384
• 所屬子需求卡 CM-1244：https://app.notion.com/p/FR-065-2-bundle-3be346da4cd08103adb2e1803cf7b42c
• 設計文件：docs/features/FR-065-2608-onprem-installer/design.md §4.4（D4：one-shot init 容器）

具體實作內容

• one-shot init 容器：內含 psql client＋scripts/init/ 腳本組；entrypoint 跑 init.sh
• 流程契約：installer 產參數（cmmgr/cm_app 兩組密碼）→ 以環境變數/secret 注入 init 容器 → 跑 init.sh（連 guidant-db）→ exit 0 才繼續起服務容器
• 服務容器全程只持 cm_app 憑證；cmmgr 憑證不落 guidant.env 服務段（installer 端管理）
• 失敗語意＝整庫重建可重來（init 場景可接受，配合 T-2.1 冪等 marker）
• 與升級 migration 容器共用同一形態（D4/D5）：同 image、不同 entrypoint 參數——設計時預留升級模式介面（T-3.4 接手）

易踩雷提醒

• 別走「服務容器 entrypoint 自動 init」路線——那要服務長期持有 cmmgr 憑證，違反最小權限（D4 明確排除的 C 案）
• init 容器退出碼必須可靠：非 0 時 installer 要擋下不起服務
• 密碼經環境變數注入時注意不要進 docker logs／inspect 可見面（實作時評估 secret 掛檔）

驗收條件

• 服務容器全程只持 cm_app 憑證（檢查 compose env 與容器內實際變數）
• init 失敗後可整庫重建重來（重跑驗證）

依賴

• 前置：T-2.1（CM-1252：https://app.notion.com/p/FR-065-T-2-1-SQL-schema-RLS-3be346da4cd081999aa9fb2b1cd7432f）