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

5 Commits

Author SHA1 Message Date
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 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 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 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 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