Testing

Preview Testing Skill

This skill tests Lovable apps in Preview mode - the live, running version of the app - using Claude's browser automation. It manages a standardized test workspace at .claude/lovable-claude/test/ containing test plans, test user profiles, and results.

When to Activate

1. Preview testing is enabled in CLAUDE.md (Preview Testing → Status: on) 2. User runs testing commands:

• /lovable:test-init - Test wizard (scaffold workspace, create test plans)
• /lovable:test-run - Execute test plans in Preview mode
• /lovable:test-sync - Resync test plans with new/changed features

3. After implementing a feature (when test workspace exists):

• Suggest adding/updating unit tests AND test plans for the new feature
• If test_after_implementation: on, run the affected test plans automatically

4. After auto-deploy (yolo mode integration):

• If test_after_deploy: on, run smoke-level test plans after deployment

5. User mentions preview testing in any form

How Preview Access Works

Lovable Preview is the running app inside the Lovable editor. There are two ways to access it for testing:

Method 1: Logged-in Browser (simplest)

If the user is logged in to Lovable in Chrome (Claude in Chrome extension), navigate directly to the Lovable project preview. No token needed.

Method 2: Tokenized Preview URL (works without login)

Lovable exposes a shareable preview URL with an access token:

https://preview--[app-name].lovable.app/?__lovable_token=[JWT]

• The user gets this URL by opening their Lovable project in preview mode and clicking the arrow icon at the top, next to the address bar - this opens the preview in a new tab with the token in the URL.
• The token is valid for 7 days. After expiry, ask the user to capture a fresh URL.
• The token is a credential - never commit it to git. Store it in .claude/lovable-claude/test/preview-token.local (gitignored).

See references/preview-access.md for full procedures: capture, storage, expiry detection, and re-prompting.

Access Priority

1. Valid stored token → use tokenized preview URL (most reliable, no login dependency) 2. No/expired token + user logged in to Lovable in Chrome → use logged-in browser session 3. Neither → ask the user to either log in or provide a fresh preview URL with token 4. Fallback: provide manual test checklist for the user to run themselves (never block)

Test Workspace Structure

All testing artifacts live in a standardized folder in the user's project:

.claude/lovable-claude/test/
├── README.md              # Explains the workspace (generated)
├── test-config.json       # Preview URL (no token), settings, coverage state
├── preview-token.local    # Preview token ONLY - gitignored, 7-day validity
├── plans/                 # Test plans (one file per plan)
│   ├── TP-001-user-signup.md
│   ├── TP-002-create-project.md
│   └── ...
├── profiles/              # Test user profiles (test accounts, personas, data)
│   ├── default.json
│   └── admin.json
└── results/               # Test run results (one file per run)
    └── 2026-06-10-TP-001.md

See references/test-plan-format.md for the standardized formats of every file type.

Core Functionality

1. Test Wizard (/lovable:test-init)

Guided creation of the test workspace: 1. Scaffold .claude/lovable-claude/test/ structure 2. Capture preview URL + token (or detect logged-in browser) 3. Scan the codebase to identify the app's main user actions (routes, forms, auth flows, CRUD operations, edge function calls) 4. Suggest test plans for each main action, ask guided questions to refine them 5. Create test user profiles 6. Write standardized test plan files 7. Record coverage state (git commit hash) in test-config.json

See references/test-wizard.md for the complete wizard procedure.

2. Test Execution (/lovable:test-run)

Execute test plans against the Preview app via browser automation:

• Navigate to preview (tokenized URL or logged-in session)
• Execute each test plan step-by-step (clicks, form fills, navigation)
• Verify expected results (UI state, console errors, network responses)
• Write results to results/ and report a summary

Modes:

• --all: run every test plan (planned end-to-end run)
• --changed: run only plans affected by recent changes (after each implementation)
• --smoke: run only plans tagged smoke
• [plan-id]: run one specific plan

See references/test-execution.md for browser automation workflows.

3. Test Resync (/lovable:test-sync)

Keep tests in sync with the codebase as features are added: 1. Compare current codebase against last_synced_commit in test-config.json 2. Identify new/changed features (new routes, components, edge functions, migrations) 3. Map them against existing test plans → find coverage gaps 4. Suggest new test plans and updates to stale ones 5. Also check unit test coverage gaps (if the project has a test framework) 6. Update test-config.json with the new sync point

4. Continuous Test Maintenance (after each feature)

When preview testing is enabled and Claude implements a new feature in the project:

1. Add/update unit tests for the new code (if the project has a test framework) 2. Add/update test plans covering the new user-facing behavior 3. If test_after_implementation: on → run the affected test plans in Preview immediately 4. If test_after_implementation: off → remind the user: "New feature lacks a test plan - run /lovable:test-sync to update coverage"

This keeps the test suite alive instead of letting it rot.

Configuration in CLAUDE.md

The skill reads these fields from the user's CLAUDE.md:

## Preview Testing Configuration

- **Status**: on
- **Preview URL**: https://preview--my-app.lovable.app
- **Access Method**: token   # token | browser-login
- **Token Captured**: 2026-06-10 (valid ~7 days)
- **Test After Implementation**: on   # run affected plans after each feature
- **Test After Deploy**: smoke        # off | smoke | all - run after yolo auto-deploy
- **Last Test Sync**: [commit hash]

Configuration options:

• Status: Enable/disable preview testing entirely
• Access Method: token (tokenized preview URL) or browser-login (user logged in to Lovable)
• Test After Implementation: Run affected test plans automatically after implementing each feature
• Test After Deploy: What to run after yolo auto-deploy (off, smoke, or all)

The actual token is NEVER in CLAUDE.md - only in preview-token.local.

Integration with Other Features

With Yolo Mode (auto-deploy)

When both yolo mode and preview testing are enabled, the post-deploy verification gains a fourth level:

• Level 1-3: existing deployment verification (logs, console, functional) - see yolo skill
• Level 4: Preview test plans - run smoke (or all) test plans against the Preview app per Test After Deploy setting

With Auto-Push

After auto-push of frontend changes (which sync to Lovable in 1-2 minutes), wait for sync before running preview tests so the Preview reflects the pushed code. See references/test-execution.md → "Sync wait".

With /lovable:init

/lovable:init asks about preview testing (Question 8.7) and can capture the preview URL/token during setup, then offers to run /lovable:test-init to build the initial test plans.

Error Handling

Golden rule: never block the user. Every automation failure has a manual fallback.

Token expired:

🔑 Preview token expired (captured [date], valid 7 days)

To capture a fresh one:
1. Open your Lovable project in preview mode
2. Click the arrow icon at the top, next to the address bar
3. Copy the URL from the new tab (contains ?__lovable_token=...)
4. Paste it here

Or log in to Lovable in Chrome and I'll use your session instead.

Browser automation unavailable:

❌ Browser automation unavailable (Claude in Chrome extension required)

Manual test checklist for [plan-id]:
[numbered steps + expected results from the plan]

Report results back and I'll record them in results/.

Preview app shows error / blank page:

• Capture console errors and screenshot description
• Check if a deploy/sync is still in progress (wait + retry once)
• Report findings with suggested fixes - do not mark tests passed

Test failure:

• Record exact step that failed, expected vs actual, console/network errors
• Write a FAIL result file
• Offer to investigate and fix the underlying code

Reference Files

1. `references/preview-access.md` - Capturing, storing, and validating preview URLs and tokens; access priority; expiry handling 2. `references/test-plan-format.md` - Standardized formats for test plans, profiles, config, results, and the workspace README 3. `references/test-wizard.md` - Codebase scanning for main user actions; guided question flow; plan generation 4. `references/test-execution.md` - Browser automation workflows for executing plans in Preview; verification; results reporting

---

This skill closes the loop: code → push → deploy → test in the real running app → fix → repeat.

Preview Access: URLs, Tokens, and Sessions

How to obtain and maintain access to a Lovable project's Preview app for automated testing.

What is the Preview?

Lovable Preview is the live, running build of the app - the same thing the user sees in the right panel of the Lovable editor. It reflects the latest synced code (including unpublished changes), which makes it the right target for testing after each implementation: you test what was just built, before/independent of publishing to production.

Preview URL format:

https://preview--[app-name].lovable.app/

Access Methods

Method 1: Tokenized Preview URL (preferred for automation)

Lovable generates a shareable preview URL containing a JWT access token:

https://preview--[app-name].lovable.app/?__lovable_token=eyJhbGciOiJSUzI1NiIs...

How the user captures it: 1. Open the Lovable project at lovable.dev 2. Make sure the right panel is in Preview mode (not code view) 3. Click the arrow icon at the top of the preview, next to the preview address bar ("open in new tab") 4. A new browser tab opens - the full URL in that tab contains ?__lovable_token=... 5. Copy the entire URL

Token properties:

• It's a JWT (three base64url segments separated by dots)
• Payload contains user_id, project_id, iat (issued at), exp (expiry)
• Valid for 7 days from issuance
• Grants access to the preview app for that project - treat it as a credential

Method 2: Logged-in Browser Session

If the user is logged in to Lovable in Chrome (with the Claude in Chrome extension connected), navigate to the bare preview URL (https://preview--[app-name].lovable.app/) or open the preview from within the Lovable editor. The session cookie provides access - no token needed.

Trade-offs: No token maintenance, but breaks if the user logs out, and requires the Chrome extension with an active session.

Access Priority (decision order)

1. preview-token.local exists AND token not expired
   → Navigate to: [preview_url]?__lovable_token=[token]

2. Token missing/expired, Access Method is browser-login OR user likely logged in
   → Navigate to bare preview URL
   → If app loads (not a login/denied page) → proceed
   → If login wall appears → fall through to 3

3. Ask the user:
   "I need access to your Lovable Preview to run tests. Either:
    A) Log in to Lovable in Chrome, or
    B) Paste a fresh preview URL with token:
       (Lovable project → preview mode → click the arrow icon next to
        the address bar → copy the URL from the new tab)"

4. If browser automation itself is unavailable
   → Output manual test checklist (never block)

Storing Access Safely

The token is a credential. NEVER:

• Commit it to git
• Write it into CLAUDE.md
• Write it into test-config.json
• Echo the full token back in chat output (refer to it as "stored token")

Storage layout:

`preview-token.local` format (token string only, single line):

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoi...

Gitignore enforcement: when scaffolding the workspace, ensure the project's .gitignore contains:

.claude/lovable-claude/test/preview-token.local

If .gitignore is missing the entry, add it BEFORE writing the token file.

Parsing a Pasted Preview URL

When the user pastes a full tokenized URL:

1. Split at ?__lovable_token=:

• Left part → preview_url (strip trailing / and ?)
• Right part → token (strip any additional query params after &)

2. Validate the token shape: three dot-separated base64url segments 3. Decode the payload (second segment, base64url → JSON) to extract:

• exp → expiry as unix timestamp → store as ISO date in token_expires
• iat → captured date → store in token_captured
• project_id → sanity check against lovable_url in CLAUDE.md if available

4. Write:

• Token → preview-token.local
• URL + dates → test-config.json

5. Confirm to the user (without echoing the token):

   ✅ Preview access configured
   - Preview URL: https://preview--my-app.lovable.app
   - Token valid until: 2026-06-17 (7 days)
   - Token stored in preview-token.local (gitignored)

Decoding exp example (shell):

echo "[middle-segment]" | tr '_-' '/+' | base64 -d 2>/dev/null | head -c 1000
# → {"user_id":"...","project_id":"...","exp":1781707140,...}

Expiry Handling

Before every test run: 1. Read token_expires from test-config.json 2. If today ≥ expiry date (or within 12 hours of it) → treat as expired 3. If expired:

• Try Method 2 (logged-in session) silently first
• If that fails, prompt for a fresh URL:

🔑 Your preview token expired on [date] (tokens last 7 days).

To capture a fresh one:
1. Open your Lovable project, switch to preview mode
2. Click the arrow icon at the top, next to the address bar
3. Copy the URL from the new tab and paste it here

Or just log in to Lovable in Chrome and I'll use your session.

4. On receiving a new URL, re-run the parsing procedure above

Detecting a rejected token at runtime: if navigation with a token lands on an error page, access-denied message, or Lovable login screen, treat it the same as expiry (the token may have been revoked) and re-prompt.

Verifying Access Works

After configuring access (and at the start of each test session), do a quick access check:

1. Navigate to the preview URL (with token if using Method 1) 2. Wait for page load (up to 30s - preview cold starts can be slow) 3. Success: app content renders (root element populated, no Lovable login/error page) 4. Read console for fatal errors 5. Report:

   ✅ Preview access verified - app loaded at [preview_url]

or the appropriate error + fallback from SKILL.md.

Test Execution: Running Plans in Lovable Preview

Browser automation workflow for /lovable:test-run and automatic post-implementation / post-deploy runs.

Prerequisites Check

Before any run:

1. Workspace exists: .claude/lovable-claude/test/test-config.json present

• If not: "No test workspace found. Run /lovable:test-init first."

2. Preview access valid: per preview-access.md (token unexpired, or logged-in session) 3. Browser automation available: Claude in Chrome extension connected

• If not → manual fallback (below)

4. Code is synced: if there are unpushed commits or a push happened < sync_wait_seconds ago, the Preview may not reflect the latest code (see "Sync wait")

Selecting Plans

Run order: smoke plans first, then by priority (high → low), then by ID. If a login-dependent plan is selected, ensure an auth plan or login step runs first in the same session.

Sync Wait

The Preview reflects code synced from GitHub. After a push:

1. Note push time
2. Wait sync_wait_seconds (default 120s) OR poll:
   - Reload preview, check for a marker of the new change (new text/element)
   - Poll every 20s, max 3 minutes
3. If unsure whether sync landed, say so in the result:
   "⚠️ Could not confirm Preview reflects commit abc1234 - results may be stale"

Execution Workflow (per plan)

Performance: model and tool choices

Same hybrid approach as the yolo skill:

• Haiku-level operations: clicking refs, form_input fills, key presses, navigation, polling
• Sonnet-level operations: page understanding, deciding pass/fail, error diagnosis
• Prefer read_page/find + refs over screenshots; form_input over click+type

Steps

1. Resolve profile: load profiles/[plan.profile].json; substitute {profile.xxx} and {timestamp} placeholders in steps

2. Navigate to start:

• URL = preview_url + plan's starting route
• Append ?__lovable_token=[token] on the FIRST navigation of the session (token sets a session; subsequent navigations within the tab usually don't need it - re-append if access is lost)
• Wait for app render (root populated), up to 30s cold start

3. Open observation channels:

• Clear/read console messages baseline
• Note network request baseline

4. Execute each step from the plan's steps table:

• Perform the Action (click / fill / navigate / wait)
• Verify the Expected Result:
• UI: element/text present via find or read_page
• URL: current URL matches expectation
• Console: no new errors (ignore third-party noise per yolo testing-procedures filtering rules)
• Network: expected request fired with expected status
• On match → step PASS, continue
• On mismatch → retry verification once after 3s (async rendering), then step FAIL
• [MANUAL] steps → stop automation, ask the user to perform it, or mark plan blocked if unattended

5. On step failure:

• Capture: failing step number, expected vs actual, console errors, failed network requests (status + response body if readable)
• Stop the plan (later steps depend on earlier ones)
• Mark plan FAIL, continue with the NEXT plan (don't abort the run)

6. Cleanup: perform the plan's Cleanup section (e.g., delete created test entities) when feasible

Recording Results

After the run:

1. Write results/[YYYY-MM-DD]-[run-slug].md per test-plan-format.md 2. Update each executed plan's frontmatter: last_run, last_result 3. Report a summary to the user:

🧪 Preview Test Run - smoke suite (3 plans)

✅ TP-001 User signup with email (38s)
✅ TP-002 Login and logout (21s)
❌ TP-004 Invite team member - failed at step 3
   Expected: success toast
   Actual: POST /functions/v1/send-invite → 500
   "RESEND_API_KEY is not configured"

Result: 2/3 passed
📄 Full report: .claude/lovable-claude/test/results/2026-06-10-smoke.md

Suggested fix for TP-004: add RESEND_API_KEY in Cloud → Secrets, redeploy, re-run:
/lovable:test-run TP-004

4. Offer to fix failures: when a failure traces to code (not config), offer to investigate and fix it now. After fixing + pushing, re-run the failed plan.

Manual Fallback

If browser automation is unavailable or repeatedly fails, never block:

❌ Can't run automated preview tests ([reason])

Manual checklist for TP-001 (User signup with email):
1. Open [preview_url with token note]
2. Go to /signup - expect: form with email + password
3. Fill test+[timestamp]@example.com / TestPass!2026 - expect: no validation errors
4. Click "Sign up" - expect: redirect to /dashboard
5. Check DevTools console - expect: no errors

Tell me the results and I'll record them in results/.

If the user reports results, write the result file with Trigger: manual (user-executed).

Safety Rules

• Test against Preview, not production - unless the user explicitly asks for a production smoke check
• Never execute real payments, real bulk sends, or destructive operations on non-test data - those steps are [MANUAL] by format rules; honor them
• Only test apps the user owns - the preview URL/token comes from the user's own Lovable project
• Don't echo tokens in output, results files, or commit messages
• Test data should be clearly synthetic (test+ emails, "Test" prefixed names) so it's identifiable and cleanable

Test Workspace: Standardized File Formats

Every file in .claude/lovable-claude/test/ follows these formats. Always use them - consistency is what lets /lovable:test-run and /lovable:test-sync work reliably across sessions.

Folder Layout

.claude/lovable-claude/test/
├── README.md              # Workspace explanation (template below)
├── test-config.json       # Settings + coverage state
├── preview-token.local    # Token only - MUST be gitignored
├── plans/
│   └── TP-[NNN]-[slug].md
├── profiles/
│   └── [name].json
└── results/
    └── [YYYY-MM-DD]-[run-slug].md

test-config.json

{
  "version": 1,
  "preview_url": "https://preview--my-app.lovable.app",
  "access_method": "token",
  "token_captured": "2026-06-10",
  "token_expires": "2026-06-17",
  "production_url": "https://my-app.lovable.app",
  "test_after_implementation": true,
  "test_after_deploy": "smoke",
  "last_synced_commit": "abc1234",
  "last_synced_at": "2026-06-10T14:30:00Z",
  "plan_counter": 7,
  "default_profile": "default",
  "sync_wait_seconds": 120
}

Field notes:

• access_method: "token" or "browser-login"
• token_captured / token_expires: dates only - the token itself lives in preview-token.local
• last_synced_commit: git hash at last /lovable:test-init or /lovable:test-sync - the baseline for detecting untested features
• plan_counter: highest TP number issued (next plan = counter + 1)
• test_after_deploy: "off", "smoke", or "all"
• sync_wait_seconds: how long to wait after git push before testing (GitHub → Lovable sync time)

Test Plan: plans/TP-NNN-slug.md

One file per plan. ID format TP-001, TP-002, ... with a kebab-case slug.

---
id: TP-001
title: User signup with email
feature: Authentication
priority: high          # high | medium | low
tags: [smoke, auth]     # "smoke" tag = included in smoke runs
profile: default        # profile from profiles/ to use
covers:                 # code this plan covers (used by /test-sync)
  - src/pages/Signup.tsx
  - src/hooks/useAuth.ts
  - supabase/functions/send-welcome
status: active          # active | draft | deprecated
created: 2026-06-10
updated: 2026-06-10
last_run: 2026-06-10
last_result: pass       # pass | fail | blocked | never-run
---

# TP-001: User signup with email

## Objective
Verify a new user can sign up with email/password and lands on the dashboard.

## Preconditions
- Preview app accessible
- Email used must not already exist (use timestamped email from profile pattern)

## Steps

| # | Action | Expected Result |
|---|--------|-----------------|
| 1 | Navigate to `/signup` | Signup form visible with email, password fields |
| 2 | Fill email with `{profile.email_pattern}` and password `{profile.password}` | Fields accept input, no validation errors |
| 3 | Click "Sign up" button | Loading state, then redirect to `/dashboard` |
| 4 | Check dashboard | Welcome message shows; no console errors |
| 5 | Check network | POST to auth endpoint returned 200 |

## Cleanup
- None required (test accounts are throwaway)

## Notes
- Welcome email sending (send-welcome function) is verified only by absence of errors - actual delivery is out of scope.

Conventions:

• Steps table is the contract: each row has one Action and one verifiable Expected Result
• {profile.xxx} placeholders resolve from the profile JSON at run time
• covers: paths let /test-sync map code changes → affected plans (--changed mode)
• Tag smoke for the minimal always-run set (post-deploy verification)
• Destructive/paid actions (real payments, mass emails): mark the step [MANUAL] - automation stops there and asks the user, or skips with blocked status

Test Profile: profiles/name.json

Test personas and accounts. Test credentials only - never real user passwords or production secrets.

{
  "name": "default",
  "description": "Standard throwaway test user",
  "email_pattern": "test+{timestamp}@example.com",
  "email": "claude-test@example.com",
  "password": "TestPass!2026",
  "role": "user",
  "seed_data": {
    "display_name": "Claude Test",
    "company": "Test Co"
  },
  "notes": "email_pattern with {timestamp} generates unique signup emails; fixed email is for login tests (account must exist in preview DB)."
}

• {timestamp} in patterns → replace with unix timestamp at run time for uniqueness
• An admin.json, viewer.json, etc. for role-based testing
• If a profile's fixed account doesn't exist yet, the wizard/run should create it via the signup flow first (and note it)

Test Result: results/YYYY-MM-DD-run-slug.md

One file per run (a run may cover multiple plans). Slug examples: 2026-06-10-smoke, 2026-06-10-TP-001, 2026-06-10-all.

# Test Run: 2026-06-10 - smoke suite

- **Trigger**: post-deploy (yolo) | manual | post-implementation
- **Preview URL**: https://preview--my-app.lovable.app
- **Access**: token (expires 2026-06-17)
- **Commit tested**: abc1234
- **Plans run**: 3 | ✅ 2 pass | ❌ 1 fail | ⏭️ 0 blocked

## TP-001: User signup with email - ✅ PASS
All 5 steps passed. Duration: 38s.

## TP-002: Create project - ✅ PASS
All 4 steps passed. Duration: 22s.

## TP-004: Send invitation - ❌ FAIL
- Failed at step 3: "Click Send invite"
- Expected: success toast appears
- Actual: console error `POST /functions/v1/send-invite 500`
  `{"error":"RESEND_API_KEY is not configured"}`
- Diagnosis: missing secret in Lovable Cloud
- Suggested fix: add RESEND_API_KEY in Cloud → Secrets, then redeploy

## Follow-ups
- [ ] Configure RESEND_API_KEY and re-run TP-004

After each run, also update each plan's frontmatter: last_run, last_result.

README.md (workspace)

Generated once at scaffold time:

# Lovable Preview Test Workspace

Managed by the lovable-claude-code plugin (`/lovable:test-*` commands).

- `test-config.json` - settings, preview URL, coverage state
- `preview-token.local` - preview access token (gitignored, valid 7 days)
- `plans/` - test plans (TP-NNN). Edit freely; keep the steps table format.
- `profiles/` - test user personas. Test credentials only - never real secrets.
- `results/` - test run reports (newest = current state)

Commands:
- `/lovable:test-run [TP-NNN | --all | --changed | --smoke]` - run tests in Lovable Preview
- `/lovable:test-sync` - update plans for new/changed features
- `/lovable:test-init` - re-run the setup wizard

ID and Naming Rules

• Plan IDs: TP- + zero-padded 3-digit number, never reused (deprecate, don't delete, plans that no longer apply: set status: deprecated)
• Slugs: kebab-case, short, from the title
• Result files: ISO date prefix for sorting
• Profile names: lowercase, single word where possible

Test Wizard: Scanning and Guided Plan Creation

Procedure for /lovable:test-init - scan the codebase, identify the app's main user actions, and guide the user through creating test plans.

Phase 1: Codebase Scan

Goal: build a candidate list of main user actions the app supports. Scan based on architecture (detected via vite.config.ts vs app.config.ts, same as /lovable:init).

1. Routes / Pages

• Vite SPA: parse src/App.tsx for <Route path=...>; list src/pages/*.tsx
• TanStack Start: list app/routes/**/*.tsx (filename = URL)

Each route is a candidate test surface. Classify:

• Public pages (landing, about) → low priority "renders correctly" plans
• Auth pages (login, signup, reset) → high priority flow plans
• App pages (dashboard, settings, CRUD views) → medium/high priority flow plans

2. Forms and Mutations

Search for user actions that change state:

• onSubmit, <form, useMutation, .insert(, .update(, .delete(, .upsert(
• Supabase auth calls: signUp, signInWithPassword, signInWithOAuth, signOut, resetPasswordForEmail
• Edge function invocations: supabase.functions.invoke("name"), fetch(".../functions/v1/

Each distinct mutation = a candidate test plan, with covers: pointing at the implementing files.

3. Edge Functions and Migrations

• List supabase/functions/* - each function that's user-triggered gets covered by the flow plan that invokes it; note functions with NO frontend caller (webhook-style) as "manual/API-only test" candidates
• Skim supabase/migrations/ for core tables → informs what entities CRUD plans should cover

4. Roles and Profiles

Detect role/permission patterns (role, is_admin, RLS-related code, route guards). Each distinct role → candidate test profile.

5. Existing unit tests

Check for test framework (vitest, jest, @testing-library in package.json; *.test.ts(x) files). Record whether unit tests exist - the maintenance loop ("add unit tests + test plans per feature") needs this.

Phase 2: Present Findings and Suggest Plans

Present a compact summary, then the suggested plan list:

📋 Test Wizard - here's what I found:

Routes: 8 (2 public, 3 auth, 3 app)
User actions detected:
- Sign up / Log in / Log out (src/hooks/useAuth.ts)
- Create / edit / delete project (src/pages/Projects.tsx)
- Invite team member → send-invite edge function
- Update profile settings (src/pages/Settings.tsx)
Roles detected: user, admin
Unit tests: none detected

Suggested test plans:
1. TP-001 User signup with email          [smoke, high]
2. TP-002 Login and logout                [smoke, high]
3. TP-003 Create a project                [smoke, high]
4. TP-004 Edit and delete a project       [medium]
5. TP-005 Invite team member              [high] (covers send-invite function)
6. TP-006 Update profile settings         [medium]
7. TP-007 Public pages render             [smoke, low]

Accept all, or tell me which to add/remove/change? (e.g. "all", "1-5 only", "add: password reset")

Phase 3: Guided Questions

Ask ONE at a time. Skip questions already answered by config/CLAUDE.md.

Q1: Preview access (skip if already configured)

How should I access your Lovable Preview for testing?

A) Paste a preview URL with token (recommended - works without login)
   Get it: open your Lovable project in preview mode, click the arrow
   icon at the top next to the address bar, copy the URL from the new tab.
   (Token is valid 7 days; I'll store it gitignored and ask again when it expires.)

B) I'm logged in to Lovable in Chrome - use my session

Reply A (then paste URL) or B:

Process per preview-access.md.

Q2: Plan selection

(The accept/modify question from Phase 2.)

Q3: Test profiles

I'll create test user profiles for: [detected roles]

For each, I need test credentials (TEST accounts only - never real passwords):
- Should I generate throwaway accounts via your signup flow? (recommended)
- Or do you have existing test accounts to use? (provide email/password per role)

Q4: Per-plan refinement (only for plans needing input)

For plans with ambiguous expected results or required test data, ask targeted questions:

For TP-005 (Invite team member):
- What should happen after sending an invite? (toast? email? pending list entry?)
- Safe to send invites to test+...@example.com addresses? (yes/no)

Q5: Automation settings

When should tests run?

A) After each implementation (I run affected plans automatically) + manual runs
B) Manual only (/lovable:test-run when you ask)

And after yolo auto-deploys (if yolo enabled): off / smoke / all?

Phase 4: Generate the Workspace

1. Create .claude/lovable-claude/test/{plans,profiles,results} directories 2. Ensure .gitignore contains .claude/lovable-claude/test/preview-token.local 3. Write preview-token.local (if token provided) - per preview-access.md 4. Write test-config.json with all settings + last_synced_commit = current git rev-parse --short HEAD 5. Write each accepted plan as plans/TP-NNN-slug.md per test-plan-format.md

• Derive concrete steps from the actual code: real route paths, real button labels (read the JSX), real field names
• Fill covers: with the implementing file paths

6. Write profiles/*.json 7. Write the workspace README.md 8. Add the Preview Testing Configuration section to the project's CLAUDE.md (template in CLAUDE-template.md)

Phase 5: Verify and Offer First Run

1. Run the access check from preview-access.md 2. Summarize:

✅ Test workspace created: .claude/lovable-claude/test/

- 7 test plans (4 smoke)
- 2 profiles (default, admin)
- Preview access: token (valid until 2026-06-17)
- Coverage baseline: commit abc1234

Run the smoke suite now to validate the setup? (yes/no)
→ /lovable:test-run --smoke

Writing Good Steps (quality bar)

• Read the actual component code before writing steps - use the real button text, placeholder text, and routes. Generic steps ("click the submit button") break automation.
• Every step's Expected Result must be observable: visible text, URL change, element appearing, console clean, network status code
• Keep plans at 3-8 steps; split longer journeys into multiple plans
• First plan(s) a new user would hit (signup/login) come first and get smoke
• Never include real payment execution, real bulk email, or data deletion of non-test data - mark those [MANUAL]