← 程式碼對照

cli/cli.c — 安裝與設定層

install/uninstall/update/config、43 個 client surface、hook 安裝
檔案：src/cli/cli.c（11,928 行）· cli.h

大方向

cli.c 是「安裝體驗」的所在。它做的事包括：install（下載/驗證/啟動）、uninstall、update（印出重跑 install.sh 的指令）、config（設定讀寫）、以及把 CBM 設定進 43 個 coding agent（Claude Code、Codex、OpenCode、Cursor、Gemini CLI…）。

1. 安裝 / 更新 / 移除

cbm_cmd_install / cbm_cmd_update / cbm_cmd_uninstall cli.c安裝生命週期的三個子指令。

更新刻意不做「in-process updater」——因為那結構上是「下載 + 解壓 + 標記執行 + 執行」，正是防毒軟體最警戒的 dropper 行為。所以 update 只驗證旗標、印出「重跑 install.sh」的指令，由外部指令碼完成實際替換（install.sh 是 idempotent，重跑就是更新）。

教學重點：安全設計 > 便利——這個決定換掉了「內建自動更新」換來「二進位裡沒有下載器特徵」。Windows 上更是硬性需求（執行中的 exe 無法自我替換）。

2. 43 個 agent 平台

agent 設定安裝 cli.c偵測已裝的 agent，寫入 MCP 設定 + 指令/skill/hook。

37 個自動偵測 + 6 個 conditional/explicit（有已存在的 config 路徑才寫）。每個平台寫入：MCP config、durable context（AGENTS.md / GEMINI.md 等）、skill、以及對應的 hooks。設計原則是絕不亂開實驗性 flag、不啟用 plugin、不信任第三方指令。

3. 三層 agent profile

Scout / Verify / Auditor cli.c為支援自訂 agent 的平台建立三個圖查詢 agent。

從一份 canonical contract 產生三層定義：

  • Scout（Tier 1）：3–4 個窄呼叫，快速試探性發現，不做 absence/impact/dead-code 聲稱。
  • Verify（Tier 2，預設）：任務導向的圖證據 + 精確原始碼檢查 + 引用路徑涵蓋。
  • Auditor（Tier 3）：受限範圍、完整分頁、更廣的關係檢查、明確的未解限制。

每層都批次呼叫 check_index_coverage 檢查證據路徑——clean 只代表「沒有記錄缺口」。

4. config 子指令

config set/get/list/reset cli.c讀寫 runtime 設定（auto_index、auto_watch、auto_index_limit…）。

設定存在 ${CBM_CACHE_DIR}/_config.db（SQLite）。例：config set auto_index true 讓新專案首次連線自動索引；auto_watch false 關掉背景 watcher 註冊。

看完這頁你應該能說出：為什麼 CBM 不用 in-process updater、43 個平台是「偵測 + conditional」而非全寫、Scout/Verify/Auditor 三層的職責差異、以及 config 存哪、auto_index 是做什麼。