Leo/Arcrun
1
0
Fork 0
Code Issues 49 Pull Requests 5 Actions Packages Projects Releases Wiki Activity
349 Commits 27 Branches 0 Tags
fix/error-message-truth-92
Commit Graph

35 Commits

Author SHA1 Message Date
uncle6me-web 8e9bd09072 fix(engine): 回應太大就說「回應太大」——不再冒充「請求失敗」（Arcrun#92） 
真因：零件（main.go）給 host function 的接收緩衝區是固定大小（http_request 64KB、
claude_api 1MB）。回應超過這個大小時，wasi-shim 的 writeOut 照寫不誤：

    new Uint8Array(buf, outPtr, data.length).set(data)

data 比零件的 outBuf 大 → 覆寫零件堆積體，零件接著 outBuf[:outLen] 切片 panic；
或 writeOut 撞 memory 邊界丟例外 → 回 1 → 零件印一句 "HTTP request failed"。
使用者照那句去查連線／URL／防火牆，方向全錯。

修法（容量握手，不改 host function 簽名、向後相容）：
- 零件呼叫前把 outBuf 長度預先寫進 *outLenPtr（宣告容量）
- host 在寫回前讀這個值當上限；塞不下就**不寫**（不再覆寫零件記憶體），回新的
  HOST_TOO_LARGE=3
- http_request host fn 收到 3 → 改寫一段講真話的 error envelope（實際大小＋上限＋
  「不是連線失敗」＋分頁/篩選的具體做法＋機器可讀 code/actual_bytes/limit_bytes），
  沿用既有 parsed["error"] 判定鏈原樣送到使用者面前
- 舊零件沒宣告容量（讀到 0）→ 維持舊行為。不可硬套 64KB 預設：各零件緩衝區大小不同，
  硬套會把原本正常的大回應誤判成「太大」，那只是換一種說謊

同一條路徑上另一個「訊息與真因脫節」一併修：component-loader 的 makeHttpRunner
`try res.json() catch res.text()`，在零件回非 JSON 時 body 已被消費 → 丟
"Body has already been used"，與真因無關（同檔 readBodyOnce 的註解早就寫明這個坑）。
改成只讀一次。

驗證狀態（誠實標示，mindset §7）：
- 通：5 顆零件 tinygo build 全過，wasm 已重編進 .component-builds/
  （claude_api 依 .gitignore 慣例不入庫，由部署端重編）
- 未跑：runtime 驗證。本 session 的權限層擋掉 node/vitest/wasmtime，
  before/after 實測輸出待人跑 scripts/repro-oversize-response.mjs
- 未做：.worker-builds/ 重編（需 node scripts/build-worker-artifacts.mjs），
  否則修法不會進 self-hosted 安裝路徑（Arcrun#93 同款陷阱）

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-12 16:49:22 +08:00
uncle6me-web f1370e2275 fix(engine): 等待搬回引擎——WASI 沙箱裡沒有「不花 CPU 地等」這種東西（Arcrun#101） 
leo 在 youlin stage 實測（只有 input >> wait 兩個節點）：
  ms=3000 → 38.9s 後 503(1102) / ms=20000 → 34.0s / ms=30000 → 34.9s / 寫死 3000 → 34.8s
四個值同一種死法、與 ms 無關 ⇒ 病不是「等待很貴」，是「等待從來沒成功過」。

修法：wait 移進 BUILTIN_COMPONENTS，由引擎 await 一個 timer。
只花 wall-clock、不記 CPU ⇒ 等 30 秒與等 3 秒同價（皆 ≈0）。
I/O 契約沿用 component.contract.yaml，既有 workflow 的 wait 節點定義不必改。

🔴 誠實標明：原本註解斷言「Workers 時鐘在同步執行期間凍結，所以自旋永不結束」。
寫測試去證，反而被打臉——workerd 裡自旋 2553 圈後 Date.now() 就前進了。
那條假斷言已刪除（不是改鬆），完整機制降級為推測。修法不依賴它：
純 WASI 沙箱本來就沒有睡覺這個手段，會等的只有宿主。

實測：
  npx vitest run tests/wait-builtin.test.ts  → 12 passed (12)
  npx vitest run（全套）                      → 386 passed / 14 failed
                                              （14 = 動工前的既有紅燈數，未新增）

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-12 15:15:08 +08:00
Leo 5b983c47b8 Merge branch 'main' into fix/merge-main-into-batch-t173 
# Conflicts:
#	console-ui/public/portal/index.html
#	cypher-executor/src/routes/health.ts
#	cypher-executor/src/routes/portal.ts
#	registry/components/kbdb_upsert_block/component.contract.yaml
#	registry/examples/km-wiki-ingest/workflow.yaml
 2026-08-02 23:43:16 +08:00
uncle6me-web c735b911a0 🔴 修教材反向教壞：skill §7 自打臉＋補「分支怎麼算成功」＋刪 publish 死代碼 
端到端 haiku 考 0/3、1/3，**斷點在教材不在引擎**（另一 agent 取證，別重查）：
探針零 code 實測 n=10→TRUE、n=1→FALSE 兩次 success；**考生的作品其實會動**
（amount=5000→true、amount=100→false 條件求值全對），但它以為跑不通而放棄改寫 code；
考生第二次自己指認「MCP 說明聲稱不支援 ON_TRUE/ON_FALSE，與實際系統行為不符」。

① skill `write_intent_workflow` **同一份前後打架**（我 08-01 只改了 §2 沒掃全篇）：
   §2.1 教用 ON_TRUE，§7 第 1 條卻把 ON_TRUE 列為「不存在的邊」⇒ 教材自我否定。
   改：§7 只留 ON_FAILURE（真的沒有），並明寫「ON_TRUE/ON_FALSE/ON_BRANCH 是存在的，
   見 §2.1，本行舊世代已更正」。全篇 grep 過確認無其他矛盾。

② **補 §2.2「怎麼確認分支真的走對」**——這是「看到對的結果卻以為失敗」的直接解：
   看 verdict，且**走 true 路時 false 路節點不出現＝正確行為不是失敗**；
   附 08-01 實撞案例，明講「只有一條路有輸出」不該判定壞掉。
   MCP instructions 同步加這段（比 skill 更前置，AI 一連上就讀到）。

③ #23 殘留清除（leo 08-01：「已經沒有 publish 了，零件等級一律走 PR，這條路封了」）：
   `git rm mcp/src/tools/arcrun_publish_component.ts`＋拔掉 registry.ts 的 import
   （註冊呼叫本來就已註解掉＝純死代碼配活 import）。刪前 grep 全 repo 呼叫方：
   除本檔與 registry.ts 外，其餘命中全是 md/SDD 的歷史記載（不需動）。tsc 綠。
   替代路徑＝`Leo/arcrun-components` fork→PR→人審，已寫進 registry.ts 註解。

SDD: workflow-discovery 3.11｜CP: arcrun-usable 步驟 5
 2026-07-31 18:37:48 +08:00
uncle6me-web eefbed98b6 合流 batch：步驟 3/4/5/6 併成一版出貨（同一顆 cypher worker，bundle 是 worker 粒度） 
鐵律（08-01 血淚）：CP 可分步驗收，但 bundle 是 worker 粒度——凡改同一顆 worker 的多步，
出貨前必先合流成一版再重生 bundle，否則 stage 只拿到一步（三條分支各自建 bundle 的坑）。

base=feat/step3-missing-guidance（最前緣，已含 step4+step6＋t158-t162 prod 修）
merge=feat/step5-conditional-edges（引擎條件邊＋recipe 三層＋教材世代修）
 2026-07-31 16:56:09 +08:00
uncle6me-web a9a47b7c37 🔴 步驟5 補斷點：教材說「引擎不支援條件分支」＋意圖語法收不到分支標籤 
備考 haiku 真考時自查發現的兩個斷點——**若不補，考試必掛，且掛的是我自己的教材**。
形狀＝步驟1 那個「世代脫節」的翻版：能力做好了，但教 AI 的地方還停在舊世代。

斷點①：三處教材主動說「沒有條件分支」，還教了正好造成腹語術的替代法
  - mcp/src/mcp-handler.ts:44「**沒有** ON_TRUE／ON_FALSE——引擎目前不支援條件分支」
  - registry/skills/write_intent_workflow.md:39「不要寫 ON_TRUE／ON_FALSE…
    需要判斷時**寫成一個獨立節點**再接 ON_SUCCESS」← 這正是「判斷退回 code」的入口
  - registry/skills/INDEX.md:44「已知的坑：引擎沒有條件分支」
  ⇒ 三處全部更新成現況（三顆零件都輸出 data.branch、引擎依標籤選路、
    查零件回應附 branch_hint 照著接即可），並保留「不要寫 ON_FAILURE」（那個真的沒有）。

斷點②（更隱蔽，靜默失效）：`graph-builder` 只認得 `對每個 X` 的參數化 label，
  `ON_BRANCH(branch_active)` 帶括號會落到 toEdgeType 預設值 **PIPE**
  ⇒ 我在 skill 教的寫法，編圖收不到，而且**不報錯**——AI 以為分支了、實際全走同一條。
  「教了語法但引擎不收」比沒做更糟，故與文件同批補上：比照 FOREACH 抽 iterator 的作法
  抽 branch 標籤（半形/全形括號都收），寫進 edge.branch。

新增 tests/intent-branch-syntax.test.ts（7 項綠）：守「文件教的寫法，編圖真的收得到」
——ON_TRUE/ON_FALSE 不退化成 PIPE、中文「成立時/否則」、ON_BRANCH(標籤) 抽得出 branch、
全形括號、try/catch 標籤；零變化：ON_SUCCESS 仍是 ON_SUCCESS、對每個 X 的 iterator 不受干擾。

全套 234 passed（前 227 +7），失敗數維持既有 9 筆；tsc 綠。

SDD: workflow-discovery 3.11｜CP: arcrun-usable 步驟 5

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-07-31 16:51:19 +08:00
uncle6me-web 832f270f52 Merge branch 'feat/step6-success-rate' into feat/step3-missing-guidance 2026-07-31 14:54:25 +08:00
uncle6me-web ea1c0571c1 步驟6 執行統計回寫：每顆零件跑完回寫 success_rate（task 29，design.md「執行統計設計」） 
- registry 新增 POST /analytics/record：ANALYTICS_KV 計數器（stats:{hash_id}:{version}）
  為唯一真相源，衍生值（success_rate/avg_duration_ms/call_count）回填 comp: 記錄
  ——查詢讀取端讀哪就寫哪，不開第二真相源。KV 無 CAS，誠實標註非原子。
- cypher-executor execution-evaluator 從 stub 改真實作：執行收尾（/cypher/execute
  成功與 ExecutionError 路徑＋webhook 路徑）對 trace 裡每顆 Component 節點
  fire-and-forget 回寫，waitUntil 包、不增加執行同步延遲（仿 recordRecipeStats 慣例）。
  成敗判定＝trace error 或 output.success===false（makeHttpRunner 非 2xx 不 throw）。
- registry 位置沿 search-nodes 慣例：REGISTRY_BASE_URL 覆蓋，未設走 wasmWorkerUrl。
- 新增單測 13 個全綠；本地雙 wrangler dev 端到端實測：http_request 跑 5 次
  （3 成功＋2 失敗）→ success_rate 1→0.6、call_count 0→5，/cypher/search 同步可見。

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-07-31 13:45:05 +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
uncle6me-web 7e87a3336b 3.8 新增 write_recipe skill——recipe 指路終於有目的地 
📋 SDD：workflow-discovery task 3.8（3.7 的 suggestion 指 skill write_recipe，
之前是空地——指路會指到不存在的 skill）。

- registry/skills/write_recipe.md：從真 code 反推，不是憑空教學——
  schema＝routes/recipes.ts RecipeDefinition（canonical_id/endpoint/method/auth_service…）；
  真範例＝api-recipe-seeds.ts 的 telegram_send（URL path 注入）＋gmail_send（service account）；
  auth recipe 必填欄位（required_secrets 的 help_url 必填）照 POST /auth-recipes 驗證邏輯；
  常犯錯收錄實錄（sheets append PUT→POST、telegram auth recipe 漏種、金鑰只准名字 D36）
- INDEX.md 補 write_recipe 入口；「/cypher/search 假 found」坑改標已修（2026-07-31）
- write_intent_workflow.md §6 status 表改 not_found 契約＋suggestion/similar_* 欄說明

安裝器 seed：registry/skills/*.md 由 sync-registry-to-kbdb.py 自動收，新檔即納入。

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-07-31 11:56:30 +08:00
uncle6me-web 1794072179 3.6/3.7 查詢誠實化：兩庫都查、缺件回 not_found＋分型指路 suggestion 
📋 SDD：workflow-discovery task 3.6/3.7（leo 07-31 步驟 3 考題）
契約以頂層 arcrun-usable/verify.sh 01＋03 組為準。

- 3.6 recipe 納入 /cypher/search：零件 registry 落空後查 RECIPES KV
  （resolveRecipe，執行鏈同一套解析）；recipe found 附 source/description/endpoint
- 3.7 缺件分型指路：status 契約定 not_found（verify grep），suggestion 欄——
  名字含服務詞（google/telegram/…）＝外部 API 樣貌 → 指 skill write_recipe；
  含計算詞（encrypt/hash/…）＝計算原語樣貌 → 指 skill add_new_wasm_component 投稿 PR；
  判不出型誠實說判不出、兩條路都給。規則簡單可解釋（不接 LLM），判準在 code 註解
- 相近候選：not_found 附 similar_components/similar_recipes——全名搜不中就斷詞
  （ASCII 詞＋中日韓 2-gram）打 registry /components/search，
  「判斷有沒有新資料」媒合到 if_control（leo：AI 不用知道零件存在）
- 修頭節點假 found：resolveNodeRole 把無入邊頭節點判 Input，searchNodes 對 Input
  無條件 found ⇒ 「aes_encrypt >> … >> code」的頭被掩蓋。改為只有字面
  input/trigger/…/output 名才短路（isVirtualIoName），真名字照查兩庫
- registry 查詢層補 input_schema/output_schema 透傳：KV 一直有存
  （indexOnlyComponent），toComponentRecord 丟掉 ⇒ /cypher/search 給不出
  「怎麼填 payload」。順手補 REGISTRY_BASE_URL 可選覆蓋（比照 KBDB_GRAPH_URL 慣例，
  本地 dev／self-hosted registry 掛別處時用）

驗：cypher-executor＋registry tsc 全綠；vitest 9 failed/179 passed＝與 5cadc60
基線完全相同（既有債非本次造成）；本地 wrangler dev（cypher 指本地 registry，
KV 用 index-only 種入 20 份 repo 合約）跑頂層 verify.sh 01＋03 組 9/9 全綠，
含 telegram_send 種入後 recipe found 路徑實測。部署到實例後需對真環境重驗。

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-07-31 11:56:15 +08:00
Leo cda1c7b261 instructions 補「你配備了 Arcrun、別上網搜」＋新增 skills/INDEX（LLM wiki 式導航） 
leo 兩個洞察：
① 「整個 arcrun instruction 很像 LLM wiki…它會拿到一個 index 把所有文件說明都塞給它，
   它不會就可以查，範本全部寫在裡面」
   ⇒ 對照 wiki 的 push/pull 分法：我原本只做了 push（instructions 開場），
     漏了 pull（INDEX 導航）。補 registry/skills/INDEX.md：
     什麼症狀查哪支 skill／查現成零件recipe workflow 的九支工具／四個已知的坑／腹語術紅線
② 「它不去查就不知道…如果它去上網搜因為它不知道自己有配備呢？」
   ⇒ 實測確認 instructions 是 **push**（本 session system prompt 內就有藏書地圖那段）
     ⇒ AI 不會去上網搜，但原本的 instructions 沒說「你配備了什麼」
     ⇒ 開場補：Arcrun 是什麼／你現在就有完整能力／不要上網搜（網路上沒有）

驗：tsc 零錯誤。⚠️ 未部署——實測總管 token 只有 account(read)，無法部署任何 CF worker。
 2026-07-30 22:38:37 +08:00
Leo fac7d6c9bb AI 一連上 MCP 就知道從哪開始（leo 追問揪出的最後一哩） 
leo：「arcrun_get_skill 放在 MCP 裡，現在人類說『幫我用 arcrun 寫 xxx』，
Haiku 會說『arcrun 是什麼？我看看』然後發現有個 arcrun mcp 就去執行？
如果不會，要寫什麼在外面讓它一聽到就知道要用這些資源？」

實測答案：**不會**。
① 總管寫的指引沒有任何入口指向它（真實 AI 找不到）
② MCP 五個 skill 沒有「怎麼寫意圖工作流」這支
③ AI 只看到 41 個工具名 → 自己猜 → 很可能直接 push_workflow 瞎編，
   或去讀 registry/examples 那 8/13 引用不存在零件的壞範例

兩件修法：
1. registry/skills/write_intent_workflow.md — 把指引變成 AI 拿得到的 skill
   （範本全取自實跑 verdict=success 的四支 workflow；含「查詢現在回假 found」的已知限制警告）
2. mcp-handler.ts instructions 開場指路 — instructions 是唯一「AI 一連上就必看」的欄位
   ⇒ 開場就寫明五步順序（先讀 write_intent_workflow → whoami → 查零件 → list_skills → 缺件怎麼補）
   ＋邊只有兩種、第一個節點是 input、不要因查不到就改寫 code
   ⚠️ 靜態常數：KBDB 掛了也必出現（守「不擋連線」鐵律）

驗：tsc 零錯誤。⏳ 待部署後由 leo 真的問 haiku「幫我用 arcrun 做 X」驗證它會不會自己讀 skill。
 2026-07-30 22:29:28 +08:00
Leo 156cdcbe7b chore: 刪掉兩個死零件與其壞範例（leo：這裏的每個不要的零件還存在啊） 
📋 SDD：workflow-discovery（active）／對應 CP arcrun-usable 步驟 5「死代碼清除」

刪除（git rm 保留歷史）：
- registry/components/km_writer      + .component-builds/km_writer
- registry/components/kbdb_upsert_block + .component-builds/kbdb_upsert_block
- registry/examples/km-wiki-ingest（唯一引用 kbdb_upsert_block 的範例，Mira 時代同源產物）

為什麼刪（Arcrun 自己的 06-mindset.md §1 早已載明）：
「mira 的 claude_api / km_writer 就是這樣被錯做成零件的（其實是自用服務膠水）」
＋ kbdb_upsert_block 是「一個 CRUD 操作一個零件」（leo：總不能每個都建一個零件）
＋ 兩者綁的 Mira 已於 2026-06-29 蒸發＝死零件。

刪前實測引用數：workflows.json 0／cypher src 0／examples 僅 km-wiki-ingest。
零件數 22 → 20。

✅ 投影模型驗證成功：build-bundles.mjs 掃 .component-builds/ 目錄（readdirSync），
重跑後 manifest 自動 25 顆 → 23 顆，兩顆消失，**不需手動改 manifest**。
⇒ 證明 manifest 這層本來就是投影（leo 的設計），只有 registry KV 那層是獨立登記簿（待改）。

驗：vitest 9 failed/179 passed＝與刪除前相同（既有債）。
 2026-07-30 21:30:26 +08:00
Leo cdca296044 D36：修正四個零件契約的假資訊敘述（現行沒有發 API key 的機制） 
leo 07-29 指正：「現在沒有 partner key，改用 namespace，現在沒有發 API key 的機制」。
這些契約寫著 'KBDB partner key（ak_xxx）'／'租戶識別（ak_ 前綴）'＝假資訊源——
總管就是被它騙的（先把範例改成不存在的 {{credential.kbdb_partner_key}}），
不修的話下一個 AI 會再挖同一個坑。

改：kbdb_upsert_block／auth_oauth2／auth_service_account／auth_static_key 的
api_key description，改述為「租戶識別＝Arcrun namespace」＋註明 examples 裡的
ak_test/ak_nonexistent 是測試假值不代表真實格式。

只動 description，不動 schema／欄位名／gherkin_tests
（api_key 欄位名保留——改名會破壞現有 workflow）。
驗：四檔 YAML 可解析、required 不變、欄位清單不變、gherkin_tests 全保留、
ak_test 等測試值原封不動。

人閘：leo 07-29 跑 scripts/component-arm.sh 解保險授權。
 2026-07-29 19:38:14 +08:00
Leo e8bd518efa D36 第0步：範例 workflow 金鑰統一走 credential（止血——範例是用戶照抄的樣板） 
改前四種寫法並存、沒一個是 credential，而執行端只認 {{credential.X}}
（graph-executor.ts:247→resolveCredentialRefs）⇒ 用戶照抄必踩坑：
  {{api_key}} 13／{{gitea_token}} 2／{{secret.GITHUB_BOT_TOKEN}} 2／{{kbdb_api_key}} 1

改後（19 處統一）：
  {{credential.arcrun_namespace}} 15／{{credential.gitea_token}} 2／{{credential.github_bot_token}} 2

⚠️ 中途修正一次錯誤命名：我先改成 kbdb_partner_key（照零件契約舊敘述 ak_xxx），
leo 當場指正「現在沒有 partner key，改用 namespace，沒有發 API key 的機制」——
實際機制確為 X-Arcrun-API-Key: <namespace>（實例上活的 workflow 為證）。

不動：{{secret.LEO_TELEGRAM_CHAT_ID}} 3 處——chat_id 是聊天室 ID 不是金鑰，
無腦套規則會引進「找不到 credential」的錯誤。

驗：違規寫法歸零／12 個範例 YAML 全可解析。
殘：kbdb_upsert_block 契約仍寫『KBDB partner key（ak_xxx）』＝假資訊源（我就是被它騙的），
修它被 component-guard 擋（正確），需 leo 跑 scripts/component-arm.sh。
 2026-07-29 19:33:46 +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
Leo 66d2045f06 Merge branch 'main' into feat/deploy-code-component 2026-07-07 09:39:20 +00:00
Leo 39d6fdfaff fix(examples): graph_neighbors 去寫死官方 KBDB URL（審查 🔴）＋敏感輸入註記 
審查發現：workflow.yaml 寫死 kbdb.finally.click ＝ KBDB_BASE_URL fallback 同家族坑
（self-hosted 用戶照抄示範，查詢與資料流向直接打進官方庫）。

改法：
- fetch_triplets base URL 參數化為 {{input.kbdb_base}}（每次呼叫帶），yaml 檔頂加醒目
  警示「先改成你自己的 KBDB URL」；grep 證兩檔零 finally.click 殘留。
- 1042 註解保留並補一句：self-hosted 有 global_fetch_strictly_public flag
  （credential-primitives-wasm Phase 7），開了 workers.dev URL 亦可帶。
- description.md 參數表加 kbdb_base（必填）＋觸發範例改自有域名佔位＋補
  「敏感輸入請用 POST /query（GET /q/ 的 query string 會進各層 log）」。

tsc 乾淨、全套 50 passed（1 失敗為 main 既有 executor.test.ts 斷言漂移，無關）。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015d5jDbuqT5Htwv3Q88XXKk
 2026-07-07 09:01:20 +00: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 313aeb13bf feat(cypher-executor): 同步查詢 trigger + graph_neighbors 查詢面 workflow 示範 
Part 1（框架，cypher-executor webhooks-named.ts）：加同步查詢 trigger。
現有 named webhook /trigger 回 {success,data,trace,duration_ms} 信封、只有 POST；
查詢面（console/MCP 打 graph neighbors/traverse）要 GET + 直接拿最終節點輸出當 response。
新端點同步 await 執行 workflow graph → 回 result.data（最終節點輸出）本身當 body（非 202）：
  - GET  /q/:ns/:name                    （namespace 走 path，input 走 query string）
  - GET  /webhooks/named/:name/query     （X-Arcrun-API-Key header，input 走 query string）
  - POST /webhooks/named/:name/query     （header，input 走 body）
  - POST /webhooks/named/:ns/:name/query （namespace 走 path，input 走 body）
認證沿用 X-Arcrun-API-Key。誠實（mindset §7）：節點失敗回 error+trace（500，非假綠）；
paused 工作流無法同步回答 → 409 明講；輸出 5 MiB 硬上限（超過 413）；duration 走 header 不污染 body。

Part 2（A 類 workflow.yaml）：registry/examples/graph-neighbors/。
http_request 打 base custom domain kbdb.finally.click（避 CF 1042）撈 triplet records
→ code 零件記憶體 BFS（對照 kbdb-graph-plugin graph-traverse.ts）→ 同步回鄰居。
把 graph plugin 內建 GET /graph/neighbors 泛化成查詢面 workflow 的示範。

測試：cypher-executor/tests/query-trigger.test.ts（7 測，全綠）——同步回輸出（非 202）、
GET/POST × header/path 四端點、節點失敗回錯+trace、缺 key 401、不存在 404。
用內建 comp_uppercase（純記憶體）證明 Part 1 同步 trigger 機制本身可用。

待驗：graph_neighbors 需 code 零件部署 leo21c 後才能 live 端到端（另線處理）；
triplet template id 上線前對一次（workflow 已參數化未寫死）。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015d5jDbuqT5Htwv3Q88XXKk
 2026-07-07 08:16:17 +00:00
Leo 4439880bbd merge: 機械 wiki ingest workflow（Arcrun#8）——code 節點 card→envelope，Phase B live 驗過 2026-07-06 05:48:10 +00:00
Leo b87c18df60 fix(km-wiki-ingest): code 節點 post 前剝除 envelope 的 _estSubrequests（graph strict schema） 
leo21c 實 ingest 發現：graph /triplets/ingest 為 strict schema，會以 422
unrecognized_keys 拒絕 planEnvelopes 掛在 envelope 上的診斷鍵 _estSubrequests。
修：parse_card 內聯碼在 return 前把每個 envelope 的所有 _-前綴鍵剝除，使
post_one_envelope 的 body_json={{envelope}} 為 ingest-candidate 契約乾淨 payload
（source/extractor/nodes/triplets）。已驗：剝除後 entry/nodes/triplets 與原
planCard 逐欄一致。實 ingest（直接驅動同資料流）已用此剝除成功寫入 15 triplets。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HJiLCRUU2o3aSpPEzVCt2o
 2026-07-06 05:38:10 +00:00
Leo 08a79229a5 fix(code): Workers 實部署修正 —— wasmfile+Module 載入 + tick-budget timeout（CF 實測） 
leo21c 實部署發現兩個 CF 限制並修正：
1. CF 禁 runtime 從 bytes 編譯 wasm（WebAssembly.instantiate(bytes) 被 embedder 擋）
   → singlefile(base64) 內嵌不可用。改 wasmfile variant + `import wasm from './vendor/quickjs.wasm'`
   （wrangler CompiledWasm rule 綁成預編 WebAssembly.Module），newVariant({wasmModule}) 注入。
   sandbox 改 variant 注入制（setVariant）：Worker 注 wrangler Module、Node 由 bytes 建 Module，
   同一 production 路徑受測。vendor/quickjs.wasm 由 postinstall 自 node_modules 複製（gitignored）。
2. CF 凍結同步執行期 Date.now → wall-clock deadline 對純同步迴圈失效（撞 CF CPU 回 1102）。
   改指令計數 interrupt（max_ticks，CF-safe），wall-clock 留 Node 保護。校準：cadence≈5000
   指令/tick、真實 card 解析≈4 ticks、CF 門檻≈1000+ ticks → 預設 max_ticks=500。
   有 body 的迴圈（含 100M 迴圈）皆乾淨回 TimeoutError；空體 while(true){} 仍由 CF CPU guard 容納。

Worker live: arcrun-code.leo21c.workers.dev（cypher-executor 以此 workers.dev 慣例位址呼叫）。
Node 單測 12/12 綠（wasmfile variant + 注入 Module，同 production 路徑）。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HJiLCRUU2o3aSpPEzVCt2o
 2026-07-06 05:15:50 +00:00
Leo 1a7b4639c3 docs(code): DESIGN.md 更新為「裁定 A、Workers 就緒」的最終狀態 
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HJiLCRUU2o3aSpPEzVCt2o
 2026-07-06 04:51:39 +00:00
Leo d93dc4e350 feat(km-wiki-ingest): parse_card 改用通用 code 零件；刪 domain 零件 km_wiki_card_parse 
Arcrun#10 裁定：一次性解析走通用逃生口，不再鑄 domain 零件。

- workflow.yaml：parse_card 由 component:km_wiki_card_parse -> component:code，
  config.code 內聯 card-to-envelope 的 planCard 邏輯（去 import/export、raw NUL
  分隔符改 u0000 escape、改用 code 沙箱注入的 sha256）；下游 refs 改 parse_card.data.*；
  加 limits(timeout_ms/max_output_bytes)。已端到端驗證（YAML 解析->JS eval）與原
  planCard 輸出逐欄全等（含 content_hash）。
- 刪 registry/examples/km-wiki-ingest/component-contract.yaml（km_wiki_card_parse 契約）。
- lib/card-to-envelope.mjs：header 改述為「code 節點內聯 JS 的權威來源 + 參考實作」，
  邏輯不變（續為 inline JS 之單一真相源）。
- lib/dry-run.mjs / description.md：框架改述為 code-節點形態；部署清單更新為「部署通用
  code 零件」。dry-run-evidence.json（3 entries/15 triplets/16 nodes）不變——解析輸出等價。

不部署、不寫 live。留分支可部署狀態。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HJiLCRUU2o3aSpPEzVCt2o
 2026-07-06 04:50:08 +00:00
Leo efa0b0578c feat(code): Workers 就緒化（裁定 A）—— singlefile variant + 純 JS SHA-256 prelude 
- 沙箱改用 quickjs-emscripten singlefile variant（wasm 內嵌 base64、同步載入），
  CF Workers 相容；sandbox.mjs 成 Node/Worker 共用 runtime-agnostic 核心。
- sha256 curated builtin 改「純 JS SHA-256 prelude 字串注入」，去掉 node:crypto /
  async Web Crypto host-call，Node/Worker 皆決定性（card content_hash 逐字等價）。
- index.ts 成可部署 Worker host（Hono，POST /→runCode），自足不走 TinyGo 模板流程。
- 補 wrangler.toml（arcrun-code / code.arcrun.dev）、tsconfig、DEPLOY.md。
- contract stability 修為 floating（過 registry zod schema 驗證）。
- 單測 12/12 全綠（含 card→envelope 與原模組 planCard 逐欄全等）。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HJiLCRUU2o3aSpPEzVCt2o
 2026-07-06 04:39:28 +00:00
Leo 60f5f10ba5 feat(code): 新增通用 code 零件（sandbox inline JS）—— Arcrun#10 設計+PoC 
n8n Code node 式逃生口：config 帶 inline JS、stdin 帶 input JSON、
stdout 回 {success,data}|{success:false,error,error_type}。

沙箱＝QuickJS-wasm：user JS 跑在 QuickJS context，global 只有純 ECMAScript
內建 + 唯一 curated builtin sha256（純函式）；碰不到網路/檔案/env/secret/
Worker 物件圖。資源上限：timeout(interrupt)/memory/stack/output/code size。

本輪＝設計+PoC，未部署 leo21c。sandbox.mjs + test/ 為 Node/vitest 可跑實作
（12 測試全綠，含 card→envelope 與原模組 planCard 逐欄全等）。index.ts 為
Worker host 骨架、DESIGN.md 記錄機制/安全性質/生產路徑/設計岔路(A/B)。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HJiLCRUU2o3aSpPEzVCt2o
 2026-07-06 04:27:15 +00:00
Arcrun CC cc494a250e feat(ingest): 機械式 wiki 卡片→KBDB ingest（Arcrun#8 Phase A，dry-run 驗證） 
新 ingest 模型（無 LLM，取代舊 raw→Haiku 路）：
- 來源 = system-dev/wiki/cards/**/*.md（精耕卡）+ ## 實體/## 關聯 typed-edge + [[wikilink]]
- 卡片→base entry（metadata.embed=true）；typed-edge/wikilink→graph triplet
- 純機械決定性，零 token

形式 = Arcrun workflow（cron drain + Gitea webhook delta）+ 新自訂零件 km_wiki_card_parse

不撞頂設計：一卡一 tick + 超大卡以 source_uri anchor 自動分段；
graph fan-out 精確 = 7+4N+M+D，dry-run 對 notes 三卡上限 33 subrequest（<50）。

Phase A：不部署、不寫 live。含純核心 + dry-run 證據（3 entries/15 triplets/16 nodes）。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HJiLCRUU2o3aSpPEzVCt2o
 2026-07-06 03:52:50 +00:00
uncle6me-web ed2e42e007 feat(credentials): T6 讀取/注入接新家 + T7 雙讀 fallback (credential-store-migration 方案 A) 
D19「擁有目錄不擁有內容物」遷移的讀取斷點。密文住 cypher per-script secrets、
D1 只存 secret_ref、auth worker 讀不到 cypher 的 secrets → cypher 先取值塞 payload。

WASM 端(T7 fallback 骨架，零行為改變可獨立部署驗):
- auth_static_key/main.go + auth_service_account/main.go：Input 加 resolved_secrets，
  解密處改「有 resolved 就用、沒有才 fallback 舊 kv_get+crypto_decrypt」。default 等於舊碼。
- tinygo build 兩支通過，copy 到 .component-builds/*/component.wasm。

TS 端(T6 主路徑):
- auth-dispatcher.ts 新增 resolveSecretsFromNewHome：查 D1 拿 secret_ref →
  secret_get(env[ref], T4) 取明文 → 組 map(取不到的 name 缺席，不放空字串) →
  更新 last_used_at。tryAuthDispatch + resolveCredentialRefs 都塞 resolved_secrets。
- rule 02 §2.2 對齊：只查 ref/取值/塞字串，不解密不展開模板不組 JWT。

驗證：cypher-executor + cli tsc exit 0；vitest 41/42(新增 auth-dispatcher.test.ts 6 案例全過，
剩 1 pre-existing 無關失敗)。待 leo21c 部署驗 WASM 端到端(不由本任務部署，acr update
硬綁 GitHub codeload=mistakes #23)。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-07-05 13:44:26 +08:00
uncle6me-web a234201235 修正示例 yaml：telegram 改用 recipe canonical_id；gmail 讀取留 TODO（issue #13 步驟1） 
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-28 15:45:50 +08:00
uncle6me-web 6e92ca0372 fix(self-hosted): acr update 10/23 部署失敗根因——pnpm 目錄補 commit pnpm-workspace.yaml（ERR_PNPM_IGNORED_BUILDS）+ CLI 失敗帶 stderr 尾段 
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-12 23:25:46 +08:00
uncle6me-web da84425d25 feat(credential-injection): {{credential.X}} 用戶面語法（credential-primitives §8） 
壓測 401 根因：{{credential.X}} 系統沒實裝，三條 template 展開路徑都不認
credential. namespace → 注入空值 → 目標 API 401（test_arcrun/5 Haiku 實證）。

修法（design §8，richblack 確認方向 B「讓 {{credential.X}} 真的能用」）：
- auth_static_key 加 resolve_credentials action：給 names → WASM 內 kv_get +
  crypto_decrypt → 回明文 map（不查 recipe、缺則誠實報錯）
- auth-dispatcher 加 resolveCredentialRefs：遞迴偵測 {{credential.X}} → 交 WASM
  解密 → 回填（無 ref 則零開銷不打 WASM）
- graph-executor 在 node.data interpolate 後呼叫，不碰 ENCRYPTION_KEY（rule 02 §2.2）

解密全程在 WASM，TS 只偵測+回填。tinygo build OK + tsc 0 + §2.2 自檢綠。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-10 13:55:31 +08:00
uncle6me-web 465c505000 fix(execution-truth): 修系統對 401 假綠根因 + acr run self-hosted + D1-in-update 
Haiku 自主壓測（test_arcrun/5）暴露的真 bug，逐一修復：

1. 假綠根因：http_request host function 丟掉 HTTP status code（main.go:112 架構債）
   → 非 2xx（如 Notion 401）被判 success → 引擎自己對失敗報成功。
   修：host fn 非 2xx 回 {error,status,body} envelope，既有判定鏈正確識別。
   http_request/claude_api/kbdb_upsert_block/km_writer 已修（4 worker deploy）；
   auth_service_account 自有 OAuth 判定不套。

2. acr run self-hosted：原一律走 /webhooks/<name>（需先 push）→ 沒 push 回 404 純文字
   → res.json() 爆假錯誤。修：本機有 YAML 走玩法一 /cypher/execute 直接執行（三模式一致）
   + res.ok 擋非 2xx + findWorkflowYaml 容忍 .yaml 副檔名。

3. D1-in-update：D1 只在 init 建一次，update 漏建 → token 補權限後無冪等補建路徑。
   修：update 也 ensureD1Database（已驗證 D1 建起 count:1）。

4. CF token 教學漏 D1：llms.txt/.env.example 加「Account/D1/Edit」必勾 + init/preflight
   訊息指明 token 缺 D1 權限的修法。

CLI 1.3.4 publish。Haiku 壓測結論：onboarding 治好（裝+init 沒跳過、建 recipe 不建零件），
但仍會假綠（curl 繞過/D1 沒建謊報）→ 印證執行真相要系統能驗、不信 AI 自報。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-09 22:12:09 +08:00
uncle6me-web 922a57fe34 arcrun — AI workflow execution engine (clean history) 
Self-hosted 開源：WASM 零件 + recipe + cypher-executor，跑在你自己的 Cloudflare。

此為重建的乾淨歷史起點（移除曾誤 commit 的 GCP SA 金鑰，舊歷史保留在
richblack/arcrun 與本地 backup 分支）。含：
- acr init --self-hosted installer（建 KV/R2 + codeload 拉預編譯 wasm + wrangler deploy + seed recipe）
- recipe push 把關（資料外流提醒 + 打通檢查）
- 19 個正當零件預編譯 wasm（claude_api/km_writer/kbdb_upsert_block 排除：違反 DECISIONS §1）
- CLI / cypher-executor / registry / 完整 SDD

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-03 15:52:38 +08:00