ltm-setuplisted

# 讓 claude-code-ltm 可用 **分清楚兩件事**，因為它們的成本差三個數量級： | | 誰做 | 成本 | |---|---|---| | 下載 `ltm` binary | **自動**（wrapper 在 MCP server 第一次啟動時做）| 幾秒，3 MB | | 建索引 `ltm build` | **要人同意才跑** | 首次的耗時見下方成本說明；之後自動增量 | 所以「plugin 裝好了卻查不到東西」幾乎一定是第二件事沒做。 ## 先診斷，不要直接跑 build ```bash command -v ltm || ls ~/bin/ltm # ① binary 在嗎 ltm query "test" 2>&1 | head -5 # ② 索引在嗎（錯誤訊息會直說） ``` | 症狀 | 意思 | 做什麼 | |---|---|---| | `ltm` 找不到 | wrapper 還沒跑過，或下載失敗 | 見下方〈binary 沒下載成功〉 | | `索引不存在（…）` | 只差建索引 | 往下走 | | `embedding revision 不同代` / `結構版本不符` / `定址規則不同` | 索引是舊的 | `ltm build --full`，成本同首次 | | 有結果 | 已經可用 | 不用做任何事 | ## 建索引之前先告訴使用者代價 **不要在沒說清楚的情況下啟動它。** 首次全量建索引的耗時**本 repo 沒有量過**， 而它足以讓使用者以為程式壞掉——所以要先講，並讓他自己估。 > **這裡刻意不給任何數字。** 前後改過三次，三次都被驗證推翻：先是「數十分鐘」 > （被實測推翻），再是「實測 2 小時 6 分」（引用的紀錄不含它），再是「觀察到約 > 兩小時」（改引的紀錄同樣不含它，而且那份紀錄自己寫明不支持任何耗時預測）。 > > 本 repo 的誠實邊界要求宣稱要有一份**涵蓋它**的可指名紀錄，而建置耗時目前沒有 > 那樣一份。**與其再猜一個，不如讓使用者自己量**——下面第 1 點就是那個做法。 先讓使用者知道這三件事，再問要不要現在跑： 1. **要跑多久**取決於他的語料大小——先報數字，別讓他自己猜： ```bash find ~/.claude/projects -name '*.jsonl' | wc -l du -sh ~/.claude/projects ``` 2. **全程在本機**，不連外。 3. **只有第一次要等**：之後每次查詢會自動併入新內容（`refreshIncrementally`）， 不必再手動跑。 ## 跑 ```bash ltm build ``` 跑得久，**放背景**，不要讓它把整個 session 卡住： ```bash ltm build 2> ~/.claude-ltm/build.log & ``` `ltm build` 把進度寫 **stderr**（stdout 留給最終報告），所以導到檔案再定期 `tail` 它就有真的進度可以回報——不要從外面用 `ps` 或檔案大小去猜。行的種類 **以下表為準，數字刻意不寫**——這個數字已經錯過兩次（先寫「三種」而實際四種， #44 R2 verify；#48 加了掃描心跳後「四種」又過期）。一個被複述的數字就是一份會 漂移的規格；表與 enum 的對應由 `ProgressDocS