d022ca067b
merge: kbdb DELETE 誠實回報向量刪除結果（arcrun-rag#46）
...
總管複核：改法與同檔 /entries/deprecate-by-library 一致（同步 await 再回應），
不動 schema、不加表（守 D38），附 84 行測試。
舊版 fire-and-forget 會把向量刪除失敗靜默吞掉——呼叫端看到「刪除成功」
但語意搜尋還留著殘影，這正是 #46 回報的症狀。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-10 15:50:36 +08:00
6715402bcc
fix(kbdb): DELETE /entries/:id 向量刪除改同步＋誠實回報（arcrun-rag#46）
...
舊版把向量刪除包成 fire-and-forget（waitUntil(...).catch(()=>{})）——失敗被靜默
吞掉，呼叫端（rag_takedown_direct workflow／未來的 portal 刪除 UI）永遠不知道
向量沒清乾淨。與同檔 /entries/deprecate-by-library（同步 await + 回報
vectors_deleted）的做法不一致，補齊同款誠實回報：回應加 vector_deleted
(true/false/null)，D1 本體刪除不因向量失敗而被擋下。
補上這支端點原本零覆蓋的測試（entries-delete.test.ts，3 案：模組未開／
向量刪除成功／向量刪除失敗）。
隨附 live e2e 驗證（youlin stage，4 筆測試知識，含批次 3 筆）：刪除後
keyword/semantic 混合檢索與 rag_chat AI 問答皆不再讀到已刪內容，控制組
（未刪的既有知識）不受影響——確認端到端「刪除即在所有查詢路徑消失」成立，
細節見 Leo/arcrun-rag#46 留言。
2026-08-10 15:41:01 +08:00
c4cee35adb
feat(auth): 認證與資料分離——搬動知識資料時登入不再跟著壞掉（D61 / arcrun-rag#55）
...
leo 2026-08-10 下令：「登入認證資料要分離⋯⋯就算只有我一個人存在單獨的 json 檔也好，
它不能被改資料庫的連結導致無法登入。」「昨天不能登入 portal，今天不能登入 mcp，
這根本就是一個問題。」
病：portal 帳號住 KBDB（owner_id = {CONSOLE_TENANT}::portal），console 管理員帳密住
SESSIONS_KV。兩者都靠 binding 指過去，重裝/遷移一定會被重新指一次 ⇒ 保險箱的鑰匙
放在保險箱裡。2026-08-09 leo 資料一個位元組都沒動，卻被鎖在門外。
修：認證搬到 CF Workers per-script Secrets（掛在 script 上，與 bindings 兩套資源，
重部不會洗掉；journeys/gemini-key-lost-on-reinstall.md 與 installer worker.js:1148 皆有實證）。
- 新增 lib/portal-auth-store.ts：自足的 JSON，讀取零網路呼叫，>4.6KB 自動溢位分片
- portal.ts 的帳號讀寫全部改走它；KBDB 只留為舊實例的回退讀路徑，登入成功順手搬過去
- console-auth.ts 的第二份認證資料同樣搬離 KV
- 不牴觸 D38：KBDB 三張核心表不增不減，本案是把東西搬出去
- 沿用 credentials.ts 既有的 putWorkerSecret/deleteWorkerSecret，不另造第二套寫入路徑（D36）
明顯失敗（把 #10「寧可明顯失敗，不要靜默錯置」套到門鎖上）：
- 「這台實例讀不到任何登入資料」回 503 + code=auth_store_empty，且**不計入 5 次鎖定**
（08-09 leo 就是被系統自己的誤判鎖了 15 分鐘）
- /console/setup 遇既有帳號改說「你剛才輸入的密碼沒有被採用」，不再只說「已設定過」
- /health 與 /console/auth-status 吐 auth_store 狀態（住哪、寫不寫得進去）
stage 實測撞到並修掉的坑：改 secret 會產生 worker 新版本，既有 isolate 讀到的還是舊 env
⇒ 「建好帳號立刻登入」有 15 秒以上 401，還被算進鎖定。加一層短 TTL 的 KV 加速器
（非真相源，只在 secret 查不到/密碼對不上時問一次），換 KV 不影響不變量。
驗收：stage（youlin）把知識資料庫換成另一顆空的 + 換租戶代號 + SESSIONS_KV 換成空的，
三樣一起換之後 portal / MCP /authorize / console 三條登入路徑仍全綠（複跑 3 次）。
對照組（舊版程式碼同樣換庫）：登入回「email 或密碼錯誤」，5 次後鎖 15 分鐘。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-10 14:13:37 +08:00
ae81d22775
fix(harness): 世代閘的 ON_TRUE 判準過時，反過來擋下正確教材
...
引擎自 2026-08-01 起已支援條件邊（cypher-executor/src/graph-executor.ts
case 'ON_TRUE'/'ON_FALSE'/'ON_BRANCH'，VALID_EDGE_TYPES 亦已列入；31 個
cypher-executor 測試全過）。registry/skills/write_intent_workflow.md（單一
真相源）也已在同日更正為教 ON_TRUE/ON_FALSE/ON_BRANCH 是合法邊。
但 cli/scripts/check-harness-generation.mjs 的世代閘還停在舊世代判準：
只要 SKILL.md 出現正面示範的 ON_TRUE 就擋——這道閘本身才是落後的一方，
把已經寫對的教材當錯誤攔下，害乾淨 `npm run build` 必敗。
同源的過時內容還藏在三個手動維護的 harness 原始檔（非腳本產物）：
CLAUDE.block.md／commands/arcrun.md／hooks/arcrun-guard.sh 都寫著
「引擎沒有條件邊」「沒有 ON_TRUE/ON_FALSE/ON_FAILURE」，一併更正。
真正不存在的邊是 ON_FAILURE（VALID_EDGE_TYPES 只有 ON_FAIL），把 mustNot
判準從 ON_TRUE 換成 ON_FAILURE，並新增 must 規則要求 ON_TRUE 必須出現，
防止教材日後又被改回「條件邊不存在」的舊世代說法。
skills/arcrun-mindset/SKILL.md 是由 registry 於建置期重建的產物
（build-harness-skill.mjs），本次改動只跑 `npm run build:harness`
重建、不手改。
驗證：故意把 SKILL.md 的 ON_FAILURE 改成正面示範，確認閘仍會擋下
（exit 1），還原後 `npm run build` 連跑兩次皆全綠且冪等（SKILL.md
md5 不變）。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-10 11:03:43 +08:00
9740794050
docs(3-specs): 立案 Arcrun App ↔ Portal 掛載協定 v0 提案（Leo/Arcrun#82）
...
設計全文住在票上，本檔只留指針＋影響分析，等 leo confirm。
病根實查：Portal「有哪些頁」在單檔 HTML 裡寫了四遍，出貨時整包內嵌成
單檔 worker，安裝器只會整顆換掉、無任何掛載點概念 ⇒ 加一個能力＝改核心。
未 confirm 前不開新 SDD、不動功能程式碼（現行 active＝workflow-discovery）。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-09 22:02:08 +08:00
453dec60b1
fix(scripts): template 來源改指活帳號，404 不再靜默寫入垃圾內容
...
scripts/install.sh 與 scripts/update.sh 的更新來源指向已被 GitHub suspend 的
uncle6me-web 帳號，實測全部 404 ⇒ 自動更新靜默失效。改成與 system-dev-template
本體、以及本 repo 現行世代 system-dev/scripts/ 一致的正解：預設公開 GitHub
youlinhsieh/system-dev-template，可用 TEMPLATE_SOURCE 環境變數覆寫，不改檔。
同時補上 looks_like_error_page 判斷（沿用 template repo 已修好的寫法）：curl
對 404 常回傳非空的錯誤頁內容，只判斷「非空」會把它當成正常檔案寫入且不報錯。
現在錯誤頁會被偵測、檔案不寫入、FAILED 清單於結尾列出、腳本以非零狀態碼結束。
實測：
- 修正後來源多個路徑回真實 HTTP 200（CLAUDE.md／VERSION／self-update 兩支腳本）。
- 刻意把 TEMPLATE_SOURCE 指回死帳號重跑兩支腳本：全部項目進 FAILED 清單、
無任何檔案被錯誤頁污染、exit code 1。
- 兩支腳本 bash -n 語法檢查通過。
已知缺口（不在本次範圍，留待另決）：template repo 內部檔案佈局已從
.claude/wiki/、docs/ 搬到 system-dev/ 前綴，這兩支舊世代腳本仍用舊路徑，
其中一部分檔案（wiki 範本、docs/README、SDD 範本等）在新帳號上仍 404——
現在會清楚回報失敗而不是靜默吞掉，但尚未逐一改點新路徑。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-08-09 20:54:01 +08:00
bfc98fe41a
官網與 npm 上的 GitHub 連結指向已停用帳號，全是 404（arcrun-rag#41）
...
延續同一次盤查（判準：素不相識的人點進來會不會被帶到到不了的地方）。
這批比 README 更顯眼——是 arcrun.dev 官網上那顆「GitHub」鈕，以及 npm 套件頁的
Repository 欄。逐一 curl 實測全部 404：
- landing（官網三個檔五處）：github.com/richblack/arcrun → 404（帳號已 suspend）
→ github.com/youlinhsieh/Arcrun（200）
其中 integrations 頁還指 richblack/arcrun/blob/main/CONTRIBUTING.md ＝雙重死
（帳號沒了，而且這個 repo 從來就只有 CONTRIBUTING-components.md）
→ youlinhsieh/Arcrun/blob/main/CONTRIBUTING-components.md（實測 200）
- cli/package.json 的 repository.url：github.com/uncle6me-web/Arcrun.git → 404
（同樣是 suspend 掉的舊帳號）→ youlinhsieh/Arcrun。這欄會直接顯示在
npmjs.com/package/arcrun 的 Repository 連結上，裝了 CLI 的人就是從那裡點過來。
只換字串，沒有邏輯變動；package.json 已驗證仍是合法 JSON。
⚠️ 同一批掃出但**本次未動**（behavior-affecting，另案處理）：
scripts/install.sh:29 與 scripts/update.sh:26 的 template 來源仍指
raw.githubusercontent.com/uncle6me-web/… ＝實測 404 ⇒ 自動更新靜默失效。
這正是 agent-memory 記過「uncle6me-web 曾害 template update.sh 自動更新靜默
死亡」的同一顆雷，修在 template repo 卻沒修到 Arcrun 這份 copy。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-09 20:28:05 +08:00
be9b92eb28
README：四個對外連結修掉，別再把點進來的人帶到死地方（arcrun-rag#41）
...
leo 08-09：「整個 github 的 readme 都是過時的，如果用戶真的連過來會被誤導」。
逐一 curl 實測，不靠假設：
- Arcrun RAG 連結指 git.uncle6.me/Leo/arcrun-rag ＝ **實測 404**（那顆是 private；
同主機的 Leo/Arcrun 反而匿名 200 ⇒ 判準是逐一實測，不是「Gitea 一律 private」）
→ 改指公開鏡像 github.com/youlinhsieh/arcrun-rag（200）
- 致謝的 @richblack → github.com/richblack **實測 404**（帳號已 suspend），
改 @youlinhsieh（200）
- 結尾 [CONTRIBUTING.md] → 檔案不存在，線上實測 raw 404；
repo 裡真正有的是 CONTRIBUTING-components.md（線上 200）
- 「給 AI 操盤手：開始前讀 .claude/rules/06-mindset.md」→ `.claude` 整個在公開
排除清單裡，公開 repo 根本沒這個檔 ⇒ 對外＝指了個不存在的路。改指 llms.txt
（公開、線上 200，第 23-26 行就是那套世界觀），並說明裝 harness 後才會有 Skill。
另把 08-08 留的內部說明 HTML 註解換成對外講得通的一句話：目前沒有公開試玩站，
想看產出去看 arcrun-rag-demo-knowledge 公開鏡像（實測 200）。註解寫給自己人看，
但它躺在對外 README 的原始碼裡。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-09 20:25:42 +08:00
19c82df05f
fix(portal): 管理員忘記密碼自救援出口（arcrun-rag#25）
...
唯一 admin 忘記 portal 密碼就永久卡死：requirePortalAdmin 系列端點全部要
先有 portal session 才進得去，bootstrap 又只能跑一次——登入頁只會叫他
「聯絡管理員」，而他自己就是管理員，沒有下一步。
新增 POST /portal/admin/recover-password，複用 bootstrap 已在用的 console
owner session 當人閘（與 portal 密碼完全獨立存放的另一組帳密）。畫面入口：
/console → 設定 → 「Portal 帳號密碼救援」；/portal 登入頁加一行連結指過去。
本機真瀏覽器 E2E 驗證（wrangler dev 18787/18788 + 本機靜態伺服，真的走一輪
forgot-password 狀態）：first-time setup 建帳號 → 故意打錯密碼確認鎖死
（email 或密碼錯誤）→ 點連結進 /console → 用 console 密碼登入 → 設定頁輸入
portal email → 產生新密碼 BPq2Rs4p7dBWMd6d → 回 /portal 用新密碼登入成功。
cypher-executor 4 個新測試 + 既有 59/60 綠（唯一失敗是既有 pre-existing
/portal HTML 殼 404，與本次無關，git stash 驗證過）。
2026-08-09 15:06:17 +08:00
23d36b311a
portal 設定頁補顯示 MCP 連接網址（arcrun-rag#7）
...
封測者原話：「說明叫我把 MCP 加進 claude.ai connector，但我找不到網址」。文件一直寫
「登入 portal → 設定頁，那裡可以直接複製」，但畫面上從沒真的顯示過（grep 0 命中），
用戶照文件走一定撲空。
設定頁新增「接上你的 AI（MCP）」面板：純前端把 apiBase 的 worker 名字從
arcrun-cypher-executor 換成 arcrun-mcp（同一顆自架帳號 workers.dev 子網域，對齊
cli/src/lib/deploy.ts:386-392 部署時的組法），不符形狀就誠實顯示「尚未偵測到」，
不亂猜連不到的網址。複製按鈕從既有 copyOriginUrl 拆出共用 copyText(btn, url)。
端到端本機瀏覽器實測：真 wrangler dev（kbdb+cypher-executor local D1）+ 真登入流程
（console setup → bootstrap admin → portal login）走到設定頁，面板正確顯示/隱藏；
用貼近真實自架形狀的假網址驗算，結果與 deploy.ts 的組法逐字相同；複製鈕點擊行為與
既有、未改動的 st-copy-url 按鈕在同一自動化環境下一致（clipboard-write 是瀏覽器自動化
環境限制，非本次改動的迴歸）。詳細記錄見 system-dev/docs/3-specs/portal-auth/tasks.md t218。
未部署（紅線：只 commit+push，未動任何 Cloudflare 實例）。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-09 14:23:56 +08:00
ebd4bf5d97
wiki: 記執行紀錄保留期 UI 補完（arcrun-rag#21）
...
status.md 補一段，供下個 session 接關不用重查。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-09 13:30:00 +08:00
889b70b8f9
feat(portal): 執行紀錄保留期 UI（P7 補前端，arcrun-rag#21）
...
後端（4ca23c2）已提供 GET/PUT /portal/admin/execution-log-retention，
但管理頁完全沒有對應介面——leo 只能自己 curl。本次補管理頁「執行紀錄保留期」
卡片：顯示目前保留天數、可改天數、可勾「不刪除」（企業稽核）。純薄殼，
零業務邏輯，呼叫既有端點（rule 07 薄殼原則）。
驗證（本機真瀏覽器 E2E，非 curl／非讀原始碼）：
本機起兩個真 wrangler dev（kbdb:18787／cypher-executor:18788，local D1+KV，
真的套用 migrations 0001-0006）＋本機靜態伺服 console-ui/public（18790，
config.js 指向本機 apiBase）＋UI_ORIGINS 加白名單解 CORS。瀏覽器走真實
「首次設定」流程建帳號、登入、進管理頁：
- 預設值：保留天數顯示 90（無資料時退回預設，非空白）
- 改 45 天 → 儲存 → 畫面即時更新「目前設定：保留 45 天」→ reload 頁面仍是 45
- 勾「不刪除」→ 儲存 → 天數輸入框停用、清空 → 顯示「不刪除（企業稽核）」
→ reload 仍是不刪除
- 改回 90 天 → 儲存 → reload 仍是 90（雙向都驗過）
- 全程 Network 面板每筆 GET/PUT 皆 200；console 除了測試前置階段的舊
bootstrap-conflict 雜訊外，無新增紅字
發現但沒動的問題：console-ui 本身沒有本機可跑的 dev/test 腳本
（package.json 只有 deploy/verify），E2E 用的是手工起 wrangler dev +
python http.server 兜出來的，建議之後補一支 `npm run preview:local`
方便下次驗證不用重找路。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-09 13:28:36 +08:00
21be6d19f7
把 .dev.vars 加進 .gitignore——本機密鑰檔原本完全沒被擋
...
實查：cypher-executor/.dev.vars（3 行）與 kbdb/.dev.vars（1 行）都是 untracked
且 git check-ignore 零命中，任何人一次 git add -A 就會把金鑰推上 Gitea。
歷史上沒有被 commit 過，所以是純預防、不需要清歷史。
對齊 D36「金鑰只有一個家」：真身不落在 repo 上，不是靠自律，是拿不到。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-09 13:24:24 +08:00
6846d6ddae
fix(semantic): 故障照實說是故障——不再把壞掉說成「沒開通」（leo 2026-08-09 直令）
...
一、文案（portal/console/kbdb hint）：語意搜尋是一安裝就提供的功能，
降級＝故障。橫幅改「語意搜尋目前故障／我們的問題／你不用做任何事」，
拿掉「還沒開通、想開通請匯出診斷檔」這種要使用者申請開通的假框架。
kbdb 降級回應加 degraded_reason（module_off / embed_query_failed）。
二、查詢向量化失敗不再偽裝成空結果（leo 點名的謊）：
semanticSearch 舊行為「AI 額度用完 → 回 []」會讓使用者以為
自己的知識庫裡沒有這筆資料。改丟 EmbedQueryFailedError，
route 誠實降級 keyword＋照實告知是暫時故障。
三、源頭機制（裝好的實例為什麼會失去語意搜尋）：
- acr update：kbdb_embed 判斷 ===true → !==false。config 缺欄位時
redeploy 會把 [[vectorize]]+[ai] binding 靜默剝掉（wrangler deploy
整份覆蓋），一台正常實例就此壞掉。init 預設同步翻成 [Y/n]。
-（另 repo）deploy-all.mjs ensureVectorizeIndex 失敗改致命中止。
四、順手自癒：孤兒向量/下架殘影搜尋時背景清除；空結果且 pending>0
背景 backfill；no_index 拆「故障」vs「還沒有資料」兩態。
測試：kbdb 146/146（新增 degraded 6 案＋selftest 1 案）；cli 10/10；
瀏覽器端到端兩種故障畫面實測（local wrangler dev＋portal 真登入）。
無 SDD 對應：leo 直令修故障（同 08-07 檢修孔前例的人閘直接授權路徑）。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-09 02:05:12 +08:00
8eb10049b8
P8：節點輸出 KV 寫入只服務 PIPE 讀者——拆掉比 neurons 更短的隱形短板
...
leo 08-09「不需要換模型，要調整每個 CF 數字搭配」。盤點發現真正最短的板不是
Workers AI neurons（119 檔/日），是 EXEC_CONTEXT KV：每節點（含 FOREACH 每圈）
put 一次、rag 工作流一張卡 15 次，但唯一讀點是 PIPE 邊——rag 系全無 PIPE 邊，
15 次全是白燒 ⇒ KV 1,000/日 ÷ 15 ≈ 66 檔/日，兩條路（免金鑰/Gemini）都被卡。
修法＝寫入前檢查「節點有 PIPE 出邊」。PIPE 工作流與 resume 路徑行為不變。
實測（youlin stage）：修前同構卡留 6 node key（15 put）→ 修後零 key，
blocks/triplets 照常寫入。單元測試鎖住兩側行為。
另復原 08-08 重部誤拔的 [ai] binding（extract 501→200，KEEP_AI=true）。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-09 01:26:16 +08:00
831cb62d2e
feat(portal): 拔掉雲端「疑難排解」匯出按鈕，改導向本機小幫手（t213 收尾）
...
leo 08-08：「雲端那個要刪掉？不刪用戶搞不清楚要去哪裏下載」；08-09 追認「通知
完畢可以刪除」——封測者已被通知去更新到有地端匯出的版本（arcrun-app「版本與
更新」頁的疑難排解卡，見 products/arcrun-rag commit 9f1ca58 起），放行條件已滿足。
三處改動：
1. 設定頁「疑難排解」面板：移除 #st-diag-export 按鈕與 #st-diag-status，
改成純文字指路到電腦上的 Arcrun App。
2. 對應的前端 JS 點擊處理（打 GET /portal/data/diagnostics 的那段 IIFE）整段刪除
——按鈕已不存在，留著是死代碼。
3. 語意搜尋降級橫幅（se-banner）：原本也教用戶「到設定→疑難排解匯出診斷檔」，
同步改成指向本機小幫手，否則使用者會照著走進一個不存在的按鈕。
GET /portal/data/diagnostics 端點本身未刪（無害、已無任何 UI 呼叫），純粹清路標
不動後端；已知例外——同步小幫手完全連不上、且封測者是老版本沒有本機匯出時，
會真的無路可走，判斷為可接受（他們已被個別通知升級，且雲端 portal 仍能用文字
指路，不是把人晾在原地不給說明）。
驗證：本機起 static server（config.js 指向 dummy apiBase）＋瀏覽器 JS 強制顯示
setting/search view，實際截圖確認按鈕消失、#st-diag-export/#st-diag-status 在
DOM 裡是 null、文案渲染正確無破版；console 只有 dummy apiBase 連不上的預期錯誤，
無語法/參照錯誤。cypher-executor vitest（portal-data/admin/auth）114 通過、2 個
既有失敗（HTML 殼 404，改動前後一致，非本次影響——用 git stash 前後對照過）。
未部署（紅線：本輪只到本機驗過＋commit＋push gitea，prod 需 leo 開閘）。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-09 01:09:10 +08:00
894d9abeb1
Revert "P8：/portal/daemon/extract 萃取模型 scout → qwen3-30b（真筆記實測：品質不降、額度天花板翻倍）"
...
This reverts commit aa6b899276
2026-08-09 00:51:41 +08:00
3447efc94e
docs(mcp): list_recent_executions 說明文字跟上 P7（保留期），不再寫「無固定保留期」
...
08-07 事故修復後，這支工具的說明文字曾誠實標「無固定保留期」——那時保留期
確實還沒做。前一個 commit（P7）補上保留期可設定（預設 90 天，可調，可設不刪
除），這支說明文字若不跟著改，會誤導以後讀到它的人以為系統仍然無限保留。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-09 00:45:19 +08:00
4ca23c256a
feat(kbdb): 執行紀錄保留期可設定（P7，leo 08-08 confirm）
...
背景：08-07 事故修復（60688c3）已把執行紀錄從 KV 搬到 KBDB/D1（entries 表，
API-as-Wall），解掉「稽核資料放在會揮發、被額度打斷的地方」這個結構性錯誤，
也順帶把 Evan 撞到的 1,070 次寫入牆退到 D1 額度層級。但那次修復留了一個誠實
的缺口：MCP list_recent_executions 的說明文字寫著「無固定保留期」——保留期
可設定這件事還沒做。本次補上。
P7 規格（system-dev/docs/3-specs/pending-changes.md「P7」，leo 08-08 confirm）：
執行紀錄是稽核資料，預設保留 90 天（3 個月）過期即清；租戶可自訂天數，也可
設「不刪除」（企業稽核，leo：「我願意花很多錢保存，不要刪除」）。
實作（kbdb/src/actions/execution-log.ts，牆內）：
- getRetentionDays/setRetentionDays：沿用 execution_log_usage 的 upsert 慣例，
單一 entries 列/租戶（entry_type='execution_log_retention_config'），零建表。
- cleanupExpiredLogs：分兩段掃——有自訂天數的租戶各自 cutoff；其餘（含無租戶）
套預設 90 天，排除「不刪除」與已處理過的租戶。每次呼叫界限刪除量
（CLEANUP_BATCH_LIMIT=500），長期多次呼叫可逐步清完累積量。
路由（kbdb/src/routes/execution-log.ts）：GET/PUT /execution-log/retention、
POST /execution-log/cleanup，沿用既有的 Bearer token 全域守衛（fail-closed）。
清理觸發（cypher-executor/src/scheduled.ts）：不新增排程基礎設施（wrangler.toml
[triggers] 是受保護檔案）——搭 cypher-executor 既有的每分鐘 cron tick 便車，
固定 UTC 02:30 那一分鐘 fire-and-forget 打一次 KBDB 的 cleanup 端點，一天一次，
不是輪詢。
Portal 薄殼（cypher-executor/src/routes/portal.ts）：GET/PUT
/portal/admin/execution-log-retention（role=admin 閘），讓本實例的租戶
（portalTenant）能實際設定保留天數，不只是 KBDB 內部端點。
測試（kbdb/tests/execution-log.test.ts）：新增 27 個測試（含原有測試共 27 通過
於本檔），真 SQLite 驗證 cutoff 邏輯、自訂天數隔離、「不刪除」永不清、壞資料
容錯、混合租戶情境、路由層 400/200。測試治具需要「插入指定 created_at 的過期
紀錄」這個正式寫入路徑刻意不開放的能力，做成 kbdb/src/actions/execution-log.ts
內匯出的 testInsert*/testCount* 函式（牆內執行 SQL），測試檔本身零原生 SQL。
量測（不是推論）：youlin（yuga3bse）實例上，redeploy 後對 graph_neighbors
webhook 發送 1,200 次併發請求（超過 Evan 實測失敗的 1,070 次）——全部 HTTP 200；
ANALYTICS_KV 的 key 數量在請求前後維持 663 不變，證明新寫入路徑完全不碰 KV，
Evan 撞到的那道牆的成因已被物理移除，不只是延後。
讀取端驗證（真呼叫，非 curl）：透過綁定 yuga3bse 的 MCP 連線實際呼叫
arcrun_list_recent_executions（回傳含本次量測寫入的 D1 紀錄）與
arcrun_get_execution_trace（正確回 404 not_found，非崩潰）；portal 前端
（https://arcrun-rag-ui.youlin-hsieh-dev.workers.dev/portal）瀏覽器實際載入 ，
無 console 錯誤、無異常紅色橫幅。
舊資料：KV 裡既有的 stats:* 沿用 60688c3noreply@anthropic.com >
2026-08-09 00:43:55 +08:00
aa6b899276
P8：/portal/daemon/extract 萃取模型 scout → qwen3-30b（真筆記實測：品質不降、額度天花板翻倍）
...
免金鑰路短板＝Workers AI 免費 10,000 neurons/日。leo 真實筆記 8 篇 × 5 模型實測
（arcrun-rag docs/benchmarks/p8-extractor-quality/，usage.neurons 為 CF 原生計量）：
scout 84 n/檔（119 檔/日）→ qwen3-30b 43 n/檔（232 檔/日）；格式合規 8/8、
三元組 7.6 條全可解析（scout 5.0）。granite 最便宜但 5/8 缺段＝實測否決。
聊天 recipe（workers_ai_chat）不動；只 commit 本 hunk，工作區另有 P7 進行中改動未收。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-09 00:40:52 +08:00
466e56bc2d
落帳：youlin 登入修好（瀏覽器實證）＋連線中斷 vs 密碼錯誤是決定性差別
...
含誠實限制：驗的是程式碼修對了，不是安裝器裝出來的結果。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-08 22:15:00 +08:00
07cc7f51b5
fix(cypher): 同一台實例的 portal 一律自動放行，不再依賴 UI_ORIGINS 被注入
...
2026-08-08 事故根因：leo 的 youlin 實例登入整個斷掉，瀏覽器實證
blocked by CORS policy: No 'Access-Control-Allow-Origin' header
真因＝該台 UI_ORIGINS 沒被設。
同一天發生兩次同款：這些變數只有安裝器會注入，任何手動 wrangler deploy
就會漏掉，而漏掉時系統看起來完全正常（worker 上線、200、版本號對），
只有真人點下去才會發現。leo：「這麼危險的問題已經發生 2 次，不可以再有一次。」
⇒ 治法不是「記得注入」，是讓它不需要被注入：portal 與 cypher 是同一個
workers.dev 子網域下的兄弟，位址推導得出來。少一個必須注入的變數，
就少一個會被漏掉的東西。UI_ORIGINS 仍有效（自訂網域用），只是不再是
「登得進去」的前提。
對照：改動前後 tsc 錯誤數同為 7（皆為既有、不在本檔）。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-08 20:47:32 +08:00
42cb1d7aa9
console-ui：把「線上跑的是不是當代的」變成機械判準，並接進部署鏈
...
leo 2026-08-08：「已經發生過一次這個錯誤，把舊版界面上到 prod，
你要確定不可再犯。」
實測（repo 對線上，純文字資產比對）：
repo portal/index.html 343,969 bytes
線上 mira.uncle6.me 82,911 bytes（Songti 12 處，舊金色 serif 品牌）
線上 pages.dev 82,911 bytes（同上）
而 e730b3fe730b3fnoreply@anthropic.com >
2026-08-08 20:36:18 +08:00
e730b3f831
console-ui 部署：宣告值只解讀一次，並補上線上實況驗證（WIP）
...
同源於 2026-08-08 的 apiBase 事故：部署腳本把 apiBase/profile 印在
終端機上，卻沒有寫進推上去的產物 ⇒ 印對的、推錯的。
根因比想像深：deploy.targets.json 原本靠 build.mjs 在 build 期把
profile/apiBase 烤進產物，但 t160（e744ad1）清世代債時把 build.mjs
整支刪掉改成直接託管 public/，沒有人接手「把宣告值寫進產物」這件事
⇒ 前兩次事故的解等於被還原，只剩下「印出來給人看」。
本次落地：
- targets.mjs：宣告值的唯一讀取點，把「一個目標展開成期望的產物長相」
定死成函式，供部署／驗證共用同一個答案，杜絕三邊各自解讀而漂移。
缺 apiBase／accountId／verifyUrls／未定義的 profile 一律拒絕部署。
- verify-live.mjs：獨立可跑，驗「線上網址真的在用的組態」＝「宣告值」。
- deploy.targets.json：補 _profiles（profile → views/home）與 verifyUrls。
WIP：deploy.mjs 尚未改接 targets.mjs，public/config.js 尚未退役。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-08 20:14:20 +08:00
84471659af
docs(portal): 疑難排解按鈕文案改導流（t213，InkStoneCo 總管交辦）
...
這顆按鈕在封測者瀏覽器裡執行，構不到他電腦上 daemon 的本機資料（檔案總量／
失敗分類／daemon 版本）——那半已改在 arcrun-app 本機端匯出（見
products/arcrun-rag commit 9f1ca58）。按鈕本身保留當退路（daemon 完全掛掉時
唯一還按得到的東西），文案改成誠實講清楚自己只有一半、導去完整版，照總管
給的原話：「這裡只看得到雲端這半，完整診斷請到你電腦上的 Arcrun 匯出。」
純文案改動，未動任何邏輯/端點；跑過 portal-data/portal-admin/portal-auth
三份測試，114 通過、2 個既有失敗（HTML 殼 404，測試環境問題，與本次無關，
改動前後一致）。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-08 13:13:06 +08:00
93b1140bf1
feat(portal): 新增 GET /portal/daemon/diagnostics（t213 matrix/arcrun 半部）
...
InkStoneCo 總管交辦（arcrun-rag repo t213）：leo 拿真診斷檔實測四個真實問題，只答得出一題
——其餘三題需要地端資料（daemon 本機 manifest 總量／失敗分類／自我更新狀態），而現有
GET /portal/data/diagnostics 只有 portal session 認證，daemon 背景行程沒有 session
（密碼只在連線精靈當下用過就丟，不落地），構不到這支端點。
本次只做 matrix/arcrun 半部（雲端這半）：
- 把 /portal/data/diagnostics 的核心查詢邏輯抽成 buildDiagnostics(env, tenant)
（portal.ts），薄殼原則：能力只實作一次
- 新增 GET /portal/daemon/diagnostics，認證比照既有 /portal/daemon/extract
（X-Arcrun-API-Key，非 session）；apiKey 當 owner_id 用，不與 portalTenant(env)
比對（t189 教訓：daemon 的 api_key 不保證等於 worker 的 CONSOLE_TENANT）
- /portal/data/diagnostics 改呼叫共用函式，回應形狀完全不變
- 按 leo 指示刪掉「需在失敗當下由封測者截圖」那句 notes（本機那半資料到位後這句話
失去意義）
地端那半（arcrun-app 讀 manifest 合併 + 匯出按鈕）在 products/arcrun-rag repo 進行，
待另一隻處理 t210 的 agent 落地 app.go/main.js 改動後再接線，本次不動 arcrun-app。
驗證：
- npx tsc --noEmit：與 stash 前錯誤數相同（4 個），零新增（pre-existing，與本次改動無關）
- npx vitest run：314→315 通過（+3 新測試涵蓋 401／apiKey 當 owner_id 不比對 tenant／
回應形狀與 session 版一致），14 個既有失敗與改動前完全相同（HTML 殼 404，測試環境
static asset 問題，與 portal.ts/portal-data.ts 邏輯無關）
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-08 12:32:10 +08:00
962d863ef7
fix(kbdb): 藏書地圖 M3 收尾——讀端自動核對重算，不再依賴 ingest 接鏈
...
真因（總管實測，system-dev/wiki/mistakes.md 08-08 段）：design 原訂「ingest 尾端呼
POST /map/recompute」，但 repo 內查無任何呼叫點，三週沒接上，沒手動 backfill 過的租戶
（絕大多數）GET /map 恆回空；MCP 說明文字還宣稱「地圖由 ingest 尾端自動重算（M3）」——假話。
leo 否決「降級成即時聚合、不維護快取」的提案（會丟失 narrative 這類摘要本體，只算得出
count）。改法：GET /map／GET /map/:library 讀端自己核對即時三元組數，落差就地呼叫既有的
recomputeLibraryMap 補算（kbdb/src/actions/library-map.ts ensureFreshLibraryMaps）。聚合
SQL 沒有第二套、narrative/relation_profile/bridges 摘要欄位原封不動，只是觸發時機從「等
外部呼叫」改成「讀的當下順手核對」。同時解掉：全租戶自動 backfill／跟得上新資料／不依賴
跨 repo 的 ingest 接鏈。
附帶修 recomputeLibraryMap 的 narrative 欄位：沒帶值時原本會清空，改成沿用上一版（避免
自動重算把 ingest 端/人工填過的 narrative 靜默洗掉）。
修正三處說謊的說明文字（mcp/src/tools/kbdb_map.ts、console-ui console/index.html）：
「地圖由 ingest 尾端自動重算（M3）」不存在，改為誠實描述讀端即時核對機制；404 語意從
「從未 recompute」改為「查無此庫」（已知但空的庫現在會自動補成 triplet_count:0 的 200，
不會落到 404）。
測試：kbdb 新增 6 案（18/18 全綠，覆蓋自動 backfill／跟得上資料／narrative 保留／
404 vs 空庫誠實分辨／owner 隔離／無 triplet template 不報錯）；mcp 新增 1 案釘住舊謊言
不再出現。kbdb 125/125、mcp 69/77（同基線 8 個 oauth 既有失敗，非本次引入）全綠；
tsc 兩包乾淨（kbdb 1 個既有 auth.test.ts 錯誤與 stash 前一致，非本次引入）。
SDD：system-dev/docs/3-specs/library-map/tasks.md M3 從「07-19 誤標 ✅ 」更正為實況；
design.md §3 加 2026-08-08 更正說明。未動 frontmatter status（仍 draft，D35 生命週期
鐵律留給總管/leo 裁）。
殘項：本次修改只在本機驗證（真 SQLite + 假 binding 單元測試），未部署 prod；未在真實
KBDB（如 yuga3bse 租戶）重新實測 kbdb_get_map 非空——需部署後才能貼實測輸出。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-08 00:44:55 +08:00
7dbd4f59e7
fix(portal): 檢修孔 library_count/triplet_count 恆 0 的根因＋加統計自我檢查
...
真因：/portal/data/diagnostics 讀 GET /map，那是 library_map 快取 block，只能
靠 POST /map/recompute 產生；核實過整個 repo 沒有任何呼叫點會打 /map/recompute
（library-map SDD 的 ingest 自動重算 M3 從沒接上，status: draft）。⇒ /map 對任何
租戶恆回空 libraries，與實際資料量無關——2026-08-07 leo 實測抓到：3 庫、大量
triplets，診斷檔卻回 0/0。
修法：改走 GET /portal/admin/libraries 已在用、驗證過的即時查詢組合（不依賴任何
快取）：listRecordsByTemplate(portal_library) ＋ /entries/libraries（t52 蓋章即
現身）＋ /records/triplet-stats（t142 即時聚合 SQL）。
附帶：加 library_scope_check 統計自我檢查（呼應 embedding.self_test 的精神）。
兩個計數都是 0 時，用完全不同的查詢路徑（不分庫/模板，只問這個租戶底下有沒有
任何 entries）交叉驗證，區分「真的是空」與「查詢方式或 owner_id 對不上」
（2026-08-01 t161 前科同型病：手動補的 record owner_id 存成 None，全量查得到、
按 owner_id 過濾的畫面永遠空）。
三個 diagnostics 測試全綠：即時查對出正確 library_count/triplet_count（且不再
外流庫名/內容，只回數字）、真空情境自我探測誠實回空、t161 同型病情境自我探測抓到
「查得到但統計回 0」的矛盾。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-08 00:12:54 +08:00
d779a11958
gitignore 掉 deploy-all.mjs 產的 package.json／lock
...
名字是 arcrun-deploy-shared，是本機跑 installer/scripts/deploy-all.mjs 時
npm 為了 wrangler 等依賴生出來的，不是 repo 內容。
每次本機部署都會冒出來吵未推警察 => 加 gitignore 而不是刪
（刪了下次部署又會產生）。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-08 00:10:59 +08:00
c7a0b317cb
fix(kbdb): 補 kbdb/src/routes/entries.ts 缺的自癒搬遷 hook（上一commit漏了這支檔）
...
上一個 commit（046ceba）訊息宣稱改了 entries.ts 但實際只有測試檔進了 git——
entries.ts 的 migrateLegacyCredentialsForOwner 呼叫留在工作區沒進 index
（同一份工作目錄有另一個 session 併行在改這支檔案的語意搜尋空結果診斷功能，
兩邊的 import 改到同一行，第一次 commit 時漏收）。這次補上：
- import migrateLegacyCredentialsForOwner，GET /entries 對 entry_type=
credential 觸發自癒搬遷（見 046cebanoreply@anthropic.com >
2026-08-07 22:53:51 +08:00
046ceba29c
fix(kbdb): credential 目錄自癒搬遷（D38 收尾）——修 youlin 20/20 全敗事故
...
根因（2026-08-07 youlin 測試實例）：7ba7855 把 credential 讀寫端從舊表
credentials（0002）改走 KBDB entries（entry_type='credential'），但舊表
資料的搬遷 migration（0006）要人手動觸發部署才會跑。實查 youlin 的 D1：
credentials 表有 1 筆（yuga3bse/kbdb_internal_token），entries 對應筆數
為 0——新讀取端上線、舊資料還沒搬，20 次 workflow 全部找不到 credential。
leo 追加硬要求：credential 資料住在用戶自己的 CF 帳號，換讀取路徑＝每個
既有實例都要遷移，但用戶不准做任何手動步驟——搬遷必須內建在既有更新流程
裡、天然無感。
解法（kbdb/src/actions/credential-legacy-migration.ts）：把「搬」變成
「讀」的副作用而非獨立步驟。KBDB worker（D38 唯一允許碰 SQL 的牆內）在
每次查詢某租戶的 credential 目錄前，先確認舊表資料是否已搬進 entries
——沒有就搬（per-owner scoped、NOT EXISTS 冪等），有就是零成本的
sqlite_master 短路檢查。呼叫時機掛在 GET /entries?entry_type=credential
（cypher-executor 熱路徑本來就會打的端點），故只要更新 KBDB worker，
下一次任何人跑 workflow 該租戶就自動搬好，不需要用戶或安裝器多做任何事。
刻意不執行退場（DROP TABLE）——多個實例搬遷時間點不同，舊表留著才能讓
「已搬」與「還沒搬」的實例同時安全運作；退場留給之後獨立的清理步驟。
kbdb/tests/credential-legacy-migration.test.ts：反向驗證重建 2026-08-07
事故的確切前置狀態（真 SQLite + 0001/0002/0005 migration 原檔），證明補丁
加入前 entries.length 回 0（事故重現），加入後回 1（修好）；另驗冪等
（連呼叫三次不重複搬）、多租戶互不干擾、舊表已清理時的終態安全。
cypher-executor/tests/credentials.test.ts：補齊 7ba7855noreply@anthropic.com >
2026-08-07 22:51:31 +08:00
ac4fb56c91
portal 前端文案：語意搜尋降級提示改講人話＋entry_type/mode 不再吐原始英文值
...
封測者 Oscar 回報「語義搜尋搜不到」，追查發現 portal 使用者實際會看到的降級提示
其實是後端 kbdb capability_hint 直接透傳（寫給工程師看的：「叫 CC」「vectorize」
「kbdb_embed:true」「redeploy」），比 UI 裡原本的 fallback 文案還難懂。
- se-banner：不再透傳後端 capability_hint，前端固定顯示「發生了什麼＋現在怎麼辦」
（語意搜尋還沒開通→以下是關鍵字結果→到設定頁疑難排解匯出診斷檔給我們）
- 新增 entryTypeLabel()：entry_type 原始值（wiki_card/block/execution_log…）
不再直接印給用戶看——尤其 wiki_card 原樣顯示會打臉上傳頁自己講的「AI 整理後
會以 wiki 卡形式出現」
- 新增 searchModeLabel()：搜尋結果「模式 keyword/semantic」的英文值改顯示
中文（關鍵字/語意/圖譜），AI 問答來源標籤同步套用
不動 console/index.html（僅供部署擁有者/維運者使用，非客戶介面，根目錄
index.html 明文寫「不該對客戶露出」，同類字眼在此屬合理專業詞彙，故不改）。
不動 cypher-executor/src、kbdb/src（另一 agent 正在改 credential 路徑；
真正的降級文案根因在 kbdb/src/routes/entries.ts 的 capability_hint，
已另行回報總管，非本次改動範圍）。
已用 installer/scripts/build-ui-bundle.mjs 打包驗證：新文案進 bundle、
舊文案消失，entryTypeLabel/searchModeLabel 均實際生效（非死代碼）。
2026-08-07 22:38:07 +08:00
1e2ef6806a
wiki: 落帳檢修孔第一版（embed selftest + diagnostics 端點 + 匯出按鈕）
...
記錄 2026-08-07 三個 commit（9344562/83aa1f6/5388f40）的狀態、端到端實測方式、
測試結果，以及未完成項（未 push GitHub 待 D20／Oscar 需自行按「立即更新」）。
一併誠實記錄收工時發現本機既有背景機制會把 commit 鏡到 Gitea（非本次操作觸發）。
2026-08-07 18:52:30 +08:00
5388f40c03
feat(portal-ui): 設定頁「匯出診斷檔給我們看」按鈕（檢修孔前端，2026-08-07）
...
leo 直接指令的簡化版規格：一顆按鈕、按下去下載一個檔案、用戶自己把檔案傳出去——
同意天然內建在「他自己按、自己傳」這個動作裡，不需要額外授權流程或內部概念外露。
按鈕打 GET /portal/data/diagnostics，把回應存成單一 JSON 檔（不是要解壓的一包）
直接觸發瀏覽器下載，檔名帶時間戳。沿用既有 authHeaders/safeJson/guard401/friendlyErr
helper（與同頁其餘按鈕同一套錯誤處理慣例）。
既有前端輕量測試（safejson.test.mjs／os-split.test.mjs）跑過，18/18 全綠，未受影響。
2026-08-07 18:39:30 +08:00
83aa1f6bb2
feat(portal): GET /portal/data/diagnostics —— 檢修孔聚合端點
...
leo 2026-08-07 直接指令：「一顆按鈕在設定裡，按鈕下載一個檔案，把檔案發給我，你看那個
檔」。本端點是那個檔的資料來源：聚合 embed 模組健康狀態（module_enabled/cards_embedded/
cards_pending/self_test）、知識庫規模（library_count/triplet_count）、bundle_version、
instance_url。
紅線落實：
- 只轉發數字/布林/字串狀態，KBDB /map 回應裡的 narrative/top_entities（卡片內容）讀出
triplet_count 後即丟棄，測試 portal-data.test.ts 新增案專門斷言回應不含內容字樣。
- 認證沿用既有 requirePortalUser session 閘，不對外公開。
3 個新測試全綠（未登入 401／完整聚合含隱私斷言／embed 未開時誠實回 false 不假裝）。
既有 1 個失敗案（/portal HTML 殼 404）為 stash 驗證過的既有失敗，與本次改動無關。
2026-08-07 18:38:03 +08:00
9344562258
feat(kbdb): embed 自我檢查端點（檢修孔第一塊，2026-08-07 leo 直接指令）
...
GET /embed/selftest?owner_id= —— 挑一筆已標記「已嵌入」的卡片，拿它自己的內容做一次
真實語義查詢，檢查「自己是否搜得到自己」。backfillStatus 的 pending/embedded 計數
看不出 Arcrun#11 那種「嵌了但查不到」的故障模式（metadata index 事後才建、既有向量
沒被收錄），本端點是唯一能端到端驗證 index 真的可用的方法。
隱私邊界：只回 {enabled, tested, passed, note} 四個布林/字串欄位，不回卡片內容、
不回 entry id（測試 embed-selftest.test.ts 最後一案專門斷言不洩漏）。
12/12 kbdb vitest 全綠（含既有 embed-backfill 6 案未壞）。
2026-08-07 18:35:06 +08:00
7ba78552a4
D38：credential 目錄改走 KBDB API（零原生 SQL）＋舊表退場；測試刻意留紅燈
...
存取層：credentials.ts / auth-dispatcher.ts / portal.ts 全改走 kbdbBase()+fetch
到 /entries（照 execution-logger.ts 既有慣例），.prepare/.exec/.batch 命中 0。
資料層：0005 seed credential template；0006 把舊表資料搬進 entries 後拆表；
0002 標退役、deploy.ts 不再套用（加 kbdb-sql-ok 留痕，純歷史對照）。
總管親驗四項（不聽 agent 自評）：
1 三個檔 .prepare/.exec/.batch 命中 0；六個檔全部通過 kbdb-api-wall-guard
2 0006 的 INSERT 欄位（id/entry_type/owner_id/page_name/metadata_json/
created_at/updated_at）與 0001_base 的 entries 表逐一對得上
3 不可逆風險查官方：D1 batch 是 transaction、任一句失敗整批 rollback；
exec 出錯則「執行停止、後續不執行」=> 兩種語意下 INSERT 失敗都不會跑到
DROP TABLE，用戶 credential 目錄不會遺失
4 0006 搬在拆之前、冪等（NOT EXISTS 防重複）、豁免標記有留痕且理由正當
（拆表是牆內施工，API 不提供也不該提供拆表）
🔴 抓到一個假綠並修正：agent 中途被中斷，把 111 行的 credentials.test.ts
砍成一行「// placeholder — see edit below」，那個 edit 從來沒發生，
且 setup.ts 被刪。vitest 對這種檔案回報「Tests: no tests」，
很容易被讀成「沒失敗＝通過」——正是 CP 記過的
「這條 route 曾整條消失過沒人發現」同型。
處置：還原 setup.ts/vitest.config.ts，credentials.test.ts 改成
**刻意會失敗的紅燈**並在檔頭列出要補的五項。空檔會被誤認為綠，紅燈不會。
未部署。本批要先上 stage 驗過才進 prod（leo 08-07 定）。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-07 17:27:18 +08:00
60688c3108
fix(kv-quota): workflow 執行紀錄搬離 KV，改走 KBDB template 機制（A1/A2/A7）
...
事故：cypher-executor/src/actions/execution-logger.ts 舊版每跑完一次 workflow 就
ANALYTICS_KV.put() 一筆新 key（註解寫「避免覆蓋」）= 只增不減，封測者 Evan 處理約 690 個
檔案就把 KV 免費層 1,000 write/日打爆（實測 1,070 write），整個實例 429。
A1 少記：workflow 執行紀錄改走 KBDB template 機制（entries 表 entry_type='execution_log'，
kbdb/migrations/0004_execution_log_template.sql 只 seed 一列 template 定義，零建表/改表）。
儲存精神比照既有 recipe_stat（kbdb/src/actions/recipe-stat.ts）：template 只負責文件化，
實際一筆執行是 entries 表一列（1 次執行=1 次 D1 寫入，不走 entry_values 全展開）。欄位收斂：
時間/workflow/verdict/duration/錯誤訊息/(可得的)目標；成功記最少，失敗多記（訊息截斷長度
不對稱：200 vs 2000 字）。target 只認 trigger context 的 page_name/path，不整包存 input。
A2 自我降級：D1 額度仍與知識卡共用同一顆 100,000 rows/日，本模組自設 20% 軟上限（可用
EXECUTION_LOG_DAILY_WRITE_LIMIT 覆寫），超過 80% 降成只記失敗、超過 100% 完全停止記錄，
但 workflow 執行永遠照跑（cypher-executor 端 fire-and-forget 永不 throw）。
A7 讀取端：/workflows/:name/executions、/portal/data/workflows 的 last_execution、MCP
list_recent_executions 全部改打 KBDB HTTP API（GET /execution-log、/execution-log/latest），
取代原本的 ANALYTICS_KV list/get（免費層 list 也是 1,000/日）。
架構鐵律修正（本次施工中兩度被抓到走偏，過程留痕於 commit 訊息供後續參考）：
- KBDB 三張表打天下（entries/templates/entry_values），永遠不加新 table——新資料類型
一律用 template + entries，不建表、不 ALTER TABLE。
- KBDB = API-as-Wall，零 SQL：cypher-executor 端一律走 KBDB 的 HTTP API（連法比照既有
recordRecipeStats/kbdbFetch 慣例），不直連任何 D1、不對 arcrun-kbdb 下任何原生 SQL。
順帶修復：kbdb/src/actions/entry-crud.ts listEntries 的 ORDER BY 補 `, rowid DESC` 二級
排序——entries.created_at 是 unixepoch() 秒級解析度，高頻寫入（execution_log 一秒內多筆）
常同秒，單靠 created_at DESC 不保證「最新一筆」正確，此為本次測試（latestExecutionLog）
發現的既有潛在缺陷，順手補上決定性排序，不改變任何既有查詢在 created_at 不同時的行為。
隔離：portal-data.ts INTERNAL_ENTRY_TYPES 加入 execution_log/execution_log_usage（與既有
value/workflow 同層級排除），避免用戶知識搜尋混進執行 log；本模組從不設 metadata_json.embed，
故永不進 Vectorize 語意搜尋索引。
不動：registry/src/actions/recordAnalytics.ts（零件市場統計，獨立 Worker、獨立 KV 命名空間、
不同資料模型，非本次事故根因所指範圍）；cypher-executor/{wrangler.toml,kbdb/wrangler.toml}
未變動（repo 層級 deny 規則保護這兩個生產設定檔不被 AI 編輯）——ANALYTICS_KV binding
因此仍留在 wrangler.toml 宣告中但程式碼零讀寫點（見 PR 說明的完整 grep 佐證）。
KV 裡既有的 stats:* 舊資料不搬移（是統計不是真相源，維持原樣任其依 90 天 TTL 自然過期）。
測試：kbdb/tests/execution-log.test.ts（13 個，含零建表證明/少記/A2 降級/route）、
cypher-executor/tests/execution-logger.test.ts（payload 正確性/永不 throw）、
cypher-executor/tests/executions-route.test.ts（讀取端轉發）、portal-data.test.ts 對應區塊
改寫。kbdb 全測試 104/104 通過；cypher-executor 320 個測試中 9 個失敗為 main 既有（與本次
改動無關，改動前後 stash 對照確認）。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-07 16:13:00 +08:00
36a5630c63
portal 顯示同步器版本＋下載網址改讀真相源（leo 08-06）
...
leo：「Portal 和 rag.arcrun.dev 應該顯示同步器的版本⋯⋯因為你說最新 0.18.5
連我都沒辦法確認，所以用戶到底是否最新版他自己也不知道」。
## 病
release（雲端知識庫）與 daemon（桌面同步器）是兩條版本線。
版本卡只顯示前者；下載按鈕的檔名是寫死的固定別名
（DAEMON_MAC/DAEMON_WIN）⇒ 頁面上完全看不出「同步器是哪一版」。
## 改
- 下載網址改向 /api/latest 取 daemon.downloads（真相源＝bundles manifest），
取不到才退回原本的固定別名 ⇒ 按鈕永遠可用。
⚠️ 沒有違背 fe0ee82
2026-08-06 13:12:15 +08:00
05b215c9f7
語意門檻改相對式＋下架連帶刪向量（leo 兩個實測回饋）
...
## ① 「關懷型 AI 命中 20 筆、只有前 3 筆相關」⇒ 閾值太寬（leo 判斷正確）
固定門檻兩頭都不對，因為每個查詢的分數尺度不同（實測 youlin 實例）：
關懷型 AI 正解 0.645-0.770，雜訊起於 0.547 ← 固定 0.5 放進 6 筆雜訊
閉環機 正解 0.552-0.638，雜訊起於 0.446 ← 固定 0.6 砍到剩 2/4（＝早上的 0 命中）
人力媒合系統規劃書 正解 0.842，雜訊起於 0.550
⇒ 改**相對門檻** max(0.45, top×0.8)。五組實測：固定 0.5 混入 9 筆雜訊／
固定 0.6 有兩組正解被砍／相對式四組雜訊 0 且正解全留。
## 🔴 寫測試才發現的真問題：門檻不能在 Vectorize 那層算
Vectorize 的 indexed metadata 沒有 status ⇒ 那層不知道誰已下架。
若最高分是下架殘影（t24 復現案 0.971），拿它算門檻＝0.777，
會把 0.6 的正解一起砍光 ⇒ **又變成 0 命中**。
⇒ 相對門檻移到 routes/entries.ts，接在「hydrate＋濾下架」之後；
embed.ts 只留絕對下限。新增測試鎖住這個順序。
## ② leo：「理論上它的向量也要刪掉，就不會有殘影了吧？」——對，補上
單筆真刪已接 deleteByIds（b7af622），但「移除整個庫」走軟刪、向量原地不動。
⇒ deprecate-by-library 同時 deleteByIds ＋ is_embedded 歸零（D1 與 Vectorize 不說兩套話）；
backfill 兩條路徑（含 reindex）都排除 deprecated，否則下次補嵌會把殘影養回來。
不違背 t135「資料保留可還原」：D1 那列原封不動，還原後跑 backfill 重嵌即可。
回應新增 vectors_deleted，刪失敗誠實回 0 不假裝清乾淨。
驗：kbdb 91/91 綠（新增 4 項相對門檻測試，含「下架殘影不得決定門檻」）
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-05 18:47:10 +08:00
0ff369f818
修語意搜尋全 0 命中：分數門檻沒跟著 bge-m3 換代（換模型漏掉的第五處）
...
leo 2026-08-05 實撞：「新上傳的『loop-engine-north-star.md』語義 0 命中，
但舊的『人力媒合系統規劃書』語義 2 命中」。
## 根因不在向量——向量是好的
直打 Vectorize 實測（youlin 實例、bge-m3、1024 維 index）：
搜「閉環機」→ loop-engine-north-star.md 穩坐第 1-4 名（0.638/0.603/0.588/0.552）
D1 與 Vectorize 也對得上：659 筆 embeddable 全 is_embedded=1、index vectorCount 659。
真兇是 **min_score 門檻綁在舊模型的分數尺度上**：
舊 bge-base-en-v1.5：中文分數全擠 0.65-0.90（沒區辨力）⇒ t183 取 0.75 砍雜訊，對
新 bge-m3 ：尺度整體下移（相關 0.5-0.85、雜訊 0.4 上下）⇒ 0.75 砍掉的是正解
leo 看到的「舊檔中、新檔不中」由此而來——「人力媒合系統規劃書」拿 0.842 僥倖存活，
其餘全被門檻掃掉。08-05 換 bge-m3 的「四處同步」清單（embed.ts／deploy.ts／
deploy-all.mjs／worker.js）**漏了這第五處**，因為它不在 kbdb 而在 portal 呼叫端。
## 改動
· kbdb/src/embed.ts：新增 DEFAULT_MIN_SCORE=0.5，**緊鄰 DEFAULT_EMBED_MODEL**
——門檻是模型的性質，放模型旁邊，下次換模型的人一定會看到
· cypher-executor/src/routes/portal-data.ts：拿掉硬寫的 0.75，
只在使用者顯式指定時才傳 min_score（不再各自持有一份數字＝不再漂移）
· console-ui/public/portal/os-split.test.mjs：修好被今天 fe0ee82noreply@anthropic.com >
2026-08-05 18:00:43 +08:00
fe0ee8296a
portal 下載 Mac 版改給 DMG（拖進 Applications），不再給 zip
...
leo 2026-08-05：「Mac 強調要包裝成 application + dmg 的格式，拖進去就會放到
application，**解決之前直接在下載資料夾啟動造成更新問題**」
## 病（實查證實）
manifest 已有 mac_dmg 欄，DMG 也上傳了，**但 portal 下載按鈕仍指 zip**：
DAEMON_MAC = 'ArcrunRAG-mac-unsigned.zip'
用戶端實抓該 zip → 解開就是 Arcrun.app ⇒ 很可能直接在「下載」資料夾雙擊啟動，
正是 t184（Oscar）那個「更新完又跳回舊版」的病灶。
## 修
· DAEMON_MAC → 'ArcrunRAG-mac.dmg'（**固定檔名**，否則每出一版都要改 code）
· Mac 安裝提示改成 DMG 的步驟：「開啟後把 Arcrun 拖進『應用程式』，再從啟動台開啟」
（zip 版的話術是「右鍵→打開」，步驟不同不能沿用）
## 說明：App 端的更新邏輯本來就修好了
selfupdate.go 已改成更新「正在跑的那個 .app」（runningAppBundlePath），不寫死
/Applications ⇒ 放哪都更新得了。本次補的是**入口**：讓使用者一開始就放對位置。
## ⚠️ 殘項（未送達）
bundles repo 目前**只有帶版號的 DMG**（ArcrunRAG-v0.18.4.dmg），
**沒有固定檔名 ArcrunRAG-mac.dmg**（實測 404）⇒ 這行改動要等出貨時
一併產生固定檔名副本才會生效。出貨需 D20 開閘。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com >
2026-08-05 16:35:02 +08:00
b9b5d98d75
併 bge-m3 換代（#59）＋補上分支漏做的另一半：Vectorize index 也換
...
leo 2026-08-05：「換 embed model 當然要合併，當然要換 vectorize，**原本的根本不能用**」
——我把已拍板的事當成待裁決，錯了。
## 為什麼非換不可（08-03 leo 拍板，5 組中文測資實證）
@cf/baai/bge-base-en-v1.5 768 排序正確 2/5 margin -0.0413 1660ms ← 舊
@cf/baai/bge-m3 1024 5/5 +0.1410 959ms ← 新
舊英文模型嵌中文：分數全擠在 0.65-0.81，區辨力接近沒有＝**根本不能用**。
## 🔴 分支只做了一半，另一半我補上
feat/embed-model-m3-t59 只改 kbdb（embed.ts / types.ts / 測試），**完全沒動 deploy.ts**
⇒ 就算合併，安裝器仍會建 **768 維的舊 index**，新向量根本收不進去。
（git show f3af5d3noreply@anthropic.com >
2026-08-05 13:46:33 +08:00
3d21bf0725
移植 t21 溯源 scheme 相容：kb:// 不造死鏈（救自已刪分支）
...
## 這條與 t195 直接相關
新 ingest 鏈（rag_ingest_card／rag_ingest_direct，就是我今天在修的收卡鏈）
寫的 metadata.source 是 **kb://<path>**，但 main 的 portal 溯源只認 gitea://
⇒ 卡片上傳成功後，**溯源連結一律失效**。
原修補在 fix/portal-source-scheme-t21（07-24），一個月沒併回 main。
該分支的檔案 console-ui/src/portal-ui.ts 已被重構搬走（UI 搬 CF Pages），
⇒ 不能直接 merge，**移植邏輯到現行的 console-ui/public/portal/index.html**。
## 三種 scheme 的正解（照原分支設計）
· gitea://<path> 舊 rag_ingest v2 → {base}/<path>，行為一字不變（不回歸）
· gitea:<org/repo>@<path> km-wiki-ingest 實形 → {base}/<org/repo>/src/branch/main/<path>
· kb://<path> 新 ingest 鏈實形 → **回空字串＝維持純文字，不造死鏈**
（雲端沒有對應網頁；另給 srcLocalPath() 取本地相對路徑顯示）
## 實測四情境（抽出函式跑 node）
gitea://docs/a b.md#3 → https://…/base/docs/a%20b.md ✅ 錨點捨棄+編碼
gitea:Leo/kb@notes/x.md#seg01 → https://…/base/Leo/kb/src/branch/main/notes/x.md ✅
kb://wiki/cards/policy.md → ✅ 不造死鏈
srcLocalPath(kb://…#seg02) → wiki/cards/policy.md ✅
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com >
2026-08-05 13:38:19 +08:00
5783420fcf
併 feat/harness-content-refresh：install-harness 升現世代＋世代閘
...
leo 2026-08-05：「Arcrun 是它的父層，這裏的問題也影響 Arcrun RAG」。
main 的 cli/harness/ 停在 06-15，分支是 07-31 的升級（676 行實質改動）：
· cli/scripts/check-harness-generation.mjs（130 行）＝**世代閘**——
與今天救回的 build-bundles 落後閘同族，都是防「發舊版給用戶」
· cli/scripts/build-harness-skill.mjs（64 行）
· CLAUDE.block.md／commands/arcrun.md／hooks/arcrun-guard.sh 交付內容升級
自動合併零衝突。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com >
2026-08-05 13:35:56 +08:00
Leo
1eefce952b
docs: 零件/binding PR 審核規範——結構性防架構錯誤(不靠記規則):A反過度工程(D27)/B binding層級(D28)/C contract/D驗證誠實/E部署資料鐵律/F走PR+機械化CI補強
2026-08-05 13:33:56 +08:00
6c5706ba7d
補上合併漏收的修改檔（t189/t181/CIS portal 本體）
...
上一筆 5d7880623f2fd4noreply@anthropic.com >
2026-08-05 13:31:57 +08:00
5d78806806
併 fix/cis-round3-portal 進 main：CIS 視覺＋t181/t183/t189 收口
...
## 為什麼現在併
leo 2026-08-05：「完工、下班，都要把所有東西整理乾淨，沒推的要推、沒合併要合併」
「至少在 gitea，我不要看到還有沒處理的 PR 或分支」。
這條是 arcrun 的**現役工作分支**（領先 main 15 筆、只落後 3 筆），
含的都是已驗過的東西：
· CIS 第三輪：portal 換色票／真向量 wordmark／favicon 三件套／裁淨版 lockup
· 底色與字形對齊 landing（Paper #FDFCFB／Canvas #F2F1ED，9 處明體→無襯線）
· portal 設定頁版本卡（落後紅點＋一鍵更新，t154 免辨識碼）
· t176 套到 CIS 版 portal（刪 AI 設定區塊）
· t181：POST /portal/daemon/extract——daemon 萃取走 Workers AI（免金鑰）
· t183：語意搜尋補 min_score=0.75
· t189：/portal/daemon/extract 拿掉 tenant 等值比對（geek6688 萃取永遠 401）
· 移除誤入版控的 cypher-executor/node_modules 自指 symlink
落後的 3 筆＝剛併進 main 的 PR#22（純文件）⇒ 自動合併零衝突。
## 測試對帳（合併前後比對，非只看合併後）
合併後：Test Files 4 failed | 22 passed；Tests 9 failed | 301 passed
合併前（純 main 同樣跑一次）：Test Files 4 failed | 22 passed
⇒ **9 fail 是既有債，非本次合併造成**（與 D36 那次 commit 記載的既有債一致）。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com >
2026-08-05 13:29:15 +08:00
1b6b775c0e
Merge commit '5491409003ff'
2026-08-05 13:21:09 +08:00
66f1b59f7f
t176：雲端不再管地端 LLM 設定（leo 08-03 緊急）
...
leo 回報四件事：①雲端 Gemini 無法用 ②搞不清楚設定 AI 是設雲端還是地端
③地端不會萃、每個人都死掉因為都去抓 Claude ④雲端還要設置明明就有 Workers AI。
目標：「雲端裝好就能用，地端輸一個 Gemini API Key，然後就開始用。」
根因：extractor_config 的 KV key 由 portalTenant() 組出，而 portalTenant 是
**worker 層級**環境變數（portal.ts:43）⇒ **全租戶共用一把**。任一處設了 claude，
所有人的 daemon 都收到 claude；沒裝 Claude Code 的機器萃取全滅，而 portal 的
Claude 勾選框又恆 disabled（daemon 從未實作 report-capabilities ⇒ daemon_caps 永遠空）
⇒ 用戶自己解不開（awindhon 08-03 實證：雲端同步成功、金鑰有效、零張卡）。
本次（雲端側）：
- POST /portal/daemon/config **不再下發** extractor／gemini_api_key／llm_model，
只回連線欄位。⚠️ route 本身與 daemon/libraries 資料夾管理完全不動（leo 明確劃界：
「雲端拉地端檔案夾部分不要刪，刪掉從雲端設置地端 LLM 選項部分」）。
- 移除 POST|GET /portal/admin/extractor（t122）——這是「雲端指定地端引擎」的入口，
且無任何伺服器端驗證，打一下就能把全租戶設成 claude。
- 移除 POST /portal/daemon/report-capabilities（t131）——daemon 端從未實作該呼叫。
- 移除 t131 那組重複註冊的 /portal/admin/ai。**它是重複 route**：後段（arcrun-rag#10）
另有同路徑一組，Hono 先到先比 ⇒ 舊的一直贏，後段修好的「金鑰真的寫進 credentials」
形同死碼。保留後段那組（只管 Gemini 金鑰、走 storeCredential），並拿掉 Claude 偏好欄。
- portal 設定頁「AI 設定」整塊移除，改成一句話說明：雲端不需設定（Workers AI 免金鑰），
地端請在同步小幫手的「AI 設定…」填 Gemini Key。順手清掉 main 上既有的 conflict 標記。
- 清掉隨之孤兒化的 helper（ExtractorConfig／AiConfig／DaemonCapabilities／
syncExtractorFromAiConfig／readAiPref 等）。
測試：**相對 merge 前 main 基準線，新增失敗 = 0**（基準線本就 9 紅：console 藏書地圖 6／
portal HTML 殼 2／POST execute 1，皆與本次無關）。t122/t131 兩組測試改寫成
**回歸守衛**（斷言那些端點/欄位確實 404、確實不存在），不是刪掉充綠。
順手修 health bundle_version 測試與實作對齊（實作刻意省略該欄，測試卻期待空字串）。
未送達：本 commit 只到 code，尚未部署上線。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com >
2026-08-03 22:11:45 +08:00
uncle6me-web
Leo