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

8 Commits

Author SHA1 Message Date
Leo 6c74b97718 feat(collector): workers-ai 路改吃共用契約——免金鑰預設路的卡跟 BYOK 一樣完整（Arcrun#134） 
InkStoneCo#44 ④ 只修了 gemma BYOK 路（JSON 契約＋wikishape 機械組卡），
免金鑰預設路（多數用戶實際走的）仍吃雲端舊 prompt 的舊格式卡 ⇒ 走預設路
拿到次級知識庫。

修法＝契約單一真相源：wikiExtractPrompt（原 gemmaPrompt 改名，因為它已是
兩條路共用）由 daemon 整段帶上雲（request prompt 欄位），雲端只當執行器回
模型原文（response output），解析（parseWikiExtractJSON）與組卡（BuildWikiDoc）
回到本 package 與 gemma 路同一段程式碼——同形不再靠「兩邊要一起改」的叮嚀。

版本歪斜兩向都有路：舊雲端忽略 prompt 回 card ⇒ fallback 走 legacy 落卡
（#60 前綴／不覆蓋保護原封不動，收端 lint 新舊雙軌）；舊 daemon 不帶 prompt
⇒ 雲端 legacy 行為不變（對向修法在 Arcrun work/extract-wiki-json-0815）。

測試：+2——①request 的 prompt 必須是 wikiExtractPrompt 本人（不是手抄第二份）
②同原稿＋同判斷走兩條路，.wiki/ 產物逐位元組相同（卡＋00-INDEX＋manifest）。
既有兩則（stub 回 card）自動變成舊雲端 fallback 的守衛。go test ./... 全綠。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-15 21:26:30 +08:00
Leo 12c2d41886 feat(collector): daemon 產出改成規範形 wiki 卡——1 文件卡＋N 原子卡落 .wiki/（InkStoneCo#44 ④） 
LLM 只回 JSON 判斷，格式/落點/連結閉合/索引/manifest 全由 wikishape.go 機械組裝：
- 卡形＝frontmatter(tags/gloss/created/updated)＋← 上層＋摘要/重點/實體(帶類型)/
  關聯(內文知識關係/卡片關係/出處)——差距表 #6
- 落點 <節點>/.wiki/、檔名＝H1（.wiki 隱藏目錄自身即機器標記，machinemark 例外③）——#7
- 00-INDEX 機械維護：每行五樣照抄 frontmatter；每份原稿必列——#8
- 萃取端就切 1 hub＋N 原子卡（gemma 路 prompt 改 JSON 契約）——#9
- 無可萃概念標「空」＋理由，上索引不產卡——#10
機械保證對著 wiki-lint.py 寫：斷連結拆殼、index 式句改寫、三元組恰三項、
雙向邊自動補反向、佔用不覆蓋、原稿永不動；同名概念跨文件先消歧（merge 歸第⑤環）。
scan/convert 白名單補 .feature/.yaml/.yml/.org/.rst（規範洞 6）；
lint.go 新舊格式雙軌（workers-ai 雲端 prompt 屬 matrix/arcrun 核心，待開票）；
direct.go 只送文件卡上雲（takedown 配對鍵不變）、下架收走 .wiki 產物。

實測：真資料夾＋真 Gemini → 2 節點 12 卡，wiki-lint 17/17 exit 0，
原稿 sha256 前後不變；go test collector＋supervisor＋arcrun-app 全綠（新增 9 案）。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-15 21:03:45 +08: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
Leo f10d10747c fix(collector): 萃取產物加 vault 辨識＋落卡不再無條件覆蓋（arcrun-rag#60） 
事故：daemon 完全沒有 vault 辨識，把萃取卡片寫進使用者的 Logseq vault
（system-dev/wiki/cards/ 對一般資料夾沒事，對 vault＝憑空多出頁面，
2026-08-10 leo 實撞：25 個簡體字卡片污染 ~/Documents/KB）。

修法（照票上指示搬現成的，不重新設計）：
- collector/vault.go：DetectVaultType/IsVault，判準逐條抄自
  system-dev-template/scripts/install.sh:209-221（先查 logseq/、再查 .obsidian/）。
  已用同一批 fixture 資料夾跑過 install.sh 與這支 Go 版，五種情境（logseq／
  obsidian／一般資料夾／兩者皆有／空資料夾）IS_VAULT 判斷逐一比對一致。
- extract.go：cardsRelDirFor() 依 IsVault 決定卡片相對路徑——非 vault 不變
  （system-dev/wiki/cards/），vault 改落 .arcrun-rag/wiki/cards/（點開頭隱藏
  目錄，Logseq/Obsidian 預設不掃描，跟 daemon 自己 scan.go 的隱藏目錄跳過規則
  一致）。extract_workersai.go／extract_gemma.go／direct.go 的落卡與下架清除
  都改用這個函式，三處對同一個 absRoot 保證同一個答案。
- safewrite.go：safeWriteCard() 取代兩處無條件 os.WriteFile——目標已存在且
  內容不同就先備份成 <dest>.bak-<unixnano> 才覆寫；內容相同則不動（不產生
  垃圾備份）；備份失敗就整個中止，不無聲蓋掉使用者機器上已有的東西。

驗證（見 PR/commit 說明附的實測輸出）：
- 用 fake Logseq vault fixture 重現舊行為（卡片確實落在 system-dev/wiki/cards/），
  再用同一份 fixture 驗新行為（卡片改落 .arcrun-rag/wiki/cards/，vault 根目錄
  非隱藏 .md 數量不變、journals/ 原稿位元不動）。
- 故意放同名既有卡片，跑完既有內容被備份、新內容確實寫入，未無聲遺失。
- 非 vault 既有測試（extract_gemma_test.go 原有三支）全數不動照過，確認
  一般資料夾行為零改變。

範圍外（留給下一輪）：ExtractWithClaude（extract.go 的 claude 路）與其
templatefs/.claude/commands/rag-extract-file.md 技能檔仍硬寫 system-dev/wiki/cards/，
但這條路目前在 direct.go 的 RunDirectOnce 是不支援狀態（cfg.Extractor 只認
workers-ai／gemma），非本次事故的作用路徑，故未動。

不影響：leo 機器上的 daemon（未重啟、未重新打包）；此修復要生效還要
①總管審過併 main ②重新打包桌面版裝上他機器 ③總管用新二進位實測，
三件缺一不可（見 issue #60 leo 的重啟條件）。
 2026-08-11 12:12:51 +08:00
Leo 4d3a6a09a6 v0.18.9：collector 併進同一支執行檔——磁碟上不再攤出第二支 exe 
leo 08-06 裁決：「不要兩支，寫成一支檔案」。

## 為什麼
v0.18.7-8 的「單一 exe」其實是**一支包著另一支**：collector.exe 被 go:embed
進 Arcrun.exe，執行時攤到 ~/.arcrun-rag/bin/ 再跑。
那正是防毒軟體眼中的 dropper 特徵 —— 封測者實撞
`Trojan:Win32/Sabsik.FL.A!ml`，檔案當場被隔離、自動刪除。

⚠️ 誠實界定：`!ml` 結尾＝**機器學習判定**，Sabsik 是最常見的通用誤判家族，
   主因是「未簽章＋下載次數少」，**不是**特別指向 dropper 行為。
   所以本次改動**不保證**解除誤判——真正的解是上架 MS Store（微軟簽章）。
   但「執行時把第二支 PE 寫到磁碟再執行」本來就該拿掉，這是對的方向且順手變小。

## 怎麼做
- `collector/` 39 個檔 `package main` → `package collector`，`main()` → 匯出的 `Run(args) int`
- 新增 `collector/cmd/collector/`（薄殼 CLI，讓單獨跑 collector 這條路仍可用）
- App 直接 import 該套件；`main()` 第一件事就判 `--collector`，是的話走 `collector.Run` 不碰 GUI
- `supervisor` 加 `ArgPrefix`，App 把 `BinPath` 指向 `os.Executable()` 自己
- 刪掉 `bundled_collector_{windows,other}.go`（embed + 攤檔那套）
- 三支打包腳本不再編/複製第二支；版本注入同時打到兩個 package
- build-win.sh 的機械閘改成**直接問它**：`--collector --version` 回得出版本才放行
  （舊閘是比大小，只能證明「有 embed」，證明不了「分派是對的」）

## 驗（真機實跑）
· `.app/Contents/MacOS/` 只有 **一個** 執行檔（原本兩個）
· 跑起來兩個行程是**同一個 exe**：
    …/MacOS/arcrun-app
    …/MacOS/arcrun-app --collector direct --config …
· `~/.arcrun-rag/bin` **不存在**（沒有任何東西被攤出來）
· 端到端：丟檔進看守資料夾 → collector.log `"status":"ingested","http_status":200`
· `lsappinfo` 仍是 `type="UIElement"`、`Version="0.18.9"`
· collector 39 檔測試全過；app 測試過；go vet 全綠；mac + windows 交叉編譯皆過
· 單檔 26MB → 22MB（不再夾帶第二份完整程式）
 2026-08-06 16:00:47 +08:00
Leo 09bf454402 feat(t73): 轉檔層接進主流程——docx 真的走得通（零件完成≠功能完成） 
ExtractWithGemma 讀檔後改走 ConvertToText，LLM 只會收到文字永不收二進位。
刻意不吞錯：ErrNoText(掃描件/空檔) 與 ErrUnsupported(未支援格式) 都往上拋，
因為靜默略過正是 leo 撞到的病。

接線測試 5/5（驗用戶真的會走的那條路，非只測零件）：
  scan 收得到 .docx／收 .md／不收 .png
  ⭐ docx 一路走到 Gemini API 才因假 key 失敗 ＝ 決定性證據：
     轉檔確實發生在送模型之前（非宣稱）
  抽不出文字 → 明確失敗且 errors.Is(ErrNoText) 可判定，不靜默送空卡
  未支援格式 → ErrUnsupported，與 ErrNoText 可區分（給用戶的說法不同）
  .md 迴歸保護：不因接了轉檔層而壞掉

順帶修：變數名與既有 text(LLM 回應) 衝突 → 改 srcText(輸入原稿)，IDE 診斷抓到。
全 collector 測試綠。
 2026-07-27 20:44:29 +08:00
Leo be47afe26e feat(daemon-beta t3/t4): 可插拔本地萃取器——claude 路(叫起用戶訂閱跑 /wiki-capture、stub 驗呼叫契約)＋gemma 路(實戰 prompt/thought 淨化/httptest 替身)；測試 6 支全綠 2026-07-24 12:21:41 +08:00