inkstone/arcrun-collector
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 14 Wiki Activity
187 Commits 2 Branches 14 Tags
main
Commit Graph

4 Commits

Author SHA1 Message Date
Leo ef5fe1df6f sync: collector/ 同步自 inkstone/arcrun-rag@4982b50（桌面小幫手 0.18.43） 2026-08-28 01:48:25 +08:00
Claude 129fe79ecb fix(collector): daemon 不再改用戶版控中的檔案，接 repo 只讀整理好的 wiki（#105／#104） 
## #105 daemon 會改用戶的檔案（不可逆，先修）

2026-08-14 21:45 實撞：InkStoneCo 在看守清單裡，daemon 回報「已把 1 張舊卡片歸位」，
實際把 system-dev/wiki/cards/autonomy/ 整個子目錄壓平改名，16 個版控中的檔案變成刪除。

真兇是 MigrateCardNames 的一句假設：「那兩個目錄從頭到尾只有 daemon 會寫」。
那句話在 vault 上成立，在 repo 上不成立——system-dev/wiki/cards/ 是 template 的規約
路徑，而 template 就是要裝進開發者自己的 repo，那裡本來就有人家自己的檔案。

- 新增 repoguard.go：`.git` 判準（含 linked worktree），與 #104 共用同一個判準源
- 版控中的資料夾一個檔都不自動動；改成記帳＋講給使用者聽，出口是 collector tidy --apply
- Blocked 只算「確定是我們寫的」（帶 arcrun- 標記）——報使用者自己的卡等於發假訊息
- 落卡與工作區改走 .arcrun-rag/（與 vault 同待遇），自帶 .gitignore(*) 讓它對 git 隱形
- 非版控資料夾（含 vault）行為與 #60 第三輪完全一致，不推翻前兩輪的成果

## #104 接上開發 repo 會把上萬個原始檔排進佇列

leo 的規格：「它要辨識這個庫已經有 wiki，那就直接 ingest 了」「只有文件要讀，程式碼不用讀」。

- 新增 ingestplan.go：掃描前先問「這個資料夾是什麼」——all／curated-wiki／docs-only
- 排除靠路徑身分不靠副檔名：依賴、建置產物、templatefs 範本、linked worktree、巢狀子 repo
- 策略與擋掉的數字經 TriggerPayload.Plan 走進 status.json，CLI 走 stderr（排除規則要看得見）
- 子專案自己的 wiki 刻意不收，但一定列出來讓使用者知道去哪裡找
- 與 TemplateOwns（把 system-dev/ 整棵當開發用的）的對撞用身分化解，不拿掉任一條：
  我們代裝的資料夾沒有 .git（舊規則照舊），他自己的 repo 有（收那份 wiki）

## 實測

#105：舊版 daemon 對真 repo 跑一輪 → git status 32 行（16 個 D ＋ 16 個 ??，與 21:45
      撞到的一字不差）；新版跑同一輪 → 0 行。另有真 git init 的端到端測試。
#104：造出 leo 那棵樹的形狀（InkStoneCo ＋ products/arcrun-rag ＋ 3 份出貨 worktree，
      967 個文件檔）→ 舊版送 91 個檔（多收的全是 -wt*ship/ 裡的 templatefs 範本、
      benchmark 結果、docs-site 產物），新版送 32 個，全部落在 system-dev/wiki/ 底下。

MachineMark 規約新增唯一例外 IsMachineOwnedRel：.arcrun-rag/ 底下的檔以目錄名為標記
（.gitignore 的檔名是 git 定的，改不得）。迴歸網判準同步換過去。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UUwsLkFEGN8496bZTqhjFq
 2026-08-14 14:41:08 +00:00
Leo 2f33324d3f fix(collector): #60 監看的是筆記庫底下的子資料夾時，保護整個失效 
真正的根因不是「vault 判斷漏了子庫」，是**判斷的方向搞反了**：
前兩輪問的都是「監看根**這一層**是不是 vault」，但 daemon 的產物一律落在
監看根底下——這兩件事只有在「監看根 == 庫根」時才等價，而那正好是前兩輪
唯一測過、也唯一不會出事的擺法。

使用者只要把庫底下的某一層加進監看（`KB/docs`、`KB/pages`、Obsidian 庫裡的
某個專案夾——很自然的用法），DetectVaultType 就回 VaultNone，整套保護退回
一般資料夾模式，卡片落在 `<監看根>/system-dev/wiki/cards/`：那個路徑就在
使用者的 graph 裡面，而且看得見，Logseq/Obsidian 每一張卡都收編成一頁。
前綴（第二輪）只擋得住撞名，擋不住「多出一堆機器頁」。

改法：把「這一層是不是庫」與「我寫的東西會不會落進誰的庫」拆成兩個判準。

- vault.go：新增 DetectVaultContext（往上找到最近的庫根）與 VaultDirUnder
  （往下擋：寫入目標會不會踩進子庫）。DetectVaultType 一字未改，繼續與
  install.sh 對齊——往上找用較嚴的判準（logseq/ 要有 config.edn 或
  journals//pages/ 佐證），因為那是替使用者猜、而且一次猜好幾層。
  停在家目錄與檔案系統根，避免 `~/logseq` 這種常見資料夾把整個家目錄判成庫。
- extract.go：cardsRelDirFor 改用 DetectVaultContext。
- safewrite.go：落卡前過 ensureWritable 機械閘——目標踩進子庫就中止，
  不靜靜寫進去。今天不會觸發，它防的是以後新增的寫檔點。
- tidy.go：收拾判準從「有沒有帶標記」擴充成「位置對不對 ＋ 有沒有帶標記」，
  舊版留在看得見位置的卡會被搬進隱藏目錄；MigrateCardNames 每輪自動做，
  使用者不必下任何指令。報告多一個 VaultRoot，說清楚是誰的庫。

leo 派工單上的線索（庫在監看根**底下**）實測不成立：產物一律錨在監看根，
不會落進子庫。但那個「本來就沒破」原本沒有任何機制保證，所以照樣把兩種
格式的子庫情境永久寫進測試，加上 ensureWritable 當第二道保險。

驗證缺口（票上第 6 條）：第二輪的足跡測試方向是對的，漏的是**觀測窗**——
snapshotTree 只拍監看根，而災情發生在監看根外面、庫裡面；且 fixture 只有
`root := vault` 一種擺法，測試與被測程式犯了同一個假設，所以永遠是綠的。
vault_subdir_test.go 把快照邊界改成筆記庫，並把「監看根與庫根的關係」升格
成測試維度（庫在上／庫在下／庫就是它／沒有庫 × Logseq/Obsidian）。

全程只用 t.TempDir() 與 mktemp -d；沒碰任何真實筆記庫、沒重啟任何 daemon。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-12 18:23:49 +08:00
Leo 5a140faf1f fix(collector): 機器寫進筆記庫的檔案一律帶前綴，不再跟使用者的頁面撞名（arcrun-rag#60） 
leo 2026-08-12：「我的 Logseq 又被覆蓋⋯⋯**不只是加上 journal，可能所有的檔案都加一個前後綴，比如「wiki」**。」

不是資料被蓋掉，是機器產出用了跟他一樣的命名空間（status.md、日期檔那些）
⇒ 他打開資料夾分不出哪些是自己的。**心理上的覆蓋跟實際覆蓋一樣糟。**
 2026-08-12 14:57:32 +08:00