a5e4caf5cb
fix(portal): 讀不到就說讀不到——總圖不再把「讀不到」畫成「你沒有」（Arcrun#100）
...
leo 2026-08-12 打開總圖看到：「0 個實體 · 0 條關聯／知識庫還沒有任何關聯——
上傳文件後 AI 會自動織網」。**而他庫裡有 1854 條三元組。**
那句話會叫他去做一件不需要做的事。
三個獨立的洞疊起來才變成那句謊：
① console-dashboard.ts 打 kbdb-graph-plugin 沒帶認證（同段落打 kbdb 的兩支都有帶）
② 那顆 worker 不在更新的部署清單裡 ⇒ token 一換它就落單
③ **畫面把 null 畫成 0**——後端已經誠實回 null 了，是前端把它變成謊話
為什麼一直沒被發現：graph plugin 原本身上沒有 token ⇒ 門開著 ⇒ 沒帶也進得去。
2026-08-12 輪替後它有了 token，門關上，401 才浮出來。
📍 repo：matrix/arcrun（cypher-executor/src/routes/、console-ui/public/）
📍 票：Leo/Arcrun#100
2026-08-12 13:33:53 +08:00
e69d6bbc03
chore(worker-builds): 重編——kbdb 的跳脫修法要進執行檔才算數（Arcrun#94）
...
今天已經在這件事上被咬過一次（8e10f1d）：源碼改了、執行檔沒重編，
出貨會全綠地送出舊的。這次併完就重編，不留同一個坑。
kbdb source 525faaf
2026-08-12 12:22:10 +08:00
b302c03ea8
merge: 搜尋框打的 % 和 _ 是字，不是萬用字元（Arcrun#94）
...
總管逐筆審過兩筆，並自己跑了測試（那條線被權限閘擋住沒能執行）：
前後對照 查 100% 改前撈回「共有 100 個待辦項目」→ 改後只回真的含 100% 的
查 owner_id 改前連 ownerXid 也中 → 改後只回字面命中
單打 % 或 _ 改前整個庫都回來 → 改後只回字面命中
反向驗證 拿掉跳脫 → 8 failed（紅的正是病徵本身）
拿掉 ESCAPE → 5 failed（含既有 search-long-query 兩條）
既有測試 18 檔 197 pass → 19 檔 213 pass
它連帶處理了一個我沒想到的：跳脫會讓 pattern 變長，所以長度上限改用「跳脫後」的
長度算——否則打 48 個 % 會產生 98 bytes 的 pattern，退回 08-03 修掉的那個 HTTP 500。
誠實標記：只在本機真 SQLite 上驗過，沒對任何線上實例跑過。
同款漏洞另有兩處未動（library-map.ts:169、library-backfill.ts:75-76，吃維運端前綴參數）。
2026-08-12 12:21:48 +08:00
c497ec418e
test(kbdb): 用真 SQLite 釘住 #94 的前後對照與跳脫邊界
...
只驗 SQL 形狀不算數——「% 被當成萬用字元」這件事，只有真的跑一次 LIKE 才看得見。
用 node:sqlite（與 library-map／embed-backfill 同款治具）跑真 SQL，每組驗收同時跑
「舊寫法」與「現行寫法」，讓前後對照直接長在測試裡。
守五件事：
① 前後對照 —— 100% / owner_id / 單打符號，改前撈回不相干的、改後只回字面命中
② 跳脫邊界 —— `\` 不跳脫會漏掉真正的 `C:\`，也會讓 `_` 的跳脫失效、萬用字元漏回來
③ ESCAPE 齊全 —— 沒有任何 `content LIKE ?` 是裸的（漏一個就等於那條路沒修）
④ 不退化 —— 不含 % _ \ 的查詢 pattern 逐字不變，最熱路徑仍是單一 LIKE
⑤ byte 預算 —— 滿是 % 的長查詢仍在 D1 的 50 bytes 上限內（承 2026-08-03 的 500 修復）
反向驗證（把修法拿掉，兩半分別驗，兩半都是承重的）：
拿掉跳脫 → 8 failed / 204 passed，紅的正是病徵本身
拿掉 ESCAPE → 5 failed / 207 passed（含既有 search-long-query 2 條）
復原後 → 19 檔 213 pass（基線 18 檔 197 pass）
2026-08-12 11:59:36 +08:00
6985bf4850
fix(kbdb): 搜尋框打的 % 和 _ 是字，不是萬用字元（Arcrun#94）
...
使用者在搜尋框打 `%` 或 `_`，搜出來一堆跟他打的字無關的東西。
病根：pattern 一直是 `'%' + 使用者輸入 + '%'` 直接內插，而 SQLite 的 LIKE 有
兩個萬用字元（`%` 任意長度、`_` 任意一字）且**沒有預設跳脫字元**——不寫
ESCAPE 就沒有任何辦法表示「字面上的 %」。所以他打的符號被當成 pattern 語法：
`100%` → `%100%%` → 「100」後面接什麼都算 ⇒ 撈回一堆不相干的
`owner_id` → `%owner_id%` → `_` 匹配任一字元 ⇒ ownerXid 也中
單打 `%`／`_` → `%%%`／`%_%` → 整個庫都回來
舊病，不是 08-10 斷詞（#84）引進的：pattern 從來就是這樣拼的。之前關鍵字搜尋
幾乎恆為 0 命中，這個洞被那個洞蓋住；斷詞讓搜尋真的會回東西之後才浮出來。
斷詞那段一個字都沒動。
修法：pattern 產生點全部收斂到兩支 helper——
· escapeLikeLiteral()：跳脫 `%` `_` `\` 三個字元
· CONTENT_LIKE 常數：每個 `content LIKE ?` 一律帶 `ESCAPE '\'`
為什麼跳脫字元本身（`\`）也要處理：宣告 ESCAPE 之後 `\` 就變成 pattern 裡有
意義的字元，而且它會把後面那個字吃掉、且不報錯——打 `C:\` 會變成去找 `C:%`
（真正的 `C:\` 反而漏掉）；只跳脫 %/_ 而漏掉 `\`，打 `C:\_temp` 時 `\\` 先被
讀成字面 `\`、後面的 `_` 變回萬用字元 ⇒ 撈到 `C:\Xtemp`。三個是一組的。
`[` `]` `?` `*` 不需要跳脫（那是 GLOB／別的方言，LIKE 不吃），多跳只會白白吃掉
pattern 的 byte 預算。
連帶：跳脫會變長（`%`→`\%`），所以 50 bytes 上限改用「跳脫後」的長度算
（likeBytes），否則打 48 個 `%` 會產生 98 bytes 的 pattern ⇒ 退回 2026-08-03
修掉的那個 HTTP 500。不含這三個字元的查詢 likeBytes ≡ utf8Len ⇒ 既有查詢逐字不變。
search-long-query.test.ts 兩條「逐字比對謂詞字串」的斷言跟著新字串更新——改的是
比對用的常數、不是放寬檢查（仍逐字相等比對），pattern 本身一個字都沒變。
沒有引進第三種搜尋機制，沒有動資料層（三表不變），沒有動斷詞。
2026-08-12 11:59:36 +08:00
8e10f1d83e
chore(worker-builds): 重編官方成品——kbdb／cypher-executor 的修法之前只在源碼裡
...
為什麼要有這一筆：`.worker-builds/` 是**出貨與安裝真正拿去部署的執行檔**，
而它記的 source_commit 在剛併完 #85／#88 之後對不上源碼：
arcrun-cypher-executor 成品記的 797e7f7525faaf⚠️
arcrun-kbdb 成品記的 a7e23ba3eb8b31⚠️
⇒ 這時候去出貨或 `init`，送出去的是**舊的執行檔**，測試全綠也沒用
（wiki/mistakes.md「修的東西在執行檔裡，改完源碼＋測試綠 ≠ 送到用戶手上」）。
🔴 build-bundles.mjs 的「落後閘」抓不到這個：它比的是「.worker-builds 這個目錄有沒有
落後 main 的 commit」，不是「成品記的 source_commit 有沒有落後那顆 worker 的源碼」。
這次是人工比對才發現的。修這道閘另開票。
重編後：cypher-executor source=525faaf、kbdb source=3eb8b31，兩顆的新程式碼都在產物裡
（kbdb 找得到 embed_backfill_usage／backfillEntryLibraryTags，cypher 找得到 builtin 那條路）。
誠實標記：另外三顆（code／http_request／mcp）源碼沒動，位元組卻變了——是 esbuild
版本漂移換了它產生的 helper（`__esm` 多了一段 try/catch）。這正是 #77 記的
「build 不可跨機器重現」那個結構性斷點的實例。
2026-08-12 09:50:50 +08:00
3eb8b31f2b
merge: 補算向量的節奏、額度、世代核對＋標庫共用同一顆閘（Arcrun#85／D68／D69）
...
總管逐筆審過 1d6dde4／674e1b4／37e13fc：全部落在 kbdb/，沒有新表（額度用量寄生在
既有 entries 表單一列，D38）、沒有動實例。標庫與時間分層共用一套 SelectionCriteria
與同一顆每日 D1 額度計數器——兩者若各記各的，其中一個會把另一個的閘繞過去。
實測：kbdb 全套 196 pass / 0 fail（含反向驗證：拿掉 cap 那個 case 會變紅）。
紅線仍在：這只是併進 main，還沒部署到任何實例。
2026-08-12 09:40:30 +08:00
8cee9c9f76
merge: /cypher/search 不再誤報執行期原生零件 not_found（Arcrun#88）
...
總管逐筆審過 525faaf：改動只在 cypher-executor 的 search-nodes.ts（查 registry 前先比對
執行期白名單）與 component-loader.ts（把既有三份白名單的聯集匯出），沒有新清單、
沒有掃目錄灌死碼。實測基準線：本分支 357 pass / 14 fail，main 350 pass / 14 fail
——同樣的 14 個既有失敗（portal-data 等 5 檔），新增的 7 個全綠。
2026-08-12 09:40:18 +08:00
7e3ca4c1a1
Revert "WIP(kbdb): 語意搜尋零命中的排查—— ⚠️ 被總管中途叫停，未完成驗證"
...
This reverts commit af3edff856
2026-08-11 23:18:38 +08:00
af3edff856
WIP(kbdb): 語意搜尋零命中的排查—— ⚠️ 被總管中途叫停，未完成驗證
...
leo 2026-08-11 判斷「如果是 Vectorize 沒完成就不用查了」，總管據此停線。
真因已經寫在 repo 自己的註解裡（kbdb/wrangler.toml:43-51，Arcrun#11）：
metadata index 只收「建立後 upsert」的向量，既有向量須 reindex，
否則帶 owner_id filter 一律 0 命中——與實測每一格吻合
（805 筆在、關鍵字搜得到、語意 0、拿自己查自己也 0 ⇒ 不是分數門檻）。
⚠️ 這批改動是排查途中的產物，**沒有走完驗證**，不要當成可用的修法。
保留只是不讓它憑空消失（總管中斷造成，不是它做壞）。
接手的人請先讀 Arcrun#85 上的結論再決定要不要用。
真正的補救是 reindex，而 reindex 要燒 AI 額度
⇒ 卡在 Arcrun#85 的每日額度閘上線之後才能做。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-11 23:05:20 +08:00
c5d696556e
保管：#89/#90/#91 卡在人類閘前的產物，從 session 暫存目錄搶進版控
...
三樣都做完並實測過，但落地的最後一步是終端機裡等人親手打字的互動閘。
它們原本只存在於某個 session 的 scratchpad——那種目錄一關就沒了。
· recipes/gitea_put_file.yaml 出貨線 7 站等它
· recipes/cf_worker_deploy_simple.yaml ⚠️ 只適用無 bindings 的簡單情形（見 #90）
· hash-component/ sha256/sha1/md5，已與系統原生指令逐位元核對
（.wasm 是 1.3MB 編譯產物，不進版控，README 附重編指令）
README 寫了落地指令與各自的注意事項。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-11 22:38:55 +08:00
5919c6b90f
fix(kbdb): 藏書地圖讀端每次都觸發重算寫 D1（Arcrun#87 止血）
...
liveTripletCountsByLibrary 沒有過濾 status，recomputeLibraryMap 只算
COALESCE(status,'active')='active'——兩邊判準不一致，只要庫裡有一筆
superseded triplet 就永遠判定 stale，導致每次讀地圖（GET /map、GET /map/:library、
kbdb_get_map MCP 工具）都觸發重算並新建一筆 library_map record，無止盡寫 D1，
且加劇既有的非原子 supersede 競態（kb 44 筆全 superseded、notes 兩筆同時 active
即 arcrun-rag#50 的共同根因之一）。
修法：liveTripletCountsByLibrary 的 SQL 改成 pivot 出 status 再套用與
recomputeLibraryMap 逐字一致的過濾，兩邊判準對齊。
新增迴歸測試釘住此 bug（反向驗證：跑在修前的 SQL 上會失敗，非空氣測試）；
獨立用 leo21c MCP 連線連讀兩次 kbdb_get_map() 重現修前症狀
（general 庫 updated_at 從 1786457080 前進到 1786457114，中間無寫入）。
kbdb/tests/library-map.test.ts 19/19 全綠。既有殘骸（100 筆 library_map record）
未清——目前沒有可用的 DELETE 通道，待部署後另行處理。
kbdb-sql-ok：liveTripletCountsByLibrary 的 .prepare 呼叫是牆內本體
（kbdb/src/actions/），本次 checkout 開在巢狀 worktree
matrix/arcrun/.worktree-fix-87/（避免打斷另一 session 佔用中的
matrix/arcrun 主 checkout），kbdb-api-wall-guard.sh 的字面路徑比對
*matrix/arcrun/kbdb/src/* 吃不到中間多出的 worktree 目錄層，非真的繞牆。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-11 22:16:30 +08:00
525faaf5d0
fix(cypher-executor): /cypher/search 不再誤報執行期原生零件 not_found（Arcrun#88）
...
病因：/cypher/search 只查 component registry（SUBMISSIONS_KV，經 submitComponent/
index-only 才有記錄）；而 component-loader.ts 能直接解析、從不查 registry 的一整類
零件（trigger_workflow／BUILTIN_COMPONENTS／LOGIC_BINDING_MAP／WASM_HTTP_RUNNER_IDS，
如 if_control／http_request／switch）從未被 submit 過。leo21c 實例實測：
GET /components/catalog 回 404「零件 catalog 不存在」，search 因此對這些零件誠實地
回「兩庫都查過沒有」——但它們其實跑得動（leo 08-11 探測工作流已證）。
修法：從 component-loader.ts 匯出 RUNTIME_NATIVE_COMPONENT_IDS（既有三份執行期
解析白名單的聯集，非新清單），search-nodes.ts 在查 registry 之前先比對，
不受 registry 是否可達／是否已 backfill 影響。真正不存在的零件仍誠實回
not_found／unknown，not_found 的分型建議與相似候選機制不變。
刻意不做：不掃描 registry/components/* 目錄當清單來源——那含已標記待刪的死碼
（km_writer／kbdb_upsert_block），07-30 曾把這類死碼誤灌進 registry；也不投資
SUBMISSIONS_KV 的 backfill 腳本——decisions-summary.md D29 已定調 SUBMISSIONS_KV
併入「KV 退休戰」，不宜再加投資。
測試：cypher-executor/tests/search-nodes-runtime-native.test.ts 7 case 全綠，
複現 registry unreachable／registry 可達但目錄空（leo21c 實例的真實症狀）兩種情境。
全 suite 迴歸：357 pass（較修前 350 pass 多 7 個新測試），既有 14 個失敗與修前
數量、內容完全相同（pre-existing，與本次改動無關）。
2026-08-11 21:51:21 +08:00
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
uncle6me-web
Leo