uncle6me-web
5d00e71275
頂層 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>
11 KiB
壓測 Test Case — Recipe 公庫/私庫機制 + UUID（2026-06-07 deploy 後）
對象：本次上線的 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，裝不起來後面全白搭
- A.3 落空→Haiku 是否自己走向創作（§7.5.6 閉環被接住）？← 設計目標核心
- 錯誤訊息的 next_actions 是否讓 Haiku 自癒（不靠更強模型腦補）？
- F.2 CLI/MCP 帳號是否一致（§5.2 已知違反會在此暴露）？
- D.4 多作者市場數據是否真正區分？
- 複雜多步（pull→改→submit-p→跑→看市場）Haiku 能否一氣呵成？
撞牆處理：Haiku 過不了某 case → 先判「是介面缺陷還是模型本質限制」： 暫時升 Sonnet 跑同一 case。Sonnet 過、Haiku 不過 → 介面缺陷（修介面後 Haiku 重測）。 兩者都不過 → 功能 bug。記錄撞牆點 = arcrun 要磨白痴化的地方（前瞻 Gemini/更弱模型）。