Yolo

Yolo Mode Automation Skill

This skill automates Lovable deployment workflows using either the Lovable MCP server (preferred) or Claude's browser automation as a fallback.

When to Activate

This skill should be active when:

1. Yolo mode is enabled in CLAUDE.md (yolo_mode: on) 2. User runs deployment commands:

• /deploy-edge - Edge function deployment
• /apply-migration - Database migration application

3. After git push to main (if auto_deploy: on):

• Automatically detect backend file changes
• Trigger deployment without manual command

4. User mentions yolo automation:

• "use yolo mode"
• "automate the Lovable prompt"
• "submit this to Lovable automatically"
• "browser automation"

Deployment Method Priority

When yolo mode triggers, always choose the deployment method in this order:

1. Lovable MCP (Preferred)

Check if Lovable MCP tools are available (look for send_message from a Lovable MCP connector):

• If available: Use the MCP workflow (references/mcp-workflows.md)
• Extract project ID from lovable_url in CLAUDE.md
• Call send_message(project_id, prompt)
• Poll for response if async
• Run verification tests as configured

• Why preferred: 3-5x faster, no Chrome extension needed, unaffected by UI changes

2. Browser Automation (Fallback)

If MCP is not available or Deployment Method: browser is set in CLAUDE.md:

• Use Claude's browser automation (references/automation-workflows.md)
• Navigate to Lovable, submit prompt via chat interface
• Monitor for response

3. Manual Prompt (Last Resort)

If both MCP and browser automation fail:

• Show the deployment prompt to the user for copy-paste into Lovable
• Never block the user - always provide a manual fallback

Checking Deployment Method

Read Deployment Method from the Yolo Mode Configuration section of CLAUDE.md:

• auto (default): Try MCP first, fall back to browser
• mcp: Use MCP only, fall back to manual prompt (skip browser)
• browser: Use browser automation only (skip MCP check)

---

Performance Optimization

Model Selection (Hybrid Approach)

For optimal speed + reliability, use different models for different tasks:

Use Haiku for:

• Clicking elements using refs (simple, deterministic)
• Form input operations (form_input tool calls)
• Key presses and simple navigation
• Waiting/polling operations
• Simple element finding with find tool

Use Sonnet for:

• Initial page understanding after navigation
• Error detection and recovery decisions
• Parsing Lovable's responses for success/failure
• Deciding next steps when something unexpected happens
• Complex page state analysis

Why this matters:

• Haiku is 3-5x faster for simple operations
• Sonnet provides better reliability for complex reasoning
• Hybrid approach gives best of both: speed + accuracy

Tool Preferences

Always prefer these tools:

• find and read_page over screenshots for element location
• form_input over click + type for input values
• ref parameters over coordinates for clicking
• DOM polling over screenshot-based monitoring

See references/automation-workflows.md for detailed implementation.

---

Core Functionality

1. Auto-Detection

When yolo mode is enabled, automatically detect when Lovable prompts are needed:

Edge Function Deployment:

• Files in supabase/functions/ modified
• Changes committed and pushed to main
• Deployment prompt generated

Migration Application:

• New files in supabase/migrations/
• Changes committed and pushed to main
• Migration prompt generated

See references/detection-logic.md for complete detection criteria.

1.5. Auto-Deploy After Git Push (NEW)

When auto_deploy: on is enabled, Claude automatically detects and deploys backend changes after a successful git push:

Trigger: Successful git push origin main

Detection: 1. Analyze files changed in the push 2. Check for supabase/functions/ or supabase/migrations/ changes 3. If backend files found AND auto_deploy enabled → trigger automation

Flow:

git push origin main [succeeds]
    ↓
Claude detects backend file changes
    ↓
Check: yolo_mode: on AND auto_deploy: on
    ↓
🤖 "Auto-deploy: Backend changes detected, starting deployment..."
    ↓
Execute browser automation
    ↓
Run verification tests
    ↓
Show deployment summary

Graceful Fallback: If auto-deploy fails for any reason:

• Show clear error message
• Provide manual prompt as fallback
• Never block the user

See references/post-push-automation.md for complete implementation.

2. Deployment Execution

When a deployment is needed, execute based on the chosen method:

MCP Method: 1. Extract project ID from lovable_url in CLAUDE.md 2. Call Lovable MCP send_message with the deployment prompt 3. Poll for completion if the response is async 4. Parse success/failure from response

See references/mcp-workflows.md for full MCP workflow.

Browser Automation Method: 1. Navigate to Lovable

• Read lovable_url from CLAUDE.md
• Open browser and navigate to project
• Handle login if needed

2. Submit Prompt

• Locate chat input element
• Type the generated Lovable prompt
• Submit and confirm message sent

3. Monitor Response

• Wait for Lovable's response
• Check for success indicators
• Detect errors or warnings
• Timeout after 3 minutes

See references/automation-workflows.md for detailed browser automation steps.

3. Testing & Verification

After successful deployment, run tests based on yolo_testing setting:

If `yolo_testing: on` (default):

• Level 1: Basic verification (check logs via Lovable)
• Level 2: Console error checking (monitor production URL)
• Level 3: Functional testing (test endpoints/queries)

If `yolo_testing: off`:

• Skip all testing
• Only confirm deployment success from Lovable response

Level 4 (optional): Preview test plans If the project has preview testing enabled (CLAUDE.md → Preview Testing Configuration) and Test After Deploy is smoke or all, run the corresponding test plans against the Lovable Preview app after deployment verification. This is handled by the testing skill (skills/testing/SKILL.md) - equivalent to /lovable:test-run --smoke (or --all).

See references/testing-procedures.md for complete testing workflows.

4. Debug Mode

When yolo_debug: on, provide verbose output:

🐛 DEBUG: Browser Automation

Step 1: Navigating to Lovable
  URL: https://lovable.dev/projects/abc123
  Wait for: Page load complete
  ✅ Success (1.2s)

Step 2: Locating chat interface
  Selector: textarea[data-testid="chat-input"]
  Wait for: Element interactable
  ✅ Found (0.3s)

Step 3: Typing prompt
  Text: "Deploy the send-email edge function"
  ✅ Typed (0.5s)

Step 4: Submitting
  Action: Press Enter
  ✅ Submitted (0.1s)

Step 5: Monitoring response
  Watching for: New message from assistant
  Timeout: 180s
  ✅ Response received (4.2s)

Response content:
"I'll deploy the send-email edge function now..."
[full response text]

Success keywords detected: ['deploy', 'function']
No error keywords found

Configuration in CLAUDE.md

The skill reads these fields from CLAUDE.md:

## Yolo Mode Configuration (Beta)

- **Status**: on
- **Deployment Method**: auto
- **Auto-Deploy**: on
- **Deployment Testing**: on
- **Auto-run Tests**: off
- **Debug Mode**: off
- **Last Updated**: 2025-01-03 10:30:00

Configuration options:

• Status: Enable/disable yolo mode entirely
• Deployment Method: auto (MCP first, then browser), mcp (MCP only), or browser (browser only)
• Auto-Deploy: Auto-deploy after git push (no manual command needed)
• Deployment Testing: Run verification tests after deployments
• Auto-run Tests: Run project test suite after git push
• Debug Mode: Show verbose automation logs

And from Project Overview:

- **Lovable Project URL**: https://lovable.dev/projects/abc123
- **Production URL**: https://my-app.lovable.app

User Notifications

Progress Updates

Show real-time progress during automation:

MCP Mode (debug off):

🤖 Yolo mode (MCP): Deploying send-email edge function

⏳ Sending deployment prompt via Lovable MCP...
✅ Deployment confirmed by Lovable (3.1s)
⏳ Running verification tests...
✅ All tests passed

Browser Mode (debug off):

🤖 Yolo mode: Deploying send-email edge function

⏳ Step 1/8: Navigating to Lovable project...
⏳ Step 2/8: Waiting for GitHub sync...
✅ Step 3/8: Sync verified - Lovable has latest code
✅ Step 4/8: Located chat interface
✅ Step 5/8: Submitted prompt
⏳ Step 6/8: Waiting for Lovable response...
✅ Step 7/8: Deployment confirmed
⏳ Step 8/8: Running verification tests...
✅ Step 8/8: All tests passed

Debug Mode (debug on): Include detailed logs with timing, selectors, and full responses.

Deployment Summary

After automation completes:

## Deployment Summary

**Operation:** Edge Function Deployment
**Function:** send-email
**Status:** ✅ Success
**Duration:** 45 seconds

**Automation Steps:**
1. ✅ Navigated to Lovable
2. ✅ Submitted deployment prompt
3. ✅ Received deployment confirmation

**Verification Tests:** (if testing enabled)
1. ✅ Basic verification: Deployment logs show no errors
2. ✅ Console check: No errors at production URL
3. ✅ Functional test: Function endpoint responds (200 OK)

**Production Status:**
- Function is live and responding
- No errors detected
- Ready for use

💡 Yolo mode is enabled. I'll continue automating deployments.
   Run `/yolo off` to disable.

Error Handling

All automation failures fall back gracefully to manual prompts:

Common Errors

MCP not connected (auto mode - will try browser next):

⚠️ Lovable MCP not connected - trying browser automation...
[continues with browser automation]

MCP not connected (mcp-only mode):

❌ Lovable MCP not available

Deployment Method is set to "mcp" but Lovable MCP tools are not connected.

To connect: /lovable:connect-mcp
To use browser automation instead: /lovable:yolo on --browser

Fallback - run this prompt manually in Lovable:
📋 "Deploy the send-email edge function"

Browser automation not available:

❌ Browser automation unavailable

Yolo mode requires the Claude in Chrome extension.

Install: https://chrome.google.com/webstore/detail/claude/...

Tip: Use Lovable MCP instead (no extension needed):
  /lovable:connect-mcp

Fallback - run this prompt manually in Lovable:
📋 "Deploy the send-email edge function"

Login required:

🔐 Please log in to Lovable

The browser opened to your Lovable project, but you're not logged in.
Please log in and I'll retry automatically.

Or run this prompt manually:
📋 "Deploy the send-email edge function"

UI element not found:

❌ Could not locate Lovable chat interface

The Lovable UI may have changed since this plugin was created.

Fallback - run this prompt manually in Lovable:
📋 "Deploy the send-email edge function"

💡 Please report this issue at:
   https://github.com/10kdigital/lovable-claude-code/issues

Timeout:

⏱️ Lovable hasn't responded after 3 minutes

The operation may still be processing.
Please check Lovable manually to verify status.

Prompt that was submitted:
📋 "Deploy the send-email edge function"

Deployment failed:

❌ Deployment failed in Lovable

Error from Lovable:
[captured error message]

Suggested fixes:
- Check function code for syntax errors
- Verify required secrets are set in Cloud → Secrets
- Review function logs in Lovable

Would you like me to:
1. Review the function code for issues
2. Check if secrets are documented in CLAUDE.md
3. Show you how to access logs in Lovable

Graceful Degradation

When automation fails: 1. Capture error details 2. Show user-friendly error message 3. Provide manual prompt as fallback 4. Suggest troubleshooting steps 5. Offer to disable yolo mode if errors persist

Never fail silently - always inform user and provide manual options.

Integration with Other Commands

/deploy-edge

When yolo mode is on, /deploy-edge automatically triggers browser automation:

[... existing deploy-edge logic ...]

## Deployment Execution

1. Check yolo mode status from CLAUDE.md

2. If `yolo_mode: on`:
   - Activate yolo skill
   - Execute browser automation workflow
   - Run tests based on `yolo_testing` setting
   - Report results

3. If `yolo_mode: off`:
   - Show manual prompt (current behavior)
   - Suggest enabling yolo mode

/apply-migration

Same pattern as deploy-edge for migration workflows.

/yolo

The /yolo command controls this skill:

• /yolo on - Enables skill by setting yolo_mode: on
• /yolo off - Disables skill
• Accepts flags: --testing, --no-testing, --debug

Beta Status & Limitations

Beta Warning

Yolo mode is in beta - users should be aware:

✅ What works well:

• Automated prompt submission via MCP (preferred) or browser
• Basic deployment verification
• Error handling with manual fallback

⚠️ Known limitations (MCP mode):

• Requires Lovable Pro plan
• Requires initial OAuth setup (/lovable:connect-mcp)
• Uses Lovable credits for send_message calls

⚠️ Known limitations (browser mode):

• Requires Claude in Chrome extension
• Lovable UI changes may break automation
• User must be logged into Lovable

⚠️ Shared limitations:

• Testing adds 1-3 minutes per deployment
• Only works for edge functions and migrations (not tables, RLS, etc.)

When to Recommend Yolo Mode

✅ Good for:

• Frequent deployments (saves time)
• Users comfortable with browser automation
• Development workflows (fast iteration)

❌ Not ideal for:

• One-off deployments (manual is faster)
• Production deployments requiring extra review
• Users without Chrome extension
• Environments without browser access

Future Enhancements

Not yet implemented, but could be added:

1. Batch operations

• Deploy multiple edge functions at once
• Apply multiple migrations in sequence

2. Rollback support

• Detect deployment failures
• Offer to rollback via Lovable

3. Monitoring mode

• Periodically check logs
• Alert on new errors

4. Custom test scripts

• User-defined test payloads
• Stored in CLAUDE.md

5. Broader operation support

• Table creation
• RLS policies
• Storage buckets

Reference Files

This skill uses these reference documents:

1. `references/mcp-workflows.md` (NEW - preferred)

• Lovable MCP send_message workflow
• Project ID extraction
• MCP error handling and fallbacks

2. `references/automation-workflows.md`

• Browser automation step-by-step
• Lovable UI navigation
• Element selectors and wait conditions

3. `references/detection-logic.md`

• When to trigger automation
• File change detection
• Integration with commands

4. `references/post-push-automation.md`

• Auto-deploy after git push
• Graceful fallback handling
• User notification templates

5. `references/testing-procedures.md`

• Level 1: Basic verification
• Level 2: Console checking
• Level 3: Functional testing

Quick Reference

Check if Yolo Mode is Active

1. Read CLAUDE.md
2. Look for "Status: on" in Yolo Mode Configuration
3. If not found or "off", yolo mode is disabled

Check if Auto-Deploy is Enabled

1. Read CLAUDE.md
2. Check both "Status: on" AND "Auto-Deploy: on"
3. Both must be enabled for auto-deploy to trigger

Execute Automation

1. Confirm yolo_mode is on
2. Read Deployment Method from CLAUDE.md (auto / mcp / browser)
3. If auto or mcp:
   - Check if Lovable MCP tools are available
   - If yes → Load mcp-workflows.md and execute MCP workflow
   - If no and auto → fall through to browser
4. If auto or browser:
   - Load automation-workflows.md
   - Execute navigation → submit → monitor workflow
5. Run tests if yolo_testing is on
6. Report results

Auto-Deploy After Git Push

1. Git push succeeds
2. Check for backend file changes (supabase/functions/, supabase/migrations/)
3. If changes found AND auto_deploy enabled:
   - Trigger automation automatically
   - Show: "🤖 Auto-deploy: Backend changes detected..."
4. If auto_deploy disabled:
   - Show notification only
   - Suggest running /deploy-edge or /apply-migration

Handle Errors

1. Try automation
2. If fails, capture error
3. Show error + manual fallback prompt
4. Never block user - always provide manual option
5. Suggest troubleshooting based on error type

---

This skill enables hands-free Lovable deployments while maintaining safety through manual fallbacks and comprehensive testing.

Yolo Mode: Browser Automation Workflows

Complete reference for browser automation when yolo mode is enabled.

Overview

This document provides step-by-step instructions for automating Lovable prompt submission using Claude's browser automation capabilities.

Performance Principles

To maximize speed and reliability, this automation follows these principles:

Use ref Parameters Instead of Coordinates

• Always use read_page and find tools to get element references
• Click elements using ref="ref_X" instead of coordinate-based (x, y) clicks
• This eliminates "clicking wrong places" issues entirely

Use form_input Instead of Typing

• Set input values directly using form_input(ref=X, value="...")
• Avoids character-by-character typing which is slow (~50ms per char) and error-prone
• Results in 20x faster prompt entry with zero mistyping

Minimize Screenshots

• Use read_page to understand page state (fast, deterministic)
• Only take screenshots on errors or for final user confirmation
• Screenshots are slow (~1-2s each) and add unnecessary latency

Model Selection (Hybrid Approach)

For optimal speed + reliability:

• Use Haiku for: clicking refs, form inputs, key presses, waiting
• Use Sonnet for: initial page understanding, error handling, parsing responses

Prerequisites

• Claude in Chrome extension installed
• User logged into Lovable.dev
• lovable_url configured in CLAUDE.md
• yolo_mode: on in CLAUDE.md

Trigger Modes

1. Auto-Deploy Mode (Recommended)

When auto_deploy: on:

• Triggered automatically after git push origin main
• Claude detects backend file changes and starts deployment
• No manual command needed

2. Command-Triggered Mode

When auto_deploy: off or using manual commands:

• Triggered by /deploy-edge or /apply-migration commands
• User explicitly initiates deployment

Core Automation Workflow

Step 1: Navigate to Lovable Project

Goal: Open the Lovable project page in the browser.

IMPORTANT: After navigation, you MUST wait for GitHub sync before submitting any deployment prompts. See Step 1.5.

1. Read configuration:

   - Read CLAUDE.md
   - Extract `lovable_url` field
   - Example: "https://lovable.dev/projects/abc123"

2. Open browser:

   - Use Claude's browser automation to navigate
   - Target URL: [lovable_url from CLAUDE.md]
   - Wait for: Page load complete

3. Check for login:

   - If URL redirects to /login or /signin:
     → User not logged in
     → Show message: "Please log in to Lovable"
     → Wait for user to log in
     → Retry navigation

   - If URL stays on project page:
     → User is logged in
     → Proceed to next step

4. Verify project page loaded:

   - Wait for: Chat interface to appear
   - Timeout: 10 seconds
   - If timeout:
     → Error: "Could not load Lovable project page"
     → Fall back to manual prompt

Debug output (if `yolo_debug: on`):

🐛 DEBUG: Step 1 - Navigate to Lovable

URL: https://lovable.dev/projects/abc123
Status: Navigating...
Wait: Page load event
Result: ✅ Loaded (1.2s)
Current URL: https://lovable.dev/projects/abc123
Login status: Authenticated

---

Step 1.5: Wait for GitHub Sync (CRITICAL)

Goal: Verify Lovable has synced the latest code from GitHub before deployment.

Why this matters: Lovable syncs from GitHub asynchronously (typically 1-2 minutes). If we submit a deployment prompt before sync completes, Lovable will deploy stale code.

OPTIMIZED APPROACH: Use DOM-based detection instead of visual scanning for speed and reliability.

1. Navigate to project immediately (no initial wait):

   - Go directly to Lovable project page after git push
   - Don't wait 30 seconds first - sync detection starts immediately

2. DOM-Based Sync Detection (FAST & RELIABLE):

   Use read_page or JavaScript to find sync confirmation:

   METHOD 1: Use read_page to search accessibility tree
   - Call read_page(tabId=X)
   - Search for text containing commit message (first ~30 chars)
   - Look for elements with "github" or commit text in their content

   METHOD 2: Use JavaScript for direct DOM query
   - Use javascript_tool to run:

// Get all text content from sidebar const sidebar = document.querySelector('[data-sidebar]') || document.querySelector('.sidebar') || document.querySelector('nav'); const text = sidebar?.textContent || ''; // Check if commit message appears text.includes('YOUR_COMMIT_MESSAGE_PREFIX')

   METHOD 3: Use find tool
   - Call find(query="conversation item with YOUR_COMMIT_MESSAGE", tabId=X)
   - If element found with matching text, sync is confirmed

   WHY THIS IS BETTER:
   - No screenshots needed (saves ~1-2s per check)
   - Deterministic - text matching vs visual icon recognition
   - Faster polling interval possible (2s vs 4s)
   - More reliable - doesn't depend on icon rendering

3. Verification loop (optimized):

   attempts = 0
   max_attempts = 30  # 2s each = 60 seconds max (faster checks)
   commit_prefix = first 30 chars of commit message

   # Check immediately first using read_page
   page_content = read_page(tabId=X)
   if commit_prefix in page_content:
     → Sync confirmed, proceed to Step 2

   # If not found, wait and retry
   while not synced and attempts < max_attempts:
     wait 2 seconds  # Faster than 4s since no screenshot overhead
     page_content = read_page(tabId=X)
     if commit_prefix in page_content:
       → Sync confirmed, proceed to Step 2
       break
     attempts++

   if not synced after max_attempts:
     → Show sync timeout warning
     → Offer options to user

4. If sync verified:

   ✅ Step 2/8: Sync verified - Lovable has latest code
      Commit: abc1234 "Add email notifications"

5. If sync times out:

   ⚠️ Sync verification timeout

   Lovable hasn't synced the latest changes after 60 seconds.

   **Options:**
   1. Wait and retry (I'll check again in 30s)
   2. Proceed anyway (may deploy stale code)
   3. Cancel and verify manually

   What would you like to do?

6. Handle sync timeout user choice:

   If user chooses "retry":
     → Wait 30s, check again
     → Up to 2 more attempts

   If user chooses "proceed":
     → Continue with warning
     → Note in summary: "⚠️ Deployed without sync verification"

   If user chooses "cancel":
     → Show manual fallback prompt
     → Exit automation

Debug output (if `yolo_debug: on`):

🐛 DEBUG: Step 1.5 - GitHub Sync Verification (DOM-based)

Commit just pushed:
  Hash: abc1234
  Message: "Add email notifications"
  Search prefix: "Add email notifications"

Sync check #1 (0s - immediate):
  Method: read_page DOM query
  Looking for: "Add email notifications"
  Result: Not found yet

Sync check #2 (2s):
  Method: read_page DOM query
  Looking for: "Add email notifications"
  Result: Not found yet

Sync check #3 (4s):
  Method: read_page DOM query
  Found: ✅ Text "Add email notifications feat..." in sidebar
  Status: ✅ Synced

Result: ✅ Sync verified (4s) - DOM-based detection is faster and more reliable!

---

Step 2: Locate Chat Interface

Goal: Find and prepare the CORRECT chat input element using ref-based approach.

CRITICAL: Use the LOWER LEFT corner chat input, NOT the top input for preview!

OPTIMIZED APPROACH: Use find tool to get element ref directly - no coordinates needed!

1. Use `find` tool for reliable element location:

   PREFERRED METHOD: Use find tool with natural language query
   - Call: find(query="Ask Lovable chat input textarea", tabId=X)
   - Returns: Element ref (e.g., ref_42) that can be used for all interactions
   - No coordinate calculations needed
   - Guaranteed to interact with correct element

   ALTERNATIVE: Use read_page + search
   - Call: read_page(tabId=X, filter="interactive")
   - Search for element with "Ask Lovable" in name/placeholder
   - Extract ref from matching element

   WHY THIS IS BETTER:
   - Refs are stable - clicking ref_42 always clicks that exact element
   - No viewport/resolution dependencies
   - No "clicking wrong places" issues
   - Works even if UI positions change

2. Store the element ref for later use:

   chatInputRef = result from find tool (e.g., "ref_42")

   This ref will be used in Step 3 for:
   - form_input(ref=chatInputRef, value="...")
   - No need to click to focus first

3. Verify element is correct (quick check):

   The find tool result includes element details:
   - role: "textbox" or "textarea"
   - name: should contain "Ask Lovable" or similar
   - If name doesn't match, search read_page results manually

4. If element not found:

   Error: "Could not locate chat interface"

   Possible reasons:
   - Lovable UI has changed
   - Page still loading
   - Wrong tab/window focused

   Recovery:
   1. Wait 2 seconds, retry find()
   2. If still not found, try read_page(filter="interactive") and search manually
   3. If still not found, fall back to manual prompt

   Fallback: Provide manual prompt to user

Debug output (if `yolo_debug: on`):

🐛 DEBUG: Step 2 - Locate Chat Interface (ref-based)

Method: find tool
Query: "Ask Lovable chat input textarea"
Result: ✅ Found

Element details:
  ref: ref_42
  role: textbox
  name: "Ask Lovable..."
  state: enabled, visible

Verification:
  ✅ Name contains "Ask Lovable"
  ✅ Element is enabled
  ✅ Ref stored for Step 3

Result: ✅ Chat input ref acquired (0.2s)

---

Step 3: Submit the Prompt

Goal: Enter the Lovable prompt and submit it.

OPTIMIZED APPROACH: Use form_input tool - 20x faster than typing, zero mistyping!

1. Use `form_input` to set prompt value (FAST):

   PREFERRED METHOD: Direct value setting
   - Call: form_input(ref=chatInputRef, value="Deploy the send-email edge function", tabId=X)
   - Sets the value instantly (~100ms total)
   - No clicking to focus needed
   - No character-by-character typing
   - Zero chance of mistyping

   WHY THIS IS BETTER:
   - Old approach: Click + type 40 chars × 50ms = ~2-3 seconds + possible typos
   - New approach: form_input = ~100ms, guaranteed accuracy
   - 20x faster with 100% reliability

2. Submit the prompt:

   PREFERRED: Press Enter using ref
   - Call: computer(action="key", text="Enter", tabId=X)
   - Wait: 200ms for form submission

   ALTERNATIVE: Click send button if Enter doesn't work
   - Call: find(query="send button", tabId=X)
   - Call: computer(action="left_click", ref=sendButtonRef, tabId=X)

3. Confirm message sent (quick DOM check):

   - Wait 1-2 seconds
   - Call: read_page(tabId=X) to check chat state
   - Look for user message containing our prompt text
   - Timeout: 5 seconds

   NOTE: No screenshot needed - DOM is faster and more reliable

4. If submission fails:

   Recovery steps:
   1. Try clicking send button instead of Enter
   2. If still fails, take screenshot for debugging
   3. Fall back to manual prompt

   Fallback: Provide manual prompt to user

Debug output (if `yolo_debug: on`):

🐛 DEBUG: Step 3 - Submit Prompt (form_input)

Method: form_input (instant)
Ref: ref_42
Value: "Deploy the send-email edge function"
Result: ✅ Value set (0.1s)

Submission method: Enter key
Result: ✅ Submitted (0.1s)

Confirmation: read_page DOM check
Looking for: User message with "Deploy the send-email"
Result: ✅ Message confirmed in DOM (0.3s)

Total time: 0.5s (vs ~2.5s with typing)

---

Step 4: Monitor Lovable's Response

Goal: Wait for Lovable to process the prompt and respond.

OPTIMIZED APPROACH: Use read_page polling instead of screenshots for speed.

1. Poll for assistant message using DOM:

   PREFERRED METHOD: read_page polling
   - Wait 2-3 seconds initial delay (let Lovable start processing)
   - Call: read_page(tabId=X)
   - Search for new assistant message in chat
   - Look for text that wasn't there before submission

   POLLING LOOP:
   while no response and elapsed < 180 seconds:
     wait 2 seconds
     content = read_page(tabId=X)
     check for new assistant message
     if found and not loading indicator present:
       → Response received, proceed to Step 5

   WHY THIS IS BETTER:
   - No screenshots needed (saves ~1-2s per check)
   - Faster polling (2s vs 5s with screenshots)
   - More reliable text extraction

2. Detect loading state:

   During polling, check for loading indicators in DOM:
   - Text containing "Thinking", "Generating", "Loading"
   - Elements with loading/spinner roles

   If loading indicator present:
     → Response in progress, keep waiting
   If loading gone + new text present:
     → Response complete, capture text

3. Capture response text:

   Once response detected:
   - Extract assistant message text from DOM
   - Store full text for Step 5 analysis
   - No screenshot needed unless debugging

4. If timeout (180 seconds):

   ⏱️ Lovable hasn't responded after 3 minutes

   The operation may still be processing.
   Please check Lovable manually to verify status.

   Prompt that was submitted:
   📋 "Deploy the send-email edge function"

   At this point: Take ONE screenshot for user reference

Debug output (if `yolo_debug: on`):

🐛 DEBUG: Step 4 - Monitor Response (DOM polling)

Method: read_page polling (2s interval)
Elapsed: 0s → 2s → 4s → 6s

Poll #1 (2s):
  New content: None yet
  Loading indicator: "Thinking..."
  Status: ⏳ Still processing

Poll #2 (4s):
  New content: Detected new text
  Loading indicator: None
  Status: ✅ Response complete

Response extracted:
  Length: 245 characters
  Content: "I'll deploy the send-email edge function now..."

Result: ✅ Response received (4s) - No screenshots used!

---

Step 5: Detect Success or Failure

Goal: Determine if the deployment was successful based on Lovable's response.

Success Indicators:

Look for these keywords in the response (case-insensitive):

For edge functions:

• "deploy" or "deployed"
• "function is live"
• "successfully deployed"
• "deployment complete"
• "available at"

For migrations:

• "migration applied"
• "database updated"
• "successfully ran"
• "schema updated"
• "migration complete"

Error Indicators:

Look for these keywords in the response:

• "error"
• "failed"
• "could not"
• "unable to"
• "invalid"
• "syntax error"
• "constraint"
• "permission denied"

Detection Logic:

1. Convert response to lowercase
2. Count success keywords found
3. Count error keywords found

4. If error keywords > 0:
   → Deployment failed
   → Extract error message
   → Show error to user

5. Else if success keywords > 0:
   → Deployment succeeded
   → Proceed to testing (if enabled)

6. Else:
   → Unclear response
   → Show response to user
   → Ask user to verify manually

Examples:

Success response:

"I'll deploy the send-email edge function now..."
→ Found: "deploy", "function"
→ No errors found
→ Status: ✅ Success

Error response:

"I encountered an error deploying the function. The syntax is invalid..."
→ Found: "error", "invalid"
→ Status: ❌ Failed
→ Error: "syntax is invalid"

Debug output (if `yolo_debug: on`):

🐛 DEBUG: Step 5 - Detect Success/Failure

Response analysis:
  Length: 245 characters
  Lowercase: "i'll deploy the send-email..."

Keyword search:
  Success keywords:
    - "deploy" → ✅ Found (position 6)
    - "deployed" → Not found
    - "function is live" → Not found
    - "successfully" → Not found

  Error keywords:
    - "error" → Not found
    - "failed" → Not found
    - "could not" → Not found

Result:
  Success keywords: 1
  Error keywords: 0
  Status: ✅ SUCCESS

---

Testing Workflows

When yolo_testing: on, run these verification tests after successful deployment.

Level 1: Basic Deployment Verification

Goal: Confirm deployment completed via Lovable's own confirmation.

For Edge Functions:

1. Ask Lovable for deployment logs:

   Submit follow-up prompt:
   "Show logs for [function-name] edge function"

   Wait for response (60 second timeout)

2. Check logs response:

   Success indicators in logs:
   - No deployment errors
   - Function shows as "active" or "running"
   - Recent timestamp matches deployment time

   Error indicators:
   - "no logs found"
   - Error messages in logs
   - Function shows as "inactive"

3. Report result:

   ✅ Basic verification: Deployment logs show no errors
   OR
   ⚠️ Basic verification: Logs show warnings
   OR
   ❌ Basic verification: Deployment errors in logs

For Migrations:

1. Ask Lovable for schema confirmation:

   Submit follow-up prompt:
   "Show me the [table-name] table structure"

   Wait for response (60 second timeout)

2. Check schema response:

   Success indicators:
   - Table exists
   - Columns match migration
   - No schema errors

   Error indicators:
   - "table does not exist"
   - Missing columns
   - Type mismatches

3. Report result:

   ✅ Basic verification: Migration applied (schema confirmed)
   OR
   ❌ Basic verification: Schema doesn't match migration

Debug output (if `yolo_debug: on`):

🐛 DEBUG: Level 1 - Basic Verification

Follow-up prompt: "Show logs for send-email edge function"
Response time: 2.1s
Response excerpt:
  "Here are the recent logs for send-email:
   [2024-01-15 10:30:00] Function deployed
   [2024-01-15 10:30:01] Function active
   No errors found."

Analysis:
  Deployment timestamp: Recent (< 1 min ago)
  Status: Active
  Errors: None found

Result: ✅ PASS (2.1s)

---

Level 2: Console Error Checking

Goal: Monitor the production URL for JavaScript and network errors.

1. Navigate to production URL:

   - Read `production_url` from CLAUDE.md
   - Example: "https://my-app.lovable.app"
   - Navigate to URL in new tab
   - Wait for: Page load complete

2. Open browser console:

   - Access browser developer tools
   - Navigate to Console tab
   - Clear existing console messages

3. Monitor for errors:

   Watch for (10-15 seconds):

   JavaScript errors:
   - Uncaught exceptions
   - Reference errors
   - Type errors

   Network errors:
   - Failed API calls (500, 404 status)
   - Edge function call failures
   - CORS errors

4. Capture and categorize errors:

   For each error found:
   - Source: Which file/line
   - Type: JS error, network error, etc.
   - Message: Full error text
   - Severity: Error vs Warning

   Filter out:
   - Third-party script errors (analytics, etc.)
   - Known warnings that are safe

5. Report findings:

   If no errors:
   ✅ Console check: No errors detected

   If warnings only:
   ⚠️ Console check: 2 warnings found (non-critical)

   If errors:
   ❌ Console check: 3 errors found
   - Network error: Edge function call to /send-email returned 500
   - JS error: Cannot read property 'data' of undefined (app.js:45)

Debug output (if `yolo_debug: on`):

🐛 DEBUG: Level 2 - Console Error Checking

Navigation:
  URL: https://my-app.lovable.app
  Load time: 1.8s
  Status: 200 OK

Console monitoring (15s):
  Errors: 0
  Warnings: 1
  Info: 5

Warning details:
  [1] DevTools: Third-party cookie warning
    Source: Chrome
    Severity: Low
    Filter: ✅ Ignored (third-party)

Network requests (during monitoring):
  Total: 12
  Success: 12
  Failed: 0

Result: ✅ PASS - No errors (0.1s monitoring)

---

Level 3: Functional Testing

Goal: Test that the deployed feature actually works.

For Edge Functions:

1. Determine function endpoint:

   Pattern: https://{supabase-ref}.supabase.co/functions/v1/{function-name}

   Get supabase-ref from:
   - CLAUDE.md (if documented)
   - Lovable response (if mentioned)
   - Ask user if not available

2. Determine test payload:

   Option A: Known test payload
   - If function has documented test data
   - Example: send-email might test with dummy email

   Option B: Ask user
   - "What test data should I send to test [function-name]?"
   - Wait for user input

   Option C: No-payload test
   - For functions that don't require input
   - Just check if endpoint responds

3. Make test request:

   - HTTP POST to function endpoint
   - Include: Auth headers (if needed), test payload
   - Timeout: 30 seconds
   - Capture: Status code, response body

4. Verify response:

   Success indicators:
   - Status code: 200-299
   - Response body: Expected structure
   - No error messages in body

   Failure indicators:
   - Status code: 400-599
   - Timeout
   - Error in response body

5. Report result:

   ✅ Functional test: Function responds correctly (200 OK)
   Response: {"success": true, "message": "Email sent"}

   OR

   ⚠️ Functional test: Function responds with error (500)
   Response: {"error": "SMTP connection failed"}

   OR

   ⏭️ Functional test: Skipped (no test payload available)
   To test manually: [show endpoint and example payload]

For Migrations:

1. Determine test query:

   Based on migration type:

   CREATE TABLE: "SELECT * FROM [table] LIMIT 1"
   ADD COLUMN: "SELECT [column] FROM [table] LIMIT 1"
   CREATE INDEX: "EXPLAIN SELECT * FROM [table] WHERE [indexed-column]"

2. Execute test query via Lovable:

   Submit prompt to Lovable:
   "Run this query: [test-query]"

   Wait for response (60 second timeout)

3. Verify query result:

   Success indicators:
   - Query executes without error
   - Returns expected structure
   - No permission errors

   Failure indicators:
   - "relation does not exist"
   - "column does not exist"
   - Permission denied

4. Report result:

   ✅ Functional test: Test query succeeded
   Query: SELECT * FROM users LIMIT 1
   Result: Table structure confirmed

   OR

   ❌ Functional test: Query failed
   Error: column "new_field" does not exist

Debug output (if `yolo_debug: on`):

🐛 DEBUG: Level 3 - Functional Testing

Function: send-email
Endpoint: https://abc123.supabase.co/functions/v1/send-email

Test payload:
  Method: POST
  Headers:
    Authorization: Bearer [token]
    Content-Type: application/json
  Body:
    {
      "to": "test@example.com",
      "subject": "Test",
      "body": "Test message"
    }

Request: Sending...
Response time: 1.2s
Status: 200 OK
Headers:
  Content-Type: application/json
Body:
  {
    "success": true,
    "messageId": "abc-123-def"
  }

Analysis:
  Status code: ✅ 200 (success range)
  Response structure: ✅ Valid JSON
  Error indicators: ❌ None found

Result: ✅ PASS (1.2s)

---

Error Handling Reference

Error Categories

1. Browser/Navigation Errors

Could not access browser:
→ Check Chrome extension installed
→ Check browser is running
→ Fallback: Manual prompt

Could not navigate to URL:
→ Check lovable_url is valid
→ Check internet connection
→ Fallback: Manual prompt

Login required:
→ Instruct user to log in
→ Retry automatically
→ Timeout after 2 minutes → manual prompt

2. UI Element Errors

Chat interface not found:
→ Try alternative selectors
→ Wait longer (Lovable may be loading)
→ If still not found → Manual prompt
→ Suggest reporting issue

Element not interactable:
→ Scroll into view
→ Wait for animations to complete
→ Remove overlays if present
→ If still blocked → Manual prompt

3. Submission Errors

Could not submit prompt:
→ Try Enter key
→ Try click send button
→ Try paste and submit
→ If all fail → Manual prompt

Message not confirmed:
→ Wait longer (up to 5s)
→ Check if message appeared later
→ If still not confirmed → Warn user, continue

4. Response Errors

Timeout (no response):
→ Warn: "3 minutes without response"
→ Suggest manual check
→ Show what prompt was submitted

Lovable returned error:
→ Parse error message
→ Show to user
→ Suggest fixes based on error type
→ Offer to help debug

5. Testing Errors

Test failed:
→ Show which test failed
→ Show specific error
→ Mark deployment as "⚠️ Deployed but test failed"
→ Suggest manual verification

Could not run test:
→ Skip that test level
→ Continue with remaining tests
→ Note in summary: "Some tests skipped"

Fallback Strategy

For ANY automation failure:

1. Capture the error 2. Show user-friendly message 3. Provide manual prompt as fallback:

   ❌ [Error description]

   Fallback: Here's the prompt to run manually in Lovable:
   📋 "Deploy the send-email edge function"

   [Context-specific troubleshooting]

4. Never block the user - always provide a way forward

---

User Notification Templates

Progress Notifications

Standard mode (debug off):

🤖 Yolo mode: Deploying send-email edge function

⏳ Step 1/8: Navigating to Lovable project...
⏳ Step 2/8: Waiting for GitHub sync...
✅ Step 3/8: Sync verified - Lovable has latest code
✅ Step 4/8: Located chat interface
✅ Step 5/8: Submitted prompt
⏳ Step 6/8: Waiting for Lovable response...
✅ Step 7/8: Deployment confirmed
⏳ Step 8/8: Running verification tests...
  ⏳ Basic verification...
  ⏳ Console error checking...
  ⏳ Functional testing...
✅ Step 8/8: All tests passed

✅ Complete! Edge function deployed and verified.

Summary Notifications

Success with all tests passed:

## Deployment Summary

**Operation:** Edge Function Deployment
**Function:** send-email
**Status:** ✅ Success
**Duration:** 45 seconds

**Automation Steps:**
1. ✅ Navigated to Lovable project
2. ✅ GitHub sync verified
3. ✅ Submitted deployment prompt
4. ✅ Deployment confirmed by Lovable

**Verification Tests:**
1. ✅ Basic verification: Deployment logs show no errors
2. ✅ Console check: No errors in browser console
3. ✅ Functional test: Function endpoint responds (200 OK)
   Response: {"success": true, "messageId": "abc-123"}

**Production Status:**
- Function is live at endpoint
- No errors detected
- Ready for use

💡 Yolo mode is still enabled. Run `/yolo off` to disable.

Success with test warnings:

## Deployment Summary

**Operation:** Edge Function Deployment
**Function:** send-email
**Status:** ⚠️ Deployed (with warnings)
**Duration:** 52 seconds

**Automation Steps:**
1. ✅ Navigated to Lovable project
2. ✅ GitHub sync verified
3. ✅ Submitted deployment prompt
4. ✅ Deployment confirmed by Lovable

**Verification Tests:**
1. ✅ Basic verification: Deployment logs show no errors
2. ⚠️ Console check: 1 warning found (non-critical)
   - Warning: "Rate limit approaching for Resend API"
3. ✅ Functional test: Function responds (200 OK)

**Recommendation:**
- Function deployed successfully
- Monitor the rate limit warning
- Consider upgrading Resend plan if needed

💡 Yolo mode is still enabled. Run `/yolo off` to disable.

Deployment succeeded but testing failed:

## Deployment Summary

**Operation:** Edge Function Deployment
**Function:** send-email
**Status:** ⚠️ Deployed (test failures)
**Duration:** 48 seconds

**Automation Steps:**
1. ✅ Navigated to Lovable project
2. ✅ GitHub sync verified
3. ✅ Submitted deployment prompt
4. ✅ Deployment confirmed by Lovable

**Verification Tests:**
1. ✅ Basic verification: Passed
2. ✅ Console check: Passed
3. ❌ Functional test: Failed
   Status: 500 Internal Server Error
   Error: "RESEND_API_KEY not found"

**Issue Found:**
The function deployed but isn't working because the RESEND_API_KEY
secret is missing.

**Next Steps:**
1. Go to Cloud → Secrets in Lovable
2. Add: RESEND_API_KEY = [your key]
3. Test the function again

Would you like me to help you find your Resend API key?

---

Configuration Options

Testing Control

Enable all tests (default):

yolo_testing: on

Runs all 3 testing levels after each deployment.

Disable all tests:

yolo_testing: off

Only deploys, no verification. Faster but less safe.

Debug Control

Enable debug output:

yolo_debug: on

Shows verbose logs with timing, selectors, full responses.

Disable debug output (default):

yolo_debug: off

Shows minimal progress indicators only.

---

Screenshot Policy

To maximize performance, follow these guidelines for screenshot usage:

DO Take Screenshot:

• On errors - Capture state for debugging when something fails
• Final confirmation - One screenshot after deployment completes (optional)
• User request - If user explicitly asks to see what happened
• Debugging mode - When yolo_debug: on and investigating issues

DO NOT Take Screenshot:

• For element location - Use read_page and find tools instead
• For sync verification - Use DOM-based text search
• Between each step - Too slow, use DOM polling
• For response monitoring - Use read_page to check chat state
• For success detection - Parse text from DOM, not screenshot

Why This Matters:

• Each screenshot adds ~1-2 seconds latency
• Old approach: 5-8 screenshots = 5-16 seconds of overhead
• New approach: 1-2 screenshots = 1-4 seconds of overhead
• 75% reduction in screenshot-related latency

---

Performance Notes

Optimized timing (with ref-based approach):

• Navigation: 1-2s
• Element location: 0.1-0.2s (using find/read_page)
• Prompt submission: 0.1-0.3s (using form_input)
• Sync verification: 2-10s (DOM polling every 2s)
• Lovable response: 3-10s
• Basic verification: 2-5s
• Console checking: 10-15s
• Functional testing: 1-5s

Total automation time (optimized):

• Without testing: ~5-12s (was 15-45s)
• With testing: ~15-30s (was 20-40s)

Improvement summary:

Timeout limits:

• Page load: 10s
• Element finding: 5s (usually <1s with find tool)
• Sync verification: 60s (faster polling than before)
• Lovable response: 180s (3 min)
• Test requests: 30-60s

---

Graceful Fallback Strategy

CRITICAL: Browser automation MUST always fall back gracefully to manual instructions. Never leave the user stuck.

Fallback Principles

1. Always provide manual prompt - Every failure message includes the Lovable prompt to copy-paste 2. Clear error explanation - Tell user why automation failed 3. Actionable next steps - Provide troubleshooting or workaround 4. Never block progress - User can always complete task manually

Auto-Deploy Fallback Flow

git push origin main
    ↓
Detect backend changes
    ↓
Attempt automation
    ↓
┌─ Success → Show deployment summary
│
└─ Failure → Graceful fallback:
      1. Show clear error message
      2. Explain what went wrong
      3. Provide manual Lovable prompt
      4. Suggest troubleshooting steps
      5. Offer to disable auto-deploy if needed

Fallback Message Templates

For auto-deploy failures:

❌ Auto-deploy failed: [specific error]

Backend changes were pushed successfully to GitHub.
Lovable will sync the code, but deployment requires a prompt.

**Complete manually in Lovable:**

📋 **LOVABLE PROMPT:**
> "Deploy the [function-name] edge function"

**Troubleshooting:**
[Context-specific suggestions]

💡 To disable auto-deploy: /lovable:yolo --no-auto-deploy

For command-triggered failures:

❌ Browser automation failed: [specific error]

**Fallback - run this prompt in Lovable:**

📋 **LOVABLE PROMPT:**
> "[the prompt that was going to be submitted]"

**What happened:**
[Brief explanation]

**Suggestions:**
[How to fix or work around]

Error-Specific Fallbacks

Recovery Options

After any failure, offer these options:

1. Manual completion - Provide exact prompt to copy-paste 2. Retry - User can try automation again 3. Change mode - Suggest switching to manual mode if errors persist 4. Report issue - Link to GitHub issues for persistent problems

---

This reference should be consulted for all browser automation operations in yolo mode.

Yolo Mode: Auto-Detection Logic

Reference for when to trigger browser automation.

Overview

When yolo mode is enabled (yolo_mode: on in CLAUDE.md), automatically detect when Lovable prompts are needed and trigger browser automation.

Detection Criteria

1. Edge Function Deployment Detection

When to trigger:

• User runs /deploy-edge command
• Files in supabase/functions/ have been modified
• Changes are committed and pushed to main branch

Detection steps:

1. Check yolo mode status:

   - Read CLAUDE.md
   - Look for: yolo_mode: on
   - If off or not found → skip automation

2. Verify changes are ready:

   - Run: git status
   - Check: No uncommitted changes in supabase/functions/
   - Run: git log origin/main..HEAD
   - Check: All commits are pushed to main

3. Identify which functions changed:

   - Run: git diff origin/main HEAD -- supabase/functions/
   - Parse: Which function directories have changes
   - List: Function names (folder names)

4. Trigger automation:

   - If single function changed:
     Prompt: "Deploy the [function-name] edge function"

   - If multiple functions changed:
     Prompt: "Deploy all edge functions"

   - Load automation-workflows.md
   - Execute browser automation

Example:

Files changed:
  supabase/functions/send-email/index.ts
  supabase/functions/send-email/utils.ts

Detection:
✅ yolo_mode: on
✅ Changes in supabase/functions/
✅ All committed and pushed to main
✅ Function identified: send-email

Action: Trigger automation
Prompt: "Deploy the send-email edge function"

---

2. Migration Application Detection

When to trigger:

• User runs /apply-migration command
• New files in supabase/migrations/ exist
• Changes are committed and pushed to main branch

Detection steps:

1. Check yolo mode status:

   - Read CLAUDE.md
   - Look for: yolo_mode: on
   - If off → skip automation

2. Verify migrations are ready:

   - Run: git status
   - Check: No uncommitted migrations
   - Run: git log origin/main..HEAD -- supabase/migrations/
   - Check: Migration files are pushed to main

3. List pending migrations:

   - List all files in supabase/migrations/
   - Sort by timestamp (filename prefix)
   - Identify: New or modified migrations

4. Trigger automation:

   - If one migration:
     Prompt: "Apply the [migration-name] migration"

   - If multiple migrations:
     Prompt: "Apply pending Supabase migrations"

   - Load automation-workflows.md
   - Execute browser automation

Example:

Files in supabase/migrations/:
  20240115103000_add_user_preferences.sql (new)

Detection:
✅ yolo_mode: on
✅ New migration file exists
✅ Committed and pushed to main

Action: Trigger automation
Prompt: "Apply pending Supabase migrations"

---

Integration with Commands

/deploy-edge Integration

Add this logic at the end of /deploy-edge command:

## Check for Yolo Mode

1. Read CLAUDE.md
2. Check if `yolo_mode: on`

3. If yolo mode is ON:
   - Activate yolo skill
   - Execute browser automation (see automation-workflows.md)
   - Run testing based on yolo_testing setting
   - Show deployment summary
   - Exit (don't show manual prompt)

4. If yolo mode is OFF:
   - Show manual prompt (current behavior):
     📋 **LOVABLE PROMPT:**
     > "Deploy the [name] edge function"

   - Suggest enabling yolo mode:
     💡 Tip: Enable yolo mode to automate this!
     Run: /yolo on

/apply-migration Integration

Add this logic at the end of /apply-migration command:

## Check for Yolo Mode

1. Read CLAUDE.md
2. Check if `yolo_mode: on`

3. If yolo mode is ON:
   - Activate yolo skill
   - Execute browser automation
   - Run testing if enabled
   - Show summary
   - Exit

4. If yolo mode is OFF:
   - Show manual prompt:
     📋 **LOVABLE PROMPT:**
     > "Apply pending Supabase migrations"

   - Suggest yolo mode:
     💡 Automate this with: /yolo on

---

Proactive Detection: Auto-Deploy After Git Push

When auto_deploy: on is enabled, Claude automatically detects and deploys backend changes after a successful git push to main.

Activation Criteria

Auto-deploy triggers when ALL conditions are met: 1. yolo_mode: on in CLAUDE.md 2. auto_deploy: on in CLAUDE.md 3. git push origin main completed successfully 4. Push included changes to supabase/functions/ or supabase/migrations/

Detection After Git Push

Step 1: Analyze pushed files

After: git push origin main [succeeds]

1. Get files changed in push:
   Run: git diff --name-only HEAD~[n]..HEAD
   (where n = number of commits pushed)

2. Filter for backend files:
   - Edge functions: supabase/functions/**/*
   - Migrations: supabase/migrations/*.sql

Step 2: Check configuration

1. Read CLAUDE.md
2. Check yolo_mode and auto_deploy settings
3. Branch based on settings:
   - Both ON → Proceed with automation
   - yolo_mode ON, auto_deploy OFF → Notify only
   - yolo_mode OFF → Show manual prompts

Step 3: Verify GitHub Sync (DOM-based)

IMPORTANT: Before submitting deployment prompts, verify Lovable has synced.

Use DOM-based detection (faster & more reliable than visual scanning):
1. Navigate to Lovable project page
2. Use read_page to get page content
3. Search for commit message text in sidebar
4. Poll every 2 seconds until found (max 60 seconds)

See automation-workflows.md Step 1.5 for detailed implementation.

WHY THIS MATTERS:
- Lovable syncs from GitHub asynchronously (1-2 min)
- Deploying before sync = deploying stale code
- DOM-based detection is faster than visual scanning for icons

Step 4: Execute or notify

If auto_deploy: on AND sync verified:
  - Show: "🤖 Auto-deploy: Backend changes detected..."
  - Execute browser automation
  - Run tests if enabled
  - Show summary

If auto_deploy: off:
  - Show: "📦 Backend changes detected. Run /deploy-edge to deploy."
  - Don't auto-execute

Example Auto-Deploy Flow

User pushes changes including supabase/functions/send-email/index.ts

Claude detects:
  ✅ Push to main successful
  ✅ Backend files changed: supabase/functions/send-email/
  ✅ yolo_mode: on
  ✅ auto_deploy: on

🤖 Auto-Deploy Triggered

Backend changes detected in your push:
- Edge functions: send-email

⏳ Step 1/7: Navigating to Lovable project...
✅ Step 2/7: Located chat interface
✅ Step 3/7: Submitted prompt: "Deploy the send-email edge function"
⏳ Step 4/7: Waiting for Lovable response...
✅ Step 5/7: Deployment confirmed
⏳ Step 6/7: Running verification tests...
✅ Step 7/7: All tests passed

## Auto-Deploy Summary
**Trigger:** git push to main
**Function:** send-email
**Status:** ✅ Success
**Duration:** 38 seconds

Graceful Fallback

If auto-deploy fails for ANY reason, fall back gracefully:

❌ Auto-deploy failed: [reason]

Fallback - complete manually in Lovable:

📋 **LOVABLE PROMPT:**
> "Deploy the send-email edge function"

[Troubleshooting suggestions based on error]

Never block the user - always provide manual options.

See references/post-push-automation.md for complete implementation details.

---

Reading CLAUDE.md for Yolo Configuration

Check if yolo mode is enabled:

1. Read file: CLAUDE.md (in project root)
2. Parse markdown sections
3. Find: "## Yolo Mode Configuration (Beta)"
4. Extract fields:
   - Status: on/off
   - Auto-Deploy: on/off (NEW)
   - Deployment Testing: on/off
   - Auto-run Tests: on/off
   - Debug Mode: on/off
5. Return configuration object

Example CLAUDE.md section:

## Yolo Mode Configuration (Beta)

- **Status**: on
- **Auto-Deploy**: on
- **Deployment Testing**: on
- **Auto-run Tests**: off
- **Debug Mode**: off
- **Last Updated**: 2025-01-03 10:30:00

Parsed result:

{
  yolo_mode: "on",
  auto_deploy: "on",
  yolo_testing: "on",
  auto_tests: "off",
  yolo_debug: "off",
  last_updated: "2025-01-03 10:30:00"
}

Auto-deploy decision logic:

if (yolo_mode === "on" && auto_deploy === "on") {
  // Automatically deploy after git push
  triggerAutoDeployment();
} else if (yolo_mode === "on") {
  // Notify but don't auto-deploy
  showDeploymentNotification();
} else {
  // Show manual prompts
  showManualPrompts();
}

---

Error Handling in Detection

CLAUDE.md not found:

- Assume yolo mode is off
- Proceed with manual prompts
- Don't show error (project may not be initialized)

Yolo mode section not in CLAUDE.md:

- Assume yolo mode is off
- Proceed with manual prompts

Invalid yolo mode value:

- Treat as "off"
- Proceed with manual prompts

Git operations fail:

- Show error to user
- Can't determine if changes are pushed
- Proceed with manual prompts
- Suggest: git status, git push

---

Decision Flow

User runs /deploy-edge or /apply-migration
    ↓
Read CLAUDE.md
    ↓
Check: yolo_mode field
    ↓
    ├─ yolo_mode: on
    │     ↓
    │  Verify changes committed & pushed
    │     ↓
    │  Identify what changed
    │     ↓
    │  Generate Lovable prompt
    │     ↓
    │  Load automation-workflows.md
    │     ↓
    │  Execute browser automation
    │     ↓
    │  Run tests if yolo_testing: on
    │     ↓
    │  Show deployment summary
    │
    └─ yolo_mode: off
          ↓
       Show manual prompt
          ↓
       Suggest /yolo on

---

Testing Detection Logic

Test case 1: Yolo mode on, single edge function changed

Setup:
- CLAUDE.md has yolo_mode: on
- Modified: supabase/functions/send-email/index.ts
- Committed and pushed to main

Expected:
✅ Yolo mode detected
✅ Function identified: send-email
✅ Automation triggered
✅ Prompt: "Deploy the send-email edge function"

Test case 2: Yolo mode off

Setup:
- CLAUDE.md has yolo_mode: off
- Modified: supabase/functions/send-email/index.ts

Expected:
✅ Yolo mode not active
✅ Show manual prompt
✅ Suggest /yolo on

Test case 3: Multiple functions changed

Setup:
- CLAUDE.md has yolo_mode: on
- Modified: send-email/, process-payment/

Expected:
✅ Multiple functions detected
✅ Automation triggered
✅ Prompt: "Deploy all edge functions"

Test case 4: Migration detection

Setup:
- CLAUDE.md has yolo_mode: on
- New file: supabase/migrations/20240115_add_field.sql
- Committed and pushed

Expected:
✅ Migration detected
✅ Automation triggered
✅ Prompt: "Apply pending Supabase migrations"

---

This detection logic ensures yolo mode only activates when explicitly enabled and changes are ready to deploy.

Yolo Mode: Lovable MCP Workflows

Reference for submitting Lovable prompts via the official Lovable MCP server. This is the preferred method over browser automation - it is faster, more reliable, and does not require the Chrome extension.

Overview

The Lovable MCP server (https://mcp.lovable.dev) exposes tools that let Claude send prompts directly to a Lovable project via API. When the user has connected Lovable MCP in their Claude settings, Claude can call send_message instead of navigating the browser.

Priority order for yolo mode: 1. MCP (preferred) - Use Lovable MCP tools if available 2. Browser automation (fallback) - Use Claude's browser automation 3. Manual (last resort) - Show prompt for the user to copy-paste

Prerequisites

• User has added Lovable as a connector in Claude settings (see connect-mcp.md command)
• lovable_url is set in CLAUDE.md (to extract the project ID)
• Lovable Pro or higher plan (required by Lovable MCP)

Detecting MCP Availability

Before attempting MCP, check if Lovable MCP tools are available in the current session:

1. Look for available MCP tools that match "lovable" or have "send_message"
2. The tool will typically be named: mcp__Lovable__send_message
   (or similar depending on the connector name the user used)
3. If found → use MCP workflow
4. If not found → fall back to browser automation

Detection approach:

• Try to call send_message and check if the tool exists
• If tool not found, treat as MCP unavailable and fall back gracefully
• Do NOT error or block the user - MCP is optional

Extracting the Project ID

The project ID is extracted from lovable_url in CLAUDE.md:

lovable_url: https://lovable.dev/projects/abc123-def456
                                          ^^^^^^^^^^^^^^^
                                          This is the project_id

Extraction logic:

1. Read `lovable_url` from CLAUDE.md
2. Parse the URL: https://lovable.dev/projects/{project_id}
3. Extract everything after the last `/`
4. Use this as the `project_id` parameter for send_message

Example:

• URL: https://lovable.dev/projects/8f3a2b1c-4d5e-6789-abcd-ef0123456789
• Project ID: 8f3a2b1c-4d5e-6789-abcd-ef0123456789

Core MCP Workflow

Step 1: Check for GitHub Sync (Still Required)

Even with MCP, Lovable needs the latest code from GitHub before deploying:

IMPORTANT: send_message tells Lovable to deploy the code it has synced from GitHub.
If you send the prompt before GitHub sync completes, Lovable will deploy stale code.

Wait procedure (same as browser automation):
1. Confirm git push succeeded
2. Wait for GitHub → Lovable sync (typically 30-60 seconds)
3. Proceed with send_message once sync is expected to be complete

Alternatively: send_message with a note for Lovable to wait for latest sync

Practical approach:

• For auto-deploy: Wait ~30 seconds after git push before calling send_message
• For manual /deploy-edge: Code was pushed earlier, proceed immediately
• Lovable's agent is smart enough to verify sync state - trust it

Step 2: Call send_message

Use the Lovable MCP send_message tool:

Tool: send_message (via Lovable MCP connector)

Parameters:
  project_id: [extracted from lovable_url]
  message: [the Lovable deployment prompt]

Example call:
  send_message(
    project_id: "abc123",
    message: "Deploy the send-email edge function"
  )

Important: send_message is asynchronous - Lovable's agent starts processing but the response may not be immediate. The tool may return a message ID that you can poll with get_message.

Step 3: Poll for Completion

If send_message returns a message ID (async mode):

Poll using get_message:
  get_message(message_id: "[returned id]")

Polling strategy:
  - Poll every 5 seconds
  - Timeout after 180 seconds (3 minutes)
  - Check response for completion indicators

Completion indicators in response:
  - "deployed successfully"
  - "function is live"
  - "migration applied"
  - "deployment complete"

Error indicators:
  - "error"
  - "failed"
  - "could not"

If send_message returns the full response synchronously, skip polling.

Step 4: Parse the Result

Success indicators:
  Edge functions:
  - "deploy" or "deployed"
  - "function is live"
  - "successfully deployed"

  Migrations:
  - "migration applied"
  - "database updated"
  - "schema updated"

Error indicators:
  - "error", "failed", "could not", "invalid", "syntax error"

Unclear response:
  - Show full response to user
  - Ask them to verify in Lovable manually

Step 5: Run Verification Tests (if enabled)

After successful deployment, run tests based on yolo_testing setting.

With MCP, Level 1 verification (basic logs) is simplified:

Submit follow-up via send_message:
  message: "Show logs for [function-name] edge function"

Analyze response for:
  - No error indicators
  - Recent deployment timestamp
  - Function status: active

Level 2 (console checking) and Level 3 (functional testing) are the same as browser automation - they test the production URL directly, not through Lovable.

Complete MCP Deployment Flow

Edge Function Deployment

🤖 Yolo mode (MCP): Deploying send-email edge function

Step 1/5: Verifying code is pushed to GitHub... ✅
Step 2/5: Sending deployment prompt via Lovable MCP...
  → send_message(project_id="abc123", message="Deploy the send-email edge function")
  → Response received (3.2s)
Step 3/5: Parsing Lovable response... ✅ Deployment confirmed
Step 4/5: Running verification tests...
  → Level 1: Basic logs... ✅
  → Level 2: Console check... ✅
  → Level 3: Functional test... ✅
Step 5/5: All tests passed ✅

## Deployment Summary

Operation: Edge Function Deployment
Function: send-email
Method: Lovable MCP
Status: ✅ Success
Duration: 15 seconds

Migration Application

🤖 Yolo mode (MCP): Applying database migration

Step 1/4: Verifying migration file is pushed to GitHub... ✅
Step 2/4: Sending migration prompt via Lovable MCP...
  → send_message(project_id="abc123", message="Apply pending Supabase migrations")
  → Response received (5.1s)
Step 3/4: Parsing Lovable response... ✅ Migration applied
Step 4/4: Running verification tests...
  → Level 1: Schema confirmation... ✅

## Migration Summary

Operation: Database Migration
Method: Lovable MCP
Status: ✅ Success
Duration: 12 seconds

Error Handling

MCP Not Available

When send_message tool is not found:

⚠️ Lovable MCP not connected

Falling back to browser automation...

[Continue with browser automation workflow]

If browser automation also fails:

❌ Automated deployment unavailable

MCP not connected + Browser automation failed.

Fallback: Run this prompt manually in Lovable:
📋 "Deploy the send-email edge function"

To enable MCP (recommended): /lovable:connect-mcp

Missing Project ID

When lovable_url is not set in CLAUDE.md:

❌ Cannot use Lovable MCP: project URL not configured

Please provide your Lovable project URL to use MCP:
  1. Add to CLAUDE.md: Lovable Project URL: https://lovable.dev/projects/YOUR_ID
  2. Or run /lovable:init to reconfigure

Fallback: Run this prompt manually in Lovable:
📋 "[deployment prompt]"

Deployment Failed via MCP

When send_message returns an error:

❌ Deployment failed via Lovable MCP

Error from Lovable:
[captured error message]

Suggested fixes:
- Check function code for syntax errors
- Verify required secrets are set in Cloud → Secrets
- Review function logs in Lovable

Fallback: You can also try running this manually:
📋 "[deployment prompt]"

Authentication Error

When MCP returns auth/permission errors:

🔐 Lovable MCP authentication issue

Your Lovable MCP connection may have expired.

To reconnect:
  Run: /lovable:connect-mcp
  Then re-authorize via OAuth

Fallback: Run this prompt manually in Lovable:
📋 "[deployment prompt]"

Rate Limit / Credits

When credits are insufficient:

⚠️ Lovable credits exhausted

send_message and create_project operations use Lovable credits.
Your workspace may have run out.

To check: Log in to Lovable → Workspace Settings → Credits

Fallback: Run this prompt manually in Lovable:
📋 "[deployment prompt]"

Comparison: MCP vs Browser Automation

Configuration in CLAUDE.md

The Deployment Method field controls which method to use:

## Yolo Mode Configuration (Beta)

- **Status**: on
- **Deployment Method**: auto   # auto | mcp | browser
- **Deployment Testing**: on
- **Debug Mode**: off

Options:

• auto (default): Try MCP first, fall back to browser if not available
• mcp: Use MCP only, show manual prompt if MCP fails (skip browser)
• browser: Use browser automation only (legacy behavior)

Progress Notifications

MCP mode (debug off):

🤖 Yolo mode (MCP): Deploying [function-name]

⏳ Sending prompt to Lovable via MCP...
✅ Deployment confirmed by Lovable
⏳ Running verification tests...
✅ All tests passed

MCP mode (debug on):

🐛 DEBUG: Yolo mode - MCP Deployment

Project ID: abc123
Tool: send_message
Message: "Deploy the send-email edge function"

Request: Sending...
Response time: 3.2s
Response:
  "I'll deploy the send-email edge function now. Checking the latest
   code from GitHub... The function looks good. Deploying..."

Analysis:
  Success keywords: "deploy" ✅, "deploying" ✅
  Error keywords: none
  Status: ✅ SUCCESS

---

This reference is used by the yolo skill when Lovable MCP is connected. See `connect-mcp.md` command for setup instructions.

Post-Push Automatic Deployment

Reference for automatic deployment detection and execution after git push.

Overview

When auto_deploy: on is enabled in CLAUDE.md, Claude automatically detects backend changes after a successful git push to main and proceeds with Lovable deployment without requiring manual /deploy-edge or /apply-migration commands.

When Auto-Deploy Triggers

Auto-deploy activates when ALL of these conditions are met:

1. Yolo mode is enabled (yolo_mode: on in CLAUDE.md) 2. Auto-deploy is enabled (auto_deploy: on in CLAUDE.md) 3. Git push to main was successful 4. Backend files were modified in the push:

• Edge functions: supabase/functions/**/*
• Migrations: supabase/migrations/*.sql

Detection Flow After Git Push

User completes work on backend files
    |
    v
git add . && git commit -m "..."
    |
    v
git push origin main
    |
    v
[Push succeeds]
    |
    v
Claude detects backend changes
    |
    +---> Edge functions modified?
    |         |
    |         +--> Yes: Queue edge function deployment
    |
    +---> Migrations added?
              |
              +--> Yes: Queue migration application
    |
    v
Check yolo_mode and auto_deploy settings
    |
    +--> Both ON: Execute automated deployment
    |
    +--> yolo_mode ON but auto_deploy OFF:
    |       Show: "Backend changes detected. Run /deploy-edge to deploy."
    |
    +--> yolo_mode OFF:
            Show manual prompts with tip to enable yolo mode

Implementation Steps

Step 1: Detect Backend Changes in Push

After a successful git push origin main:

1. Get the commit range that was pushed:
   - Run: git log origin/main@{1}..origin/main --name-only --pretty=format:""
   - This shows all files changed in the push

2. Check for edge function changes:
   - Filter files matching: supabase/functions/**/*
   - Extract function names (directory names under supabase/functions/)

3. Check for migration changes:
   - Filter files matching: supabase/migrations/*.sql
   - List new migration files

4. Build deployment queue:
   - If edge functions changed: Add "deploy-edge" task
   - If migrations added: Add "apply-migration" task

Example detection output:

Push analysis:
  Files changed: 5
  Edge functions modified: send-email, process-payment
  New migrations: 20250103_add_user_preferences.sql

Deployment queue:
  1. Deploy edge functions: send-email, process-payment
  2. Apply migration: 20250103_add_user_preferences.sql

Step 2: Check Configuration

Read CLAUDE.md and verify settings:

1. Read CLAUDE.md file
2. Find "## Yolo Mode Configuration (Beta)" section
3. Extract:
   - yolo_mode: on/off
   - auto_deploy: on/off
   - yolo_testing: on/off
   - yolo_debug: on/off

4. Decision:
   - If yolo_mode: on AND auto_deploy: on → Proceed with automation
   - If yolo_mode: on AND auto_deploy: off → Show notification only
   - If yolo_mode: off → Show manual prompts

Step 3: Execute Automated Deployment

When conditions are met, proceed with deployment:

Show progress message:
  "Auto-deploy: Backend changes detected, starting deployment..."

IMPORTANT: Wait for Lovable to sync from GitHub first!
  1. Navigate to Lovable project
  2. Wait for GitHub sync to complete (up to 2 minutes)
  3. Verify the pushed commit is visible in Lovable
  4. Only then proceed with deployment prompts

For edge functions:
  1. Validate secrets (scan for Deno.env.get patterns)
  2. If missing secrets → Warn and ask user to add them first
  3. Wait for sync verification
  4. If secrets OK and sync complete → Execute browser automation
  5. Run verification tests if yolo_testing: on

For migrations:
  1. Check for destructive operations
  2. If destructive → Warn and get user confirmation
  3. Wait for sync verification
  4. If safe or confirmed and sync complete → Execute browser automation
  5. Verify schema after application

Step 3.5: Wait for GitHub Sync (CRITICAL)

Why this matters: Lovable syncs from GitHub asynchronously. If we submit a deployment prompt before Lovable has the latest code, the deployment will use stale code and fail or deploy the wrong version.

Sync timing: Lovable typically syncs within 1-2 minutes of a push to main.

NEW APPROACH: Navigate immediately, check chat history for sync confirmation.

Verification process:

1. Navigate to Lovable project page IMMEDIATELY (no initial wait)

2. Check LEFT SIDEBAR chat history for sync confirmation:
   VISUAL REFERENCE:
   See: skills/yolo/references/lovable-commented-screenshot.png
   - Left sidebar is the scrollable chat history area
   - GitHub commits appear as conversation items
   - Example: "Fix Mercado Pago installment config..." with GitHub icon

   WHAT TO LOOK FOR:
   - Conversation item in left sidebar
   - GitHub icon (looks like small octocat/mark before the text)
   - Message text matches your commit message (first ~50 chars)
   - May show "Active Edit" or "Code" buttons below
   - Appears as a clickable conversation item

   WHERE TO LOOK:
   - Left sidebar (scrollable conversation history)
   - Scroll to the BOTTOM - newest items at bottom
   - Should appear within seconds after push

   EXACT VISUAL PATTERN:
   [GitHub Icon] "Your commit message here..."
                 Active Edit        Code

   Example from screenshot: "Fix Mercado Pago installment config..."

3. Fast checking loop:
   - Check immediately first (no wait)
   - If not found: Wait 4 seconds, check again
   - Keep checking every 4 seconds
   - Max attempts: 20 (total 80 seconds max)

4. If sync found:
   → Proceed to deployment prompt

5. If not found after 80 seconds:
   → Show warning
   → Ask user to verify manually
   → Provide manual fallback prompt

Sync verification output:

⏳ Step 2/8: Checking for GitHub sync...
  Commit pushed: abc1234 "Add email notifications"
  Checking left sidebar chat history...
  ⏳ Checking... (0s - immediate)
  ⏳ Checking... (4s)
  ⏳ Checking... (8s)
  ✅ Sync confirmed! Found commit in chat history.

  Much faster than old 30s+ approach!

If sync times out:

⚠️ Sync verification timeout

Couldn't confirm GitHub sync after 80 seconds of checking.
This can happen if:
- Sync is taking longer than usual
- GitHub webhook didn't trigger
- Network issues
- Chat history not showing the commit yet

**Options:**
1. Wait and retry: I'll check again (4 more attempts)
2. Proceed anyway: Deploy with current code (may use stale version)
3. Manual check: Verify sync in Lovable, then run /deploy-edge

What would you like to do?

Step 4: Show Results

After deployment completes:

## Auto-Deploy Summary

**Trigger:** git push to main
**Changes detected:**
- Edge functions: send-email, process-payment
- Migrations: 20250103_add_user_preferences.sql

**Deployments:**
1. ✅ Edge functions deployed
   - send-email: Deployed successfully
   - process-payment: Deployed successfully

2. ✅ Migration applied
   - 20250103_add_user_preferences.sql: Applied

**Verification:** (if testing enabled)
- ✅ Basic: All deployments confirmed
- ✅ Console: No errors detected
- ✅ Functional: All tests passed

**Duration:** 52 seconds

💡 Auto-deploy is enabled. Run `/yolo --no-auto-deploy` to disable.

---

User Notifications

When Auto-Deploy Starts

🤖 **Auto-Deploy Triggered**

Backend changes detected in your push to main:
- Edge functions: send-email
- Migrations: None

Starting automated deployment...

⏳ Step 1/8: Navigating to Lovable project...
⏳ Step 2/8: Waiting for GitHub sync to complete...
✅ Step 3/8: Sync verified - Lovable has latest code
⏳ Step 4/8: Locating chat interface...

When Auto-Deploy is Disabled

If yolo_mode: on but auto_deploy: off:

📦 **Backend Changes Detected**

Your push to main included backend changes:
- Edge functions: send-email
- Migrations: 20250103_add_preferences.sql

These changes require Lovable deployment.

**Options:**
1. Run `/lovable:deploy-edge` to deploy edge functions
2. Run `/lovable:apply-migration` to apply migrations
3. Enable auto-deploy: `/lovable:yolo --auto-deploy`

When Yolo Mode is Disabled

If yolo_mode: off:

📦 **Backend Changes Detected**

Your push to main included backend changes that require Lovable deployment.

**Edge Functions:** send-email

📋 **LOVABLE PROMPT:**
> "Deploy the send-email edge function"

**Migrations:** 20250103_add_preferences.sql

📋 **LOVABLE PROMPT:**
> "Apply pending Supabase migrations"

💡 **Tip:** Enable yolo mode to automate this!
   Run: /lovable:yolo on --auto-deploy
   Benefits: Automatic deployment after every push

---

Graceful Fallback Handling

Auto-deploy MUST gracefully fall back to manual instructions when:

1. Browser Automation Unavailable

❌ **Auto-deploy failed:** Browser automation unavailable

The Claude in Chrome extension is required for automated deployment.

**Fallback - Manual Deployment:**

📋 **LOVABLE PROMPT (Edge Functions):**
> "Deploy all edge functions"

📋 **LOVABLE PROMPT (Migrations):**
> "Apply pending Supabase migrations"

💡 Install Chrome extension: https://chrome.google.com/webstore/detail/claude/...

2. User Not Logged Into Lovable

🔐 **Auto-deploy paused:** Please log in to Lovable

I opened your Lovable project but you're not logged in.
Please log in, then I'll continue automatically.

[Waiting for login...]

**Or complete manually:**
📋 "Deploy the send-email edge function"

3. Lovable UI Not Found

❌ **Auto-deploy failed:** Could not locate Lovable chat interface

The Lovable UI may have changed. Please complete deployment manually.

**Fallback - Manual Deployment:**

📋 **LOVABLE PROMPT:**
> "Deploy the send-email edge function"

💡 Please report this issue: https://github.com/10k-digital/lovable-claude-code/issues

4. Timeout

⏱️ **Auto-deploy timeout:** No response after 3 minutes

The deployment may still be processing. Please check Lovable manually.

**What was submitted:**
📋 "Deploy the send-email edge function"

**Suggestions:**
- Check Lovable for deployment status
- Look for error messages in Lovable
- Try refreshing the Lovable page

5. Deployment Failed in Lovable

❌ **Auto-deploy failed:** Lovable reported an error

**Error from Lovable:**
"Could not deploy function: RESEND_API_KEY is not set"

**Suggested fixes:**
1. Add the missing secret in Cloud → Secrets
2. Re-run deployment with `/lovable:deploy-edge`

**Or manually in Lovable:**
📋 "Deploy the send-email edge function"

6. Missing Secrets

⚠️ **Auto-deploy blocked:** Missing secrets

The following secrets are required but not configured:
- STRIPE_SECRET_KEY (used by process-payment)
- RESEND_API_KEY (used by send-email)

**To proceed:**
1. Go to Cloud → Secrets in Lovable
2. Add the missing secrets
3. Push changes again or run `/lovable:deploy-edge`

**I'll wait here.** Let me know when secrets are added, or:
- Type "skip" to deploy anyway (function will fail without secrets)
- Type "cancel" to skip deployment

---

Order of Operations

When both edge functions and migrations need deployment:

1. **Apply migrations FIRST**
   - Migrations often create tables/columns that functions depend on
   - Wait for migration to complete before deploying functions

2. **Deploy edge functions SECOND**
   - Functions may reference new tables from migrations
   - Deploy after schema is updated

Example sequence:
  ⏳ Step 1: Applying migration 20250103_add_preferences.sql...
  ✅ Migration applied
  ⏳ Step 2: Deploying send-email edge function...
  ✅ Edge function deployed
  ⏳ Step 3: Running verification tests...
  ✅ All tests passed

---

Configuration in CLAUDE.md

Add this to the Yolo Mode Configuration section:

## Yolo Mode Configuration (Beta)

- **Status**: on
- **Auto-Deploy**: on     # NEW: Deploy automatically after git push
- **Deployment Testing**: on
- **Auto-run Tests**: off
- **Debug Mode**: off
- **Last Updated**: 2025-01-03 10:30:00

Configure with:

/lovable:yolo on --auto-deploy     # Enable auto-deploy
/lovable:yolo on --no-auto-deploy  # Disable auto-deploy (manual commands only)

---

Debug Mode Output

When yolo_debug: on, show detailed auto-deploy information:

🐛 DEBUG: Auto-Deploy Detection

Git push completed to: origin/main
Commit range: abc123..def456

Files in push:
  - supabase/functions/send-email/index.ts (modified)
  - supabase/functions/send-email/utils.ts (modified)
  - src/components/EmailForm.tsx (modified)

Backend file analysis:
  Edge functions:
    - send-email: 2 files changed
  Migrations:
    - None

Configuration check:
  CLAUDE.md found: Yes
  yolo_mode: on
  auto_deploy: on
  yolo_testing: on
  yolo_debug: on

Decision: ✅ Proceed with automated deployment

Secret validation:
  Scanning supabase/functions/send-email/...
  Found: RESEND_API_KEY
  Status: ✅ In Lovable Cloud (from CLAUDE.md secrets table)

Starting automation workflow...

---

Best Practices

When to Enable Auto-Deploy

Good for:

• Active development with frequent backend changes
• Solo developers who want maximum automation
• Teams with robust CI/CD who trust automated deployments

Less ideal for:

• Production environments requiring review
• Teams with strict change management
• Projects with complex secret dependencies

Recommendations

1. Start with auto-deploy off

• Get comfortable with yolo mode first
• Enable auto-deploy once workflow is established

2. Keep testing enabled

• Even with auto-deploy, verification tests catch issues
• Only disable testing for speed-critical workflows

3. Monitor first few auto-deploys

• Watch the automation run
• Verify deployments complete successfully
• Adjust settings based on results

4. Have a rollback plan

• Know how to revert deployments in Lovable
• Keep backup of previous function versions

---

Error Recovery

If auto-deploy fails repeatedly:

1. Disable auto-deploy temporarily:

   /lovable:yolo --no-auto-deploy

2. Debug the issue:

• Enable debug mode: /lovable:yolo --debug
• Push changes and observe detailed output
• Check for patterns in failures

3. Fix underlying issue:

• Missing secrets: Add to Cloud → Secrets
• UI changes: Report issue, use manual commands
• Login issues: Ensure logged into Lovable

4. Re-enable when fixed:

   /lovable:yolo --auto-deploy

---

This reference enables fully automated deployment after git push while maintaining safety through graceful fallbacks and clear error messages.

Secrets Extraction via Browser Automation

Reference for extracting existing secrets from Lovable Cloud's settings page using browser automation. This enables the init command to see which secrets are already configured before collecting new ones.

Overview

Navigate to Lovable Cloud settings and extract existing secret names. This helps:

• Show which secrets are already configured
• Avoid duplicate configuration attempts
• Merge Lovable Cloud secrets with codebase-detected secrets
• Provide users with complete secret status

Prerequisites

• Lovable project URL available
• User logged into Lovable.dev in browser
• Claude in Chrome extension enabled
• Browser automation capabilities available

Workflow Steps

Step 1: Construct Cloud Settings URL

Input: Lovable project URL

https://lovable.dev/projects/PROJECT_ID

Output: Cloud settings URL

https://lovable.dev/projects/PROJECT_ID?view=cloud

Example:

• Input: https://lovable.dev/projects/c0be81e7-dc30-4214-825a-9322c311c8df
• Output: https://lovable.dev/projects/c0be81e7-dc30-4214-825a-9322c311c8df?view=cloud

Step 2: Navigate to Cloud Page

Sequence:

1. Navigate to cloud URL

   URL: https://lovable.dev/projects/PROJECT_ID?view=cloud
   Action: Navigate
   Timeout: 10 seconds

2. Wait for page load

   Wait for: DOM content loaded
   Check for loading indicators: disappear

3. Check for login redirect

   If current URL contains: /login, /signin, /auth
   Then: Wait for user to login (30 second timeout)
   After login: Return to cloud URL automatically

4. If redirected by login

   Wait for: User to complete login in browser
   Timeout: 30 seconds
   Action: Return to cloud URL after login detected

Debug output (if enabled):

🐛 DEBUG: Navigation Step

Target URL: https://lovable.dev/projects/abc123?view=cloud
Navigation: Started
Status: 200 OK
Page load time: 1.2 seconds
Login detected: false
Current URL: https://lovable.dev/projects/abc123?view=cloud

Result: ✅ Loaded successfully

Step 3: Locate Secrets Section

Element selectors (try in order):

1. Data-testid attribute (most reliable)

   [data-testid="secrets-section"]
   [data-testid="cloud-secrets"]
   [data-testid="secrets-list"]

2. ARIA labels (accessibility attributes)

   section[aria-label*="Secret"]
   div[aria-label*="Secret"]

3. Class-based selectors (fallback)

   div[class*="secrets"]
   div[class*="secret-list"]
   section[class*="settings"]

4. Text content (last resort)

   Look for heading text matching "Secrets"
   Look for section with text "Secret keys" or "Environment variables"

Timeouts:

• Max wait for section: 5 seconds
• If not found: Return empty array, continue

Debug output:

🐛 DEBUG: Locate Secrets Section

Selector 1: [data-testid="secrets-section"]
  Status: ✅ Found
  Element: div#secrets-section
  Location: x=200, y=400, width=600, height=400

Result: ✅ Located

Step 4: Extract Secret Names

Element patterns to extract (try in order):

Pattern A: Data-testid Attributes

[data-testid="secret-key"]
[data-testid="secret-name"]
[data-testid="secret-item"]

Action: Get text content of element

Pattern B: Input Fields

input[name*="secret"][readonly]
input[name*="secret"][disabled]
input[name*="key"]

Action: Get value attribute

Pattern C: Code/Pre Elements

code
pre
span[class*="key"]
span[class*="secret"]

Action: Get text content

Pattern D: List Items

li[class*="secret"]
li[class*="key"]
tr[class*="secret"] td:first-child

Action: Get text content of first cell/child

Pattern E: Container Elements

div[class*="secret-item"] span
div[class*="secret-row"] [class*="name"]

Action: Get text content of name element

Extraction logic:

function extractSecretNames(secretsSection: Element): string[] {
  const secrets = new Set<string>();

  // Try each pattern
  const patterns = [
    '[data-testid="secret-key"]',
    'input[name*="secret"][readonly]',
    'code',
    'li[class*="secret"] span:first-child',
    // ... more patterns
  ];

  for (const pattern of patterns) {
    const elements = secretsSection.querySelectorAll(pattern);
    for (const elem of elements) {
      const value = elem.textContent?.trim() || elem.value?.trim();

      if (value && isValidSecretName(value)) {
        // Extract only KEY portion (before value fields)
        const secretName = extractKeyName(value);
        secrets.add(secretName);
      }
    }
  }

  return Array.from(secrets);
}

function extractKeyName(rawValue: string): string {
  // Handle different formats:
  // "KEY=*****" → "KEY"
  // "KEY: [hidden]" → "KEY"
  // "• KEY" → "KEY"
  // "KEY (xxxxx)" → "KEY"

  const cleanValue = rawValue
    .split('=')[0]
    .split(':')[0]
    .replace(/^[•\-\*]+\s*/, '')
    .replace(/\s*\([^)]*\).*$/, '')
    .trim();

  return cleanValue.toUpperCase();
}

function isValidSecretName(value: string): boolean {
  // Valid secret names are alphanumeric + underscore
  // At least 3 characters, contains at least one letter
  return /^[A-Z_][A-Z0-9_]{2,}$/i.test(value);
}

Common secret name formats in Lovable:

• KEY=***** → Extract "KEY"
• KEY: [hidden] → Extract "KEY"
• • KEY_NAME → Extract "KEY_NAME"
• KEY_NAME (last rotated: 2024-01-01) → Extract "KEY_NAME"
• Plain text: RESEND_API_KEY → Extract "RESEND_API_KEY"

Expected output:

[
  "RESEND_API_KEY",
  "SUPABASE_SERVICE_ROLE_KEY",
  "OPENAI_API_KEY",
  "STRIPE_SECRET_KEY"
]

Debug output:

🐛 DEBUG: Extract Secret Names

Secrets section found: true
Number of secret items detected: 4

Extraction method: data-testid attributes
Items found: 4

Extracted secrets:
  1. RESEND_API_KEY
  2. SUPABASE_SERVICE_ROLE_KEY
  3. OPENAI_API_KEY
  4. STRIPE_SECRET_KEY

Result: ✅ Success (extracted 4 secrets)

Step 5: Return Results

Return format:

{
  "success": true,
  "secrets": [
    "RESEND_API_KEY",
    "SUPABASE_SERVICE_ROLE_KEY",
    "OPENAI_API_KEY"
  ],
  "count": 3,
  "source": "lovable_cloud",
  "timestamp": "2024-01-15T10:30:00Z"
}

Return values:

Error Handling

Scenario 1: Page Not Found (404)

Detection:

URL returns 404 status
OR "Page not found" message visible
OR Redirect to homepage detected

Handling:

Log: "Lovable project URL not found"
Return: { success: true, secrets: [] }
Reason: Project may not exist or URL may be incorrect
Fallback: Continue with codebase-only detection

User message: "Could not access Lovable Cloud settings (project not found). Using codebase detection only."

Scenario 2: Login Required

Detection:

Current URL contains: /login, /signin, /auth
OR Login form visible
OR "Sign in" button present

Handling:

Log: "User login required"
Message: "Please log in to Lovable"
Wait: 30 seconds for user to complete login
Check: After login redirect, return to cloud URL
Timeout: If login not completed in 30s
  → Cancel automation
  → Return { success: true, secrets: [] }
  → Continue with fallback

User message: "Please log in to Lovable in your browser, then we'll extract your secrets. (Waiting up to 30 seconds...)"

Scenario 3: Secrets Section Not Found

Detection:

None of the selectors return elements
Timeout: Section not visible after 5 seconds

Handling:

Log: "Secrets section not found - Lovable UI may have changed"
Return: { success: true, secrets: [] }
Reason: Selectors may be outdated
Fallback: Continue with codebase-only detection

User message: "Could not locate secrets section in Lovable Cloud (UI may have changed). Using codebase detection only."

Scenario 4: No Secrets Configured

Detection:

Secrets section is visible and loaded
No secret items found
OR Empty state message visible: "No secrets yet", "Add your first secret"

Handling:

Log: "Secrets section found but empty"
Return: { success: true, secrets: [] }
Reason: This is valid - new project has no secrets yet
Fallback: Continue - codebase detection will find what's needed

User message: "No secrets configured in Lovable Cloud yet. We'll help you add them."

Scenario 5: Extraction Timeout (Total)

Detection:

Navigation + extraction takes > 30 seconds total

Timeout breakdown:

• Navigation: 10 seconds
• Wait for section: 5 seconds
• Wait for login: 30 seconds (optional, only if needed)
• Extraction: 5 seconds
• Total max: 30 seconds of actual time

Handling:

If any step exceeds timeout:
  Log: "Secrets extraction timed out"
  Return: { success: true, secrets: [] }
  Action: Don't retry - move forward

User message: "Secrets extraction took too long, skipping. Using codebase detection only."

Scenario 6: Extraction Partial Failure

Detection:

Some secrets extracted, some failed
HTML structure partially changed
Only 2/5 expected secrets found

Handling:

Return successfully with partial results:
  { success: true, secrets: ["SECRET1", "SECRET2"] }
Reason: Partial extraction is useful
User will add any missing manually

User message: "Extracted some existing secrets from Lovable Cloud. Review and add any additional ones needed."

Edge Cases

Case 1: Secret Names with Special Characters

Example: API-KEY-v2, API.KEY, API KEY

Handling:

Normalize to uppercase + underscore: API_KEY_V2
Ask user to confirm: "Found 'API_KEY_V2', is this correct?"
Store as provided if user confirms

Case 2: Very Long Secret Names

Example: VERY_VERY_VERY_LONG_SECRET_NAME_WITH_MANY_PARTS

Handling:

Extract fully (no length limit)
Display with truncation if needed: "VERY_VERY_...NAME_WITH_MANY_PARTS"
Store complete name

Case 3: Duplicate Detection

Example: UI shows same secret twice (bug or UI duplication)

Handling:

Use Set to deduplicate
Return unique secrets only
Log: "Removed 1 duplicate: SECRET_NAME"

Case 4: Hidden/Masked Values

Example: Input shows RESEND_API_KEY: ••••••••••••••••

Handling:

Extract "RESEND_API_KEY"
Ignore the masked value portion (•••••)
Store secret name only (values not extracted for security)

Integration with Init Flow

When to Trigger

Called during Question 6 (Secret Detection Method) when:

1. ✅ User chooses option "A) Auto-detect" 2. ✅ Lovable project URL was provided in Q5 3. ✅ Browser automation is available 4. ✅ First attempt only (don't retry if failed)

Data Flow

User provides Lovable URL (Q5)
    ↓
User chooses auto-detect (Q6 option A)
    ↓
Secrets extraction workflow starts
    ├─ Navigate to Cloud URL
    ├─ Extract secret names
    └─ Return list
    ↓
Merge with codebase-detected secrets
    ↓
Present merged results to user
    ↓
Ask for additional secrets

Error Recovery

If browser automation fails:
  ├─ Log error
  ├─ Return empty list
  └─ Fall back to codebase-only detection
     ↓
  User still sees codebase results
  User still asked for additional secrets
  Init completes successfully

Performance Metrics

Typical timings:

• Navigation: 1-2 seconds
• Wait for section: 1-2 seconds
• Extraction: 0.5-1 seconds
• Total: 3-5 seconds (most cases)

Worst case:

• Navigation: 10 seconds
• Wait for section: 5 seconds
• Total: 15 seconds (rare)

Timeout ceiling: 30 seconds total, never blocks init

Debug Mode Output

When yolo_debug: on in CLAUDE.md:

🐛 DEBUG: Secrets Extraction

Step 1: Navigation
  URL: https://lovable.dev/projects/abc123?view=cloud
  Status: 200 OK
  Load time: 1.2s
  Login required: false
  Result: ✅ Loaded

Step 2: Locate Secrets Section
  Selector 1: [data-testid="secrets-section"] → ✅ Found
  Element: div#secrets-container
  Visibility: visible
  Location: x=200, y=400
  Result: ✅ Located

Step 3: Extract Secret Names
  Pattern 1: [data-testid="secret-key"] → Found 4 items
  Items: ["RESEND_API_KEY", "STRIPE_SECRET_KEY", "OPENAI_API_KEY", "SUPABASE_SERVICE_ROLE_KEY"]
  Validation: All valid secret names
  Deduplication: 0 duplicates found
  Result: ✅ Extracted

Summary:
  Total time: 2.3 seconds
  Secrets found: 4
  Success rate: 100%

Extracted secrets:
  1. RESEND_API_KEY
  2. STRIPE_SECRET_KEY
  3. OPENAI_API_KEY
  4. SUPABASE_SERVICE_ROLE_KEY

Result: ✅ Success

Fallback Manual Instructions

If browser automation is unavailable or fails, provide these instructions:

ℹ️ Could not automatically extract secrets from Lovable Cloud

To view your existing secrets:
1. Open your Lovable project: https://lovable.dev/projects/YOUR_PROJECT_ID
2. Click "Cloud" in the left sidebar
3. Select the "Secrets" tab
4. You'll see all configured secret names

These secrets are already configured:
- Check the list in Lovable
- Compare with the code-detected secrets below

Then we'll merge them together.

Testing Checklist

• [ ] Test with login required (user needs to login)
• [ ] Test with no secrets configured (empty state)
• [ ] Test with many secrets (10+)
• [ ] Test with special characters in secret names
• [ ] Test timeout behavior (page takes >30s to load)
• [ ] Test with different Lovable Cloud UI versions
• [ ] Test fallback when automation unavailable
• [ ] Test debug output with yolo_debug: on
• [ ] Test with duplicate secret names
• [ ] Test with very long secret names

---

This workflow enables the init command to automatically gather secret configuration status from Lovable Cloud, improving the user experience and reducing manual steps.

Yolo Mode: Testing Procedures

Detailed verification workflows for each testing level.

Overview

When yolo_testing: on, run three levels of verification after successful deployment: 1. Level 1: Basic deployment verification (via Lovable) 2. Level 2: Console error checking (production URL) 3. Level 3: Functional testing (actual feature testing)

When yolo_testing: off, skip all testing.

---

Level 1: Basic Deployment Verification

Goal: Confirm deployment succeeded using Lovable's own tools.

For Edge Functions

Procedure:

1. Submit follow-up prompt to Lovable:

   "Show logs for [function-name] edge function"

2. Wait for response (60 second timeout)

3. Analyze logs response:

   Success indicators:
   - Logs show recent deployment timestamp
   - Function status: "active" or "deployed"
   - No error messages in recent logs
   - Deployment success message present

   Warning indicators:
   - Old deployment timestamp (> 5 min ago)
   - Warnings in logs (non-fatal)

   Error indicators:
   - "No logs found"
   - Errors in recent logs
   - Function status: "inactive" or "failed"
   - Deployment error messages

4. Report result:

   ✅ Basic verification: Deployment logs confirm success
   ⚠️ Basic verification: Logs show warnings (details)
   ❌ Basic verification: Errors found in logs (details)

Example - Success:

Prompt: "Show logs for send-email edge function"

Response excerpt:
"Here are the recent logs for send-email:
 [2024-01-15 10:30:15] Deployment started
 [2024-01-15 10:30:18] Function deployed successfully
 [2024-01-15 10:30:19] Function is now active
 No errors in the last 100 log entries."

Analysis:
✅ Recent deployment (< 1 minute ago)
✅ Status: "deployed successfully", "active"
✅ No errors mentioned

Result: ✅ PASS

For Migrations

Procedure:

1. Identify what was migrated:

   - Parse migration file name
   - Extract table/operation from SQL
   - Example: "add_user_preferences.sql" → table: users, operation: add column

2. Submit follow-up prompt to Lovable:

   For table creation:
   "Show me the [table-name] table structure"

   For column addition:
   "Describe the [table-name] table"

   For index creation:
   "Show indexes on [table-name]"

3. Wait for response (60 second timeout)

4. Analyze schema response:

   Success indicators:
   - Table exists (if CREATE TABLE)
   - Column exists (if ADD COLUMN)
   - Schema matches migration
   - No error messages

   Error indicators:
   - "table does not exist"
   - "column not found"
   - Schema doesn't match migration

5. Report result:

   ✅ Basic verification: Migration applied (schema confirmed)
   ❌ Basic verification: Schema doesn't match migration

Example - Success:

Migration: 20240115_add_user_preferences.sql
Content: ALTER TABLE users ADD COLUMN preferences JSONB;

Prompt: "Describe the users table"

Response excerpt:
"The users table has these columns:
 - id (uuid, primary key)
 - email (text)
 - created_at (timestamp)
 - preferences (jsonb)  ← new column
 ..."

Analysis:
✅ Column "preferences" exists
✅ Type matches: jsonb
✅ In correct table: users

Result: ✅ PASS

---

Level 2: Console Error Checking

Goal: Monitor production URL for JavaScript and network errors.

Procedure

1. Navigate to production URL:

   - Read: production_url from CLAUDE.md
   - Example: "https://my-app.lovable.app"
   - Open: New browser tab
   - Wait: Page load complete

2. Access browser console:

   - Open developer tools
   - Navigate to Console tab
   - Clear existing messages

3. Monitor for 10-15 seconds:

   Capture:

   JavaScript Errors:
   - Uncaught exceptions
   - Reference errors (undefined variables)
   - Type errors (wrong types)
   - Syntax errors

   Network Errors:
   - Failed API requests (status 400-599)
   - Edge function call failures
   - CORS errors
   - Timeout errors

4. Filter noise:

   Ignore:
   - Third-party script errors (analytics, ads)
   - Browser extension errors
   - Deprecation warnings
   - Info messages

   Focus on:
   - Errors from application domain
   - Errors related to deployed feature
   - Network errors to Supabase

5. Categorize errors:

   For each error:
   - Type: JS error, network error, etc.
   - Source: File and line number
   - Message: Full error text
   - Severity: Critical, warning, info
   - Related to deployment: yes/no

6. Report findings:

   No errors:
   ✅ Console check: No errors detected

   Warnings only:
   ⚠️ Console check: 2 non-critical warnings
   - Warning: "Cookie SameSite attribute" (browser)
   - Warning: "Deprecated API usage" (third-party)

   Errors found:
   ❌ Console check: 2 errors detected
   - Network: Edge function /send-email returned 500
     Details: "Internal Server Error"
   - JS Error: Cannot read property 'data' of undefined
     Location: app.js:45
     Context: After clicking send button

Example - With Errors:

Console monitoring (15 seconds):

[0.2s] Info: "App initialized"
[1.5s] Warning: "Third-party cookie will be blocked" (chrome)
[3.2s] ❌ Error: "Failed to fetch https://abc.supabase.co/functions/v1/send-email"
       Status: 500 Internal Server Error
       Initiator: app.js:45
[3.2s] ❌ Error: Uncaught TypeError: Cannot read property 'data' of undefined
       at handleEmailResponse (app.js:47)

Analysis:
Total errors: 2
Related to send-email function: ✅ Yes
Severity: High (breaks functionality)

Result: ❌ FAIL
Errors directly related to deployed edge function

---

Level 3: Functional Testing

Goal: Test that the deployed feature actually works.

For Edge Functions

Procedure:

1. Determine endpoint URL:

   Pattern: https://{project-ref}.supabase.co/functions/v1/{function-name}

   Get project-ref from:
   - CLAUDE.md (if documented)
   - src/integrations/supabase/client.ts
   - Ask Lovable: "What's my Supabase project ref?"

2. Prepare test payload:

   Option A: Known test data
   - If function has documented test in CLAUDE.md
   - Use predefined test payload

   Option B: Minimal valid payload
   - For send-email: {"to": "test@example.com", "subject": "Test"}
   - For process-payment: Skip (don't test real payments)

   Option C: Ask user
   - "What test data should I use for [function]?"
   - Wait for user input

3. Make HTTP request:

   Method: POST (usually)
   URL: https://{ref}.supabase.co/functions/v1/{function}
   Headers:
     Authorization: Bearer {anon-key} (from client.ts)
     Content-Type: application/json
   Body: {test payload}
   Timeout: 30 seconds

4. Evaluate response:

   Success: HTTP 200-299
   - Check: Response body structure
   - Verify: Expected fields present
   - Confirm: No error messages

   Client error: HTTP 400-499
   - Indicates: Bad request or auth issue
   - Check: Error message for details

   Server error: HTTP 500-599
   - Indicates: Function failed
   - Check: Error details
   - May need: Secrets, dependencies

   Timeout:
   - Indicates: Function hung or very slow
   - Check: Function complexity

5. Report result:

   Success:
   ✅ Functional test: Function responds correctly (200 OK)
   Response: {"success": true, "messageId": "abc-123"}
   Time: 1.2s

   Error:
   ❌ Functional test: Function error (500)
   Response: {"error": "RESEND_API_KEY not set"}
   Suggestion: Add secret in Cloud → Secrets

   Skipped:
   ⏭️ Functional test: Skipped (no safe test available)
   To test manually: POST to [endpoint] with [example payload]

Example - Success:

Function: send-email
Endpoint: https://abc123.supabase.co/functions/v1/send-email

Test request:
  POST /functions/v1/send-email
  Body: {
    "to": "test@example.com",
    "subject": "Test from yolo mode",
    "body": "This is a test"
  }

Response:
  Status: 200 OK
  Time: 1.4s
  Body: {
    "success": true,
    "messageId": "550e8400-e29b-41d4-a716-446655440000"
  }

Analysis:
✅ Status code in success range
✅ Response has expected structure
✅ "success": true present
✅ Message ID returned
✅ No error fields

Result: ✅ PASS

Example - Error (Missing Secret):

Function: send-email
Endpoint: https://abc123.supabase.co/functions/v1/send-email

Response:
  Status: 500 Internal Server Error
  Time: 0.3s
  Body: {
    "error": "Deno.env.get('RESEND_API_KEY') returned undefined"
  }

Analysis:
❌ Server error (500)
❌ Error message: Secret not configured

Diagnosis:
The function code looks for RESEND_API_KEY but it's not set.

Result: ❌ FAIL

Fix:
1. Go to Cloud → Secrets in Lovable
2. Add: RESEND_API_KEY = [your key]
3. Redeploy the function

For Migrations

Procedure:

1. Determine test query:

   Based on migration type:

   CREATE TABLE:
     SELECT COUNT(*) FROM [table-name];
     → Should succeed and return 0 or more

   ADD COLUMN:
     SELECT [new-column] FROM [table-name] LIMIT 1;
     → Should succeed (even if no rows)

   CREATE INDEX:
     EXPLAIN SELECT * FROM [table] WHERE [indexed-column] = 'value';
     → Should show index usage

   ADD CONSTRAINT:
     Try to violate constraint
     → Should fail with constraint error

2. Execute test via Lovable:

   Submit prompt:
   "Run this query: [test-query]"

   Wait for response (60 second timeout)

3. Analyze result:

   Success indicators:
   - Query executes without error
   - Returns expected result
   - For EXPLAIN: Shows index is used

   Error indicators:
   - "relation does not exist"
   - "column does not exist"
   - Permission denied
   - Syntax error (migration may be malformed)

4. Report result:

   ✅ Functional test: Query succeeded, migration verified
   ❌ Functional test: Query failed, migration may not be applied
   ⏭️ Functional test: Skipped (destructive or complex test)

Example - Success:

Migration: 20240115_add_user_preferences.sql
Operation: ADD COLUMN preferences JSONB

Test query: SELECT preferences FROM users LIMIT 1;

Lovable response:
"Query executed successfully:
 Result: 1 row returned
 preferences: null"

Analysis:
✅ Query succeeded
✅ Column exists and is accessible
✅ Type appears correct (returns null, not error)

Result: ✅ PASS

---

Testing Summary Template

After all 3 levels complete, show summary:

All tests passed:

**Verification Tests:**
1. ✅ Basic verification: Deployment confirmed
2. ✅ Console check: No errors detected
3. ✅ Functional test: Feature works correctly
   [details]

**Overall:** ✅ All tests passed

Some tests failed:

**Verification Tests:**
1. ✅ Basic verification: Deployment confirmed
2. ⚠️ Console check: 1 warning found (non-critical)
   - Warning: [details]
3. ❌ Functional test: Error detected
   - Error: [details]
   - Fix: [suggestion]

**Overall:** ⚠️ Deployed but issues found

Tests skipped (yolo_testing: off):

**Verification Tests:**
- Skipped (yolo_testing is off)

**Overall:** Deployment completed (not verified)
💡 Enable testing with: /yolo on --testing

---

Performance Benchmarks

Typical test timings:

• Level 1: 2-5 seconds
• Level 2: 10-15 seconds
• Level 3: 1-5 seconds

Total testing time: 15-25 seconds

When to skip testing:

• Time-sensitive deployments
• Repeat deployments (already verified)
• Trusted code changes

When to run testing:

• First deployment of new function
• After significant changes
• Before production deployment
• When debugging issues

---

These testing procedures ensure deployed features work correctly and catch issues early.