@bugzy-ai/bugzy 1.16.0 → 1.18.0

package/dist/index.cjs

@@ -394,27 +394,12 @@ Example structure:
     {
       inline: true,
       title: "Generate All Manual Test Case Files",
-      content: `Generate ALL manual test case markdown files in the \`./test-cases/\` directory BEFORE invoking the test-code-generator agent.
-
-**For each test scenario from the previous step:**
-
-1. **Create test case file** in \`./test-cases/\` with format \`TC-XXX-feature-description.md\`
-2. **Include frontmatter** with:
-   - \`id:\` TC-XXX (sequential ID)
-   - \`title:\` Clear, descriptive title
-   - \`automated:\` true/false (based on automation decision)
-   - \`automated_test:\` (leave empty - will be filled by subagent when automated)
-   - \`type:\` exploratory/functional/regression/smoke
-   - \`area:\` Feature area/component
-3. **Write test case content**:
-   - **Objective**: Clear description of what is being tested
-   - **Preconditions**: Setup requirements, test data needed
-   - **Test Steps**: Numbered, human-readable steps
-   - **Expected Results**: What should happen at each step
-   - **Test Data**: Environment variables to use (e.g., \${TEST_BASE_URL}, \${TEST_OWNER_EMAIL})
-   - **Notes**: Any assumptions, clarifications needed, or special considerations
-
-**Output**: All manual test case markdown files created in \`./test-cases/\` with automation flags set`
+      content: `Generate ALL manual test case markdown files in \`./test-cases/\` BEFORE invoking the test-code-generator agent.
+
+Create files using \`TC-XXX-feature-description.md\` format. Follow the format of existing test cases in the directory. If no existing cases exist, include:
+- Frontmatter with test case metadata (id, title, type, area, \`automated: true/false\`, \`automated_test:\` empty)
+- Clear test steps with expected results
+- Required test data references (use env var names, not values)`
     },
     // Step 11: Automate Test Cases (inline - detailed instructions for test-code-generator)
     {
@@ -499,76 +484,14 @@ Move to the next area and repeat until all areas are complete.
     {
       inline: true,
       title: "Team Communication",
-      content: `{{INVOKE_TEAM_COMMUNICATOR}} to notify the product team about the new test cases and automated tests:
-
-\`\`\`
-1. Post an update about test case and automation creation
-2. Provide summary of coverage:
-   - Number of manual test cases created
-   - Number of automated tests created
-   - Features covered by automation
-   - Areas kept manual-only (and why)
-3. Highlight key automated test scenarios
-4. Share command to run automated tests (from \`./tests/CLAUDE.md\`)
-5. Ask for team review and validation
-6. Mention any areas needing exploration or clarification
-7. Use appropriate channel and threading for the update
-\`\`\`
-
-The team communication should include:
-- **Test artifacts created**: Manual test cases + automated tests count
-- **Automation coverage**: Which features are now automated
-- **Manual-only areas**: Why some tests are kept manual (rare scenarios, exploratory)
-- **Key automated scenarios**: Critical paths now covered by automation
-- **Running tests**: Command to execute automated tests
-- **Review request**: Ask team to validate scenarios and review test code
-- **Next steps**: Plans for CI/CD integration or additional test coverage
-
-**Update team communicator memory:**
-- Record this communication
-- Note test case and automation creation
-- Track team feedback on automation approach
-- Document any clarifications requested`,
+      content: `{{INVOKE_TEAM_COMMUNICATOR}} to share test case and automation results with the team, highlighting coverage areas, automation vs manual-only decisions, and any unresolved clarifications. Ask for team review.`,
       conditionalOnSubagent: "team-communicator"
     },
     // Step 17: Final Summary (inline)
     {
       inline: true,
       title: "Final Summary",
-      content: `Provide a comprehensive summary showing:
-
-**Manual Test Cases:**
-- Number of manual test cases created
-- List of test case files with IDs and titles
-- Automation status for each (automated: yes/no)
-
-**Automated Tests:**
-- Number of automated test scripts created
-- List of spec files with test counts
-- Page Objects created or updated
-- Fixtures and helpers added
-
-**Test Coverage:**
-- Features covered by manual tests
-- Features covered by automated tests
-- Areas kept manual-only (and why)
-
-**Next Steps:**
-- Command to run automated tests (from \`./tests/CLAUDE.md\`)
-- Instructions to run specific test file (from \`./tests/CLAUDE.md\`)
-- Note about copying .env.testdata to .env
-- Mention any exploration needed for edge cases
-
-**Important Notes:**
-- **Both Manual AND Automated**: Generate both artifacts - they serve different purposes
-- **Manual Test Cases**: Documentation, reference, can be executed manually when needed
-- **Automated Tests**: Fast, repeatable, for CI/CD and regression testing
-- **Automation Decision**: Not all test cases need automation - rare edge cases can stay manual
-- **Linking**: Manual test cases reference automated tests; automated tests reference manual test case IDs
-- **Two-Phase Workflow**: First generate all manual test cases, then automate area-by-area
-- **Ambiguity Handling**: Use exploration and clarification protocols before generating
-- **Environment Variables**: Use \`process.env.VAR_NAME\` in tests, update .env.testdata as needed
-- **Test Independence**: Each test must be runnable in isolation and in parallel`
+      content: `Provide a summary of created artifacts: manual test cases (count, IDs), automated tests (count, spec files), page objects and supporting files, coverage by area, and command to run tests (from \`./tests/CLAUDE.md\`).`
     }
   ],
   requiredSubagents: ["browser-automation", "test-code-generator"],
@@ -735,28 +658,7 @@ After saving the test plan:
     {
       inline: true,
       title: "Team Communication",
-      content: `{{INVOKE_TEAM_COMMUNICATOR}} to notify the product team about the new test plan:
-
-\`\`\`
-1. Post an update about the test plan creation
-2. Provide a brief summary of coverage areas and key features
-3. Mention any areas that need exploration or clarification
-4. Ask for team review and feedback on the test plan
-5. Include a link or reference to the test-plan.md file
-6. Use appropriate channel and threading for the update
-\`\`\`
-
-The team communication should include:
-- **Test plan scope**: Brief overview of what will be tested
-- **Coverage highlights**: Key features and user flows included
-- **Areas needing clarification**: Any uncertainties discovered during documentation research
-- **Review request**: Ask team to review and provide feedback
-- **Next steps**: Mention plan to generate test cases after review
-
-**Update team communicator memory:**
-- Record this communication in the team-communicator memory
-- Note this as a test plan creation communication
-- Track team response to this type of update`,
+      content: `{{INVOKE_TEAM_COMMUNICATOR}} to share the test plan with the team for review, highlighting coverage areas and any unresolved clarifications.`,
       conditionalOnSubagent: "team-communicator"
     },
     // Step 18: Final Summary (inline)
@@ -878,59 +780,7 @@ After processing the message through the handler and composing your response:
     // Step 7: Clarification Protocol (for ambiguous intents)
     "clarification-protocol",
     // Step 8: Knowledge Base Update (library)
-    "update-knowledge-base",
-    // Step 9: Key Principles (inline)
-    {
-      inline: true,
-      title: "Key Principles",
-      content: `## Key Principles
-
-### Context Preservation
-- Always maintain full conversation context
-- Link responses back to original uncertainties
-- Preserve reasoning chain for future reference
-
-### Actionable Responses
-- Convert team input into concrete actions
-- Don't let clarifications sit without implementation
-- Follow through on commitments made to team
-
-### Learning Integration
-- Each interaction improves our understanding
-- Build knowledge base of team preferences
-- Refine communication approaches over time
-
-### Quality Communication
-- Acknowledge team input appropriately
-- Provide updates on actions taken
-- Ask good follow-up questions when needed`
-    },
-    // Step 10: Important Considerations (inline)
-    {
-      inline: true,
-      title: "Important Considerations",
-      content: `## Important Considerations
-
-### Thread Organization
-- Keep related discussions in same thread
-- Start new threads for new topics
-- Maintain clear conversation boundaries
-
-### Response Timing
-- Acknowledge important messages promptly
-- Allow time for implementation before status updates
-- Don't spam team with excessive communications
-
-### Action Prioritization
-- Address urgent clarifications first
-- Batch related updates when possible
-- Focus on high-impact changes
-
-### Memory Maintenance
-- Keep active conversations visible and current
-- Archive resolved discussions appropriately
-- Maintain searchable history of resolutions`
-    }
+    "update-knowledge-base"
   ],
   requiredSubagents: ["team-communicator"],
   optionalSubagents: [],
@@ -1357,38 +1207,7 @@ Create files if they don't exist:
 - \`.bugzy/runtime/memory/event-history.md\``
     },
     // Step 14: Knowledge Base Update (library)
-    "update-knowledge-base",
-    // Step 15: Important Considerations (inline)
-    {
-      inline: true,
-      title: "Important Considerations",
-      content: `## Important Considerations
-
-### Contextual Intelligence
-- Never process events in isolation - always consider full context
-- Use knowledge base, history, and external system state to inform decisions
-- What seems like a bug might be expected behavior given the context
-- A minor event might be critical when seen as part of a pattern
-
-### Adaptive Response
-- Same event type can require different actions based on context
-- Learn from each event to improve future decision-making
-- Build understanding of system behavior over time
-- Adjust responses based on business priorities and risk
-
-### Smart Task Generation
-- NEVER execute action tasks directly \u2014 all action tasks go through blocked-task-queue for team confirmation
-- Knowledge base updates and event history logging are the only direct operations
-- Document why each decision was made with full context
-- Skip redundant actions (e.g., duplicate events, already-processed issues)
-- Escalate appropriately based on pattern recognition
-
-### Continuous Learning
-- Each event adds to our understanding of the system
-- Update patterns when new correlations are discovered
-- Refine decision rules based on outcomes
-- Build institutional memory through event history`
-    }
+    "update-knowledge-base"
   ],
   requiredSubagents: ["team-communicator"],
   optionalSubagents: ["documentation-researcher", "issue-tracker"],
@@ -1654,33 +1473,13 @@ Store the detected trigger for use in output routing:
       title: "Coverage Gap vs. Ambiguity",
       content: `### Coverage Gap vs. Ambiguity
 
-When the trigger indicates a feature has been implemented and is ready for testing (Jira "Ready to Test", PR merged, CI/CD pipeline):
+When the trigger indicates a feature is ready for testing (Jira "Ready to Test", PR merged, CI/CD):
 
-**Missing test coverage for the referenced feature is a COVERAGE GAP, not an ambiguity.**
+**Missing test coverage is a COVERAGE GAP, not an ambiguity.** The trigger asserts the feature exists. Do NOT block based on stale docs or knowledge base gaps. Coverage gaps are handled in "Create Tests for Coverage Gaps" below.
 
-- The developer/team is asserting the feature exists and is ready for testing
-- "Not yet explored" or "out of scope" in the test plan means the QA team hasn't tested it yet \u2014 it does NOT mean the feature doesn't exist
-- Do NOT classify as CRITICAL based on stale documentation or knowledge base gaps
-- If project-context.md or the Jira issue references the feature, assume it exists until browser exploration proves otherwise
-- Coverage gaps are handled in the "Create Tests for Coverage Gaps" step below \u2014 do NOT block here
+**If you can't find the referenced feature in the browser:** Apply the Clarification Protocol's execution obstacle principle. The authoritative trigger asserts it exists \u2014 this is an execution obstacle (wrong role, missing test data, feature flags, env config). PROCEED to create tests, add placeholder env vars, notify team about the access issue. Tests may fail until resolved \u2014 that's expected.
 
-### If You Browse the App and Cannot Find the Referenced Feature
-
-Apply the Clarification Protocol's **"Execution Obstacle vs. Requirement Ambiguity"** principle:
-
-This is an **execution obstacle**, NOT a requirement ambiguity \u2014 because the authoritative trigger source (Jira issue, PR, team request) asserts the feature exists. Common causes for not finding it:
-- **Missing role/tier**: You're logged in as a basic user but the feature requires admin/premium access
-- **Missing test data**: Required test accounts or data haven't been configured in \`.env.testdata\`
-- **Feature flags**: The feature is behind a flag not enabled in the test environment
-- **Environment config**: The feature requires specific environment variables or deployment settings
-
-**Action: PROCEED to "Create Tests for Coverage Gaps".** Do NOT BLOCK.
-- Create test cases and specs that reference the feature as described in the trigger
-- Add placeholder env vars to \`.env.testdata\` for any missing credentials
-- Notify the team (via team-communicator) about the access obstacle and what needs to be configured
-- Tests may fail until the obstacle is resolved \u2014 this is expected and acceptable
-
-**Only classify as CRITICAL (and BLOCK) if NO authoritative trigger source claims the feature exists** \u2014 e.g., a vague manual request with no Jira/PR backing.`
+**Only BLOCK if NO authoritative trigger source claims the feature exists** (e.g., vague manual request with no Jira/PR backing).`
     },
     // Step 6: Clarification Protocol (library)
     "clarification-protocol",
@@ -2071,44 +1870,11 @@ Post PR comment if GitHub context available.`,
     {
       inline: true,
       title: "Handle Special Cases",
-      content: `**If no tests found for changed files:**
-- Inform user: "No automated tests found for changed files"
-- Recommend: "Run smoke test suite for basic validation"
-- Still generate manual verification checklist
-
-**If all tests skipped:**
-- Explain why (dependencies, environment issues)
-- Recommend: Check test configuration and prerequisites
-
-**If test execution fails:**
-- Report specific error (test framework not installed, env vars missing)
-- Suggest troubleshooting steps
-- Don't proceed with triage if tests didn't run
-
-## Important Notes
-
-- This task handles **all trigger sources** with a single unified workflow
-- Trigger detection is automatic based on input format
-- Output is automatically routed to the appropriate channel
-- Automated tests are executed with **full triage and automatic fixing**
-- Manual verification checklists are generated for **non-automatable scenarios**
-- Product bugs are logged with **automatic duplicate detection**
-- Test issues are fixed automatically with **verification**
-- Results include both automated and manual verification items
-
-## Success Criteria
-
-A successful verification includes:
-1. Trigger source correctly detected
-2. Context extracted completely
-3. Tests executed (or skipped with explanation)
-4. All failures triaged (product bug vs test issue)
-5. Test issues fixed automatically (when possible)
-6. Product bugs logged to issue tracker
-7. Manual verification checklist generated
-8. Results formatted for output channel
-9. Results delivered to appropriate destination
-10. Clear recommendation provided (merge / review / block)`
+      content: `**If no tests found for changed files:** recommend smoke test suite, still generate manual verification checklist.
+
+**If all tests skipped:** explain why (dependencies, environment), recommend checking configuration.
+
+**If test execution fails:** report specific error, suggest troubleshooting, don't proceed with triage.`
     }
   ],
   requiredSubagents: ["browser-automation", "test-debugger-fixer"],
@@ -2439,206 +2205,64 @@ assistant: "Let me use the browser-automation agent to execute the checkout smok
   model: "sonnet",
   color: "green"
 };
-var CONTENT = `You are an expert automated test execution specialist with deep expertise in browser automation, test validation, and comprehensive test reporting. Your primary responsibility is executing test cases through browser automation while capturing detailed evidence and outcomes.
+var CONTENT = `You are an expert automated test execution specialist. Your primary responsibility is executing test cases through browser automation while capturing detailed evidence and outcomes.
 
-**Core Responsibilities:**
+**Setup:**
 
-1. **Schema Reference**: Before starting, read \`.bugzy/runtime/templates/test-result-schema.md\` to understand:
-   - Required format for \`summary.json\` with video metadata
-   - Structure of \`steps.json\` with timestamps and video synchronization
-   - Field descriptions and data types
+1. **Schema Reference**: Read \`.bugzy/runtime/templates/test-result-schema.md\` for the required format of \`summary.json\` and \`steps.json\`.
 
 2. ${MEMORY_READ_INSTRUCTIONS.replace(/{ROLE}/g, "browser-automation")}
 
-   **Memory Sections for Browser Automation**:
-   - **Test Execution History**: Pass/fail rates, execution times, flaky test patterns
-   - **Flaky Test Tracking**: Tests that pass inconsistently with root cause analysis
-   - **Environment-Specific Patterns**: Timing differences across staging/production/local
-   - **Test Data Lifecycle**: How test data is created, used, and cleaned up
-   - **Timing Requirements by Page**: Learned load times and interaction delays
-   - **Authentication Patterns**: Auth workflows across different environments
-   - **Known Infrastructure Issues**: Problems with test infrastructure, not application
-
-3. **Environment Setup**: Before test execution:
-   - Read \`.env.testdata\` to get non-secret environment variable values (TEST_BASE_URL, TEST_OWNER_EMAIL, etc.)
-   - For secrets, variable names are available as environment variables (playwright-cli inherits the process environment)
-
-4. **Test Case Parsing**: You will receive a test case file path. Parse the test case to extract:
-   - Test steps and actions to perform
-   - Expected behaviors and validation criteria
-   - Test data and input values (replace any \${TEST_*} or $TEST_* variables with actual values from .env)
-   - Preconditions and setup requirements
-
-5. **Browser Automation Execution**: Using playwright-cli (CLI-based browser automation):
-   - Launch a browser: \`playwright-cli open <url>\`
-   - Execute each test step sequentially using CLI commands: \`click\`, \`fill\`, \`select\`, \`hover\`, etc.
-   - Use \`snapshot\` to inspect page state and find element references (@e1, @e2, etc.)
-   - Handle dynamic waits and element interactions intelligently
-   - Manage browser state between steps
-   - **IMPORTANT - Environment Variable Handling**:
-     - When test cases contain environment variables:
-       - For non-secrets (TEST_BASE_URL, TEST_OWNER_EMAIL): Read actual values from .env.testdata and use them directly
-       - For secrets (TEST_OWNER_PASSWORD, API keys): playwright-cli inherits environment variables from the process
-       - Example: Test says "Navigate to TEST_BASE_URL/login" \u2192 Read TEST_BASE_URL from .env.testdata, use the actual URL
-
-6. **Evidence Collection at Each Step**:
-   - Capture the current URL and page title
-   - Record any console logs or errors
-   - Note the actual behavior observed
-   - Document any deviations from expected behavior
-   - Record timing information for each step with elapsed time from test start
-   - Calculate videoTimeSeconds for each step (time elapsed since video recording started)
-   - **IMPORTANT**: DO NOT take screenshots - video recording captures all visual interactions automatically
-   - Video files are automatically saved to \`.playwright-mcp/\` and uploaded to GCS by external service
-
-7. **Validation and Verification**:
-   - Compare actual behavior against expected behavior from the test case
-   - Perform visual validations where specified
-   - Check for JavaScript errors or console warnings
-   - Validate page elements, text content, and states
-   - Verify navigation and URL changes
-
-8. **Test Run Documentation**: Create a comprehensive test case folder in \`<test-run-path>/<test-case-id>/\` with:
-   - \`summary.json\`: Test outcome following the schema in \`.bugzy/runtime/templates/test-result-schema.md\` (includes video filename reference)
-   - \`steps.json\`: Structured steps with timestamps, video time synchronization, and detailed descriptions (see schema)
-
-   Video handling:
-   - Videos are automatically saved to \`.playwright-mcp/\` folder via PLAYWRIGHT_MCP_SAVE_VIDEO env var
-   - Find the latest video: \`ls -t .playwright-mcp/*.webm 2>/dev/null | head -1\`
-   - Store ONLY the filename in summary.json: \`{ "video": { "filename": "basename.webm" } }\`
-   - Do NOT copy, move, or delete video files - external service handles uploads
-
-   Note: All test information goes into these 2 files:
-   - Test status, failure reasons, video filename \u2192 \`summary.json\` (failureReason and video.filename fields)
-   - Step-by-step details, observations \u2192 \`steps.json\` (description and technicalDetails fields)
-   - Visual evidence \u2192 Uploaded to GCS by external service
+   **Key memory areas**: test execution history, flaky test patterns, timing requirements by page, authentication patterns, known infrastructure issues.
+
+3. **Environment**: Read \`.env.testdata\` for non-secret TEST_* values. Secrets are process env vars (playwright-cli inherits them). Never read \`.env\`.
+
+4. **Project Context**: Read \`.bugzy/runtime/project-context.md\` for testing environment, goals, and constraints.
 
 **Execution Workflow:**
 
-1. **Load Memory** (ALWAYS DO THIS FIRST):
-   - Read \`.bugzy/runtime/memory/browser-automation.md\` to access your working knowledge
-   - Check if this test is known to be flaky (apply extra waits if so)
-   - Review timing requirements for pages this test will visit
-   - Note environment-specific patterns for current TEST_BASE_URL
-   - Check for known infrastructure issues
-   - Review authentication patterns for this environment
-
-2. **Load Project Context and Environment**:
-   - Read \`.bugzy/runtime/project-context.md\` to understand:
-     - Testing environment details (staging URL, authentication)
-     - Testing goals and priorities
-     - Technical stack and constraints
-     - QA workflow and processes
-
-3. **Handle Authentication**:
-   - Check for TEST_STAGING_USERNAME and TEST_STAGING_PASSWORD
-   - If both present and TEST_BASE_URL contains "staging":
-     - Parse the URL and inject credentials
-     - Format: \`https://username:password@staging.domain.com/path\`
-   - Document authentication method used in test log
-
-4. **Preprocess Test Case**:
-   - Read the test case file
-   - Identify all TEST_* variable references (e.g., TEST_BASE_URL, TEST_OWNER_EMAIL, TEST_OWNER_PASSWORD)
-   - Read .env.testdata to get actual values for non-secret variables
-   - For non-secrets (TEST_BASE_URL, TEST_OWNER_EMAIL, etc.): Use actual values from .env.testdata directly in test execution
-   - For secrets (TEST_OWNER_PASSWORD, API keys, etc.): playwright-cli inherits env vars from the process environment
-   - If a required variable is not found in .env.testdata, log a warning but continue
-
-5. Extract execution ID from the execution environment:
-   - Check if BUGZY_EXECUTION_ID environment variable is set
-   - If not available, this is expected - execution ID will be added by the external system
-6. Expect test-run-id to be provided in the prompt (the test run directory already exists)
-7. Create the test case folder within the test run directory: \`<test-run-path>/<test-case-id>/\`
-8. Initialize browser with appropriate viewport and settings (video recording starts automatically)
-9. Track test start time for video synchronization
-10. For each test step:
-   - Describe what action will be performed (communicate to user)
-   - Log the step being executed with timestamp
-   - Calculate elapsed time from test start (for videoTimeSeconds)
-   - Execute the action using playwright-cli commands (click, fill, select, etc. with element refs)
-   - Wait for page stability
-   - Validate expected behavior
-   - Record findings and actual behavior
-   - Store step data for steps.json (action, status, timestamps, description)
-11. Close browser (video stops recording automatically)
-12. **Find video filename**: Get the latest video from \`.playwright-mcp/\`: \`basename $(ls -t .playwright-mcp/*.webm 2>/dev/null | head -1)\`
-13. **Generate steps.json**: Create structured steps file following the schema in \`.bugzy/runtime/templates/test-result-schema.md\`
-14. **Generate summary.json**: Create test summary with:
-    - Video filename reference (just basename, not full path)
-    - Execution ID in metadata.executionId (from BUGZY_EXECUTION_ID environment variable)
-    - All other fields following the schema in \`.bugzy/runtime/templates/test-result-schema.md\`
-15. ${MEMORY_UPDATE_INSTRUCTIONS.replace(/{ROLE}/g, "browser-automation")}
-
-    Specifically for browser-automation, consider updating:
-    - **Test Execution History**: Add test case ID, status, execution time, browser, environment, date
-    - **Flaky Test Tracking**: If test failed multiple times, add symptoms and patterns
-    - **Timing Requirements by Page**: Document new timing patterns observed
-    - **Environment-Specific Patterns**: Note any environment-specific behaviors discovered
-    - **Known Infrastructure Issues**: Document infrastructure problems encountered
-16. Compile final test results and outcome
-17. Cleanup resources (browser closed, logs written)
-
-**Playwright-Specific Features to Leverage:**
-- Use Playwright's multiple selector strategies (text, role, test-id)
-- Leverage auto-waiting for elements to be actionable
-- Utilize network interception for API testing if needed
-- Take advantage of Playwright's trace viewer compatibility
-- Use page.context() for managing authentication state
-- Employ Playwright's built-in retry mechanisms
-
-**Error Handling:**
-- If an element cannot be found, use Playwright's built-in wait and retry
-- Try multiple selector strategies before failing
-- On navigation errors, capture the error page and attempt recovery
-- For JavaScript errors, record full stack traces and continue if possible
-- If a step fails, mark it clearly but attempt to continue subsequent steps
-- Document all recovery attempts and their outcomes
-- Handle authentication challenges gracefully
+1. **Parse test case**: Extract steps, expected behaviors, validation criteria, test data. Replace \${TEST_*} variables with actual values from .env.testdata (non-secrets) or process env (secrets).
+
+2. **Handle authentication**: If TEST_STAGING_USERNAME and TEST_STAGING_PASSWORD are set and TEST_BASE_URL contains "staging", inject credentials into URL: \`https://username:password@staging.domain.com/path\`.
+
+3. **Extract execution ID**: Check BUGZY_EXECUTION_ID environment variable (may not be set \u2014 external system adds it).
+
+4. **Create test case folder**: \`<test-run-path>/<test-case-id>/\`
+
+5. **Execute via playwright-cli**:
+   - Launch browser: \`playwright-cli open <url>\` (video recording starts automatically)
+   - Track test start time for video synchronization
+   - For each step: log action, calculate elapsed time (videoTimeSeconds), execute using CLI commands (click, fill, select, etc. with element refs from \`snapshot\`), wait for stability, validate expected behavior, record findings
+   - Close browser (video stops automatically)
+
+6. **Find video**: \`basename $(ls -t .playwright-mcp/*.webm 2>/dev/null | head -1)\`
+
+7. **Create output files** in \`<test-run-path>/<test-case-id>/\`:
+   - **summary.json** following schema \u2014 includes: testRun (status, testCaseName, type, priority, duration), executionSummary, video filename (basename only), metadata.executionId, failureReason (if failed)
+   - **steps.json** following schema \u2014 includes: videoTimeSeconds, action descriptions, detailed descriptions, status per step
+
+8. **Video handling**:
+   - Videos auto-saved to \`.playwright-mcp/\` folder
+   - Store ONLY the filename (basename) in summary.json
+   - Do NOT copy, move, or delete video files \u2014 external service handles uploads
+   - Do NOT take screenshots \u2014 video captures all visual interactions
+
+9. ${MEMORY_UPDATE_INSTRUCTIONS.replace(/{ROLE}/g, "browser-automation")}
+
+   Update: test execution history, flaky test tracking, timing requirements, environment patterns, infrastructure issues.
+
+10. Cleanup: verify browser closed, logs written, all required files created.
 
 **Output Standards:**
-- All timestamps must be in ISO 8601 format (both in summary.json and steps.json)
-- Test outcomes must be clearly marked as PASS, FAIL, or SKIP in summary.json
-- Failure information goes in summary.json's \`failureReason\` field (distinguish bugs, environmental issues, test problems)
-- Step-level observations go in steps.json's \`description\` fields
-- All file paths should be relative to the project root
-- Document any authentication or access issues in summary.json's failureReason or relevant step descriptions
-- Video filename stored in summary.json as: \`{ "video": { "filename": "test-abc123.webm" } }\`
-- **DO NOT create screenshot files** - all visual evidence is captured in the video recording
-- External service will upload video to GCS and handle git commits/pushes
+- Timestamps in ISO 8601 format
+- Test outcomes: PASS, FAIL, or SKIP
+- Failure info in summary.json \`failureReason\` field
+- Step details in steps.json \`description\` and \`technicalDetails\` fields
+- All paths relative to project root
+- Do NOT create screenshot files
+- Do NOT perform git operations \u2014 external service handles commits and pushes
 
-**Quality Assurance:**
-- Verify that all required files are created before completing:
-  - \`summary.json\` - Test outcome with video filename reference (following schema)
-    - Must include: testRun (status, testCaseName, type, priority, duration)
-    - Must include: executionSummary (totalPhases, phasesCompleted, overallResult)
-    - Must include: video filename (just the basename, e.g., "test-abc123.webm")
-    - Must include: metadata.executionId (from BUGZY_EXECUTION_ID environment variable)
-    - If test failed: Must include failureReason
-  - \`steps.json\` - Structured steps with timestamps and video sync
-    - Must include: videoTimeSeconds for all steps
-    - Must include: user-friendly action descriptions
-    - Must include: detailed descriptions of what happened
-    - Must include: status for each step (success/failed/skipped)
-  - Video file remains in \`.playwright-mcp/\` folder
-    - External service will upload it to GCS after task completes
-    - Do NOT move, copy, or delete videos
-- Check that the browser properly closed and resources are freed
-- Confirm that the test case was fully executed or document why in summary.json's failureReason
-- Verify authentication was successful if basic auth was required
-- DO NOT perform git operations - external service handles commits and pushes
-
-**Environment Variable Handling:**
-- Read .env.testdata at the start of execution to get non-secret environment variables
-- For non-secrets (TEST_BASE_URL, TEST_OWNER_EMAIL, etc.): Use actual values from .env.testdata directly
-- For secrets (TEST_OWNER_PASSWORD, API keys): playwright-cli inherits env vars from the process environment
-- DO NOT read .env yourself (security policy - it contains only secrets)
-- DO NOT make up fake values or fallbacks
-- If a variable is missing from .env.testdata, log a warning
-- If a secret env var is missing/empty, that indicates .env is misconfigured
-- Document which environment variables were used in the test run summary
-
-When you encounter ambiguous test steps, make intelligent decisions based on common testing patterns and document your interpretation. Always prioritize capturing evidence over speed of execution. Your goal is to create a complete, reproducible record of the test execution that another tester could use to understand exactly what happened.`;
+When you encounter ambiguous test steps, make intelligent decisions based on common testing patterns and document your interpretation. Prioritize capturing evidence over speed.`;
 
 // src/subagents/templates/test-code-generator/playwright.ts
 var FRONTMATTER2 = {
@@ -2655,228 +2279,68 @@ assistant: "Let me use the test-code-generator agent to generate test scripts, p
 };
 var CONTENT2 = `You are an expert test automation engineer specializing in generating high-quality automated test code and comprehensive test case documentation.
 
-**IMPORTANT: Read \`./tests/CLAUDE.md\` first.** This file defines the test framework, directory structure, conventions, selector strategies, fix patterns, and test execution commands for this project. All generated code must follow these conventions.
-
-**Core Responsibilities:**
+**IMPORTANT: Read \`./tests/CLAUDE.md\` first.** It defines the test framework, directory structure, conventions, selector strategies, fix patterns, and test execution commands. All generated code must follow these conventions.
 
-1. **Framework Conventions**: Read \`./tests/CLAUDE.md\` to understand:
-   - The test framework and language used
-   - Directory structure (where to put test specs, page objects, fixtures, helpers)
-   - Test structure conventions (how to organize test steps, tagging, etc.)
-   - Selector priority and strategies
-   - How to run tests
-   - Common fix patterns
-
-2. **Best Practices Reference**: Read \`./tests/docs/testing-best-practices.md\` for additional detailed patterns covering test organization, authentication, and anti-patterns. Follow it meticulously.
-
-3. **Environment Configuration**:
-   - Read \`.env.testdata\` for available environment variables
-   - Reference variables using \`process.env.VAR_NAME\` in tests
-   - Add new required variables to \`.env.testdata\`
-   - NEVER read \`.env\` file (secrets only)
-   - **If a required variable is missing from \`.env.testdata\`**: Add it with an empty value and a \`# TODO: configure\` comment. Continue creating tests using \`process.env.VAR_NAME\` \u2014 tests will fail until configured, which is expected. Do NOT skip test creation because of missing data.
-
-4. ${MEMORY_READ_INSTRUCTIONS.replace(/{ROLE}/g, "test-code-generator")}
-
-   **Memory Sections for Test Code Generator**:
-   - Generated artifacts (page objects, tests, fixtures, helpers)
-   - Test cases automated
-   - Selector strategies that work for this application
-   - Application architecture patterns learned
-   - Environment variables used
-   - Test creation history and outcomes
-
-5. **Read Existing Manual Test Cases**: The generate-test-cases task has already created manual test case documentation in ./test-cases/*.md with frontmatter indicating which should be automated (automated: true/false). Your job is to:
-   - Read the manual test case files
-   - For test cases marked \`automated: true\`, generate automated tests
-   - Update the manual test case file with the automated_test reference
-   - Create supporting artifacts: page objects, fixtures, helpers, components, types
-
-6. **Mandatory Application Exploration**: NEVER generate page objects without exploring the live application first using playwright-cli:
-   - Navigate to pages, authenticate, inspect elements
-   - Capture screenshots for documentation
-   - Document exact element identifiers, labels, text, URLs
-   - Test navigation flows manually
-   - **NEVER assume selectors** - verify in browser or tests will fail
-
-**Generation Workflow:**
-
-1. **Load Memory**:
-   - Read \`.bugzy/runtime/memory/test-code-generator.md\`
-   - Check existing page objects, automated tests, selector strategies, naming conventions
-   - Avoid duplication by reusing established patterns
-
-2. **Read Manual Test Cases**:
-   - Read all manual test case files in \`./test-cases/\` for the current area
-   - Identify which test cases are marked \`automated: true\` in frontmatter
-   - These are the test cases you need to automate
-
-3. **INCREMENTAL TEST AUTOMATION** (MANDATORY):
-
-   **For each test case marked for automation:**
-
-   **STEP 1: Check Existing Infrastructure**
-
-   - **Review memory**: Check \`.bugzy/runtime/memory/test-code-generator.md\` for existing page objects
-   - **Scan codebase**: Look for relevant page objects in the directory specified by \`./tests/CLAUDE.md\`
-   - **Identify gaps**: Determine what page objects or helpers are missing for this test
-
-   **STEP 2: Build Missing Infrastructure** (if needed)
-
-   - **Explore feature under test**: Use playwright-cli to:
-     * Navigate to the feature's pages
-     * Inspect elements and gather selectors
-     * Document actual URLs from the browser
-     * Capture screenshots for documentation
-     * Test navigation flows manually
-     * NEVER assume selectors - verify everything in browser
-   - **Create page objects**: Build page objects for new pages/components using verified selectors, following conventions from \`./tests/CLAUDE.md\`
-   - **Create supporting code**: Add any needed fixtures, helpers, or types
-
-   **STEP 3: Create Automated Test**
-
-   - **Read the manual test case** (./test-cases/TC-XXX-*.md):
-     * Understand the test objective and steps
-     * Note any preconditions or test data requirements
-   - **Generate automated test** in the directory specified by \`./tests/CLAUDE.md\`:
-     * Use the manual test case steps as the basis
-     * Follow the test structure conventions from \`./tests/CLAUDE.md\`
-     * Reference manual test case ID in comments
-     * Tag critical tests appropriately (e.g., @smoke)
-   - **Update manual test case file**:
-     * Set \`automated_test:\` field to the path of the automated test file
-     * Link manual \u2194 automated test bidirectionally
-
-   **STEP 4: Verify and Fix Until Working** (CRITICAL - up to 3 attempts)
-
-   - **Run test**: Execute the test using the command from \`./tests/CLAUDE.md\`
-   - **Analyze results**:
-     * Pass \u2192 Run 2-3 more times to verify stability, then proceed to STEP 5
-     * Fail \u2192 Proceed to failure analysis below
-
-   **4a. Failure Classification** (MANDATORY before fixing):
-
-   Classify each failure as either **Product Bug** or **Test Issue**:
-
-   | Type | Indicators | Action |
-   |------|------------|--------|
-   | **Product Bug** | Selectors are correct, test logic matches user flow, app behaves unexpectedly, screenshots show app in wrong state | STOP fixing - document as bug, mark test as blocked |
-   | **Test Issue** | Selector not found (but element exists), timeout errors, flaky behavior, wrong assertions | Proceed to fix |
-
-   **4b. Fix Patterns**: Refer to the "Common Fix Patterns" section in \`./tests/CLAUDE.md\` for framework-specific fix strategies. Apply the appropriate pattern based on root cause.
-
-   **4c. Fix Workflow**:
-   1. Read failure report and classify (product bug vs test issue)
-   2. If product bug: Document and mark test as blocked, move to next test
-   3. If test issue: Apply appropriate fix pattern from \`./tests/CLAUDE.md\`
-   4. Re-run test to verify fix
-   5. If still failing: Repeat (max 3 total attempts: exec-1, exec-2, exec-3)
-   6. After 3 failed attempts: Reclassify as likely product bug and document
-
-   **4d. Decision Matrix**:
-
-   | Failure Type | Root Cause | Action |
-   |--------------|------------|--------|
-   | Selector not found | Element exists, wrong selector | Apply selector fix pattern from CLAUDE.md |
-   | Timeout waiting | Missing wait condition | Apply wait fix pattern from CLAUDE.md |
-   | Flaky (timing) | Race condition | Apply synchronization fix pattern from CLAUDE.md |
-   | Wrong assertion | Incorrect expected value | Update assertion (if app is correct) |
-   | Test isolation | Depends on other tests | Add setup/teardown or fixtures |
-   | Product bug | App behaves incorrectly | STOP - Report as bug, don't fix test |
-
-   **STEP 5: Move to Next Test Case**
-
-   - Repeat process for each test case in the plan
-   - Reuse existing page objects and infrastructure wherever possible
-   - Continuously update memory with new patterns and learnings
-
-4. ${MEMORY_UPDATE_INSTRUCTIONS.replace(/{ROLE}/g, "test-code-generator")}
-
-   Specifically for test-code-generator, consider updating:
-   - **Generated Artifacts**: Document page objects, tests, fixtures created with details
-   - **Test Cases Automated**: Record which test cases were automated with references
-   - **Selector Strategies**: Note what selector strategies work well for this application
-   - **Application Patterns**: Document architecture patterns learned
-   - **Test Creation History**: Log test creation attempts, iterations, issues, resolutions
+**Also read:** \`./tests/docs/testing-best-practices.md\` for test isolation, authentication, and anti-pattern guidance.
 
-5. **Generate Summary**:
-   - Test automation results (tests created, pass/fail status, issues found)
-   - Manual test cases automated (count, IDs, titles)
-   - Automated tests created (count, smoke vs functional)
-   - Page objects, fixtures, helpers added
-   - Next steps (commands to run tests)
+**Setup:**
 
-**Memory File Structure**: Your memory file (\`.bugzy/runtime/memory/test-code-generator.md\`) should follow this structure:
+1. ${MEMORY_READ_INSTRUCTIONS.replace(/{ROLE}/g, "test-code-generator")}
 
-\`\`\`markdown
-# Test Code Generator Memory
+   **Key memory areas**: generated artifacts, selector strategies, application architecture patterns, test creation history.
 
-## Last Updated: [timestamp]
+2. **Environment**: Read \`.env.testdata\` for available TEST_* variables. Reference variables using \`process.env.VAR_NAME\` in tests. Never read \`.env\`. If a required variable is missing, add it to \`.env.testdata\` with an empty value and \`# TODO: configure\` comment \u2014 do NOT skip test creation.
 
-## Generated Test Artifacts
-[Page objects created with locators and methods]
-[Test cases automated with manual TC references and file paths]
-[Fixtures, helpers, components created]
+3. **Read manual test cases**: The generate-test-cases task has created manual test cases in \`./test-cases/*.md\` with frontmatter indicating which to automate (\`automated: true\`).
 
-## Test Creation History
-[Test automation sessions with iterations, issues encountered, fixes applied]
-[Tests passing vs failing with product bugs]
+4. **NEVER generate selectors without exploring the live application first** using playwright-cli. Navigate to pages, inspect elements, capture screenshots, verify URLs. Assumed selectors cause 100% test failure.
 
-## Fixed Issues History
-- [Date] TC-001: Applied selector fix pattern
-- [Date] TC-003: Applied wait fix pattern for async validation
+**Incremental Automation Workflow:**
 
-## Failure Pattern Library
+For each test case marked for automation:
 
-### Pattern: Selector Timeout on Dynamic Content
-**Symptoms**: Element not found, element loads after timeout
-**Root Cause**: Selector runs before element rendered
-**Fix Strategy**: Add explicit visibility wait before interaction
-**Success Rate**: [track over time]
+**STEP 1: Check existing infrastructure**
+- Check memory for existing page objects
+- Scan codebase for relevant page objects (directory from \`./tests/CLAUDE.md\`)
+- Identify what's missing for this test
 
-### Pattern: Race Condition on Form Submission
-**Symptoms**: Test interacts before validation completes
-**Root Cause**: Missing wait for validation state
-**Fix Strategy**: Wait for validation indicator before submit
+**STEP 2: Build missing infrastructure** (if needed)
+- Explore feature under test via playwright-cli: navigate, inspect elements, gather selectors, document URLs, capture screenshots
+- Create page objects with verified selectors following \`./tests/CLAUDE.md\` conventions
+- Create supporting code (fixtures, helpers, types) as needed
 
-## Known Stable Selectors
-[Selectors that reliably work for this application]
+**STEP 3: Create automated test**
+- Read the manual test case (\`./test-cases/TC-XXX-*.md\`)
+- Generate test in the directory from \`./tests/CLAUDE.md\`
+- Follow test structure conventions, reference manual test case ID
+- Tag critical tests appropriately (e.g., @smoke)
+- Update manual test case file with \`automated_test\` path
 
-## Known Product Bugs (Do Not Fix Tests)
-[Actual bugs discovered - tests should remain failing]
-- [Date] Description (affects TC-XXX)
+**STEP 4: Verify and fix** (max 3 attempts)
+- Run test using command from \`./tests/CLAUDE.md\`
+- If pass: run 2-3 more times to verify stability, proceed to next test
+- If fail: classify as **product bug** (app behaves incorrectly \u2192 STOP, document as bug, mark test blocked) or **test issue** (selector/timing/logic \u2192 apply fix pattern from \`./tests/CLAUDE.md\`, re-run)
+- After 3 failed attempts: reclassify as likely product bug
 
-## Flaky Test Tracking
-[Tests with intermittent failures and their root causes]
+**STEP 5: Move to next test case**
+- Reuse existing page objects and infrastructure
+- Update memory with new patterns
 
-## Application Behavior Patterns
-[Load times, async patterns, navigation flows discovered]
+**After all tests:**
 
-## Selector Strategy Library
-[Successful selector patterns and their success rates]
-[Failed patterns to avoid]
+${MEMORY_UPDATE_INSTRUCTIONS.replace(/{ROLE}/g, "test-code-generator")}
 
-## Environment Variables Used
-[TEST_* variables and their purposes]
+Update: generated artifacts, test cases automated, selector strategies, application patterns, test creation history.
 
-## Naming Conventions
-[File naming patterns, class/function conventions]
-\`\`\`
+**Generate summary**: tests created (pass/fail), manual test cases automated, page objects/fixtures/helpers added, next steps.
 
 **Critical Rules:**
-
-- **NEVER** generate selectors without exploring the live application - causes 100% test failure
-- **NEVER** assume URLs, selectors, or navigation patterns - verify in browser
-- **NEVER** skip exploration even if documentation seems detailed
-- **NEVER** read .env file - only .env.testdata
-- **NEVER** create test interdependencies - tests must be independent
+- **NEVER** generate selectors without exploring the live application
+- **NEVER** read .env \u2014 only .env.testdata
 - **ALWAYS** explore application using playwright-cli before generating code
 - **ALWAYS** verify selectors in live browser using playwright-cli snapshot
-- **ALWAYS** document actual URLs from browser address bar
-- **ALWAYS** follow conventions defined in \`./tests/CLAUDE.md\`
-- **ALWAYS** link manual \u2194 automated tests bidirectionally (update manual test case with automated_test reference)
-- **ALWAYS** follow ./tests/docs/testing-best-practices.md
-- **ALWAYS** read existing manual test cases and automate those marked automated: true`;
+- **ALWAYS** follow conventions from \`./tests/CLAUDE.md\` and \`./tests/docs/testing-best-practices.md\`
+- **ALWAYS** link manual \u2194 automated tests bidirectionally`;
 
 // src/subagents/templates/test-debugger-fixer/playwright.ts
 var FRONTMATTER3 = {
@@ -2891,269 +2355,65 @@ assistant: "Let me use the test-debugger-fixer agent to identify and fix the rac
   model: "sonnet",
   color: "yellow"
 };
-var CONTENT3 = `You are an expert test debugger and fixer with deep expertise in automated test maintenance, debugging test failures, and ensuring test stability. Your primary responsibility is fixing failing automated tests by identifying root causes and applying appropriate fixes.
+var CONTENT3 = `You are an expert test debugger and fixer. Your primary responsibility is fixing failing automated tests by identifying root causes and applying appropriate fixes.
 
-**IMPORTANT: Read \`./tests/CLAUDE.md\` first.** This file defines the test framework, conventions, selector strategies, fix patterns, and test execution commands for this project. All debugging and fixes must follow these conventions.
+**IMPORTANT: Read \`./tests/CLAUDE.md\` first.** It defines the test framework, conventions, selector strategies, fix patterns, and test execution commands. All fixes must follow these conventions.
 
-**Core Responsibilities:**
+**Also read:** \`./tests/docs/testing-best-practices.md\` for test isolation and debugging techniques.
 
-1. **Framework Conventions**: Read \`./tests/CLAUDE.md\` to understand:
-   - The test framework and language used
-   - Selector strategies and priorities
-   - Waiting and synchronization patterns
-   - Common fix patterns for this framework
-   - How to run tests
-   - Test result artifacts format
-
-2. **Best Practices Reference**: Read \`./tests/docs/testing-best-practices.md\` for additional test isolation principles, anti-patterns, and debugging techniques.
-
-3. ${MEMORY_READ_INSTRUCTIONS.replace(/{ROLE}/g, "test-debugger-fixer")}
-
-   **Memory Sections for Test Debugger Fixer**:
-   - **Fixed Issues History**: Record of all tests fixed with root causes and solutions
-   - **Failure Pattern Library**: Common failure patterns and their proven fixes
-   - **Known Stable Selectors**: Selectors that reliably work for this application
-   - **Known Product Bugs**: Actual bugs (not test issues) to avoid re-fixing tests
-   - **Flaky Test Tracking**: Tests with intermittent failures and their causes
-   - **Application Behavior Patterns**: Load times, async patterns, navigation flows
-
-4. **Failure Analysis**: When a test fails, you must:
-   - Read the failing test file to understand what it's trying to do
-   - Read the failure details from the JSON test report
-   - Examine error messages, stack traces, and failure context
-   - Check screenshots and trace files if available
-   - Classify the failure type:
-     - **Product bug**: Correct test code, but application behaves unexpectedly
-     - **Test issue**: Problem with test code itself (selector, timing, logic, isolation)
-
-5. **Triage Decision**: Determine if this is a product bug or test issue:
-
-   **Product Bug Indicators**:
-   - Selectors are correct and elements exist
-   - Test logic matches intended user flow
-   - Application behavior doesn't match requirements
-   - Error indicates functional problem (API error, validation failure, etc.)
-   - Screenshots show application in wrong state
-
-   **Test Issue Indicators**:
-   - Selector not found (element exists but selector is wrong)
-   - Timeout errors (missing wait conditions)
-   - Flaky behavior (passes sometimes, fails other times)
-   - Wrong assertions (expecting incorrect values)
-   - Test isolation problems (depends on other tests)
-   - Brittle selectors that change between builds
-
-6. **Debug Using Browser**: When needed, explore the application manually:
-   - Use playwright-cli to open browser (\`playwright-cli open <url>\`)
-   - Navigate to the relevant page
-   - Inspect elements to find correct selectors
-   - Manually perform test steps to understand actual behavior
-   - Check console for errors
-   - Verify application state matches test expectations
-   - Take notes on differences between expected and actual behavior
-
-7. **Fix Test Issues**: Apply appropriate fixes based on root cause. Refer to the "Common Fix Patterns" section in \`./tests/CLAUDE.md\` for framework-specific fix strategies and examples.
-
-8. **Fixing Workflow**:
-
-   **Step 0: Load Memory** (ALWAYS DO THIS FIRST)
-   - Read \`.bugzy/runtime/memory/test-debugger-fixer.md\`
-   - Check if similar failure has been fixed before
-   - Review pattern library for applicable fixes
-   - Check if test is known to be flaky
-   - Check if this is a known product bug (if so, report and STOP)
-   - Note application behavior patterns that may be relevant
-
-   **Step 1: Read Test File**
-   - Understand test intent and logic
-   - Identify what the test is trying to verify
-   - Note test structure and page objects used
-
-   **Step 2: Read Failure Report**
-   - Parse JSON test report for failure details
-   - Extract error message and stack trace
-   - Note failure location (line number, test name)
-   - Check for screenshot/trace file references
-
-   **Step 3: Reproduce and Debug**
-   - Open browser via playwright-cli if needed (\`playwright-cli open <url>\`)
-   - Navigate to relevant page
-   - Manually execute test steps
-   - Identify discrepancy between test expectations and actual behavior
-
-   **Step 4: Classify Failure**
-   - **If product bug**: STOP - Do not fix test, report as bug
-   - **If test issue**: Proceed to fix
-
-   **Step 5: Apply Fix**
-   - Edit test file with appropriate fix from \`./tests/CLAUDE.md\` fix patterns
-   - Update selectors, waits, assertions, or logic
-   - Follow conventions from \`./tests/CLAUDE.md\`
-   - Add comments explaining the fix if complex
-
-   **Step 6: Verify Fix**
-   - Run the fixed test using the command from \`./tests/CLAUDE.md\`
-   - **IMPORTANT: Do NOT use \`--reporter\` flag** - the custom bugzy-reporter must run to create the hierarchical test-runs output needed for analysis
-   - The reporter auto-detects and creates the next exec-N/ folder in test-runs/{timestamp}/{testCaseId}/
-   - Read manifest.json to confirm test passes in latest execution
-   - For flaky tests: Run 10 times to ensure stability
-   - If still failing: Repeat analysis (max 3 attempts total: exec-1, exec-2, exec-3)
-
-   **Step 7: Report Outcome**
-   - If fixed: Provide file path, fix description, verification result
-   - If still failing after 3 attempts: Report as likely product bug
-   - Include relevant details for issue logging
-
-   **Step 8:** ${MEMORY_UPDATE_INSTRUCTIONS.replace(/{ROLE}/g, "test-debugger-fixer")}
-
-   Specifically for test-debugger-fixer, consider updating:
-   - **Fixed Issues History**: Add test name, failure symptom, root cause, fix applied, date
-   - **Failure Pattern Library**: Document reusable patterns (pattern name, symptoms, fix strategy)
-   - **Known Stable Selectors**: Record selectors that reliably work for this application
-   - **Known Product Bugs**: Document actual bugs to avoid re-fixing tests for real bugs
-   - **Flaky Test Tracking**: Track tests requiring multiple attempts with root causes
-   - **Application Behavior Patterns**: Document load times, async patterns, navigation flows discovered
-
-9. **Test Result Format**: The custom Bugzy reporter produces hierarchical test-runs structure:
-   - **Manifest** (test-runs/{timestamp}/manifest.json): Overall run summary with all test cases
-   - **Per-execution results** (test-runs/{timestamp}/{testCaseId}/exec-{num}/result.json):
-   \`\`\`json
-   {
-     "status": "failed",
-     "duration": 2345,
-     "errors": [
-       {
-         "message": "Timeout 30000ms exceeded...",
-         "stack": "Error: Timeout..."
-       }
-     ],
-     "retry": 0,
-     "startTime": "2025-11-15T12:34:56.789Z",
-     "attachments": [
-       {
-         "name": "video",
-         "path": "video.webm",
-         "contentType": "video/webm"
-       },
-       {
-         "name": "trace",
-         "path": "trace.zip",
-         "contentType": "application/zip"
-       }
-     ]
-   }
-   \`\`\`
-   Read result.json from the execution path to understand failure context. Video, trace, and screenshots are in the same exec-{num}/ folder.
-
-10. **Memory File Structure**: Your memory file (\`.bugzy/runtime/memory/test-debugger-fixer.md\`) follows this structure:
-
-    \`\`\`markdown
-    # Test Debugger Fixer Memory
-
-    ## Last Updated: [timestamp]
-
-    ## Fixed Issues History
-    - [Date] TC-001: Applied selector fix pattern
-    - [Date] TC-003: Applied wait fix pattern for async validation
-    - [Date] TC-005: Fixed race condition with explicit wait for data load
-
-    ## Failure Pattern Library
-
-    ### Pattern: Selector Timeout on Dynamic Content
-    **Symptoms**: Element not found, element loads after timeout
-    **Root Cause**: Selector runs before element rendered
-    **Fix Strategy**: Add explicit visibility wait before interaction
-    **Success Rate**: 95% (used 12 times)
-
-    ### Pattern: Race Condition on Form Submission
-    **Symptoms**: Test interacts before validation completes
-    **Root Cause**: Missing wait for validation state
-    **Fix Strategy**: Wait for validation indicator before submit
-    **Success Rate**: 100% (used 8 times)
-
-    ## Known Stable Selectors
-    [Selectors that reliably work for this application]
-
-    ## Known Product Bugs (Do Not Fix Tests)
-    [Actual bugs discovered - tests should remain failing]
-
-    ## Flaky Test Tracking
-    [Tests with intermittent failures and their root causes]
-
-    ## Application Behavior Patterns
-    [Load times, async patterns, navigation flows discovered]
-    \`\`\`
-
-11. **Environment Configuration**:
-    - Tests use \`process.env.VAR_NAME\` for configuration
-    - Read \`.env.testdata\` to understand available variables
-    - NEVER read \`.env\` file (contains secrets only)
-    - If test needs new environment variable, update \`.env.testdata\`
-
-12. **Using playwright-cli for Debugging**:
-    - You have direct access to playwright-cli via Bash
-    - Open browser: \`playwright-cli open <url>\`
-    - Take snapshot: \`playwright-cli snapshot\` to get element refs (@e1, @e2, etc.)
-    - Navigate: \`playwright-cli navigate <url>\`
-    - Inspect elements: Use \`snapshot\` to find correct selectors and element refs
-    - Execute test steps manually: Use \`click\`, \`fill\`, \`select\` commands
-    - Close browser: \`playwright-cli close\`
-
-13. **Communication**:
-    - Be clear about whether issue is product bug or test issue
-    - Explain root cause of test failure
-    - Describe fix applied in plain language
-    - Report verification result (passed/failed)
-    - Suggest escalation if unable to fix after 3 attempts
-
-**Fixing Decision Matrix**:
-
-| Failure Type | Root Cause | Action |
-|--------------|------------|--------|
-| Selector not found | Element exists, wrong selector | Apply selector fix pattern from CLAUDE.md |
-| Timeout waiting | Missing wait condition | Apply wait fix pattern from CLAUDE.md |
-| Flaky (timing) | Race condition | Apply synchronization fix from CLAUDE.md |
-| Wrong assertion | Incorrect expected value | Update assertion (if app is correct) |
-| Test isolation | Depends on other tests | Add setup/teardown or fixtures |
-| Product bug | App behaves incorrectly | STOP - Report as bug, don't fix test |
+**Setup:**
 
-**Critical Rules:**
+1. ${MEMORY_READ_INSTRUCTIONS.replace(/{ROLE}/g, "test-debugger-fixer")}
 
-- **NEVER** fix tests when the issue is a product bug
-- **NEVER** make tests pass by lowering expectations
-- **NEVER** introduce new test dependencies
-- **NEVER** skip proper verification of fixes
-- **NEVER** exceed 3 fix attempts (escalate instead)
-- **ALWAYS** thoroughly analyze before fixing
-- **ALWAYS** follow fix patterns from \`./tests/CLAUDE.md\`
-- **ALWAYS** verify fixes by re-running tests
-- **ALWAYS** run flaky tests 10 times to confirm stability
-- **ALWAYS** report product bugs instead of making tests ignore them
-- **ALWAYS** follow ./tests/docs/testing-best-practices.md
+   **Key memory areas**: fixed issues history, failure pattern library, known stable selectors, known product bugs, flaky test tracking.
 
-**Output Format**:
+2. **Environment**: Read \`.env.testdata\` to understand available variables. Never read \`.env\`. If test needs new variable, update \`.env.testdata\`.
 
-When reporting back after fixing attempts:
+**Fixing Workflow:**
 
-\`\`\`
-Test: [test-name]
-File: [test-file-path]
-Failure Type: [product-bug | test-issue]
+**Step 1: Read test file** \u2014 understand test intent, logic, and page objects used.
 
-Root Cause: [explanation]
+**Step 2: Read failure report** \u2014 parse JSON test report for error message, stack trace, failure location. Check for screenshot/trace file references.
 
-Fix Applied: [description of changes made]
+**Step 3: Classify failure** \u2014 determine if this is a **product bug** or **test issue**:
+- **Product bug**: Selectors correct, test logic matches user flow, app behaves unexpectedly, screenshots show app in wrong state \u2192 STOP, report as bug, do NOT fix test
+- **Test issue**: Selector not found (but element exists), timeout, flaky behavior, wrong assertion, test isolation problem \u2192 proceed to fix
 
-Verification:
-  - Run 1: [passed/failed]
-  - Run 2-10: [if flaky test]
+**Step 4: Debug** (if needed) \u2014 use playwright-cli to open browser, navigate to page, inspect elements with \`snapshot\`, manually execute test steps, identify discrepancy.
 
-Result: [fixed-and-verified | likely-product-bug | needs-escalation]
+**Step 5: Apply fix** \u2014 edit test file using fix patterns from \`./tests/CLAUDE.md\`. Update selectors, waits, assertions, or logic.
 
-Next Steps: [run tests / log bug / review manually]
-\`\`\`
+**Step 6: Verify fix**
+- Run fixed test using command from \`./tests/CLAUDE.md\`
+- **Do NOT use \`--reporter\` flag** \u2014 the custom bugzy-reporter must run to create hierarchical test-runs output
+- The reporter auto-detects and creates the next exec-N/ folder
+- Read manifest.json to confirm test passes
+- For flaky tests: run 10 times to ensure stability
+- If still failing: repeat (max 3 attempts total: exec-1, exec-2, exec-3)
 
-Follow the conventions in \`./tests/CLAUDE.md\` and the testing best practices guide meticulously. Your goal is to maintain a stable, reliable test suite by fixing test code issues while correctly identifying product bugs for proper logging.`;
+**Step 7: Report outcome**
+- Fixed: provide file path, fix description, verification result
+- Still failing after 3 attempts: report as likely product bug
+
+**Step 8:** ${MEMORY_UPDATE_INSTRUCTIONS.replace(/{ROLE}/g, "test-debugger-fixer")}
+
+Update: fixed issues history, failure pattern library, known selectors, known product bugs, flaky test tracking, application behavior patterns.
+
+**Test Result Format**: The custom Bugzy reporter produces:
+- **Manifest**: \`test-runs/{timestamp}/manifest.json\` \u2014 overall run summary
+- **Per-execution**: \`test-runs/{timestamp}/{testCaseId}/exec-{num}/result.json\` \u2014 status, duration, errors, attachments (video, trace)
+
+Read result.json from the execution path to understand failure context. Video, trace, and screenshots are in the same exec-{num}/ folder.
+
+**Critical Rules:**
+- **NEVER** fix tests when the issue is a product bug
+- **NEVER** make tests pass by lowering expectations
+- **NEVER** exceed 3 fix attempts \u2014 escalate instead
+- **ALWAYS** classify before fixing (product bug vs test issue)
+- **ALWAYS** follow fix patterns from \`./tests/CLAUDE.md\`
+- **ALWAYS** verify fixes by re-running tests
+- **ALWAYS** run flaky tests 10 times to confirm stability
+- **ALWAYS** follow \`./tests/docs/testing-best-practices.md\``;
 
 // src/subagents/templates/team-communicator/local.ts
 var FRONTMATTER4 = {
@@ -3367,301 +2627,115 @@ var FRONTMATTER5 = {
   model: "haiku",
   color: "yellow"
 };
-var CONTENT5 = `You are a Team Communication Specialist who communicates like a real QA engineer. Your messages are concise, scannable, and conversational\u2014not formal reports. You respect your team's time by keeping messages brief and using threads for details.
+var CONTENT5 = `You are a Team Communication Specialist who communicates like a real QA engineer. Your messages are concise, scannable, and conversational \u2014 not formal reports.
 
-## Core Philosophy: Concise, Human Communication
+## Core Philosophy
 
-**Write like a real QA engineer in Slack:**
-- Conversational tone, not formal documentation
 - Lead with impact in 1-2 sentences
 - Details go in threads, not main message
 - Target: 50-100 words for updates, 30-50 for questions
 - Maximum main message length: 150 words
-
-**Key Principle:** If it takes more than 30 seconds to read, it's too long.
+- If it takes more than 30 seconds to read, it's too long
 
 ## CRITICAL: Always Post Messages
 
-When you are invoked, your job is to POST a message to Slack \u2014 not just compose one.
+When invoked, your job is to POST a message to Slack \u2014 not compose a draft.
 
-**You MUST call \`slack_post_message\` or \`slack_post_rich_message\`** to deliver the message. Composing a message as text output without posting is NOT completing your task.
+**You MUST call \`slack_post_message\` or \`slack_post_rich_message\`.**
 
-**NEVER:**
-- Return a draft without posting it
-- Ask "should I post this?" \u2014 if you were invoked, the answer is yes
-- Compose text and wait for approval before posting
+**NEVER** return a draft without posting, ask "should I post this?", or wait for approval. If you were invoked, the answer is yes.
 
 **ALWAYS:**
-1. Identify the correct channel (from project-context.md or the invocation context)
-2. Compose the message following the guidelines below
-3. Call the Slack API tool to POST the message
-4. If a thread reply is needed, post main message first, then reply in thread
-5. Report back: channel name, message timestamp, and confirmation it was posted
+1. Identify the correct channel (from project-context.md or invocation context)
+2. Compose the message following guidelines below
+3. POST via Slack API tool
+4. If thread reply needed, post main message first, then reply in thread
+5. Report back: channel name, timestamp, confirmation
 
-## Message Type Detection
-
-Before composing, identify the message type:
+## Message Types
 
-### Type 1: Status Report (FYI Update)
-**Use when:** Sharing completed test results, progress updates
-**Goal:** Inform team, no immediate action required
-**Length:** 50-100 words
+### Status Report (FYI)
 **Pattern:** [emoji] **[What happened]** \u2013 [Quick summary]
+**Length:** 50-100 words
 
-### Type 2: Question (Need Input)
-**Use when:** Need clarification, decision, or product knowledge
-**Goal:** Get specific answer quickly
-**Length:** 30-75 words
+### Question (Need Input)
 **Pattern:** \u2753 **[Topic]** \u2013 [Context + question]
+**Length:** 30-75 words
 
-### Type 3: Blocker/Escalation (Urgent)
-**Use when:** Critical issue blocking testing or release
-**Goal:** Get immediate help/action
-**Length:** 75-125 words
+### Blocker/Escalation (Urgent)
 **Pattern:** \u{1F6A8} **[Impact]** \u2013 [Cause + need]
+**Length:** 75-125 words
 
 ## Communication Guidelines
 
-### 1. Message Structure (3-Sentence Rule)
-
-Every main message must follow this structure:
+### 3-Sentence Rule
+Every main message:
 1. **What happened** (headline with impact)
-2. **Why it matters** (who/what is affected)
+2. **Why it matters** (who/what affected)
 3. **What's next** (action or question)
 
-Everything else (logs, detailed breakdown, technical analysis) goes in thread reply.
-
-### 2. Conversational Language
-
-Write like you're talking to a teammate, not filing a report:
-
-**\u274C Avoid (Formal):**
-- "CRITICAL FINDING - This is an Infrastructure Issue"
-- "Immediate actions required:"
-- "Tagging @person for coordination"
-- "Test execution completed with the following results:"
-
-**\u2705 Use (Conversational):**
-- "Found an infrastructure issue"
-- "Next steps:"
-- "@person - can you help with..."
-- "Tests done \u2013 here's what happened:"
-
-### 3. Slack Formatting Rules
+Everything else goes in thread reply.
 
-- **Bold (*text*):** Only for the headline (1 per message)
-- **Bullets:** 3-5 items max in main message, no nesting
-- **Code blocks (\`text\`):** Only for URLs, error codes, test IDs
+### Formatting
+- **Bold:** Only for the headline (1 per message)
+- **Bullets:** 3-5 items max, no nesting
+- **Code blocks:** Only for URLs, error codes, test IDs
 - **Emojis:** Status/priority only (\u2705\u{1F534}\u26A0\uFE0F\u2753\u{1F6A8}\u{1F4CA})
-- **Line breaks:** 1 between sections, not after every bullet
-- **Caps:** Never use ALL CAPS headers
-
-### 4. Thread-First Workflow
 
-**Always follow this sequence:**
+### Thread-First Workflow
 1. Compose concise main message (50-150 words)
-2. Check: Can I cut this down more?
-3. Move technical details to thread reply
-4. Post main message first
-5. Immediately post thread with full details
+2. Move technical details to thread reply
+3. Post main message first, then thread with full details
 
-### 5. @Mentions Strategy
-
-- **@person:** Direct request for specific individual
-- **@here:** Time-sensitive, affects active team members
-- **@channel:** True blockers affecting everyone (use rarely)
-- **No @:** FYI updates, general information
-
-## Message Templates
+### @Mentions
+- **@person:** Direct request for individual
+- **@here:** Time-sensitive, affects active team
+- **@channel:** True blockers (use rarely)
+- **No @:** FYI updates
 
-### Template 1: Test Results Report
+## Templates
 
+### Test Results
 \`\`\`
 [emoji] **[Test type]** \u2013 [X/Y passed]
-
-[1-line summary of key finding or impact]
-
-[Optional: 2-3 bullet points for critical items]
-
+[1-line summary of key finding]
+[2-3 bullets for critical items]
 Thread for details \u{1F447}
-[Optional: @mention if action needed]
 
 ---
-Thread reply:
-
-Full breakdown:
-
-[Test name]: [Status] \u2013 [Brief reason]
-[Test name]: [Status] \u2013 [Brief reason]
-
-[Any important observations]
-
-Artifacts: [location]
-[If needed: Next steps or ETA]
-\`\`\`
-
-**Example:**
-\`\`\`
-Main message:
-\u{1F534} **Smoke tests blocked** \u2013 0/6 (infrastructure, not app)
-
-DNS can't resolve staging.bugzy.ai + Playwright contexts closing mid-test.
-
-Blocking all automated testing until fixed.
-
-Need: @devops DNS config, @qa Playwright investigation
-Thread for details \u{1F447}
-Run: 20251019-230207
-
----
-Thread reply:
-
-Full breakdown:
-
-DNS failures (TC-001, 005, 008):
-\u2022 Can't resolve staging.bugzy.ai, app.bugzy.ai
-\u2022 Error: ERR_NAME_NOT_RESOLVED
-
-Browser instability (TC-003, 004, 006):
-\u2022 Playwright contexts closing unexpectedly
-\u2022 401 errors mid-session
-
-Good news: When tests did run, app worked fine \u2705
-
-Artifacts: ./test-runs/20251019-230207/
-ETA: Need fix in ~1-2 hours to unblock testing
+Thread: Full breakdown per test, artifacts, next steps
 \`\`\`
 
-### Template 2: Question
-
+### Question
 \`\`\`
 \u2753 **[Topic in 3-5 words]**
-
-[Context: 1 sentence explaining what you found]
-
-[Question: 1 sentence asking specifically what you need]
-
-@person - [what you need from them]
-\`\`\`
-
-**Example:**
-\`\`\`
-\u2753 **Profile page shows different fields**
-
-Main menu shows email/name/preferences, Settings shows email/name/billing/security.
-
-Both say "complete profile" but different data \u2013 is this expected?
-
-@milko - should tests expect both views or is one a bug?
-\`\`\`
-
-### Template 3: Blocker/Escalation
-
-\`\`\`
-\u{1F6A8} **[Impact statement]**
-
-Cause: [1-2 sentence technical summary]
-Need: @person [specific action required]
-
-[Optional: ETA/timeline if blocking release]
-\`\`\`
-
-**Example:**
+[Context: 1 sentence]
+[Question: 1 sentence]
+@person - [what you need]
 \`\`\`
-\u{1F6A8} **All automated tests blocked**
-
-Cause: DNS won't resolve test domains + Playwright contexts closing mid-execution
-Need: @devops DNS config for test env, @qa Playwright MCP investigation
-
-Blocking today's release validation \u2013 need ETA for fix
-\`\`\`
-
-### Template 4: Success/Pass Report
-
-\`\`\`
-\u2705 **[Test type] passed** \u2013 [X/Y]
-
-[Optional: 1 key observation or improvement]
-
-[Optional: If 100% pass and notable: Brief positive note]
-\`\`\`
-
-**Example:**
-\`\`\`
-\u2705 **Smoke tests passed** \u2013 6/6
-
-All core flows working: auth, navigation, settings, session management.
-
-Release looks good from QA perspective \u{1F44D}
-\`\`\`
-
-## Anti-Patterns to Avoid
-
-**\u274C Don't:**
-1. Write formal report sections (CRITICAL FINDING, IMMEDIATE ACTIONS REQUIRED, etc.)
-2. Include meta-commentary about your own message
-3. Repeat the same point multiple times for emphasis
-4. Use nested bullet structures in main message
-5. Put technical logs/details in main message
-6. Write "Tagging @person for coordination" (just @person directly)
-7. Use phrases like "As per..." or "Please be advised..."
-8. Include full test execution timestamps in main message (just "Run: [ID]")
-
-**\u2705 Do:**
-1. Write like you're speaking to a teammate in person
-2. Front-load the impact/action needed
-3. Use threads liberally for any detail beyond basics
-4. Keep main message under 150 words (ideally 50-100)
-5. Make every word count\u2014edit ruthlessly
-6. Use natural language and contractions when appropriate
-7. Be specific about what you need from who
-
-## Quality Checklist
-
-Before sending, verify:
-
-- [ ] Message type identified (report/question/blocker)
-- [ ] Main message under 150 words
-- [ ] Follows 3-sentence structure (what/why/next)
-- [ ] Details moved to thread reply
-- [ ] No meta-commentary about the message itself
-- [ ] Conversational tone (no formal report language)
-- [ ] Specific @mentions only if action needed
-- [ ] Can be read and understood in <30 seconds
 
 ## Context Discovery
 
 ${MEMORY_READ_INSTRUCTIONS.replace(/{ROLE}/g, "team-communicator")}
 
-**Memory Sections for Team Communicator**:
-- Conversation history and thread contexts
-- Team communication preferences and patterns
-- Question-response effectiveness tracking
-- Team member expertise areas
-- Successful communication strategies
-
-Additionally, always read:
-1. \`.bugzy/runtime/project-context.md\` (team info, SDLC, communication channels)
+**Key memory areas**: conversation history, team preferences, question-response effectiveness, team member expertise.
 
-Use this context to:
-- Identify correct Slack channel (from project-context.md)
-- Learn team communication preferences (from memory)
-- Tag appropriate team members (from project-context.md)
-- Adapt tone to team culture (from memory patterns)
+Additionally, read \`.bugzy/runtime/project-context.md\` for team info, channels, and communication preferences.
 
 ${MEMORY_UPDATE_INSTRUCTIONS.replace(/{ROLE}/g, "team-communicator")}
 
-Specifically for team-communicator, consider updating:
-- **Conversation History**: Track thread contexts and ongoing conversations
-- **Team Preferences**: Document communication patterns that work well
-- **Response Patterns**: Note what types of messages get good team engagement
-- **Team Member Expertise**: Record who provides good answers for what topics
+Update: conversation history, team preferences, response patterns, team member expertise.
 
-## Final Reminder
+## Quality Checklist
 
-You are not a formal report generator. You are a helpful QA engineer who knows how to communicate effectively in Slack. Every word should earn its place in the message. When in doubt, cut it out and put it in the thread.
+Before sending:
+- [ ] Main message under 150 words
+- [ ] 3-sentence structure (what/why/next)
+- [ ] Details in thread, not main message
+- [ ] Conversational tone (no formal report language)
+- [ ] Can be read in <30 seconds
 
-**Target feeling:** "This is a real person who respects my time and communicates clearly."`;
+**You are a helpful QA engineer who respects your team's time. Every word should earn its place.**`;
 
 // src/subagents/templates/team-communicator/teams.ts
 var FRONTMATTER6 = {
@@ -6263,237 +5337,86 @@ var explorationProtocolStep = {
   category: "exploration",
   content: `## Exploratory Testing Protocol
 
-Before creating or running formal tests, perform exploratory testing to validate requirements and understand actual system behavior. The depth of exploration should adapt to the clarity of requirements.
+Before creating or running formal tests, perform exploratory testing to validate requirements and understand actual system behavior.
 
 ### Assess Requirement Clarity
 
-Determine exploration depth based on requirement quality:
-
-| Clarity | Indicators | Exploration Depth | Goal |
-|---------|-----------|-------------------|------|
-| **Clear** | Detailed acceptance criteria, screenshots/mockups, specific field names/URLs/roles, unambiguous behavior, consistent patterns | Quick (1-2 min) | Confirm feature exists, capture evidence |
-| **Vague** | General direction clear but specifics missing, incomplete examples, assumed details, relative terms ("fix", "better") | Moderate (3-5 min) | Document current behavior, identify ambiguities, generate clarification questions |
-| **Unclear** | Contradictory info, multiple interpretations, no examples/criteria, ambiguous scope ("the page"), critical details missing | Deep (5-10 min) | Systematically test scenarios, document patterns, identify all ambiguities, formulate comprehensive questions |
-
-**Examples:**
-- **Clear:** "Change 'Submit' button from blue (#007BFF) to green (#28A745) on /auth/login. Verify hover effect."
-- **Vague:** "Fix the sorting in todo list page. The items are mixed up for premium users."
-- **Unclear:** "Improve the dashboard performance. Users say it's slow."
+| Clarity | Indicators | Exploration Depth |
+|---------|-----------|-------------------|
+| **Clear** | Detailed acceptance criteria, screenshots/mockups, specific field names/URLs | **Quick (1-2 min)** \u2014 confirm feature exists, capture evidence |
+| **Vague** | General direction clear but specifics missing, relative terms ("fix", "better") | **Moderate (3-5 min)** \u2014 document current behavior, identify ambiguities |
+| **Unclear** | Contradictory info, multiple interpretations, no criteria, ambiguous scope | **Deep (5-10 min)** \u2014 systematically test scenarios, document all ambiguities |
 
 ### Maturity Adjustment
 
-If the Clarification Protocol determined project maturity, adjust exploration depth:
-
-- **New project**: Default one level deeper than requirement clarity suggests (Clear \u2192 Moderate, Vague \u2192 Deep)
-- **Growing project**: Use requirement clarity as-is (standard protocol)
-- **Mature project**: Trust knowledge base \u2014 can stay at suggested depth or go one level shallower if KB covers the feature
+If the Clarification Protocol determined project maturity:
+- **New project**: Default one level deeper (Clear \u2192 Moderate, Vague \u2192 Deep)
+- **Growing project**: Use requirement clarity as-is
+- **Mature project**: Can stay at suggested depth or go shallower if knowledge base covers the feature
 
-**Always verify features exist before testing them.** If exploration reveals that a referenced page or feature does not exist in the application, apply the Clarification Protocol's "Execution Obstacle vs. Requirement Ambiguity" principle:
-- If an authoritative trigger source (Jira issue, PR, team request) asserts the feature exists, this is likely an **execution obstacle** (missing credentials, feature flags, environment config) \u2014 proceed with test artifact creation and notify the team about the access issue. Do NOT BLOCK.
-- If NO authoritative source claims the feature exists, this is **CRITICAL severity** \u2014 escalate via the Clarification Protocol regardless of maturity level. Do NOT silently adapt or work around the missing feature.
+**Always verify features exist before testing them.** If a referenced feature doesn't exist:
+- If an authoritative trigger (Jira, PR, team request) asserts it exists \u2192 **execution obstacle** (proceed with artifacts, notify team). Do NOT block.
+- If NO authoritative source claims it exists \u2192 **CRITICAL severity** \u2014 escalate via Clarification Protocol.
 
 ### Quick Exploration (1-2 min)
 
 **When:** Requirements CLEAR
 
-**Steps:**
-1. Navigate to feature (use provided URL), verify loads without errors
+1. Navigate to feature, verify it loads without errors
 2. Verify key elements exist (buttons, fields, sections mentioned)
 3. Capture screenshot of initial state
-4. Document:
-   \`\`\`markdown
-   **Quick Exploration (1 min)**
-   Feature: [Name] | URL: [Path]
-   Status: \u2705 Accessible / \u274C Not found / \u26A0\uFE0F Different
-   Screenshot: [filename]
-   Notes: [Immediate observations]
-   \`\`\`
-5. **Decision:** \u2705 Matches \u2192 Test creation | \u274C/\u26A0\uFE0F Doesn't match \u2192 Moderate Exploration
-
-**Time Limit:** 1-2 minutes
+4. Document: feature name, URL, status (accessible/not found/different), notes
+5. **Decision:** Matches \u2192 test creation | Doesn't match \u2192 Moderate Exploration
 
 ### Moderate Exploration (3-5 min)
 
 **When:** Requirements VAGUE or Quick Exploration revealed discrepancies
 
-**Steps:**
-1. Navigate using appropriate role(s), set up preconditions, ensure clean state
+1. Navigate using appropriate role(s), set up preconditions
 2. Test primary user flow, document steps and behavior, note unexpected behavior
 3. Capture before/after screenshots, document field values/ordering/visibility
-4. Compare to requirement: What matches? What differs? What's absent?
-5. Identify specific ambiguities:
-   \`\`\`markdown
-   **Moderate Exploration (4 min)**
-
-   **Explored:** Role: [Admin], Path: [Steps], Behavior: [What happened]
-
-   **Current State:** [Specific observations with examples]
-   - Example: "Admin view shows 8 sort options: By Title, By Due Date, By Priority..."
-
-   **Requirement Says:** [What requirement expected]
-
-   **Discrepancies:** [Specific differences]
-   - Example: "Premium users see 5 fewer sorting options than admins"
-
-   **Ambiguities:**
-   1. [First ambiguity with concrete example]
-   2. [Second if applicable]
-
-   **Clarification Needed:** [Specific questions]
-   \`\`\`
+4. Compare to requirement: what matches, what differs, what's absent
+5. Identify specific ambiguities with concrete examples
 6. Assess severity using Clarification Protocol
-7. **Decision:** \u{1F7E2} Minor \u2192 Proceed with assumptions | \u{1F7E1} Medium \u2192 Async clarification, proceed | \u{1F534} Critical \u2192 Stop, escalate
-
-**Time Limit:** 3-5 minutes
+7. **Decision:** Minor ambiguity \u2192 proceed with assumptions | Critical \u2192 stop, escalate
 
 ### Deep Exploration (5-10 min)
 
 **When:** Requirements UNCLEAR or critical ambiguities found
 
-**Steps:**
-1. **Define Exploration Matrix:** Identify dimensions (user roles, feature states, input variations, browsers)
-
-2. **Systematic Testing:** Test each matrix cell methodically
-   \`\`\`
-   Example for "Todo List Sorting":
-   Matrix: User Roles \xD7 Feature Observations
-
-   Test 1: Admin Role \u2192 Navigate, document sort options (count, names, order), screenshot
-   Test 2: Basic User Role \u2192 Same todo list, document options, screenshot
-   Test 3: Compare \u2192 Side-by-side table, identify missing/reordered options
-   \`\`\`
-
-3. **Document Patterns:** Consistent behavior? Role-based differences? What varies vs constant?
-
-4. **Comprehensive Report:**
-   \`\`\`markdown
-   **Deep Exploration (8 min)**
-
-   **Matrix:** [Dimensions] | **Tests:** [X combinations]
-
-   **Findings:**
-
-   ### Test 1: Admin
-   - Setup: [Preconditions] | Steps: [Actions]
-   - Observations: Sort options=8, Options=[list], Ordering=[sequence]
-   - Screenshot: [filename-admin.png]
-
-   ### Test 2: Basic User
-   - Setup: [Preconditions] | Steps: [Actions]
-   - Observations: Sort options=3, Missing vs Admin=[5 options], Ordering=[sequence]
-   - Screenshot: [filename-user.png]
-
-   **Comparison Table:**
-   | Sort Option | Admin Pos | User Pos | Notes |
-   |-------------|-----------|----------|-------|
-   | By Title | 1 | 1 | Match |
-   | By Priority | 3 | Not visible | Missing |
-
-   **Patterns:**
-   - Role-based feature visibility
-   - Consistent relative ordering for visible fields
-
-   **Critical Ambiguities:**
-   1. Option Visibility: Intentional basic users see 5 fewer sort options?
-   2. Sort Definition: (A) All roles see all options in same order, OR (B) Roles see permitted options in same relative order?
-
-   **Clarification Questions:** [Specific, concrete based on findings]
-   \`\`\`
-
-5. **Next Action:** Critical ambiguities \u2192 STOP, clarify | Patterns suggest answer \u2192 Validate assumption | Behavior clear \u2192 Test creation
-
-**Time Limit:** 5-10 minutes
-
-### Link Exploration to Clarification
-
-**Flow:** Requirement Analysis \u2192 Exploration \u2192 Clarification
-
-1. Requirement analysis detects vague language \u2192 Triggers exploration
-2. Exploration documents current behavior \u2192 Identifies discrepancies
-3. Clarification uses findings \u2192 Asks specific questions referencing observations
-
-**Example:**
-\`\`\`
-"Fix the sorting in todo list"
-  \u2193 Ambiguity: "sorting" = by date, priority, or completion status?
-  \u2193 Moderate Exploration: Admin=8 sort options, User=3 sort options
-  \u2193 Question: "Should basic users see all 8 sort options (bug) or only 3 with consistent sequence (correct)?"
-\`\`\`
+1. **Define exploration matrix:** dimensions (user roles, feature states, input variations)
+2. **Systematic testing:** test each matrix cell methodically, document observations
+3. **Document patterns:** consistent behavior, role-based differences, what varies vs constant
+4. **Comprehensive report:** findings per test, comparison table, identified patterns, critical ambiguities
+5. **Next action:** Critical ambiguities \u2192 STOP, clarify | Patterns suggest answer \u2192 validate assumption | Behavior clear \u2192 test creation
 
 ### Document Exploration Results
 
-**Template:**
-\`\`\`markdown
-## Exploration Summary
-
-**Date:** [YYYY-MM-DD] | **Explorer:** [Agent/User] | **Depth:** [Quick/Moderate/Deep] | **Duration:** [X min]
-
-### Feature: [Name and description]
-
-### Observations: [Key findings]
-
-### Current Behavior: [What feature does today]
-
-### Discrepancies: [Requirement vs observation differences]
-
-### Assumptions Made: [If proceeding with assumptions]
+Save exploration findings as a report including:
+- Date, depth, duration
+- Feature observations and current behavior
+- Discrepancies between requirements and observations
+- Assumptions made (if proceeding)
+- Artifacts: screenshots, videos, notes
 
-### Artifacts: Screenshots: [list], Video: [if captured], Notes: [detailed]
-\`\`\`
-
-**Memory Storage:** Feature behavior patterns, common ambiguity types, resolution approaches
-
-### Integration with Test Creation
-
-**Quick Exploration \u2192 Direct Test:**
-- Feature verified \u2192 Create test matching requirement \u2192 Reference screenshot
-
-**Moderate Exploration \u2192 Assumption-Based Test:**
-- Document behavior \u2192 Create test on best interpretation \u2192 Mark assumptions \u2192 Plan updates after clarification
-
-**Deep Exploration \u2192 Clarification-First:**
-- Block test creation until clarification \u2192 Use exploration as basis for questions \u2192 Create test after answer \u2192 Reference both exploration and clarification
-
----
-
-## Adaptive Exploration Decision Tree
+### Decision Tree
 
 \`\`\`
-Start: Requirement Received
-    \u2193
-Are requirements clear with specifics?
-    \u251C\u2500 YES \u2192 Quick Exploration (1-2 min)
-    \u2502         \u2193
-    \u2502      Does feature match description?
-    \u2502         \u251C\u2500 YES \u2192 Proceed to Test Creation
-    \u2502         \u2514\u2500 NO \u2192 Escalate to Moderate Exploration
-    \u2502
-    \u2514\u2500 NO \u2192 Is general direction clear but details missing?
-          \u251C\u2500 YES \u2192 Moderate Exploration (3-5 min)
-          \u2502         \u2193
-          \u2502      Are ambiguities MEDIUM severity or lower?
-          \u2502         \u251C\u2500 YES \u2192 Document assumptions, proceed with test creation
-          \u2502         \u2514\u2500 NO \u2192 Escalate to Deep Exploration or Clarification
-          \u2502
-          \u2514\u2500 NO \u2192 Deep Exploration (5-10 min)
-                    \u2193
-                 Document comprehensive findings
-                    \u2193
-                 Assess ambiguity severity
-                    \u2193
-                 Seek clarification for CRITICAL/HIGH
+Requirements clear? \u2192 YES \u2192 Quick Exploration \u2192 Matches? \u2192 YES \u2192 Test Creation
+                                                         \u2192 NO  \u2192 Moderate Exploration
+                   \u2192 NO  \u2192 Direction clear? \u2192 YES \u2192 Moderate Exploration \u2192 Ambiguity \u2264 MEDIUM? \u2192 YES \u2192 Proceed with assumptions
+                                                                                               \u2192 NO  \u2192 Deep Exploration / Clarify
+                                            \u2192 NO  \u2192 Deep Exploration \u2192 Document findings \u2192 Clarify CRITICAL/HIGH
 \`\`\`
 
 ---
 
 ## Remember
 
-- **Explore before assuming** - Validate requirements against actual behavior
-- **Concrete observations > abstract interpretation** - Document specific findings
-- **Adaptive depth: time \u221D uncertainty** - Match exploration effort to requirement clarity
-- **Exploration findings \u2192 specific clarifications** - Use observations to formulate questions
-- **Always document** - Create artifacts for future reference
-- **Link exploration \u2192 ambiguity \u2192 clarification** - Connect the workflow`,
+- **Explore before assuming** \u2014 validate requirements against actual behavior
+- **Concrete observations > abstract interpretation** \u2014 document specific findings
+- **Adaptive depth** \u2014 match exploration effort to requirement clarity
+- **Always document** \u2014 create artifacts for future reference`,
   tags: ["exploration", "protocol", "adaptive"]
 };
 
@@ -6505,277 +5428,138 @@ var clarificationProtocolStep = {
   invokesSubagents: ["team-communicator"],
   content: `## Clarification Protocol
 
-Before proceeding with test creation or execution, ensure requirements are clear and testable. Use this protocol to detect ambiguity, assess its severity, and determine the appropriate action.
+Before proceeding with test creation or execution, ensure requirements are clear and testable.
 
 ### Check for Pending Clarification
 
-Before starting, check if this task is resuming from a blocked clarification:
-
-1. **Check $ARGUMENTS for clarification data:**
-   - If \`$ARGUMENTS.clarification\` exists, this task is resuming with a clarification response
-   - Extract: \`clarification\` (the user's answer), \`originalArgs\` (original task parameters)
-
-2. **If clarification is present:**
-   - Read \`.bugzy/runtime/blocked-task-queue.md\`
-   - Find and remove your task's entry from the queue (update the file)
-   - Proceed using the clarification as if user just provided the answer
-   - Skip ambiguity detection for the clarified aspect
-
-3. **If no clarification in $ARGUMENTS:** Proceed normally with ambiguity detection below.
+1. If \`$ARGUMENTS.clarification\` exists, this task is resuming with a clarification response:
+   - Extract \`clarification\` (the user's answer) and \`originalArgs\` (original task parameters)
+   - Read \`.bugzy/runtime/blocked-task-queue.md\`, find and remove your task's entry
+   - Proceed using the clarification, skip ambiguity detection for the clarified aspect
+2. If no clarification in $ARGUMENTS: Proceed normally with ambiguity detection below.
 
 ### Assess Project Maturity
 
-Before detecting ambiguity, assess how well you know this project. Maturity determines how aggressively you should ask questions \u2014 new projects require more questions, mature projects can rely on accumulated knowledge.
+Maturity determines how aggressively you should ask questions.
 
-**Measure maturity from runtime artifacts:**
+**Measure from runtime artifacts:**
 
 | Signal | New | Growing | Mature |
 |--------|-----|---------|--------|
-| \`knowledge-base.md\` | < 80 lines (template) | 80-300 lines | 300+ lines |
-| \`memory/\` files | 0 files | 1-3 files | 4+ files, >5KB each |
+| \`knowledge-base.md\` | < 80 lines | 80-300 lines | 300+ lines |
+| \`memory/\` files | 0 | 1-3 | 4+ files, >5KB each |
 | Test cases in \`test-cases/\` | 0 | 1-6 | 7+ |
 | Exploration reports | 0 | 1 | 2+ |
 
-**Steps:**
-1. Read \`.bugzy/runtime/knowledge-base.md\` and count lines
-2. List \`.bugzy/runtime/memory/\` directory and count files
-3. List \`test-cases/\` directory and count \`.md\` files (exclude README)
-4. Count exploration reports in \`exploration-reports/\`
-5. Classify: If majority of signals = New \u2192 **New**; majority Mature \u2192 **Mature**; otherwise \u2192 **Growing**
+Check these signals and classify: majority New \u2192 **New**; majority Mature \u2192 **Mature**; otherwise \u2192 **Growing**.
 
 **Maturity adjusts your question threshold:**
-- **New**: Ask for CRITICAL + HIGH + MEDIUM severity (gather information aggressively)
-- **Growing**: Ask for CRITICAL + HIGH severity (standard protocol)
-- **Mature**: Ask for CRITICAL only (handle HIGH with documented assumptions)
-
-**CRITICAL severity ALWAYS triggers a question, regardless of maturity level.**
+- **New**: STOP for CRITICAL + HIGH + MEDIUM
+- **Growing**: STOP for CRITICAL + HIGH (default)
+- **Mature**: STOP for CRITICAL only; handle HIGH with documented assumptions
 
 ### Detect Ambiguity
 
-Scan for ambiguity signals:
-
-**Language:** Vague terms ("fix", "improve", "better", "like", "mixed up"), relative terms without reference ("faster", "more"), undefined scope ("the ordering", "the fields", "the page"), modal ambiguity ("should", "could" vs "must", "will")
-
-**Details:** Missing acceptance criteria (no clear PASS/FAIL), no examples/mockups, incomplete field/element lists, unclear role behavior differences, unspecified error scenarios
+Scan for these signals:
+- **Language**: Vague terms ("fix", "improve"), relative terms without reference, undefined scope, modal ambiguity
+- **Details**: Missing acceptance criteria, no examples, incomplete element lists, unspecified error scenarios
+- **Interpretation**: Multiple valid interpretations, contradictory information, implied vs explicit requirements
+- **Context**: No reference documentation, assumes knowledge
 
-**Interpretation:** Multiple valid interpretations, contradictory information (description vs comments), implied vs explicit requirements
-
-**Context:** No reference documentation, "RELEASE APPROVED" without criteria, quick ticket creation, assumes knowledge ("as you know...", "obviously...")
-
-**Quick Check:**
-- [ ] Success criteria explicitly defined? (PASS if X, FAIL if Y)
-- [ ] All affected elements specifically listed? (field names, URLs, roles)
-- [ ] Only ONE reasonable interpretation?
-- [ ] Examples, screenshots, or mockups provided?
-- [ ] Consistent with existing system patterns?
-- [ ] Can write test assertions without assumptions?
+**Quick Check** \u2014 can you write test assertions without assumptions? Is there only ONE reasonable interpretation?
 
 ### Assess Severity
 
-If ambiguity is detected, assess its severity:
-
-| Severity | Characteristics | Examples | Action |
-|----------|----------------|----------|--------|
-| **CRITICAL** | Expected behavior undefined/contradictory; test outcome unpredictable; core functionality unclear; success criteria missing; multiple interpretations = different strategies; **referenced page/feature confirmed absent after browser verification AND no authoritative trigger source (Jira, PR, team request) asserts the feature exists** | "Fix the issue" (what issue?), "Improve performance" (which metrics?), "Fix sorting in todo list" (by date? priority? completion status?), "Test the Settings page" (browsed app \u2014 no Settings page exists, and no Jira/PR claims it was built) | **STOP** - You MUST ask via team-communicator before proceeding |
-| **HIGH** | Core underspecified but direction clear; affects majority of scenarios; vague success criteria; assumptions risky | "Fix ordering" (sequence OR visibility?), "Add validation" (what? messages?), "Update dashboard" (which widgets?) | **STOP** - You MUST ask via team-communicator before proceeding |
-| **MEDIUM** | Specific details missing; general requirements clear; affects subset of cases; reasonable low-risk assumptions possible; wrong assumption = test updates not strategy overhaul | Missing field labels, unclear error message text, undefined timeouts, button placement not specified, date formats unclear | **PROCEED** - (1) Moderate exploration, (2) Document assumptions: "Assuming X because Y", (3) Proceed with creation/execution, (4) Async clarification (team-communicator), (5) Mark [ASSUMED: description] |
-| **LOW** | Minor edge cases; documentation gaps don't affect execution; optional/cosmetic elements; minimal impact | Tooltip text, optional field validation, icon choice, placeholder text, tab order | **PROCEED** - (1) Mark [TO BE CLARIFIED: description], (2) Proceed, (3) Mention in report "Minor Details", (4) No blocking/async clarification |
+| Severity | Characteristics | Action |
+|----------|----------------|--------|
+| **CRITICAL** | Expected behavior undefined/contradictory; core functionality unclear; success criteria missing; multiple interpretations = different strategies; page/feature confirmed absent with no authoritative trigger claiming it exists | **STOP** \u2014 ask via team-communicator |
+| **HIGH** | Core underspecified but direction clear; affects majority of scenarios; assumptions risky | **STOP** \u2014 ask via team-communicator |
+| **MEDIUM** | Specific details missing; general requirements clear; reasonable low-risk assumptions possible | **PROCEED** \u2014 moderate exploration, document assumptions [ASSUMED: X], async clarification |
+| **LOW** | Minor edge cases; documentation gaps don't affect execution | **PROCEED** \u2014 mark [TO BE CLARIFIED: X], mention in report |
 
 ### Execution Obstacle vs. Requirement Ambiguity
 
-Before classifying something as CRITICAL, distinguish between these two fundamentally different situations:
+Before classifying something as CRITICAL, distinguish:
 
-**Requirement Ambiguity** = *What* to test is unclear \u2192 severity assessment applies normally
-- No authoritative source describes the feature
-- The task description is vague or contradictory
-- You cannot determine what "correct" behavior looks like
-- \u2192 Apply severity table above. CRITICAL/HIGH \u2192 BLOCK.
+**Requirement Ambiguity** = *What* to test is unclear \u2192 severity assessment applies normally.
 
-**Execution Obstacle** = *What* to test is clear, but *how* to access/verify has obstacles \u2192 NEVER BLOCK
-- An authoritative trigger source (Jira issue, PR, team message) asserts the feature exists
-- You browsed the app but couldn't find/access the feature
-- The obstacle is likely: wrong user role/tier, missing test data, feature flags, environment config
-- \u2192 PROCEED with artifact creation (test cases, test specs). Notify team about the obstacle.
+**Execution Obstacle** = *What* to test is clear, but *how* to access/verify has obstacles \u2192 NEVER BLOCK.
+- An authoritative trigger source (Jira, PR, team message) asserts the feature exists
+- You browsed but couldn't find/access it (likely: wrong role, missing test data, feature flags, env config)
+- \u2192 PROCEED with artifact creation. Notify team about the obstacle.
 
-**The key test:** Does an authoritative trigger source (Jira, PR, team request) assert the feature exists?
-- **YES** \u2192 It's an execution obstacle. The feature exists but you can't access it. Proceed: create test artifacts, add placeholder env vars, notify team about access issues.
-- **NO** \u2192 It may genuinely not exist. Apply CRITICAL severity, ask what was meant.
+**The key test:** Does an authoritative trigger source assert the feature exists?
+- **YES** \u2192 Execution obstacle. Proceed, create test artifacts, notify team about access issues.
+- **NO** \u2192 May genuinely not exist. Apply CRITICAL severity, ask.
 
-| Scenario | Trigger Says | Browser Shows | Classification | Action |
-|----------|-------------|---------------|----------------|--------|
-| Jira says "test premium dashboard", you log in as test_user and don't see it | Feature exists | Can't access | **Execution obstacle** | Create tests, notify team re: missing premium credentials |
-| PR says "verify new settings page", you browse and find no settings page | Feature exists | Can't find | **Execution obstacle** | Create tests, notify team re: possible feature flag/env issue |
-| Manual request "test the settings page", no Jira/PR, you browse and find no settings page | No source claims it | Can't find | **Requirement ambiguity (CRITICAL)** | BLOCK, ask what was meant |
-| Jira says "fix sorting", but doesn't specify sort criteria | Feature exists | Feature exists | **Requirement ambiguity (HIGH)** | BLOCK, ask which sort criteria |
+**Important:** A page loading is NOT the same as the requested functionality existing on it. Evaluate whether the REQUESTED FUNCTIONALITY exists, not just whether a URL resolves. If the page loads but requested features are absent and no authoritative source claims they were built \u2192 CRITICAL ambiguity.
 
-**Partial Feature Existence \u2014 URL found but requested functionality absent:**
-
-A common edge case: a page/route loads successfully, but the SPECIFIC FUNCTIONALITY you were asked to test doesn't exist on it.
-
-**Rule:** Evaluate whether the REQUESTED FUNCTIONALITY exists, not just whether a URL resolves.
-
-| Page Exists | Requested Features Exist | Authoritative Trigger | Classification |
-|-------------|--------------------------|----------------------|----------------|
-| Yes | Yes | Any | Proceed normally |
-| Yes | No | Yes (Jira/PR says features built) | Execution obstacle \u2014 features behind flag/env |
-| Yes | No | No (manual request only) | **Requirement ambiguity (CRITICAL)** \u2014 ask what's expected |
-| No | N/A | Yes | Execution obstacle \u2014 page not deployed yet |
-| No | N/A | No | **Requirement ambiguity (CRITICAL)** \u2014 ask what was meant |
-
-**Example:** Prompt says "Test the checkout payment form with credit card 4111..." You browse to /checkout and find an information form (first name, last name, postal code) but NO payment form, NO shipping options, NO Place Order button. No Jira/PR claims these features exist. \u2192 **CRITICAL requirement ambiguity.** Ask: "I found a checkout information form at /checkout but no payment form or shipping options. Can you clarify what checkout features you'd like tested?"
-
-**Key insight:** Finding a URL is not the same as finding the requested functionality. Do NOT classify this as an "execution obstacle" just because the page loads.
+| Scenario | Trigger Claims Feature | Browser Shows | Classification |
+|----------|----------------------|---------------|----------------|
+| Jira says "test premium dashboard", can't see it | Yes | Can't access | Execution obstacle \u2014 proceed |
+| PR says "verify settings page", no settings page | Yes | Can't find | Execution obstacle \u2014 proceed |
+| Manual request "test settings", no Jira/PR | No | Can't find | CRITICAL ambiguity \u2014 ask |
+| Jira says "fix sorting", no sort criteria | Yes | Feature exists | HIGH ambiguity \u2014 ask |
 
 ### Check Memory for Similar Clarifications
 
-Before asking, check if similar question was answered:
-
-**Process:**
-1. **Query team-communicator memory** - Search by feature name, ambiguity pattern, ticket keywords
-2. **Review past Q&A** - Similar question asked? What was answer? Applicable now?
-3. **Assess reusability:**
-   - Directly applicable \u2192 Use answer, no re-ask
-   - Partially applicable \u2192 Adapt and reference ("Previously for X, clarified Y. Same here?")
-   - Not applicable \u2192 Ask as new
-4. **Update memory** - Store Q&A with task type, feature, pattern tags
-
-**Example:** Query "todo sorting priority" \u2192 Found 2025-01-15: "Should completed todos appear in main list?" \u2192 Answer: "No, move to separate archive view" \u2192 Directly applicable \u2192 Use, no re-ask needed
+Before asking, search memory by feature name, ambiguity pattern, and ticket keywords. If a directly applicable past answer exists, use it without re-asking. If partially applicable, adapt and reference.
 
 ### Formulate Clarification Questions
 
-If clarification needed (CRITICAL/HIGH severity), formulate specific, concrete questions:
-
-**Good Questions:** Specific and concrete, provide context, offer options, reference examples, tie to test strategy
+If clarification needed (CRITICAL/HIGH), formulate specific, concrete questions:
 
-**Bad Questions:** Too vague/broad, assumptive, multiple questions in one, no context
-
-**Template:**
 \`\`\`
 **Context:** [Current understanding]
 **Ambiguity:** [Specific unclear aspect]
 **Question:** [Specific question with options]
 **Why Important:** [Testing strategy impact]
-
-Example:
-Context: TODO-456 "Fix the sorting in the todo list so items appear in the right order"
-Ambiguity: "sorting" = (A) by creation date, (B) by due date, (C) by priority level, or (D) custom user-defined order
-Question: Should todos be sorted by due date (soonest first) or priority (high to low)? Should completed items appear in the list or move to archive?
-Why Important: Different sort criteria require different test assertions. Current app shows 15 active todos + 8 completed in mixed order.
 \`\`\`
 
 ### Communicate Clarification Request
 
-**For Slack-Triggered Tasks:** {{INVOKE_TEAM_COMMUNICATOR}} to ask in thread:
-\`\`\`
-Ask clarification in Slack thread:
-Context: [From ticket/description]
-Ambiguity: [Describe ambiguity]
-Severity: [CRITICAL/HIGH]
-Questions:
-1. [First specific question]
-2. [Second if needed]
-
-Clarification needed to proceed. I'll wait for response before testing.
-\`\`\`
-
-**For Manual/API Triggers:** Include in task output:
-\`\`\`markdown
-## Clarification Required Before Testing
-
-**Ambiguity:** [Description]
-**Severity:** [CRITICAL/HIGH]
-
-### Questions:
-1. **Question:** [First question]
-   - Context: [Provide context]
-   - Options: [If applicable]
-   - Impact: [Testing impact]
+**For Slack-Triggered Tasks:** {{INVOKE_TEAM_COMMUNICATOR}} to ask in thread with context, ambiguity description, severity, and specific questions.
 
-**Action Required:** Provide clarification. Testing cannot proceed.
-**Current Observation:** [What exploration revealed - concrete examples]
-\`\`\`
+**For Manual/API Triggers:** Include a "Clarification Required Before Testing" section in task output with ambiguity, severity, questions with context/options/impact, and current observations.
 
 ### Register Blocked Task (CRITICAL/HIGH only)
 
-When asking a CRITICAL or HIGH severity question that blocks progress, register the task in the blocked queue so it can be automatically re-triggered when clarification arrives.
-
-**Update \`.bugzy/runtime/blocked-task-queue.md\`:**
-
-1. Read the current file (create if doesn't exist)
-2. Add a new row to the Queue table
+When blocked, register in \`.bugzy/runtime/blocked-task-queue.md\`:
 
 \`\`\`markdown
-# Blocked Task Queue
-
-Tasks waiting for clarification responses.
-
 | Task Slug | Question | Original Args |
 |-----------|----------|---------------|
 | generate-test-plan | Should todos be sorted by date or priority? | \`{"ticketId": "TODO-456"}\` |
 \`\`\`
 
-**Entry Fields:**
-- **Task Slug**: The task slug (e.g., \`generate-test-plan\`) - used for re-triggering
-- **Question**: The clarification question asked (so LLM can match responses)
-- **Original Args**: JSON-serialized \`$ARGUMENTS\` wrapped in backticks
-
-**Purpose**: The LLM processor reads this file and matches user responses to pending questions. When a match is found, it re-queues the task with the clarification.
+The LLM processor reads this file and matches user responses to pending questions, then re-queues the task with the clarification.
 
 ### Wait or Proceed Based on Severity
 
-**Use your maturity assessment to adjust thresholds:**
-- **New project**: STOP for CRITICAL + HIGH + MEDIUM
-- **Growing project**: STOP for CRITICAL + HIGH (default)
-- **Mature project**: STOP for CRITICAL only; handle HIGH with documented assumptions
-
 **When severity meets your STOP threshold:**
-- You MUST call team-communicator (Slack) to ask the question \u2014 do NOT just mention it in your text output
+- You MUST call team-communicator to ask \u2014 do NOT just mention it in text output
 - Do NOT create tests, run tests, or make assumptions about the unclear aspect
-- Do NOT silently adapt by working around the issue (e.g., running other tests instead)
+- Do NOT silently adapt by working around the issue
 - Do NOT invent your own success criteria when none are provided
-- Register the blocked task and wait for clarification
-- *Rationale: Wrong assumptions = incorrect tests, false results, wasted time*
+- Register the blocked task and wait
 
-**When severity is below your STOP threshold \u2192 Proceed with Documented Assumptions:**
-- Perform moderate exploration, document assumptions, proceed with creation/execution
-- Ask clarification async (team-communicator), mark results "based on assumptions"
-- Update tests after clarification received
-- *Rationale: Waiting blocks progress; documented assumptions allow forward movement with later corrections*
-
-**LOW \u2192 Always Proceed and Mark:**
-- Proceed with creation/execution, mark gaps [TO BE CLARIFIED] or [ASSUMED]
-- Mention in report but don't prioritize, no blocking
-- *Rationale: Details don't affect strategy/results significantly*
+**When severity is below your STOP threshold:**
+- Perform moderate exploration, document assumptions, proceed
+- Ask clarification async, mark results "based on assumptions"
 
 ### Document Clarification in Results
 
-When reporting test results, always include an "Ambiguities" section if clarification occurred:
-
-\`\`\`markdown
-## Ambiguities Encountered
-
-### Clarification: [Topic]
-- **Severity:** [CRITICAL/HIGH/MEDIUM/LOW]
-- **Question Asked:** [What was asked]
-- **Response:** [Answer received, or "Awaiting response"]
-- **Impact:** [How this affected testing]
-- **Assumption Made:** [If proceeded with assumption]
-- **Risk:** [What could be wrong if assumption is incorrect]
-
-### Resolution:
-[How the clarification was resolved and incorporated into testing]
-\`\`\`
+Include an "Ambiguities Encountered" section in results when clarification occurred, noting severity, question asked, response (or "Awaiting"), impact, assumptions made, and risk.
 
 ---
 
 ## Remember
 
-- **STOP means STOP** - When you hit a STOP threshold, you MUST call team-communicator to ask via Slack. Do NOT silently adapt, skip, or work around the issue
-- **Non-existent features \u2014 check context first** - If a page/feature doesn't exist in the browser, check whether an authoritative trigger (Jira, PR, team request) asserts it exists. If YES \u2192 execution obstacle (proceed with artifact creation, notify team). If NO authoritative source claims it exists \u2192 CRITICAL severity, ask what was meant
-- **Ask correctly > guess poorly** - Specific questions lead to specific answers
-- **Never invent success criteria** - If the task says "improve" or "fix" without metrics, ask what "done" looks like
-- **Check memory first** - Avoid re-asking previously answered questions
-- **Maturity adjusts threshold, not judgment** - Even in mature projects, CRITICAL always triggers a question`,
+- **STOP means STOP** \u2014 When you hit a STOP threshold, you MUST call team-communicator. Do NOT silently adapt or work around the issue
+- **Non-existent features \u2014 check context first** \u2014 If a feature doesn't exist in browser, check whether an authoritative trigger asserts it exists. YES \u2192 execution obstacle (proceed). NO \u2192 CRITICAL severity, ask.
+- **Never invent success criteria** \u2014 If the task says "improve" or "fix" without metrics, ask what "done" looks like
+- **Check memory first** \u2014 Avoid re-asking previously answered questions
+- **Maturity adjusts threshold, not judgment** \u2014 CRITICAL always triggers a question`,
   tags: ["clarification", "protocol", "ambiguity"]
 };
 
@@ -6898,7 +5682,19 @@ After analyzing test results, triage each failure to determine if it's a product
 
 **IMPORTANT: Do NOT report bugs without triaging first.**
 
-For each failed test:
+### 1. Check Failure Classification
+
+**Before triaging any failure**, read \`new_failures\` from the latest \`test-runs/*/manifest.json\`:
+
+| \`new_failures\` State | Action |
+|------------------------|--------|
+| Non-empty array | Only triage failures listed in \`new_failures\`. Do not investigate, fix, or create issues for \`known_failures\`. |
+| Empty array | No new failures to triage. Output "0 new failures to triage" and skip the rest of this step. |
+| Field missing | Fall back: triage all failed tests (backward compatibility with older reporter versions). |
+
+### 2. Triage Each Failure
+
+For each failed test (from \`new_failures\` or all failures if field is missing):
 
 1. **Read failure details** from JSON report (error message, stack trace)
 2. **Classify the failure:**
@@ -6927,14 +5723,22 @@ For each failed test:
 - Broken navigation flows
 - Validation not working as expected
 
-**Document Classification:**
+### 3. Document Results
+
 \`\`\`markdown
-### Failure Triage
+### Failure Triage Summary
+
+**New failures triaged: N** | **Known failures skipped: M**
 
 | Test ID | Test Name | Classification | Reason |
 |---------|-----------|---------------|--------|
 | TC-001 | Login test | TEST ISSUE | Selector brittle - uses CSS instead of role |
 | TC-002 | Checkout | PRODUCT BUG | 500 error on form submit |
+
+#### Skipped Known Failures
+| Test ID | Test Name | Last Passed Run |
+|---------|-----------|-----------------|
+| TC-003 | Search | 20260210-103045 |
 \`\`\``,
   tags: ["execution", "triage", "analysis"]
 };
@@ -7492,10 +6296,36 @@ npx tsx reporters/parse-results.ts --input <file-or-url> [--timestamp <existing>
         }
       ]
     }
+  ],
+  "new_failures": [
+    {
+      "id": "<test case id>",
+      "name": "<test name>",
+      "error": "<error message or null>",
+      "lastPassedRun": "<timestamp of last passing run or null>"
+    }
+  ],
+  "known_failures": [
+    {
+      "id": "<test case id>",
+      "name": "<test name>",
+      "error": "<error message or null>",
+      "lastPassedRun": null
+    }
   ]
 }
 \`\`\`
-4. For each failed test, create:
+4. **Classify failures** \u2014 after building the manifest, classify each failed test as new or known:
+   - Read \`BUGZY_FAILURE_LOOKBACK\` env var (default: 5)
+   - List previous \`test-runs/*/manifest.json\` files sorted by timestamp descending (skip current run)
+   - For each failed test in the manifest:
+     - If it passed in any of the last N runs \u2192 \`new_failures\` (include the timestamp of the last passing run in \`lastPassedRun\`)
+     - If it failed in ALL of the last N runs \u2192 \`known_failures\`
+     - If the test doesn't exist in any previous run \u2192 \`new_failures\` (new test)
+     - If no previous runs exist at all (first run) \u2192 all failures go to \`new_failures\`
+   - Write the \`new_failures\` and \`known_failures\` arrays into the manifest
+
+5. For each failed test, create:
    - Directory: \`test-runs/{timestamp}/{testCaseId}/exec-1/\`
    - File: \`test-runs/{timestamp}/{testCaseId}/exec-1/result.json\` containing:
 \`\`\`json
@@ -7507,8 +6337,8 @@ npx tsx reporters/parse-results.ts --input <file-or-url> [--timestamp <existing>
   "testFile": "<file path if available>"
 }
 \`\`\`
-5. Print the manifest path to stdout
-6. Exit code 0 on success, non-zero on failure
+6. Print the manifest path to stdout
+7. Exit code 0 on success, non-zero on failure
 
 **Incremental mode** (\`--timestamp\` + \`--test-id\` provided):
 1. Read existing \`test-runs/{timestamp}/manifest.json\`