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

72 Commits

Author SHA1 Message Date
richblack 68f042cfd0 fix(resource-rule): 帳號上資源超過一頁時，規則看到的必須是全部（Arcrun#123 續集） 
三支清單方法只打 `?per_page=100`，也就是**只看第一頁**。這個洞在 #123 的修法
前後嚴重度不同，這才是它必須跟那張票一起修的理由：

  · 修法前：被截掉的是「worker 綁著的那顆」→ 2b 判「綁著的資源不見了」
            → blocker → 停手。誣告使用者，但安全。
  · 修法後：被截掉的是「同名殘骸」→ 2c 判「這個名字沒被佔走」
            → 去建 → CF 回 title already exists → #123 的死路原樣回來。

⇒ 修法把它從「叫得太大聲」變成「安靜地復發」。分開出貨等於把 #123 的災情
  延後到「資源比較多的帳號」再爆。

做法：`cfListAll()` 翻到底；翻不完、或數量對不上 CF 回報的 `total_count`，
一律 throw ⇒ 變 blocker ⇒ 整趟停手（README 規則第 3 條）。
「我不知道」不准被當成「它沒有」。

三支端點的分頁行為不一樣（2026-08-14 在 geek6688 帳號實測，唯讀）：
  /storage/kv/namespaces  result_info 有 total_pages
  /d1/database            result_info **沒有** total_pages ⇒ 不能拿它當終止條件
  /vectorize/v2/indexes   result_info 是 null，不分頁（分頁參數被忽略）
所以終止條件只用「三支都有或都沒有」的兩件事：result_info 在不在、total_count 對不對得上。

fixture 的清單端點同步照真 CF 的形狀分頁（三支各自不同）——假資料失真就會養出
「拿 total_pages 當終止條件」這種在 D1 上必壞的實作，而測試全綠。

新增 tests/list-pagination.mjs（在舊碼上實測會紅，且第 ③ 段直接重現
「無 blocker → 排 10 顆新建 → CF 回 title already exists」的 #123 死路）。
cli 73 項全綠、demo 與 half-finished-install 全綠。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-14 19:52:24 +08:00
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
uncle6me-web 7e3ca4c1a1 Revert "WIP(kbdb): 語意搜尋零命中的排查——⚠️ 被總管中途叫停，未完成驗證" 
This reverts commit af3edff856.
 2026-08-11 23:18:38 +08:00
uncle6me-web 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
uncle6me-web 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
uncle6me-web 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
uncle6me-web 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
uncle6me-web 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
uncle6me-web 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
uncle6me-web 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 f3af5d3 --stat 實查：只有 3 個檔，全在 kbdb/）

本次補上安裝器那半：
· KBDB_VECTORIZE_INDEX: arcrun-kbdb-embed → **arcrun-kbdb-embed-m3**（換名字，非只換維度）
· ensureVectorizeIndex: dimensions 768 → **1024**
· kbdb/wrangler.toml 說明與 metadata-index 指令同步改新名（照抄不會建錯 index）
· embed.ts docstring「768 維向量」→ 1024（分支漏改，會誤導）

## 為什麼要換「名字」不是只改維度
① 維度 768→1024，舊 index 收不進新向量
② 就算維度相同也不能沿用——不同模型的向量混在同一 index 比對出來是垃圾，
   而 #58（Vectorize vector delete 未接）代表舊向量刪不掉
   ⇒ **開新名字反而順手繞開 #58**，且新舊並存可回滾。

## 查證（歷史警察 Q0-Q3，非假設）
· git log --all -S"arcrun-kbdb-embed-m3" / -S"dimensions: 1024" 皆空 ⇒ 無分支改過，非重造輪子
· **metadata index 用同一個常數**（deploy.ts:426 ensureVectorizeMetadataIndexes）
  ⇒ t36 的四個 metadata index（owner_id/entry_type/source/library，Arcrun#11 根因修復）
  會自動建在新 index 上，**不會因改名而遺失**——這點特地查過，不是假設。

## 驗
· kbdb 測試 87/87 綠（含新增 4 項 embed-model-config）
· cli tsc --noEmit **零錯誤**
· 三處一致性機械確認：embed.ts=bge-m3／deploy.ts=dimensions 1024／index=arcrun-kbdb-embed-m3
· 踩到並記錄：註解寫 `**dimensions=1024**​/metric` 會因 `*/` 提早關掉 block comment（TS1127）

## 既有實例遷移（尚未執行，需對實例操作）
建新 index → 重部署 kbdb（binding 指新 index）
→ POST /embed/backfill {"reindex":true} 到 remaining=0 → 舊 index 可刪。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-05 13:46:33 +08:00
uncle6me-web 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
uncle6me-web 46afea83c2 步驟1 最後一筆：install-harness 交付內容升級到現世代＋世代閘 
管道本來就是好的（install-harness 功能完整、冪等），**過時的是內容**：
harness skill（4066B）grep「意圖」「>>」= 0 命中，只講世界觀／別寫 Python
⇒ 新裝的封測者拿不到步驟 1 的核心教材（`>>` 意圖語法）。

■ 單一真相源：harness skill 改為建置期由 registry 複製
  build-harness-skill.mjs＝head ＋ registry/skills/write_intent_workflow.md 正文 ＋ tail。
  選「建置期複製」的理由：npm files 只收 harness/，registry 不進套件；
  symlink 在 npm pack 與 Windows 不可靠。產物 commit 進 repo（npm 裝的是產物、不跑 build）。
  head/tail 是 harness 專屬（CLI 語境入口／acr 指令表／暴露同意／誠實鐵律），
  install-harness 的 copyTree 跳過 .head/.tail，不鋪進使用者專案。

■ 其餘三件逐份對照現世代事實後更新（過時的直接刪，不留死代碼）
  - CLAUDE.block.md：補 >> 意圖語法、not_found 兩條路、零件 vs recipe 分型、
    腹語術紅線、金鑰只拿名字
  - commands/arcrun.md：步驟改成「先寫意圖 → 丟去查 → 再寫 YAML」，補 acr search／validate
  - hooks/arcrun-guard.sh：**正路提示改為指向 arcrun-mindset Skill ＋意圖語法**
    （呼應「hook 沒提 skill 反而把 AI 導向 repo 文件」的教訓）；
    新增 code 節點腹語術提醒，settings.fragment 補 Write|Edit|MultiEdit matcher

■ 世代閘（防再度脫節）
  check-harness-generation.mjs 檢查四件交付物的現世代指紋，缺指紋 exit 1，
  掛進 npm run build（prepublishOnly 因此也擋）。
  反向驗證：把 skill／CLAUDE.block 換回上一代 → 兩者都被擋下並逐條點名缺哪個指紋。

■ 驗收（考生 haiku／受測物＝環境）
  乾淨臨時目錄 acr install-harness → 四件鋪好；重跑冪等（全檔 md5 不變、
  CLAUDE.md 66 行不變、hooks 條目 2 不變、arcrun 區塊仍 1 個）。
  haiku 只讀該目錄的 CLAUDE.md＋SKILL.md（明令禁讀 ~/.claude、禁上網；
  兩份教材 md5 與大小均不同，可證非考本機那支）答十題
  → grade-step1.sh **10 / 10 通過**（判分器同時反向驗證仍會抓
  ON_TRUE／ON_FAILURE／第一節點非 input）。
  npm test 18/18、tsc 綠。

SDD：workflow-discovery/tasks.md 3.11

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-07-31 15:29:17 +08:00
uncle6me-web 9c9aff0046 t158 P1 素材：workflow export/import 原語（definition 端點＋CLI 命令，未接線） 
leo 07-31：「你要做的就是一個叫 export，另一個是 import……現在如果我要把我做的
工作流分享給同事，我要怎麼 export？他要如何 import？是缺了功能用 search 來湊嗎？」

- cypher GET /webhooks/named/:name/definition：吐可攜定義（graph＋config＋description
  ＝record 原樣）——export 的引擎端；import 端直接 POST /webhooks/named 即送進任何實例
- cli/commands/workflow.ts：acr workflow export <name>（definition→.workflow.yaml，
  flow 從 graph.edges 反推供人讀）／import <file>（graph 直 POST，零編圖零 search
  零存在性驗證＝V2 純複製；手寫 yaml 無 graph → 指去 acr push）
- ⚠️ 未接線：index.ts 尚未掛 workflow 命令組（P1 收尾：接線＋分享場景 A export→
  B import 驗收＋parser 共用模組化）

安裝器側 P0（rag-installer 5a6539d）已用同形狀（打包期預編 graph＋純上傳）上 prod。

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-07-31 13:49:23 +08:00
uncle6me-web 7e631a890a t158 迴歸修復「部署≠發現」：複製路徑回毫秒級純編圖，誠實化只留在 discover 
leo 07-31 定調：「這裡只是複製一些工作流的 data 過去，沒有要在這裡驗證，難怪這麼慢。
就算是我自己寫了錯的工作流，也可以跑跑看，如果錯誤就修改，
沒有說有錯誤還要一個個驗證這回事。」

定性＝迴歸非新設計：部署路徑純複製是既有設計（arcrun-rag installer/src/index.js:13
「workflows.json 是既有 workflows/*.local.yaml 的搬運（打包期抽 flow/config）」＋
arcrun-rag wiki「workflow 打包期預編成 workflows.json（worker 免帶 parser）」）。
5cadc60 起誠實化漏進 /cypher/search ⇒ 複製路徑也逐節點跑兩庫查詢＋相似搜尋
（每 missing 節點 1+9 次 HTTP＋recipe KV 掃）⇒ 冷實例 8 節點實測 25.7s、
安裝器 15s timeout 必炸（leo stage 實走 rag_takedown_direct aborted）。

改動：
- /cypher/search 加 mode：compile＝純編圖零查詢（安裝器/acr push 複製路徑）；
  discover＝誠實查詢預設（AI 問「有沒有」的既有契約，not_found＋分型指路全保留）
- /cypher/execute 一律 compile（存在性由 component-loader 執行時決定＝原權威）
- compile 的節點 status 標 unchecked（誠實「沒查」，不回假 found）
- discover 批次化：registry 新增 GET /components/catalog（一次回全目錄含
  input_schema，補 CP2-B「沒有列表端點」缺口）＋recipe 清單一次抓，
  存在判定與相似度全記憶體比對；舊 registry 無 catalog 端點 → 退回逐顆（相容）；
  registry 整個查不通 → unknown 照舊（不誤判 not_found）
- cli push 帶 mode:compile＋拔 missing 擋（push 不看 missing；要問有沒有走 validate）

驗（本地 wrangler dev 誠實環境，registry 種 20 合約）：
- compile 編圖：graph_neighbors 39ms／rag_chat(11節點) 3ms／rag_ingest_card 2ms／
  rag_takedown_direct(8節點) 3ms——回迴歸前毫秒級
- 安裝器 pushWorkflowTo（mode:compile）4/4 ok（44/7/7/5ms）
- 故意引用不存在零件的 workflow：部署 ok=true，trigger 執行時誠實報
  「找不到零件…」＋可用零件清單（部署≠發現實證）
- discover 契約：邏輯名 missing=2＋not_found＋suggestion（21ms）；
  頂層 verify.sh 01 組 5/5＋03 組 4/4 全綠
- cypher+registry tsc 全綠；vitest 9 failed/179 passed＝5cadc60 基線完全相同

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-07-31 13:31:33 +08:00
Leo 8d8b01d240 docs(sdd): credential-primitives-wasm 封存進 archive（T10 完成，卷已結案） 
leo 2026-07-21 明令封存：卷已完成，留主目錄會讓未來 session 誤以為進行中。
最後一項 T10（廢除自管加密金鑰）已於 20c7610 完成（移除約 2500 行）。

- git mv 整卷 → system-dev/docs/3-specs/archive/credential-primitives-wasm/
  design.md status: closed；superseded_by 留空（據實：非被另一卷取代，是機制整個換掉）
- 卷首補「封存時仍未完成的項目」——逐條查 code 核實，不當作完成：
  真缺口＝auth_mtls 從未實作、7.6 self-hosted auth 鏈端到端從未驗；
  另有勾選過期（auth_oauth2 其實已完成）與驗收條件已作廢（與現行 rule 07 牴觸）者
- 修好 14 處引用（原盤點 10 處，實際更多）：session-start-load-sdd.sh 內容嚴重過期
  （把已完成 Phase 寫成進行中）→ 改為以 frontmatter 為判準；四份 rules、CLAUDE.md、
  BACKLOG、3-specs/README、deploy.ts、credentials.ts、wrangler.toml 逐一按性質處理
- 額外：system-dev/docs/2-architecture/ 有四個規則檔重複副本（06-08 遷移遺留）
  → 同步修好，否則留一份過期真相（今日第三次撞到「同一資訊兩份副本」的債）
- 02-forbidden.md §2.1 列的三個「待刪違規 TS」其實早已不存在
  → 改標刪除線＋禁止重新引入（過期文件同時製造假待辦與假進行中）

驗證：sdd-active-check exit 0（active 仍恰一份＝portal-auth）；
session-start-load-sdd.sh exit 0；cypher-executor 與 cli typecheck 全綠；
測試 187/188（唯一 fail 為 pre-existing，stash 覆驗相同）。

未動：pre-write-guard.sh 的 KNOWN_SDDS 白名單不含 archive 路徑
（放寬 guardrail 需明確授權，留待決定）。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-07-21 01:57:34 +08:00
Leo 20c7610371 refactor: 移除已廢棄的自管加密金鑰機制（credential 全面託管 CF Workers Secrets） 
leo 2026-07-20 明令：「已經改用 cf 自己的 secrets，不要再說它了」
「我希望以後再也看不到這個詞再出現」

背景：credential 早已遷移至 CF Workers per-script Secrets + D1 目錄，
舊的自管金鑰（client 端 AES-GCM + KV 密文 + crypto_decrypt）是遷移期遺留。
本次連根移除，含一併作廢的死 SaaS 碼。

移除：
- 舊 KV 密文解密路徑（credential-injector.ts 整檔、dual-read fallback）
  前置驗證：leo21c / youlin 兩帳號 CREDENTIALS_KV 實測 *:cred:* 皆 0 筆
- migrate-to-workers-secrets 搬家端點（回填已完成，無可回填）
- /register 路由與 generateApiKey（HMAC 產 ak_ key 是 SaaS 遺物；
  self-hosted 走 namespace 明碼 D21，已無人使用）
- platform_crypto component（三帳號實測 404 已退役，無 workflow 引用）

保留（附理由）：
- crypto_decrypt 保留為永遠回失敗的 stub——現役三個 auth .wasm 仍宣告該
  import，缺項會讓 WASM instantiate 直接失敗。待零件重編後可真正刪除。

順帶修復（原不在範圍，但會實際壞事）：
- /auth/callback 有 `if (!key) redirect(server_error)` 閘，未設該 secret 的
  實例會登入直接失敗 → 已移除
- OAuth 兩處把 provider token 寫進舊加密 KV（租戶鍵與實際 api_key 在 rotate
  後必然分歧，已失效）→ 改導向 Workers Secrets，包 try/catch 不影響登入
- acr init Standard 模式呼叫已刪除的 /register → 改引導 OAuth 取 key
- .claude/rules 與 system-dev/docs 是同一規範的兩份鏡像，先前只改 rules
  導致鏡像仍在教舊做法 → 已同步（此類雙檔同步應納入檢查）

新用戶安裝從此零 secret 前置。
測試 187/188（唯一 fail 為 pre-existing，stash 驗證與本次無關）；
cypher-executor 與 cli typecheck 全綠。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-07-21 01:32:48 +08:00
uncle6me-web 85ffe2d16d chore(release): 1.3.14 npm 補發——對齊 main（exposure 閘已移除/creds 新行為），治 npm drift 兩次誤判根源 
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-07-08 21:36:30 +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
Leo 9a609c4a04 Merge branch 'main' into feat/mcp-tool-rename-arcrun 2026-07-07 06:02:07 +00:00
Claude 5fc7277c3c refactor(mcp): u6u_* tool 全面 rename 為 arcrun_* + 前綴收斂單一來源 
零 u6u 洩漏（leo 要求 1）：connector tool 清單只剩 arcrun_*，並移除壞掉/
重複的 u6u_ workflow tool（deploy/execute/get/list_workflows 由 arcrun_
push/run/get/list_workflows 取代）；MCP server name 也由 u6u-mcp-server
改 arcrun-mcp-server。

前綴單一真相源（leo 要求 2）：新增 mcp/src/brand.ts（TOOL_PREFIX + toolName()
helper），所有 server.tool() 註冊一律走 toolName("suffix")，前綴不再明碼散寫。
未來 rebrand 只改 brand.ts 一行。

- 12 個獨有能力 tool rename（component/tag/gui/search_workflows）
- 4 個重複/壞掉 tool 移除
- inter-tool hint、描述字串、註解內 u6u_ 名字全數更新
- tsc exit 0；vitest 19/19 綠

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015d5jDbuqT5Htwv3Q88XXKk
 2026-07-07 05:21:34 +00:00
Claude 92cfb9c59f fix(mcp): address PR #15 review — aud validation, OAUTH_KV auto-inject, TTL/​sunset docs, drift test 
leo review 5 條逐條處理：

1. RFC 8707 aud 驗證（真缺口）：partner-auth OAuth 路徑補「at.aud === resourceUri(originOf(url))」，
   不符回 401 invalid_token（防別的 arcrun-mcp 部署簽的 token passthrough）。加 aud 不符→401 測試。

2. deploy.ts injectWranglerConfig 涵蓋 OAUTH_KV（在 PR 內補）：OAUTH_KV 納入 REQUIRED_KV_NAMESPACES →
   acr init/update 自動建 namespace + 注入用戶帳號真 id（比照 SUBMISSIONS_KV 家族）。wrangler.toml 註解
   更新（CLI 路徑自動、手動直推才需手建）。注入 regex 已驗證命中。

3. MCP_TOKEN_TTL 預設維持 30 天（leo 拍板不改）：OAUTH.md 明寫為有意取捨（無 refresh token → 到期重走
   OAuth＝再輸 owner secret），MCP_TOKEN_TTL 可調、7 天為更保守選項。per-owner 可調另開 issue #19（非阻塞）。

4. ALLOW_PLAINTEXT_NAMESPACE 逃生門標 SUNSET（code + wrangler.toml + OAUTH.md），開 issue #18 追蹤
   「遷移完成後移除整段 code path + Env 欄位」。

5. 防 drift 測試：spy KV 攔所有 put，斷言對 OAUTH_KV 的每一次 put 都帶 expirationTtl>0（完整流程 +
   store 層兩道），防未來往這顆短效 KV 塞長效資料。

驗證：mcp tsc exit 0、vitest 45/45（+aud +drift×2）；cli tsc exit 0。

Refs #15 #18 #19

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015d5jDbuqT5Htwv3Q88XXKk
 2026-07-07 04:56:59 +00:00
kbdb-cc befc63cfe0 fix(kbdb/embed): 語意查詢 metadata 過濾根因修復（Arcrun#11） 
根因：Vectorize index 建了卻從沒建 metadata index。CF Vectorize v2 要對某
metadata 欄位下 filter，必須先為該欄建 metadata index，否則帶 owner_id/
entry_type/source 過濾的語意查詢一律回 0 命中（app 端 filter 接線本來就對）。
且 metadata index 只索引「建立後 upsert」的向量 → 既有向量須重推才會被收錄。

- deploy.ts：加 ensureVectorizeMetadataIndexes()，隨部署冪等建 owner_id/
  entry_type/source（string）三個 metadata index（self-host/官方帳號皆自動）。
- embed.ts / routes/embed.ts：backfillEmbeddings 加 reindex+offset，重推「所有
  embeddable（含 is_embedded=1）」既有向量，讓事後建立的 metadata index 收錄；
  POST /embed/backfill {"reindex":true} 觸發，offset 分頁到 remaining=0。
- wrangler.toml：註解補 create-metadata-index 手動步驟 + reindex 提示。
- tests：mock DB 對齊 LIMIT?/OFFSET? 與 reindex predicate；補 reindex 測試。

leo21c 已驗：owner_id=leo / entry_type 過濾修前 0→修後命中，不帶過濾不變。
已知後續（非本 bug 症狀）：source 值 89-91 bytes 超過 Vectorize string
metadata index 的 64-byte 索引上限 → source 過濾對長值失效，另案。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HJiLCRUU2o3aSpPEzVCt2o
 2026-07-06 06:03:43 +00:00
Claude 1d19d46161 feat(credentials): T8 回填端點 + T9 治理端點/CLI (credential-store-migration) 
- POST /credentials/migrate-to-workers-secrets：舊 KV credential 逐筆解密回填 D1+Workers
  Secrets，冪等可審，重用 wasi-shim 唯一合法 crypto_decrypt 呼叫點
- GET /credentials 改讀 D1（與既有 /credentials/catalog 共用查詢）；DELETE 改為新家優先、
  舊 KV fallback，避免孤兒資料
- acr creds list/replace/delete 三支 CLI 薄殼指令；順手修好過期的 acr creds push（舊
  client 端加密格式已被 T5 取代）
- 新增 cypher-executor/tests/credentials.test.ts + D1 test fixture

T6/T7（讀取/注入路徑、雙讀 fallback）需要重新編譯 registry/components/auth_static_key
的 TinyGo WASM，本環境無 tinygo 且 proxy 擋 github.com 下載，卡在工具鏈缺口，詳細分析
記錄在 credential-store-migration.md。

端到端驗證：部署到 leo21c 帳號真實跑過 GET/POST/DELETE 三分支 + migrate 端點（對真實
既存的兩筆 credential 跑，發現 cypher-executor 自己的 ENCRYPTION_KEY secret 疑似為空，
誠實記錄為待 leo/總管裁決的不可逆風險項，未擅自重設）。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
 2026-07-04 23:00:07 +00:00
Claude 05333b8fe6 feat(credential-store-migration): T3 best-effort — secrets 設定就緒 + 誠實缺口 closure 
acr init 加印手動指令 wrangler secret put CF_SECRETS_API_TOKEN
（比照既有 ENCRYPTION_KEY 模式，不發明新模式）；CF_ACCOUNT_ID 已在
T5 的 deploy.ts 改動中自動注入（同 WORKER_SUBDOMAIN 機制）。

誠實缺口 closure：對本次真實改動過的 committed code（leo21c
arcrun-cypher-executor）做第二次 wrangler deploy，確認
CF_SECRETS_API_TOKEN/ENCRYPTION_KEY 兩個 secret 存活 + 寫入路徑
redeploy 後仍正常運作（真實 curl 驗證），比 T1.5 spike 對 throwaway
worker 的舊證據更貼近本次改動。

刻意不跑 acr update：mistakes #23 已知限制（硬綁 GitHub codeload
舊碼，會拉回覆蓋剛部署的 T4/T5 成果），跑了只會摧毀測試環境又
證明不了新東西，SDD 本身允許此替代路徑。此結構性衝突留 leo 裁決。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018D6QoC5waFkcjc2N7csJBB
 2026-07-03 23:07:42 +00:00
Claude c24edbbdb6 feat(credential-store-migration): T5 寫入路徑改走 Workers Secrets + D1 ref 
POST/PUT /credentials 改寫：密文值 PUT 進 CF Workers per-script Secrets
（唯寫，D19 不持有內容物），D1 credentials 表只存目錄（不含密文）。
secret_ref = CRED_<NAME>_<sha256(api_key)[:8]>，避免跨租戶撞名。
DELETE/GET /credentials 本次不動（仍走舊 KV，T9 範圍），已誠實標注。

新增 CREDENTIALS_DB D1 binding（與 KBDB base 共用同一顆 arcrun-kbdb，
沿用既有 database_id 注入機制）+ CF_SECRETS_API_TOKEN/CF_ACCOUNT_ID
env vars（CF_ACCOUNT_ID 由 deploy.ts 自動注入，同 WORKER_SUBDOMAIN 模式）。

§2.4 選項甲落地：client 不再加密，明文值經 TLS 傳輸，cypher 短暫經手
明文不落地不持金鑰——與舊版 01-tech-stack.md 傳輸格式不同，是本 SDD
對舊格式的刻意取代（§6 Q-b 仍需 leo 明確接受）。

驗證：tsc --noEmit exit 0；vitest 26/27（1 pre-existing 無關失敗）。
端到端：真實部署 leo21c arcrun-cypher-executor，POST/PUT /credentials
成功寫入 Workers Secrets + D1 row（CF API + D1 query 雙重確認），
清理測試資料後 restore wrangler.toml（無帳號專屬 id 殘留 git）。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018D6QoC5waFkcjc2N7csJBB
 2026-07-03 23:04:59 +00:00
Claude f9dad311ff feat(credential-store-migration): T2 D1 migration 0002_credentials.sql 
新增 credentials 目錄表（api_key/name/service/sensitivity/secret_ref/
created_at/last_used_at，PRIMARY KEY(api_key,name) + idx_cred_apikey），
D19：只存目錄不存密文，密文本體改住 CF Workers per-script Secrets（T5）。

deploy.ts 重用既有 applyD1Migration，緊接 0001_base.sql 之後套用同一顆 D1，
機制完全一致（同一支 CF D1 query API）。

驗證：cli tsc --noEmit exit 0；leo21c arcrun-kbdb D1
（1099d0f3-d062-4202-984c-5a57b0a8c031）實際套用，
sqlite_master 確認 table+index 存在，重跑驗證冪等。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018D6QoC5waFkcjc2N7csJBB
 2026-07-03 22:52:09 +00:00
uncle6me-web 2a51d67da0 fix(deploy): cache-bust codeload tarball 下載，修 seed 假綠根因 (Arcrun#13 P2) 
根因：acr update / init 從 codeload.github.com/.../tar.gz/main 抓部署源，該 branch
tarball 由 GitHub CDN 快取，push 後可 stale 數分鐘。「push→立刻 acr update」抓到舊
tarball → wrangler deploy 仍回 ✓ 但 ship 舊 code → /init/seed 只灌 23（舊種子數，
不含 telegram/line_notify/kbdb）。「deploy 成功」≠「部到修好的版本」= 假綠同一類。

實證：leo21c GET /auth-recipes 部署後仍持久回 23、無 telegram（非傳播延遲）；
source main 已含 27 個種子（git show main 核實），但部署的是舊 bundle。

修：downloadRepoTarball 加 no-cache header + cache: 'no-store' + 唯一 _cb query
param，強制繞過 CDN stale entry，每次抓 ref 的最新內容。

待 leo21c 驗：push 此修 + acr update → /auth-recipes 應變 26+（含 telegram）。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-29 21:04:52 +08:00
uncle6me-web c1a06df68f feat(exposure): 完全移除 acr push 暴露 consent 閘 (Arcrun#13 P1) 
leo 2026-06-29 拍板：arcrun 是給 AI 用的系統，push/暴露不再需要人類確認。
- 刪 cypher-executor/src/lib/exposure-consent.ts（server 閘，MCP push 的真正擋點）
- 刪 cli/src/lib/exposure-warning.ts（CLI 互動 + 非 TTY 拒絕）
- recipes.ts / webhooks-named.ts：移除 checkExposureConsent 403 閘，直接放行
- recipe.ts / push.ts：移除 obtainExposureConsent 呼叫，不再 prompt/拒絕
- init-seed / seed-api-recipes：移除種子層級 consent
- exposure_consent 欄位降為向後相容（讀舊 record 不報錯，不再寫入/檢查）
不補審計線索、不做替代防護（leo：先拿掉，出問題再設置）。
tsc 全綠（cypher-executor + cli）。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-29 20:58:32 +08:00
uncle6me-web 2aa26a5bdd feat(cli): acr search 跨類統一搜尋 + acr parts 去 hardcode recipe（issue #13 根治） 
leo 2026-06-29 重構根因：「telegram 與 google 不一致」其實是查錯表——舊世界要找一個能力
必須先決定它是 component/recipe/workflow 才查對清單，但查到答案前根本不知道屬哪類 →
「先知道分類」成了查詢前置，倒因為果（leo:連我都會查錯表）。這是搜尋設計缺陷，非粗心。

兩部分互補修法：
1. acr parts 清理（W3.1/W3.3）：移除 5 個 hardcode 的 recipe（gmail_send/google_sheets_append/
   telegram_send/line_notify_send/notion）——它們是 recipe(動態,存 store)不是零件(component)。
   只留真 WASM 零件。檔頭寫死分流原則 + 移除處留註解防再 hardcode。footer 改指向動態清單 + acr search。
2. acr search <term> 新增（W3.2，正向修法）：cli/src/commands/search.ts。fan-out 4 來源——
   component(靜態 BUILTIN_COMPONENTS) + recipe(GET /recipes) + auth-recipe(GET /auth-recipes)
   + workflow(GET /webhooks/named)，依類別回 counts+命中。各來源獨立 try（離線降級指路、不連坐）。
   查的人不必先選表 → 結構性消除「查錯表」。

薄殼合規（rule 07 §2）：search 只 fan-out 既有清單端點 + 過濾 + 分組 + 印出（介面層暴露/格式化），
不在介面層拼裝能力。component 靜態(PR-only)、recipe/auth/workflow 動態(store) 分流明確、不再 conflate。

實證（對 leo21c 跑，read-only GET）：
- acr search telegram → component:0 recipe:1 auth-recipe:0 workflow:1（一眼看出 telegram 是 recipe）
- acr parts → 只剩 http_request 等真零件，5 個 recipe 已不在
- tsc 全綠、build 通過

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-29 13:08:11 +08:00
uncle6me-web 225aa9f9e7 清 parts.ts 降級零件殘留：telegram/gmail/sheets/line 改走 recipe、移除已刪的 ai_transform（issue #13 步驟2） 
telegram/gmail/google_sheets/line_notify 已於 2026-05-29 Phase 2 降級為 recipe，
但 acr parts 仍列舊 component: 形態誤導 CC。參照 notion 樣板改成「走 recipe」描述 +
canonical_id 對齊 api-recipe-seeds.ts（telegram_send/gmail_send/google_sheets_append/line_notify_send）。
ai_transform_compile/run 已刪除（mindset §2），整段移除。
canonical_id 均已核實存在於 cypher-executor/src/lib/api-recipe-seeds.ts。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-28 16:05:39 +08:00
uncle6me-web 5d38b599fd feat(#11): CLI/MCP 薄殼對齊 — P0 run 死端點修 + P1 list 同源 + R4 防複發機制 
P0 CLI run 改打 /webhooks/named/:name/trigger 真端點（原打 /webhooks/<name> 死端點 404）。
P1 CLI/MCP list 收斂到 GET /webhooks/named（KV 同源）：
   - CLI list 停 CfKvClient 直連 KV，順手修 key 前綴 bug（原讀 workflow: 對不上部署的 {apiKey}:wf:）
     + self-hosted 不再需 CF API token。
   - MCP u6u_list_workflows 從讀 KBDB record 改讀 GET /webhooks/named（registry 簽名加 partnerToken）。
R4 防複發機制：
   - cli-mcp-capability-matrix.md（13 能力對照，docs/ gitignored 不進此 commit，僅本機）
   - thin-shell-smoke.sh（對真端點斷言非 404，本機手動跑非 CI/cron）
   - 機制自驗：注入故意死端點當場攔下、exit 1。

依賴關係：本批依賴 #8（webhooks-named GET 補 description/created_at 欄位、search/backfill 端點），
故疊在 feat/issue-8 branch 上、作獨立 commit。

⚠️ tsc 綠 = code done 非完成。端到端待 leo21c（CLI/MCP 真打通 200 非 404、smoke 對已部署 prod
全綠——目前 smoke 揭 #8 search/backfill 在 prod 仍 404=未部署）。P2 validate 收斂待 #10、
tag resource_id 語意債待方向①。#11 留 open。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-27 19:36:58 +08:00
uncle6me-web 934b9265d9 feat: KBDB self-hosted 查詢 + embed 模組 + thin-shell 收窄 + search_workflow（code done 待端到端） 
按 issue 分段標明（檔 #5/#8 改動交疊處無法乾淨拆檔，故併一個 commit）：

#4 thin-shell §3.1 自力救濟階梯 + code-node 規則（純文檔/規則，code-node 零件未實作）
#5 KBDB source filter（json_extract metadata_json 零建表）+ 能力對照；documents 聚合與
   DELETE proxy 部分擱置等頂層 T8
#7 base embed 模組（kbdb/src/embed.ts）+ vectorize 開關（deploy/config/wrangler.toml 註解範本）
   + 語義查詢降級閉環（mode=semantic 未開→LIKE+capability_hint）
#8 部分（workflow-discovery）：
   - KBDB /entries/search 加 base 通用 entry_type filter（entry-crud/embed/route/kbdb-proxy 透傳）
   - /webhooks/named 強制 description（空→400，訊息要求操盤 AI 據實寫一句）
   - 部署雙寫 entry_type=workflow embeddable entry（waitUntil 非阻塞，供 search）
   - cypher GET /workflows/search + MCP u6u_search_workflows（優先語意、降級 hint）
   - cypher POST /workflows/backfill-search-entries（無 desc 列出不編造）
   - GET /webhooks/named 補回 description/created_at 欄位（為 list 來源收斂備）

⚠️ tsc 綠 = code done，非完成（mindset §7 禁假綠）：
- #7/#8 端到端待 leo21c 部署驗（Vectorize 需官方憑證、CC 跑不了）
- #8 ①-a（MCP deploy 改打 /webhooks/named）未做、MCP deploy 那半仍 404
- #8 端到端（強制填擋空/語義命中/租戶隔離/降級 hint）未驗

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-27 17:52:52 +08:00
uncle6me-web b090695414 chore(release): cli 1.3.13（npm publish issue #2 KBDB_BASE_URL 注入修復） 
deploy 不只 git——self-hosted 用戶裝 npm 套件，修復要 publish 才到用戶手上。
自動 patch bump 1.3.12→1.3.13 + CHANGELOG 記錄（同 local-deploy.sh §6 邏輯）。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-24 12:35:50 +08:00
uncle6me-web 9c4333defb fix(cli): self-hosted 注入 cypher KBDB_BASE_URL 指向用戶自己的 kbdb（issue #2） 
injectWranglerConfig 的 self-hosted 分支原本只注 database_id / MULTI_TENANT，
漏了 KBDB_BASE_URL → cypher /kbdb/* 一律指向官方 arcrun-kbdb.uncle6-me，
self-hosted 用戶資料默默寫進官方庫（隔離破損）。

比照既有注入模式，用 ctx.workerSubdomain 把 KBDB_BASE_URL 就地改寫成
arcrun-kbdb.<subdomain>.workers.dev。init 與 update 共用此注入點，一處修兩條路。

驗證：tsc --noEmit 通過；真實 cypher toml 注入 subdomain=leo21c →
KBDB_BASE_URL = "https://arcrun-kbdb.leo21c.workers.dev"。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-24 12:26:36 +08:00
uncle6me-web 4d6e77ff2d chore(release): cli 1.3.12（local-deploy 自動 bump，含 block.md 三盲點重寫） 
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-15 13:20:29 +08:00
uncle6me-web b1e302b3b5 fix(kbdb): cypher proxy 補 /kbdb/entries CRUD + report_feedback 改打 /entries 
kbdb-base Phase 9.6/9.7（HANDOFF §2 缺口① + §3b 連帶）：

- 9.6 cypher kbdb-proxy 補 /kbdb/entries CRUD（POST/GET list/GET :id/PATCH :id）
  純轉發到 KBDB 基本盤 /entries，解鎖 mira _kbdb_client.py 主線遷移。
  租戶隔離同 9.5：寫入注入 owner_id、list 強制本租戶過濾、PATCH 剝 owner_id。
  刻意不開 DELETE（基本盤 delete 無 owner 檢查 → 跨租戶刪除風險）。
- 9.7 arcrun_report_feedback 從死 route /blocks 改打基本盤 /entries
  （entry_type=agent-feedback）。9.4 漏網的同類修；基本盤無 /blocks → 原本 404 假紅。

順帶（HANDOFF §6 harness 表達優化）：
- 重寫 cli/harness/CLAUDE.block.md 補三盲點（recipe 是公共投稿 / 缺能力補 API 不拼裝 /
  自製零件退場路徑），目標 Haiku 級 CC 讀懂。
- README 零件 vs recipe 段對齊同三點。

cypher + mcp tsc exit 0。端到端 smoke test 隨後。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-15 13:06:58 +08:00
uncle6me-web 8f4c5dbe59 chore(release): cli 1.3.11 版本檔同步（含 MULTI_TENANT 注入修法） 
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-14 22:46:49 +08:00
uncle6me-web 642b61dc9f fix(cli): deploy 注入 MULTI_TENANT=false 到 self-hosted worker（修 MCP 401 注入缺口） 
根因（非 code bug）：partner-auth.ts MULTI_TENANT 分支邏輯對，但部署沒注入
→ worker c.env.MULTI_TENANT===undefined → 走 partner-key → self-hosted 401。
mcp/wrangler.toml 的 MULTI_TENANT 原是註解掉的，injectWranglerConfig 注了
KV/WORKER_SUBDOMAIN/D1 卻漏 MULTI_TENANT。只取消註解不夠（只修手動 fork，
沒修 acr update 自動部署這條 mira 走的路）。

修法（方案①，注 vars 非 secret，self-hosted 零填寫）：
- deploy.ts：DeployContext 加 selfHosted；新增 injectMultiTenant（active/註解/無行三態
  → 加進 [vars]）；injectWranglerConfig 在 selfHosted 時呼叫。
- init.ts：deployCtx selfHosted:true（本就是 --self-hosted 分支）。
- update.ts：ctx selfHosted = mode==='self-hosted' || multi_tenant===false（mira 走這條）。
- mcp/wrangler.toml：# [vars] 改 active [vars]（官方不含 MULTI_TENANT=多租戶；
  注入加行在 [vars] 下，結構正確）。

本地驗注入（真實 export 函式 dry-run）：mcp/cypher 注入後各 1 行 active
MULTI_TENANT="false" 在 active [vars] 下 → PASS。cli tsc exit 0。
端到端交棒 mira：leo21c 重跑 acr update → curl Bearer leo /mcp 應 200。
SDD: mcp-account-source.md §5.5.1。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-14 22:45:48 +08:00
uncle6me-web b932d96a88 chore(release): cli 1.3.10 版本檔同步（deploy 腳本自動 bump） 
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-14 22:18:39 +08:00
uncle6me-web a410af0b6c fix(cypher): KBDB proxy 指向現役 arcrun-kbdb（舊 fallback kbdb.finally.click 已死） 
煙霧測試發現 proxy fallback 寫死舊的 kbdb.finally.click（inkstone 遺留、
回 Missing token），非現役 KBDB。改：
- kbdb-proxy.ts fallback → arcrun-kbdb.uncle6-me.workers.dev（現役、無 auth）
- cypher wrangler.toml [vars] KBDB_BASE_URL 明設現役 URL（self-host fork 覆蓋自己的）

現役 arcrun-kbdb 無 auth middleware，不需 KBDB_INTERNAL_TOKEN。
cli 版本檔 1.3.8→1.3.9（deploy 腳本自動 bump，含 acr kbdb 命令）。

cypher tsc exit 0。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-14 22:16:18 +08:00
uncle6me-web 886a8e31d0 feat(kbdb,mcp): KBDB 資料層薄殼 + self-hosted MCP 認證 + cypher KBDB proxy 
三件一條鏈（HANDOFF §2/§3b，kbdb-base Phase 9）：

A. KBDB MCP 薄殼（9.1）：mcp/src/tools/kbdb_data.ts 6 工具
   template/record/query/search，調基本盤 API。鐵律：不給建表/SQL，只 template+slot。

B. MCP self-hosted 認證 401（mcp-account-source §5.5）：
   - partner-auth.ts：MULTI_TENANT=false 時 Bearer 明碼直接當 org_namespace，
     繞 KBDB partner 驗證（對齊 cypher 的 opaque-key 模型）。官方 SaaS 行為不變、共用同碼。
   - mcp-setup.ts：把 namespace/api_key 寫進 .mcp.json headers.Authorization。
   - 新增 self-hosted vs SaaS 分支單測（9 tests 綠）。

C. cypher KBDB proxy（9.5）+ CLI 薄殼（9.2）：
   - routes/kbdb-proxy.ts 純轉發 /kbdb/* → KBDB 基本盤（KBDB_BASE_URL HTTP fetch，
     不新增 service binding）。讓 CLI（只認證到 cypher）能達獨立 KBDB worker。
   - 租戶隔離：X-Arcrun-API-Key 自動當 owner_id 注入 records/entries（強制覆寫防跨租戶）；
     templates 全域共享（虛擬表定義是 schema 非資料）。
   - cli/src/commands/kbdb.ts：acr kbdb template/record/query/search，與 MCP kbdb_* 同能力。
   - kbdb base：entries 加 page_name 過濾（9.3）。

cypher + cli + mcp tsc exit 0。未驗收：端到端需 deploy + KBDB_BASE_URL 可達後實測。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-14 22:12:32 +08:00
uncle6me-web e5b1ce5420 chore(release): cli 1.3.8 版本檔同步 2026-06-13 14:55:08 +08:00
uncle6me-web b778086f4a perf(self-hosted): acr update 共享一次 install 取代 23 個 worker 各裝 324MB 
壓測 2026-06-12 真因：每個 worker 各 pnpm install ~324MB node_modules（23× 重複，
全是 hono+wrangler）→ 好幾分鐘。改成 tarball root 裝一次（hono+wrangler+tier2 額外
zod/mcp-sdk/yaml），各 worker 靠 node 往上 resolve（dry-run 驗證 tier1+tier2 都 bundle 成功）。
207MB×1 取代 324MB×23。疊加 manifest 跳過 → 第二次 update 近乎瞬間。
共享失敗自動退回各 worker 自裝（不破壞既有路徑）。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-13 14:45:30 +08:00
uncle6me-web f336fb2fca chore(release): cli 1.3.7 版本檔同步 2026-06-13 13:40:34 +08:00