chore: D22 落地——docs/SDD/wiki/CLAUDE.md 進 repo（Gitea private 預設全 push）

頂層 D22 決策（leo 2026-07-03 拍板）：推什麼由開發環境歸屬決定，
Gitea private＝除機敏值/build 產物/.github 外全 push。
解 T1.5 卡點：雲端工人 clone 拿得到 credential-store-migration.md，可就地改寫 SDD。
機敏掃描兩輪通過（新增 189 檔約 2.1MB，node_modules/dist/wasm 照舊排除）。

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

system-dev/docs/3-specs/arcrun/credential-primitives-wasm/credential-store-migration.md

@@ -0,0 +1,184 @@
+# Credential Store 遷移 SDD — KV → D1（目錄）+ Cloudflare Secrets Store（密文）
+
+> 建立：2026-06-29 by arcrun CC｜對應 issue：Arcrun#13（優先序 3）｜決策：leo 2026-06-29 拍板（D19）
+> 範圍宣告：本檔是既有 SDD `credential-primitives-wasm/` 的補充設計（rule 02 §4.3 例外：現有 SDD 目錄內新增單檔）。**不施工，先 SDD，總管審對齊後放行。**
+> 取代關係：本檔的儲存決策**取代** `credential-store-redesign.md` §4.5 的「維持 KV」推薦——leo 看完該推薦後**拍板走 D1+Secrets Store**（D19），故 Phase B 翻回「搬」。redesign.md 的 A（telegram 一致性，已做）/ C（友善前門）/ Q1（acr parts）不受影響。
+> 詞彙：component=TinyGo WASM｜recipe=http_request+固定設定｜workflow=多步 YAML｜auth-recipe=credential 怎麼注入。
+
+---
+
+## 0. leo 的最終決策（D19，一句話）
+
+**「擁有目錄，不擁有內容物」**：arcrun 持有 credential 的**目錄**（看得到存了哪些、最後何時用），但**不持有、也讀不回密文明文**——連 owner 自己的界面都讀不到值。
+
+動機（leo 親述）：用戶 API key 外泄被盜刷的經濟損失 + 商譽風險（「就算不是我們過失也會怪在我們身上」）。**我們不持有明文、不持有金鑰 = 不背這個鍋。**
+
+```
+密文值（token / SA JSON / private key）  →  Cloudflare Secrets Store（CF 託管金鑰，arcrun 拿不到明文）
+credential 目錄（name/service/metadata） →  使用者自己的 D1（不含密文，只含指向 Secrets Store 的 secret_ref）
+舊自管 ENCRYPTION_KEY + 密文存 KV         →  廢掉（回填完成後）；KV 降為暫存/熱讀快取，非真相源
+界面 acr creds list                      →  讀 D1（顯示清單 + last_used），看得到但讀不回值
+```
+
+### n8n credentials UX（D19 定案）
+- 界面顯示**很多 credentials**（名字 / 服務 / metadata / last_used）。
+- **不能 read 既有值、不能 edit 既有值**（連 owner 都不行）。只能：
+  - **整筆 replace**（重貼新值覆蓋舊的）
+  - **delete**
+- read 不回值「不是限制、是設計」——值在 Secrets Store，arcrun 拿不到。
+
+---
+
+## 1. 現狀（已核實 code，2026-06-29）
+
+| 項目 | 現狀 | 檔案 |
+|---|---|---|
+| 密文儲存 | `CREDENTIALS_KV`，key=`{api_key}:cred:{name}`，值=`{encrypted, iv}`（AES-GCM） | `cypher-executor/src/routes/credentials.ts:48` |
+| 加密金鑰 | 自管全域 `ENCRYPTION_KEY`（client 端加密、WASM `crypto_decrypt` 解密） | rule 01 加解密；`wasi-shim.ts` |
+| 寫 | `POST /credentials` { name, encrypted, iv } | `credentials.ts:24-53` |
+| 讀+解密 | `auth_static_key` WASM `kv_get` → `crypto_decrypt` | `registry/components/auth_static_key/main.go:146` |
+| 列表 | `GET /credentials` → `KV.list({prefix})` 列名（不含值） | `credentials.ts:68-78` |
+| D1 | 全 repo 無 credential D1（D1 只有 KBDB graph） | `kbdb/wrangler.toml:10` |
+
+**風險點（leo 要廢的）**：自管單一 `ENCRYPTION_KEY` → 漏一把，全部 credential 裸。
+
+---
+
+## 2. 目標架構（D19）
+
+### 2.1 三方職責
+| 元件 | 存什麼 | 誰拿得到明文 |
+|---|---|---|
+| **Cloudflare Secrets Store** | 密文值本體（token/SA JSON/private key） | **只有 CF runtime 在執行期注入時**。arcrun TS/WASM/owner 界面**都拿不回** |
+| **使用者的 D1**（與 KBDB 共用那顆 `arcrun-kbdb`） | credential **目錄**：`api_key / name / service / sensitivity / created_at / last_used_at / secret_ref`，**無密文** | 全員可讀目錄（非機密），**無人從這拿到值** |
+| **CREDENTIALS_KV** | 過渡期：舊自管密文；遷移後：降為可選熱讀快取或廢用 | （遷移後不再是真相源） |
+
+### 2.2 D1 schema（明確不含密文欄）
+```sql
+-- migrations/0002_credentials.sql（kbdb 同一顆 D1，IF NOT EXISTS 冪等）
+CREATE TABLE IF NOT EXISTS credentials (
+  api_key      TEXT NOT NULL,           -- 租戶
+  name         TEXT NOT NULL,           -- credential 名（= auth-recipe required_secrets[].key，如 telegram_bot_token）
+  service      TEXT,                    -- 對應 service（telegram / notion …），可空
+  sensitivity  TEXT NOT NULL DEFAULT 'standard',  -- 'standard' | 'high'（high = SA JSON/private key）
+  secret_ref   TEXT NOT NULL,           -- 指向 Secrets Store 的 secret 名（不是密文本體）
+  created_at   INTEGER NOT NULL,
+  last_used_at INTEGER,                 -- 執行注入時更新（治理面 last_used 顯示用）
+  PRIMARY KEY (api_key, name)
+);
+CREATE INDEX IF NOT EXISTS idx_cred_apikey ON credentials(api_key);
+```
+> ⚠️ **「name 是名字標籤不是密文」**（leo 防誤解）：`name`/`secret_ref` 都是字串標籤，**密文值永不進 D1**。
+
+### 2.3 Secrets Store 整合（密文存 store、D1 存 ref）
+
+**已核實 CF Secrets Store 形態（wrangler 文件）：**
+- 管理 CLI：`wrangler secrets-store store create/list/delete`、`wrangler secrets-store secret put/get/list/delete <STORE_ID> <name>`。
+- Worker binding（wrangler.jsonc）：
+  ```jsonc
+  "secrets_store_secrets": [
+    { "binding": "CRED_STORE", "store_id": "<STORE_ID>", "secret_name": "<name>" }
+  ]
+  ```
+- 執行期：`await env.CRED_STORE.get()` 回密文值。
+
+**⚠️ 設計約束（必須在施工前對齊，本 SDD 標為待決）**：
+上述 binding 形態要求 `secret_name` **在 wrangler config 部署時靜態宣告**——這不適合「每個用戶任意數量的動態 credential」（不可能為每個 token 改 toml 重部署）。三條候選路徑，**請 leo/總管拍板選一**：
+
+1. **Secrets Store Account REST API（動態 by ref，推薦）**：worker 執行期用 CF API（`accounts/{id}/secrets_store/stores/{store_id}/secrets/{secret_ref}/value`，或官方提供的等價端點）依 `secret_ref` 動態取值。需一把「能讀 Secrets Store 的 CF API token」給 cypher worker（本身是高敏感、走 `wrangler secret put` 注入該 worker，非進 git）。**好處**：完全動態、不用為每 cred 改 toml。**代價**：worker 持有一把能讀 store 的 token（但仍比「自管全域 ENCRYPTION_KEY」好——CF 託管、可輪替、範圍限 store）。
+2. **靜態 binding + 預宣告**：只適合固定少量 credential，動態場景不可行 → 排除。
+3. **過渡折衷**：高敏感（SA JSON/private key）走 Secrets Store；低敏感 token 暫留 KV(AES-GCM) → 但這不滿足 D19「廢自管 ENCRYPTION_KEY、owner 也讀不回」→ 僅作為回填未完成前的中繼。
+
+> **本 SDD 預設走路徑 1（REST by ref）**，並標「待 leo 確認 self-hosted leo21c CF 帳號的 Secrets Store API 路徑與 token 範圍」。施工前需一次 spike 驗證 leo21c 帳號可建 store + worker 可 by-ref 取值。
+
+**self-hosted（leo21c）**：Secrets Store 是 CF 原生能力，leo21c 自己的 CF 帳號支援。`acr init/update` 需新增「ensure Secrets Store store 存在」步驟（類比現有 `ensureD1Database` / `ensureKvNamespace`），把 `store_id` 注入 worker。
+> 註：這與「Anthropic Routine env-var 型 self-hosted 不支援」是**不同層**（那是 Anthropic 雲端；這是 CF 帳號能力）——別混（leo 提醒）。
+
+### 2.4 寫入流程（client 加密 → Secrets Store）
+> ⚠️ 鐵律對齊：現行是 **client 端加密 + 自管 ENCRYPTION_KEY**。走 Secrets Store 後，**密文交給 CF 託管**，arcrun 不再自管金鑰。client 端是否仍加密一層 = 待決（見 §6 開放問題 Q-b）：
+> - 選項甲：client 不再加密，明文值經 TLS 送到 cypher → cypher 用「能寫 store 的 token」寫進 Secrets Store（CF 端加密託管）。**arcrun TS 短暫經手明文**（記憶體中，不落地）。
+> - 選項乙：保留 client 加密當「傳輸期保護」，但這需 arcrun 持有解密金鑰才能寫進 store 明文槽 → 又回到自管金鑰，違 D19。
+> → 傾向**選項甲**（符合「不持有金鑰」），但「TS 短暫經手明文」需 leo 接受（mindset §7 誠實標：不是零接觸，是不落地、不持久、不持金鑰）。
+
+### 2.5 讀取/注入流程（執行期 by ref）
+1. cypher 執行 workflow，遇 recipe `auth_service='telegram'`。
+2. 查 D1 `credentials` where api_key+name=`telegram_bot_token` → 取 `secret_ref` + `sensitivity`。
+3. 用 `secret_ref` 向 Secrets Store 取密文值（路徑 1：REST by ref）。
+4. 依 `auth_recipe:telegram` 的 `inject.path/header` 注入（與現行 auth-dispatcher 同型，只是值來源從「KV 密文+WASM 解密」換成「Secrets Store 取值」）。
+5. 更新 D1 `last_used_at`。
+> ⚠️ rule 02 §2.2/§2.3 對齊：解密/注入仍不在 cypher TS 實作業務邏輯。Secrets Store 取值是「host 能力」（類比 `kv_get`/`crypto_decrypt`），應落在 wasi-shim host function（新增 `secret_get(ref)`）或等價的 host 邊界，**WASM 零件仍是注入邏輯的所在**。施工時須守此界線（見 §5）。
+
+---
+
+## 3. 治理 / UX 端點（n8n 模式）
+
+| 端點 | 行為 | 對齊 D19 |
+|---|---|---|
+| `GET /credentials` | 讀 **D1**，回 `[{name, service, sensitivity, created_at, last_used_at}]`（**不含 secret_ref 對外、不含值**） | 顯示清單 + last_used |
+| `PUT /credentials/:name`（replace） | 整筆覆寫：寫新值進 Secrets Store（同 ref 覆蓋或新 ref）+ 更新 D1 metadata | 只能 replace |
+| `DELETE /credentials/:name` | 刪 D1 row + 刪 Secrets Store secret | 可 delete |
+| ~~`GET /credentials/:name/value`~~ | **不存在 / 移除任何讀回值的路徑** | 讀不回值 = 設計 |
+
+CLI 薄殼（rule 07）：`acr creds list`（讀 D1 顯示）、`acr creds replace <name>`（覆寫）、`acr creds delete <name>`。**移除任何「印出 credential 值」的路徑**。
+
+---
+
+## 4. 遷移：雙讀過渡 + 回填 + 回滾
+
+### 4.1 雙讀過渡（不停機）
+執行期取 credential 值的順序：
+1. 先查 D1 有無 `secret_ref` → 有 → 走 Secrets Store 取值（新家）。
+2. 找不到 → fallback 舊路徑：`CREDENTIALS_KV {api_key}:cred:{name}` + WASM `crypto_decrypt`（舊自管）。
+→ 新寫入一律走新家；舊資料未回填前仍可讀。
+
+### 4.2 回填（一次性、冪等、可審）
+`POST /credentials/migrate-to-secrets-store`（類比現有 `migrate-cron-index` 冪等端點）：
+- 對每個 `{api_key}:cred:{name}` KV row：WASM 解密取明文 → 寫進 Secrets Store（領 `secret_ref`）→ 在 D1 建 row（含 ref + metadata）。
+- 冪等：D1 已有該 (api_key,name) row 且 ref 可解析 → 跳過。
+- **誠實回報**逐筆 ok/fail（不假綠，mindset §7）。
+- **回填完成且驗證通過後**，才執行 §4.4 廢 ENCRYPTION_KEY。
+
+### 4.3 回滾錨點
+- 回填**不刪 KV 舊密文**（保留為回滾錨點），只新增 D1+Secrets Store。
+- 出問題 → 雙讀 fallback 自動回到 KV 路徑；D1 row 可刪、Secrets Store secret 可刪 → 回到純 KV 狀態。
+- 只有在「全租戶回填驗證綠 + 觀察期無 fallback 命中」後，才進 §4.4。
+
+### 4.4 廢自管 ENCRYPTION_KEY（最後一步）
+- 移除 `crypto_decrypt` 對 credential 的依賴路徑（KV 密文路徑停用）。
+- `wrangler secret delete ENCRYPTION_KEY`（cypher / auth_static_key / auth_service_account）。
+- 清理 KV 舊密文（確認 Secrets Store 是唯一真相源後）。
+- ⚠️ **此步不可逆**，須 leo 明示放行 + 回填觀察期通過。
+
+---
+
+## 5. 與鐵律 / 既有架構對齊（施工硬約束）
+- **rule 02 §2.2/§2.3**：cypher TS 不實作 credential 解密/注入業務邏輯。Secrets Store 取值走 host function 邊界（新增 `secret_get(ref)` 於 wasi-shim），注入仍在 WASM auth primitive。
+- **rule 01 加解密**：自管 AES-GCM 路徑在回填後廢除；新家由 CF Secrets Store 託管金鑰（arcrun 不持金鑰）。
+- **不新增 component**（mindset §1）；不新增 service binding（rule 03 §3.1）。
+- **薄殼（rule 07）**：CLI/MCP 只做「list 顯示 / replace 覆寫 / delete」介面轉換，store 能力在 API。
+- **部署繞開 GitHub Actions**：D1 migration + Secrets Store ensure 走 `acr init/update`（wrangler 直推），不掛 Actions。
+- **D1 同源**：用使用者既有 `arcrun-kbdb` D1（不新建第二顆），migration `0002_credentials.sql` 走現有 `deploy.ts` migration 注入路徑（與 `0001_base.sql` 同模式）。
+
+---
+
+## 6. 開放問題（施工前須 leo / 總管拍板）
+- **Q-a（核心）**：Secrets Store 動態 by-ref 取值路徑（§2.3 路徑 1 REST API）—— leo21c 自己的 CF 帳號是否支援、API 路徑與 token 範圍？需一次 spike 驗證。**這是整個遷移的硬前置**（取值不通則 D19 走不了）。
+- **Q-b**：寫入時 client 是否仍加密一層（§2.4 甲/乙）。傾向甲（不持金鑰，TS 短暫經手明文不落地）——需 leo 接受此誠實 trade-off。
+- **Q-c**：`sensitivity` 分級的判定（誰標 high/standard）——auth-recipe 可加 `sensitivity` 欄宣告該 service 的 credential 等級，或一律 high。
+- **Q-d**：與 redesign.md C（友善前門：.env → 一次填）整合——C 的「值來源 .env」在新架構下是「.env 明文 → cypher 寫進 Secrets Store」，與 §2.4 甲一致。確認 C 依附本 SDD（store 是 Secrets Store 不是 D1）。
+
+---
+
+## 7. 任務分解（待放行後施工；本批僅 SDD）
+- [ ] T1 spike：leo21c CF 帳號 Secrets Store create store + worker by-ref 取值驗證（解 Q-a）。**硬前置。**
+- [ ] T2 D1 migration `0002_credentials.sql`（§2.2）+ deploy.ts 注入。
+- [ ] T3 `acr init/update` 新增 ensure Secrets Store store + 注入 store_id（類比 ensureD1Database）。
+- [ ] T4 wasi-shim 新增 `secret_get(ref)` host function（守 rule 02 邊界）。
+- [ ] T5 寫入路徑：`POST/PUT /credentials` 改寫 Secrets Store + D1 ref（§2.4）。
+- [ ] T6 讀取/注入路徑：auth-dispatcher 改 D1 ref → Secrets Store 取值（§2.5）+ 更新 last_used。
+- [ ] T7 雙讀 fallback（§4.1）。
+- [ ] T8 回填端點 `POST /credentials/migrate-to-secrets-store`（§4.2，冪等可審）。
+- [ ] T9 治理端點 list/replace/delete + 移除任何 read-value 路徑（§3）+ CLI 薄殼。
+- [ ] T10 回填驗證 + 觀察期 → 廢 ENCRYPTION_KEY（§4.4，leo 明示放行）。
+
+> **每個 cred 操作跨 TS / WASM / host-function / 兩個 store，必端到端實測**（防再假綠，mindset §7）。T1 不通則整案停，先解 Q-a。

system-dev/docs/3-specs/arcrun/credential-primitives-wasm/credential-store-redesign.md

@@ -0,0 +1,211 @@
+# Credential Store 重設計提案（A telegram 一致性 + B KV→D1 + C 友善前門）
+
+> 建立：2026-06-29 by arcrun CC｜更新：2026-06-29（依 leo 最終精確 spec 改寫）｜對應 issue：Arcrun#13
+> 範圍宣告：本檔是既有 SDD `credential-primitives-wasm/` 的補充設計筆記（不是新 SDD 子系統，rule 02 §4.3 例外）。
+> 詞彙（leo 堅持精確）：**零件/component=TinyGo WASM**、**recipe=http_request+固定設定（打最終 API）**、
+> **workflow=多步 YAML（在這層「按名指定要哪個 credential」）**、**auth-recipe=credential 怎麼注入**。
+
+---
+
+## 0. leo 的最終 spec（一句話）：**不是拆除，是把前門做友善 + 把 D1 收尾**
+
+**保留全部既有零件，只改「credential 怎麼餵進去」，不改 recipe 本身。**
+
+```
+人填 .env / 環境變數                  ← 友善前門，任何人都會（本機=.env；雲端=code-on-web 的 Environment 設定，對稱）
+     ↓  acr creds push 保留，但「值的來源」= .env/env-var（不再強迫手寫 credentials.yaml）
+長久存「我的 D1」                      ← 存一次，存進使用者自己的 D1；之後自動，永不重推
+     ↓  workflow YAML「按名」指定要哪個 credential（"我要 google 那把"）→ 自動從 D1 取
+recipe 打最終 API                     ← telegram_send / notion / gsheets，保留，不刪
+```
+
+**對稱性**：本機讀 `.env`；雲端讀 code-on-web 的 Environment 設定。**同機制，只是來源位置不同。**
+
+### 明確「保留、不可刪」
+1. **`acr creds push` 保留** —— 手動推單一 credential 仍合法（只是不再是唯一/被迫的路徑）。
+2. **最終 API recipe 保留** —— telegram_send / notion / gsheets（http_request + 固定設定）是打 API 的端點，**不刪**。改的是「credential 怎麼餵」，不是 recipe。
+
+---
+
+## 0.5 Q1 — list 是動態讀 store 還是 hardcoded？（已核實 code，2026-06-29）
+
+**結論：recipe/auth-recipe 的「正規清單」是動態的；但 `acr parts` 是 hardcoded 且把 5 個 recipe 混進去 → 那 5 個之外的 pushed recipe 在 `acr parts` 看不到。**
+
+| 指令 | 讀哪裡 | 動態? | pushed recipe 會出現? |
+|---|---|---|---|
+| `acr recipe push` | `POST /recipes` → KV store（recipe.ts:87） | — | 寫入 store |
+| `acr recipe list` | `GET /recipes` → `RECIPES.list({prefix:'recipe:'})`（recipe.ts:182 / recipes.ts:260） | ✅ 動態 | ✅ 會 |
+| `acr auth-recipe list` | `GET /auth-recipes` → `RECIPES.list({prefix:'auth_recipe:'})`（auth-recipe.ts:42 / recipes.ts:547） | ✅ 動態 | ✅ 會 |
+| **`acr parts`** | **hardcoded `BUILTIN_COMPONENTS` 陣列（parts.ts:28-262），完全不 fetch store** | **❌ 靜態** | **❌ 不會** |
+
+- **component（零件＝WASM）hardcoded 是對的**：零件只能 PR merge 新增（mindset §4 人類閘門），固定、慢增，靜態清單反映真實。
+- **但 `acr parts` 把 5 個 recipe 也 hardcode 進去**（parts.ts:197-261：gmail_send / google_sheets_append / telegram_send / line_notify_send / notion）——**這是 component 與 recipe 的 conflation**。recipe 是動態投稿的（任何人 `acr recipe push`），卻被釘進 `acr parts` 的靜態清單。
+- **後果（leo 的擔憂成立，但範圍精確）**：用戶 `acr recipe push my_recipe` → 進 store → `acr recipe list` / `acr recipe search` **看得到**；但 `acr parts` **永遠看不到**（除非改 source 重發 CLI）。「submitted = invisible」**只發生在 `acr parts` 這個面**，不是整個生態壞掉。
+- **與 telegram bug 的關係**：telegram bug 是另一條軸（seed source vs live KV 漂移，A 已修），但與此**同病**＝「hardcoded 清單 ≠ live store」。`acr parts` 列退役/釘選 recipe（#13）也是這病的症狀。
+
+### Q1 修法 scope（建議，未在本批改 code）
+1. **`acr parts` 移除 5 個 recipe 的 hardcode**（parts.ts:197-261），只留**真零件**（logic/data/ai/http_request/cron…＝WASM，PR-only，靜態正確）。
+2. **`acr parts` 末尾改成「指路」**：列完真零件後，動態提示「整合類服務 → `acr auth-recipe list`（即時讀 store）；API recipe → `acr recipe list`（即時讀 store）」。讓 AI/人從 `acr parts` 被導到動態清單，不在靜態清單找 recipe。
+   - 進階（可選）：`acr parts` 末段直接 fetch `GET /recipes` + `GET /auth-recipes` 把 store 的 recipe 也列出來（標明「動態，來自 store」），徹底消除「submitted = invisible」。
+3. **明確分流原則寫進 parts.ts 註解**：零件＝靜態（PR-only）；recipe/auth-recipe＝動態（從 store 讀）。不再把 recipe 釘進零件清單。
+4. 這 scope ＝ #13「acr parts 殘留」的根治版（#13 只把 recipe 描述改對，沒解決「recipe 不該 hardcode 在 parts」的結構問題）。**屬薄殼修正（rule 07）＝把「列 recipe」這能力從介面靜態資料改成讀 API store，不違禁令。**
+
+---
+
+## 1. 現狀（已核實 code + 實測 live，2026-06-29）
+
+### 1.1 儲存：**KV，不是 D1**（B 的根因＝未完成的遷移，非「設計即如此」）
+- credential 只存 `CREDENTIALS_KV`，key=`{api_key}:cred:{name}`，AES-GCM。
+  - 寫：`acr creds push` → `POST /credentials`（`cypher-executor/src/routes/credentials.ts:48`）。
+  - 讀+解密：`auth_static_key` WASM `kv_get`（`registry/components/auth_static_key/main.go:146`）。
+  - binding：`cypher-executor/wrangler.toml:23`；型別 `src/types.ts:31`。
+- **全 repo 無任何 credential 的 D1**（D1 引用全是 KBDB graph）。
+- leo 確認：採用 KBDB 後使用者已有自己的 D1，當時就要求 credential 也搬進「我的 D1」長久存 → **此遷移從未完成**。
+  → B（KV→D1）**確定要做**，是 leo 明確要的「長久存我的 D1」層。
+
+### 1.2 .env → credential：**值不會自動進**（C 的痛點，但前門不友善 ≠ 拆掉）
+- `.env` 目前只供「設定」：`ENCRYPTION_KEY`/`NAMESPACE`/`ARCRUN_*`/`CLOUDFLARE_*`（`cli/src/lib/config.ts:125`）。
+- credential 的**值**只來自手寫 `credentials.yaml` → `acr creds push`（`cli/src/commands/creds.ts`）。
+- leo 記憶「notion/gsheets 只靠 .env 就通」與 code 不符——實際是早先 push 過、值已在 KV。
+- 痛點（北極星「拿 credential ≠ 攻打用戶」）：每次要手寫 yaml；不像 n8n Credentials tab 填一次長存。
+  → **C 不是發明「自動偵測魔法」**，而是把 `acr creds push` 的**值來源**從「手寫 yaml」改成「讀 .env/env-var」，存進 D1，之後 workflow 按名取。
+
+### 1.3 telegram 漂移（A）——已實測 smoking gun，已修 source
+- recipe `telegram_send`（`api-recipe-seeds.ts:108`）`auth_service:'telegram'`，endpoint `.../bot{{auth.bot_token}}/sendMessage`。
+- 但 `auth-recipe-seeds.ts` source 只有 **23** 個 service，缺 `telegram`/`line_notify`/`kbdb`/`google_user`。
+- 實測：prod = 27（手動 seed 過 telegram）；self-host **leo21c = 23，無 telegram** → telegram_send 找不到 auth recipe → `{{auth.bot_token}}` 注入空 → URL 變 `.../bot/sendMessage` → 壞。notion/gsheets 通是因它們在那 23 裡。
+- 這是「source vs live 漂移＝假綠」。telegram **不是**走 legacy `BUILTIN_CREDENTIALS_MAP`，正確形態一直是 recipe+auth-recipe，只是 auth-recipe 沒進 source 種子。
+
+---
+
+## 2. 目標狀態（target，＝leo 的 3 層流，全部保留只連得更友善）
+
+1. **唯一打外部 API 的方式**＝ recipe（保留）。telegram 與 notion/gsheets **同一條**「workflow 按名指定 → 從 D1 取 → auth-recipe 注入 → recipe 打 API」鏈，無例外（A，本次已修 source）。
+2. **credential 長久存使用者自己的 D1**（如 n8n Credentials tab）：填一次、長存、workflow 按名引用、永不重推（B）。
+3. **友善前門**：使用者把 token 填進 `.env`（本機）/ code-on-web Environment（雲端）**一次**，`acr creds push`（保留）以此為值來源，client 端加密後存進 D1。不再被迫手寫 `credentials.yaml`（C）。
+
+---
+
+## 3. 遷移步驟（A 已做；B/C 是設計變更，誠實標工作量）
+
+### Phase A — telegram/line_notify/kbdb 一致性（本次已做，commit 90777e3，未 push/merge）
+- [x] `auth-recipe-seeds.ts` 補 telegram（inject.path bot_token）/ line_notify（header Bearer）/ kbdb（header Bearer），形態取自 prod。
+- [x] `recipes.ts` `AuthInjectSpec` 補 `path?`（WASM/SDD §六早有、source 介面漏 → tsc 擋）。
+- [ ] google_user（oauth2）暫不回灌：內嵌 client_secret 不可進 git + 介面無 oauth2 欄 → 留 Phase D。
+- 部署後 leo21c 跑 `acr update`(/init/seed) → 23→26，telegram 即與 notion 同鏈可用。
+- **不刪任何 recipe；不碰 `acr creds push`。** 純補種子 + 補型別欄位。
+
+### Phase B —（已翻案，見 §4.5）儲存：**KV 維持，不搬 D1**；高敏感可選補 Secrets Store
+> 早先版本寫「KV→D1 遷移」。§4.5 核實史實 + leo 自己 2026-06-07 拍板（credential 留 KV）後**翻案**：
+> credential＝Redis-class（按 key 直接點查、密文不可 SQL 查），搬 D1 是淨負債。**B 改為：**
+1. **低敏感 credential 維持 KV**（現狀 CREDENTIALS_KV，AES-GCM）。`acr creds list` 已可用（`GET /credentials` KV.list）。
+2. **（可選、後續）高敏感（service account JSON/private key）→ Cloudflare Secrets Store**（credential_parts.md §8.2，KV 只存 ref）。唯一值得的儲存升級，與拍板不衝突。
+3. **不新增 D1 credentials 表、不新增 `cred_get` host function、不做 KV→D1 migration**——這些原計畫取消（好處 KV 已有）。
+4. 若 leo 仍要 D1：屬新需求（須更新 2026-06-07 拍板）。即便如此，密文本體仍留 KV/Secrets Store，D1 只放非機密 metadata。
+5. 風險：跨 TS Worker / WASM / host function 三層，**必端到端實測**（防再假綠，mindset §7）。**非小工程。**
+
+### Phase C — 友善前門：`acr creds push` 值來源＝.env/env-var → D1（小～中工程，依附 B）
+> **精確（leo 修正）**：不是「自動 pickup 魔法」，是「`acr creds push` 保留，但值的來源改成 .env/env-var，存進 D1，之後 workflow 按名取」。
+1. `acr creds push`（保留）新增「從 .env/env-var 讀值」模式：掃 .env 中「已知 credential 名」
+   （由 auth-recipe 的 `required_secrets[].key` 反推，例 `notion_token`/`telegram_bot_token`）→ client 端加密 → 存進 D1（Phase B 的 store）。
+   - 仍保留現有「從 credentials.yaml 讀值」模式（向後相容，不刪）。yaml 變成可選輸入源之一，不再是被迫。
+2. **對稱**：本機讀 `.env`（`config.ts loadDotEnvOnce` 已會載入 .env 進 `process.env`）；
+   雲端＝code-on-web 的 Environment 設定（同樣落到 env-var）。同一套讀法、不同來源位置。
+3. 名稱規約：.env 用大寫（`NOTION_TOKEN`）→ normalize 成 credential 名 `notion_token`（＝auth-recipe required_secrets.key）。
+4. **薄殼界線**（rule 07）：這是「擴 `acr creds push` 的輸入源」＝介面慣例的輸入解析（§2 允許第 1 項），
+   **不是**在 CLI 拼裝 API 缺的能力（值來源是 .env/yaml 都只是「轉成 API 期望的加密 payload」）。加密仍 client 端（§2 第 4 項唯一例外）。store 仍是 API（D1）。
+5. 結果：填一次 .env → `acr creds push`（或 deploy 末尾自動觸發一次）→ 長存 D1 → workflow 按名引用、零重複推。
+
+### Phase D（後續，非本批）— google_user(oauth2) 回灌 + oauth2 secret 部署期注入
+- AuthRecipeDefinition 介面補 oauth2 欄位；client_secret 走 `wrangler secret`/env 注入（不進 git），再回灌 source。
+
+---
+
+## 4. 正解：telegram 的 workflow / recipe yaml（給 mira 抄）
+
+telegram 發訊＝**recipe `telegram_send`**（不是 component、不是自建零件）；**credential 在 workflow 層按名指定**：
+
+```yaml
+name: notify_done
+flow:
+  - "notify >> ON_SUCCESS >> end"   # 單節點時 flow 可省
+
+config:
+  notify:
+    component: telegram_send         # ← 內建 recipe canonical_id（不是 component:telegram）
+    chat_id: "123456789"
+    text: "✅ 任務完成"
+    # bot_token 不寫這裡。recipe 的 auth_service='telegram' → 按名從 D1 取 telegram_bot_token
+    #   → auth-recipe:telegram 的 inject.path 注入進 URL path。一致鏈，與 notion/gsheets 同型。
+```
+
+**credential 解析（target 設計）：**
+1. 使用者把 `TELEGRAM_BOT_TOKEN=123456:ABC...` 填進 `.env`（本機）/ code-on-web Environment（雲端）**一次**。
+2. `acr creds push`（保留；值來源＝.env）→ client 加密 → 存進「我的 D1」credential store。**之後永不重推。**
+3. 執行時：cypher-executor 見 `telegram_send.auth_service='telegram'` → `auth_static_key` WASM 用 `cred_get` 從 D1 取
+   `telegram_bot_token` 密文 → `crypto_decrypt` → 依 `auth_recipe:telegram` 的 `inject.path.bot_token` 輸出 `auth_path`
+   → `makeRecipeRunner` 把 endpoint `{{auth.bot_token}}` 換成真 token → POST `https://api.telegram.org/bot<token>/sendMessage`，body=`{chat_id,text}`。
+
+這條鏈與 notion（header 注入）/gsheets（service_account runtime token 注入）**完全同型**，只注入位置不同（path vs header）。
+
+> **過渡期（B/C 未完成前，今天就能用的方式）**：在 `credentials.yaml` 放 `telegram_bot_token` + `acr creds push`（值進 KV）。
+> 上面 yaml 的 workflow 寫法不變——只是 store 暫時是 KV、值來源暫時是手寫 yaml。B/C 完成後 store→D1、來源→.env，**workflow yaml 一字不改**（按名引用穩定）。
+
+---
+
+## 4.5 Q2 — KV vs D1：史實核實 + 三方調和 + CC 推薦（leo 授權我決定）
+
+### 史實（git 核實，2026-06-29）：**本 repo 的 credential 從來沒在 D1**
+- 最早 MVP commit `2707fca`：credential 即「AES-GCM decrypt from **CREDENTIALS_KV**」。
+- 更早的 u6u-credentials ancestor worker（`credentials/` 已刪）：`CREDENTIALS_KV.put('cred:${id}')`——**也是 KV**。
+  （它的 `CredentialRecord` 已有 name/type/created_at 結構欄位，但以 JSON 存進 KV。）
+- 全 history 的 `CREATE TABLE` 只有 KBDB（entries/templates/entry_values），**從無 credentials 表**。
+- → **找不到任何「credential D1→KV 撤退」的 commit**。leo 記憶的「原本 D1 有 credentials 表、後來退 KV」
+  **在本 repo 史實裡不存在**（可能是 pre-repo 設計或別處，沒落地過 code）。
+
+### 三方說法（全部攤開，none 寫 D1 存 credential）
+| 來源 | 對 credential 儲存的說法 |
+|---|---|
+| leo 口頭（現在） | 存 **D1**（「長久存我的 D1」） |
+| 現行 code | **KV**（CREDENTIALS_KV，MVP 至今未變） |
+| **kbdb-base SDD 拍板 2026-06-07（leo 親簽「Leo：同意」）** | **credential 留 KV**（「session、verdict、credential 留 KV＝短期高頻純取用，類比 Redis；workflow/recipe/成功記錄才進 D1＝要層級/列舉/排序」）。`kbdb-base/design.md:318`、`tasks.md:11`、`tasks.md:83` 三處一致。 |
+| credential_parts.md §8.2（長期需求源） | **tenant KV + Cloudflare Secrets Store**（低敏感→KV AES-GCM；高敏感如 service account JSON/private key→Secrets Store，KV 只存 ref）。**不是 D1。** |
+
+→ **leo 口頭「D1」與他自己 2026-06-07 的書面拍板（credential 留 KV）直接衝突**，且兩份書面需求源都沒說 D1。
+SDD 協議（00-sdd-protocol「規範互相矛盾→引原文、不自行猜」）要求攤開矛盾；但 leo 此次**明確授權「你決定並推薦」**，故下方給推薦（grounded in 上述證據），同時把矛盾標清楚讓 leo 有機會推翻。
+
+### 「退 D1→KV 的理由還成立嗎？」（leo 的核心提問）
+- 本 repo 沒發生過該退守，故無「當初理由」可考。但 leo 假設的理由（「self-hosted 少依賴、免 D1」）**今天確實已 moot**——
+  self-hosted 用戶現在本來就有一顆 KBDB D1（`kbdb/wrangler.toml:10` `[[d1_databases]]`，deploy.ts 注入用戶自己的 id）。
+- **但「能用 D1」不等於「credential 該用 D1」。** 2026-06-07 拍板把 KV 留給 credential 的理由不是「沒有 D1」，
+  而是**「credential ＝短期高頻純取用（by api_key+name 直接點查），是 Redis-class 工作負載，不需要 D1 的層級/列舉/排序」**。
+  這個理由**與有沒有 D1 無關，今天仍成立**。
+
+### ✅ CC 推薦（leo 授權我決定）：**credential 主存維持 KV；不為「列表/按名引用」而搬 D1**
+理由（誠實 trade-off，mindset §7）：
+1. **守 leo 自己的拍板**：2026-06-07「credential 留 KV」是有理由的設計（Redis vs PostgreSQL 分工），非偷懶。推翻它要有新理由，目前沒有。
+2. **D1 宣稱的好處在 KV 上已可達或不需要**：
+   - 「`acr creds list`」KV 已能做（`GET /credentials` 用 `KV.list({prefix})` 列名，credentials.ts:68-78 已實作，**今天就有**）。
+   - 「按名引用（workflow 指定要哪把 cred）」是 **key 設計**（`{api_key}:cred:{name}`）就給的，與 KV/D1 無關——telegram_send 的 `auth_service`→`required_secrets.key` 已是按名取。**A 修好後就具備，不需 D1。**
+   - 「結構化欄位/sensitivity 分級」credential 是不可查詢的密文 blob（查詢明文＝洩漏），D1 的 SQL 查詢優勢對 credential **用不上**；分級需求由 credential_parts.md 的 **Secrets Store**（高敏感）解，不是 D1。
+3. **搬 D1 成本高且踩鐵律邊界**：要新 host function `cred_get`（WASM 改）、一次性 migration、跨 TS/WASM/host-function 三層 e2e——換來的好處 KV 已有。**淨負債。**
+4. **真正缺的不是 D1，是「友善前門 C」**：leo 真痛點是「每 cred 手寫 yaml + 重推」，那是 **C（.env 當值來源 + 一次存）** 解的，**與 store 是 KV 還 D1 無關**。
+
+**推薦的目標儲存（取代本檔早先「搬 D1」設計）：**
+- **低敏感 credential（多數 token/api_key）→ 維持 KV**（現狀，AES-GCM）。
+- **高敏感（service account JSON / private key）→ Cloudflare Secrets Store**（依 credential_parts.md §8.2，KV 只存 ref）——這是**唯一值得做的儲存升級**，且與 leo 拍板不衝突（拍板說 credential 留 KV，未禁高敏感走 Secrets Store；兩者互補）。
+- **C（友善前門）照做**：`acr creds push` 值來源＝.env/env-var、存一次、workflow 按名取。**store 仍 KV(+Secrets Store)**。
+- → **B 從「KV→D1 遷移」改為「KV 維持 + 高敏感補 Secrets Store（可選、後續）」**。telegram/notion/gsheets 的一致鏈（A）與一次填（C）**完全不依賴 D1**。
+
+> 若 leo 看完仍要 D1（例如想未來在同一顆 DB 做 cred 審計/輪替記錄）：那是**新需求**，需更新 2026-06-07 拍板。
+> 屆時 credential **本體**仍建議 KV/Secrets Store（密文不需 SQL），D1 只放**非機密的 metadata**（cred 名稱/服務/建立時間/last_verified），與 workflow/recipe 進 D1 同模式。**不要把密文搬進 D1 當主存。**
+
+---
+
+## 5. 與既有鐵律/SDD 的對齊
+- **不刪 recipe、不禁 `acr creds push`**（leo spec）。A 純補種子 + 型別欄位；C 是擴 `acr creds push` 輸入源，非拆除。
+- 不新建 component（mindset §1 / rule 02）。
+- credential 解密仍在 WASM（rule 02 §2.2）；KV→D1 只是密文來源從 `kv_get` 換成新 host function `cred_get`（屬 wasi-shim，rule 02 §2.3 合法）。
+- 薄殼（rule 07）：`acr creds push` 讀 .env 仍只做「輸入解析 + client 加密 + 呼叫 API」，能力（store）在 API/D1，不在介面層。
+- 設計權威：`auth-recipe.md` §六（telegram path 注入 line 70-71）、§七（kbdb 共用 line 150-151）；
+  需求源 `docs/user_requirements/credential_parts.md`（credential 長期規格）。

system-dev/docs/3-specs/arcrun/credential-primitives-wasm/design.md

@@ -0,0 +1,245 @@
+# Design Document: Credential Primitives TS → WASM 改寫
+
+## Overview
+
+將 `cypher-executor` 中以 TypeScript 實作的 credential 注入邏輯，改寫為 4 個獨立的 WASM 零件。這是 `credential_parts.md` 長期規格的實現，不再是「未來 Phase」。
+
+**動機**：TS 實作無法在地端（workerd）和邊緣端（Wazero）執行。WASM 零件跨 runtime 可攜，符合 u6u 三層部署架構。
+
+**嚴格規範（richblack 2026-04-19 確認）**：cypher-executor TS **完全不實作**任何 credential / auth / template / JWT / 解密邏輯。所有業務邏輯必須在 TinyGo WASM 零件內。TS 僅負責 HTTP routing + 呼叫 WASM + host function 提供 runtime primitive（crypto.subtle / KV / fetch）。
+
+---
+
+## 現有 TS 實作（要刪除的）
+
+| 檔案 | 功能 | 對應 WASM Primitive |
+|------|------|---------------------|
+| `credential-injector.ts` — `injectFromAuthRecipe()` | static_key template 展開 | `auth_static_key` |
+| `credential-injector.ts` — service_account 分支 | JWT signing + token exchange | `auth_service_account` |
+| `credential-injector.ts` — `decryptCredential()` | AES-GCM 解密 | host function（所有 primitive 共用） |
+| `credential-injector.ts` — `interpolateTemplate()` | `{{secret.KEY}}` 替換 | 內建在各 primitive |
+| `jwt-signer.ts` — `exchangeGoogleJwt()` | PEM→PKCS8→RS256→token | `auth_service_account` |
+| `component-loader.ts` — BUILTIN_API_RECIPES | gmail/telegram/line/gsheets 寫死邏輯 | 刪除，改用 auth recipe + `http_request` 零件 |
+| `credential-injector.ts` — BUILTIN_CREDENTIALS_MAP | 舊路徑 flat injection | 刪除，統一走 auth recipe |
+| `arcrun/credentials/` | 重複的 credentials Worker | 刪除，路由已在 cypher-executor |
+
+---
+
+## 4 個 WASM Primitive 設計
+
+### 統一 I/O 介面（stdin/stdout JSON）
+
+```
+stdin（Worker → WASM）：
+{
+  "action": "authenticate" | "needs_refresh" | "refresh" | "test",
+  "api_key": "ak_xxx",          // 租戶識別，用來組 KV key
+  "service": "openai",          // 對應 auth_recipe:{service}
+  "request": { "method": "GET", "url": "/path", "headers": {}, "body": null }
+}
+
+WASM 內部流程：
+  1. recipeJSON = kv_get("auth_recipe:" + service)
+  2. 依 recipe.required_secrets 逐一 kv_get("{api_key}:cred:{name}") → {encrypted, iv}
+  3. secrets[name] = crypto_decrypt(encrypted, iv)
+  4. （service_account）crypto_sign_rs256(jwt, pkcs8) + http_request 換 token
+  5. 展開 recipe.inject 的 {{secret.X}} / {{runtime.X}} 模板
+
+stdout（WASM → Worker）：
+{
+  "success": true,
+  "auth_headers": { "Authorization": "Bearer xxx" },
+  "auth_query": {},
+  "auth_body": {},
+  "runtime": { ... updated runtime state，供下次 refresh 用 }
+}
+```
+
+### auth_static_key
+
+**位置**：`arcrun/registry/components/auth_static_key/`
+**語言**：TinyGo 或 AssemblyScript
+
+功能：
+1. 讀取 `recipe.inject.header/query/body` 模板
+2. 用 `secrets` 展開 `{{secret.KEY}}` 模板
+3. 回傳 `auth_headers` / `auth_query` / `auth_body`
+
+涵蓋：~80% 服務（Bearer token, API Key, Basic Auth, custom header）
+
+### auth_service_account
+
+**位置**：`arcrun/registry/components/auth_service_account/`
+**語言**：TinyGo 或 AssemblyScript
+
+功能：
+1. 從 `secrets.service_account_json` 解析 private key
+2. JWT signing（RS256：PEM→PKCS8→sign）
+3. POST token exchange endpoint → 取得 access_token
+4. 展開 `{{runtime.access_token}}` 模板
+
+**crypto 考量**：
+- TinyGo 的 `crypto/rsa` + `crypto/x509` 支援有限
+- 若 TinyGo 不支援 RS256：使用 host function 讓 Worker 的 `crypto.subtle` 代簽
+- 或改用 AssemblyScript（有 as-crypto 套件）
+
+### auth_oauth2（新建）
+
+**位置**：`arcrun/registry/components/auth_oauth2/`
+
+功能：
+1. `needs_refresh`：檢查 `runtime.expires_at` 是否過期
+2. `refresh`：用 `runtime.refresh_token` + `secrets.client_secret` 換新 token
+3. `authenticate`：展開 `{{runtime.access_token}}` 到 headers
+
+### auth_mtls（新建）
+
+**位置**：`arcrun/registry/components/auth_mtls/`
+
+功能：
+1. 從 `secrets` 讀取 client cert + key
+2. 回傳 TLS 設定（由 Worker runtime 執行實際 mTLS handshake）
+
+---
+
+## cypher-executor 改動
+
+### 保留（TS routing 層）
+
+- `routes/credentials.ts` — HTTP CRUD for credentials（接收加密的 payload）
+- `routes/recipes.ts` — HTTP CRUD for auth recipes
+- `routes/auth.ts` — OAuth flow routing
+- `graph-executor.ts` — workflow 執行排程
+- `lib/wasi-shim.ts` — WASM runtime + host functions（加解密 / KV / 簽章 / HTTP 實際由 `crypto.subtle` / env binding / fetch 執行，但**呼叫時機由 WASM 決定**）
+
+### 修改
+
+- `actions/credential-injector.ts` — **整檔刪除**，改為新檔 `actions/auth-dispatcher.ts`（約 30 行）：
+  1. 查 `resolveAuthRecipe(componentId)` 取得 `primitive` 名稱（static_key / service_account / oauth2 / mtls）
+  2. 呼叫對應的 auth primitive Worker（見下「呼叫方式」）
+  3. 送 `{ action, api_key, service, request }`（**不送 secrets、不送 recipe plaintext**）
+  4. WASM 透過 host function 自行 `kv_get` 讀 recipe + 加密 secret，`crypto_decrypt` 解密
+  5. 讀回傳 → 合併 `_auth_headers` / `_auth_query` / `_auth_body` 進 ctx
+
+  **呼叫方式（Phase 7，2026-06-06 演化）**：原設計走 `fetch(wasmWorkerUrl(auth_{primitive}, WORKER_SUBDOMAIN))`（workers.dev 公網 URL）。但壓測階段 11 證實：**self-hosted** cypher（`arcrun-cypher-executor.{sub}.workers.dev`）用 `fetch()` 打**同 `{sub}.workers.dev` zone** 的 auth worker，CF 回 **1042**（官方 docs：「fetch from another Worker on the **same zone**」）。官方不踩是因官方 cypher 在自訂域 `cypher.arcrun.dev`、打 `*.workers.dev` 屬**跨 zone**（非官方有 flag）。token/解密鏈本身正常，唯一卡點是同 zone fetch。
+  - **解法 = `global_fetch_strictly_public` compatibility flag**（cypher wrangler.toml），auth-dispatcher **維持原本 `fetch(workers.dev)` 不改**。此 flag 讓 `fetch()` 走公網「前門」→ same-zone fetch 也通（官方 docs：「Worker-to-Worker fetch 可用 service binding **或** `global_fetch_strictly_public` flag」）。
+  - **為何選 flag 不選 service binding**：service binding 靜態、加/改要重 deploy cypher（官方 docs）；flag 一行解、用戶無感、不動 service binding 禁令。先做了 service binding（A）後 richblack 拍板廢、改 flag（B）。
+  - **flag 安全（查證官方 docs）**：唯一副作用「Worker fetch 自己 hostname → self-loop」；cypher 只打外部 API + sibling auth worker（皆非自己 hostname）→ 不 self-loop。
+  - **官方/self-host 共用同一份 toml**：官方 cypher 本就跨 zone（cypher.arcrun.dev → workers.dev），加 flag 行為不變；self-host 同 zone 被修好。`stripOfficialOnlyBindings()` 不碰 `compatibility_flags`，self-hosted 部署自動帶上。
+
+- `lib/component-loader.ts` — **刪除 `BUILTIN_API_RECIPES`**（含 http_request / gmail / telegram / line_notify / google_sheets 的 TS 實作），全部改走 WASM runner。每個 `.wasm` 零件都已編譯並以獨立 Worker 部署（`{canonical-id-kebab}.arcrun.dev`）。loader 新增的「WASM runner」路徑就是「canonical_id → HTTP URL 查表後 fetch」，**不做** WASM instantiate。
+  - **R2 動態注入 WASM 路徑作廢**（richblack 2026-04-19 確認：CF workerd 無法以 R2 物件臨時 instantiate WASM）。用戶自製零件（Phase 5）同樣走「產生獨立 Worker」流程，不從 R2 讀。
+
+### 刪除
+
+- `lib/jwt-signer.ts` — 整檔刪除，RS256 簽章移入 `auth_service_account` WASM（透過 host function `crypto_sign_rs256`）
+- `credential-injector.ts` 整檔刪除（見上）
+- `component-loader.ts` 的 `BUILTIN_API_RECIPES` 整段刪除
+- `BUILTIN_CREDENTIALS_MAP` 已在 `credential-injector.ts` 內，隨檔一併刪
+
+---
+
+## Host Functions（WASM ↔ Worker 的橋接）
+
+auth primitive WASM 需要呼叫外部能力時，透過 host function。全部放 `u6u` namespace。**錯誤回傳非零 uint32；成功 = 0 且把結果寫入 `outPtr` 指向的 buffer**。
+
+| Host Function | TinyGo 簽章 | 用途 |
+|---|---|---|
+| `http_request` | `(urlPtr/Len, methodPtr/Len, headersPtr/Len, bodyPtr/Len, outPtr, outLenPtr) uint32` | HTTP 請求（已實作） |
+| `kv_get` | `(keyPtr, keyLen, outPtr, outLenPtr) uint32` | 讀 KV。Worker 依 key 前綴路由到 `CREDENTIALS_KV` / `RECIPES` |
+| `crypto_decrypt` | `(encPtr, encLen, ivPtr, ivLen, outPtr, outLenPtr) uint32` | AES-GCM 解密。encryption key 由 Worker 從 `env.ENCRYPTION_KEY` 內部讀取，**永遠不暴露給 WASM** |
+| `crypto_sign_rs256` | `(dataPtr, dataLen, pkcs8Ptr, pkcs8Len, outPtr, outLenPtr) uint32` | Worker 用 `crypto.subtle.sign('RSASSA-PKCS1-v1_5' + SHA-256)`；private key 以 PKCS8 bytes 傳入 |
+
+這些 host function 在 `lib/wasi-shim.ts` 中以 WASI import 提供。
+
+### 安全邊界
+
+- `ENCRYPTION_KEY` 只在 `crypto_decrypt` host function 內部使用，**絕不**經 stdin / 回傳值 / 任何路徑傳給 WASM
+- `api_key` 經 stdin 傳入 WASM（讓 WASM 自己組 `{api_key}:cred:{name}` KV key）
+- `kv_get` 在 Worker 側檢查 key 前綴：
+  - `auth_recipe:*` → 讀 `RECIPES`
+  - `{api_key}:cred:*` → 讀 `CREDENTIALS_KV`，且 `{api_key}` 必須等於 stdin 傳入的 api_key（防越權）
+  - 其他前綴 → 回傳錯誤
+
+---
+
+## 關於解密位置
+
+採用**方案 B（唯一方案）**：WASM 透過 host function `crypto_decrypt()` 自行解密。
+
+- cypher-executor TS 完全不解密、不知道 plaintext
+- `ENCRYPTION_KEY` 永遠留在 Worker host function 內
+- WASM 知道要解哪份 ciphertext（經 `kv_get` 讀到的 `{encrypted, iv}`），但拿不到 encryption key
+- 這樣 TS 層完全沒有零件業務邏輯，符合 CLAUDE.md §禁止行為 1/6
+
+（歷史註記：曾規劃方案 A「TS 先解密再送 stdin」，已廢棄 — 違反「TS 不得實作零件邏輯」。）
+
+---
+
+## §8 `{{credential.X}}` 用戶面注入語法（2026-06-10，richblack 確認 change）
+
+### 問題（壓測實證的 401 根因）
+
+Haiku 自主壓測時自然地在 workflow node.data 寫 `{{credential.openai_key}}` 引用已存的 credential，
+結果打目標 API 回 **401**；只有把 token **明文硬編碼**進 workflow 才 200。
+
+**根因（系統客觀證據，三條 template 展開路徑都不認 `credential.` namespace）**：
+1. `graph-executor.ts` `interpolateString()`（node.data 展開）只認「context 內已存在的 key path」
+   （`{{input.X}}` / `{{data.Y}}` / 任意 dot path），**無 `credential` namespace** → `{{credential.X}}`
+   展不開 → header 帶字面值 `Bearer {{credential.X}}` 或空 → 401。
+2. auth recipe `inject` + auth primitive WASM 只認 `{{secret.X}}` / `{{runtime.X}}`，那條是 auth recipe
+   **自動注入**路徑（recipe 宣告 `auth_service` 才觸發），不是用戶在 node.data 直接引用的入口。
+
+**正解（auth recipe 自動注入）其實存在，但用戶不知道、直覺會寫 `{{credential.X}}`** → 這是
+**設計缺口**（缺一個直覺的用戶面 credential 引用入口），不是單純 bug。
+
+### 決策：讓 `{{credential.X}}` 真的能用（richblack 2026-06-10）
+
+新增「用戶在 workflow node.data 直接寫 `{{credential.NAME}}` → 自動解密回填」這條入口。
+
+**硬約束（rule 02 §2.2）**：解密**絕不能**在 graph-executor TS 做（hook 擋 `crypto.subtle.decrypt`，
+且違反「TS 不實作 credential 邏輯」）。故 `{{credential.X}}` 的解密**復用既有 auth_static_key WASM**。
+
+### 設計：auth_static_key 新增 `resolve_credentials` action
+
+| 角色 | 職責 |
+|------|------|
+| graph-executor.ts（薄 routing） | 偵測 node.data 內 `{{credential.NAME}}` → 收集 names → 呼叫 auth_static_key WASM `resolve_credentials` → 拿回明文 → 回填 node.data。**不解密、不碰 ENCRYPTION_KEY**。 |
+| auth_static_key WASM（新 action） | 收 `{action:"resolve_credentials", api_key, names:[...]}` → 對每個 name `kv_get("{api_key}:cred:{name}")` + `crypto_decrypt` → 回 `{success, credentials:{name: plaintext}}`。**不查 recipe**（與 authenticate 分流）。 |
+
+**stdin/stdout（resolve_credentials）**：
+```
+stdin:  { "action": "resolve_credentials", "api_key": "ak_xxx", "names": ["openai_key", "..."] }
+stdout: { "success": true, "credentials": { "openai_key": "sk-...", ... } }
+        缺某 name → success:false + error 指明缺哪個（誠實，不假綠）
+```
+
+**展開時機（graph-executor）**：在 node.data interpolate（現有 `interpolateData`）**之後**、
+node 執行**之前**插一步：掃描展開結果裡殘留的 `{{credential.NAME}}` → 走 WASM resolve → 回填。
+放在 auth recipe 自動注入（`tryAuthDispatch`）**之外**，兩條入口並存但不重疊（一個是用戶顯式引用、
+一個是 recipe 宣告 `auth_service` 隱式注入）。
+
+**安全邊界（同 authenticate）**：
+- `crypto_decrypt` host function 內部用 `ENCRYPTION_KEY`，**永不暴露給 WASM / 不經 graph-executor**。
+- `kv_get` host 側檢查 `{api_key}:cred:*` 的 api_key 必須等於 stdin api_key（防越權，現有機制）。
+- graph-executor 只傳 `names`（明文 credential 名）+ api_key，**不傳、不見** ciphertext / plaintext key。
+
+### 為何不選「新建 credential_resolve 零件」
+
+auth_static_key 已具備 `kvGet` + `cryptoDecrypt` 全部能力，新建零件 = 功能重疊 + 多一個 Worker
+部署成本。加一個 action 最貼近現有架構（richblack 2026-06-10 拍板）。
+
+### 不做
+
+- ❌ 不在 graph-executor 解密（rule 02 §2.2）
+- ❌ 不改 credential KV key 格式（仍 `{api_key}:cred:{name}`）
+- ❌ 不碰 auth recipe 自動注入路徑（`tryAuthDispatch` / `{{secret.X}}` 不變）
+
+---
+
+## 不做的事
+
+- ❌ 不改 recipe YAML schema — 沿用現有格式
+- ❌ 不改 KV 儲存結構 — `auth_recipe:{service}` / `{api_key}:cred:{name}` 不變
+- ❌ 不改 SDK API — SDK 仍是 HTTP thin wrapper
+- ❌ 不建新的 Worker — 在 cypher-executor 內完成（§8 復用 auth_static_key，不新建零件）

system-dev/docs/3-specs/arcrun/credential-primitives-wasm/tasks.md

@@ -0,0 +1,237 @@
+# Implementation Tasks: Credential Primitives TS → WASM
+
+**嚴格規範（richblack 2026-04-19）**：cypher-executor TS 不得實作任何 credential / auth / template / JWT / 解密邏輯。全部走 TinyGo WASM + host functions（方案 B）。
+
+**封測狀態**：推遲（richblack 2026-04-19 決定）。先完成 Phase 1-3 清除違規 TS，再啟動封測。
+
+---
+
+## Phase 0：核心合併（u6u-core → arcrun）
+
+- [x] 0.1 把 `u6u-core/builtins/` 搬到 `arcrun/builtins/`
+- [x] 0.2 確認 `arcrun/registry/components/` 21 個零件的 contract.yaml 完整（21/21）
+- [x] 0.3 刪除 `arcrun/credentials/` 整個目錄（重複，credential route 已在 cypher-executor）
+- [x] 0.4 更新 `arcrun/cypher-executor/wrangler.toml`：確認 CREDENTIALS_KV binding 存在
+- [x] 0.5 刪除 `matrix/u6u-core/` 整個目錄（2026-04-19 完成，只剩 credentials/ 已被 cypher-executor 取代）
+- [x] 0.6 在 `cypher-executor/src/lib/wasi-shim.ts` 新增 host functions：
+  - `u6u.kv_get(keyPtr, keyLen, outPtr, outLenPtr) uint32` — 依 key 前綴路由到 `CREDENTIALS_KV` / `RECIPES`，越權檢查 api_key
+  - `u6u.crypto_decrypt(encPtr, encLen, ivPtr, ivLen, outPtr, outLenPtr) uint32` — 用 `env.ENCRYPTION_KEY` + `crypto.subtle` AES-GCM 解密；key 不暴露給 WASM
+  - `u6u.crypto_sign_rs256(dataPtr, dataLen, pkcs8Ptr, pkcs8Len, outPtr, outLenPtr) uint32` — `crypto.subtle.sign('RSASSA-PKCS1-v1_5' + SHA-256)`
+  - 2026-04-19 完成：wasi-shim.ts 新增 `createArcrunHostFunctions(env, apiKey)` factory，集中 AES-GCM 解密 + RSA sign + KV 前綴路由越權檢查。WASI imports 的 u6u namespace wiring 本來就已接好（只是當時沒有實作 factory）。typecheck 通過。
+- [x] 0.7 在 `cypher-executor/src/lib/component-loader.ts` 新增 WASM runner 路徑：
+  - 所有 WASM 零件（含 auth primitive、API 零件、未來用戶自製）一律走 HTTP URL（`{canonical-id-kebab}.arcrun.dev`）到獨立 Worker
+  - **R2 動態注入路徑作廢**（richblack 2026-04-19 確認：CF workerd 不支援以 R2 物件臨時 instantiate WASM；用戶自製零件同樣走「產生獨立 Worker」流程，不走 R2）
+  - cypher-executor 本身**不做** WASM instantiate，也不直接呼叫 `createArcrunHostFunctions`；那個 factory 是**零件 Worker 側**（`.component-builds/{name}/src/index.ts`）用的，在 Phase 1 建立 auth_static_key Worker 時接上
+  - 2026-04-19 完成：`component-loader.ts` 新增 `WASM_HTTP_RUNNER_IDS`（10 個 canonical_id，6 個 API 零件 + 4 個 auth primitive）＋ `wasmWorkerUrl()` URL 慣例輔助函數；解析鏈新增為第 8 層（放在 `BUILTIN_API_RECIPES` fallback 之後，避免 Phase 3 尚未完成時 API 零件 Worker 未部署造成 404；Phase 3 刪除 `BUILTIN_API_RECIPES` 後，API 零件會自然落到此層）。auth primitive 從此層進入。`tsc --noEmit` 通過。
+
+---
+
+## Phase 1：auth_static_key WASM（優先，涵蓋 80% 服務）
+
+方案 B：WASM 自行讀 KV + 解密，TS 不碰 plaintext。
+
+- [x] 1.1 建立 `arcrun/registry/components/auth_static_key/` 目錄
+- [x] 1.2 寫 `component.contract.yaml`（input: `{action, api_key, service, request}` → output: `{success, auth_headers, auth_query, auth_body, runtime}`）
+- [x] 1.3 實作 `main.go`（TinyGo）：
+  - 宣告 host imports：`kv_get` / `crypto_decrypt`（static_key 不需要 http_request）
+  - 從 stdin 讀 `{action, api_key, service}`
+  - `kv_get("auth_recipe:" + service)` → recipe JSON → 驗證 `primitive == "static_key"`
+  - 對每個 non-optional `recipe.required_secrets`：`kv_get("{api_key}:cred:{name}")` → `{encrypted, iv}` → `crypto_decrypt` → plaintext
+  - 展開 `{{secret.X}}` / `{{runtime.X}}` 模板於 `inject.header/query/body`；未知 key 展空字串（與 TS parity）；其他 namespace 的 `{{...}}` 原樣保留
+  - 輸出 stdout JSON `{success, auth_headers, auth_query, auth_body, runtime}`
+- [x] 1.4 `tinygo build -o auth_static_key.wasm -target=wasi main.go` — 2026-04-19 編譯通過（1.1MB，在 contract 限制 2MB 內）
+- [🔄] 1.5 建立 `.component-builds/auth_static_key/`（用 `component-worker-template`）並部署到 `auth-static-key.arcrun.dev`
+  - 2026-04-20 完成**建置**部分:`.component-builds/auth_static_key/{wrangler.toml, package.json, tsconfig.json, src/index.ts, component.wasm}` 全數到位
+  - 方案 A:`src/index.ts` 直接 import `../../../cypher-executor/src/lib/wasi-shim` 的 `createWasiShim` + `createArcrunHostFunctions`(以 `ArcrunHostEnv` 結構型別相容);AES 解密邏輯仍只存在於 wasi-shim.ts 一處(rule 02 §2.2)
+  - 綁同組 KV:CREDENTIALS_KV (e7f4320f88d343f187e35e3543dd74c9) / RECIPES (9cf9db905c6241f78503199e58b2ffe0);ENCRYPTION_KEY 走 `wrangler secret put`
+  - `wrangler deploy --dry-run` 通過(1192 KiB, 419 KiB gzip);實際 `wrangler deploy` + `secret put ENCRYPTION_KEY` 留給 richblack 執行
+- [x] 1.6 建立 `auth-dispatcher.ts`（取代 `credential-injector.ts`）：查 auth recipe → HTTP POST 到對應 auth primitive URL → 合併 `_auth_headers` 進 ctx
+  - 2026-04-20 完成:`cypher-executor/src/actions/auth-dispatcher.ts` 新建,export `tryAuthDispatch(componentId, input, env, apiKey)`
+  - 流程:查 `resolveAuthRecipe` → primitive 在 `SUPPORTED_PRIMITIVES`(目前只有 `static_key`)→ fetch `wasmWorkerUrl('auth_static_key')` → 合併 `_auth_headers/_auth_query/_auth_body`
+  - 自引用防護:`AUTH_PRIMITIVE_IDS` set 排除 4 個 `auth_*` componentId
+  - `wasmWorkerUrl` 從 `component-loader.ts` export 出來共用
+  - `graph-executor.ts` 改為:先試 `tryAuthDispatch`(新路徑),沒命中 fallback 到舊 `injectCredentials`(Phase 1.9 刪)
+  - 檢查過 auth-dispatcher.ts 無 `crypto.subtle` / `interpolate` / `{{secret.` / hard-code API URL,符合 rule 02 §2.2
+  - `tsc --noEmit` 通過
+- [ ] 1.7 端對端測試：openai recipe → 成功注入 `Authorization: Bearer <openai_key>`
+- [ ] 1.8 端對端測試：twilio recipe（Basic Auth）→ 成功注入
+- [ ] 1.9 **刪除 `credential-injector.ts` 整檔**（`decryptCredential` / `decryptSecrets` / `interpolateTemplate` / `BUILTIN_CREDENTIALS_MAP` 全刪）
+
+---
+
+## Phase 2：auth_service_account WASM
+
+- [🔄] 2.1 建立 `arcrun/registry/components/auth_service_account/` 目錄
+- [🔄] 2.2 寫 `component.contract.yaml`
+- [🔄] 2.3 實作 `main.go`：
+  - 從 stdin 讀 `{api_key, service}` + `kv_get` 拿 recipe + 解密 SA JSON
+  - 解析 SA JSON 取 `client_email` / `private_key`（PEM）
+  - PEM → PKCS8 bytes（純 Go，base64 decode + 去 header/footer）
+  - 組 JWT header + payload（base64url），呼叫 `crypto_sign_rs256(signingInput, pkcs8)` 拿 signature
+  - 組完整 JWT → `http_request` POST `token_uri` → 拿 `access_token`
+  - 展開 `{{runtime.access_token}}` 模板
+- [x] 2.4 `tinygo build -o auth_service_account.wasm -target=wasi main.go` — 2026-04-20 編譯通過（1.1MB,在 contract 限制 2MB 內）
+- [x] 2.5 建立 `.component-builds/auth_service_account/` 並部署到 `auth-service-account.arcrun.dev`
+  - 2026-04-20 完成**建置**部分:`.component-builds/auth_service_account/{wrangler.toml, package.json, tsconfig.json, src/index.ts, component.wasm}` 全數到位
+  - 方案 A:`src/index.ts` 重用 `createArcrunHostFunctions` 提供 kv_get/crypto_decrypt/crypto_sign_rs256,**額外加 `http_request` host function**(token exchange 用,非 crypto 不受 §2.2 約束)。http_request 直接回 response body 原文(WASM 端 json.Unmarshal 找 access_token)
+  - 綁同組 KV:CREDENTIALS_KV / RECIPES;ENCRYPTION_KEY 走 `wrangler secret put`
+  - `wrangler deploy --dry-run` 通過(1248 KiB, 440 KiB gzip);實際 `wrangler deploy` + `secret put ENCRYPTION_KEY` 留給 richblack 執行
+  - `auth-dispatcher.ts` 的 `SUPPORTED_PRIMITIVES` 加入 `'service_account'`,workflow 用 google SA recipe 會自動走新 WASM 路徑
+- [ ] 2.6 端對端測試：google_sheets_sa recipe → 成功取得 access_token → 注入 header
+- [x] 2.7 **刪除 `lib/jwt-signer.ts` 整檔** — 2026-04-20 完成
+  - `cypher-executor/src/lib/jwt-signer.ts` 已刪除(RS256 JWT 邏輯移入 `auth_service_account.wasm`)
+  - `credential-injector.ts` 原 line 23 `import { exchangeGoogleJwt }` 移除
+  - `credential-injector.ts` 原 line 140-150 service_account 分支改為 throw(任何 service_account recipe 已被 auth-dispatcher 攔截;這條 TS fallback 若被觸發即表架構錯亂,直接爆錯比沈默解密更安全)
+  - `cypher-executor` tsc --noEmit 通過
+
+---
+
+## Phase 3：清理 component-loader 的 TS 實作（全刪）
+
+目標：`BUILTIN_API_RECIPES` 整段刪除，所有服務走 WASM runner（HTTP URL 路徑）。
+
+- [x] 3.1 確認 `http_request.wasm` / `gmail.wasm` / `telegram.wasm` / `line_notify.wasm` / `google_sheets.wasm` 都在 `registry/components/` 且可執行 — 2026-04-20 驗證 6 個(含 cron)全數存在,main.go + .wasm 齊備
+- [x] 3.2 確認上述零件 Worker 都已部署（`{name}.arcrun.dev` 可用） — 2026-04-20 完成**建置**部分
+  - 6 個 Worker 建置到位:`.component-builds/{http_request, gmail, telegram, line_notify, google_sheets, cron}/{wrangler.toml, package.json, tsconfig.json, src/index.ts, component.wasm}`
+  - 方案 A:5 個需 http_request 的零件(http_request/gmail/telegram/line_notify/google_sheets)`src/index.ts` 共用模板;cron 是純計算不註冊 host function
+  - 全部透過 `createWasiShim` 複用 cypher-executor/src/lib/wasi-shim.ts(rule 02 §2.2 邊界)
+  - 6 個 `wrangler deploy --dry-run` 全通過(~1.17 MB / ~413 KB gzip 每個);實際 `wrangler deploy` 留給 richblack 執行
+- [x] 3.3 `component-loader.ts` 的內建路徑改為查對應 Worker URL → HTTP POST — 2026-04-20 完成
+  - 原本第 7 層是 `BUILTIN_API_RECIPES` fallback、第 8 層是 `WASM_HTTP_RUNNER_IDS` (HTTP URL);兩層合併為第 7 層 `WASM_HTTP_RUNNER_IDS` 直接走 `makeHttpRunner(wasmWorkerUrl(id))`
+  - 解析鏈新編號 1-8,順序不變(外部 URL → recipe hash → component hash → R2 → Service Binding → auth recipe runner → WASM HTTP runner → 找不到)
+- [x] 3.4 **刪除 `BUILTIN_API_RECIPES` 整個 Record**（`http_request` / `gmail` / `telegram` / `line_notify` / `google_sheets` / `cron` 的 TS 實作全刪） — 2026-04-20 完成
+  - `cypher-executor/src/lib/component-loader.ts` 原 line 253-326 `BUILTIN_API_RECIPES` 常數 + fallback lookup 全刪(約 80 行)
+  - 全域搜尋確認:`gmail.googleapis.com/...messages/send` / `api.telegram.org/bot.*sendMessage` / `sheets.googleapis.com/v4/spreadsheets` / `notify-api.line.me/api/notify` 在 cypher-executor TS 中已不存在(auth-recipe-seeds.ts 的 `base_url` 是 recipe 資料欄位,不是 hard-coded API call)
+  - `cypher-executor` tsc --noEmit 通過
+- [ ] 3.5 端對端測試：workflow 用 gmail auth recipe + gmail.wasm Worker → 成功發信
+- [ ] 3.6 端對端測試：workflow 用 http_request.wasm Worker + auth_static_key 注入 → 成功呼叫任意 API
+
+---
+
+## Phase 4：auth_oauth2 + auth_mtls WASM（封測後）
+
+- [ ] 4.1 建立 `arcrun/registry/components/auth_oauth2/`
+- [ ] 4.2 實作：`needs_refresh` / `refresh` / `authenticate` 三個 action
+- [ ] 4.3 建立 `arcrun/registry/components/auth_mtls/`
+- [ ] 4.4 實作：輸出 TLS cert/key（實際 mTLS handshake 由 Worker runtime 執行，WASM 無法做 socket）
+
+---
+
+## Phase 5：封測啟動門檻 — 核心穩定驗證
+
+**全部通過才能啟動封測**。
+
+- [ ] 5.1 所有 20 個 auth recipe seed 可正常運作（static_key 17 個 + service_account 3 個）
+- [ ] 5.2 `cypher-executor/src/actions/credential-injector.ts` **不存在**
+- [ ] 5.3 `cypher-executor/src/lib/jwt-signer.ts` **不存在**
+- [ ] 5.4 `cypher-executor/src/lib/component-loader.ts` 無 `BUILTIN_API_RECIPES` / `BUILTIN_CREDENTIALS_MAP`
+- [ ] 5.5 `cypher-executor/src/` 全域搜尋 `crypto.subtle.decrypt` 只出現在 `wasi-shim.ts` 的 `crypto_decrypt` host function
+- [ ] 5.6 `cypher-executor/src/` 全域搜尋 `crypto.subtle.sign` 只出現在 `wasi-shim.ts` 的 `crypto_sign_rs256` host function
+- [ ] 5.7 `cypher-executor/src/` 全域搜尋 `interpolate` 回傳 0 筆（template 展開全在 WASM）
+- [ ] 5.8 全域搜尋 `{{secret\.` / `{{runtime\.` 在 TS 檔案中回傳 0 筆
+
+---
+
+## Phase 6:通用 CI/CD deploy workflow
+
+**背景**(2026-04-20 richblack 決定):現 `.github/workflows/deploy.yml` 只部署 cypher-executor + registry + 已刪除的 credentials,漏掉 Phase 1-3 產出的 8 個 Worker,且硬編碼每個 job 導致未來新增 Worker 都要改 CI。改為**通用掃描式 workflow**:任何含 `wrangler.toml` 的目錄 = 部署單位,改到該目錄下任何檔案 = 觸發重新 deploy。
+
+**關鍵決策**:
+- 零件 `.wasm` 由 CI build(不 commit):`registry/components/{name}/main.go` 改動時才重 build,用 timestamp / content hash 判斷
+- `.component-builds/{name}/component.wasm` 由 CI 從 `registry/components/{name}/{name}.wasm` 複製產生(deploy 前一步)
+- 統一用 pnpm(`.component-builds/*` 本來就是;順勢把 cypher-executor 的 `package-lock.json` 砍了)
+- runtime secret(`ENCRYPTION_KEY`)不進 CI,由 richblack 一次性 `wrangler secret put`
+- registry Worker 的 `wrangler.toml` 現階段不改(職責是合約管理,與封測無關;`sandboxAcceptance.ts` 的 rule 02 §2.2 審查留到 Phase 5 用戶自製零件啟動時)
+
+### Tasks
+
+- [x] 6.1 改寫 `.github/workflows/deploy.yml`:動態掃描所有含 `wrangler.toml` 的目錄(排除 `node_modules/` + Pages 專案),用 matrix job fanout 部署;分兩層(tier1=`.component-builds/*`,tier2=其他),tier1 全綠後才 tier2(避免 service binding target 未存在)
+- [x] 6.2 加上 TinyGo build 步驟:tier1 matrix 一律 setup-tinygo + 從 `registry/components/{name}/main.go` rebuild `.wasm` → copy 到 `.component-builds/{name}/component.wasm`
+- [x] 6.3 diff-aware:push 到 main 時比對 `github.event.before..github.sha`,只 deploy 有 diff 的 Worker(含 `registry/components/{name}/` 連動 `.component-builds/{name}/`);`workflow_dispatch` 提供 `force_all` + `only` 選項
+- [x] 6.4 統一 pnpm:刪除 `cypher-executor/package-lock.json` + `registry/package-lock.json`;workflow 優先 `pnpm install --frozen-lockfile`,若該目錄無 `pnpm-lock.yaml` 則 fallback 到 `--no-frozen-lockfile`(混合期容錯)
+- [x] 6.5 加 `max-parallel: 5` 控制 Workers API rate limit(tier1 和 tier2 各自)
+- [x] 6.6 驗證:`workflow_dispatch` + `force_all=true` 手動跑一次,24 個 Worker 全綠 — 2026-04-20 完成
+  - 最終綠色 run 24668903627(28/28 jobs,含 discover + summary):tier1 24 個零件 Worker + tier2 2 個 orchestration Worker(cypher-executor / registry)全 success
+  - 過程中修兩輪:先修 `setup-node` 的 `cache: 'pnpm'` 對 legacy `package-lock.json` 目錄失效(改為不用 cache);再修 tier2 三個 package.json(cypher-executor/registry/builtins)遺漏 `wrangler` devDependency + regen pnpm-lock.yaml
+  - ENCRYPTION_KEY secret 已由 richblack 授權、CC 從 .env pipe 到三個 Worker:`arcrun-auth-static-key`、`arcrun-auth-service-account`、`arcrun-cypher-executor`(不顯示內容)
+- [x] 6.7 文件:在 `.claude/rules/` 加一份 `05-deploy-convention.md`(「新增 Worker = 新目錄 + wrangler.toml,不用改 CI」)
+
+---
+
+## Phase 7：auth primitive 改走 service binding（解 self-hosted CF 1042）
+
+> 2026-06-06 richblack 拍板。來源：壓測報告階段 11（`test_arcrun/docs/壓測報告.md §11`）。
+
+**背景（架構演化）**：
+- 當初設想「用戶對每個服務建**零件**」→ 零件用 service binding 要 redeploy → 用戶建 workflow 要 redeploy（不可接受）→ 故禁 service binding、改 cypher binding（HTTP URL）。
+- 後來架構演化：用戶要的是 **recipe（資料，存 KV）+ 固定 primitive**，不是新零件。`acr recipe push` 進 KV **不 deploy**。用戶用「http_request primitive + 不同 recipe」打各種服務，永不新增 primitive。
+- 結論：「用戶建 workflow 要 deploy」這個禁令前提**在 recipe 模型下不成立**。primitive（http_request + 4 個 auth）是**平台固定基礎設施**，和 13 個邏輯零件同類，給它 service binding 的 deploy 成本只在平台部署時付一次，**不落用戶身上**。
+
+**根因（壓測階段 11，唯讀證據）**：
+- `auth-dispatcher.ts:67-68` 用 `fetch(wasmWorkerUrl('auth_service_account', WORKER_SUBDOMAIN))` 打 workers.dev → CF 回 **404 + "error code: 1042"**（CF 邊緣頁，非 auth worker 回應）。
+- **1042 精確定義（官方 docs，2026-06-06 查證）**：「Worker tried to fetch from another Worker **on the same zone**, only supported when `global_fetch_strictly_public` flag is used」。關鍵是 **same zone**：
+  - **self-hosted 踩**：cypher（`arcrun-cypher-executor.{sub}.workers.dev`）與 auth worker（`arcrun-auth-*.{sub}.workers.dev`）**同在 `{sub}.workers.dev` zone** → 同 zone fetch → 1042。
+  - **官方不踩**：官方 cypher 在自訂域 `cypher.arcrun.dev`，打 auth 的 `*.uncle6-me.workers.dev` 是**跨 zone**，不觸發 same-zone 限制（非「官方有 flag」——官方 wrangler.toml 只有 `nodejs_compat`，無 `global_fetch_strictly_public`）。
+  - 這是 P0#9「同 zone 522」的**另一形態**：之前解的是 `*.arcrun.dev` 同 zone，沒解到 `*.workers.dev` 同 zone。service binding 是內部 RPC 不經 zone → 徹底免疫（13 邏輯零件正是走 binding 才不踩）。
+- 直接從外部打 `arcrun-auth-service-account.leo21c.workers.dev` → 200 + 真 `ya29...` token → **JWT/解密/token 換取鏈本身全正常**，唯一卡點是 cypher 打不到自己帳號的 auth worker。
+- service binding 是 CF 內部 RPC，不經公網 → 同時繞開**同 zone 522（P0#9）**與**同帳號 workers.dev 子請求 1042**，比 workers.dev fetch 乾淨（13 邏輯零件正是用 binding 才不踩）。
+
+**技術前提（已驗證 ✅）**：
+- CF API 查 leo21c（全新自架帳號）的 `arcrun-cypher-executor` settings → **實綁 13 個 service binding**（SVC_SET→arcrun-set …）。證明 `deploy.ts` 的 binding 注入在 self-hosted 生效，auth binding 走同路綁得上。
+
+### 修法演進：A（service binding）→ 廢 → B（global_fetch_strictly_public flag）
+
+**先做了 A（service binding）後評估廢棄，改用 B（flag）**——richblack 2026-06-06 拍板。
+
+- **A（service binding）為何廢**：service binding 靜態，加/改要重 deploy cypher（官方 docs 證實）。richblack 判定不夠乾淨，且有更簡單的 B。
+- **B（`global_fetch_strictly_public` flag）為何對**：官方 docs——此 flag 讓 `fetch()` 走公網「前門」，**same-zone fetch 也能通**。cypher wrangler.toml 加一行即解，**用戶無感、不用域名、不用重 deploy、不動 service binding 禁令**。
+- **B 安全（查證官方 docs）**：唯一副作用是「Worker fetch 自己 hostname 會 self-loop」；cypher 只打外部 API + sibling auth worker（皆非自己 hostname）→ 不 self-loop。
+- **B 官方/self-host 共用**：官方 cypher 本就跨 zone，加 flag 行為不變；self-host 同 zone 被修好。同一份 toml 兩邊通用。
+- **評估但廢的他案**：arcrun.dev 子域給 self-host cypher——查證後子域同 zone（zone=註冊域名）照踩 1042，且跨帳號 route 落地等於 PaaS 轉向，廢。
+
+### Tasks
+
+- [x] 7.1 規範：`02-forbidden §3.1` / `03` / `CLAUDE.md` 鐵律4 / `pre-bash-guard 3.1`——**禁令維持原狀（不解禁 service binding）**，僅加註「same-zone 1042 用 flag 解」。（先前一度改成「平台 primitive 例外允許 binding」，因改用 B 已**全部還原**）
+- [x] 7.2 ~~hook 解禁~~ → **還原**：`pre-bash-guard.sh` 規則 3.1 回原本「禁止新增 service binding」（B 不需解禁）
+- [x] 7.3 `cypher-executor/wrangler.toml`：`compatibility_flags` 加 `global_fetch_strictly_public`（+ 註解病因/安全）。**移除先前加的 SVC_AUTH_***（grep SVC_AUTH=0）
+- [x] 7.4 `auth-dispatcher.ts` / `types.ts`：**還原**到 A 之前（移除 binding 優先邏輯與 SVC_AUTH_* 型別，回單純 `fetch(workers.dev)`——flag 讓它同 zone 也通）；tsc exit 0
+- [x] 7.5 `cli/src/lib/deploy.ts`：**無需改**——flag 在 cypher wrangler.toml，`stripOfficialOnlyBindings()` 不碰 `compatibility_flags`，self-hosted 部署自動帶上
+- [ ] 7.6 驗收（客觀證據）：全新自架帳號 `POST /webhooks/named/{ns}/{wf}/trigger` 讓 `append_row` 的 auth 注入回 200、真的寫進 Google Sheets（第一個端到端驗 self-hosted auth 鏈的測試）；`tsc --noEmit` exit 0
+- [x] 7.7 design.md 同步（§修改 auth-dispatcher 補「binding 優先、fetch fallback」+ 架構演化 + 1042 根因）：§修改 的 auth-dispatcher 補「binding 優先、fetch fallback」；記架構演化（recipe 取代零件 → primitive 可 binding）
+
+---
+
+## Phase 8：`{{credential.X}}` 用戶面注入語法（2026-06-10 richblack 確認 change，design §8）
+
+> 根因：壓測 401 = workflow 寫 `{{credential.X}}` 但三條 template 展開路徑都不認此 namespace。
+> 修法：auth_static_key 加 `resolve_credentials` action（WASM 解密），graph-executor 偵測+回填（不解密）。
+
+- [x] 8.1 `registry/components/auth_static_key/main.go`：input 加 `Names []string`；main 在 `service`
+      必填檢查**之前**分流 `action == "resolve_credentials"` → 走新 `handleResolveCredentials`（不查 recipe、
+      不要求 service），每個 name `kvGet("{api_key}:cred:{name}")` + `cryptoDecrypt` → 回
+      `{success, credentials:{name: plaintext}}`；缺 name → success:false + error 指明（不假綠）
+- [x] 8.2 `tinygo build -target=wasi -o auth_static_key.wasm main.go` 編譯通過（1.1MB）+ copy 到
+      `.component-builds/auth_static_key/component.wasm`
+- [x] 8.3 `cypher-executor/src/graph-executor.ts`：node.data interpolate 後、node 執行前，掃描殘留
+      `{{credential.NAME}}` → 有則 POST `wasmWorkerUrl('auth_static_key')`
+      `{action:"resolve_credentials", api_key, names}` → 回填 node.data。**不解密、不碰 ENCRYPTION_KEY**（rule 02 §2.2）
+      實作放 `auth-dispatcher.ts` 的 `resolveCredentialRefs`（遞迴掃描+回填，無 {{credential.}} 則零開銷不打 WASM），graph-executor 只呼叫
+- [x] 8.4 `tsc --noEmit` exit 0 + grep 確認 graph-executor / auth-dispatcher 無 crypto.subtle / {{secret. / ENCRYPTION_KEY 業務邏輯
+- [x] 8.5 端對端驗收：機制已實證打通（2026-06-13 leo21c 壓測）。實際走 **Notion** 而非 OpenAI 路徑——
+      node.data `{{credential.notion_token}}` → 注入解密後 token → 真讀到 Notion Recipes 資料
+      （「蕃茄蘑菇燉雞」+ iCook 連結），同時 401 假綠根治全鏈驗證（host fn error envelope →
+      零件 parsed["error"] → cypher isFailure()，401 回 success:false）。客觀證據：真服務 2xx + 真 body。
+      （8.5 原訂 OpenAI 為驗收服務，實際以 Notion 達成同等證據；機制與服務無關，故視為驗收完成）
+- [x] 8.6 design.md / status.md / BACKLOG.md 同步（§8 設計 + 8.1-8.4 done 標記）
+
+---
+
+## Notes
+
+- 方案 B 是唯一方案（方案 A 已廢棄，違反 CLAUDE.md §禁止行為）
+- Phase 8 的 `resolve_credentials` 是用戶面入口，與 authenticate（recipe 自動注入）並存不重疊
+- Phase 0.6（host functions）+ 0.7（WASM runner）是 Phase 1-3 的硬前置，必須先做
+- 若 TinyGo `encoding/base64` 可用就直接用；若不可用則自行實作（見 gmail/main.go 的 `base64URLEncode`）
+- `auth_mtls` 的 TLS handshake 無法在 WASM 內做（WASI preview1 沒 socket），只能輸出 cert/key 讓 Worker 在 fetch 時用
+- **每個 auth primitive WASM 都是獨立部署的 Worker**（透過 `component-worker-template/`），不是從 R2 動態載入
+- Cypher binding = workflow YAML 裡的 URL 清單，不是 Cloudflare service binding