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

58 Commits

Author SHA1 Message Date
Leo 3cc8788e9d sync: collector/ 同步自 inkstone/arcrun-rag@d129f8b（桌面小幫手 0.18.48） 2026-08-28 09:16:44 +08:00
Leo e8800d18ef sync: collector/ 同步自 inkstone/arcrun-rag@1c31ac2（桌面小幫手 0.18.46） 2026-08-28 05:07:35 +08:00
Leo 80877af60c sync: collector/ 同步自 inkstone/arcrun-rag@740c55c（桌面小幫手 0.18.44） 2026-08-28 03:46:42 +08:00
Leo 3d1cb83110 sync: collector/ 同步自 inkstone/arcrun-rag@7c21a3a（桌面小幫手 0.18.42） 2026-08-27 21:30:21 +08:00
Leo 58d47d9080 sync: collector/ 同步自 inkstone/arcrun-rag@85cb90d（桌面小幫手 0.18.40） 2026-08-27 14:03:50 +08:00
Leo e3f1d0177d sync: collector/ 同步自 inkstone/arcrun-rag@f2a1121（桌面小幫手 0.18.39） 2026-08-27 12:54:08 +08:00
Leo 4d966b7922 sync: collector/ 同步自 inkstone/arcrun-rag@c6cf717（桌面小幫手 0.18.38） 2026-08-26 21:04:03 +08:00
Leo a1786135d5 sync: collector/ 同步自 inkstone/arcrun-rag@1edbbb2（桌面小幫手 0.18.37） 2026-08-26 17:22:08 +08:00
Leo f1658fd2ad sync: collector/ 同步自 inkstone/arcrun-rag@a39cea2（桌面小幫手 0.18.34） 2026-08-20 11:26:28 +08:00
claude-code 395cad8f12 feat(collector): 每一則知識都答得出「原稿在哪一台機器上」（inkstone/mira#6） 
現況只缺這一格：雲端的麵包屑已經有資料夾多層路徑、檔名、片段錨點
（kb://RFP/design.md#0），唯獨答不出「哪一台機器」。

leo 2026-08-18 拍板的三層，由強到弱：
① 抓得到就用真實可讀的名字 → `<使用者>@<主機名>`（實跑：youlinhsieh@Leo-MBA）
② 使用者要能改成自己看得懂的稱呼 → config.json 的 machine_label（實跑：教育部 Leo 的 Mac）
③ 什麼都抓不到也要保證兩台不同 → unknown@<隨機 8 hex>，持久化在 machine.json

做法照既有的 library 走，不新增第二種：
- daemon 逐筆隨 payload 送 machine／machine_label（收卡、總覽卡、下架、舊直送四處）
- 雲端寫進 block 的 metadata_json，與 source／source_path／library 並排
- 三元組寫進 machine slot（slot 由 matrix/arcrun 的 seed 補，見該 repo 分支）
- upsert／下架的比對規則照抄 arcrun-rag#46 對 library 的處置：**兩邊都有值才收緊**
  ⇒ 既有資料（沒有這一格的）行為一字不變，不會變兩份、也不會撤不掉

🔴 machine **不混進 source_uri**：portal 的 srcLocalPath() 直接把 kb:// 之後整段當本機
   相對路徑用，混進去會吐出不存在的路徑，而且舊資料的第一段會被誤讀成機器名
   ——那就是「憑空長出假機器」。分成獨立欄位，舊資料就誠實地空著。

ID 一鑄就不再重算（machine.json）：user@host 會變，重算會讓同一台機器的舊知識
突然掛到「新機器」底下。改名走 machine_label，不碰 ID。

驗過（youlin stage，實測輸出見 inkstone/mira#6 回報）：
- 真 daemon 跑 direct --once → 每個 block 的 metadata 都有
  machine=youlinhsieh@Leo-MBA、machine_label=教育部 Leo 的 Mac
- 同一相對路徑、兩台機器 → block 各留一份、三元組 4 筆並存，沒有互相刪掉
- 既有資料（無 machine）照樣被同一台機器 upsert 掉，沒有變兩份
- workflows/tests/machine-scope.test.mjs 13 passed；takedown-scope 8 passed；isdoc 21 passed
- collector go test ./... 全綠
 2026-08-18 16:50:23 +08:00
Leo 97309b5580 fix(collector): 排除判準不看版控、不誤殺筆記庫、剪掉什麼講得出來（arcrun-rag#104） 
票上寫的真兇是錯的。`direct.go` 那一行 `skipDirNames{"system-dev"}` 不是唯一的
排除清單——同一個 Scan 呼叫下面幾行就是 `Plan: plan`，#104 的清單一直都接著。
拿 leo 真實的 `pms` 唯讀跑一輪現行 main：策略 docs-only、送 9 個檔、node_modules 零個。
他 08-16 看到 undici 文件，是因為手上的 daemon 是 v0.18.27，而修法 cc6e500 要到
v0.18.28（08-16 16:13，7f379d0）才被戳版號——那支 commit 自己就寫著
「changelog 停在 v0.18.27，而 collector/ 早已往前走 30 個檔（…cc6e500…）」。

但那個誤判之所以會發生，是因為底下有四個真的缺陷，這一版把它們一起修掉：

① 兩張表分居兩處 ⇒ 讀源碼的人只看得到一張。
   `system-dev` 的保護搬進 IngestPlan（templateOwnedDirNames），
   direct.go 不再手捏第二張清單。判準只剩一個地方。

② 排除規則生不生效，取決於呼叫端記不記得傳 Plan。
   改成 Scan 自己算（Mode == "" ⇒ PlanIngest）。「忘了接」這個失敗模式不存在了。

③ 一張大表把「沒有人會這樣命名」與「這是普通英文字」混在一起，於是**誤殺**。
   實測：一般筆記庫 8 份筆記只送出 1 份（build/樂高作品集、out/外出旅遊、
   vendor/廠商聯絡簿…全被當成建置產物），而且回報「擋掉 0 個」。
   拆成三種理由，強度不同、要求的佐證也不同：
     ① 使用者的 .gitignore 說的（新增 ignorerules.go，git 語法的安全子集）
     ② 名字本身就不是人話（node_modules、__pycache__…）——無條件
     ③ 泛用名（build/dist/out/vendor…）——**旁邊真的擺著專案檔才算**
   🔴 判準一律不看 `.git`（leo 2026-08-16：「你不需要判斷有沒有 git，
   我的 KB 筆記庫也有 git，是否用 github/gitea 追蹤完全沒意義」）。
   `.gitignore` 只讀內容當線索，不拿存在當門檻。
   順帶：鎖定檔（pnpm-lock.yaml…）不是知識——`.yaml` 進白名單後它變成了「知識」。

④ 「排除規則要看得見」只做了一半：整棵剪掉的子樹一個都沒數（pms 實測回報 0），
   而且 Plan/ExcludedByPlan 只有 CLI 讀，daemon（使用者真正走的那條路）拿到就丟。
   新增 ExcludedDirs（路徑＋人話理由）＋ SyncStatus.FolderPlans 寫進 status.json。

實測（唯讀跑 leo 的 `/Users/youlinhsieh/Documents/tech_projects/pms`）：
  139 個文件檔 → 送出 7 個，全是他自己的 README/docs；
  6 個資料夾整棵跳過，每個都講得出理由；node_modules 與授權條款 0 個。

測試：collector 全綠（新增 12 案，含「裸呼叫 Scan 也必須排除別人的套件」、
「不准再有第二張排除清單」的源碼層守門、筆記庫不誤殺、同名看旁邊擺什麼決定）；
arcrun-app 全綠。未出貨、未推 main。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-16 22:48:22 +08:00
Leo 895d672177 fix(daemon): 移除資料夾要真的把雲端資料收回（arcrun-rag#46） 
leo 2026-08-16 實撞：掛資料夾、同步完成、從清單按「移除」之後——
「我去把 Logseq plugin 刪掉以後，**採集的 wiki 沒消失**」。
內容一筆都沒少，照樣搜得到、照樣 is_embedded=1、AI 照樣拿它回答。

真兇（源碼）：app.go 的 RemoveFolder 全文只做三件事——從 WatchFolders 拿掉、
saveCfg、restartWatch，**一次都沒碰撤除**。而撤除機制本身是好的（在部署白名單裡、
有測試、direct.go 真的會觸發它），只是那兩個觸發點都在「還在監看的資料夾裡某個檔
被刪掉」的差異偵測迴圈裡。⇒ 刪一個檔會撤除 ✅／移除整個資料夾不會 ❌。
**在使用者眼裡是同一件事，在程式裡是兩條完全不同的路，只有一條接上了撤除。**

這不只是少一個功能：產品說明卡寫著「確保資料所有權完全屬於使用者而非 SaaS
供應商」，而使用者唯一看得到的收回動作不收回任何東西 ⇒ 知情同意的問題。

修法（沿用既有那條撤除路，不另寫一份）：
- drainPendingTakedowns：把既有的「待下架清單逐筆送出」抽成共用函式
- retireRootOnce：資料夾進 retiring_folders 後，把帳本裡真的上傳過的檔排進
  既有的 PendingTakedowns、走同一條撤除路；撤乾淨才刪帳本
- 進度與失敗真因寫進 status.json（level-triggered），App 看到 done 才清設定
- App 是 config.json 的唯一寫入者（兩個行程都寫＝互相蓋掉對方的設定）

邊界（本票最危險的地方）：path 是相對於被監看資料夾的路徑 ⇒ 兩個資料夾各有
notes.md 時 page_name 與 path 完全相同，撤除一個會連坐另一個。撤除 payload 帶
library（逐根導出，與 ingest 同一個函式算的），workflow 兩個比對節點加「library
相符才殺」。只在兩邊都有 library 時才收緊 ⇒ 舊 daemon 不送／舊卡沒有都退回原行為。

畫面：舊文案「已經上傳的知識卡不會被刪除」技術上是對的，但它替使用者決定了他要的
是「只停止同步」。改成兩個選項各寫一行後果讓他選（預設待 leo 裁）。

測試：go test ./collector/... ./collector/cmd/arcrun-app/... 全綠；
新增 direct_retire_test.go(7)／remove_folder_takedown_test.go(4)／
workflows/tests/takedown-scope.test.mjs(8)。UI 用真 dist + headless Chrome 複驗，
check-cis.sh／check-render.sh 全過。

◐ 未做：真實例端到端（不可逆且 leo 正在該機器上工作，步驟已寫成清單等總管確認）／
workflow 要重新部署才生效／未重打 bundle、未出貨。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-16 21:35:22 +08:00
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 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 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
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
Leo 2cdd5bd4bc merge: 額度卡與雲端連線兩則假訊息改口（arcrun-rag#59） 
總管 2026-08-11 審過後併入：
- 額度訊息不再指向無效的出口（換模型解不掉被向量化吃掉的額度）
- 多帳號時雲端狀態不再永遠停在零值 false
- 含對照修改前程式碼會 FAIL 的回歸測試
- 總管實跑 go test ./...：collector 全過

◐ 用戶手上仍是舊訊息：daemon 未重打、未出貨
 2026-08-11 13:22:39 +08:00
Leo 4cbc7ebe11 fix(arcrun-rag#59): 額度卡與雲端連線兩則假訊息改口 
leo21c 畫面同時說「今天已經幫你整理了 0 份」與「額度用完，可以換一個模型，
或升級 Cloudflare」——一份都沒成功，額度其實是被同帳號正在做的向量化
（嵌入固定走 Workers AI，與萃取共用同一份每日免費額度）吃光的，換萃取模型
救不了。改法：buildQuotaNotice 在 dailyCount==0（本輪一份都沒吃到額度就先
撞牆）時換一套出口／保證句——不再建議換模型、不再無條件承諾「明天會自動
接著跑」，只留「升級 Cloudflare」這個結構上真的有效的出口；dailyCount>0
（單純量大用完）維持原三句話不動。

同批修另一則真因已被頂層 wiki 鎖定的假訊息：leo 三個帳號 /health 全部 200，
畫面卻顯示「沒連上雲端」——direct.go 寫 status.json 頂層 cloud_check_ok 時
以前只有剛好一個帳號才會填，2+ 帳號（leo 的常態）時恆為 Go 零值 false。
改成不論帳號數，任一帳號連得上就標頂層為 true。

兩者都有回歸測試：對修改前的程式碼跑會 FAIL（多帳號 CloudCheckOK 案例已
用 git stash 實測驗證），修完後 PASS。額度卡文案另外用真正的 frontend/dist
+ 假 window.go 灌 leo21c 現場資料，Claude Browser 實際開起來看過，確認新
文案正確渲染、不再出現「可以換一個模型」、console 無紅字。

未做：兩者都只在原始碼層修好，尚未重打 daemon bundle 出貨（0.18.25 用戶
手上還看不到）；頂層 cloud_check_ok 的實際消費端（除已知的舊版 tray）未
完全追出，留給下一輪核實。詳見 system-dev/docs/3-specs/daemon-beta/tasks.md
t216／t217。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-11 12:28:49 +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 63bea13f21 feat(daemon-beta B2): 萃取品質 lint（H1–H6）重新接到現行 direct.go 
Gitea #24：分支 work/b2-quality-lint-0726（2f3e9ec）躺在 main 外兩週，
今天重新整合進現行 direct.go（原分支落後 main 130+ 筆，direct.go 本身
差 667 行，需要真正的整合工作而非硬併，見 wiki status.md 與頂層
daemon-beta/tasks.md 已記載的殘項）。

- collector/lint.go／lint_test.go：package main → package collector
  （main.go 在 4a26856／v0.18.9 已從兩支執行檔併成一支，整個 collector/
  目錄已改名 package collector；分支停在改名之前）。
- collector/main.go：func main() → func Run(args []string) int
  （同一次重構），新增 case "lint" 呼叫 runLint。
- collector/direct.go：DirectConfig.LintStrict 欄位＋extractor 萃完、
  POST rag_ingest_card 前掛 LintCard 閘（硬缺→不送標 rejected；
  軟項→照送帶 quality:low+quality_warnings）；CLI --strict 旗標。
- 既有測試共用的 cardFixture（direct_extract_test.go）／direct_pacing_test.go
  三處 inline 卡片，從「兩段最簡卡」補成 B2 合格四段卡——不是新增例外，
  是 lint 正確地在做它的事，舊卡片本來就不合格。

驗證：go build/vet/test ./... 全綠；另以真實 PDF（docs/onboarding/封測說明.pdf，
2MB 二進位）跑過完整 direct.go 同步鏈，證實送進 Gemini 的 prompt 是
5,071 字乾淨中文（0 個控制字元/NUL），不是原始位元組——ConvertToText
（t73）已完整解決 900b895 想止血的問題，故該分支的 looksLikeText
二進位止血、Windows 交叉編譯腳本判定作廢，不併。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-09 14:26:21 +08:00
Leo 779a1b801e feat(t215): 每個知識庫顯示是否要更新，落後就給 install 頁連結 
leo 08-08：「在每個知識庫會看到其他需要更新的，在每個知識庫上顯示是否要更新，
如果要，加開啓 install 頁的連結」。小幫手以前只提示自己（daemon 本體）要不要
更新，使用者連著多個雲端知識庫時完全看不出哪一個落後。

- collector/cloud_latest.go：EvalCloudUpdate + FetchLatestCloudRelease（30 分鐘節流），
  判準與 portal 版本卡 loadVersion() 同一套（bundle_version vs install.arcrun.dev/
  api/latest 的 release，semver 逐段整數比較），不是 t103 minCloudRelease 那把相容
  底線，避免同一個知識庫在兩處得到相反答案。
- direct.go/sync_status.go：每輪同步順帶算好每個帳號的 CloudUpdateKnown/
  CloudUpdateStale/CloudLatest，寫進 status.json。
- app.go：GetState 把這些欄位接進 UIAccount，供前端讀。
- main.js/style.css：首頁新增「知識庫版本」卡（每庫一行，落後才出現「前往安裝頁
  更新」按鈕，帶 email 預填）；側邊欄庫名旁加警示點；各庫頁也顯示同一行版本狀態。
  查不到版本（連不上／latest 暫時查不到）一律誠實說「查不到」，不當成「已最新」。

已用假 window.go 在瀏覽器實測四種情境（落後／已最新／連不上／查得到 mine 但查不到
latest）＋零知識庫的 onboarding 頁＋深色模式，畫面與按鈕行為皆符合預期。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-09 00:21:40 +08:00
Leo b3f63f40fb feat(t210): 首頁改統計，不再逐檔解釋——Evan「9000/101/20 兜不起來」的病 
地基（progress.go 的 SyncProgress／ClassifyFailure／BuildFailureBreakdown，
eeb35ba）已經算好「總量」與「失敗分類」，但沒人接到畫面上：首頁仍在用
本輪計數（extractedOK）＋逐檔白話翻譯（humanizeFailure），導致 leo 08-08
轉述的病——三個數字互相對不起來，使用者無法判斷「還在跑」還是「壞了」。

接線（collector/direct.go）：
- runDirectOnceRoot 現在也回傳這一根資料夾的 SyncProgress／StuckReasons
  （rootProgress），RunDirectOnce 跨帳號跨資料夾 Add() 累加成總量。
- G-6.2 的 SkippedDocCount（讀不了的檔，根本沒進 manifest）併進
  Unreadable／Total——這是 Progress() 算不到的部分，由呼叫端補齊，
  維持不變式 Total == Done+Pending+Stuck+Unreadable。
- 「送不上去」的分類統計＝Stuck 的 LastError 原文＋Unreadable 重用
  convert.go 既有的 ErrUnsupported，一起餵給 BuildFailureBreakdown。
  分類判斷全程只經過 progress.go 的 ClassifyFailure 一個接縫，
  direct.go／app.go／前端都不認得任何分類名稱字串（留給 t214 之後
  改資料驅動時只動一個檔）。
- SyncStatus 新增 Progress／FailureBreakdown 兩個欄位，兩者都是每輪從
  manifest／掃描結果原地重算的現況快照，不進 CarryForwardActivity——
  斷網或閒置一輪不會被清成 0。

畫面（cmd/arcrun-app/app.go＋frontend/src/main.js）：
- 移除 humanizeFailure／buildFailures／UIFailures 那套逐檔白話翻譯，
  改用 UIProgress（Total/Done/Pending/CantSync/Groups）；前端 cardProgress
  只把後端給的 category/count 陣列原樣印出，不分支、不排序、不認分類名。
- 「送不上去」預設摺疊（<details>），展開只有分類與份數，不逐檔列名、
  不解釋、不給解法；細節導向「開啟使用說明」。
- 保留 buildSkipped 的「讀不了的檔」卡片（那是另一件事），但份數已併入
  Unreadable。
- 移除「總計」卡片裡用本輪計數 extractedOK 的「份已整理」——上方狀態
  時間軸的「上次 N 份」與下方矛盾（1 份 vs 0 份已整理）的病因直接消掉，
  改用 cardProgress 的累計「已送上去」。

驗證：
- go build ./... 與 go test ./...（collector／cmd/arcrun-app／
  cmd/arcrun-tray 三個 module）全綠。
- 新增 collector/progress_wiring_test.go：真跑 RunDirectOnce 湊出
  Done/Pending/Stuck/Unreadable 四種狀態同時存在，驗四數字相加等於
  總數（leo 驗法①）；再跑一輪「什麼都沒發生」驗數字不歸零（驗法③）。
- check-render.sh 視覺機械閘綠（lockup 底板／深色模式）。

殘項（誠實標記，未完成）：
- 真機驗收（leo 08-08 驗法④：拿 Evan 的情境走一遍）未做，需要 leo 或
  封測者在實機驗證。
- 「開啟使用說明」目前連到既有 docs 首頁，尚無 t210 分類對應的 FAQ 頁
  （tasks.md 已記為相依項）。
- t213 診斷檔尚未消費這組新欄位（tasks.md 記載該任務等本任務讓路）。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-08 12:45:12 +08:00
Leo a6ced32d45 collector：積壓分批＋新檔優先／額度用完講人話降速／斷點續傳／同內容多格式去重 
封測事故（Evan）：daemon 逐檔萃取上傳、每個檔在雲端產生一次工作流執行，
690 個檔在自己的免費 CF 帳號上短時間內衝出 1,070 次寫入，撞上免費上限 1,000，
額度爆掉、只有 8 個檔成功。雲端那一半（紀錄改走資料層 API）已修好，
daemon 這一半原本完全沒有節奏——本次補齊四件事：

1. 上傳節奏（direct_pacing.go）：單輪最多處理 MaxEventsPerRun 個事件
   （預設 25）、每次觸發雲端前節流 700ms；一輪掃到的事件依檔案 mtime
   由新到舊排序，今天寫的永遠優先，積壓慢慢消化不擋日常使用。

2. 額度用完講人話（quota.go）：偵測到 Workers AI「10,000 neurons」/
   「4006」等已知上游訊號後，換成三句話（今天已整理幾份／可換模型或
   升級 Cloudflare／不花錢也沒關係、今天或明天早上 8:00 會自動恢復），
   不出現裸露的錯誤碼；同帳號同輪與下一輪都不再繼續撞牆
   （quotaState 全域冷卻，跨資料夾／跨程序重啟持續，直到台灣時間
   早上 8:00 額度重置）。

3. 斷點續傳：每個事件處理完立刻寫回 manifest（不再等整輪跑完才存一次），
   process 被殺掉重開只會接著做真正還沒完成的部分；removed 事件另外
   用 preScanEntries 快照保護，下架失敗時不會被其他事件的存檔動作
   誤標成「已完成」而永遠不再重試。

4. 同內容多格式去重（scan.go）：同一批來源轉出的多種格式（如 leo 給的
   資料集 27,164 檔＝9,045 md＋9,044 json＋9,043 html，md/json 同檔名
   主幹）依檔名主幹分組，只留優先序最高的一份進事件管線，其餘標記在
   DuplicateFormats（不吃三倍額度）。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-07 16:58:07 +08:00
Leo 857420dfa7 v0.18.18：失敗原因真的顯示在畫面上（前面幾版只做了一半） 
## 補完「上游錯誤要看得到」這條線
- 退避中的檔案也進 `status.failures`（先前退避期間該欄是空的
  ⇒ 畫面只有「⚠ N 份失敗」沒有原因，等於前面白做）
- `shortError` 從 120 放寬到 240 字：真因在訊息**後半段**，砍 120 會整段切掉

## 實測輸出（不是推測，是印出來的卡片內容）
  有 2 份沒有送進知識庫
   · 2021超新星品牌白皮書-科特勒.pdf
     今天的免費 AI 額度用完了 ⇒ 明天會自動恢復，這些檔案會自己補上，你不用做什麼。
   · 台灣青年創新創業協會謝侑霖.pdf
     這份 PDF 看起來是掃描的圖片 ⇒ 需要先做文字辨識（OCR），或換一份有文字的版本。
⇒ 同樣是「失敗」，處置完全相反（等就好／要動手），使用者現在分得出來。
（測試資料取自 leo Windows collector.log 的原文。）
 2026-08-06 21:41:28 +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 01fbb21357 v0.18.16：修「明明連上卻說沒連上」——第三次「我這台好好的」 
leo Windows 實測：首頁跳「需要你處理一下 ⇒ 還沒連上知識庫」，
但側邊欄有 geek6688、Portal 的庫目錄管理也看得到它的庫（win_on_mac_test_lib）。

## 真兇：又是「只看根層欄位」
`direct.go` 判連線只看 **根層** `cypher_url`/`api_key`，
而多帳號設定（現在的常態）根層是空的 ⇒ **恆判成沒連線**。
為什麼開發機沒事：leo 的 Mac config 帶著**單帳號時代留下的根層欄位**。
⇒ **今天第三次同一個模式**（另兩次：config 缺 manifest 靠舊檔補齊、
   啟動 log 用根層組出 `/webhooks/named//…`）。
修：抽出 `accountsConnected()`＝「根層有 **或** 任一帳號有」，並補測試
（刻意用「只有 accounts、根層全空」＝全新使用者的形狀）。

## 順帶：那句話還指錯路
訊息叫人「點托盤選單的『＋ 新增帳號…』」——**托盤選單早就只剩「結束 Arcrun」**
（t194 起所有設定都在視窗裡）⇒ 使用者照著做會找不到入口。
改指「左邊『知識庫』下方的新增知識庫帳號」。

## 順帶修我自己的測試腳本（leo 實撞）
`① 測試最新版.bat` 用 `dir /o-d`（修改時間）挑版本 ⇒ 複製到共用資料夾後
時間順序不一定等於版本順序，**leo 那次挑到了 v0.18.13**。
改用 `dir /on`（檔名排序）取最後一個。
另把「固定等 20 秒」改成「等你操作完按 Enter 再收 log」——
清空後第一次跑，引擎本來就不該啟動，等 20 秒收到的是空的。

## 附帶確認（leo 截圖）
- 「有 1 個檔案沒有被整理」**已列出檔名**（`scripts/sdd-active-check.sh`）⇒ 08-06 那個修正生效
- Portal 庫目錄管理三個庫都在（含 Windows 的 `win_on_mac_test_lib`）⇒ 子庫沒出現是假警報
 2026-08-06 19:57:05 +08:00
Leo 458ff3fd88 v0.18.14/15：全新使用者連上知識庫後會自己開始＋log 不再印不存在的網址 
leo 08-06 用共用資料夾實測，兩張圖把最後一個病逼出來：
「第一次直接跑可以，**清空再來一次，就不跑了**」。

## 真兇：restartWatch 第一行就早退
全新使用者的順序是：
  ① 打開程式（**還沒有任何設定**）⇒ startSupervisor 早退，`sup` 是 nil
  ② 連上知識庫、加資料夾 ⇒ restartWatch
  ③ 舊版：`if sup == nil { return }` ⇒ **什麼都沒發生**
  ⇒ 引擎永遠不啟動，畫面叫人「請結束 Arcrun 再重新開啟」
「不算錯」（重開真的會好），但等於要求剛裝好的人自己想到去重開程式。
**每一個第一次用的人都會撞到**；開發機永遠有設定，所以永遠測不到。

修：`sup == nil` 時**現場建立**（設定剛出現，正是該啟動的時機）。
新測試 `TestFirstRunStartsEngineAfterConnect` 從「沒有設定」開始走完整順序；
反向驗證拿掉即紅。

## 順帶把那句沒用的話拿掉
「請結束 Arcrun 再重新開啟」＝把系統的無能推給使用者。
改成「正在啟動同步引擎，請稍候…」；還沒連知識庫時說
「按『新增知識庫帳號』就會開始」。

## log 不再說謊（今天第三次同一個主題）
啟動訊息印 `cfg.triggerURL(...)`＝用**根層**的 cypher_url/namespace 組的，
而多帳號設定根層是空的 ⇒ 印出 `→ /webhooks/named//rag_ingest/trigger`
（沒網域、雙斜線）**看起來像設定壞了，其實功能正常**。
改印每個帳號真正會用到的網址。

## 實測證據（共用資料夾自動收回來的 log，非截圖轉述）
  19:13:54  設定檔缺必填欄位，已自動補上 manifest=C:\Users\leo21\.arcrun-rag\manifest.json
  19:13:55  collector direct daemon 啟動：監看 …\win_on_mac_test_lib  {"phase":"start"}
⇒ v0.18.13 的自我修復在真機生效，config 已補上 manifest，collector 真的跑起來。
 2026-08-06 19:33:36 +08:00
Leo 67effe3b7f 首頁「沒被整理的檔案」修兩病：同一件事講兩次／不說是哪一個檔 
leo 08-06 封測回報（附截圖＋「他放一個 md 檔無法通過」）。

## ① 同一件事講兩次，而且「另外」前面沒有東西
截圖實況：
  「看起來不是文件，所以跳過了。」   ← 底下是空的（非文件檔不逐檔點名）
  「**另外**有 1 個不是文件的檔案（圖片、影片、壓縮檔之類）也沒有處理。」
真兇：app.go buildSkipped 的 else 分支先寫一句通用說明，
接著無條件再寫 Other 那句——後者的「另外」是為「兩種都有」寫的，
在「只有非文件檔」時就變成前面沒有東西可以「另外」。
解：該分支只講一句、自己帶數量，且不留 Other。「另外」只在兩種都有時出現。

## ② 只報總數＝等於沒說（這才是 md 那題卡住的原因）
封測者放 .md 說「無法通過」，但畫面只寫「有 1 個不是文件的檔案」，
**沒說是哪一個** ⇒ 誰也判斷不出發生什麼事。
而 `.md` 明明在 allowedExt 白名單裡（scan.go:26），我在本機實測也一次就過：
    "path":"arcrun-md-test.md","status":"ingested","http_status":200
⇒ 那個「1 個」必然不是他以為的那個檔（副檔名被 Windows 藏起來、存成別的格式…），
  但沒有檔名就永遠查不出來。
解：scan 收集非文件檔的檔名（上限 5 個），一路帶到 status.json 與首頁。
「只報總數」在幾百張圖時是對的，在 1 個時是失職——少量就點名。

## 驗
· 兩支新測試釘住規則：只有非文件檔時不准出現第二句、不准出現「另外」；
  兩種都有時「另外」才成立並帶數量
· 實際文案打出來看過（見下），不是只看測試綠
    有 1 個檔案沒有被整理
    看起來不是文件（圖片、影片、壓縮檔之類），所以跳過了。這是正常的，你不用做什麼。
      · 我的筆記.md.txt
· 312 張圖的情況：列 5 個 +「…還有 307 個」，不洗版
· collector 全測試過、app 測試過、go vet 全綠
 2026-08-06 16:12:01 +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 9cd0adab22 G-6.2：讀不了的檔案不再安靜消失——首頁當場說出來 
服務 J-1 / S6「我丟進去的檔案，查得到」的考題 G-6.2：
「要嘛查得到，要嘛**當場被告知這種檔案還不支援**，不准安靜地略過。」
本次只做後半句（轉檔本體另有人閘，等 leo 裁「那段 Go 住哪裡」）。

## 真實現況比記載更糟
t16 寫的「PDF 被靜默略過」已不成立（t73 的轉檔層把 pdf/docx/xlsx/csv/pptx
都接上了，實測 2 頁中文 PDF 完整抽出）。**真正還在沉默的是別的東西**：
副檔名不在 allowedExt 的檔案在 scan.go 直接 `return nil`——
不進事件、不進 manifest、不進 status、不進畫面。
使用者丟一份 .doc 進去，從頭到尾一個字都沒有。

實測基線（真檔）：丟 .pdf/.md/.doc/.key/.jpg 進資料夾，
`collector scan` 只吐出 pdf 與 md 兩個事件，另外三個檔沒留下任何痕跡。

## 改了什麼
- scan.go：白名單閘不再是死巷。像文件的（.doc/.xls/.ppt/.pages/.key/
  .numbers/.odt/.ods/.odp/.rtf/.epub/.wpd/.msg/.eml）逐檔留名；
  其餘（圖片/影音/程式碼）只計總數——**避免 Obsidian 附件庫炸出幾百行噪音**。
- 兩個新欄位標 `json:"-"`：collector-trigger schema 是
  additionalProperties:false，且 BuildSendablePayload 是淺拷貝
  ⇒ 有 tag 就會漏到雲端被擋。這是給本機使用者看的，不上 wire。
- direct.go → status.json → App 首頁一張卡：講檔名與格式（「舊版報告.doc
  （舊版 Word）」），並告訴他不用重丟、也給替代路（另存成 PDF/.docx）。
- 刻意不進 manifest、不走 CarryForwardActivity：每輪由檔案系統重算，
  不製造 t195 那種「跨輪欄位漏 carry 就靜默歸零」的債。

## 順手修掉一個會讓驗收失效的回歸
同綑的 arcrun-collector 一路自稱 `dev`：退役 fyne 版
（arcrun-tray/build-mac.sh:24，t150／t72）本來就有版本注入，
t194 換 Wails 時沒帶過來，Mac 與 Windows 兩邊都掉。
**幹活的是 collector**——它不報版本，就沒人能判斷修復有沒有到使用者手上。

## 實測
- go test ./... 135 過 0 敗（新增 10 條：scan 5＋首頁文案 5）
- check-cis / check-render / check-tray 三閘全過；淺色深色都抓過畫面
- 從 **DMG 裡那支** collector 實跑：Info.plist 0.18.6、
  collector 回報 v0.18.6 (build 20260806-0101)、
  status.json 吐出 skipped_docs=[簡報.key, 舊版報告.doc]、other=1

⚠️ 未出貨：推 bundles repo 在 GitHub，要 leo 開 D20 閘。
DMG 已備妥 dist/Arcrun-v0.18.6.dmg。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-06 01:04:25 +08:00
Leo 6bf0daa786 修首頁狀態說謊＋DMG 補上拖曳版面（leo 08-05 封測回報 ①②） 
## ② 首頁狀態是壞的
leo：「拖新的檔案進資料夾，完成本地萃取、上傳，但自始至終 daemon 的首頁都顯示
『有變動就自動開始』『等待中』，都顯示綠燈沒動，實際上已經做完了。」

兩個獨立的真兇：

**A. 「同步中」判斷用錯依據（回歸）**
t191 早就做好機制：collector 開工印 phase:"start"、跑完印 "done"，
supervisor 據此維護 StateSyncing。**換 Wails 時 App 沒接這條線**，改看 sync-now 訊號檔：
  ① 訊號檔只有手動按「立刻同步」才產生 ⇒ 拖檔進資料夾（自動觸發）整輪不亮燈
  ② 就算手動按，collector 是**先刪檔再跑**（consumeSyncNowSignal）⇒ 真正在跑時檔早沒了
⇒ 改讀 sup.Status().State == StateSyncing。**接回既有機制，不發明第三種判斷法。**

**B. 做完的證據被下一輪抹掉**
ExtractedOK/ExtractFailed 是**本輪**計數、每輪覆寫整份 status.json
⇒ 有產出那輪寫下 N，十幾秒後空轉的一輪把它蓋成 0
⇒ 「上一輪 N 份」永遠空白、四步時間軸的綠燈只靠「跑過任何一輪」判斷＝與實際進度脫鉤。
⇒ 新增 last_activity_{at,ok,failed}：有產出記本輪、空轉沿用上一輪（CarryForwardActivity）。
   首頁改顯示「幾點整理了幾份」，綠燈只在真的整理過東西時才亮。

## ① Mac DMG 少了「看得出要拖」的版面
leo：「要跳出虛擬隨身碟，打開一個 finder 的視窗，**顯示 Arcrun 和 Application 的捷徑**，
用戶把 App 拖進 Application」。
原本 DMG 內容是對的（Arcrun.app＋Applications 捷徑），但**沒設版面**
⇒ 預設清單視圖、位置隨機，看不出「要往右拖」。
⇒ build-dmg.sh 改走 UDRW → Finder AppleScript 設大圖示/視窗大小/左右並排 → 轉 UDZO。
   best-effort：無桌面工作階段時只警告不中止（版面是加分，不該讓打包掛掉）。

⚠️ 真正讓 leo 拿到 zip 的原因不在這裡——是**線上 portal 還沒出貨**（見下）。

## 驗（實測輸出）
· collector 全測綠；新增 TestCarryForwardActivity 四子測（含「空轉不該抹掉上次成果」）
· 掛載 dist/Arcrun-v0.18.5.dmg 實查：
    內容剛好兩項（Arcrun.app + Applications→/Applications 捷徑）
    .DS_Store 6148 bytes（版面已存進去）
    Contents/MacOS/ 有 arcrun-app **和 arcrun-collector**
    CFBundleShortVersionString = 0.18.5（不是 1.0.0）／LSUIElement = true／codesign -v 通過
· 三支機械閘 check-cis／check-render／check-tray 全 PASS

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-05 18:01:17 +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 cc6534dd39 t191/t192：daemon 主視窗（Google Drive 風格）＋「同步中…」進行中狀態 
解 issue #18＋#17（leo 指定併做）。

## #17 進行中狀態——真兇是「工作時間對用戶隱形」
leo：「按『立刻同步』後很快就回到『看守中』，看起來好像就做完了，
      這時使用者一看沒做完啊，就覺得是 bug」。
真兇：collector **只在一輪跑完後**才印 JSON ⇒ 托盤無從得知「正在跑」。
修：開工前先印 phase:"start"、跑完印 phase:"done"；
    supervisor 新增 StateSyncing；托盤／主視窗顯示「同步中… 正在讀檔並整理成知識卡」。
形狀相容：兩筆都有 at，舊版托盤只會多算一次 round，不會壞。

實測（真的跑一輪 --once）：
  第1筆 phase='start' at=21:31:26
  第2筆 phase='done'  at=21:31:27

## #18 主視窗（新檔 mainwindow.go）
leo：「daemon 設定項越來越多，不可能統統塞在下拉選單」
     「參考 Google Drive 設定畫面：點擊 daemon 就開一個視窗，佔螢幕約 1/2」
     「資料夾清單要可捲動——我每個 gitea 專案都要同步，那就是幾十個，根本塞不下」
- 920x620 視窗，關窗＝隱藏（daemon 續跑）
- 上：大字狀態＋副標（上次同步／已整理幾份／失敗幾份；有錯誤優先顯示）
- 中：widget.List 虛擬捲動的資料夾清單（帳號標題＋其下資料夾攤平成單層）
- 下：白話動作列（加入資料夾／新增知識庫帳號／AI 設定／檢查更新）
- 每秒自動刷新 ⇒ 同步中看得到在動
- 無帳號時引導去連線（onboarding），不是丟錯誤或空面板
- **所有動作複用既有 handler**，不在視窗那邊重寫一份邏輯

托盤選單第一項加「開啟 Arcrun…」——leo 已點破兩次
「能力做出來了，入口沒出現在用戶會看的地方」（docs 沒連結／MCP 零處提及），
這次做完就讓它看得見。

測試：t192_test.go 八則（狀態文案四態／同步中要說明在做什麼／
副標優先顯示錯誤／副標不可空白／清單攤平且 accIdx 正確／60 個資料夾／無帳號空清單）全過。
collector 與 supervisor 全套綠。

⚠️ 未驗：fyne GUI 的實際外觀需真機開窗（無螢幕環境驗不到），
   CIS 視覺套用待 leo 看過畫面再調。
 2026-08-04 21:32:31 +08:00
Leo 133f5add46 t182：老 config 抹除成 Workers AI＋雲端探測——leo 實測「無卡」的真因 
leo 08-04 實測回報（更新 v0.15.5 後仍顯示 Gemini／丟 PDF 無卡），
查出來不是 Workers AI 不通，是**根本沒走到那條路**。三顆真 bug：

① 抹除只做一半（leo：「就要抹除改成用 Workers AI，如果保持 Gemini
   它不會改掉，那就是失敗的」）
   t181 只在 RunDirectOnce 改頂層記憶體值，但
   - makeAccountSubConfig 會把**帳號層**舊值蓋回來（t126「帳號層優先」）
   - 完全**沒寫回檔案** ⇒ 托盤是另一個行程，讀檔還是念 Gemini
   leo 的 config 正是頂層＋兩個帳號各留 "gemma"、無 explicit
   ⇒ 畫面顯示 Gemini、萃取也真的跑 Gemini。
   修：遷移移到 LoadDirectConfig（每次啟動必經），逐層抹除 + 寫回檔案。
   金鑰保留（Gemini 是選配不是廢除）。

② 驗證器擋掉自己的新預設
   `extractor 只能是 claude / gemma` ⇒ config 一旦寫成 workers-ai，
   daemon 直接載入失敗起不來。v0.15.5 已帶著這顆出貨。

③ 托盤標籤照 config 舊字串念（t178 的通則版）
   t178 只把 claude 這**一個**殘留值導向 Gemini，殘留 gemma 一樣脫鉤。
   改成與 direct.go 同一條判準：沒 explicit 就一律念「雲端 AI」。

＋ t182 雲端探測（leo 指定設計：「會去掃一次看雲端是否裝好，沒裝好就顯示
  workers AI 還沒通，一旦通了就顯示可用」）：ProbeWorkersAI 逐帳號探
  /portal/daemon/extract（送空 text，不燒 LLM 額度），結果寫進 status.json
  由托盤「狀態：」講白話。**不做靜默退回 Gemini**——那會讓用戶永遠
  不知道自己雲端沒更新。

實測證據（非 mock，打真實例）：
- youlin 實例萃真卡：3.67s，產出完整知識卡（一句話定義/要點/關鍵實體/關聯）
- 連測三次：3.51s / 3.34s / 3.59s（Gemini 實測 16.87s ⇒ 快約 5 倍）
- 兩個實例都已有 /portal/daemon/extract（皆回 400＝route 存在）
- 拿 leo 真 config 複本跑遷移：三層全抹成 workers-ai、金鑰留著、重讀仍是 workers-ai

測試：新增 direct_t182_test.go（抹除全層/寫回磁碟/主動選過不動/合法值/冪等）；
既有三則因預設變更而失效的斷言已更新（t108 二進位不出機的契約未放寬，仍綠）。
全套綠。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-04 16:29:56 +08:00
Leo 1a8906c0b7 t181 daemon 端：萃取預設走 Workers AI（免金鑰）＋托盤可切換 AI 來源 
【leo 08-04 列為最優先】「daemon 的 AI 改用 workers AI」
——「這是我的用戶**最大障礙**，造成首輪測試用戶的**好評或惡評**」。

【新增】collector/extract_workersai.go：打自己雲端實例的 /portal/daemon/extract，
那端用 env.AI binding ⇒ **完全不需要任何金鑰**。與 gemma 路架構完全對稱
（leo 的判斷：「不論用 Claude／Gemini／Workers AI…應該是同一件事」——是，
只有「送到哪」不同，讀檔/轉檔/淨化/落卡全共用）。
舊實例回 404 時講人話：「你的知識庫還是舊版 ⇒ 請到 portal 按『立即更新』」。

【預設改為一律 Workers AI】leo 特別交代：
  「default 用 Workers AI，你要用 Gemini 要**特別去選取**，**不管你現在是否有填金鑰**」
  「只要更新版本，就已經 default workers AI 了，除非去一個地方切換」
  「不然我會有很多質疑，**花在解釋為什麼 Gemini 不管用上**」
⇒ 判準是新欄位 ExtractorExplicit（使用者主動選過），**不是「有沒有金鑰」**。
  舊 config 沒這欄＝false ⇒ 更新版本後自動走 Workers AI；金鑰留著不動，改選 Gemini 立刻可用。

【托盤＝唯一切換處】「AI 設定…」改成引擎選擇：雲端 AI（預設）／Gemini（選配）。
選 Gemini 才顯示金鑰欄，並附「Billing Tier: Unavailable ⇒ 換 Google 帳號」的排難提示
（今天 oscar 撞的那題）。Gemini 不推廣（leo：「特定人告訴他怎麼做就好」），文案只說明不慫恿。

【標籤】leo：「用 workers AI 就**不顯示**，用 Gemini 會顯示 Gemini」
⇒ 預設路徑不佔版面；只有主動選了別的才標出來（延續 t178「標籤必須與實際行為一致」）。

【測試】新增 TestT181DefaultsToWorkersAI 六則，含最關鍵的
**「有金鑰但沒主動選 ⇒ 仍走 workers-ai」**；既有測試補 ExtractorExplicit 以隔離變因
（它們測的是萃取管線，不是預設邏輯）。兩模組全綠。

⚠️ 未送達：要打包 v0.15.5 並部署雲端端點才會到用戶手上。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-04 15:00:48 +08:00
Leo 1a3e974941 t178：托盤標籤與錯誤訊息對齊實際行為（leo 封測者實撞） 
【leo 08-04】封測者是台大資工碩士，仍搞不清楚 ⇒「一般人就完蛋了」。
他的托盤顯示「oscar · Claude」但他根本沒有 Claude，
同時錯誤說「Gemini 金鑰是空的」——**兩個訊息互相矛盾**。

① 標籤與行為脫鉤（accountEngineLabel）
   direct.go 早就把 claude 正規化成 gemma（t176：地端先只支援 Gemini），
   但標籤照 config 舊字串念 ⇒ 顯示 Claude、實際走 gemma。
   舊值來源＝雲端舊版下發後留在 config.json 的殘留（t176 擋了新寫入、沒洗舊值）。
   修：claude 也顯示「· Gemini」，與萃取實際走的路一致。

② 錯誤訊息沒說設定在哪
   舊：「請在設定裡輸入 Gemini API Key」——用戶找不到入口。
   新：「點托盤選單的『AI 設定…』貼上金鑰（免費申請：aistudio.google.com/apikey）」
   ——錯誤訊息本身就要能當 onboarding。

測試：TestAccountEngineLabel 兩則斷言翻轉成新規格（claude→仍顯示 Gemini），
並註明「若變回 · Claude 代表標籤又和萃取實際走的路脫鉤」；兩模組全綠。

⚠️ 未送達：daemon 執行檔要打包 v0.15.5 出貨才會到用戶手上。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-04 11:33:13 +08:00
Leo f903a3f53f t176 daemon：LLM 設定移回地端＋托盤單一實例（leo 08-03 架構翻案） 
leo 回報 Windows daemon 三症狀，查完 ①③ 同根，根在「雲端控制地端」這個設計。

【①③ 真兇】雲端 extractor_config 是**全租戶共用一把 KV**
（arcrun:portal.ts:43 portalTenant = worker 層級變數，不分用戶），
任一處設了 claude → 所有人的 daemon 都收到 claude。沒裝 Claude Code 的機器
FindClaudeBin 失敗 → 每檔萃取 failed、一張卡都沒建；想去 portal 改回 gemini，
checkbox 卻恆 disabled（claude_available 恆 false，因 daemon 從未實作
report-capabilities 回報 → daemon_caps KV 永遠空）⇒ 用戶自己解不開。
awindhon 實證：雲端同步成功、Gemini key 有效、零張卡，config.json extractor="claude"。

【leo 裁示】「地端要用什麼模型就在 daemon 上輸入 API Key 設置，而不是雲端設置後
控制地端」「地端先限制 Gemini API Key 配合客戶要求」「雲端就是 Workers AI」。

本次（daemon 端）：
- addOrUpdateAccount 不再接受雲端下發的 extractor/gemini_api_key/llm_model，
  只收連線欄位。t126「每帳號一份萃取設定」照舊保留——t126 修的是「存在哪一層」，
  本次改的是「值從哪來」，兩者正交。
- 托盤新增「AI 設定…」：使用者自己填 Gemini API Key，寫本地 config 後立即生效。
- 萃取一律走 gemini：殘留的 extractor:"claude" 正規化為 gemma；claude 路退役。
  ⚠️ 這不是「自動偵測有無 claude」（leo 07-27 已否決的 B 案），是整條路先不支援。
- 清掉隨之死亡的 claude_bin 回寫（死代碼＝錯誤的環境信號）。
- 托盤單一實例（症狀②）：pidfile + 跨平台 processAlive。
  mac 之前不多開是借 macOS Launch Services 的巧合，Windows 沒有該層 ⇒ 每點一次多一個 icon。
  Unix 用 signal 0（EPERM 也算活著，測試抓到的實際 bug）／Windows 用 OpenProcess+ExitCode。

測試：collector 全綠、tray 全綠。5 個原本用 claude stub 的測試改走**真實 gemma 路**
（httptest 替身注入 gemmaBaseURL），不是改斷言充綠；t126②③ 兩案翻轉成
「雲端下發一律被忽略」的回歸守衛；新增 4 案 single-instance。

未送達：本 commit 只到 code，尚未打包出貨；雲端側（刪 portal AI 設定區塊、
extractor 下發、admin/extractor）未動，待部署授權。CP rag-beta 步驟仍為 ◐。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-03 17:48:10 +08:00
Leo 6a3942024a t149: Folders() 收 accounts[].watch_folders——修多帳號用戶「按同步沒反應」 
leo 07-29 實測揪出：按「立刻同步」毫無反應，log 顯示 "folders": null、results: []。
真因：Folders() 只讀頂層 watch_folder/watch_folders，**完全沒讀 Accounts[].WatchFolders**。
多帳號設定（新制）一律寫在 accounts[] 裡 ⇒ 掃描清單空 ⇒ 什麼都不做。
**每個多帳號用戶都會中**，不是 leo 特有。

驗：go build 過；純 accounts[] 設定 dry-run → folders = [/tmp/aaa /tmp/bbb]（先前 null）。
註：AccountConfig 只有複數 WatchFolders（無單數欄位），初版寫錯已修正。
 2026-07-29 21:00:00 +08:00
Leo be5d6e3237 fix(t126): 萃取引擎/金鑰改每帳號一份——多帳號不再互相覆蓋 
leo：「2 個 CF 帳號一個填 gemma4 一個填 Mistral，daemon 會用誰的？別人也加就會有一樣的疑問」
實證：金鑰只有機器層一份 ⇒ 後連的覆蓋前一個。
修：AccountConfig 加 Extractor/GeminiAPIKey/LLMModel；帳號層優先、空值繼承機器層；
既有 config 遷移（頂層金鑰複製到各帳號，冪等）；連線只寫該帳號不覆蓋機器層；
托盤帳號標題顯示「· Gemini」/「· Claude」（一眼看出誰用誰）。
三模組 go test 全綠（總管親跑）。（實作＝子 CC；驗證+commit＝總管）
 2026-07-29 14:36:44 +08:00
Leo 1738acaca7 fix(t108 🔴🔴): 逐帳號同步遺失萃取設定→原文直送——三層修＋契約保險絲 
事故（leo 機 07-28 17:3x 總管現場抓到）：t104 config 重寫吃掉機器層 extractor/key、
per-account DirectConfig 不繼承 ⇒ extractor 空 ⇒ 6 筆走 rag_ingest_direct 原文出機。
修：①config 讀改寫全程保留既有欄位（帶測試）②帳號層無值垂直繼承機器層
extractor/claude_bin/gemini_api_key/llm_model/CardIngestWF/RemovedWF（帶 fake server 測試：
必須收到 rag_ingest_card 非 direct）③契約保險絲：extractor 空時非 .md/.txt 禁直送、
標 failed「萃取器未設定，已跳過（不直送原文）」——同類 bug 永不再成外洩。
三模組 go test 全綠（總管親跑）。（實作＝子 CC；驗證+commit＝總管）
 2026-07-28 17:59:42 +08:00
Leo bf1f0d9991 feat(t104): 多帳號同時看守——切換概念消滅 
leo 架構依據：「它只是一個門，幾個帳號通過它同步並沒有影響」＋
「我不是 Google Drive……不提供暫存空間，daemon 工作輕巧，多帳號只是頁簽問題」
（D-daemon-not-Drive）。
Accounts[] 每帳號獨立連線+資料夾；舊 config 冪等遷移 accounts[0]；
逐帳號同步一敗不擋全；status.json 分帳；托盤每帳號一分組；
「連上知識庫」→「＋新增帳號…」（append 非替換）；t86 切換清空退役；
t101 刪除作用於正確帳號。+873/-149、collector 5+tray 5 新測試，
兩模組 go test 全綠（總管親跑）。
（實作＝子 CC；驗證+commit＝總管）
 2026-07-28 16:45:14 +08:00
Leo f8450815d3 feat(t103): daemon 偵測雲端過舊＋托盤更新入口——連動閉環 
每輪 GET /health 取 bundle_version（5s timeout 失敗靜默）；空或日期<minCloudBuilt
→ 托盤「⚠ 知識庫需要更新（點我）」開 install.arcrun.dev；結果進 status.json。
兩模組 go test 全綠（總管親跑）。leo：「daemon 和雲端是連動的」——自此用戶只看托盤。
（實作＝子 CC；驗證+commit＝總管）
 2026-07-28 16:15:12 +08:00
Leo 77aa4c5195 feat(t98): 托盤「立刻同步」——訊號檔法零 IPC，跨平台 
leo：「無法知道到底同步了沒，可以在 daemon 上加一個立刻同步？」
tray 點擊寫 ~/.arcrun-rag/sync-now＋短暫顯示「同步中…」；collector 主迴圈 1 秒輪詢
訊號檔、有就立刻跑一輪刪檔，無則照 PollSec 排程；完成後 status.json 更新自然刷新托盤。
測試：collector＋supervisor＋tray 三模組全綠（總管親跑）。
（實作＝子 CC；驗證+commit＝總管）
 2026-07-28 15:06:08 +08:00
Leo 9df8d037ca fix(t86b): manifest 分實例——換知識庫後同資料夾不再被舊帳跳過 
根因：manifestPathFor 雜湊只含資料夾路徑，換實例讀到舊帳本
→ 全部檔案被視為已同步 → 新知識庫靜默拿不到資料（leo 機實證：刪 manifest 才通）。
- instanceHostOf：CypherURL 的 host 作為實例鍵
- manifestPathFor：sha256(host+"\n"+absRoot)，單根多根統一公式
- migrateManifestIfNeeded：新名不在、舊名在 → rename 過戶（一次性、冪等）
- 換回舊實例帳本仍在＝不重傳（每實例一本帳，設計目標）
已知殘窗（記 tasks.md）：升級後第一次掃描前就換實例，舊帳會被過戶給新實例
（舊格式無實例資訊，無從分辨）；常態下升級後首掃已把帳過戶給舊實例，窗口極窄。
測試：新增 6 條（分實例/穩定/單根遷移/多根遷移/冪等）＋三模組全綠（總管親跑）。
（實作＝子 CC；驗證+commit＝總管）
 2026-07-28 12:59:07 +08:00
Leo 6c9d74d588 fix(t91+t92): 萃取狀態可見＋Finder 啟動 PATH 修正——背景執行不可見的兩題同根一起解 
leo 07-28 實測根因：Finder 起的 GUI app 只有最小 PATH（無 /opt/homebrew/bin）
→ claude 靜默找不到→整輪萃取失敗，托盤卻顯示「看守中」。leo：「我怎麼知道它有萃？」
- FindClaudeBin：LookPath 失敗後掃 4 個常見絕對路徑，找到回寫 config claude_bin
- CheckExtractor 預檢＋每輪寫 ~/.arcrun-rag/status.json（ok/fail 計數＋失敗清單）
- 托盤：引擎未就緒→「⚠ 萃取引擎未就緒：<白話原因>」；失敗>0→可點開明細；正常→「已萃 N 檔」
測試：collector＋supervisor＋tray 三模組 go test 全綠（總管親跑）。
（實作＝子 CC；驗證+commit＝總管）
 2026-07-28 12:41:41 +08:00
Leo fb63d9f0c4 fix(t89 🔴🔴): 純中文資料夾名不再靜默併進 kb 庫——slug 空改生路徑穩定雜湊鍵 
leo 07-28 實測：「官方總圖」被顯示成「知識庫」＝slug 後為空退到 kb；
兩個純中文資料夾會塌縮同庫（靜默混庫，B5 分庫隔離形同虛設）。
修：libraryFor 第三優先從退 c.Library/kb 改為 lib_+sha256(絕對路徑)前6hex——
路徑穩定故鍵穩定、不同路徑必不同鍵；後端庫名鍵限 A-Za-z0-9_- 相容。
測試（t52_library_test.go）：純中文→lib_雜湊非kb／兩中文夾不同鍵／同夾重跑鍵穩定／
ASCII 行為不變／明列對映仍最優先。collector go test 全綠（總管親跑）。
（實作＝子 CC headless；審查+commit＝總管）
 2026-07-28 12:03:20 +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 fedb765742 feat(t52): per-folder 庫章——DirectConfig.libraries 對映＋libraryFor()（資料夾名 slug／中文退後備／明列優先，go test 綠）；兩支 ingest workflow 的 post_block metadata 補 library（真兇：blocks 沒蓋章＝兩資料夾全歸 general）；托盤連線時回報庫自動登記 2026-07-26 01:53:44 +08:00