test
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChinesePlan 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: (gitignored, persists across runs)
test-vibes/统筹完整测试流程:凭证配置 → Connect Studio → 测试夹具组装 → Cloudflare部署 → 在线URL生成 → 单元测试。
工作目录:(已加入git忽略,跨运行会话持久保存)
test-vibes/Phase 1: Credentials
阶段1:凭证配置
Check if exists and has Clerk keys.
test-vibes/.envbash
undefined检查是否存在且包含Clerk密钥。
test-vibes/.envbash
undefinedFrom 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>
undefinedcat 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>
undefinedPhase 2: Connect Studio
阶段2:Connect Studio配置
Check if exists (marks a deployed studio).
test-vibes/.connectbash
cat test-vibes/.connect 2>/dev/nullIf exists: Read the studio name and API/Cloud URLs. Confirm reuse:
.connectAskUserQuestion:
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 doesn't exist or user wants fresh deploy:
.connectRun the deploy script. Read the Clerk keys from first:
test-vibes/.envbash
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检查是否存在(标记已部署的Studio)。
test-vibes/.connectbash
cat test-vibes/.connect 2>/dev/null**如果存在:**读取Studio名称和API/Cloud URL,确认是否复用:
.connectAskUserQuestion:
Question: "是否复用现有Connect Studio '<name>'?"
Header: "Connect配置"
Options:
- Label: "是,复用"
Description: "Studio已在运行"
- Label: "否,重新部署"
Description: "部署新的Connect Studio"如果不存在,或用户选择重新部署:
.connect运行部署脚本。先从读取Clerk密钥:
test-vibes/.envbash
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
undefinedWrite 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
undefinedecho "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
undefinedPhase 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 for a cached admin user ID from a previous run:
test-vibes/.envbash
grep CLERK_ADMIN_USER_ID test-vibes/.env 2>/dev/nullIf found, offer to reuse it (mask the middle of the value in the prompt, e.g., ):
user_37ici...ohcYAskUserQuestion:
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 in Phase 4. Admin setup will be offered post-deploy in Phase 5.5.
--admin-idsIf 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夹具:**检查中是否存在之前运行缓存的管理员用户ID:
test-vibes/.envbash
grep CLERK_ADMIN_USER_ID test-vibes/.env 2>/dev/null如果存在,提供复用选项(在提示中隐藏中间部分,例如):
user_37ici...ohcYAskUserQuestion:
Question: "是否复用已存储的管理员用户ID?(user_37ici...ohcY)"
Header: "管理员ID"
Options:
- Label: "是,复用"
Description: "使用test-vibes/.env中缓存的用户ID"
- Label: "跳过管理员配置"
Description: "部署时不配置管理员——可在部署后设置"如果选择"是,复用":在阶段4组装时使用存储的值。如果选择"跳过管理员配置":在阶段4中省略参数,管理员设置将在阶段5.5的部署后流程中提供。
--admin-ids如果不存在:无需提示。管理员将在阶段5.5的部署后流程中配置,用户可先在在线应用完成注册。
Phase 3.5: Sell Configuration (sell-ready only)
阶段3.5:销售配置(仅针对sell-ready)
Condition: Only runs when the user selected in Phase 3.
sell-readyAsk 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 in . Skip webhook setup. Proceed to Phase 4.
BILLING_MODE=offtest-vibes/.envIf "Billing required": Store in . Then guide webhook setup:
BILLING_MODE=requiredtest-vibes/.envAskUserQuestion:
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 . If not, ask again with a note that it should start with .
whsec_whsec_Store as in :
CLERK_WEBHOOK_SECRETtest-vibes/.envbash
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/.envProceed to Phase 4.
触发条件:仅当用户在阶段3中选择时运行。
sell-ready询问计费模式:
AskUserQuestion:
Question: "本次销售测试使用哪种计费模式?"
Header: "计费设置"
Options:
- Label: "免费(关闭计费)"
Description: "无需付费即可使用——仅测试认证+租户路由"
- Label: "需计费"
Description: "使用需激活Clerk订阅——测试完整付费墙流程"**如果选择"免费":**在中存储,跳过Webhook设置,进入阶段4。
test-vibes/.envBILLING_MODE=off**如果选择"需计费":**在中存储,然后引导配置Webhook:
test-vibes/.envBILLING_MODE=requiredAskUserQuestion:
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/.envCLERK_WEBHOOK_SECRETbash
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
undefinedCopy 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/.envIf admin was skipped, omit . The flag is always required.
--admin-ids--domainFor all other fixtures:
bash
node scripts/assemble.js test-vibes/app.jsx test-vibes/index.htmlValidate the output (same checks as the vitest suite):
- File exists and is non-empty
- No strings remain
__PLACEHOLDER__ - Import map is present
<script type="importmap"> - contains the fixture code
<script type="text/babel"> - For sell-ready: function is present
getRouteInfo
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 for a cached OpenRouter key first:
~/.vibes/.envbash
grep OPENROUTER_API_KEY ~/.vibes/.env 2>/dev/nullIf found, offer to reuse it (mask the key, e.g., ):
sk-or-v1-...a3b2AskUserQuestion:
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/.envIf 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/.envRun the deploy:
bash
node scripts/deploy-cloudflare.js --name vibes-test --file test-vibes/index.htmlFor sell-ready fixture: Pass to auto-detect Clerk key, and pass billing mode and webhook secret from :
--env-dirtest-vibes/.envbash
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 requiredRead and from . The flag auto-detects from (fetches JWKS, converts to PEM, sets and as Worker secrets). patches the in before deploy. sets as a Worker secret.
BILLING_MODECLERK_WEBHOOK_SECRETtest-vibes/.env--env-dirVITE_CLERK_PUBLISHABLE_KEY.envCLERK_PEM_PUBLIC_KEYPERMITTED_ORIGINS--billing-mode[vars]wrangler.toml--webhook-secretCLERK_WEBHOOK_SECRETFor ai-proxy with key:
bash
node scripts/deploy-cloudflare.js --name vibes-test --file test-vibes/index.html --ai-key <key>**针对ai-proxy夹具:**先检查中是否存在缓存的OpenRouter密钥:
~/.vibes/.envbash
grep OPENROUTER_API_KEY ~/.vibes/.env 2>/dev/null如果存在,提供复用选项(隐藏密钥中间部分,例如):
sk-or-v1-...a3b2AskUserQuestion:
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夹具:**传入参数自动检测Clerk密钥,并从传入计费模式和Webhook密钥:
--env-dirtest-vibes/.envbash
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 # 仅当需计费时传入从读取和。参数会自动从中检测(获取JWKS,转换为PEM,设置和为Worker密钥)。参数会在部署前修改中的配置。参数会将设置为Worker密钥。
test-vibes/.envBILLING_MODECLERK_WEBHOOK_SECRET--env-dir.envVITE_CLERK_PUBLISHABLE_KEYCLERK_PEM_PUBLIC_KEYPERMITTED_ORIGINS--billing-modewrangler.toml[vars]--webhook-secretCLERK_WEBHOOK_SECRET针对带密钥的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 . If not, ask again.
user_- 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 menuFor 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 proxyThen 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 |
|---|---|---|
| Duplicate React instances | |
| Deploy script wrong URL or missing CORS headers | |
| Missing import map entry | |
| Babel script block malformed | |
404 on | nginx config or Connect not running | |
7.2 Network requests — probe the deployed services:
bash
undefined你作为插件开发者测试自有代码。测试实例可随时丢弃。此处发现的问题属于插件源代码的Bug——部署脚本、模板、组装逻辑或技能说明中的问题。修复插件源代码,而非测试实例。
请用户描述问题,然后执行以下诊断步骤。如果已明确问题原因,可跳过部分步骤。
7.1 浏览器控制台——请用户检查,或使用浏览器自动化工具:
| 控制台错误 | 可能原因 | 检查文件 |
|---|---|---|
| React实例重复 | |
| 部署脚本URL错误或缺失CORS头 | |
| 缺失导入映射条目 | |
| Babel脚本块格式错误 | |
| nginx配置错误或Connect未运行 | |
7.2 网络请求——探测已部署服务:
bash
undefinedTest 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 logs7.4 Plugin source — map symptoms to source files:
| Symptom Category | Files to Read |
|---|---|
| Assembly/template | |
| Deploy/hosting | |
| Auth/Clerk | |
| Import/module errors | |
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 插件源代码——将症状映射到源文件:
| 症状类别 | 检查文件 |
|---|---|
| 组装/模板问题 | |
| 部署/托管问题 | |
| 认证/Clerk问题 | |
| 导入/模块错误 | |
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 | | |
| B: Template bug | HTML output is structurally wrong | | Missing import map entry |
| C: Skill instruction bug | Agent followed wrong steps | | Wrong hook name in instructions |
| D: Fixture bug | Only this fixture fails | | 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 | 部署脚本输出错误 | | |
| B: 模板Bug | HTML输出结构错误 | | 缺失导入映射条目 |
| C: 技能说明Bug | 代理执行了错误步骤 | | 说明中使用了错误的钩子名称 |
| D: 夹具Bug | 仅当前夹具测试失败 | | 测试夹具中存在错误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.mdmarkdown
undefined写入:
test-vibes/FIX-REPORT.mdmarkdown
undefinedFix 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 of plugin source changes (exclude ), suggest a commit message derived from the fix report. After committing, show the canonical prompt:
git difftest-vibes/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.
<未来避免此类问题的方法>
undefinedAskUserQuestion:
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 testIf 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 , loop until green.
npm test运行Vitest套件确认插件源代码健康。尤其是阶段9中应用了修复的情况下,此步骤至关重要。
bash
cd scripts && npm test如果所有测试通过: 打印通过数量(例如"429个测试通过"),进入清理阶段。
如果存在测试失败: 展示失败输出,然后询问:
AskUserQuestion:
Question: "单元/集成测试失败。是否在结束前修复?"
Header: "测试结果"
Options:
- Label: "是,修复"
Description: "排查并修复失败的测试"
- Label: "跳过"
Description: "直接结束会话"如果选择"是,修复":诊断并修复失败测试,重新运行,直到所有测试通过。
npm testPhase 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
undefinedClean 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)
undefinedcd test-vibes && find . -maxdepth 1 ! -name '.' ! -name '.env' ! -name '.connect' -exec rm -rf {} +
打印提示:
测试会话已完成。
已清理: test-vibes/ 下的工件
已保留: .env, .connect(下次会话可复用)
undefined