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
in
test-vibes/.env
. Skip webhook setup. Proceed to Phase 4.
If "Billing required": Store
BILLING_MODE=required
in
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
in
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
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):
  1. File exists and is non-empty
  2. No
    __PLACEHOLDER__
    strings remain
  3. Import map
    <script type="importmap">
    is present
  4. <script type="text/babel">
    contains the fixture code
  5. 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套件的检查逻辑一致):
  1. 文件存在且非空
  2. __PLACEHOLDER__
    字符串残留
  3. 存在导入映射
    <script type="importmap">
  4. <script type="text/babel">
    包含夹具代码
  5. 针对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]
in
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:
  1. 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.
  1. 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.
  1. 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_)
  1. 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.
  1. 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
  1. 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>"]'
  1. 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
  1. Confirm:
Admin access configured! The admin dashboard at ?subdomain=admin should now work for your account.
Proceed to Phase 6.
触发条件:仅针对sell-ready夹具,且阶段3中未复用缓存的管理员ID。
部署完成后,引导用户完成部署后的管理员配置:
  1. 告知用户应用已上线,可开始注册:
你的应用已部署完成!要配置管理员权限,请先创建账户:
  注册地址:https://vibes-test.<account>.workers.dev?subdomain=test

注册完成后,我们将从Clerk控制台获取你的用户ID。
  1. 询问用户是否完成注册:
AskUserQuestion:
  Question: "你是否已在部署的应用上完成注册?"
  Header: "注册状态"
  Options:
  - Label: "是,已注册"
    Description: "我已创建账户,准备获取用户ID"
  - Label: "跳过管理员配置"
    Description: "不配置管理员权限继续"
如果选择"跳过管理员配置":直接进入阶段6,不配置管理员。
  1. 引导用户前往Clerk控制台:
现在获取你的用户ID:
  1. 前往clerk.com → 你的应用 → 用户
  2. 点击你的用户
  3. 复制用户ID(以user_开头)
  1. 收集用户ID:
AskUserQuestion:
  Question: "粘贴你的Clerk用户ID(以user_开头)"
  Header: "管理员ID"
  Options:
  - Label: "需要帮助查找"
    Description: "告诉我如何在Clerk控制台找到用户ID"
  - Label: "跳过管理员配置"
    Description: "不配置管理员权限继续"
验证输入是否以
user_
开头,如果不是,重新询问。
  1. 保存到
    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
  1. 重新组装并配置管理员:
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>"]'
  1. 重新部署:
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  # 仅当需计费时传入
  1. 确认配置完成:
管理员权限配置完成!你的账户现在可访问?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 ErrorLikely CauseCheck 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/
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 CategoryFiles 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:
CategorySignalFix TargetExample
A: Plugin source bugDeploy script produces wrong output
scripts/*.js
deploy-connect.js
writes wrong URL
B: Template bugHTML output is structurally wrong
templates/base/template.html
or
template.delta.html
Missing import map entry
C: Skill instruction bugAgent followed wrong steps
skills/*/SKILL.md
Wrong hook name in instructions
D: Fixture bugOnly this fixture fails
scripts/__tests__/fixtures/
Bad JSX in test fixture
E: External/transientVM down, CDN outage, rate limitNone — retryesm.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: 模板BugHTML输出结构错误
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.
  1. Apply the fix to the identified source file
  2. 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
  3. Re-run from the appropriate phase:
CategoryRestart From
A: Plugin sourcePhase that uses the fixed script (2, 4, or 5)
B: TemplatePhase 4 (re-assemble)
C: Skill instructionNote the fix — no re-run needed
D: FixturePhase 4 (re-assemble)
E: ExternalRetry the failed phase
  1. 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.
修复插件源代码文件,而非测试实例
  1. 对确定的源文件应用修复
  2. 如果修复涉及模板或组件,重新生成:
    bash
    node scripts/merge-templates.js --force   # 如果template.html或delta文件修改
    node scripts/build-components.js --force  # 如果components/目录修改
  3. 从对应阶段重新执行流程:
分类重新执行起始阶段
A: 插件源代码Bug使用修复后脚本的阶段(2、4或5)
B: 模板Bug阶段4(重新组装)
C: 技能说明Bug记录修复——无需重新执行
D: 夹具Bug阶段4(重新组装)
E: 外部/临时问题重试失败的阶段
  1. 展示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

症状

<What the user reported>
<用户报告的问题>

Root Cause

根因

<What was actually wrong>
<实际问题原因>

Fix

修复方案

  • File: <path>
  • Change: <one-line description>
  • 文件: <路径>
  • 修改内容: <单行描述>

Diagnosis Commands

诊断命令

<Commands that revealed the issue>
<用于定位问题的命令>

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