test

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Plan mode: If you are planning work, this entire skill is ONE plan step: "Invoke /vibes:test". Do not decompose the steps below into separate plan tasks.

规划模式：如果你正在规划工作，整个技能仅作为一个规划步骤："调用 /vibes:test"。请勿将以下步骤拆分为单独的规划任务。

Integration Test Skill

集成测试技能

Orchestrates the full test pipeline: credentials → Connect studio → fixture assembly → Cloudflare deploy → live URL → unit tests.

Working directory:

test-vibes/

(gitignored, persists across runs)

统筹完整测试流程：凭证配置 → Connect Studio → 测试夹具组装 → Cloudflare部署 → 在线URL生成 → 单元测试。

工作目录：

test-vibes/

（已加入git忽略，跨运行会话持久保存）

Phase 1: Credentials

阶段1：凭证配置

Check if

test-vibes/.env

exists and has Clerk keys.

bash

undefined

检查

test-vibes/.env

是否存在且包含Clerk密钥。

bash

undefined

From the plugin root

从插件根目录执行

cat test-vibes/.env 2>/dev/null


**If the file exists and contains `VITE_CLERK_PUBLISHABLE_KEY`:**

AskUserQuestion: Question: "Reuse existing test credentials? (publishable key: pk_test_...)" Header: "Credentials" Options:

Label: "Yes, reuse" Description: "Use the Clerk keys already in test-vibes/.env"
Label: "No, enter new keys" Description: "I want to use different Clerk credentials"


**If the file doesn't exist or keys are missing, or user wants new keys:**

AskUserQuestion: Question: "Paste your Clerk Publishable Key (starts with pk_test_ or pk_live_)" Header: "Clerk PK" Options:

Label: "I need to get keys first" Description: "I'll go to clerk.com and come back"


If they need keys, tell them:
> Go to [clerk.com](https://clerk.com) → your application → API Keys → copy Publishable Key and Secret Key.

Then ask for the secret key:

AskUserQuestion: Question: "Paste your Clerk Secret Key (starts with sk_test_ or sk_live_)" Header: "Clerk SK"


Write `test-vibes/.env`:

VITE_CLERK_PUBLISHABLE_KEY=<key> VITE_CLERK_SECRET_KEY=<key>

undefined

cat test-vibes/.env 2>/dev/null


**如果文件存在且包含`VITE_CLERK_PUBLISHABLE_KEY`：**

AskUserQuestion: Question: "是否复用现有测试凭证？（可发布密钥：pk_test_...）" Header: "凭证配置" Options:

Label: "是，复用" Description: "使用test-vibes/.env中已有的Clerk密钥"
Label: "否，输入新密钥" Description: "我想使用其他Clerk凭证"


**如果文件不存在、密钥缺失，或用户选择输入新密钥：**

AskUserQuestion: Question: "粘贴你的Clerk可发布密钥（以pk_test_或pk_live_开头）" Header: "Clerk可发布密钥" Options:

Label: "我需要先获取密钥" Description: "我将前往clerk.com获取后返回"


如果用户需要获取密钥，告知：
> 前往 [clerk.com](https://clerk.com) → 你的应用 → API密钥 → 复制可发布密钥和密钥密钥。

然后请求密钥密钥：

AskUserQuestion: Question: "粘贴你的Clerk密钥密钥（以sk_test_或sk_live_开头）" Header: "Clerk密钥密钥"


写入`test-vibes/.env`：

VITE_CLERK_PUBLISHABLE_KEY=<key> VITE_CLERK_SECRET_KEY=<key>

undefined

Phase 2: Connect Studio

阶段2：Connect Studio配置

Check if

test-vibes/.connect

exists (marks a deployed studio).

bash

cat test-vibes/.connect 2>/dev/null

If
.connect
exists: Read the studio name and API/Cloud URLs. Confirm reuse:

AskUserQuestion:
  Question: "Reuse existing Connect studio '<name>'?"
  Header: "Connect"
  Options:
  - Label: "Yes, reuse"
    Description: "Studio is already running"
  - Label: "No, deploy fresh"
    Description: "Deploy a new Connect studio"

If
.connect
doesn't exist or user wants fresh deploy:

Run the deploy script. Read the Clerk keys from

test-vibes/.env

first:

bash

node scripts/deploy-connect.js \
  --studio vibes-test-studio \
  --clerk-publishable-key "$VITE_CLERK_PUBLISHABLE_KEY" \
  --clerk-secret-key "$VITE_CLERK_SECRET_KEY"

After deploy, save the studio info:

bash

undefined

检查

test-vibes/.connect

是否存在（标记已部署的Studio）。

bash

cat test-vibes/.connect 2>/dev/null

**如果

.connect

存在：**读取Studio名称和API/Cloud URL，确认是否复用：

AskUserQuestion:
  Question: "是否复用现有Connect Studio '<name>'？"
  Header: "Connect配置"
  Options:
  - Label: "是，复用"
    Description: "Studio已在运行"
  - Label: "否，重新部署"
    Description: "部署新的Connect Studio"

如果
.connect
不存在，或用户选择重新部署：

运行部署脚本。先从

test-vibes/.env

读取Clerk密钥：

bash

node scripts/deploy-connect.js \
  --studio vibes-test-studio \
  --clerk-publishable-key "$VITE_CLERK_PUBLISHABLE_KEY" \
  --clerk-secret-key "$VITE_CLERK_SECRET_KEY"

部署完成后，保存Studio信息：

bash

undefined

Write connect marker

写入Connect标记文件

echo "vibes-test-studio" > test-vibes/.connect


Update `test-vibes/.env` with the Connect URLs:

VITE_API_URL=https://vibes-test-studio.exe.xyz/api VITE_CLOUD_URL=fpcloud://vibes-test-studio.exe.xyz?protocol=wss

undefined

echo "vibes-test-studio" > test-vibes/.connect


更新`test-vibes/.env`中的Connect URL：

VITE_API_URL=https://vibes-test-studio.exe.xyz/api VITE_CLOUD_URL=fpcloud://vibes-test-studio.exe.xyz?protocol=wss

undefined

Phase 3: Fixture Selection

阶段3：测试夹具选择

AskUserQuestion:
  Question: "Which fixture to test?"
  Header: "Fixture"
  Options:
  - Label: "fireproof-basic (Recommended)"
    Description: "Fireproof CRUD with React singleton — the standard integration test"
  - Label: "minimal"
    Description: "Template + Babel + import map only — fastest, no Fireproof"
  - Label: "sell-ready"
    Description: "useTenant() + multi-tenant routing — tests sell assembly path"
  - Label: "ai-proxy"
    Description: "/api/ai/chat endpoint + CORS — requires OpenRouter key"

For sell-ready fixture: Check

test-vibes/.env

for a cached admin user ID from a previous run:

bash

grep CLERK_ADMIN_USER_ID test-vibes/.env 2>/dev/null

If found, offer to reuse it (mask the middle of the value in the prompt, e.g.,

user_37ici...ohcY

AskUserQuestion:
  Question: "Reuse stored admin user ID? (user_37ici...ohcY)"
  Header: "Admin ID"
  Options:
  - Label: "Yes, reuse"
    Description: "Use the cached user ID from test-vibes/.env"
  - Label: "Skip admin"
    Description: "Deploy without admin — you can set it up after deploy"

If "Yes, reuse": use the stored value in Phase 4 assembly. If "Skip admin": omit

--admin-ids

in Phase 4. Admin setup will be offered post-deploy in Phase 5.5.

If not found: No prompt needed. Admin will be set up post-deploy in Phase 5.5 after the user has a chance to sign up on the live app.

AskUserQuestion:
  Question: "选择要测试的夹具？"
  Header: "测试夹具"
  Options:
  - Label: "fireproof-basic（推荐）"
    Description: "基于React单例的Fireproof CRUD操作——标准集成测试"
  - Label: "minimal"
    Description: "仅包含模板+Babel+导入映射——速度最快，无Fireproof"
  - Label: "sell-ready"
    Description: "useTenant() + 多租户路由——测试销售组装流程"
  - Label: "ai-proxy"
    Description: "/api/ai/chat端点 + CORS——需要OpenRouter密钥"

**针对sell-ready夹具：**检查

test-vibes/.env

中是否存在之前运行缓存的管理员用户ID：

bash

grep CLERK_ADMIN_USER_ID test-vibes/.env 2>/dev/null

如果存在，提供复用选项（在提示中隐藏中间部分，例如

user_37ici...ohcY

）：

AskUserQuestion:
  Question: "是否复用已存储的管理员用户ID？（user_37ici...ohcY）"
  Header: "管理员ID"
  Options:
  - Label: "是，复用"
    Description: "使用test-vibes/.env中缓存的用户ID"
  - Label: "跳过管理员配置"
    Description: "部署时不配置管理员——可在部署后设置"

如果选择"是，复用"：在阶段4组装时使用存储的值。如果选择"跳过管理员配置"：在阶段4中省略

--admin-ids

参数，管理员设置将在阶段5.5的部署后流程中提供。

如果不存在：无需提示。管理员将在阶段5.5的部署后流程中配置，用户可先在在线应用完成注册。

Phase 3.5: Sell Configuration (sell-ready only)

阶段3.5：销售配置（仅针对sell-ready）

Condition: Only runs when the user selected

sell-ready

in Phase 3.

Ask billing mode:

AskUserQuestion:
  Question: "Which billing mode should this sell test use?"
  Header: "Billing"
  Options:
  - Label: "Free (billing off)"
    Description: "Claims work without payment — tests auth + tenant routing only"
  - Label: "Billing required"
    Description: "Claims require active Clerk subscription — tests full paywall flow"

If "Free": Store

BILLING_MODE=off

test-vibes/.env

. Skip webhook setup. Proceed to Phase 4.

If "Billing required": Store

BILLING_MODE=required

test-vibes/.env

. Then guide webhook setup:

AskUserQuestion:
  Question: "Set up the Clerk webhook for billing:\n\n1. Go to clerk.com → your app → Webhooks → Add Endpoint\n2. URL: https://vibes-test.<account>.workers.dev/webhook\n3. Subscribe to: subscription.deleted\n4. Copy the Signing Secret (starts with whsec_)\n\nPaste the webhook signing secret:"
  Header: "Webhook"
  Options:
  - Label: "I need help"
    Description: "Walk me through the Clerk webhook setup"

If "I need help": walk them through each step in the Clerk dashboard, then re-ask the question.

Validate the secret starts with

whsec_

. If not, ask again with a note that it should start with

whsec_

Store as

CLERK_WEBHOOK_SECRET

test-vibes/.env

bash

grep -q CLERK_WEBHOOK_SECRET test-vibes/.env 2>/dev/null && \
  sed -i '' 's/^CLERK_WEBHOOK_SECRET=.*/CLERK_WEBHOOK_SECRET=<secret>/' test-vibes/.env || \
  echo "CLERK_WEBHOOK_SECRET=<secret>" >> test-vibes/.env

Proceed to Phase 4.

触发条件：仅当用户在阶段3中选择

sell-ready

时运行。

询问计费模式：

AskUserQuestion:
  Question: "本次销售测试使用哪种计费模式？"
  Header: "计费设置"
  Options:
  - Label: "免费（关闭计费）"
    Description: "无需付费即可使用——仅测试认证+租户路由"
  - Label: "需计费"
    Description: "使用需激活Clerk订阅——测试完整付费墙流程"

**如果选择"免费"：**在

test-vibes/.env

中存储

BILLING_MODE=off

，跳过Webhook设置，进入阶段4。

**如果选择"需计费"：**在

test-vibes/.env

中存储

BILLING_MODE=required

，然后引导配置Webhook：

AskUserQuestion:
  Question: "配置Clerk计费Webhook：\n\n1. 前往clerk.com → 你的应用 → Webhooks → 添加端点\n2. URL：https://vibes-test.<account>.workers.dev/webhook\n3. 订阅事件：subscription.deleted\n4. 复制签名密钥（以whsec_开头）\n\n粘贴Webhook签名密钥："
  Header: "Webhook配置"
  Options:
  - Label: "需要帮助"
    Description: "引导我完成Clerk Webhook配置步骤"

如果选择"需要帮助"：逐步引导用户在Clerk控制台完成操作，然后重新询问密钥。

验证密钥是否以

whsec_

开头。如果不是，重新询问并提示密钥应以此开头。

将密钥存储到

test-vibes/.env

的

CLERK_WEBHOOK_SECRET

中：

bash

grep -q CLERK_WEBHOOK_SECRET test-vibes/.env 2>/dev/null && \
  sed -i '' 's/^CLERK_WEBHOOK_SECRET=.*/CLERK_WEBHOOK_SECRET=<secret>/' test-vibes/.env || \
  echo "CLERK_WEBHOOK_SECRET=<secret>" >> test-vibes/.env

进入阶段4。

Phase 4: Assembly

阶段4：测试夹具组装

Copy the selected fixture and assemble:

bash

undefined

复制选中的夹具并完成组装：

bash

undefined

Copy fixture to working directory

将夹具复制到工作目录

cp scripts/tests/fixtures/<fixture>.jsx test-vibes/app.jsx

Source env for assembly

加载环境变量用于组装

set -a && source test-vibes/.env && set +a


**For sell-ready fixture:**
```bash
node scripts/assemble-sell.js test-vibes/app.jsx test-vibes/index.html \
  --domain vibes-test.<account>.workers.dev \
  --admin-ids '["<admin-user-id>"]'  # read CLERK_ADMIN_USER_ID from test-vibes/.env

If admin was skipped, omit

--admin-ids

. The

--domain

flag is always required.

For all other fixtures:

bash

node scripts/assemble.js test-vibes/app.jsx test-vibes/index.html

Validate the output (same checks as the vitest suite):

File exists and is non-empty
No
```
__PLACEHOLDER__
```
strings remain
Import map
```
<script type="importmap">
```
is present
```
<script type="text/babel">
```
contains the fixture code
For sell-ready:
```
getRouteInfo
```
function is present

If any check fails, report the error, then ask:

AskUserQuestion:
  Question: "What next?"
  Header: "Next"
  Options:
  - Label: "Test another fixture"
    Description: "Go back to Phase 3 and pick a different fixture"
  - Label: "End test session"
    Description: "Clean up artifacts and finish"

If "Test another fixture": go to Phase 3. If "End test session": go to Phase 11.

set -a && source test-vibes/.env && set +a


**针对sell-ready夹具：**
```bash
node scripts/assemble-sell.js test-vibes/app.jsx test-vibes/index.html \
  --domain vibes-test.<account>.workers.dev \
  --admin-ids '["<admin-user-id>"]'  # 从test-vibes/.env读取CLERK_ADMIN_USER_ID

如果跳过了管理员配置，省略

--admin-ids

参数。

--domain

参数为必填项。

针对其他所有夹具：

bash

node scripts/assemble.js test-vibes/app.jsx test-vibes/index.html

验证输出（与Vitest套件的检查逻辑一致）：

文件存在且非空
无
```
__PLACEHOLDER__
```
字符串残留
存在导入映射
```
<script type="importmap">
```
```
<script type="text/babel">
```
包含夹具代码
针对sell-ready：存在
```
getRouteInfo
```
函数

如果任何检查失败，报告错误，然后询问：

AskUserQuestion:
  Question: "下一步操作？"
  Header: "后续选择"
  Options:
  - Label: "测试其他夹具"
    Description: "返回阶段3选择其他夹具"
  - Label: "结束测试会话"
    Description: "清理工件并结束"

如果选择"测试其他夹具"：返回阶段3。如果选择"结束测试会话"：进入阶段11。

Phase 5: Deploy to Cloudflare

阶段5：部署到Cloudflare

For ai-proxy fixture: Check

~/.vibes/.env

for a cached OpenRouter key first:

bash

grep OPENROUTER_API_KEY ~/.vibes/.env 2>/dev/null

If found, offer to reuse it (mask the key, e.g.,

sk-or-v1-...a3b2

AskUserQuestion:
  Question: "Reuse stored OpenRouter API key? (sk-or-v1-...a3b2)"
  Header: "AI Key"
  Options:
  - Label: "Yes, reuse"
    Description: "Use the cached key from ~/.vibes/.env"
  - Label: "Enter new"
    Description: "I'll paste a different key"
  - Label: "Skip AI proxy"
    Description: "Deploy without AI endpoint"

If "Yes, reuse": use the stored value. If "Enter new": collect via the prompt below, then update

~/.vibes/.env

If not found (or user chose "Enter new"):

AskUserQuestion:
  Question: "Paste your OpenRouter API key for the AI proxy"
  Header: "AI Key"
  Options:
  - Label: "Skip AI proxy"
    Description: "Deploy without AI endpoint"

After collecting a new key, offer to save it:

AskUserQuestion:
  Question: "Save this OpenRouter key to ~/.vibes/.env for future projects?"
  Header: "Cache"
  Options:
  - Label: "Yes, save"
    Description: "Cache the key so you don't have to paste it again"
  - Label: "No, skip"
    Description: "Use for this session only"

If "Yes, save":

bash

mkdir -p ~/.vibes
grep -q OPENROUTER_API_KEY ~/.vibes/.env 2>/dev/null && \
  sed -i '' 's/^OPENROUTER_API_KEY=.*/OPENROUTER_API_KEY=<new>/' ~/.vibes/.env || \
  echo "OPENROUTER_API_KEY=<new>" >> ~/.vibes/.env

Run the deploy:

bash

node scripts/deploy-cloudflare.js --name vibes-test --file test-vibes/index.html

For sell-ready fixture: Pass

--env-dir

to auto-detect Clerk key, and pass billing mode and webhook secret from

test-vibes/.env

bash

node scripts/deploy-cloudflare.js --name vibes-test --file test-vibes/index.html \
  --env-dir test-vibes \
  --billing-mode $BILLING_MODE \
  --webhook-secret $CLERK_WEBHOOK_SECRET  # only if billing required

Read

BILLING_MODE

and

CLERK_WEBHOOK_SECRET

from

test-vibes/.env

. The

--env-dir

flag auto-detects

VITE_CLERK_PUBLISHABLE_KEY

from

.env

(fetches JWKS, converts to PEM, sets

CLERK_PEM_PUBLIC_KEY

and

PERMITTED_ORIGINS

as Worker secrets).

--billing-mode

patches the

[vars]

wrangler.toml

before deploy.

--webhook-secret

sets

CLERK_WEBHOOK_SECRET

as a Worker secret.

For ai-proxy with key:

bash

node scripts/deploy-cloudflare.js --name vibes-test --file test-vibes/index.html --ai-key <key>

**针对ai-proxy夹具：**先检查

~/.vibes/.env

中是否存在缓存的OpenRouter密钥：

bash

grep OPENROUTER_API_KEY ~/.vibes/.env 2>/dev/null

如果存在，提供复用选项（隐藏密钥中间部分，例如

sk-or-v1-...a3b2

）：

AskUserQuestion:
  Question: "是否复用已存储的OpenRouter API密钥？（sk-or-v1-...a3b2）"
  Header: "AI密钥"
  Options:
  - Label: "是，复用"
    Description: "使用~/.vibes/.env中缓存的密钥"
  - Label: "输入新密钥"
    Description: "我将粘贴其他密钥"
  - Label: "跳过AI代理"
    Description: "部署时不包含AI端点"

如果选择"是，复用"：使用存储的值。如果选择"输入新密钥"：通过下方提示收集密钥，然后更新

~/.vibes/.env

。

如果不存在（或用户选择"输入新密钥"）：

AskUserQuestion:
  Question: "粘贴AI代理所需的OpenRouter API密钥"
  Header: "AI密钥"
  Options:
  - Label: "跳过AI代理"
    Description: "部署时不包含AI端点"

收集新密钥后，询问是否保存：

AskUserQuestion:
  Question: "将此OpenRouter密钥保存到~/.vibes/.env供未来项目使用？"
  Header: "密钥缓存"
  Options:
  - Label: "是，保存"
    Description: "缓存密钥，避免后续重复粘贴"
  - Label: "否，跳过"
    Description: "仅本次会话使用"

如果选择"是，保存"：

bash

mkdir -p ~/.vibes
grep -q OPENROUTER_API_KEY ~/.vibes/.env 2>/dev/null && \
  sed -i '' 's/^OPENROUTER_API_KEY=.*/OPENROUTER_API_KEY=<new>/' ~/.vibes/.env || \
  echo "OPENROUTER_API_KEY=<new>" >> ~/.vibes/.env

执行部署：

bash

node scripts/deploy-cloudflare.js --name vibes-test --file test-vibes/index.html

**针对sell-ready夹具：**传入

--env-dir

参数自动检测Clerk密钥，并从

test-vibes/.env

传入计费模式和Webhook密钥：

bash

node scripts/deploy-cloudflare.js --name vibes-test --file test-vibes/index.html \
  --env-dir test-vibes \
  --billing-mode $BILLING_MODE \
  --webhook-secret $CLERK_WEBHOOK_SECRET  # 仅当需计费时传入

从

test-vibes/.env

读取

BILLING_MODE

和

CLERK_WEBHOOK_SECRET

。

--env-dir

参数会自动从

.env

中检测

VITE_CLERK_PUBLISHABLE_KEY

（获取JWKS，转换为PEM，设置

CLERK_PEM_PUBLIC_KEY

和

PERMITTED_ORIGINS

为Worker密钥）。

--billing-mode

参数会在部署前修改

wrangler.toml

中的

[vars]

配置。

--webhook-secret

参数会将

CLERK_WEBHOOK_SECRET

设置为Worker密钥。

针对带密钥的ai-proxy：

bash

node scripts/deploy-cloudflare.js --name vibes-test --file test-vibes/index.html --ai-key <key>

Phase 5.5: Admin Setup (sell-ready only)

阶段5.5：管理员配置（仅针对sell-ready）

Condition: Only runs for the sell-ready fixture AND admin is not yet configured (no cached ID was reused in Phase 3).

After deploy, guide the user through post-deploy admin setup:

Tell the user the app is live and they can now sign up:

Your app is deployed! To configure admin access, first create an account:
  Sign up here: https://vibes-test.<account>.workers.dev?subdomain=test

After signing up, we'll grab your User ID from Clerk Dashboard.

Ask if they've signed up:

AskUserQuestion:
  Question: "Have you completed signup on the deployed app?"
  Header: "Signup"
  Options:
  - Label: "Yes, signed up"
    Description: "I've created my account and I'm ready to get my User ID"
  - Label: "Skip admin setup"
    Description: "Continue without admin access"

If "Skip admin setup": proceed to Phase 6 without admin configured.

Guide to Clerk Dashboard:

Now grab your User ID:
  1. Go to clerk.com → your application → Users
  2. Click on your user
  3. Copy the User ID (starts with user_)

Collect the User ID:

AskUserQuestion:
  Question: "Paste your Clerk User ID (starts with user_)"
  Header: "Admin ID"
  Options:
  - Label: "I need help finding it"
    Description: "Show me where to find the User ID in Clerk Dashboard"
  - Label: "Skip admin setup"
    Description: "Continue without admin access"

Validate the input starts with

user_

. If not, ask again.

Save to
```
test-vibes/.env
```
:

bash

grep -q CLERK_ADMIN_USER_ID test-vibes/.env 2>/dev/null && \
  sed -i '' 's/^CLERK_ADMIN_USER_ID=.*/CLERK_ADMIN_USER_ID=<userId>/' test-vibes/.env || \
  echo "CLERK_ADMIN_USER_ID=<userId>" >> test-vibes/.env

Re-assemble with admin configured:

bash

set -a && source test-vibes/.env && set +a

node scripts/assemble-sell.js test-vibes/app.jsx test-vibes/index.html \
  --domain vibes-test.<account>.workers.dev \
  --admin-ids '["<userId>"]'

Re-deploy:

bash

node scripts/deploy-cloudflare.js --name vibes-test --file test-vibes/index.html \
  --env-dir test-vibes \
  --billing-mode $BILLING_MODE \
  --webhook-secret $CLERK_WEBHOOK_SECRET  # only if billing required

Confirm:

Admin access configured! The admin dashboard at ?subdomain=admin should now work for your account.

Proceed to Phase 6.

触发条件：仅针对sell-ready夹具，且阶段3中未复用缓存的管理员ID。

部署完成后，引导用户完成部署后的管理员配置：

告知用户应用已上线，可开始注册：

你的应用已部署完成！要配置管理员权限，请先创建账户：
  注册地址：https://vibes-test.<account>.workers.dev?subdomain=test

注册完成后，我们将从Clerk控制台获取你的用户ID。

询问用户是否完成注册：

AskUserQuestion:
  Question: "你是否已在部署的应用上完成注册？"
  Header: "注册状态"
  Options:
  - Label: "是，已注册"
    Description: "我已创建账户，准备获取用户ID"
  - Label: "跳过管理员配置"
    Description: "不配置管理员权限继续"

如果选择"跳过管理员配置"：直接进入阶段6，不配置管理员。

引导用户前往Clerk控制台：

现在获取你的用户ID：
  1. 前往clerk.com → 你的应用 → 用户
  2. 点击你的用户
  3. 复制用户ID（以user_开头）

收集用户ID：

AskUserQuestion:
  Question: "粘贴你的Clerk用户ID（以user_开头）"
  Header: "管理员ID"
  Options:
  - Label: "需要帮助查找"
    Description: "告诉我如何在Clerk控制台找到用户ID"
  - Label: "跳过管理员配置"
    Description: "不配置管理员权限继续"

验证输入是否以

user_

开头，如果不是，重新询问。

保存到
```
test-vibes/.env
```
：

bash

grep -q CLERK_ADMIN_USER_ID test-vibes/.env 2>/dev/null && \
  sed -i '' 's/^CLERK_ADMIN_USER_ID=.*/CLERK_ADMIN_USER_ID=<userId>/' test-vibes/.env || \
  echo "CLERK_ADMIN_USER_ID=<userId>" >> test-vibes/.env

重新组装并配置管理员：

bash

set -a && source test-vibes/.env && set +a

node scripts/assemble-sell.js test-vibes/app.jsx test-vibes/index.html \
  --domain vibes-test.<account>.workers.dev \
  --admin-ids '["<userId>"]'

重新部署：

bash

node scripts/deploy-cloudflare.js --name vibes-test --file test-vibes/index.html \
  --env-dir test-vibes \
  --billing-mode $BILLING_MODE \
  --webhook-secret $CLERK_WEBHOOK_SECRET  # 仅当需计费时传入

确认配置完成：

管理员权限配置完成！你的账户现在可访问?subdomain=admin路径下的管理员控制台。

进入阶段6。

Phase 6: Present URL

阶段6：展示在线URL

Print the live URL and what to check:

For minimal / fireproof-basic:

Deployed! Open in your browser:
  https://vibes-test.<account>.workers.dev

What to verify:
- Page loads without console errors
- (fireproof-basic) CRUD operations work — add, edit, delete items
- Settings gear icon opens the menu

For sell-ready:

Deployed! Open these URLs:
  Landing:  https://vibes-test.<account>.workers.dev
  Tenant:   https://vibes-test.<account>.workers.dev?subdomain=test
  Admin:    https://vibes-test.<account>.workers.dev?subdomain=admin

What to verify:
- Landing page shows pricing/marketing content
- Claim a subdomain — should succeed (tests /claim + JWT auth)
- Tenant URL shows auth gate (Clerk sign-in)
- Admin URL shows admin dashboard (if admin was configured in Phase 3 or 5.5)
- Admin URL shows "Admin Access Required" (if admin setup was skipped)

For ai-proxy:

Deployed! Open in your browser:
  https://vibes-test.<account>.workers.dev

What to verify:
- App loads and renders
- AI chat feature works (sends to /api/ai/chat)
- Check Network tab: requests go to OpenRouter via proxy

Then ask:

AskUserQuestion:
  Question: "How does it look?"
  Header: "Result"
  Options:
  - Label: "Working"
    Description: "Everything renders correctly"
  - Label: "Has issues"
    Description: "Something isn't right — I'll describe it"

If "Working":

Print a summary table:

| Phase       | Status |
|-------------|--------|
| Credentials | ✓      |
| Connect     | ✓ <studio-name>.exe.xyz |
| Assembly    | ✓ <fixture>.jsx → index.html |
| Cloudflare  | ✓ <url> |
| Browser     | ✓ User confirmed working |

AskUserQuestion:
  Question: "What next?"
  Header: "Next"
  Options:
  - Label: "Test another fixture"
    Description: "Go back to Phase 3 and pick a different fixture"
  - Label: "End test session"
    Description: "Clean up artifacts and finish"

If "Test another fixture": go to Phase 3. If "End test session": go to Phase 11.

If "Has issues": proceed to Phase 7.

打印在线URL及验证要点：

针对minimal / fireproof-basic：

部署完成！在浏览器中打开：
  https://vibes-test.<account>.workers.dev

验证要点：
- 页面加载无控制台错误
- （fireproof-basic）CRUD操作正常——添加、编辑、删除条目
- 设置齿轮图标可打开菜单

针对sell-ready：

部署完成！打开以下URL：
  着陆页:  https://vibes-test.<account>.workers.dev
  租户页:   https://vibes-test.<account>.workers.dev?subdomain=test
  管理员页:    https://vibes-test.<account>.workers.dev?subdomain=admin

验证要点：
- 着陆页显示定价/营销内容
- 申领子域名——操作应成功（测试/claim + JWT认证）
- 租户URL显示认证入口（Clerk登录）
- 管理员URL显示管理员控制台（如果在阶段3或5.5中配置了管理员）
- 管理员URL显示"需要管理员权限"（如果跳过了管理员设置）

针对ai-proxy：

部署完成！在浏览器中打开：
  https://vibes-test.<account>.workers.dev

验证要点：
- 应用加载并正常渲染
- AI聊天功能正常（请求发送到/api/ai/chat）
- 检查网络标签：请求通过代理发送到OpenRouter

然后询问：

AskUserQuestion:
  Question: "验证结果如何？"
  Header: "结果反馈"
  Options:
  - Label: "正常运行"
    Description: "所有内容渲染正常"
  - Label: "存在问题"
    Description: "部分功能异常——我将描述问题"

如果选择"正常运行"：

打印汇总表格：

| 阶段       | 状态 |
|-------------|--------|
| 凭证配置 | ✓      |
| Connect配置 | ✓ <studio-name>.exe.xyz |
| 夹具组装    | ✓ <fixture>.jsx → index.html |
| Cloudflare部署  | ✓ <url> |
| 浏览器验证     | ✓ 用户确认正常运行 |

AskUserQuestion:
  Question: "下一步操作？"
  Header: "后续选择"
  Options:
  - Label: "测试其他夹具"
    Description: "返回阶段3选择其他夹具"
  - Label: "结束测试会话"
    Description: "清理工件并结束"

如果选择"测试其他夹具"：返回阶段3。如果选择"结束测试会话"：进入阶段11。

**如果选择"存在问题"：**进入阶段7。

Phase 7: Diagnosis

阶段7：问题诊断

You are a plugin developer testing your own code. The test instance is disposable. Bugs found here are bugs in plugin source code — deploy scripts, templates, assembly logic, or skill instructions. Fix the plugin source, NOT the test instance.

Ask the user to describe the issue. Then work through these diagnostic steps. Skip ahead when diagnosis is clear.

7.1 Browser console — ask the user to check, or use browser automation tools if available:

Console Error	Likely Cause	Check File
`Cannot read properties of null (reading 'useContext')`	Duplicate React instances	`templates/base/template.html` import map
`Failed to fetch` / CORS errors	Deploy script wrong URL or missing CORS headers	`scripts/deploy-connect.js` , `scripts/deploy-cloudflare.js`
`Fireproof is not defined`	Missing import map entry	`templates/base/template.html` import map
`Unexpected token '<'`	Babel script block malformed	`scripts/assemble.js`
404 on `/api/` routes	nginx config or Connect not running	`scripts/deploy-connect.js`

7.2 Network requests — probe the deployed services:

bash

undefined

你作为插件开发者测试自有代码。测试实例可随时丢弃。此处发现的问题属于插件源代码的Bug——部署脚本、模板、组装逻辑或技能说明中的问题。修复插件源代码，而非测试实例。

请用户描述问题，然后执行以下诊断步骤。如果已明确问题原因，可跳过部分步骤。

7.1 浏览器控制台——请用户检查，或使用浏览器自动化工具：

控制台错误	可能原因	检查文件
`Cannot read properties of null (reading 'useContext')`	React实例重复	`templates/base/template.html` 导入映射
`Failed to fetch` / CORS错误	部署脚本URL错误或缺失CORS头	`scripts/deploy-connect.js` , `scripts/deploy-cloudflare.js`
`Fireproof is not defined`	缺失导入映射条目	`templates/base/template.html` 导入映射
`Unexpected token '<'`	Babel脚本块格式错误	`scripts/assemble.js`
`/api/` 路由404错误	nginx配置错误或Connect未运行	`scripts/deploy-connect.js`

7.2 网络请求——探测已部署服务：

bash

undefined

Test Connect Studio API

测试Connect Studio API

curl -v https://<studio>.exe.xyz/api/

Test Cloudflare Worker

测试Cloudflare Worker

curl -v https://vibes-test.<account>.workers.dev/


**7.3 Server-side** — SSH into the VM if network probes fail:

```bash
ssh <studio>.exe.xyz "docker ps"           # Check containers running
ssh <studio>.exe.xyz "sudo nginx -t"       # Check nginx config
ssh <studio>.exe.xyz "docker logs gateway"  # Check gateway logs

7.4 Plugin source — map symptoms to source files:

Symptom Category	Files to Read
Assembly/template	`scripts/assemble.js` , `templates/base/template.html` , relevant `template.delta.html`
Deploy/hosting	`scripts/deploy-cloudflare.js` , `scripts/deploy-connect.js`
Auth/Clerk	`templates/base/template.html` (Clerk script), `scripts/deploy-connect.js` (env vars)
Import/module errors	`templates/base/template.html` (import map)

curl -v https://vibes-test.<account>.workers.dev/


**7.3 服务器端**——如果网络探测失败，SSH进入虚拟机：

```bash
ssh <studio>.exe.xyz "docker ps"           # 检查容器运行状态
ssh <studio>.exe.xyz "sudo nginx -t"       # 检查nginx配置
ssh <studio>.exe.xyz "docker logs gateway"  # 检查网关日志

7.4 插件源代码——将症状映射到源文件：

症状类别	检查文件
组装/模板问题	`scripts/assemble.js` , `templates/base/template.html` , 相关 `template.delta.html`
部署/托管问题	`scripts/deploy-cloudflare.js` , `scripts/deploy-connect.js`
认证/Clerk问题	`templates/base/template.html` （Clerk脚本）, `scripts/deploy-connect.js` （环境变量）
导入/模块错误	`templates/base/template.html` （导入映射）

Phase 8: Root Cause Classification

阶段8：根因分类

Before touching any file, state the classification:

Category	Signal	Fix Target	Example
A: Plugin source bug	Deploy script produces wrong output	`scripts/*.js`	`deploy-connect.js` writes wrong URL
B: Template bug	HTML output is structurally wrong	`templates/base/template.html` or `template.delta.html`	Missing import map entry
C: Skill instruction bug	Agent followed wrong steps	`skills/*/SKILL.md`	Wrong hook name in instructions
D: Fixture bug	Only this fixture fails	`scripts/__tests__/fixtures/`	Bad JSX in test fixture
E: External/transient	VM down, CDN outage, rate limit	None — retry	esm.sh 503, VM unreachable

AskUserQuestion:
  Question: "I believe this is Category <X>: <description>. The fix belongs in <file>. Proceed?"
  Header: "Fix plan"
  Options:
  - Label: "Yes, fix it"
    Description: "Apply the fix to plugin source"
  - Label: "Wrong diagnosis"
    Description: "I think the problem is something else"

If "Wrong diagnosis": ask what they think and re-diagnose.

在修改任何文件前，先明确问题分类：

分类	特征	修复目标	示例
A: 插件源代码Bug	部署脚本输出错误	`scripts/*.js`	`deploy-connect.js` 写入错误URL
B: 模板Bug	HTML输出结构错误	`templates/base/template.html` 或 `template.delta.html`	缺失导入映射条目
C: 技能说明Bug	代理执行了错误步骤	`skills/*/SKILL.md`	说明中使用了错误的钩子名称
D: 夹具Bug	仅当前夹具测试失败	`scripts/__tests__/fixtures/`	测试夹具中存在错误JSX
E: 外部/临时问题	虚拟机宕机、CDN故障、速率限制	无——重试即可	esm.sh 503错误、虚拟机不可达

AskUserQuestion:
  Question: "我判断这属于<X>类问题：<描述>。修复目标为<文件>。是否继续？"
  Header: "修复方案"
  Options:
  - Label: "是，修复"
    Description: "对插件源代码应用修复"
  - Label: "诊断错误"
    Description: "我认为问题是其他原因"

如果选择"诊断错误"：询问用户的判断，重新诊断。

Phase 9: Apply Fix and Verify

阶段9：应用修复并验证

Fix the plugin source file, NOT the test instance.

Apply the fix to the identified source file

If the fix touched templates or components, regenerate:

bash

node scripts/merge-templates.js --force   # If template.html or delta changed
node scripts/build-components.js --force  # If components/ changed

Re-run from the appropriate phase:

Category	Restart From
A: Plugin source	Phase that uses the fixed script (2, 4, or 5)
B: Template	Phase 4 (re-assemble)
C: Skill instruction	Note the fix — no re-run needed
D: Fixture	Phase 4 (re-assemble)
E: External	Retry the failed phase

Present the URL and ask:

AskUserQuestion:
  Question: "How does it look now?"
  Header: "Verify"
  Options:
  - Label: "Fixed"
    Description: "The issue is resolved"
  - Label: "Still broken"
    Description: "Same problem persists"
  - Label: "Different issue"
    Description: "Original issue fixed but something else is wrong"

If "Still broken" or "Different issue": loop back to Phase 7. After 3 loops, say:

This needs hands-on investigation. Here's what I've tried so far: <summary>. Try debugging manually or open an issue.

Then ask:

AskUserQuestion:
  Question: "What next?"
  Header: "Next"
  Options:
  - Label: "Test another fixture"
    Description: "Go back to Phase 3 and pick a different fixture"
  - Label: "End test session"
    Description: "Clean up artifacts and finish"

If "Test another fixture": go to Phase 3. If "End test session": go to Phase 11.

修复插件源代码文件，而非测试实例。

对确定的源文件应用修复

如果修复涉及模板或组件，重新生成：

bash

node scripts/merge-templates.js --force   # 如果template.html或delta文件修改
node scripts/build-components.js --force  # 如果components/目录修改

从对应阶段重新执行流程：

分类	重新执行起始阶段
A: 插件源代码Bug	使用修复后脚本的阶段（2、4或5）
B: 模板Bug	阶段4（重新组装）
C: 技能说明Bug	记录修复——无需重新执行
D: 夹具Bug	阶段4（重新组装）
E: 外部/临时问题	重试失败的阶段

展示URL并询问：

AskUserQuestion:
  Question: "现在验证结果如何？"
  Header: "修复验证"
  Options:
  - Label: "已修复"
    Description: "问题已解决"
  - Label: "仍异常"
    Description: "问题依旧存在"
  - Label: "出现新问题"
    Description: "原问题已修复，但出现其他异常"

如果选择"仍异常"或"出现新问题"：返回阶段7。如果循环3次后仍未解决，提示：

此问题需要手动排查。以下是我已尝试的操作：<总结>。请手动调试或提交Issue。

然后询问：

AskUserQuestion:
  Question: "下一步操作？"
  Header: "后续选择"
  Options:
  - Label: "测试其他夹具"
    Description: "返回阶段3选择其他夹具"
  - Label: "结束测试会话"
    Description: "清理工件并结束"

如果选择"测试其他夹具"：返回阶段3。如果选择"结束测试会话"：进入阶段11。

Phase 10: Resolution Summary

阶段10：修复总结

Write

test-vibes/FIX-REPORT.md

markdown

undefined

写入

test-vibes/FIX-REPORT.md

：

markdown

undefined

Fix Report

修复报告

Date: <date> Fixture: <fixture> Category: <A-E>

日期: <date> 测试夹具: <fixture> 问题分类: <A-E>

Symptom

症状

<用户报告的问题>

Root Cause

根因

<实际问题原因>

Fix

修复方案

File: <path>
Change: <one-line description>

文件: <路径>
修改内容: <单行描述>

Diagnosis Commands

诊断命令

<用于定位问题的命令>

Prevention

预防措施

<How to avoid this in the future> ```

AskUserQuestion:
  Question: "What next?"
  Header: "Next"
  Options:
  - Label: "Test another fixture"
    Description: "Go back to Phase 3 with the fix in place"
  - Label: "Commit the fix"
    Description: "Review and commit the plugin source changes"
  - Label: "End test session"
    Description: "Clean up artifacts and finish"

If "Commit the fix": show

git diff

of plugin source changes (exclude

test-vibes/

), suggest a commit message derived from the fix report. After committing, show the canonical prompt:

AskUserQuestion:
  Question: "What next?"
  Header: "Next"
  Options:
  - Label: "Test another fixture"
    Description: "Go back to Phase 3 and pick a different fixture"
  - Label: "End test session"
    Description: "Clean up artifacts and finish"

If "Test another fixture": go to Phase 3. If "End test session": go to Phase 11.

<未来避免此类问题的方法>

undefined

AskUserQuestion: Question: "下一步操作？" Header: "后续选择" Options:

Label: "测试其他夹具" Description: "应用修复后返回阶段3"
Label: "提交修复" Description: "审核并提交插件源代码修改"
Label: "结束测试会话" Description: "清理工件并结束"


如果选择"提交修复"：展示插件源代码的`git diff`结果（排除`test-vibes/`目录），根据修复报告建议提交信息。提交完成后，展示提示：

AskUserQuestion: Question: "下一步操作？" Header: "后续选择" Options:

Label: "测试其他夹具" Description: "返回阶段3选择其他夹具"
Label: "结束测试会话" Description: "清理工件并结束"


如果选择"测试其他夹具"：返回阶段3。如果选择"结束测试会话"：进入阶段11。

Phase 11: Unit & Integration Tests

阶段11：单元&集成测试

Run the vitest suite to confirm plugin source is healthy. Especially important after any fixes applied in Phase 9.

bash

cd scripts && npm test

If all tests pass: Print the count (e.g. "429 tests passed") and proceed to cleanup.

If any tests fail: Show the failure output and ask:

AskUserQuestion:
  Question: "Unit/integration tests failed. Fix before finishing?"
  Header: "Tests"
  Options:
  - Label: "Yes, fix them"
    Description: "Investigate and fix the failing tests"
  - Label: "Skip"
    Description: "Finish the session anyway"

If "Yes, fix them": diagnose and fix the failures, re-run

npm test

, loop until green.

运行Vitest套件确认插件源代码健康。尤其是阶段9中应用了修复的情况下，此步骤至关重要。

bash

cd scripts && npm test

如果所有测试通过: 打印通过数量（例如"429个测试通过"），进入清理阶段。

如果存在测试失败: 展示失败输出，然后询问：

AskUserQuestion:
  Question: "单元/集成测试失败。是否在结束前修复？"
  Header: "测试结果"
  Options:
  - Label: "是，修复"
    Description: "排查并修复失败的测试"
  - Label: "跳过"
    Description: "直接结束会话"

如果选择"是，修复"：诊断并修复失败测试，重新运行

npm test

，直到所有测试通过。

Phase 12: Session Cleanup

阶段12：会话清理

Triggered after Phase 11 completes or when user selects "End test session" from any "What next?" prompt.

Clean up test artifacts while preserving reusable credentials:

bash

undefined

当阶段11完成，或用户在任何"下一步操作？"提示中选择"结束测试会话"时触发。

清理测试工件，保留可复用的凭证：

bash

undefined

Clean test artifacts, preserve .env and .connect

清理测试工件，保留.env和.connect

cd test-vibes && find . -maxdepth 1 ! -name '.' ! -name '.env' ! -name '.connect' -exec rm -rf {} +


Print:

Test session complete. Cleaned: test-vibes/ artifacts Preserved: .env, .connect (reusable next session)

undefined

cd test-vibes && find . -maxdepth 1 ! -name '.' ! -name '.env' ! -name '.connect' -exec rm -rf {} +


打印提示：

测试会话已完成。已清理: test-vibes/ 下的工件已保留: .env, .connect（下次会话可复用）

undefined