Leo/Arcrun
1
0
Fork 0
Code Issues 49 Pull Requests 5 Actions Packages Projects Releases Wiki Activity
401 Commits 27 Branches 0 Tags
730c2af245e65bbdb162eb484e6e4ce9c334db55
Commit Graph

16 Commits

Author SHA1 Message Date
uncle6me-web 537b520143 build(worker-artifacts): 公庫從 5 顆變 23 顆（基底重釘到含 Arcrun#124 修法的 main） 
由乾淨工作區重編（repo_head 45169ab、dirty=false）。

🔴 這一版是**重編**不是重併：前一版是從 94d5452（#124 修法併進 main 之前）長出來的，
直接併會把 .worker-builds 的 cypher **換回沒有修法的那顆**（8e648747），
而且是安靜發生的——manifest 從 5 顆變 23 顆看起來全是進步，沒有人會去看那顆 sha 退回去。

複驗（五顆既有引擎逐顆比對 main 的 committed 值，全中）：
  cypher-executor 1da6a46e6a17 ← **含 #124 修法**（source 340b461f）
  kbdb            f15e16cca6ce
  code            751634a3fc9a
  mcp             9bc8dffb34d0
  http-request    cdd97364f277
新增 18 顆零件 worker ＋ arcrun-rag-ui；claude_api 依 .gitignore 判定不出貨，
落在 manifest.excluded。成品裡沒有任何本機路徑洩漏。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-15 01:00:45 +08:00
uncle6me-web b8a5201e8a build(worker-artifacts): 重打 cypher-executor 成品（含 Arcrun#124 修法） 
sha256 8e6487478bc8 → 1da6a46e6a17（工作區乾淨時重編，repo_head 標記可信）。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-14 23:26:28 +08:00
uncle6me-web 0b72b818a0 chore(builds): 重編 tier2 成品 manifest——repo_dirty:true 修正為乾淨 HEAD（94d5452） 
出貨 D87（Arcrun#119）到 stage 時卡在 build-bundles.mjs 的落後閘：main 上現有的
.worker-builds/manifest.json 記著 repo_head=8286c8a（4b6cc15 那個 commit 的父提交）
且 repo_dirty:true——是那次 commit 在完成前先跑了建置腳本，manifest 跟著沒完成的
工作樹一起被 commit 進去。

在乾淨的 main HEAD（94d5452）重跑 scripts/build-worker-artifacts.mjs：五顆
worker 內容位元組完全相同（cypher-executor sha256 8e6487478bc8... 不變，
證明前一份的實際內容其實是對的，只是 metadata 記錯），這次只更新
generated_at／repo_head／repo_dirty／source_commit 四個欄位為正確值。
 2026-08-14 13:27:45 +08:00
uncle6me-web 4b6cc159b8 feat(auth): 認證儲存搬回 D1/KV——落實方案C（leo confirm「走C」，arcrun-rag#99） 
實作 pending-changes.md「認證儲存要不要搬回 D1/KV」提案（commit 8286c8a）：
D61 的病根「重裝時 binding 被安裝器照名字重新指到新建空資源」已被更通用的
shared/resource-rule（Arcrun#97，2026-08-13）解掉，故不再需要繞開 binding
去躲這個病——而繞開的代價正是這次要收的債：Workers Secrets 寫入需要外部
CF_SECRETS_API_TOKEN，這把 token 從安裝那天起就沒被種過，止血版只解掉
「建第一個帳號」這一格，之後的每一次寫入（換密碼／加帳號／改權限）仍卡死。

改動：
- console 管理員帳密：家改回 SESSIONS_KV（binding，console-auth.ts）
- portal 多人帳號：家改回 KBDB（binding，走 base HTTP API，D38 零 SQL，portal.ts）
- D61 認證儲存（CF Workers Secrets）留為舊實例的唯讀回退路徑：讀取零成本、
  零外部憑證需求（只有寫入才要 token）；登入成功即 best-effort 自動搬進新家，
  且**這次登入發出的 session 就直接指向新 record_id**（不必等下一次登入）
- D61 的三項「明顯失敗」語意全部保留：auth_store_empty（讀不到不算密碼錯、
  不計入鎖定）、/console/setup 遇既有帳號說清楚密碼沒被採用、/health 與
  /console/auth-status 吐儲存狀態
- 移除止血版的 x-arcrun-install-token 表頭傳遞機制（installToken 參數）——
  帳號寫入從此不需要任何外部 CF token，這個結構性缺口已從根拔除

測試：cypher-executor 全套 vitest 439/453（14 個既存失敗與本改動無關，已用
git stash 對照 clean checkout 逐一比對檔名確認完全相同）；tsc --noEmit
無新增錯誤（3 個既存錯誤同上核實無關）。已跑 build-worker-artifacts.mjs
重打 tier2 bundle，grep 複驗 createKbdbUserRecord/promoteToKbdb 進了成品、
promoteLegacyUser／x-arcrun-install-token 完全從成品消失。

未覆蓋：POST /credentials（一般 workflow API 金鑰儲存）仍依賴
CF_SECRETS_API_TOKEN——這是 01-tech-stack.md 既有的、獨立於 D61 之外的
credential 儲存架構（D19「擁有目錄不擁有內容物」），本提案範圍只涵蓋「認證」
（登入帳密），不涵蓋一般 credential 儲存；07-29 已知缺口仍待另案處理。

不准 merge 進 main（SDD 鐵律③，等總管審過再併）；不准部署（D20 出貨閘）。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-14 12:52:07 +08:00
uncle6me-web 8286c8afec docs(pending-changes): 提案——認證儲存搬回 D1/KV（撤 D61 的儲存層決定，留其明顯失敗語意） 
arcrun-rag#99 止血修法（安裝精靈傳 OAuth token 給 cypher 建第一個帳號）只解一格，
之後的寫入（換密碼/加使用者/存金鑰）仍永久 writable:false，是留債。

查證（讀碼＋讀本機重打的 .worker-builds/manifest.json，非猜測）：D61 想解的病根
（重裝時 binding 被照名字重新指到新建空資源）已在 2026-08-13 被更通用的
shared/resource-rule（Arcrun#97）解掉——SESSIONS_KV、KBDB 的 D1 都在 cypher 的
requires 清單裡，且 runInstall:1762 每次安裝/更新都會走這條規則。技術前提成立。

提案：認證資料搬回 D1/KV（走 binding，零外部 CF token、零過期、零新 OAuth scope、
零手動步驟），保留 D61 加的三個明顯失敗機制。附影響分析、遷移考量、信心水位
（靜態推論，未動態實測）、D84 三段式驗法（③ uninstall 目前做不到，如實標記）。

⏸ 等 leo/總管 confirm，本 commit 不動任何架構程式碼。

順手修：writeAuthStore 的錯誤訊息移除誤導的「/ CF_ACCOUNT_ID」（已查證全新實例
一定有這個 var，installer worker.js:1354 無條件注入，列兩項只會讓下一個人白工）。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-14 12:06:50 +08:00
uncle6me-web 88f308642e fix(auth): 全新安裝補上 CF_SECRETS_API_TOKEN 的缺口——第一個帳號建得起來了（arcrun-rag#99） 
根因：D61（認證與資料分離，c4cee35）把 /console/setup、/portal/admin/bootstrap
的寫入全部改走 CF Workers Secrets（env.CF_SECRETS_API_TOKEN），但這把 token
從安裝那天起就沒被種過——07-29 已知缺口（pending-changes.md「credential 走
n8n 模式」），當時只降級某個功能；D61 之後升級成「連第一個帳號都建不起來」
的硬斷點，每台全新安裝必中（leo 本人＋封測者實撞：裝得起來但卡在註冊）。

修法：putWorkerSecret/deleteWorkerSecret/authStoreWritable/writeAuthStore/
mutateAuthStore 新增可選的 tokenOverride 參數（呼叫端提供 > worker 自身 env）。
/console/setup、/portal/admin/bootstrap 讀取 x-arcrun-install-token 表頭，
只有安裝精靈（裝機當下手上有一把自己還有效的 OAuth token，workers-scripts.write
scope，同一把已用於 putWorkerSecretDirect/seedCredential）會帶這個表頭；
一般使用者自己在瀏覽器操作不受影響。沿用既有「D36 安裝器代寫」precedent，
不是新開一條路；bootstrap 本身已被「已有 admin → 409」擋成只能成功一次，
不會被拿來反覆濫用。

測試：cypher-executor vitest 443/457（14 個既存失敗與本改動無關，已用
git stash 對照確認）；新增 2 則直接證明「缺 token→502 auth_store_not_writable／
帶 token→200」。tsc --noEmit 無新增錯誤。已跑 build-worker-artifacts.mjs
重打 tier2 bundle 供驗證（工作區未 commit 前提下的本地驗證版）。

未完成：安裝器（products/arcrun-rag/installer/oauth-prototype/worker.js）
端的 x-arcrun-install-token 表頭傳遞已另外修好，但兩邊都還沒部署——需要
①重打正式 worker artifact ②install.arcrun.dev 的安裝器 wrangler deploy
③已卡住的封測者要再走一次安裝精靈讓他的 cypher worker 拿到新 bundle。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-14 11:46:56 +08:00
uncle6me-web c3856470ad chore(builds): 重編成品——把 #117 地圖 entry_count 與 #118 讀不到≠不存在 放進執行檔 2026-08-13 18:28:25 +08:00
uncle6me-web 9ff933ba98 chore(builds): 重編成品——把 #108 的租戶修法放進執行檔 
cypher source 10d150a → b223a698（#108 併入）。
重編時新的租戶來源閘第一行就報：
  ✔ 租戶來源檢查通過：cypher-executor 資料面 owner_id 全部來自 src/lib/tenant.ts

⇒ 那道閘現在長在建置線上：以後有人再寫 env.XXX || 'leo'，成品編不出來。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-13 00:25:46 +08:00
uncle6me-web cac874601f chore(builds): 重編 tier2 成品——把 #108 放進執行檔（出貨路徑 A 的第 0 步） 
原始碼修好不等於使用者拿得到：`.worker-builds/` 是安裝器與 `acr update`
實際部署的那份執行檔。本次一併重編，repo_dirty=false、repo_head=b223a698。

  arcrun-cypher-executor  sha256=e0026a23792f  source=b223a698 ← #108
  arcrun-kbdb             sha256=9c6d41895d78  source=f87d0e92（未變）
  arcrun-http-request     sha256=9a9dcb71879a  source=1e85dfb4（未變）
  arcrun-code             sha256=285a7406ec69  source=621cb8d9（未變）
  arcrun-mcp              sha256=3ebc0d441bc0  source=10d150ac（未變）

其餘四顆的 js 位元組有變是 esbuild 版本/相依重裝造成的重編，source commit 未動。
本次起這條路徑多一道閘：編成品前先跑租戶來源檢查，違規直接「建置中止」
（見同 PR 的 scripts/build-worker-artifacts.mjs）——實跑輸出貼在 PR。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-13 00:16:55 +08:00
uncle6me-web e05518a2b4 chore(builds): 重編成品——把 #107 的版本標籤修法放進執行檔 
出貨線第 1 站的 #93 新鮮度閘擋下：cypher-executor 成品記 10d150a，
而 HEAD 已是 2129356（#107 改了 routes/health.ts 與 types.ts）。

這是該閘今晚第三次擋對——沒有它，1.4.42 會送出一個「版本標籤修法只在源碼裡」的成品。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-12 22:22:57 +08:00
uncle6me-web ba152bc83a chore(builds): 重編 tier2 成品——把 #105 放進執行檔（出貨路徑 A 的第 0 步） 
leo 選 A（把出貨線推到能出一版含 #105 的 bundle）。查證後發現最前面還有一層：

  cypher 源碼最後動 10d150a（#105）  ／ 成品最後動 a24f291（更早）
  mcp    源碼最後動 10d150a（#105）  ／ 成品最後動 8e10f1d（更早）

⇒ #105 改了 cypher 與 mcp 兩邊源碼，但沒有重編成品。
   這正是 Arcrun#93 那道「源碼比執行檔新就停下來」的閘要擋的狀態。

用官方唯一編譯點 scripts/build-worker-artifacts.mjs（Arcrun#80 的機制，已存在）
重編五顆，全部 5/5：
  arcrun-cypher-executor  571KB  source=10d150ac
  arcrun-kbdb             146KB  source=10d150ac
  arcrun-mcp             1152KB  source=10d150ac
  arcrun-http-request      78KB  source=1e85dfb4（未變）
  arcrun-code             150KB  source=621cb8d9（未變）

交叉驗證（不只信它自記的 commit）：/portal/data/ 這條 #105 才有的路徑
在 arcrun-mcp 成品裡出現 8 次。

下一步（等 leo 解閘）：把修好的引擎部署到 geek6688 當出貨機
（ARCRUN_SHIP_BASE 可覆寫，預設是 leo21c——arcrun-rag#79 要搬離的正是這個），
再從那台跑出貨線，第 17 站 purge 的 wait 節點才有帶修法的引擎可跑。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-12 20:03:30 +08:00
uncle6me-web a24f2912eb chore(builds): 重編執行檔——把 wait 的修法真的放進引擎成品（Arcrun#93 的閘抓到的） 
#101 併進 main 後，.worker-builds/arcrun-cypher-executor 還記著 a5e4caf，
比源碼 HEAD 少了 f1370e2（wait 搬回引擎那筆）。

⇒ 這正是 #93 那道閘存在的理由：**沒有它，這次出貨會送出一個
「引擎裡沒有 wait 修法」的成品**——leo 更新完照樣燒 CPU，而出貨線全綠。
閘寫出來的隔天就抓到一次，抓到的還是我。

arcrun-cypher-executor  source a5e4caf → f1370e22  sha256=8411ed59b7ad

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-12 15:30:26 +08:00
uncle6me-web 793a94ecb5 chore(worker-builds): 重編——#100 的修法要進執行檔才會送到用戶那台 
cypher-executor source 525faaf → a5e4caf（sha 49d59597 → d1765930）。
今天第三次在同一件事上被提醒：改完源碼沒重編，出貨與安裝送出去的還是舊的。
 2026-08-12 13:36:39 +08:00
uncle6me-web e69d6bbc03 chore(worker-builds): 重編——kbdb 的跳脫修法要進執行檔才算數（Arcrun#94） 
今天已經在這件事上被咬過一次（8e10f1d）：源碼改了、執行檔沒重編，
出貨會全綠地送出舊的。這次併完就重編，不留同一個坑。

kbdb source 525faaf → c497ec4（sha256 7bc66656 → ffb8d434）。
其餘四顆源碼沒動、位元組也沒動。
 2026-08-12 12:22:10 +08:00
uncle6me-web 8e10f1d83e chore(worker-builds): 重編官方成品——kbdb／cypher-executor 的修法之前只在源碼裡 
為什麼要有這一筆：`.worker-builds/` 是**出貨與安裝真正拿去部署的執行檔**，
而它記的 source_commit 在剛併完 #85／#88 之後對不上源碼：

    arcrun-cypher-executor  成品記的 797e7f7  源碼已經是 525faaf  ⚠️
    arcrun-kbdb             成品記的 a7e23ba  源碼已經是 3eb8b31  ⚠️

⇒ 這時候去出貨或 `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
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