/test

name: test
description: Self-contained test automation — invoke directly, do not decompose. End-to-end integration test that assembles a fixture, deploys to Cloudflare (with auto-provisioned Connect), and presents a live URL for browser verification. Use when testing the plugin, running E2E tests, verifying deployment works, or checking that templates assemble correctly.
license: MIT
allowed-tools: Read, Write, Edit, Bash, Glob, Grep, AskUserQuestion
metadata:
  author: "Marcus Estes"

> **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.

Integration Test Skill

Orchestrates the full test pipeline: credentials → fixture assembly → Cloudflare deploy (with auto-provisioned Connect) → live URL → unit tests.

**Working directory:** `test-vibes/` (gitignored, persists across runs)

Phase 1: Credentials

Check if `test-vibes/.env` exists and has OIDC credentials.

# From the plugin root
cat test-vibes/.env 2>/dev/null

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

AskUserQuestion:
  Question: "Reuse existing test credentials? (OIDC authority: https://...)"
  Header: "Credentials"
  Options:
  - Label: "Yes, reuse"
    Description: "Use the OIDC credentials already in test-vibes/.env"
  - Label: "No, enter new credentials"
    Description: "I want to use different OIDC credentials"

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

AskUserQuestion:
  Question: "Paste your OIDC Authority URL (e.g., https://studio.exe.xyz/auth)"
  Header: "OIDC Authority"
  Options:
  - Label: "I need to set up OIDC first"
    Description: "I'll configure Pocket ID and come back"

If they need to set up OIDC, tell them: > You need a Pocket ID instance for authentication. Connect is auto-provisioned on first deploy -- you just need the OIDC Authority URL and Client ID from your Pocket ID configuration.

Then ask for the client ID:

AskUserQuestion:
  Question: "Paste your OIDC Client ID"
  Header: "OIDC Client ID"

Write `test-vibes/.env`:

VITE_OIDC_AUTHORITY=<authority-url>
VITE_OIDC_CLIENT_ID=<client-id>

Phase 2: Connect (Auto-Provisioned)

Connect is automatically provisioned on first Cloudflare deploy -- no manual setup needed. The `deploy-cloudflare.js` script handles R2 bucket, D1 databases, and cloud backend Worker provisioning via alchemy. Subsequent deploys skip Connect setup.

Proceed directly to fixture selection.

Phase 3: Fixture Selection

AskUserQuestion:
  Question: "Which fixture to test?"
  Header: "Fixture"
  Options:
  - Label: "basic (Recommended)"
    Description: "TinyBase data operations with React singleton — the standard integration test"
  - Label: "minimal"
    Description: "Template + Babel + import map only — fastest, no data layer"
  - Label: "sell-ready"
    Description: "useTenant() + multi-tenant routing — tests factory 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:

grep OIDC_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.

Phase 3.5: Factory Configuration (sell-ready only)

**Condition:** Only runs when the user selected `sell-ready` in Phase 3.

**Ask billing mode:**

AskUserQuestion:
  Question: "Which billing mode should this factory 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 subscription — tests auth gate flow (Stripe billing is phase 2)"

**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`. Note that Stripe billing integration is phase 2, so the paywall will be a placeholder.

Proceed to Phase 4.

Phase 4: Assembly

Copy the selected fixture and assemble:

# 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:**

bun scripts/assemble-factory.js test-vibes/app.jsx test-vibes/index.html \
  --domain vibes-test.<account>.workers.dev \
  --admin-ids '["<admin-user-id>"]'  # read OIDC_ADMIN_USER_ID from test-vibes/.env

If admin was skipped, omit `--admin-ids`. The `--domain` flag is always required.

**For all other fixtures:**

bun 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