arcrun-collector

inkstone/arcrun-collector

Fork 0

Commit Graph

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	d787bfc47d	t195：燈號不再說謊＋加診斷 log（leo：「燈號是真的還是假的？」→ 是假的） ## leo 實撞丟 PDF 進 youlinhsieh-test1 沒反應；按「立刻同步」後畫面顯示「正在整理知識卡」，但卡從來沒產出。 ## 燈號為什麼是假的舊版 describeStatus 只看「sync-now 訊號檔存不存在」就顯示「同步中…」。那只代表排隊了，不代表有人處理：leo 的 collector 在 11:25 跑完最後一輪，他 11:38 按同步 ⇒ 訊號檔沒人消化 ⇒ 畫面一直說在整理，實際 13 分鐘沒跑過。這比沒有燈號更糟——它在說謊。修：燈號要有憑有據—— · collector 沒在跑 → 明說「同步引擎沒有在跑」並告訴他怎麼辦 · 有排隊且引擎活著 → 才是「同步中」 · 其餘 → 看守中 ## 順手補上診斷 log（~/.arcrun-rag/app.log） startSupervisor 以前只 Stat(config) 就靜默 return，出問題完全查不到（我這次也是繞了很久才確定它有啟動）。現在每個 return 點都留痕。 ## 🔴 但真正擋住產卡的是另一個 401（未修，需 leo 裁）實測鏈路：掃到 PDF ✅ → /portal/daemon/extract ✅ 200 → 寫 kbdb ❌ 401 curl -X POST https://arcrun-kbdb.youlin-hsieh-dev.workers.dev/entries（無 token）→ 401 真兇：workflows/rag-ingest-card.local.yaml 打 __KBDB_BASE__/entries 完全沒帶 Authorization，但 kbdb 要 Bearer KBDB_INTERNAL_TOKEN。 ⚠️ 與今天修的 t189 不同：那是 extract 端點入口（現已 200），這是 workflow 內部寫 kbdb。修法命中 D36 金鑰鐵律（「只能拿 key，送出時自動拉 value」） ⇒ 應寫 {{credential.kbdb_internal_token}} 由 resolve_credentials 回填，而非讓安裝器 sed 把 token 值塞進定義。已停下等 leo 裁。 ## CP 對帳「丟檔→產卡」＝ ❌ 斷（卡產不出來）。本次只修好「燈號誠實」與「可診斷」，未送達用戶（daemon 新版尚未出貨、401 未修）。	2026-08-05 11:45:07 +08:00

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

d787bfc47d

t195：燈號不再說謊＋加診斷 log（leo：「燈號是真的還是假的？」→ 是假的）

## leo 實撞
丟 PDF 進 youlinhsieh-test1 沒反應；按「立刻同步」後畫面顯示
「正在整理知識卡」，但**卡從來沒產出**。

## 燈號為什麼是假的
舊版 describeStatus 只看「sync-now 訊號檔存不存在」就顯示「同步中…」。
那只代表**排隊了**，不代表有人處理：leo 的 collector 在 11:25 跑完最後一輪，
他 11:38 按同步 ⇒ 訊號檔沒人消化 ⇒ 畫面一直說在整理，實際 13 分鐘沒跑過。
**這比沒有燈號更糟——它在說謊。**

修：燈號要有憑有據——
  · collector 沒在跑 → 明說「同步引擎沒有在跑」並告訴他怎麼辦
  · 有排隊 **且** 引擎活著 → 才是「同步中」
  · 其餘 → 看守中

## 順手補上診斷 log（~/.arcrun-rag/app.log）
startSupervisor 以前只 Stat(config) 就靜默 return，出問題完全查不到
（我這次也是繞了很久才確定它有啟動）。現在每個 return 點都留痕。

## 🔴 但真正擋住產卡的是另一個 401（未修，需 leo 裁）
實測鏈路：掃到 PDF ✅ → /portal/daemon/extract ✅ 200 → 寫 kbdb ❌ 401
  curl -X POST https://arcrun-kbdb.youlin-hsieh-dev.workers.dev/entries（無 token）→ 401
真兇：workflows/rag-ingest-card.local.yaml 打 __KBDB_BASE__/entries
**完全沒帶 Authorization**，但 kbdb 要 Bearer KBDB_INTERNAL_TOKEN。
⚠️ 與今天修的 t189 不同：那是 extract 端點入口（現已 200），這是 workflow 內部寫 kbdb。

修法命中 D36 金鑰鐵律（「只能拿 key，送出時自動拉 value」）
⇒ 應寫 {{credential.kbdb_internal_token}} 由 resolve_credentials 回填，
   而非讓安裝器 sed 把 token 值塞進定義。**已停下等 leo 裁**。

## CP 對帳
「丟檔→產卡」＝ ❌ 斷（卡產不出來）。本次只修好「燈號誠實」與「可診斷」，
**未送達用戶**（daemon 新版尚未出貨、401 未修）。

2026-08-05 11:45:07 +08:00

2 Commits