testchimp-runner-core 0.0.34 → 0.0.36

package/src/prompts.ts

@@ -1,842 +0,0 @@
-/**
- * All LLM prompts used throughout the application
- */
-
-export const PROMPTS = {
-  // Test name generation
-  TEST_NAME_GENERATION: {
-    SYSTEM: 'You are an AI assistant that generates meaningful test names for user journey tests. Carefully analyze the scenario description to look for any hints, indicators, or explicit mentions of what this test should be called. Pay attention to phrases like "test", "scenario", "check", "verify", "flow", or any descriptive terms that suggest the test purpose. If you find such indicators, use them as the basis for the test name. Otherwise, analyze the overall user journey and business purpose. Generate a concise test name (under 30 characters) in camelCase format. Respond with a JSON object in this format: {"testName": "userJourneyName"}',
-    
-    USER: (scenario: string) => `Analyze this scenario description and generate a meaningful test name:\n\n"${scenario}"\n\nInstructions:\n1. Look for ANY hints or indicators in the text that suggest what this test should be called:\n   - Explicit mentions: "Test: ...", "Scenario: ...", "Check: ...", "Verify: ..."\n   - Descriptive phrases: "...flow", "...process", "...journey", "...workflow"\n   - Action-focused terms: "login", "registration", "purchase", "messaging", "search"\n   - Business context: "user onboarding", "checkout process", "team collaboration"\n2. If you find such indicators, use them as the basis for the test name\n3. If not found, analyze the user journey and business purpose\n4. Generate a concise name under 30 characters in camelCase\n\nExamples:\n- "Test: User login and messaging flow" -> "userLoginAndMessagingFlow"\n- "Checkout process with payment" -> "checkoutProcess"\n- "User registration and email verification" -> "userRegistration"\n- "Team messaging and collaboration" -> "teamMessaging"`
-  },
-
-  // Hashtag generation for semantic grouping
-  HASHTAG_GENERATION: {
-    SYSTEM: 'You are an AI assistant that generates relevant hashtags for test scenarios to enable semantic grouping across test files. Analyze the scenario description and generate 2-5 hashtags that capture the key aspects of the test such as functionality, user journey, or domain.',
-    
-    USER: (scenario: string) => `Analyze this scenario description and generate relevant hashtags for semantic grouping:\n\n"${scenario}"\n\nInstructions:\n1. Identify the main functionality being tested (e.g., #login, #checkout, #messaging)\n2. Identify the user journey type (e.g., #registration, #onboarding, #payment)\n3. Identify the domain/area (e.g., #ecommerce, #social, #admin)\n4. Identify any specific features (e.g., #search, #upload, #notification)\n5. Generate 2-5 hashtags that are:\n   - Concise and descriptive\n   - Lowercase with no spaces or special characters\n   - Relevant for grouping similar tests\n\nExamples:\n- "User login and messaging flow" -> ["#login", "#messaging", "#social"]\n- "Checkout process with payment" -> ["#checkout", "#payment", "#ecommerce"]\n- "User registration and email verification" -> ["#registration", "#verification", "#onboarding"]\n\nRespond with JSON: {"hashtags": ["#tag1", "#tag2", "#tag3"]}`
-  },
-
-  // Scenario breakdown
-  SCENARIO_BREAKDOWN: {
-    SYSTEM: `Split user scenarios into individual steps. Copy each step exactly as provided. Do not add, expand, or modify.`,
-    
-    USER: (scenario: string) => `Split this into steps. Keep each step exactly as written.
-
-${scenario}
-
-Return JSON: {"steps": ["step 1", "step 2", ...]}`
-  },
-
-  // Goal completion assessment
-  GOAL_COMPLETION_CHECK: {
-    SYSTEM: 'You are an expert test automation analyst. Evaluate whether a goal has been fully achieved. Be EXTREMELY CONSERVATIVE - mark goals complete when the PRIMARY action succeeds. DO NOT invent verification steps that were not explicitly requested. However, if the scenario explicitly specifies verification requirements, those MUST be completed and not skipped.',
-    
-    USER: (goalDescription: string, completedActions: string[], pageInfo: any) => `Analyze whether the following goal has been fully completed:
-
-    GOAL: "${goalDescription}"
-    
-    COMPLETED ACTIONS IN THIS STEP:
-    ${completedActions.map((action, idx) => `${idx + 1}. ${action}`).join('\n')}
-    
-    CURRENT PAGE STATE:
-    - URL: ${pageInfo.url}
-    - Title: ${pageInfo.title}
-    - Interactive Elements:
-${pageInfo.formattedElements}
-    
-    CRITICAL GUIDELINES - MARK COMPLETE AGGRESSIVELY:
-    
-    1. **Action Goals vs Verification Goals**:
-       - If goal is an ACTION (click, type, select, send, submit), mark COMPLETE after successful action
-       - If goal is VERIFICATION (verify, check, ensure, assert), mark COMPLETE after assertion passes
-       - NEVER add verification to action goals - if the goal doesn't mention verification, don't require it
-       - HOWEVER: If verification is EXPLICITLY mentioned in the goal, it MUST be completed - do not skip it
-    
-    2. **Understand Action Semantics** (what does the action verb really mean):
-       
-       Some actions are ATOMIC (one operation):
-       - "Click X" → Just click
-       - "Type X into field" → Just type
-       - "Navigate to URL" → Just navigate
-       - "Select option" → Just select
-       
-       Other actions imply a WORKFLOW with implicit final trigger:
-       - ANY action verb that implies submission/sending/triggering
-       - If the action includes data to provide, it usually implies using that data
-       - If the action name is a business process (login, register, send, post, etc.), think about what the user expects to happen
-       
-       **General Pattern Recognition:**
-       
-       Ask yourself: "In normal usage, does [ACTION VERB] require a final trigger/button?"
-       - "Login" → Yes, requires clicking a login/submit button after entering credentials
-       - "Send" → Yes, requires clicking a send button after typing content
-       - "Post" → Yes, requires clicking a post/publish button after entering content
-       - "Search for X" → Yes, requires triggering search after entering search term
-       - "Filter by X" → Maybe, depends on if filter auto-applies or needs button
-       - "Fill in X" → No, just data entry unless goal says "fill AND submit"
-       
-       Mark COMPLETE when the BUSINESS ACTION is done from user perspective:
-       - Not complete if you only prepared data (filled fields) but didn't trigger the action
-       - Complete when the system would have processed/submitted/executed the action
-       
-       Examples:
-       - "Login with credentials: X" → Incomplete until credentials submitted (button clicked)
-       - "Send message: Y" → Incomplete until message sent (send button clicked)  
-       - "Fill in name field" → Complete after fill (no submission implied)
-       - "Search for products" → Incomplete until search triggered
-       
-       Think: "From a user's perspective, is the action done?" not "Did I type the data?"
-    
-    3. **Multi-part Goals** (explicit multiple requirements):
-       - "Fill in ALL fields" → Need multiple fills for each field
-       - "Click submit AND verify success message appears" → Need both click + explicit verification
-       - Goals with explicit "and" requiring multiple distinct actions
-    
-    4. **NEVER Create Hallucinated Verification Sub-goals, BUT Honor Explicit Verification Requirements**:
-       - Don't invent verification steps that weren't in the original goal
-       - Don't look for confirmation messages unless goal explicitly asks for them
-       - Don't check for success indicators unless goal explicitly requires verification
-       - Trust Playwright's execution - if action succeeded without error, it worked
-       - Action success IS the completion criteria for action goals
-       - CRITICAL: If the goal explicitly says "verify", "check", "ensure", "confirm" something, that verification MUST be completed
-    
-    5. **State Changes After Actions Are SUCCESS, Not Failure**:
-       - Button becomes disabled after click → SUCCESS (expected behavior)
-       - Form clears after submit → SUCCESS (expected behavior)
-       - Page navigates after action → SUCCESS (expected behavior)
-       - Element disappears after interaction → SUCCESS (expected behavior)
-    
-    6. **What "nextSubGoal" Should Look Like**:
-       - For "Fill in all fields" with 5 fields, if 2 filled: "Fill in the remaining 3 fields" ✅
-       - For "Click submit AND verify", if clicked but not verified: "Verify the success message appears" ✅
-       - For "Click send button" after click succeeds: NO nextSubGoal - COMPLETE ✅
-       - DON'T create nextSubGoal for verification unless goal explicitly asks for it ❌
-       
-       CRITICAL - Preserve specific values in nextSubGoal:
-       - Original: "Login with credentials: admin, pass123" (username filled, password not)
-         ✅ nextSubGoal: "Enter password: pass123"
-         ❌ NOT: "Complete the login" (loses the password value!)
-       
-       - Original: "Enter user details: Name: John, Email: john@test.com" (name done, email not)
-         ✅ nextSubGoal: "Enter email: john@test.com"
-         ❌ NOT: "Enter email address" (loses specific email!)
-    
-    Examples:
-    
-    ✅ PURE ACTION GOALS (no verification in description - complete after action):
-    - Goal: "Click the send button" + Action: click() succeeded → COMPLETE ✅ (no verification needed)
-    - Goal: "Enter email address" + Action: fill() succeeded → COMPLETE ✅ (no verification needed)
-    - Goal: "Navigate to dashboard" + Action: goto() succeeded → COMPLETE ✅ (no verification needed)
-    - Goal: "Submit the form" + Action: click() succeeded → COMPLETE ✅ (no verification needed)
-    
-    ⏳ GOALS WITH EXPLICIT VERIFICATION (must complete BOTH action AND verification):
-    - Goal: "Click send and verify message sent" + Action: click() succeeded → INCOMPLETE ⏳ nextSubGoal: "Verify message sent confirmation"
-    - Goal: "Submit form and check for success message" + Action: submit clicked → INCOMPLETE ⏳ nextSubGoal: "Check for success message"
-    - Goal: "Login and verify dashboard appears" + Action: login completed → INCOMPLETE ⏳ nextSubGoal: "Verify dashboard appears"
-    
-    ✅ PURE VERIFICATION GOALS (complete after verification):
-    - Goal: "Verify page title is correct" + Action: assertion passed → COMPLETE ✅
-    - Goal: "Check that the error message is displayed" + Action: assertion passed → COMPLETE ✅
-    - Goal: "Ensure user is logged in" + Action: assertion passed → COMPLETE ✅
-    
-    ⏳ MULTI-STEP ACTION GOALS (complete all parts):
-    - Goal: "Fill in all required fields" + Action: filled 2 of 5 → INCOMPLETE ⏳ nextSubGoal: "Fill in remaining 3 fields"
-    
-    GOLDEN RULE: 
-    - If the goal is a SIMPLE ACTION and that action SUCCEEDED, mark COMPLETE immediately
-    - Don't hallucinate verification requirements that weren't explicitly requested
-    - BUT if verification IS explicitly mentioned in the goal, it MUST be completed before marking COMPLETE
-    - Only verify what is instructed to be verified, nothing more, nothing less
-    
-    Respond with JSON:
-    {
-      "isComplete": true/false,
-      "reason": "brief explanation - if action succeeded and goal was just the action, mark complete",
-      "nextSubGoal": "ONLY if goal has multiple parts and not all parts done yet - must be based on ACTUAL goal requirements, not invented verification"
-    }`
-  },
-
-  // Screenshot need assessment
-  SCREENSHOT_NEED_ASSESSMENT: {
-    SYSTEM: 'You are an expert test automation analyst. Determine if visual screenshot analysis is ABSOLUTELY NECESSARY to solve this failure. Vision mode is expensive (GPT-4o), so only recommend when there is CLEAR diagnostic value that DOM cannot provide.',
-    
-    USER: (stepDescription: string, errorMessage: string, attemptCount: number, pageInfo: any) => `After 2 failures, determine if VISION MODE is absolutely necessary. This is the ONLY chance to use vision.
-
-    STEP: "${stepDescription}"
-    ERROR: "${errorMessage}"
-    ATTEMPT: ${attemptCount} (after ${attemptCount - 1} failures - vision can diagnose the issue)
-    
-    CURRENT DOM INFO AVAILABLE:
-    - URL: ${pageInfo.url}
-    - Interactive Elements:
-${pageInfo.formattedElements}
-    
-    🎯 VISION MODE - USE SPARINGLY (Expensive GPT-4o):
-    
-    Vision provides diagnostic value ONLY when DOM information is truly insufficient.
-    
-    ✅ **RECOMMEND SCREENSHOT only for these HIGH-VALUE cases:**
-    
-    1. **Suspected Element Hallucination** (HIGH priority):
-       - Previous attempts tried getByText/toBeVisible for elements that might not exist
-       - Error: "not found" or "timeout" on verification attempts
-       - Visual will definitively show if elements exist or if we need alternative verification
-    
-    2. **Visual-Only Elements**:
-       - Icons, images, or visual indicators without text/roles
-       - Elements identified by position ("button on the right")
-       - Shadow DOM or complex component structures
-    
-    3. **Visual Blockers**:
-       - Overlays, modals, or popups blocking interactions
-       - Z-index issues preventing clicks
-       - Scrolling problems that DOM doesn't reveal
-    
-    ❌ **DO NOT RECOMMEND SCREENSHOT when:**
-    - **Strict mode violations / multiple matches** - Accessibility tree shows duplicates, use DOM info to scope selector
-    - Simple selector errors (try different selector strategies first)
-    - Navigation issues (URL problems are not visual)
-    - Invalid Playwright API (syntax errors)
-    - Timing issues that can be solved with better waits
-    - DOM clearly shows the solution (IDs, data-testid available)
-    - Error has obvious DOM-based fix
-    
-    **Conservative Assessment Required:**
-    - Vision mode is EXPENSIVE (uses GPT-4o)
-    - This is the ONLY chance (attempt 3 of 4)
-    - Only recommend if DOM truly cannot solve it
-    - If in doubt, suggest DOM-based alternative instead
-    
-    Respond with JSON:
-    {
-      "needsScreenshot": true/false,
-      "reason": "If true: [specific diagnostic value vision provides]. If false: [why DOM-based approach is sufficient]",
-      "alternativeApproach": "REQUIRED if needsScreenshot=false: [specific DOM-based solution to try next]"
-    }
-    
-    Remember: Default to NO unless there's compelling evidence that visual analysis is the ONLY way to solve this.`
-  },
-
-  // Playwright command generation
-  PLAYWRIGHT_COMMAND: {
-    SYSTEM: 'You are an expert Playwright automation engineer with strong self-awareness and problem-solving skills. You understand cause-and-effect, learn from your own actions, and can reason about application state changes.',
-    
-    USER: (stepDescription: string, pageInfo: any, previousCommands: string, attemptHistory: string, errorContext: string) => `You are working to achieve a specific goal. Generate ONE precise Playwright command that makes progress.
-
-    🎯 CURRENT GOAL: "${stepDescription}"
-    
-    📋 WHAT YOU'VE ALREADY DONE IN THIS STEP:
-    ${previousCommands || 'Nothing yet - this is the first action for this goal'}
-    
-    ${errorContext ? `⚠️ PREVIOUS ATTEMPT FAILED:\n${errorContext}\n` : ''}
-    ${attemptHistory ? `📊 ALL ATTEMPTS SO FAR:\n${attemptHistory}\n` : ''}
-
-    🧠 SELF-AWARENESS & REASONING:
-    
-    1. **Analyze Your Own Actions**:
-       - Review what you've ALREADY done in this step above
-       - Did your previous actions CAUSE the current state?
-       - Ask: "What is the LOGICAL consequence of what I just did?"
-       - Understand that your actions change the application state
-    
-    2. **Understand Cause & Effect**:
-       - Element state changed? → Did YOUR previous action cause it?
-       - Element not found? → Did YOUR action remove it or navigate away?
-       - Validation error? → Did YOUR action trigger it (empty field, wrong format)?
-       - Before retrying, ask: "Is this the EXPECTED result of my actions?"
-    
-    3. **Self-Correction Logic**:
-       - If you caused the problem → Fix it (don't just retry)
-       - If you achieved the goal (even with side effects) → Move on!
-       - If you're stuck in a loop → You're fighting expected behavior, change approach
-       - Don't undo successful work or fight against normal state transitions
-    
-    4. **Smart Recovery**:
-       - Element not ready/unavailable → Identify what prerequisite is missing, complete it first
-       - Element not found → Distinguish between: your action removed it (success) vs genuine error
-       - Multiple failures on same approach → Fundamentally rethink strategy, don't iterate blindly
-       - Stuck in retry loop → Step back, analyze root cause, try completely different approach
-    
-    5. **NEVER Hallucinate Verification Elements**:
-       - ONLY verify elements that ACTUALLY EXIST in the current DOM state
-       - Check the "CURRENT PAGE STATE" section for what elements are available
-       - Don't look for "success message", "confirmation text", or "sent message" unless you see them in the DOM
-       - Don't invent text patterns or regex for elements that don't exist
-       - If verification is needed but element doesn't exist, use alternative methods:
-         * Check for state changes (button disabled, form cleared, URL changed)
-         * Wait for page load state changes
-         * Check for element detachment/attachment
-         * Use waitForResponse for network verification
-       - When previous attempts failed looking for non-existent elements, STOP trying to find them
-    
-    6. **Navigation and Redirects** (CRITICAL):
-       
-       Handle redirects properly - DON'T keep retrying original URL if navigation succeeded:
-       
-       - For navigation, use explicit 10-second timeout (default is 5s, too short for redirects):
-         await page.goto(url, { waitUntil: 'domcontentloaded', timeout: 10000 })
-       
-       - Why longer timeout for navigation:
-         * Redirects take extra time
-         * Initial page loads are slower
-         * Default 5s timeout is for fast element operations only
-       
-       - If navigation times out or throws "execution context destroyed":
-         * CHECK CURRENT URL FIRST: const currentUrl = page.url()
-         * If URL changed from about:blank → Navigation SUCCEEDED (even if redirected)
-         * DON'T retry goto() if already on a page
-         * Proceed with next step
-       
-       - Navigation succeeded if:
-         * page.url() is NOT 'about:blank'
-         * page.url() changed from previous URL
-         * Even if different from target URL (redirects are normal)
-       
-       - Only retry navigation if:
-         * page.url() is still 'about:blank' or previous URL
-         * AND no redirect happened
-    
-    7. **Real-World Web App Resilience**:
-       
-       Common Interruptions (handle gracefully):
-       - Cookie consent banners → Dismiss if blocking main UI (look for "Accept", "OK", "Close")
-       - Modal popups → Close if not relevant to current goal (look for X button, "Dismiss")
-       - Page refreshes → Re-find elements, don't assume page state persists
-       - Loading states → Wait for content, check for spinners/loading indicators
-       - Overlays → Dismiss or wait for them to disappear before proceeding
-       
-       Detection Patterns:
-       - If element suddenly not found → Check if overlay/modal appeared
-       - If click fails → Check if cookie banner is blocking element
-       - If page URL changed unexpectedly → Handle redirect/refresh gracefully
-       - If timeout occurs → Check for loading indicators, wait for them to disappear
-       
-       Resilience Strategies:
-       - Before critical interactions, check for and dismiss blocking overlays
-       - After page loads, wait for dynamic content (networkidle, specific elements)
-       - If element covered/blocked, look for overlay and close it
-       - Use flexible selectors that work across page refreshes
-       - Add waits for elements that load dynamically
-       
-       Examples:
-       - If cookie banner present: await page.getByRole('button', {name: /accept|ok|agree/i}).click();
-       - If modal blocking: await page.getByRole('button', {name: /close|dismiss|x/i}).click();
-       - After action that might refresh: await page.waitForLoadState('domcontentloaded');
-       - For dynamic content: await page.getByText('expected content').waitFor();
-    
-    8. **Use Specific Values from Goal Description**:
-       
-       CRITICAL: Extract and use exact values mentioned in the goal.
-       
-      Examples:
-      - Goal: "Login with credentials: alice, pass123"
-        ✅ Use: await page.fill('username', 'alice'); await page.fill('password', 'pass123');
-        ❌ NOT: await page.fill('username', process.env.USERNAME);
-       
-       - Goal: "Enter name: John Doe"
-         ✅ Use: await page.fill('[name="name"]', 'John Doe');
-         ❌ NOT: await page.fill('[name="name"]', 'Test User');
-       
-       Apply this to ANY specific value in the goal (amounts, dates, selections, text, etc.).
-       
-       NEVER:
-       - Replace specific values with environment variables
-       - Replace specific values with generic test data
-       - Hallucinate different values than what's in the goal
-       - Use process.env, config, or placeholder values
-       
-       Be creative ONLY when goal doesn't specify values:
-       - "Login with valid credentials" → Infer reasonable values
-       - "Login with credentials: admin, pass123" → Use EXACTLY those values
-    
-    GOAL-ORIENTED APPROACH:
-    - What needs to be done to achieve this goal?
-    - Have I ALREADY done parts of this? (check "WHAT YOU'VE ALREADY DONE")
-    - If yes, what's the NEXT logical action?
-    - If retrying after failure, WHY did it fail? Did I cause it?
-    - Is something blocking the UI? (cookie banner, modal, overlay)
-    - Extract any specific values from the goal and use them EXACTLY
-    
-    9. **Strict Mode Violations & Multiple Matches** (CRITICAL):
-       
-       Playwright throws "strict mode violation" when a selector matches MULTIPLE elements.
-       
-      **PROACTIVE DETECTION** - Check BEFORE generating command:
-      - Review the "CURRENT PAGE STATE" section below (accessibility tree / aria snapshot)
-      - Look for duplicate elements with same role/text (e.g., multiple links with "Settings")
-      - If duplicates exist, generate a MORE SPECIFIC selector from the start
-      - Don't wait for strict mode error - prevent it by analyzing the DOM structure
-      
-      🚨 ERROR PATTERNS:
-      - "strict mode violation" → Your selector matched multiple elements
-      - "Multiple elements found" → Same issue
-      - "locator resolved to 2 elements" → Often one is a tooltip/popover with duplicate text
-      - Command chain with multiple strategies → Sign of selector problems
-      
-      ✅ SOLUTIONS (in order of preference):
-      
-      **Option 1: Use Role-Based Selectors** (BEST - avoids tooltips):
-      - BAD: page.getByText('Settings').click() → Matches button AND its tooltip
-      - GOOD: page.getByRole('button', { name: 'Settings' }).click() → Only matches button role
-      - GOOD: page.locator('button').getByText('Settings').click() → Scoped to button tag
-      - GOOD: page.locator('[role="button"]').getByText('Settings').click() → Scoped to role
-      
-      **Option 2: Scope to Container**:
-      - BAD: page.locator('a', { hasText: 'Settings' }).click() → Matches multiple links
-      - GOOD: page.locator('nav a', { hasText: 'Settings' }).click() → Scoped to nav
-      - GOOD: page.locator('a[href*="/settings"]').click() → Use unique attribute
-      
-      **Option 2: Use Position-Based Selection**:
-      - If multiple matches are expected: page.locator('a', { hasText: 'Settings' }).first().click()
-      - Or use: .nth(0) for first, .last() for last
-      
-      **Option 3: Filter by Visibility/State**:
-      - page.locator('button', { hasText: 'Submit' }).filter({ hasNotText: 'Draft' }).click()
-      
-      🚫 **ANTI-PATTERNS (DON'T DO THIS)**:
-      - BAD: Chaining multiple selector strategies in one command with semicolons
-      - BAD: Using page.evaluate() to find/click elements (defeats Playwright's auto-waiting)
-      - GOOD: ONE clear, specific selector like page.locator('nav a', { hasText: 'Settings' }).click()
-       
-       **When You See Strict Mode Errors:**
-       1. Analyze - Why did my selector match multiple elements?
-       2. Narrow Down - Add parent context (nav, sidebar, header)
-       3. Combine - Use multiple attributes (role + text, class + href)
-       4. Position - If truly ambiguous, use .first() or .nth()
-       5. NEVER - Chain multiple selector attempts or use page.evaluate()
-       
-       **Key Principle:**
-       - ONE command = ONE clear selector strategy
-       - Don't hedge your bets with multiple approaches
-       - Trust Playwright's auto-waiting and built-in selectors
-    
-    CRITICAL RULES:
-    - Generate ONLY ONE command that moves toward the goal
-    - NEVER undo your own successful work (don't clear fields you just filled!)
-    - If previous attempts failed, analyze WHY before trying different approach
-    - Learn from failures and your own action history
-    - Use the most reliable selectors (prefer getByRole, getByText, getByLabel)
-    - Trust Playwright's auto-waiting - if click succeeded, it worked!
-    - If strict mode violation: Make selector MORE SPECIFIC or use .first()
-    - Generate ONE clear command, not multiple chained selector attempts
-    
-    ELEMENT SELECTION PRIORITY:
-    1. getByTestId() - BEST if data-testid is available (most stable, designed for tests)
-    2. locator('#id') - EXCELLENT if element has unique ID (stable, direct targeting)
-    3. getByRole() - Very reliable for interactive elements (semantic)
-    4. getByText() - For text content (good for unique text)
-    5. getByLabel() - For form inputs (semantic)
-    6. getByPlaceholder() - For input placeholders
-    7. locator() with CSS classes - Last resort (brittle, changes frequently)
-    
-    COMMON PATTERNS (prefer IDs/data-testid when available):
-    - Navigation: await page.goto('url')
-    - Click with testid: await page.getByTestId('submit-btn').click()
-    - Click with ID: await page.locator('#login-button').click()
-    - Click with role: await page.getByRole('button', { name: 'text' }).click()
-    - Type with testid: await page.getByTestId('username-input').fill('text')
-    - Type with ID: await page.locator('#email').fill('text')
-    - Type with role: await page.getByRole('textbox', { name: 'label' }).fill('text')
-    - Wait: await page.waitForLoadState('networkidle')
-    - Verify: await expect(page).toHaveTitle(/expected/)
-    
-    IMPORTANT: Use IDs/data attributes in COMMANDS, but keep goal descriptions semantic!
-    
-    CODE STYLE GUIDELINES:
-    - Keep commands concise and clean
-    - Avoid explicit timeouts unless necessary
-    - Use Playwright's built-in auto-waiting
-    - Only add timeouts for specific slow operations
-    - Prefer single-line commands when possible
-    
-    VALID PLAYWRIGHT API REFERENCE:
-    - locator.waitFor({ state: 'visible'|'hidden'|'attached'|'detached' }) - ONLY these states
-    - NEVER use waitFor({ state: 'enabled' }) - THIS IS INVALID
-    - For disabled elements: Use page.waitForFunction() with DOM check
-    - CSS selectors: Standard CSS only (no :has-text(), :enabled pseudo-classes)
-    - Playwright pseudo-selectors only work in locator(), NOT in querySelector()
-    
-    RETRY STRATEGIES:
-    - Timeout errors: Add waitFor() or increase timeout, check for loading states
-    - Not found errors: Try different selectors, wait for element, or check if DOM changed
-    - Not visible errors: Scroll into view, dismiss overlays, or wait for visibility
-    - Not enabled/Disabled errors: Identify and complete prerequisites that enable the element
-    - Detached errors: Element removed from DOM, refetch or use different selector
-    - Covered/Blocked errors: Close overlays, modals, or popups blocking the element
-    
-    ELEMENT STATE AWARENESS:
-    - Element disabled/inactive? → Identify and complete the prerequisite (fill required fields, check boxes, select options)
-    - Interacting with unavailable elements ALWAYS fails → Enable/prepare element state first
-    - Review your action history → Did you reverse a prerequisite? Complete it again before proceeding
-    - Different element states need different handling:
-      * Disabled → Complete prerequisites (validation, required fields, agreements)
-      * Hidden/Not visible → Scroll, dismiss overlays, or wait for visibility
-      * Detached → Element removed from DOM, may need navigation or different selector
-      * Loading → Wait for completion before interaction
-    
-    TIMEOUT GUIDELINES:
-    - Only add explicit timeouts for slow operations (file uploads, large data loads)
-    - Use page.waitForLoadState('networkidle') for page navigation
-    - Use element.waitFor() only when waiting for specific conditions
-    - Let Playwright's auto-waiting handle most interactions
-    
-    Respond with JSON:
-    {
-      "command": "await page.goto('https://www.google.com');",
-      "reasoning": "Direct navigation to target URL",
-      "selectorStrategy": "direct_navigation"
-    }
-    
-    Current State:
-    - URL: ${pageInfo.url}
-    - Title: ${pageInfo.title}
-    - Interactive Elements:
-${pageInfo.formattedElements}
-    
-    Previous Commands:
-    \`\`\`javascript
-    ${previousCommands}
-    \`\`\`
-    
-    ${attemptHistory}
-    
-    ${errorContext}
-    
-    Step to execute: "${stepDescription}"`
-  },
-
-  // Vision diagnostic analysis (supervisor reviewing screenshot)
-  VISION_DIAGNOSTIC_ANALYSIS: {
-    SYSTEM: 'You are a senior QA supervisor with vision capabilities. Analyze the screenshot AND DOM snapshot together to identify what went wrong and provide specific instructions with accurate selectors.',
-    
-    USER: (stepDescription: string, pageInfo: any, previousCommands: string, attemptHistory: string, errorContext: string) => `Analyze screenshot + DOM snapshot to diagnose failures and provide specific instructions.
-
-🎯 GOAL: "${stepDescription}"
-
-📸 SCREENSHOT + 🌳 DOM SNAPSHOT:
-Correlate visual elements in screenshot with DOM structure below.
-
-**DOM Snapshot:**
-- URL: ${pageInfo.url}
-- Title: ${pageInfo.title}
-- Interactive Elements:
-${pageInfo.formattedElements}
-
-**Previous Failed Attempts:**
-${previousCommands || 'None'}
-
-**Errors:**
-${errorContext || 'None'}
-
-**Your Task:**
-1. Look at screenshot - identify target element visually
-2. Look at DOM - find matching element in ARIA tree
-3. Check if element has ID or data-testid (best selectors)
-4. Provide EXACT selector from DOM
-
-Respond with JSON:
-{
-  "visualAnalysis": "I see...",
-  "rootCause": "Failed because...",
-  "specificInstructions": "Click element with [exact selector from DOM]...",
-  "recommendedApproach": "Use page.locator('[exact-attribute]')...",
-  "elementsFound": ["element with id='x'", "button[name='y']"],
-  "elementsNotFound": ["element worker looked for but doesn't exist"]
-}`
-  },
-
-  // Playwright command generation with supervisor instructions
-  PLAYWRIGHT_COMMAND_WITH_SUPERVISOR: {
-    SYSTEM: 'You are a Playwright automation engineer. Your supervisor has analyzed a screenshot and provided specific instructions. Follow their instructions EXACTLY to generate the correct command.',
-    
-    USER: (stepDescription: string, supervisorInstructions: string, supervisorAnalysis: string, elementsFound: string[], elementsNotFound: string[], pageInfo: any) => `Your supervisor has reviewed the screenshot and provided specific instructions. Follow them EXACTLY.
-
-    🎯 ORIGINAL GOAL: "${stepDescription}"
-    
-    👔 SUPERVISOR'S VISUAL ANALYSIS:
-    ${supervisorAnalysis}
-    
-    📋 SUPERVISOR'S SPECIFIC INSTRUCTIONS:
-    ${supervisorInstructions}
-    
-    ✅ ELEMENTS THAT EXIST (confirmed by supervisor from screenshot):
-    ${elementsFound.length > 0 ? elementsFound.map((el, i) => `${i + 1}. ${el}`).join('\n') : 'None specified'}
-    
-    ❌ ELEMENTS THAT DON'T EXIST (confirmed absent from screenshot):
-    ${elementsNotFound.length > 0 ? elementsNotFound.map((el, i) => `${i + 1}. ${el}`).join('\n') : 'None specified'}
-    
-    **YOUR TASK:**
-    Generate ONE Playwright command that implements the supervisor's instructions EXACTLY.
-    
-    **CRITICAL RULES:**
-    1. Follow supervisor's instructions to the letter
-    2. ONLY use elements from "ELEMENTS THAT EXIST" list
-    3. NEVER try to find elements from "ELEMENTS THAT DON'T EXIST" list
-    4. Use the exact selectors/strategies supervisor recommended
-    5. If supervisor said "don't verify X, check Y instead" - do exactly that
-    
-    **Current DOM Context:**
-    - URL: ${pageInfo.url}
-    - Interactive Elements:
-${pageInfo.formattedElements}
-    
-    Respond with JSON:
-    {
-      "command": "await page.locator('#exact-selector').click();",
-      "reasoning": "Following supervisor's instruction to [what you're doing]"
-    }`
-  },
-
-  // Legacy vision command generation (kept for compatibility)
-  PLAYWRIGHT_COMMAND_WITH_VISION: {
-    SYSTEM: 'Analyze screenshot + DOM together. Correlate visual elements with DOM to generate accurate Playwright commands with precise selectors.',
-    
-    USER: (stepDescription: string, pageInfo: any, previousCommands: string, attemptHistory: string, errorContext: string) => `Vision mode: Correlate screenshot with DOM to generate command.
-
-🎯 GOAL: "${stepDescription}"
-
-📸 SCREENSHOT + 🌳 DOM SNAPSHOT:
-Correlate visual elements in screenshot with DOM structure below.
-
-**DOM Snapshot:**
-- URL: ${pageInfo.url}
-- Title: ${pageInfo.title}
-- Interactive Elements:
-${pageInfo.formattedElements}
-
-**Previous Failed Attempts:**
-${previousCommands || 'None'}
-
-**Errors:**
-${errorContext || 'None'}
-
-**Your Task:**
-1. Look at screenshot - identify target element visually
-2. Look at DOM - find matching element in ARIA tree
-3. Check if element has ID or data-testid (best selectors)
-4. Generate command with EXACT selector from DOM
-
-Respond with JSON:
-{
-  "command": "await page.locator('[exact-selector-from-dom]').click();",
-  "reasoning": "Visual element matches DOM element with [attribute]",
-  "visualInsights": "I see [element] in screenshot",
-  "failureRootCause": "Previous failed because [reason]",
-  "recommendedAlternative": "Use [strategy]"
-}`
-  },
-
-  // Script parsing for AI repair
-  SCRIPT_PARSING: {
-    SYSTEM: 'Parse Playwright scripts into steps. Use existing // comments as step boundaries.',
-    
-    USER: (script: string) => `Extract steps from this script.
-
-Find code INSIDE: test('...', async ({ page, browser, context }) => { ... })
-
-Each // comment starts a new step. Use comment text (without //) as description.
-Preserve code exactly.
-
-Script:
-${script}
-
-Return JSON: {"steps": [{"description": "...", "code": "..."}, ...]}`
-  },
-
-  // Repair suggestion
-  REPAIR_SUGGESTION: {
-    SYSTEM: 'You are an expert test automation engineer specializing in fixing failing Playwright tests. Analyze the current DOM state, error message, and step description to suggest the best repair action. Consider the failure history to avoid repeating the same mistakes. CRITICAL: Only use valid Playwright API methods.',
-    
-    USER: (stepDescription: string, stepCode: string, errorMessage: string, pageInfo: any, failureHistory: string, recentRepairs: string) => `Analyze this failing Playwright test step and suggest a repair action.
-
-    Current Step:
-    Description: ${stepDescription}
-    Code: ${stepCode}
-    Error: ${errorMessage}
-
-    Current Page State:
-    - URL: ${pageInfo.url}
-    - Title: ${pageInfo.title}
-    - Interactive Elements:
-${pageInfo.formattedElements}
-
-    ${failureHistory}
-
-    ${recentRepairs}
-
-    VALID PLAYWRIGHT API METHODS (DO NOT use methods not listed here):
-    
-    Locator Methods:
-    - .click({ force: true })  // Force click even if element is covered
-    - .click({ timeout: 10000 })  // Increase timeout
-    - .fill(value)
-    - .type(value, { delay: 100 })  // Type with delay
-    - .press('Enter')
-    - .selectOption(value)
-    - .check() / .uncheck()
-    - .scrollIntoViewIfNeeded()  // NOT scrollIntoView() - that doesn't exist!
-    - .waitFor({ state: 'visible' })
-    - .waitFor({ state: 'attached' })
-    - .isVisible()
-    - .isEnabled()
-    - .count()
-    - .first() / .last() / .nth(index)
-    - .filter({ hasText: 'text' })
-    
-    Page Methods:
-    - page.goto(url, { waitUntil: 'networkidle' })
-    - page.waitForLoadState('networkidle')
-    - page.waitForTimeout(ms)
-    - page.evaluate(() => window.scrollBy(0, 500))  // Scroll page
-    - page.getByRole(role, { name: 'text' })
-    - page.getByText('text')
-    - page.getByLabel('text')
-    - page.getByPlaceholder('text')
-    - page.getByTestId('id')
-    - page.locator('selector')
-    
-    COMMON FIXES FOR "element outside viewport":
-    - Use { force: true } option: await locator.click({ force: true });
-    - Scroll page first: await page.evaluate(() => window.scrollBy(0, 300));
-    - Wait longer: await locator.click({ timeout: 10000 });
-    - Click parent/container instead if element has overlays
-    
-    INVALID METHODS TO AVOID:
-    - ❌ .scrollIntoView() - DOES NOT EXIST (use .scrollIntoViewIfNeeded() instead)
-    - ❌ .scrollIntoView({ behavior: 'smooth' }) - WRONG API
-    - ❌ Any jQuery methods - This is Playwright, not jQuery
-    
-    Choose the best repair action:
-    1. MODIFY - Fix the current step with better selectors, waits, or logic
-    2. INSERT - Add a new step before the current one (e.g., wait for element, handle popups)
-    3. REMOVE - Skip this step entirely if it's not essential
-
-    IMPORTANT: Your repair code MUST use ONLY valid Playwright API methods listed above!
-
-    Respond with JSON:
-    {
-      "shouldContinue": true/false,
-      "reason": "explanation of decision",
-      "action": {
-        "operation": "MODIFY|INSERT|REMOVE",
-        "newStep": {
-          "description": "step description",
-          "code": "await page.getByRole('button', { name: 'Submit' }).click({ force: true });"
-        }
-      }
-    }`
-  },
-
-  // Repair confidence assessment
-  REPAIR_CONFIDENCE: {
-    SYSTEM: 'You are an expert test automation engineer who writes concise repair advice to build a running understanding of this test behavior and repairs done.',
-    
-    USER: (originalScript: string, updatedScript: string) => `You are an expert test automation engineer. Generate a short repair advice that will be used to build a running understanding of this test.
-
-            Original Script:
-            ${originalScript}
-
-            Repaired Script:
-            ${updatedScript}
-
-            Instructions:
-            1. Compare the original and repaired scripts to identify what was fixed
-            2. Determine confidence level (0-5) where:
-               - 0 = Low confidence, repairs may be unreliable
-               - 5 = High confidence, repairs are solid and maintainable
-            3. Write SHORT advice (few short sentences max) that:
-               - States what specific fix was made
-               - Builds on any previous repair advice found in the original script
-               - Captures patterns (e.g., "usually fails on selector issues", "often needs deflaking")
-               - Will help future repairs understand this test's quirks
-
-            IMPORTANT:
-            - Step comments are EXPECTED and GOOD - do not mention them as issues
-            - Be concise and factual
-            - Focus on the actual fix made, not general recommendations
-            - Build a running understanding of this test's behavior relating to the repairs done
-            - If the original script contains previous repair advice, build upon it to create a cumulative understanding
-
-            Respond with JSON:
-            {
-              "confidence": 0-5,
-              "advice": "short factual statement about the fix and test patterns"
-            }`
-  },
-
-  // Final script generation
-  FINAL_SCRIPT: {
-    SYSTEM: 'You are an expert at creating drop-in replacement scripts. Generate a complete, properly formatted script that preserves the original structure while incorporating repairs and new advice.',
-    
-    USER: (originalScript: string, updatedScript: string, newRepairAdvice: string) => `You are an expert at generating drop-in replacement scripts. Create a final script that can be pasted directly into the original file.
-
-            Original Script (with existing repair advice):
-            ${originalScript}
-
-            Updated Script (with repairs):
-            ${updatedScript}
-
-            New Repair Advice:
-            ${newRepairAdvice}
-
-            Instructions:
-            1. Create a drop-in replacement that preserves the original test name and structure
-            2. Update the TestChimp comment block at the top to include BOTH existing and new repair advice
-            3. If there was existing repair advice, combine it with the new advice to build a running understanding
-            4. Use the repaired code from the updated script
-            5. Preserve the original test name (don't use 'repairedTest')
-            6. Keep the same import statements and overall structure
-            7. Ensure the script is properly formatted and ready to use
-            8. The repair advice should accumulate knowledge about this test's behavior patterns
-
-            Return JSON object with the final script:
-            {
-              "script": "complete final script that can be pasted into the original file"
-            }`
-  },
-
-  // Script cleanup (minor adjustments only)
-  SCRIPT_CLEANUP: {
-    SYSTEM: 'You are a Playwright test script reviewer. Your job is to do MINOR cleanup only - remove obvious redundancies, but preserve the core structure and logic.',
-    
-    USER: (script: string) => `Review this generated Playwright test script and make MINOR adjustments only.
-
-SCRIPT:
-${script}
-
-YOUR TASK (MINOR ADJUSTMENTS ONLY):
-1. Remove duplicate/redundant expect() assertions (e.g., same assertion repeated twice)
-2. Fix obvious formatting issues (inconsistent spacing, etc.)
-3. Consolidate multiple identical assertions into one
-4. Remove any obviously redundant waits or checks
-
-DO NOT:
-- Remove the TestChimp header comment (/* This is a TestChimp Smart Test... */) - this must be preserved
-- Remove step comments (e.g., "// Step 1: ..." or "// Navigate to...") - these are important for readability
-- Change the test logic or flow
-- Remove legitimate assertions
-- Restructure the code
-- Change selectors
-- Add new functionality
-- Remove important waits
-
-EXAMPLES:
-
-❌ REMOVE redundancy:
-await expect(page.getByText('Hello')).toBeVisible();
-await expect(page.getByText('Hello')).toBeVisible();  // duplicate
-
-✅ KEEP legitimate checks:
-await expect(page.getByPlaceholder('Message...')).toBeEmpty();
-await page.getByPlaceholder('Message...').fill('Hello');
-await expect(page.getByPlaceholder('Message...')).toHaveValue('Hello');  // different checks
-
-Return JSON:
-{
-  "script": "cleaned script (or original if no changes needed)",
-  "changes": ["list of minor changes made, or empty array if none"],
-  "skipped": "reason if you chose not to make changes"
-}`
-  }
-};