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

5 Commits

Author SHA1 Message Date
uncle6me-web 525faaf5d0 fix(cypher-executor): /cypher/search 不再誤報執行期原生零件 not_found（Arcrun#88） 
病因：/cypher/search 只查 component registry（SUBMISSIONS_KV，經 submitComponent/
index-only 才有記錄）；而 component-loader.ts 能直接解析、從不查 registry 的一整類
零件（trigger_workflow／BUILTIN_COMPONENTS／LOGIC_BINDING_MAP／WASM_HTTP_RUNNER_IDS，
如 if_control／http_request／switch）從未被 submit 過。leo21c 實例實測：
GET /components/catalog 回 404「零件 catalog 不存在」，search 因此對這些零件誠實地
回「兩庫都查過沒有」——但它們其實跑得動（leo 08-11 探測工作流已證）。

修法：從 component-loader.ts 匯出 RUNTIME_NATIVE_COMPONENT_IDS（既有三份執行期
解析白名單的聯集，非新清單），search-nodes.ts 在查 registry 之前先比對，
不受 registry 是否可達／是否已 backfill 影響。真正不存在的零件仍誠實回
not_found／unknown，not_found 的分型建議與相似候選機制不變。

刻意不做：不掃描 registry/components/* 目錄當清單來源——那含已標記待刪的死碼
（km_writer／kbdb_upsert_block），07-30 曾把這類死碼誤灌進 registry；也不投資
SUBMISSIONS_KV 的 backfill 腳本——decisions-summary.md D29 已定調 SUBMISSIONS_KV
併入「KV 退休戰」，不宜再加投資。

測試：cypher-executor/tests/search-nodes-runtime-native.test.ts 7 case 全綠，
複現 registry unreachable／registry 可達但目錄空（leo21c 實例的真實症狀）兩種情境。
全 suite 迴歸：357 pass（較修前 350 pass 多 7 個新測試），既有 14 個失敗與修前
數量、內容完全相同（pre-existing，與本次改動無關）。
 2026-08-11 21:51:21 +08:00
uncle6me-web 5f5c0a89e2 步驟5 缺口②：recipe 補 payload／回應正規化／binding 三層（leo 三層模型的第③層） 
問題：舊 recipe schema 只有 {canonical_id, endpoint, method, auth_service}（body 有但淺）
⇒ ①帶 body 的 API 只能繞過 recipe 把整包寫進 workflow code
  ②回應解析綁死單一供應商（rag_chat 的 finalize 2786 字元全在對付 Gemini 形狀）
  ③Cloudflare binding（env.AI/VECTORIZE/BROWSER/QUEUE）整類被「只認 HTTP+金鑰」的抽象排除
⇒ 換 LLM 供應商＝改 workflow，而非換 recipe，違背「外部 API 只有一條一致的路」。

新增 lib/recipe-payload.ts（純函式，好測）：
- renderBodyTemplate：遞迴插值，單一 {{x}} 保留原型別、混合文字拼字串、
  支援 dot path、取不到保留原樣（不靜默吞掉，看得見才好 debug）。
  語義刻意與 graph-executor 的 interpolateData 一致，不新造第二種插值行為。
- applyResponseMap：text_path 取值／thinking_model 剔除 thought=true 取最後一個非 thought／
  answer_marker 用 lastIndexOf（自檢清單內文也會提到標記）／strip_prefixes 循環剝殼
  （實撞三型「Draft: 【答】」「* 【答】」「Answer: * 【答】」，單趟剝不乾淨）。

RecipeDefinition 加四個**全選填**欄位：body_template／response_map／auth／binding_name。
- component-loader：body_template 優先於 body，兩者皆無才沿用 ctx 當 body（既有行為）
- response_map 有設才附 text 欄，未設原樣回傳 ⇒ 既有 recipe 行為完全不變
- 新增 makeBindingRecipeRunner＋pickRecipeRunner：auth='binding' 走平台 binding（免金鑰、
  開機即可用），其餘一律走既有 HTTP 路徑。binding 缺綁定/無 run() 時回可操作錯誤，不假綠。
  這型不是為 Workers AI 開特例——一次打開 env.AI/VECTORIZE/BROWSER/QUEUE 整排。

payload 用法要「查得到」（同 branch_hint 動機，leo 08-01 的 n8n 式逐顆查）：
buildPayloadHint() 讓 recipe 的查詢回應說得出「payload 怎麼填、回應怎麼取值、
認證誰負責」，wire 進 discover 混搜／legacy 逐顆／target=recipe 三條路徑。
金鑰鐵律 D36：hint 只說「走 auth recipe X，金鑰由系統注入、你不必也不該填」，不吐值。

測試：tests/recipe-payload-response.test.ts 14 項全綠（含三家形狀 Gemini/Claude/Workers AI
用不同 path 都取得出文字＝換源＝換 recipe 的實證；未設 response_map 原樣回傳的相容性）。
全套 209 passed（前 179 +30 新），失敗數維持既有 9 筆未變；tsc --noEmit 綠。

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

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-07-31 16:31:58 +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 06ff0e21ce fix(cypher-executor): component-loader 白名單補 code 零件（#29 發現） 
WASM_HTTP_RUNNER_IDS 漏 'code'，導致 workflow 寫 `component: code` 在解析鏈
step 1-6 全不命中後落到 step 8 直接「找不到零件」——本 PR 的 graph_neighbors
範例正用 code 節點，故歸此分支。

URL 推導：走既有 wasmWorkerUrl 通用推導 arcrun-code.{WORKER_SUBDOMAIN}.workers.dev
（WORKER_SUBDOMAIN 來自 wrangler.toml [vars]，self-hosted 由 deploy 注入自己的
subdomain）——無寫死官方 code.arcrun.dev，self-hosted 天然成立。

測試：tests/component-loader-code.test.ts（2 測）——`code` 解析成 runner 不 throw、
stub fetch 證 runner 打 arcrun-code.{sub}.workers.dev；wasmWorkerUrl 對任意 subdomain
推導正確。tsc 乾淨、全套 50 passed（1 失敗為 main 既有、無關）。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015d5jDbuqT5Htwv3Q88XXKk
 2026-07-07 08:42:51 +00: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