inkstone/arcrun-collector
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 15 Wiki Activity
172 Commits 2 Branches 15 Tags
ac01dd5e7bf411d255cab4e7dde2b01983ff77fa
Commit Graph

8 Commits

Author SHA1 Message Date
Leo febc6708ef WIP(#44 ⑦⑩)：關聯段擷取式不再被 H3 打斷；改名/搬移偵測施工中 
⑦（總管已複驗）：雲端 parse_card 的邊界正規式 lookahead 是 \n#，
會停在「## 關聯」底下第一個 ### 之前。而規範形卡（ef5e6c5）正是
### 內文知識關係 開頭 ⇒ 除機械補的 part_of 外，關係一條都收不到。
agent 對 youlin 實際部署的 rag_ingest_card POST 真卡：卡上 4 條／落地 1 條。
改成只認下一個 H1/H2 後離線重跑同一段 JS：解析出 4 條。
併同重編 installer 兩份 precompiled workflows（只改 yaml 不重編＝新用戶拿不到）。

⑩（施工中）：direct.go／manifest.go 的改名搬移下架，尚未驗收。

🔴 尚未送達：這一版還沒部署到 youlin，live after 數字還沒拿到。
不得標 ✅。出貨 CP 步驟①。

未納入本次 commit：collector/cmd/arcrun-app/arcrun-app（20MB 編譯產物）
與兩個探針目錄——那是驗證用的臨時物，不該跟修法一起進版控。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-16 13:13:59 +08:00
Leo f233eec9c2 feat(collector): 結構先行——掃描完幾秒內就能問「資料夾裡有什麼」，不等 LLM 不等額度（InkStoneCo#43） 
leo 08-15 量測：266 檔真正算的 ~20 分鐘／<$0.5，使用者卻等 ~4 天（多在等
Workers AI 每日額度）；而「有哪些檔案／最近改了什麼」本地掃一遍就有答案
（1,335 檔實測 0.254s），卻因 part_of 只在雲端 parse_card（萃取之後）生成
而排同一條隊、撞同一面額度牆。

- collector/inventory.go：Scan() 後、萃取迴圈前（額度冷卻閘之外），把 manifest
  現況做成機械總覽卡（檔案清單／最近改動／目錄 part_of）POST 既有 rag_ingest_card
  ——零 LLM、零新 workflow、既有實例直接受益；自帶同頁名 upsert 防重複
- 冪等：內容 sha256 記 manifest.inventory_hash；失敗 10 分鐘退避（防 t195 同款
  每 5 秒重撞）；額度失敗訊息人話化，不裸露 4006/502
- 清單 ≤200 逐檔、關聯 ≤10 條：守 Workers 免費層 50 subrequests 天花板
- 不寫本機檔案、不動使用者原稿

實測（youlin stage yuga3bse，刻意無金鑰＝零萃取）：總覽卡 200 送達、rag_chat
正確回答「有哪些檔案／最近改了什麼」；重掃不重複（blocks 恆 5、triplets 恆 2）；
go test collector＋supervisor＋arcrun-app 全綠（新增 inventory_test.go 6 案）。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-15 16:39:45 +08:00
Leo c7675a10a0 不再把開發用 template 塞進使用者資料夾；上游錯誤不再被退避訊息吞掉 
## leo 三條裁決，逐條落實
① 「**別人的錯誤一律要顯示給用戶看，不然就會變成我的錯誤，導致客服**」
   → manifest entry 新增 `LastError`（存**原文**），退避訊息改成
     「上次失敗（第 N 次），58m 後重試｜**原因：**<上游原文>」。
     成功後清空，不留舊錯誤嚇人。
     測試 `TestUpstreamErrorSurvivesBackoff` 從上游錯誤字串出發，
     驗它活到給使用者看的那句話；反向驗證拿掉即紅。

② 「**拿來開發一般人用不到的根本別安裝**」
   → daemon 不再代裝 system-dev template（`CLAUDE.md`／`scripts/`／`system-dev/`，37 檔）。
     兩層傷害：把人家資料夾弄亂 ＋ 那些檔被當知識吃進去
     ⇒ 知識庫長出 `kb`／`t195-watch` 這種不是使用者內容的庫（leo 實撞）。
     `template-install` 子命令保留，開發者情境不受影響。

③ 「**它也不能只看隱藏檔內，因為 template 在我所有的 repo 裡不是隱藏的**」
   → 排除規則用**路徑身分**（`TemplateOwns()`，來源是內嵌 templatefs 的實際路徑
     ＋ `system-dev/`・`scripts/` 目錄前綴），**不是**「有沒有以點開頭」。
     測試刻意把 template 檔放成**不隱藏**（就像 leo 的 repo），驗它仍被排除；反向驗證即紅。
     這些檔也不計進「有 N 個檔案沒有被整理」——那欄是給使用者看他自己的檔案的。

## 順帶修 leo 截圖上的重複
「有 2 個檔案沒有被整理」底下 `scripts/sdd-active-check.sh` 出現兩次
——多帳號時同一個資料夾被掃多輪、每輪都 append。已去重。

## 殘項（誠實）
App 端失敗卡還沒接上這條線 ⇒ **畫面尚未真的顯示原因**。未打包、未送達。
 2026-08-06 21:33:37 +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 47580f4ba5 t195：失敗重試加指數退避＋上限——一個壞檔不再拖住整個資料夾 
leo 2026-08-05：「有封測者在等，一直出錯」「已經等了幾天了」

## 病（leo 實撞，log 實證）
`小果被AFTEE詐貸.pdf` 雲端 401 失敗後，**manifest 完全不記失敗**
⇒ 下輪掃描又當「新檔」⇒ **1387 輪、跨 11 小時**，每輪 3.2~3.8 秒全在撞同一面牆；
且它排在佇列前面 ⇒ **整個資料夾的同步被一個壞檔拖住**。
leo：「原先萃檔案速度也快，現在花了十幾分才萃完」——**萃取沒變慢，慢的是重試**
（log 的 `FOREACH 所有 5 項目均失敗` 證明卡早就萃好了）。

**這是獨立於 401 的架構缺陷**：401 修好了，下次換別的錯照樣卡死。

## 修
· ManifestEntry 加 FailCount / LastFailAt / NextRetry
· MarkFailed()：退避階梯 1m→5m→15m→1h→6h（之後維持 6h）
· ShouldRetry()：退避窗口內跳過；連續失敗 8 次暫停自動重試
  force（使用者按「立刻同步」）忽略退避與上限——**人明確要求不該被機器擋住**
· MarkIngestedBy() 成功時清空失敗狀態（下次再壞從第一階重算）
· direct.go 三個失敗出口都記退避（讀檔失敗／萃取失敗／上傳失敗）
· retrySkipReason()：跳過時說人話，不靜默（同 t195 燈號誠實原則）

## 🔴 真兇其實有兩層——第二層才是關鍵
只加退避欄位**沒有用**：`scan.go` 每輪都**重建** ManifestEntry，
原本只 carry IngestedHash/IngestedAt ⇒ 我寫進去的 fail_count 下一輪就被抹掉
⇒ 退避永遠停在「第 1 次失敗」＝等同沒有退避。
（順帶發現 ExtractedBy(t73「誰萃的」)原本也一直悄悄丟失。）
⇒ scan.go carry 補齊四個欄位，並留註解：**日後新增跨輪欄位必須加在這裡**。

## 驗（真實跑，非只有單元測試）
單元測試 6 項全過（退避窗口／指數遞增 60/300/900/3600/21600/21600／
上限停止／force 忽略／成功清空／壞檔不連累同輪其他檔）
實跑（cypher_url 指向不存在主機製造必失敗）：
  第 1 輪 failed
  第 2 輪 skipped「上次失敗（第 1 次），1m0s 後重試」
  第 3 輪 skipped（同上）
  第 4 輪 skipped（同上）
  模擬退避到期 → 確實重送、fail_count=2、退避升為 300s ✅
go test ./... 全綠；go vet 通過。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-05 14:46:03 +08:00
Leo a50cc37949 feat(t73): manifest 記錄 extracted_by——換萃取器時才分辨得出哪些卡是舊的 
leo 07-27 三問查證後補的缺口。查證結果（已用測試釘死，下次不必再讀碼推論）：
① 已萃過它知道嗎 → 知道。ingested_hash vs content_hash，相同就跳過；
   只有 2xx 成功才回寫(direct.go:405)，失敗下輪自動重試不漏檔。
② gemma 會重萃 claude 萃過的嗎 → 不會重萃(hash 相同)，但原本**分辨不出誰萃的**
   ＝換萃取器後兩種品質的卡混在同一知識庫，想重萃也不知該重萃哪些。← 這次補的
③ 誰負責萃 → cfg.Extractor 一個資料夾一個設定(direct.go:346)，無自動判斷。

做法（純記錄不改行為、可逆，故自裁）：
- ManifestEntry 加 ExtractedBy(omitempty)
- 另開 MarkIngestedBy 而非改 MarkIngested 簽名——後者有多處呼叫(direct 兩處+
  trigger.go MarkIngestedEvents+測試)，改簽名會擴散破壞

測試 7/7：萃過不重萃／改了要重萃／失敗下輪重試／記得誰萃的／
舊簽名仍可用／舊 manifest 讀得進來且空值不污染 JSON／有值真的存進檔案。

未做(屬品味題待 leo 裁)：B 自動偵測有無 claude 優先用用戶訂閱、C ChatGPT 路。
 2026-07-27 20:58:30 +08:00
Leo fdb7a67484 feat(ingest-hash-trigger): collector R2 content-addressed 原稿上傳（SDD task 3） 
- collector upload 子命令＝scan＋把 added/modified 原稿傳 R2（CF REST API
  Bearer token，key=raw/<sha256hex>，對齊 collector-trigger.v1 的 r2_key）
- 冪等：存在檢查命中＝skipped_exists 不 PUT；CF API objects 端點不支援
  HEAD（live 實測 405）→ 改 GET＋Range: bytes=0-0
- 完整性：上傳前重算 hash 核對 key，不符＝failed 不上傳
- 失敗語意：failed → exit 1，ingested_hash 不動＝下輪自動重試；
  回寫鉤子 Manifest.MarkIngested 留給 task 4
- 設定只走環境變數 CF_ACCOUNT_ID/CF_API_TOKEN/R2_BUCKET，不落 repo
- go test 14/14 綠（httptest mock 對齊真 API：HEAD 405）；live e2e 全通
  （arcrun-rag-raw-demo：真上傳→重傳 no-op→下載 diff 一致＋sha256==key）

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-07-19 21:27:42 +08:00
Leo bb96bceb04 feat(ingest-hash-trigger): 凍結 collector/ingest schema＋Go collector 骨架（issue #5, SDD task 1+2） 
- schemas/collector-trigger.v1.schema.json：collector→named-webhook 觸發 payload（source_hash/r2_key/renamed/R6 warnings）
- schemas/kbdb-ingest-request.v1.schema.json：source_hash 必填缺=400；儲存映射走 metadata_json.$.source_hash（守 kbdb 表不變鐵律）；同 hash 重送=200 already_ingested
- schemas/MIGRATION-webhook-payload.md：舊 Gitea push payload 逐欄對照（給 task 4 改寫 workflow）
- collector/：Go module（純 stdlib）——manifest 讀寫＋mtime fast-path 掃描＋renamed hash 配對＋40% 大量刪除防呆；CLI collector scan
- go test ./... 全綠 7/7（added/modified/removed/renamed/防呆五情境＋fast-path＋manifest 往返）
- Node 版 collector 標 legacy 並存（SDD task 4 拆除）

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-07-19 20:31:11 +08:00