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

8 Commits

Author SHA1 Message Date
claude-code 3f2e45f5dc fix(resource-rule): 上次裝到一半死掉的帳號要能再裝一次（Arcrun#123） 
封測者 1.4.45 實撞：
  a namespace with this account ID and title already exists
⇒ 那個帳號從此永遠裝不起來，而錯誤訊息對用戶完全無法行動。

根因：rule.mjs 第 2c 段只問「有沒有已部署的 worker 綁著它」，
不問「這個名字在帳號上是不是已經存在」。註解裡「本來就沒有東西可丟」
漏掉一種狀態——資源已建、worker 還沒部署就中斷（逾時／關掉分頁／斷網）。
拆除 youlin 時親眼看到的 8 顆空殼 KV 是同一個形狀。

修法：2c 在 create 之前先查同名。找到同名資源時：
  · 呼叫端聲明了 createNameIsOurs → 接回那一顆（adopt + reclaimed 標記）
  · 沒聲明 → 停手，訊息帶 RES-NAME-TAKEN 錯誤碼讓用戶回報

createNameIsOurs 是接管的唯一依據，預設 false（fail-closed）。只有名字
推導自使用者自己的身分時才准聲明——安裝器的
arcrun-rag-<slugFromEmail(email)>-kv-<binding> 合格；acr 從 toml 讀到的
裸 binding 名（WEBHOOKS）不合格，因為用戶自己也可能用那個名字。

這不是把 #97 刪掉的「照名字 ensure」搬回來：
  ① #97 找不到就新建一顆頂上去（會弄丟資料）；這裡找到才沿用，
     找不到照舊新建，永遠不拿新的空資源頂替既有的
  ② 排在「已部署綁定＝事實」之後，名字只在沒有任何綁定可看時才有發言權
  ③ #97 無條件相信名字；這裡要呼叫端先證明名字推導自用戶身分

順手補上假帳號的保真度：FakeCloudflare.createKvNamespace 原本不擋同名，
所以半殘帳號在測試裡看起來只是「多幾顆孤兒」，實際上是裝不起來——
少了那一行，這個 bug 測不出來。fixture-account.mjs 也把
resourcesExist 與 deployed 拆開，才表達得出這個狀態。

驗證（皆為實跑）：
  node shared/resource-rule/tests/half-finished-install.mjs  → 全部通過（零依賴）
  cd cli && npm test                                          → 73/73 pass
  sync-resource-rule --check                                  → 三份副本皆與原稿一致

⚠️ 只有規則這一半。安裝器要在 manifestRequirements 聲明 createNameIsOurs
才會生效，那一半在 arcrun-rag（D85）。

Refs: inkstone/Arcrun#123
 2026-08-14 08:08:37 +00:00
Leo 2fcae722e7 Merge PR #112: 藏書地圖看得到自己的知識——租戶字串改從寫入端來（Arcrun#108） 
總管複驗（不聽自述，自己重跑並與 base 逐條比對）：
  cypher  14 failed / 441 passed（base 14 / 400）⇒ 多 41 條新測試全過
          失敗清單 diff 無輸出＝逐字元相同、零回歸
  閘實測  照 #105/#108 的原句形狀種一個違規（env.CONSOLE_TENANT || leo）
          → 掃描器當場抓到並指名道姓；移除後恢復綠 ⇒ 不是假綠

這道閘的價值超過本票：它擋的是「身分來自環境變數」整族，
#105 那句話今天再寫一次也會被擋。符合 leo 08-12 立的
「做平台要減少 hotfix」——修掉 bug 不算完成，要留下下次再犯會被擋住的機制。

agent 誠實標的殘項（不擋併）：
  · kbdb_get_map 回 1851、Portal 總圖畫面、部分授權帳號實測——都要部署 leo21c，紅線沒碰
  · 想把閘也接進 .claude/hooks/pre-write-guard.sh（寫入前就擋），該檔受保護改不動；
    檢查器已備妥 --stdin 模式，總管代接
 2026-08-12 16:24:45 +00:00
uncle6me-web b223a69884 fix(portal): 藏書地圖看得到自己的知識——租戶字串改從「寫入端」來，不再拿環境變數預設值（Arcrun#108） 
leo 2026-08-12 實撞：藏書地圖回 0 個庫，同一分鐘 KBDB 裡有 1854 條三元組，
`arcrun_whoami` 顯示 admin／全部知識庫、`kbdb_search` 也查得到——只有地圖那格是空的。

病根（不是資料掉了，是讀寫兩端各拿一個來源）：
  寫入端 owner_id ＝ `~/.arcrun/config.yaml` 的 `api_key`（CLI push／小幫手上傳／MCP，
    leo ＝ `bfezv28v`）
  讀取端過濾 ＝ `portalTenant(env) = env.CONSOLE_TENANT || "leo"`
    ——repo toml 帶的**官方 prod 值**，而 `acr` 從來不注入 CONSOLE_TENANT
  ⇒ 那個 `"leo"` 不是理論邊角，是每台 self-hosted 實例的實際行為，1854 條全被濾掉。

與 #105（`env.MCP_OWNER_NAMESPACE || "leo"`）同一句話，換一個檔案。

租戶字串該從哪裡來（本票的核心判斷）：
  **從「寫入這批知識的那一方」來，不是從一份手抄的環境變數預設值來。**
  不是「掛到每個帳號上」——portal 帳號共用同一台實例的知識庫（design D-2），
  帳號之間的差別是 libraries 權限不是 owner_id；複製一份到帳號上只是多一個會過期的副本。
  #105 真正的教訓是：過濾用的租戶字串要有單一權威來源、解析不到要誠實失敗、且要能機械驗證。

修法：
1. 唯一產地 `cypher-executor/src/lib/tenant.ts`
   - `knowledgeOwner(env)` → branded `TenantId`：`ARCRUN_NAMESPACE` → `CONSOLE_TENANT` →
     丟 `TenantUnresolvedError`。**沒有字面預設值**——`|| 'leo'` 正是把「這台機器沒設定」
     偽裝成「你沒有資料」的元凶。
   - `accountTenant(env)` → 普通 `string`（帳號子 namespace `{tenant}::portal` 與 cypher
     自己寫的設定用它）。**回 string 是刻意的**：型別上就不可能流進知識資料面。
   - 資料面過濾一律經 `ownerQuery()` / `ownerField()`，只吃 `TenantId`。
2. 值的正解由 CLI 從真相源導出：`acr update` 把 config 的 `api_key` 注入成 `ARCRUN_NAMESPACE`，
   但**先驗再寫**（`GET /kbdb/map?owner_id=<api_key>` 查得到庫才寫；查不到／問不到就一個字
   都不動）。無條件覆蓋會把「知識本來就在 CONSOLE_TENANT 底下」的一鍵安裝實例指向空的那一格
   ——那是 #97/#106 那類「更新一次把人家的東西弄不見」，比原本的 bug 更糟。
   未注入時回退 CONSOLE_TENANT ⇒ 對官方 prod 與未更新的實例，這次改動是惰性的。
3. 空地圖分四態（沿 #100「讀不到就說讀不到」）：no_library_grant／filtered_out／
   scope_mismatch／confirmed_empty。scope_mismatch 以前不存在，所以設定錯誤被畫成
   「你沒有資料」。回應仍不含租戶字串（design §3.3 紅線）。
4. 同族一起修（同一道閘一次抓到）：console-dashboard 4 處、console-auth 1 處
   ——console 首頁的規模數字與藏書地圖對 leo 也一直是空的。

留下的閘（規則存在但沒機制驗證＝會再犯第三次）：
  · 型別閘：TenantId 只能由 tenant.ts 產出 → 拿隨手一個 string 去過濾，tsc 當場不給過。
  · 出貨閘：scripts/build-worker-artifacts.mjs 編 tier2 成品前先掃，違規 → 編不出成品。
  · 閘自己可測：規則是純函式（tenant-source-rules.mjs），tests/tenant-gate.test.ts
    逐條驗「5 種壞例子會擋」＋「11 種合法寫法零誤攔」；掃描範圍只有 src/，擋不到自己。
  規範寫入 .claude/rules/02-forbidden.md 第六類、system-dev/wiki/mistakes.md #26。

沒動：庫權限過濾（一字未改，回歸測試釘住）、帳號資料落點、任何金鑰、租戶字串仍不下發前端。

驗證：
  cypher   vitest 441 綠 / 14 紅，14 紅與 base commit e05518a 逐字相同（既有）
           tsc 5 個既有錯誤，零新增
  cli      node:test 60/60 綠（含本次新增 12 條）；tsc 零錯誤
  閘       壞例子實跑 exit 1；build 實跑「建置中止」；乾淨時實跑通過
  端到端   ◐ 未驗：需部署到 leo21c，那道閘要 leo 親手解（見 PR ③）

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-13 00:15:58 +08:00
uncle6me-web bb548b6fdf refactor(shared): 「該用哪些資源」搬出 CLI——一份實作，acr 與安裝器吃同一條規則 
leo 2026-08-12：「根本就不應該在 CLI，我要的是一個大家都可以用到的規則。」

「這個實例該用哪些資源」換到安裝器就要重寫一次 ⇒ 依 rules/07-thin-shell.md 的判準
它是**能力**，而它原本住在 cli/src/lib/resource-resolver.ts ⇒ 那本身就是違規。
後果已經真的發生：acr 那條有 Arcrun#97 的修法、安裝器那條沒有，於是安裝器照名字
找、找不到就建一顆空的綁上去 ⇒「我按了更新，工作流和登入全不見了」。

規則搬到 shared/resource-rule/（零依賴 ESM，Node 與 Workers runtime 都直接跑）：

  · rule.mjs           規則本體＋把 CF 回應讀成事實的 normalizeLive*
  · cf-resource-api.mjs ResourceApi 的 CF REST 實作——**眼睛也共用**：
                        兩條路各自解讀 CF 回應，只要一邊看不到既有綁定就會去新建，
                        #97 不需要規則寫錯就能重演
  · installer-entry.mjs 安裝器唯一該碰的入口 resolveInstanceResources()

不是做成 cypher 端點的理由（自舉）：這條規則要在「決定怎麼裝」的當下就用得到，
而那時 cypher 可能還不存在（安裝器的工作正是把它生出來）；且輸入是使用者自己帳號的
綁定狀態，不該送去平台換答案。它是純函式，用不著變成服務。

只有一份，機械看守：
  · 安裝器直接 import repo archive 裡的原稿，**不需要副本**
  · acr 因為 npm pack 打不進套件目錄外的檔案，帶一份逐位元組鏡射
    （scripts/sync-resource-rule.mjs 產生；build/test 先跑 --check，差一位元組就紅）
    ——同 cli/harness/ 產生物＋世代閘的既有慣例
  · cli/tests/single-implementation.test.ts 掃全 repo：7 支規則函式的實作只有一處

CLI 淨 -496 行（邏輯是搬走，不是複製）。cf-api.ts 的 CfAccountClient 保留公開介面，
ResourceApi 那七個方法全部委派共用 client。

驗證：cli 58/58 綠（含新增的兩條路一致性 fixture ＋ 三種情境），tsc --noEmit 乾淨。
 2026-08-12 23:37:01 +08:00
uncle6me-web 53b05c6d3d fix(cli): 更新完還看得到版本號——CLI 重部署不再把版本標籤（和你的設定）洗掉 
leo 08-12 實撞：更新完 leo21c，Portal 設定頁的「版本」變成
「無法讀取目前版本（知識庫服務可能正在啟動）」。版本號是 leo 唯一的驗收介面，
看不到就等於他無法自己確認任何一次更新有沒有生效。

根因（Arcrun#106）：`bundle_version` 來自部署時注入的 plain_text var
`ARCRUN_BUNDLE_VERSION`，而**只有安裝器會注入**。wrangler deploy 是整份覆蓋，
toml 沒寫的 var 直接消失 ⇒ CLI 更新那條路每跑一次就把標籤洗掉一次。
#97 修好了「櫃子」（KV/D1/Vectorize 沿用既有），沒修「櫃子上的標籤」。

修法（兩種 var 走相反的規則，這是本次的判斷）：
· 設定類 var ＝ 使用者實例的事實 → **沿用**（讀綁定時同一份回應就帶回來，不多打 API）
  ——把 #97「已部署的 worker 上綁著什麼就是事實」原封不動套用到 plain_text var。
· 版本標籤 ＝ 這份成品的屬性 → **每趟重烙，絕不沿用舊值**。
  沿用舊值會得到一個永遠停在安裝當天的假標籤——比沒有標籤更糟，
  因為它會讓人以為驗收過了。
  版號取部署當下發行頻道公告的 release（Portal/daemon 就是拿它當「最新版」比），
  另外把**真正部署的 commit** 一起烙上去（/health 多吐 `bundle_commit`）→ 漂掉查得出來。
  查不到 release 就誠實退成 `YYYY-MM-DD+<commit7>`，不掰一個 semver 假裝已是最新。

順帶（都是同一條路上的東西）：
· ref 先解析成 commit sha 再用 sha 下載 archive——不可變，順手解掉 branch tarball 被快取的老病
· Portal 版本行接受帶 build metadata 的 semver（`1.4.41+d61` 這種先前一律被當成「較舊版本」）
· cli 測試在 node 22 上本來一支都跑不起來（.js→.ts 解析 + parameter property），補上 resolve hook
  ——#97 那份「使用者的東西還在不在」的迴歸守衛也在其中，跑不起來的守衛等於沒有守衛
· types.ts 的 ARCRUN_BUNDLE_VERSION 重複宣告（TS2300）併回一處

驗證見 PR：cli 49/49 綠、cypher health 4/4 綠、Portal 版本行原始碼實跑五種情境、
對真實已部署 worker 的唯讀 dry-run。**未做**：真實實例上的 acr update 端到端
（本機唯一有憑證的帳號是 leo21c＝紅線禁碰，youlin 無憑證）。

Refs: Leo/Arcrun#106, #97, #95

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-12 21:58:43 +08:00
uncle6me-web 45a546a686 fix(cli): 更新不再照名字找資源——已部署 worker 綁著什麼就是什麼（Arcrun#97） 
病根：更新會「確保」它需要的資源存在，而它是**照名字找**的。
使用者的資源是安裝器建的（`arcrun-rag-<x>-kv-webhooks`），更新找的是 `WEBHOOKS`
⇒ 找不到 ⇒ 新建一顆空的並綁上去。

2026-08-12 實撞（leo21c）：一次例行更新後
  KV 9 顆 → 18 顆、D1 1 顆 → 2 顆，worker 全綁到新建的空的
  ⇒ 工作流一支都看不到、portal 登出、總圖空的、80 把 recipe 解不出來
  leo 原話：「leo21c 是掛掉的」。資料沒掉，但從他的角度就是東西全不見了。

修法方向：**已經部署上去的 worker 綁著什麼，那就是事實**——
名字是使用者那側的事，不是更新指令可以決定的。

📍 repo：matrix/arcrun（cli/）｜📍 票：Leo/Arcrun#97
 2026-08-12 13:30:17 +08:00
Leo 621cb8d948 feat(cli): code 零件接進 acr init/update 部署流程（自足 Worker 進部署清單 + vendored wasm 進 repo） 
動機（Arcrun#4 後續，leo 批准）：code 零件只有原始碼（registry/components/code），
downloadAndDeploy 完全沒涵蓋它——tier1 只掃 .component-builds/*（TinyGo 家族，要求
component.wasm），tier2 寫死四個引擎。merge 後用戶跑 acr update 應真的裝上 code。

接法（實查後裁定）：
- code 是自足 Worker（quickjs-emscripten wasmfile variant，非 TinyGo；見其 index.ts 頭註），
  「缺 wasm」的真相是「這一類根本不在部署清單」+「vendored quickjs.wasm 是 gitignored
  build 產物、不進 archive」。
- deploy.ts 新增 SELF_CONTAINED_COMPONENT_WORKERS（目錄 + 必要產物 gate，比照 tier1
  component.wasm gate 的誠實跳過精神），discoverWorkerDirs 將其排進 tier1（零件先於引擎）。
- vendored quickjs.wasm（491KB）commit 進 repo：.gitignore 放行（完全比照
  !.component-builds/**/component.wasm 的「部署物 wasm 例外」先例）→ acr update 從
  Gitea archive 直接拿到，更新不需 npm build 工具鏈。
- 共享依賴抽成 SHARED_DEPLOY_DEPS 並補 quickjs-emscripten-core + wasmfile variant
  （版本對齊零件 package.json，測試看守 drift）→ root 裝一次、esbuild 往上 resolve。
- 注入零改動：既有 stripOfficialOnlyBindings 剝掉 code.arcrun.dev 官方 route、
  workers_dev=true 保留 → self-hosted 自動落 arcrun-code.<sub>.workers.dev。
- parts.ts BUILTIN_COMPONENTS 加 code 條目（issue #13 W3：零件=靜態清單）→ acr parts 可見。
  實查：init 本來就不對 registry 註冊任何零件（registry index 是官方 backfill 腳本的事），
  故「比照其他零件」＝進 BUILTIN_COMPONENTS 即對齊。

測試：cli/tests/deploy-code-component.test.ts 9 顆全綠（node --test，零新依賴）：
部署清單含 code / 缺產物誠實跳過 / wasm 已 git 追蹤（會進 archive）/ SHARED_DEPLOY_DEPS
涵蓋零件全部 runtime deps + 版本一致 / route 剝除與 [vars] 保留 / parts 清單含 code。
tsc --noEmit 綠；零件自身 12 顆 vitest 綠（沙箱行為未動）。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015d5jDbuqT5Htwv3Q88XXKk
 2026-07-07 09:01:11 +00:00
Leo 794e3eba3a fix(cli): acr update/deploy 下載源由 GitHub codeload 改指 Gitea archive（Arcrun#4） 
動機：D20 防 flag 鐵律下 self-hosted 用戶（如 Mira）不能碰 GitHub，
而「init 之後才新增的零件」（如 code 零件）唯一重裝管道 acr update 綁死
GitHub codeload → 沒有乾淨重裝路徑。

改動（只碰 CLI 下載邏輯，不動 README/cypher/mcp/tools）：
- deploy.ts：ARCRUN_REPO 預設 uncle6me-web/Arcrun → Leo/Arcrun；
  新增 ARCRUN_GITEA_BASE（預設 https://git.uncle6.me）與 giteaToken()
  （ARCRUN_GITEA_TOKEN > GITEA_TOKEN，不寫死）。
- 抽出純函式 buildArchiveUrl / buildDownloadHeaders 走 Gitea archive API
  GET {base}/api/v1/repos/{owner}/{repo}/archive/{ref}.tar.gz，保留 #13 P2
  cache-buster + no-cache 防 stale；private repo 帶 Authorization: token。
- downloadRepoTarball 改用上述；401/403 給「設 GITEA_TOKEN」提示。
- update.ts docstring 對齊（GitHub release → Gitea archive；標註 install≈update）。

install≈update：init 與 update 共用 downloadAndDeploy，其內容指紋 manifest
天然「新零件補、內容未變者略過」，故用戶跑 acr update 即補裝新零件。

測試：cli/tests/deploy-url.test.ts（Node 內建 test runner，零新依賴）8 顆全綠，
涵蓋 URL 組裝、repo/base 覆蓋、token→header、public 無 token、env 優先序。
真正打 Gitea 下載/部署是 leo 的閘，不在本 PR。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015d5jDbuqT5Htwv3Q88XXKk
 2026-07-07 08:13:05 +00:00