 Leo
|
577d883e94
|
fix(collector): 收檔策略改看資料夾裝了什麼，不看有沒有版控（arcrun-rag#104 第二層）
leo 2026-08-16：「你不需要判斷有沒有 git，我的 KB 筆記庫也有 git，
是否用 github/gitea 追蹤完全沒意義。」
第一層（80aed82）已把「哪些目錄算雜訊」改成不看版控；本輪處理
「這個資料夾整體該用哪種收法」（all／curated-wiki／docs-only）那一層。
定時炸彈（實測，非推測）：`~/Documents/KB` 是 leo 的真知識庫，今天沒有
`.git` ⇒ all ⇒ 全收；而它**真的有 system-dev/wiki**（他在筆記庫裡也裝過
template）⇒ 只要有人跑一次 `git init`，就翻成 curated-wiki，靜默塌成十幾張。
新判準（collector/foldershape.go）：三條同時成立才算軟體專案——
① 找得到專案檔 ② 原始碼 ≥ 20 ③ 原始碼 × 4 ≥ 文件數。三條都不看版控。
第③條擋的是「筆記庫裡放了一整份下載回來的範例專案」。
實測分得很開：KB＝0/15/5915（筆記庫）｜InkStoneCo＝213/3355/6115（專案）
｜pms＝21/37/22（專案）。InkStoneCo 與 pms 的模式都不變。
判準換成內容，證據也換成內容：`IngestPlan.RepoRoot`（.git 在哪）改成
`IngestPlan.Shape`（實測形狀），Reason 句子改成「我看到 go.mod 等專案檔，
還有 3,355 個原始碼檔」——使用者看得出憑什麼那樣判。
- 既有那條迴歸測試就地擴充到涵蓋模式選擇（不另開平行的一條），
判準升成「同一棵樹有無版控，收到的檔案集合必須一模一樣」
- 加上三種收法各自仍正確、筆記庫有像產物的資料夾與零星腳本不准翻成專案、
理由裡不准再出現版控字眼、以及「ingestplan.go 不准再引用 DetectRepoRoot」
的接線測試（反面同時釘住 #105 在 tidy.go 的正當用途不准被順手拆掉）
- collector/probe_real_manual_test.go：唯讀探針，留著給下一個人重量存量影響
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-16 23:26:52 +08:00 |
|