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 |
|