§2
結論
整套 CI 的現況（機器、服務、設定、流程、排錯）在獨立文件 出版管線系統說明；本站是 FR-173 的設計決策與過程。
- 發版起點：GitLab BE（或 Agent）專案 → Run pipeline。正式版從受保護 tag 跑，測試包勾
internal_test 從任何 branch 跑。Mac 不用參與。
- 出包時就蓋章：CI 打包完向自架 Vault 要簽名，登記「蓋好章的草稿」，只有 190 看得到；190 試過，回 GitLab 按「發布」，客戶才看得到。原因：客戶端一律拒收沒蓋章的清單，「先裝草稿再蓋章」走不通。
- 更新站多認 GitLab 的 job 身分來按發布（只限 BE／Agent 專案、受保護 tag），不留長效通行碼。
- 測試包：跳過排練、SBOM＋弱掃、Harbor、R2、更新站，用 Vault 測試章簽、直接升 190；主系統約 30 分（不重編約 10 分），正式約 50 分。
- BE、Agent、FE 各一支 CI，都跑在 188 shell runner；BE 觸發 FE；只有 Nuitka 那段 BE、Agent 串行。jedi 套件的 runner 待開。
- 只有決策者按的 pipeline 拿得到章：Vault 角色綁 GitLab
user_id（免費版受保護 tag 不能指定人）。
- 建置期祕密進 Vault，188 上不再落檔。GitLab 免費版：用
id_tokens＋script 內登入 Vault（secrets: 是付費版）。
- Mac 根印章保留當備用。像但不做：雲端 KMS、Sigstore keyless、update-center 與 LC 進管線、客戶主機預設密碼（另案）、推 tag 自動跑。
§4
需求討論紀錄
- 2026-11-01 決策者：「我看一定要我主本機去簽章，我想把這個 secret 放到 gitlab secret 讓他自己去簽有機會嗎？」「release note 以及最小相容版本應該可以放在 CI 前的欄位，Azure 的 SSL 憑證就是放在 key vault。」
- 2026-11-01 首腦：私鑰貼 GitLab 變數是反模式；GitLab 沒有簽章服務；Cloudflare 沒有 KMS（Workers KV 不是金庫）；三條路①update-center Worker 簽②雲端 KMS 換 P-256③自架 Vault。查業界：共識是 KMS／Vault＋OIDC，Sigstore keyless 不適合離線客戶。
- 2026-11-01 決策者：「那就 3 吧」（自架 Vault）。「主系統／agent 的 CI 要分開」「update center 應該是分開跟 LC 狀況一樣，這先不管」。
- 2026-11-01 決策者確認：用 HashiCorp Vault（不是 OpenBao；文件多、內部用 BSL 不受限、日後要換 OpenBao 指令與 API 相同）；GitLab 是免費版，GitLab Secrets Manager（19.5 GA、底層 OpenBao）要 Premium 且不開放簽章，不用；專用 VM 192.168.50.172（Ubuntu 26.04、4 vCPU、15 GB）、apt 裝不用 docker；決策者自己登入照手冊裝，解封鑰匙與 root token 自己保管。
- 2026-11-01 決策者在 172 照手冊架好 Vault；中途手冊兩處寫錯（第 2 段
cd 進 700 目錄失敗導致憑證寫到家目錄、第 9 段先撤 root 才登新帳號導致無 token 可用，靠 generate-root 救回），已修正。帳號名改 jedi。快照與防火牆裁先不做、先開發。
- 2026-11-01 決策者：「那個不能放最後嗎？開發應該不影響吧」「開發跑的期間我會來執行架設，CI 應該是準備出版的最後一步了」→ 排最後，Vault 與 runner 由決策者自架。
§5
文件
以下全部由 build 掃資料夾產生，新增檔案重 build 即自動出現。標題連結指向渲染後的 HTML，md 連向源檔。
說明與手冊
設計
其他文件
交接與收口時間軸（handoff/，2 份）
由新到舊。每份是某一棒次交接當下的完整現況快照，看某個時間點「當時知道什麼」請從這裡進。