# 壓測 Test Case — Recipe 公庫/私庫機制 + UUID（2026-06-07 deploy 後）

> ⚠️ 歷史記錄。文中 credential 相關步驟依據的舊自管金鑰機制已於 2026-07-20 完全移除，
> **勿照本文操作**；現行做法見 `.claude/rules/01-tech-stack.md`。

> 對象：本次上線的 kbdb-base §7.5（公庫/私庫雙向、UUID 身份、市場數據）+ 回歸。
>
> **操盤模型：全程 Haiku。Haiku 能搞定是「設計目標」不只是壓測手段（richblack 2026-06-07）。**
> 理由：arcrun 價值=比直接開發容易→用戶省 token+省時間+可重複用。若只有 Sonnet 能驅動 arcrun，
> 「省」就不成立（Sonnet 貴）。**Haiku 就能搞定才證明 arcrun 真降低門檻**。前瞻：未來要接 Gemini /
> 更弱模型門檻只會更高，現在用最弱的 Haiku 把介面磨到夠白痴化，未來接別的模型才不會更難。
>
> **∴ Haiku 撞牆 = 設計缺陷訊號（不是「換 Sonnet 解決」），撞牆點就是要修介面的地方。**
> 只有真的撞牆才**暫時**升 Sonnet 跑同一 case，用來判別「是介面問題（Haiku/Sonnet 都該過但 Haiku 過不了→修介面）
> vs 模型能力本質差異」。修完介面再用 Haiku 重測該 case。
> arcrun 是 AI 呼叫的工具 → 壓測打 floor 不打 ceiling。
>
> 介面：兩條都要測（CLI `acr` + MCP tools），驗薄殼一致性（rule 07 §5）。
> 判定原則（mindset §7）：完成=客觀證據（HTTP status / D1 數據 / 2xx），不是口頭宣布。

---

## Cold. 冷啟動：空專案 → 能跑（真實第一次體驗，最容易撞牆）— Haiku

> 真實起點：用戶在 VSCode 開一個**空白專案**，叫 Haiku「幫我做 X 工作」。
> 此時 **arcrun 沒裝、環境沒建、CF 沒設**。Haiku 要從零把環境建起來才談得上做事。
> 這是 self-hosted-init.md 流程的 dogfood。**裝不起來後面全白搭 → 這組是壓測 floor 的 floor。**
>
> 測法：給 Haiku 一句話需求（如「幫我做一個每天抓 RSS 存到 Google Sheet 的工作流」），
> **不給任何安裝指示**，看它能否自己摸出完整環境建置。觀察它卡在哪 = 介面要磨白痴化的地方。

| # | 觀察點 | 預期（Haiku 自己走通） | 判定（撞牆=介面缺陷） |
|---|--------|------|------|
| Cold.1 | Haiku 是否知道「要先裝 arcrun」 | 自己找到 `npm i -g arcrun` 或從 MCP/README 得知 | 卡 → 入口可發現性不足 |
| Cold.2 | 選模式：local / standard / self-hosted | Haiku 能依需求選對（要存 credential→standard/self-hosted；純試→local） | 卡 → `acr init` 模式說明不夠白痴 |
| Cold.3 | self-hosted 前置：wrangler 未裝時 | 錯訊「npm i -g wrangler 後重跑」→ Haiku 照做 | 卡 → 前置提示不可自癒 |
| Cold.4 | `acr init --self-hosted` 非互動參數 | Haiku 知道要帶 --account-id/--api-token（或被引導） | 卡 → 非互動路徑不明 |
| Cold.5 | 建 .env（NAMESPACE + ENCRYPTION_KEY） | Haiku 照「下一步①」生成 key 並寫 .env | 卡 → key 生成指令是否現成可抄 |
| Cold.6 | wrangler secret put ENCRYPTION_KEY | Haiku 照「下一步②」對各 worker 設 secret | 卡 → 多 worker 共用 key 是否講清楚（[[encryption-key-drift-trap]]） |
| Cold.7 | MCP / harness 安裝（acr mcp-setup / install-harness） | 自動或被引導補上 | 卡 → 補裝路徑是否被提示 |
| Cold.8 | 環境就緒後，Haiku 能接著做原始需求 | 不卡在環境、進入實際 workflow 建置 | **冷啟動到能做事的端到端卡點數** |

> **核心觀察**：Haiku 從「一句話需求 + 空專案」到「環境就緒能做事」，**全程靠 CLI 輸出 + 錯誤訊息 + MCP 工具描述自我引導**，
> 不靠人類補指示、不靠強模型腦補。每個卡點記下 = arcrun onboarding 要磨白痴化的清單。
> 非互動雷區：mindset §7「非 TTY 直跑就拒絕、不自塞 flag 假裝人類同意」——Haiku 遇到需人類確認處（建 CF 資源、暴露）
> 應停下請用戶確認，不自己偽造同意。測這個界線有沒有守住。

---

## 0. 前置 / 環境健康（回歸，每輪先跑）

| # | 操作 | 預期 | 判定 |
|---|------|------|------|
| 0.1 | `curl https://arcrun-kbdb.uncle6-me.workers.dev/health` | `{"ok":true}` | KBDB 活著 |
| 0.2 | `curl https://cypher.arcrun.dev/public-recipes?q=gmail` | `{found:true, recipes:[...]}` | 公庫端點上線 |
| 0.3 | `curl https://arcrun-kbdb.uncle6-me.workers.dev/recipe-stats/x` | `{success:true, stat:{...0}}` | D1 三表通 |

---

## A. 公庫搜尋 + 落空創作引導（§7.5.6）— Haiku

測「AI 找 recipe，公庫沒有時是否被正確引導去自己做」。

| # | 操作（CLI / MCP） | 預期 | 判定（暴露什麼） |
|---|------|------|------|
| A.1 | `acr recipe search gmail` / `arcrun_recipe_search{query:"gmail"}` | found:true，列 gmail_send 等，各帶 author/market_stat | 搜尋可用 |
| A.2 | 搜一個一定不存在的：`acr recipe search zzz_nonexistent_xyz` | **found:false + hint「可自己做一個投稿成為作者」** | **落空引導是否讓 AI 知道下一步**（不是回空陣列卡住） |
| A.3 | 接 A.2：操盤 AI 讀到 hint 後，**是否自己提議「那我做一個 recipe」** | AI 主動走向 push→submit-p（非停手說「找不到」） | **§7.5.6 閉環是否被 AI 接住**（這是核心壓測點） |

> A.3 是最關鍵的 Haiku 測點：弱模型若能靠 hint 自己走向創作，代表引導設計成功。

---

## B. 公→私 pull（§7.5.3 流1）— Haiku

| # | 操作 | 預期 | 判定 |
|---|------|------|------|
| B.1 | `acr recipe pull gmail_send` / `arcrun_recipe_pull{canonical_id:"gmail_send"}` | ✓ 拉進私庫，提示可用 component: gmail_send | pull 寫進私庫成功 |
| B.2 | `acr recipe list`（私庫）→ 應出現 gmail_send | 私庫有這筆 | pull 確實落地（不是只回成功訊息） |
| B.3 | pull 一個不存在的 `acr recipe pull zzz_nonexistent` | found:false + 創作引導 | pull 落空也引導（不報模糊錯誤） |
| B.4 | 指定作者 `acr recipe pull gmail_send --author=system` | 取 system 版本 | author 參數生效 |

---

## C. 私→公 submit-p + UUID 多作者並存（§7.5.5 app-store）— Haiku（撞牆才升 Sonnet 判別）

測 app-store 模型：同 canonical 多作者並存、submit=新增不覆蓋。

| # | 操作 | 預期 | 判定（暴露什麼） |
|---|------|------|------|
| C.1 | 建一個自製 recipe push 私庫（如 `my_test_api`，endpoint 指 httpbin.org/post） | ✓ 私庫有 | push 可用 |
| C.2 | `acr recipe submit-p my_test_api`（**需暴露同意**） | 提示暴露警示 → 同意後投稿公庫、領新 uuid | **暴露同意是否擋住**（mindset §6）；非互動/未同意是否拒絕 |
| C.3 | 第二次用**不同作者**再 submit-p 同 canonical（模擬 John 版） | 公庫**並存兩筆**同 canonical 不同 uuid/author（非覆蓋） | **app-store 模型驗證**：覆蓋 vs 新增 |
| C.4 | `acr recipe search my_test_api` | 回**多筆**同名不同作者，各帶 market_stat | 多作者並存可被搜到 |

---

## D. 市場數據 per-uuid（§7.5.h）— Haiku（要跑工作流；撞牆才升 Sonnet）

測「跑工作流 → recipe 成功/失敗記到 KBDB per-uuid → 影響市場選擇」。

| # | 操作 | 預期 | 判定 |
|---|------|------|------|
| D.1 | pull 一個能實打通的 recipe（或用 httpbin 自製），建 workflow，`acr run` 跑成功 | workflow 回 2xx | 工作流能跑 |
| D.2 | 跑完後 `curl kbdb/recipe-stats/{該 recipe uuid}` | success_count +1 | **5.1 成功記錄落 D1**（per-uuid 非 canonical） |
| D.3 | 故意讓 recipe 打不通（壞 endpoint）再跑，查 stat | failure_count +1 | 失敗也記、且區分 |
| D.4 | 同 canonical 兩作者版本各跑幾次成功率不同 → `recipe search` | market_stat 區分兩 uuid（不是同一份） | **§7.5.h per-uuid 真正生效**（Leo/John 可區分） |

---

## E. 回歸 — 既有能力沒被 UUID 改動破壞（§7.5.f 向後相容）— Haiku

UUID key 重構最大風險 = 破執行鏈。必測既有 recipe 執行不掛。

| # | 操作 | 預期 | 判定 |
|---|------|------|------|
| E.1 | 用一個既有種子 recipe（gmail/telegram）建 workflow `acr run` | 正常執行（resolveRecipe 向後相容） | **執行鏈沒被 key 重構破壞** |
| E.2 | `acr recipe list` 不出現重複（同 canonical 舊 key + uuid 兩筆） | dedup 正確 | GET dedup 生效 |
| E.3 | `acr recipe delete {某 recipe}` 後再 list | 該 recipe 消失、索引清乾淨 | DELETE 清 uuid+索引 |
| E.4 | 既有 workflow push/list/run（與 recipe 無關） | 全正常 | 沒波及無關功能 |

---

## F. 薄殼一致性（rule 07 §5）— Haiku

同一能力 CLI 和 MCP 走出**同樣結果**（驗薄殼不漂移）。

| # | 操作 | 預期 | 判定 |
|---|------|------|------|
| F.1 | `acr recipe search gmail` vs `arcrun_recipe_search{query:"gmail"}` | 兩者回**同一組** recipe | CLI/MCP 不漂移 |
| F.2 | CLI pull 後，MCP `arcrun_recipe_list` 看得到（反之亦然） | 同一私庫、同一帳號 | **帳號來源統一**（§5.3，self-hosted 帳號是否一致） |
| F.3 | MCP submit-p 的 exposure_consent 把關 = CLI 的暴露同意 | 兩者都擋未同意 | 暴露把關一致 |

> F.2 會踩到已知違反（§5.2 MCP account-source）：若 self-hosted 用 MCP 連到平台 cypher 而非自己的，
> CLI 和 MCP 會看到不同私庫 → **這是預期會暴露的問題**，記下不算 bug 是待修項。

---

## G. 邊界 / 異常（誠實性測試，mindset §7）— Haiku

| # | 操作 | 預期 | 判定 |
|---|------|------|------|
| G.1 | submit-p 缺 endpoint / 缺 canonical_id | 400 明確錯 | 不假綠、錯訊清楚 |
| G.2 | pull 後私庫改該 recipe 再 submit-p | author 變自己、不冒原作者（derived_from 溯源） | **不冒名**（§7.5.5） |
| G.3 | 缺 credential 的 recipe 跑 workflow | 誠實標「未驗收：缺 X」、401/403 不當 arcrun bug | 不 mock 假綠（mindset §3/§7） |
| G.4 | migrate-uuid 重跑一次 | skipped 全部、migrated 0（冪等） | 重跑安全 |

---

## 判定總表（壓測完填）

每個 case 標：✅ 通過（附證據：HTTP status / D1 數字 / 截圖）/ ⚠️ 暴露問題（描述）/ ❌ 失敗。
**禁假綠**：沒實際拿到 2xx/數據就標「未驗收：缺 X」，不口頭宣布通過。

**重點觀察（全程 Haiku）**：
0. **Cold.1-8 冷啟動：Haiku 從空專案能否自己把環境裝起來**？← floor 的 floor，裝不起來後面全白搭
1. A.3 落空→Haiku 是否自己走向創作（§7.5.6 閉環被接住）？← 設計目標核心
2. 錯誤訊息的 next_actions 是否讓 Haiku 自癒（不靠更強模型腦補）？
3. F.2 CLI/MCP 帳號是否一致（§5.2 已知違反會在此暴露）？
4. D.4 多作者市場數據是否真正區分？
5. 複雜多步（pull→改→submit-p→跑→看市場）Haiku 能否一氣呵成？

**撞牆處理**：Haiku 過不了某 case → 先判「是介面缺陷還是模型本質限制」：
暫時升 Sonnet 跑同一 case。Sonnet 過、Haiku 不過 → **介面缺陷**（修介面後 Haiku 重測）。
兩者都不過 → 功能 bug。記錄撞牆點 = arcrun 要磨白痴化的地方（前瞻 Gemini/更弱模型）。
