37e13fc9bf
merge: 併入 main 最新（b6ef0f0 三元組 library 補標 proxy＋測試）保持分支不落後
2026-08-11 18:46:03 +08:00
674e1b4fa2
fix(kbdb): D69 節流世代核對＋標庫共用 D1 額度，補「挑哪一批」的統一 SelectionCriteria（Arcrun#85）
...
leo 逐行複核 fix/embed-backfill-d68 後點出的破口＋二次裁決（票上全文見 Leo/Arcrun#85）：
一、向量化優先序（今天寫的立刻／本週在跑的先跑／有查詢紀錄的庫優先／半年前慢慢跑）表達
不出來——策略要能從外面（工作流）指定，不能焊死在資料層。新增 embed.ts 的
`SelectionCriteria`（owner_id/source/library/since/until）,backfillEmbeddings 與
reconcileEmbedGeneration 共用同一套形狀；「按庫」那一層現在有資料可用即可運作（見下）。
二、世代核對（reconcileEmbedGeneration）不打 AI 但逐筆寫 D1，47 萬筆候選 ≈ 4.7 倍 D1
100,000 rows/日免費額度，先前零保護。新增 actions/maintenance-quota.ts（單一 entries
列/日的共用計數器，精神同 execution-log.ts／embed.ts 既有慣例，不新增表）。
三、leo 二度裁決：「標庫」與「時間分層」其實是一件事，判定標準要從第一天同時容納兩者，
不能先做一半再回頭改。新增 actions/library-backfill.ts 的 backfillEntryLibraryTags——
呼叫端（ingest／daemon／Arcrun#87）決定要貼哪個庫、用 page_names（Gitea 原稿卡名精準
點名，leo 定案的正解）或 source_prefix/page_name_prefix 過渡 fallback 篩選候選，base
只負責安全、節流地寫入。owner_id 刻意必填（leo 點出「補錯 owner 等於白做」——實查卡片
掛在 owner_id=bfezv28v，換成 'leo' 查卻是空的）。
D69：reconcile 與標庫 backfill 共用同一顆「今天還剩多少 D1 寫入額度」計數器（不共用的話
其中一個會把另一個的閘繞過去）；新增 POST /entries/backfill-library + GET .../status，
擴充 POST /embed/backfill 與 /embed/reconcile 吃 library/since/until 參數。
測試：92 → 39 個新增/擴充案例覆蓋 since/until/library 篩選、reconcile 額度真的擋
（含「拿掉 cap 會變紅」反向驗證）、標庫 backfill 冪等/owner_id 必填/page_names 精準比對、
以及兩個操作共用同一顆額度計數器的跨模組驗證（雙向：先 reconcile 耗盡再標庫、反之亦然）。
kbdb 全套 192 個測試綠燈，tsc --noEmit 除既有 auth.test.ts 舊缺陷外無新增錯誤。
紅線：未併 main、未部署、未動任何實例的 is_embedded 旗標（只在本地 SQLite 測試治具跑過）。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-11 18:39:55 +08:00
b6ef0f07dc
fix(kbdb): 開通 PATCH /kbdb/records/:id proxy + 補三元組 library 補標測試
...
leo 2026-08-11：貼 wiki 卡「這裏就有 3 個三元組，如果三元組是 0 一定是有錯」——
三元組沒有不見（新式 1,633 筆／舊式 636 筆都還在），問題是地圖看不到：新式三元組
只有 171 筆填了 library slot，其餘因寫入時 template 還沒有該 slot 而被靜默丟棄
（record-crud.ts createRecord 只替「已宣告」的 slot 建值，不是替 caller 傳的
values 建值——順序錯了值就消失，不報錯）。
本次改動：
- cypher-executor/src/routes/kbdb-proxy.ts：補 PATCH /kbdb/records/:recordId。
基本盤（kbdb/src/routes/records.ts）早有這個端點（mira-dissolve T2.1 的
updateRecord），但這條 proxy 之前只轉發 GET/POST /kbdb/records，外部（工作流/
CLI/補標腳本）打不到——能力在，通道沒開，補標三元組只能繞去改表（違 D38）。
純轉發、無業務邏輯，比照既有 PATCH /kbdb/entries/:id 慣例。
- kbdb/tests/triplet-library-backfill.test.ts：真 node:sqlite 驗三件事——
①源頭順序（ensure-slot 必須在 write 之前，事後補救不了已寫的那筆，重現＋
驗證正解）②存量補標（地圖輸出前後對照）③不會重複做（同批跑兩次，第二次
touch 0 筆）。順手記錄一個相關但不在本次範圍的小落差：liveTripletCountsByLibrary
的 'general' fallback 桶與 recomputeLibraryMap 的精確比對語意沒對齊。
- cypher-executor/tests/kbdb-records-patch-proxy.test.ts：新端點的租戶閘／
參數驗證／轉發／404 透傳。
全數綠燈：kbdb 181/181、cypher-executor 新增 8 案全過（既有 14 案失敗為
pre-existing，已用 git stash 比對確認與本次改動無關）。
kbdb-graph-plugin（實際的三元組寫入端 createTriplet/ingestEnvelope）需要同款
修正（library 補進 TRIPLET_SLOTS + 從 source_uri 推導），但該 repo 現行
0 份 active SDD，其 sdd-guard 明確要求人決定要不要開啟——本次不越界代為決定，
留在報告中交回。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-11 16:48:31 +08:00
1d6dde4a01
fix(kbdb/embed): D68 補算向量照新到舊排序＋每日額度上限＋修復舊世代 is_embedded 誤判
...
leo 2026-08-11 拍板（D68，system-dev/wiki/decisions-summary.md）：補算向量要照時間
由新到舊、且每天有額度上限，不能一次把 Workers AI 每日免費 10,000 neurons 燒光
（與萃取共用同一份額度，見 ops-facts.md）。對應 Leo/Arcrun#85 列出的三個缺口：
① 補算是由舊到新（ORDER BY created_at ASC）② 沒有每日額度上限 ③ 沒有任何自動觸發。
改動：
- backfillEmbeddings：ORDER BY created_at DESC（新到舊），並在打 AI 前依
env.EMBED_BACKFILL_DAILY_LIMIT（未設用推導出的預設值 1800，算式見 embed.ts 註解）
截斷候選、額度用完即停手不再打 AI。額度用量存在 entries 表單一列
（entry_type='embed_backfill_usage'，UTC 日期切）,不新增表（D38）。
- embedOnWrite / backfillEmbeddings 成功嵌入後在既有 content_hash 欄位蓋上
現行模型名（世代戳記），修復 leo21c 資料還原案：從備份整批灌回的列帶著對已退役
768 維索引的 is_embedded=1，現行 1024 維索引永遠不會補到它們。
- 新增 reconcileEmbedGeneration + POST /embed/reconcile：對 is_embedded=1 但
content_hash 非現行世代的候選，問 Vectorize.getByIds 是否真的在現行 index——
在→只補 content_hash 不打 AI；不在→重置 is_embedded=0 交回正常 backfill 佇列。
- 新增 kbdb/tests/embed-backfill.test.ts（改走真 SQLite，比舊版手刻假 DB 更硬）：
14 個測試涵蓋新到舊排序、額度真的擋（含「拿掉 cap 會變紅」的反向驗證）、
世代核對端到端（reconcile → 重置 → backfill 真的補回來）、既有行為不迴歸。
現況誠實回報：目前沒有任何東西會自動觸發補算（無 cron/scheduled handler）——
唯一的「自動」路徑是 entries.ts 的語意搜尋回 0 命中時 fire-and-forget 觸發一次
（既有行為，本次未改動），仍需人或 CC 主動呼叫 /embed/backfill 或掛排程。
紅線：未動 leo 正式實例 leo21c；未動資料層形狀（三表不變，仍走既有 content_hash
bookkeeping 欄）；未 push main，本 commit 在獨立分支 fix/embed-backfill-d68。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-11 16:42:54 +08:00
507620e313
merge: Arcrun 統一編譯零件，成品放固定位置 .worker-builds/（Arcrun#80）
...
總管 2026-08-11 審過後併入：
- 照本 repo 既有慣例（.component-builds 底下的 wasm 本來就 commit 進來），不新造第二套
- 每顆成品自帶 source_commit ＋ content_sha256 ⇒ 答得出「我是哪個版本編出來的」到單顆層級
- 重現性已驗：兩個不同路徑深度的獨立 clone 分別裝依賴分別編譯，
5 顆的 content_sha256 與 wasm sha256 逐位元相同（manifest 只差 generated_at）
⇒ 這正是 arcrun-rag#39 的驗收條件，也是 #72 那個死結的解
待觀察（不擋本次）：每次編譯會 commit 數萬行成品進原始碼 repo，長期會脹。
2026-08-11 13:54:19 +08:00
Leo
1e94f8451e
Arcrun#80: commit tier2 worker 官方編譯成品到固定位置 .worker-builds/
...
從本 repo 的 cypher-executor / kbdb / .component-builds/http_request /
registry/components/code / mcp 五個原始碼目錄，用 scripts/build-worker-artifacts.mjs
編出 5 顆成品，commit 進 repo（與既有 .component-builds/*/component.wasm 同一套
「固定位置、任何人直接拿」慣例）。
每顆 manifest 條目自帶 source_commit（該原始碼目錄最後改動的 commit）與
content_sha256，答得出「我是哪個版本的原始碼編出來的」到單顆層級。
重現性已驗證（見 commit 說明外的驗證記錄）：同一個 commit 在兩個獨立 clone
（不同磁碟路徑深度，刻意模擬雲端 vs 地端的目錄結構差異）分別裝依賴、分別編譯，
5 顆的 content_sha256 與 wasm module sha256 逐位元相同，manifest.json 唯一差異
是 generated_at 時間戳。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-11 13:45:33 +08:00
Leo
dcb6ad693b
fix(build-worker-artifacts): dirty 判斷排除自己的輸出目錄
...
.worker-builds/ 是本腳本的輸出，在成品寫出、commit 之前永遠是 untracked——
拿它判斷「原始碼乾不乾淨」是自己把自己判成髒的假陽性。git status pathspec
排除 .worker-builds 後才是「原始碼有沒有未 commit 變更」的真實訊號。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-11 13:45:33 +08:00
Leo
3b0238bb28
Arcrun#80: 新增 tier2 worker 官方編譯腳本（成品固定位置的地基）
...
背景：安裝器（arcrun-rag）過去自己對 Arcrun 原始碼跑 esbuild，導致同一份原始碼在
不同機器編出不同位元組（見 arcrun-rag changelog 1.4.33 段、arcrun-rag#72）：
① esbuild 把入口路徑寫進產物內部註解，該路徑預設相依於執行時 cwd
② 各 worker 目錄用不同套件管理器裝 node_modules，夾帶不同版本間接依賴
本腳本解法：
- absWorkingDir 固定為「本腳本自己算出的 repo 根目錄」，entry 一律用相對路徑餵給
esbuild——不管 clone 放在磁碟哪個絕對路徑，esbuild 內部產生的相對路徑字串相同
- 不自己跑 install，強制要求呼叫者先用該目錄既有 lockfile 裝好依賴（pnpm frozen /
npm ci），避免「install 方式不同 → 依賴版本不同 → 位元組不同」
- 每顆 worker 的 manifest entry 自帶 source_commit（該目錄最後改動的 commit），
答到單顆層級，不是整包一個 source 欄位
涵蓋 5 顆 tier2 worker（與 arcrun-rag bundle-components.mjs CORE_COMPONENTS 對齊）：
cypher-executor / kbdb / http_request / code / mcp。
scripts/ 自帶 package.json + pnpm-lock.yaml 鎖 esbuild 版本（0.24.0）——
工具版本本身也是重現性的輸入之一。
驗證：本地跑通 5/5 build；byte-identical 重現性驗證見後續 commit（兩個獨立 clone
比對 sha256）。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-11 13:45:33 +08:00
788295ed71
merge: 忘記密碼的錯誤訊息改白話＋健康檢查回報寄信有沒有接上（arcrun-rag#38／#69／#25）
...
總管 2026-08-11 審過後併入：
- 拿掉行話「實例」；拿掉「請管理員直接幫你改密碼」（單人使用者就是管理員＝死路，#25 同病）
- 改成給一條他自己走得完的路：重新跑一次安裝／更新
- /health 增回報 mail_relay_configured，讓安裝器判斷得出這台要不要重推
2026-08-11 13:24:34 +08:00
797e7f751c
fix(portal): 忘記密碼斷點——安裝器從沒注入 PORTAL_MAIL_RELAY_BASE（arcrun-rag#38/#69/#25）
...
leo 被鎖在自己的系統外面：1.4.35 已出 prod，「忘記密碼」畫面在線上，但按下去回
503「這台實例還沒有設定寄信服務」。根因在 products/arcrun-rag 的安裝器——
`grep -rn PORTAL_MAIL_RELAY installer/` 是零命中，即使 landing 那半（郵差）
D62 已經寫好。這個 repo 這邊改兩件配合修：
- /health 多回 `mail_relay_configured`（布林，不洩漏網址）——安裝器判斷「要不要
重推」只比 bundle_version，但這個 var 是這次才第一次被注入，跟版本號無關；
純比版本號的話，已經在最新版的實例（如 leo 那台）永遠不會因為「按更新」而
重推，這個 var 永遠補不進去。安裝器那邊會讀這個欄位決定要不要強制重推。
- portal.ts 的 503 訊息改白話（不提「實例」）＋給一條使用者自己走得完的路
（重新執行安裝／更新），不再說「請管理員幫你改密碼」——單人使用者的管理員
就是他自己，那是死路（同源病灶：arcrun-rag#25）。
安裝器那半的修法（PORTAL_MAIL_RELAY_BASE 注入＋stale 判斷）在
products/arcrun-rag 同批修（installer/oauth-prototype/worker.js）。
測試：cypher-executor `npx vitest run tests/portal-auth.test.ts tests/health.test.ts`
37/37 綠（35+2，既有測試無回歸；本次未新增測試——改動是訊息文案與健康檢查欄位，
行為已由既有測試覆蓋的路徑保護）。
2026-08-11 12:59:57 +08:00
d1c44a5878
merge: 忘記密碼與改密碼合成同一個機制（D62，arcrun-rag#69／#25）
...
總管 2026-08-11 逐筆審過後併入：
- 三筆：8d49d88 機制／9a29eb5 瀏覽器實測抓到的兩個前端缺陷／c76e10d 回歸測試
- #66 的修正 417d69c⚠️ 併入 main ≠ 出貨。要送到用戶手上仍需走出貨管線並由 leo 解保險。
2026-08-11 11:14:13 +08:00
a7e23badf2
WIP(kbdb): 關鍵字搜尋改成斷詞—— ⚠️ 未完成驗證，agent 被中途停止
...
【為什麼要這個】leo 2026-08-10：「沒有 MCP 你就是瞎的」。
總管實測（有對照組）證明搜尋對 AI 結構上不可用：
kbdb_search("Gemini 逃生口") → 0 筆 ← 兩個詞從不相鄰
kbdb_search("Gemini") → 864 行 ← 知識明明在
kbdb_search("local arcrun") → 5 筆 ← 這兩字在內容裡剛好相鄰
⇒ 現況是拿整個查詢字串去 LIKE，不拆詞。而 AI 問的永遠是問句 ⇒ 永遠回 0。
【這筆做了什麼】CJK/英數分段切詞、CJK 與 ASCII 停用詞、
單詞份量上限（避免長詞獨大）、相對分數截斷；附 search-tokenize.test.ts。
🔴 【誠實聲明】**這筆沒有驗完就被停了**（leo 要求全體停工專心 MCP 進安裝清單）。
未做：前後對照的實際輸出、回歸（原本查得到的不能變查不到）、相關性不崩壞。
**接手的人不要當成已驗證的東西**，先跑那三項再說。
分支保留於 gitea，隨時可接回去。相關：Leo/mira#4 總管留言。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
(cherry picked from commit 763de199b5
2026-08-11 10:02:09 +08:00
Leo
eebb691426
merge: 傳播空窗期不再銷毀 session（arcrun-rag#66）
...
leo 2026-08-10 本人被這個鎖在 stage 外面，並靠修好後的重設流程走回來——
這是「收的人自己驗到」，不是我們自己測過。
病：認證的家是 Workers Secret，改它會產生 worker 新版本，既有 isolate 讀到舊 env。
舊碼在那個空窗裡讀不到 record 就直接 SESSIONS_KV.delete()
⇒ 帶著完全有效的 token，登入狀態被當場銷毀，secret 鋪開也回不來。
#55 補的加速器重試只加在登入路徑，session 驗證這道門沒有。
實測空窗約 45 秒（不是 #55 記的 ≥15 秒）：
改完密碼後舊密碼一路到 t+44.1s 仍登得進去，t+47.1s 才開始 401。
三段修法：
1. 先問加速器再判定（與登入路徑同一支 hydrateFromAccelerator）
2. 永不因「讀不到」刪 session——刪是 best-effort 清潔工，清掉的卻是使用者唯一的憑據
3. 仍讀不到且在空窗 → 503 auth_store_propagating，不是 401
（前端看到 401 就清 localStorage，後端不刪也沒用）
前端 boot() 收斂成「只有 401 才算被登出」。
驗證：stage 改密碼後同一 token 打 90 秒 → 200x30 / 401x0；瀏覽器實跑仍在站內；
tests/portal-auth.test.ts 27/27 綠。
2026-08-10 14:19:04 +00:00
c76e10d314
test(portal): 補 #66 與 D62 的回歸測試（8 條，35/35 綠）
...
#66（三條，斷言的是「session 有沒有被刪掉」而不只是狀態碼）
- 傳播空窗（加速器 key 還在）＋讀不到 record → 503 auth_store_propagating，**KV 那筆還在**
- 非空窗＋讀不到 record → 401 擋下，**KV 那筆仍然還在**（刪是清潔工，清掉的卻是唯一憑據）
- session 內容本身壞掉 → 401 且**該刪**（那是確定的事實，不是暫時讀不到）
⇒ 前兩條在舊碼上必紅：舊碼在這兩個情況都會 SESSIONS_KV.delete()
D62（五條）
- 帶 reset_token 呼叫 /portal/password/change：**不必登入、不必現有密碼**；
且「先刪再回」＝同一條連結第二次必定 400 reset_token_invalid，KV 裡也真的沒了
- 先「看一眼」票（GET /portal/password/reset）不會消耗它
- 亂猜 / 格式不對的 token → 400
- 沒 reset_token 又沒登入 → 401（修改密碼那一格仍要身分）
- 沒設代寄服務 → /portal/password/forgot 誠實 503 mail_relay_not_configured（不假裝寄出去了）
擺放順序有註解說明：#66 那組會故意把 per-isolate overlay 灌成空的（模擬空窗），
而 overlay 是模組級全域變數不隨 test 重置，故必須排在檔案最後。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
Claude-Session: https://claude.ai/code/session_01R8vF2zS2XpaZjzkC75Fjss
2026-08-10 13:55:53 +00:00
9a29eb5af6
fix(portal): 瀏覽器實測抓到的兩個前端缺陷——連結被路由吃掉、.hide 從來沒有在藏東西
...
兩個都是「HTTP 200 看不出來、真的開瀏覽器才會現形」的（規則五點五③）。
① `#/reset?token=…` 被路由正規化吃掉
route() 的第一行是「raw 不在 VIEWS 就換成 HOME」，而 reset 不是站內的 view
⇒ 使用者點信裡的連結，網址被改寫成 `#/search`、修改密碼畫面根本沒出現，
**而且 token 一起被丟掉**——連結一次有效，等於這條連結就這樣廢了。
改：route() 開頭先看有沒有 reset token，有就走 showReset 並 return。
（boot() 那條只顧得到「整頁重新載入」；hash 變動這條路以前沒人守。）
② `.hide` 一直只有三條有 scope 的規則（#tabbar .tab / #sidenav .nav / .modebtn）
沒有通用的 `.hide { display:none }` ⇒ 任何其他元素掛上 class="hide" **完全沒被藏起來**，
看起來有藏、其實沒藏。實測畫面：登入頁還沒按「忘記密碼」就已經露出 email 欄與「寄出連結」；
連結模式下「現有密碼」那一格也照樣顯示（D62 的「差別只有一格」當場破功）。
補通用規則，帶 !important 以蓋過 inline display（#forgot-box 有）。
既有三種用法意圖一致（都是要藏），行為不變。
stage 瀏覽器實測（youlin，playwright）：忘記密碼 → 取連結 → 點進去 →
不輸入現有密碼設新密碼 → 自動回登入頁 → 用新密碼登入成功 → 進站 →
設定頁同一份表單（現有密碼那一格回來）改密碼 → **沒有被踢出去、可以繼續操作**。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
Claude-Session: https://claude.ai/code/session_01R8vF2zS2XpaZjzkC75Fjss
2026-08-10 13:51:41 +00:00
8d49d883c0
feat(portal): 改密碼與忘記密碼合成同一個機制，用連結不用一次性密碼（D62）
...
leo 2026-08-10 拍板：「這兩個機制其實是一個機制，可以簡化。」
修改密碼：輸入**現有的** → 輸入新的 → 覆蓋
忘記密碼：收到**「修改密碼」連結** → **不輸入現有密碼（忽略）** → 輸入新的 → 覆蓋
⇒ 同一個畫面、同一條寫入路徑，差別只有「現有密碼」那一格。
後端（cypher-executor/src/routes/portal.ts）
- POST /portal/password/change ＝**那一支**。帶 reset_token 就走連結那一格（忽略 current），
沒帶就要登入 ＋ 正確的 current。兩條路在 writeNewPassword 之後完全相同。
/portal/me/password 保留成**別名轉呼同一支**（不留第二份實作，兩份必然漂移）。
- POST /portal/password/forgot（公開）／GET /portal/password/reset（看票，不消耗）
- 連結的安全性（承 D50，不可退讓）：**一次有效**（用掉即刪，先刪再回）、
**會過期**（KV TTL 30 分鐘）、**與註冊辨識碼不同源**（現場 crypto 亂數，
只活在本實例 SESSIONS_KV，與 landing SIGNUPS 那組安裝辨識碼毫無關係）。
KV 存的是 token 的 sha256，不是 token 本身。
- 🔴 不做一次性密碼（leo：「不要發一次性密碼太麻煩」）。
- 🔴 已否決不准寫回來的三條（D50）：console 密碼救援／重裝重設密碼／直接用固定辨識碼。
中央代寄（arcrun-rag landing 那半在該 repo）
leo 給的職責切法：實例產生連結、管一次性/過期；arcrun.dev 只是郵差。
必須這樣切的硬理由：用戶自己的實例**沒有 send_email binding**，根本寄不了信。
🔴 總管紅線：**絕不把整條 URL 交給郵差**——寄件網域帶 DKIM，肯收「任意 URL＋任意 email」
就是一台開放的釣魚中繼，燒的是整個網域信譽、不可逆。
故只交出本實例 origin ＋ 一張回呼票，並新增 POST /portal/password/relay-verify：
郵差**回頭打這個 origin** 問「這張票是你發的嗎」，冒用別人網域會被那台實例自己否認
⇒ 主機屬於呼叫方這件事由郵差親自確認，不是相信宣稱。
信裡的連結落點 GET /portal/password/reset-link（主機刻意＝被確認過的那個 origin）。
前端（console-ui/public/portal/index.html）
- 登入頁「忘記密碼」入口，**在 portal 不在 console**（leo：「是對 portal 不是對 console，
這樣 youlin 雖然忘記，我還是可以去 portal 忘記密碼。」）
- 拆掉登入頁原有的「用管理主控台密碼救援自己」連結與「忘記密碼請聯絡管理員」
——兩條都是 D50 已否決的做法（console 與 portal 是同一組帳密的兩個鑰匙孔）。
- #v-reset 殼**沒有自己的密碼欄位**：真正的表單是設定頁那唯一一份 #pw-form，
進入連結模式時被原封不動搬過去，只切換「現有密碼」那一格顯不顯示。
同一個表單元素、同一支送出函式 —— D62「同一個畫面」的字面落地。
驗證：tsc 與 baseline 同為 23 個既有錯誤（零新增）；27/27 既有測試綠；前端 JS node --check 過。
stage 實測見交付回報。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
Claude-Session: https://claude.ai/code/session_01R8vF2zS2XpaZjzkC75Fjss
2026-08-10 13:23:44 +00:00
417d69ceb3
fix(portal): 傳播空窗期不再銷毀 session——讀不到 ≠ 這個人不存在（arcrun-rag#66）
...
leo 2026-08-10 在 youlin stage 改完密碼被登出，之後怎麼登都回不去。
病灶是「這一瞬間讀不到」被當成「這個人不存在」，而且做的是**不可逆**的動作。
認證的家是 CF Workers Secret，改它會產生 worker 新版本，既有 isolate 讀到的
還是舊 env（#55 實測 ≥15 秒）。舊的 requirePortalUser 在那個空窗裡直接把
session 從 KV 刪掉——不是擋下讓你重試，是當場銷毀，等 secret 鋪開也回不來。
#55 補的「讀不到就再問一次加速器」只加在登入路徑（findAndVerifyUser），這道門沒有。
三處修法（缺一不可）：
1. requirePortalUser 先問一次加速器再判定（與登入路徑同一招、同一支函式）
2. **永不因「讀不到」刪 session**；仍讀不到且正在傳播空窗 → 回 503
`auth_store_propagating` 而不是 401（讀得到 record 的「已停用」照舊刪，那是確定的事實）
3. 前端 boot() 從「任何非 2xx 都 dropSession」收斂成**只有 401 才算被登出**
——後端不刪、前端卻自己丟掉 localStorage 的 token，症狀一模一樣
順帶修掉同一族的一個資料遺失路徑：mutateAuthStore 舊版拿「可能是舊版 env」當底稿做
read-modify-write，而 writeAuthStore 會重切分片並刪掉多出來的舊分片 ⇒ 底稿若是
「某帳號被建立之前」的版本，那個帳號會在這次寫入中被抹掉且無法還原（secret 是唯一真相源）。
改成先問加速器、再把 env 版與 overlay 版取聯集當底稿；刪除仍有效（fn() 在聯集之後才跑）。
驗證：tsc 與 baseline 同為 23 個既有錯誤（零新增）；tests/portal-auth.test.ts 27/27 綠。
stage 實測見交付回報。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
Claude-Session: https://claude.ai/code/session_01R8vF2zS2XpaZjzkC75Fjss
2026-08-10 13:22:34 +00:00
Leo
035e8b255b
chore(mcp): stage build 標記對齊實際部署的 commit
...
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-10 09:51:36 +00:00
Leo
1c630ecfd4
docs(mcp): /health 註解誠實界定——404 只代表比本版舊，不等於舊世代
...
實測：leo21c 與 geek6688 的 /health 都回 404，但 geek6688 是新世代（email+password）。
原註解會讓下一個人拿 404 去判世代而誤判。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-10 09:51:36 +00:00
Leo
a99d3e5a3e
chore(mcp): 補 stage 部署設定（youlin）——升級 arcrun-mcp 終於有測試場
...
arcrun-mcp 不在安裝器出貨的那批裡，所以「升級某台的 arcrun-mcp」一直沒有地方先驗，
要驗只能拿 leo21c（唯一一份 47.9 萬筆知識的真身）冒險。本檔把 stage 補上。
順帶把「手動直推 arcrun-mcp 到自架帳號」的兩個坑從人的記性搬進檔案：
① 拿掉 mcp.arcrun.dev route（zone 在 uncle6，自架帳號沒有）
② OAUTH_KV 填真 id（出貨 toml 是佔位符，直推不填 → /authorize 503）
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-10 09:51:36 +00:00
Leo
894408181f
feat(mcp): GET /health — 一條 curl 看出這台是新舊世代 MCP
...
判斷一台實例的 arcrun-mcp 是哪一代認證，原本只能打 /authorize 剖 HTML 有幾個欄位
（ops-facts 2026-08-10 的土法）。改成誠實版本面：200+auth=portal-login ＝新世代；
404 ＝舊世代（同意頁還要那把沒人拿得到的 MCP_OWNER_SECRET ⇒ 等於接不上）。
順帶 build 標記（MCP_BUILD var）讓「這台跑的是哪一版」看得到。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-10 09:51:36 +00:00
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
uncle6me-web
Leo