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>
This commit is contained in:
uncle6me-web
@@ -0,0 +1,286 @@
|
||||
# arcrun 封測指南
|
||||
|
||||
感謝你參與 arcrun 的封測。
|
||||
|
||||
arcrun 是一個讓 AI 和人都能直接讀寫、執行的 workflow 工具。
|
||||
你的任務是測試核心功能，並記錄任何不符合預期的地方。
|
||||
|
||||
---
|
||||
|
||||
## 環境安裝（5 分鐘）
|
||||
|
||||
```bash
|
||||
npm install -g arcrun
|
||||
acr --version # 應顯示 1.1.0 或以上
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 模式選擇
|
||||
|
||||
arcrun 有兩種使用模式：
|
||||
|
||||
### Local 模式（不需要帳號，快速試用）
|
||||
|
||||
```bash
|
||||
mkdir my-workflows && cd my-workflows
|
||||
acr init --local
|
||||
```
|
||||
|
||||
建立 `~/.arcrun/config.yaml`（local 模式）和一個 `hello.yaml` 範例。
|
||||
|
||||
```bash
|
||||
acr validate hello.yaml --offline
|
||||
acr run hello --input input="Hello, arcrun!"
|
||||
```
|
||||
|
||||
預期看到：`"result": "HELLO, ARCRUN!"`
|
||||
|
||||
### Standard 模式（需要 API Key，支援 Webhook 部署）
|
||||
|
||||
```bash
|
||||
acr init
|
||||
```
|
||||
|
||||
互動式設定，輸入 email 後自動取得 API Key，存入 `~/.arcrun/config.yaml`。
|
||||
|
||||
---
|
||||
|
||||
## 零件清單
|
||||
|
||||
執行以下指令查看所有可用零件：
|
||||
|
||||
```bash
|
||||
acr parts
|
||||
```
|
||||
|
||||
取得單一零件的 config 範本：
|
||||
|
||||
```bash
|
||||
acr parts scaffold string_ops
|
||||
acr parts scaffold http_request
|
||||
acr parts scaffold gmail # 含 credentials.yaml 範本
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 可用零件（21 個，不需要帳號）
|
||||
|
||||
### 字串操作 — `string_ops`
|
||||
|
||||
```yaml
|
||||
config:
|
||||
my_node:
|
||||
component: string_ops
|
||||
operation: upper # upper / lower / trim / length / replace / split / join
|
||||
```
|
||||
|
||||
### 數字運算 — `number_ops`
|
||||
|
||||
```yaml
|
||||
config:
|
||||
my_node:
|
||||
component: number_ops
|
||||
operation: add
|
||||
b: 10 # 加上 10
|
||||
```
|
||||
|
||||
支援：`add` / `sub` / `mul` / `div` / `round` / `floor` / `ceil` / `abs`
|
||||
|
||||
### HTTP 請求 — `http_request`
|
||||
|
||||
```yaml
|
||||
config:
|
||||
my_node:
|
||||
component: http_request
|
||||
method: GET # GET / POST / PUT / DELETE
|
||||
```
|
||||
|
||||
```bash
|
||||
acr run notify --input url="https://httpbin.org/get"
|
||||
```
|
||||
|
||||
### 其他零件
|
||||
|
||||
```
|
||||
if_control 條件分支（ON_SUCCESS / ON_FAIL 路由）
|
||||
switch 多分支條件
|
||||
foreach_control 迭代陣列
|
||||
filter 過濾陣列
|
||||
set 設定固定值到 context
|
||||
array_ops 陣列操作（push / pop / slice）
|
||||
date_ops 日期操作（now / format / diff）
|
||||
validate_json 驗證 JSON Schema
|
||||
ai_transform_compile / ai_transform_run AI 自然語言轉換
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 動態參數 `{{variable}}`
|
||||
|
||||
config 裡的字串欄位支援 `{{variable}}`，從 `--input` 取值：
|
||||
|
||||
```yaml
|
||||
# flexible.yaml
|
||||
name: flexible
|
||||
flow:
|
||||
- "input >> ON_SUCCESS >> process"
|
||||
config:
|
||||
process:
|
||||
component: string_ops
|
||||
operation: "{{op}}"
|
||||
```
|
||||
|
||||
```bash
|
||||
acr run flexible --input input="hello" --input op=upper # → HELLO
|
||||
acr run flexible --input input="HELLO" --input op=lower # → hello
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 錯誤路由（ON_FAIL）
|
||||
|
||||
```yaml
|
||||
# safe-fetch.yaml
|
||||
name: safe-fetch
|
||||
flow:
|
||||
- "input >> ON_SUCCESS >> fetch"
|
||||
- "fetch >> ON_FAIL >> fallback"
|
||||
config:
|
||||
fetch:
|
||||
component: http_request
|
||||
method: GET
|
||||
fallback:
|
||||
component: string_ops
|
||||
operation: upper
|
||||
```
|
||||
|
||||
```bash
|
||||
# 故意讓 fetch 失敗，觸發 fallback
|
||||
acr run safe-fetch \
|
||||
--input url="https://invalid.domain.xyz" \
|
||||
--input input="fallback triggered"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 中文語意
|
||||
|
||||
flow 支援中文關係詞：
|
||||
|
||||
```yaml
|
||||
flow:
|
||||
- "輸入 >> 完成後 >> 轉換"
|
||||
- "轉換 >> 失敗時 >> 錯誤處理"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Webhook 部署（Standard 模式）
|
||||
|
||||
讓外部網頁或服務能觸發你的 workflow：
|
||||
|
||||
```bash
|
||||
# 部署 workflow
|
||||
acr push my-workflow.yaml
|
||||
```
|
||||
|
||||
輸出範例：
|
||||
```
|
||||
✓ "my-workflow" 已部署
|
||||
|
||||
Webhook URL：https://cypher.arcrun.dev/webhooks/named/my-workflow/trigger
|
||||
需帶 Header：X-Arcrun-API-Key: ak_...
|
||||
|
||||
curl 觸發範例：
|
||||
curl -X POST https://cypher.arcrun.dev/webhooks/named/my-workflow/trigger \
|
||||
-H 'X-Arcrun-API-Key: ak_your-key' \
|
||||
-H 'Content-Type: application/json' \
|
||||
-d '{"message": "hello"}'
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## API Recipe（整合外部服務）
|
||||
|
||||
不需要 deploy Worker，只要上傳 recipe YAML：
|
||||
|
||||
```bash
|
||||
acr recipe push my-recipe.yaml
|
||||
acr recipe list
|
||||
acr recipe delete rec_xxxxxxxx
|
||||
```
|
||||
|
||||
Recipe 上傳後會得到 `rec_xxxxxxxx` hash，可直接在 workflow config 的 `component` 欄位使用。
|
||||
|
||||
---
|
||||
|
||||
## Credential 管理（Standard 模式）
|
||||
|
||||
需要帶 token 的零件（gmail、telegram、notion 等）可以提前上傳 credential，執行 workflow 時自動注入。
|
||||
|
||||
**加密金鑰在 `acr init` 時已自動取得並存入 `~/.arcrun/config.yaml`，不需要手動設定。**
|
||||
|
||||
**步驟一：查看某服務需要哪些 credential**
|
||||
|
||||
```bash
|
||||
acr auth-recipe scaffold notion # 輸出 credentials.yaml 範本 + workflow 使用範例
|
||||
acr auth-recipe list # 列出所有支援的服務（20 個）
|
||||
```
|
||||
|
||||
**步驟二：建立 credentials.yaml**（參考 scaffold 的輸出）：
|
||||
|
||||
```yaml
|
||||
# 範例：Notion
|
||||
notion_token: "secret_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
|
||||
|
||||
# 範例：Telegram Bot
|
||||
telegram_bot_token: "123456789:your-bot-token"
|
||||
```
|
||||
|
||||
**步驟三：上傳**：
|
||||
```bash
|
||||
acr creds push credentials.yaml
|
||||
```
|
||||
|
||||
上傳後執行 workflow 時，tokens 自動注入，不需要在 `--input` 手動帶。
|
||||
|
||||
### 支援的第三方服務（20 個）
|
||||
|
||||
```bash
|
||||
acr auth-recipe list
|
||||
```
|
||||
|
||||
輸出：Notion、Slack、GitHub、OpenAI、Anthropic、Airtable、Discord、Stripe、Twilio、SendGrid、HubSpot、Linear、Shopify、Resend、Supabase、Typeform、Jira、Google Sheets（Service Account）、Gmail（Service Account）、Google Drive（Service Account）
|
||||
|
||||
---
|
||||
|
||||
## 回饋格式
|
||||
|
||||
請把你的觀察記錄在 `FEEDBACK.md`，格式不限，但希望包含：
|
||||
|
||||
1. **成功的地方** — 哪些功能符合預期？
|
||||
2. **失敗的地方** — 錯誤訊息是什麼？步驟是？
|
||||
3. **困惑的地方** — 不知道怎麼用、文件不清楚的地方
|
||||
4. **想要的功能** — 你覺得少了什麼
|
||||
|
||||
---
|
||||
|
||||
## 已知限制
|
||||
|
||||
- `number_ops` 的數字參數（`a`、`b`）若從 `--input` 帶入為字串，需要零件自行做型別轉換（目前已支援）
|
||||
- `ON_FAIL` 觸發時，fallback 節點收到的 context 包含上游的錯誤物件（`{success: false, ...}`）
|
||||
- 多節點串連時，context 為 flat merge，上游的 `data.result` 會直接合併到頂層
|
||||
- `if_control` 條件為 false 時，不執行任何下游節點（沒有明確的 else 分支）
|
||||
|
||||
---
|
||||
|
||||
## 有問題？
|
||||
|
||||
遇到任何問題直接問。你的 API Key 是確定性的，只要用同一個 email 呼叫 `/register` 就能拿回來：
|
||||
|
||||
```bash
|
||||
curl -X POST https://cypher.arcrun.dev/register \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{"email":"your@email.com"}'
|
||||
```
|
||||
@@ -0,0 +1,72 @@
|
||||
# 交付前自測 Checklist（pre-customer）— 2026-06-07
|
||||
|
||||
> 給 **你（人）** 在交給客戶前跑一次的精簡清單，不是給 Haiku 操盤的詳細壓測（那份在
|
||||
> 壓測-recipe-library-2026-06-07.md）。順序照客戶真實旅程。**任一項 ❌ = 不能交付。**
|
||||
> 過關標準都是客觀證據（HTTP 2xx / D1 數字 / 檔案存在），禁口頭過關。
|
||||
|
||||
---
|
||||
|
||||
## 1. 雲端後端活著（最快，先確認 deploy 沒掛）
|
||||
|
||||
- [ ] `curl https://arcrun-kbdb.uncle6-me.workers.dev/health` → `{"ok":true}`
|
||||
- [ ] `curl https://cypher.arcrun.dev/public-recipes?q=gmail` → `{"found":true,...}`
|
||||
- [ ] `curl https://cypher.arcrun.dev/health`（或任一既有端點）→ 200
|
||||
- [ ] npm 上有最新 CLI：`npm view arcrun version` → 1.3.2（或更新）
|
||||
|
||||
## 2. 冷啟動：空專案能裝起來（客戶第一步）
|
||||
|
||||
- [ ] 開**空目錄**，`npm i -g arcrun` → `acr --version` 出版本
|
||||
- [ ] `acr init`（local 模式）→ 不報錯、寫出 config
|
||||
- [ ] 跟著它印的「下一步」跑 hello workflow → `acr run hello` 有輸出
|
||||
- [ ] （self-hosted 路徑）`acr init --self-hosted` 無 wrangler 時 → 錯訊清楚教裝 wrangler
|
||||
|
||||
## 3. 環境設定（self-hosted，客戶要用自己 CF）
|
||||
|
||||
- [ ] `acr init --self-hosted --account-id X --api-token Y` → 建 KV + D1 + deploy 成功
|
||||
- [ ] 印出的「下一步①②」可照抄：.env（NAMESPACE+ENCRYPTION_KEY）+ wrangler secret put
|
||||
- [ ] D1 建出來且套了 migration（`/recipe-stats/x` 回 stat 結構）
|
||||
- [ ] 免綁卡（全程沒被要信用卡）
|
||||
|
||||
## 4. Recipe 公庫/私庫（本次新功能，重點測）
|
||||
|
||||
- [ ] `acr recipe search gmail` → 列出 recipe 含 author/market_stat
|
||||
- [ ] `acr recipe search 不存在的xyz` → found:false + 創作引導 hint
|
||||
- [ ] `acr recipe pull gmail_send` → 拉進私庫；`acr recipe list` 看得到
|
||||
- [ ] 自製 recipe `acr recipe push` → 私庫有
|
||||
- [ ] `acr recipe submit-p <id>` → **跳暴露同意**（未同意/非互動擋住），同意後投稿成功
|
||||
- [ ] 同 canonical 不同作者 submit-p 兩次 → 公庫並存兩筆（非覆蓋）
|
||||
|
||||
## 5. 做一件真實的事（端到端，客戶的目的）
|
||||
|
||||
- [ ] 建一個真實 workflow（如 webhook → http_request → 輸出），`acr push` + `acr run` 跑通回 2xx
|
||||
- [ ] 用到 recipe 的 workflow 跑完 → `curl kbdb/recipe-stats/{uuid}` success_count +1
|
||||
- [ ] 缺 credential 時 → 誠實標「未驗收：缺 X」，不假裝成功（401/403 不當 bug）
|
||||
|
||||
## 6. 兩介面一致（CLI + MCP，AI 客戶會用 MCP）
|
||||
|
||||
- [ ] MCP 已裝（`acr mcp-setup` 或 init 自動）→ `.mcp.json` 存在
|
||||
- [ ] MCP `arcrun_recipe_search` 回的 = CLI `acr recipe search` 回的（同一組）
|
||||
- [ ] CLI pull 後 MCP `arcrun_recipe_list` 看得到（同一私庫帳號）
|
||||
⚠️ 若 self-hosted 的 MCP 連到平台而非自己 cypher → 記下（§5.2 已知違反待修）
|
||||
|
||||
## 7. 回歸（沒把舊功能弄壞）
|
||||
|
||||
- [ ] 既有種子 recipe（gmail/telegram）的 workflow 跑通（UUID 重構沒破執行鏈）
|
||||
- [ ] `acr recipe list` 無重複項（同 canonical 舊 key+uuid 兩筆）
|
||||
- [ ] 既有 workflow push/list/run 全正常
|
||||
|
||||
## 8. 誠實性 / 安全界線（交付前必守）
|
||||
|
||||
- [ ] 暴露動作（submit-p / push webhook）都有人類明示同意關卡
|
||||
- [ ] 非互動環境（你直跑）→ 需確認處會停下，不自己偽造同意
|
||||
- [ ] 任何「未實作/缺 credential」誠實回 success:false 或標未驗收，無假綠
|
||||
|
||||
---
|
||||
|
||||
## 交付判定
|
||||
|
||||
- 全 ✅ → 可交付。
|
||||
- 任一 ❌ → 修掉再交（記下是哪項）。
|
||||
- ⚠️（已知違反，如 §5.2 MCP account-source）→ 寫進交付說明的「已知限制」，不假裝沒有。
|
||||
|
||||
**禁假綠**：沒實際看到證據的項目標「未測」，不要勾 ✅。
|
||||
@@ -0,0 +1,162 @@
|
||||
# 壓測 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，裝不起來後面全白搭
|
||||
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/更弱模型）。
|
||||
Reference in New Issue
Block a user