 Leo
|
6c74b97718
|
feat(collector): workers-ai 路改吃共用契約——免金鑰預設路的卡跟 BYOK 一樣完整（Arcrun#134）
InkStoneCo#44 ④ 只修了 gemma BYOK 路（JSON 契約＋wikishape 機械組卡），
免金鑰預設路（多數用戶實際走的）仍吃雲端舊 prompt 的舊格式卡 ⇒ 走預設路
拿到次級知識庫。
修法＝契約單一真相源：wikiExtractPrompt（原 gemmaPrompt 改名，因為它已是
兩條路共用）由 daemon 整段帶上雲（request prompt 欄位），雲端只當執行器回
模型原文（response output），解析（parseWikiExtractJSON）與組卡（BuildWikiDoc）
回到本 package 與 gemma 路同一段程式碼——同形不再靠「兩邊要一起改」的叮嚀。
版本歪斜兩向都有路：舊雲端忽略 prompt 回 card ⇒ fallback 走 legacy 落卡
（#60 前綴／不覆蓋保護原封不動，收端 lint 新舊雙軌）；舊 daemon 不帶 prompt
⇒ 雲端 legacy 行為不變（對向修法在 Arcrun work/extract-wiki-json-0815）。
測試：+2——①request 的 prompt 必須是 wikiExtractPrompt 本人（不是手抄第二份）
②同原稿＋同判斷走兩條路，.wiki/ 產物逐位元組相同（卡＋00-INDEX＋manifest）。
既有兩則（stub 回 card）自動變成舊雲端 fallback 的守衛。go test ./... 全綠。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-15 21:26:30 +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
|
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 |
|