@bugzy-ai/bugzy 1.2.0

package/dist/tasks/index.js

@@ -0,0 +1,3431 @@
+// src/tasks/constants.ts
+var TASK_SLUGS = {
+  EXPLORE_APPLICATION: "explore-application",
+  GENERATE_TEST_CASES: "generate-test-cases",
+  GENERATE_TEST_PLAN: "generate-test-plan",
+  HANDLE_MESSAGE: "handle-message",
+  PROCESS_EVENT: "process-event",
+  RUN_TESTS: "run-tests",
+  VERIFY_CHANGES: "verify-changes"
+};
+
+// src/tasks/templates/exploration-instructions.ts
+var EXPLORATION_INSTRUCTIONS = `
+## 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.
+
+### Step {{STEP_NUMBER}}.1: 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."
+
+### Step {{STEP_NUMBER}}.2: Quick Exploration (1-2 min)
+
+**When:** Requirements CLEAR
+
+**Steps:**
+1. Navigate to feature (use provided URL), verify 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
+
+### Step {{STEP_NUMBER}}.3: 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
+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]
+   \`\`\`
+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
+
+### Step {{STEP_NUMBER}}.4: 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
+
+### Step {{STEP_NUMBER}}.5: 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)?"
+\`\`\`
+
+### Step {{STEP_NUMBER}}.6: 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]
+
+### Artifacts: Screenshots: [list], Video: [if captured], Notes: [detailed]
+\`\`\`
+
+**Memory Storage:** Feature behavior patterns, common ambiguity types, resolution approaches
+
+### Step {{STEP_NUMBER}}.7: 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
+
+\`\`\`
+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
+\`\`\`
+
+---
+
+## Remember:
+
+\u{1F50D} **Explore before assuming** | \u{1F4CA} **Concrete observations > abstract interpretation** | \u23F1\uFE0F **Adaptive depth: time \u221D uncertainty** | \u{1F3AF} **Exploration findings \u2192 specific clarifications** | \u{1F4DD} **Always document** | \u{1F517} **Link exploration \u2192 ambiguity \u2192 clarification**
+`;
+
+// src/tasks/templates/knowledge-base.ts
+var KNOWLEDGE_BASE_READ_INSTRUCTIONS = `
+## Knowledge Base Context
+
+Before proceeding, read the curated knowledge base to inform your work:
+
+**Location:** \`.bugzy/runtime/knowledge-base.md\`
+
+**Purpose:** The knowledge base is a living collection of factual knowledge - what we currently know and believe to be true about this project, its patterns, and its context. This is NOT a historical log, but a curated snapshot that evolves as understanding improves.
+
+**How to Use:**
+1. Read the knowledge base to understand:
+   - Project-specific patterns and conventions
+   - Known behaviors and system characteristics
+   - Relevant context from past work
+   - Documented decisions and approaches
+
+2. Apply this knowledge to:
+   - Make informed decisions aligned with project patterns
+   - Avoid repeating past mistakes
+   - Build on existing understanding
+   - Maintain consistency with established practices
+
+**Note:** The knowledge base may not exist yet or may be empty. If it doesn't exist or is empty, proceed without this context and help build it as you work.
+`;
+var KNOWLEDGE_BASE_UPDATE_INSTRUCTIONS = `
+## Knowledge Base Maintenance
+
+After completing your work, update the knowledge base with new insights.
+
+**Location:** \`.bugzy/runtime/knowledge-base.md\`
+
+**Process:**
+
+1. **Read the maintenance guide** at \`.bugzy/runtime/knowledge-maintenance-guide.md\` to understand when to ADD, UPDATE, or REMOVE entries and how to maintain a curated knowledge base (not an append-only log)
+
+2. **Review the current knowledge base** to check for overlaps, contradictions, or opportunities to consolidate existing knowledge
+
+3. **Update the knowledge base** following the maintenance guide principles: favor consolidation over addition, update rather than append, resolve contradictions immediately, and focus on quality over completeness
+
+**Remember:** Every entry should answer "Will this help someone working on this project in 6 months?"
+`;
+
+// src/tasks/library/explore-application.ts
+var exploreApplicationTask = {
+  slug: TASK_SLUGS.EXPLORE_APPLICATION,
+  name: "Explore Application",
+  description: "Systematically explore application to discover UI elements, workflows, and behaviors",
+  frontmatter: {
+    description: "Systematically explore application to discover UI elements, workflows, and behaviors",
+    "argument-hint": "--focus [area] --depth [shallow|deep] --system [system-name]"
+  },
+  baseContent: `# Explore Application Command
+
+## SECURITY NOTICE
+**CRITICAL**: Never read the \`.env\` file. It contains ONLY secrets (passwords, API keys).
+- **Read \`.env.testdata\`** for non-secret environment variables (TEST_BASE_URL, TEST_OWNER_EMAIL, etc.)
+- \`.env.testdata\` contains actual values for test data, URLs, and non-sensitive configuration
+- For secrets: Reference variable names only (TEST_OWNER_PASSWORD) - values are injected at runtime
+- The \`.env\` file access is blocked by settings.json
+
+Systematically explore the application using the test-runner agent to discover actual UI elements, workflows, and behaviors. Updates test plan and project documentation with findings.
+
+## Arguments
+Arguments: $ARGUMENTS
+
+## Parse Arguments
+Extract the following from arguments:
+- **focus**: Specific area to explore (authentication, navigation, search, content, admin)
+- **depth**: Exploration depth - shallow (quick discovery) or deep (comprehensive) - defaults to deep
+- **system**: Which system to explore (optional for multi-system setups)
+
+${KNOWLEDGE_BASE_READ_INSTRUCTIONS}
+
+## Process
+
+### Step 0: Understand Exploration Protocol
+
+This task implements the exploration protocol defined in the exploration-instructions template.
+
+**Purpose**: This task provides the infrastructure for systematic application exploration that is referenced by other tasks (generate-test-plan, generate-test-cases, verify-changes) when they need to explore features before proceeding.
+
+**Depth Alignment**: The depth levels in this task align with the exploration template:
+- **Shallow exploration (15-20 min)** implements the quick/moderate exploration from the template
+- **Deep exploration (45-60 min)** implements comprehensive deep exploration from the template
+
+The depth levels are extended for full application exploration compared to the focused feature exploration used in other tasks.
+
+**Full Exploration Protocol Reference**:
+
+${EXPLORATION_INSTRUCTIONS}
+
+**Note**: This task extends the protocol for comprehensive application-wide exploration, while other tasks use abbreviated versions for targeted feature exploration.
+
+### Step 1: Load Environment and Context
+
+#### 1.1 Check Environment Variables
+Read \`.env.testdata\` file to understand what variables are required:
+- TEST_BASE_URL or TEST_MOBILE_BASE_URL (base URL variable names)
+- [SYSTEM_NAME]_URL (if multi-system setup)
+- Authentication credential variable names for the selected system
+- Any test data variable names
+
+Note: The actual values will be read from the user's \`.env\` file at test execution time.
+Verify \`.env.testdata\` exists to understand variable structure. If it doesn't exist, notify user to create it based on test plan.
+
+#### 1.2 Read Current Test Plan
+Read \`test-plan.md\` to:
+- Identify sections marked with [TO BE EXPLORED]
+- Find features requiring discovery
+- Understand testing scope and priorities
+
+#### 1.3 Read Project Context
+Read \`.bugzy/runtime/project-context.md\` for:
+- System architecture understanding
+- Testing environment details
+- QA workflow requirements
+
+### Step 2: Prepare Exploration Strategy
+
+Based on the arguments and context, prepare exploration instructions.
+
+#### 2.1 Focus Area Strategies
+
+**If focus is "authentication":**
+\`\`\`
+1. Navigate to the application homepage
+2. Locate and document all authentication entry points:
+   - Login button/link location and selector
+   - Registration option and flow
+   - Social login options (Facebook, Google, etc.)
+3. Test login flow:
+   - Document form fields and validation
+   - Test error states with invalid credentials
+   - Verify successful login indicators
+4. Test logout functionality:
+   - Find logout option
+   - Verify session termination
+   - Check redirect behavior
+5. Explore password recovery:
+   - Locate forgot password link
+   - Document recovery flow
+   - Note email/SMS options
+6. Check role-based access:
+   - Identify user role indicators
+   - Document permission differences
+   - Test admin/moderator access if available
+7. Test session persistence:
+   - Check remember me functionality
+   - Test timeout behavior
+   - Verify multi-tab session handling
+\`\`\`
+
+**If focus is "navigation":**
+\`\`\`
+1. Document main navigation structure:
+   - Primary menu items and hierarchy
+   - Mobile menu behavior
+   - Footer navigation links
+2. Map URL patterns:
+   - Category URL structure
+   - Parameter patterns
+   - Deep linking support
+3. Test breadcrumb navigation:
+   - Availability on different pages
+   - Clickability and accuracy
+   - Mobile display
+4. Explore category system:
+   - Main categories and subcategories
+   - Navigation between levels
+   - Content organization
+5. Document special sections:
+   - User profiles
+   - Admin areas
+   - Help/Support sections
+6. Test browser navigation:
+   - Back/forward button behavior
+   - History management
+   - State preservation
+\`\`\`
+
+**If focus is "search":**
+\`\`\`
+1. Locate search interfaces:
+   - Main search bar
+   - Advanced search options
+   - Category-specific search
+2. Document search features:
+   - Autocomplete/suggestions
+   - Search filters
+   - Sort options
+3. Test search functionality:
+   - Special character handling
+   - Empty/invalid queries
+4. Analyze search results:
+   - Result format and layout
+   - Pagination
+   - No results handling
+5. Check search performance:
+   - Response times
+   - Result relevance
+   - Load more/infinite scroll
+\`\`\`
+
+**If no focus specified:**
+Use comprehensive exploration covering all major areas.
+
+#### 2.2 Depth Configuration
+
+**Implementation Note**: These depths implement the exploration protocol defined in exploration-instructions.ts, extended for full application exploration.
+
+**Shallow exploration (--depth shallow):**
+- Quick discovery pass (15-20 minutes)
+- Focus on main features only
+- Basic screenshot capture
+- High-level findings
+- *Aligns with Quick/Moderate exploration from template*
+
+**Deep exploration (--depth deep or default):**
+- Comprehensive exploration (45-60 minutes)
+- Test edge cases and variations
+- Extensive screenshot documentation
+- Detailed technical findings
+- Performance observations
+- Accessibility notes
+- *Aligns with Deep exploration from template*
+
+### Step 3: Execute Exploration
+
+#### 3.1 Create Exploration Test Case
+Generate a temporary exploration test case file at \`./test-cases/EXPLORATION-TEMP.md\`:
+
+\`\`\`markdown
+---
+id: EXPLORATION-TEMP
+title: Application Exploration - [Focus Area or Comprehensive]
+type: exploratory
+priority: high
+---
+
+## Preconditions
+- Browser with cleared cookies and cache
+- Access to [system] environment
+- Credentials configured per .env.testdata template
+
+## Test Steps
+[Generated exploration steps based on strategy]
+
+## Expected Results
+Document all findings including:
+- UI element locations and selectors
+- Navigation patterns and URLs
+- Feature behaviors and workflows
+- Performance observations
+- Error states and edge cases
+- Screenshots of all key areas
+\`\`\`
+
+#### 3.2 Launch Test Runner Agent
+Invoke the test-runner agent with special exploration instructions:
+
+\`\`\`
+Execute the exploration test case at ./test-cases/EXPLORATION-TEMP.md with focus on discovery and documentation.
+
+Special instructions for exploration mode:
+1. Take screenshots of EVERY significant UI element and page
+2. Document all clickable elements with their selectors
+3. Note all URL patterns and parameters
+4. Test variations and edge cases where possible
+5. Document load times and performance observations
+6. Create detailed findings report with structured data
+7. Organize screenshots by functional area
+8. Note any console errors or warnings
+9. Document which features are accessible vs restricted
+
+Generate a comprehensive exploration report that can be used to update project documentation.
+\`\`\`
+
+### Step 4: Process Exploration Results
+
+#### 4.1 Read Test Runner Output
+Read the generated test run files from \`./test-runs/[timestamp]/EXPLORATION-TEMP/\`:
+- \`findings.md\` - Main findings document
+- \`test-log.md\` - Detailed step execution
+- \`screenshots/\` - Visual documentation
+- \`summary.json\` - Execution summary
+
+#### 4.2 Parse and Structure Findings
+Extract and organize:
+- Discovered features and capabilities
+- UI element selectors and patterns
+- Navigation structure and URLs
+- Authentication flow details
+- Performance metrics
+- Technical observations
+- Areas requiring further investigation
+
+### Step 5: Update Project Artifacts
+
+#### 5.1 Update Test Plan
+Read and update \`test-plan.md\`:
+- Replace [TO BE EXPLORED] markers with concrete findings
+- Add newly discovered features to test items
+- Update navigation patterns and URL structures
+- Document actual authentication methods
+- Update environment variables if new ones discovered
+- Refine pass/fail criteria based on actual behavior
+
+#### 5.2 Create Exploration Report
+Create \`./exploration-reports/[timestamp]-[focus]-exploration.md\`
+
+### Step 6: Cleanup
+
+#### 6.1 Remove Temporary Files
+Delete the temporary exploration test case:
+\`\`\`bash
+rm ./test-cases/EXPLORATION-TEMP.md
+\`\`\`
+
+### Step 7: Generate Summary Report
+Create a concise summary for the user
+
+## Error Handling
+
+### Environment Issues
+- If \`.env.testdata\` missing: Warn user and suggest creating it from test plan
+- If credentials invalid (at runtime): Document in report and continue with public areas
+- If system unreachable: Retry with exponential backoff, report if persistent
+
+### Exploration Failures
+- If test-runner fails: Capture partial results and report
+- If specific area inaccessible: Note in findings and continue
+- If browser crashes: Attempt recovery and resume
+- If test-runner stops, but does not create files, inspect what it did and if it was not enough remove the test-run and start the test-runner agent again. If it has enough info, continue with what you have.
+
+### Data Issues
+- If dynamic content prevents exploration: Note and try alternative approaches
+- If rate limited: Implement delays and retry
+
+## Integration with Other Commands
+
+### Feeds into /generate-test-cases
+- Provides actual UI elements for test steps
+- Documents real workflows for test scenarios
+- Identifies edge cases to test
+
+### Updates from /process-event
+- New exploration findings can be processed as events
+- Discovered bugs trigger issue creation
+- Feature discoveries update test coverage
+
+### Enhances /run-tests
+- Tests use discovered selectors
+- Validation based on actual behavior
+- More reliable test execution
+
+${KNOWLEDGE_BASE_UPDATE_INSTRUCTIONS}`,
+  optionalSubagents: [],
+  requiredSubagents: ["test-runner"]
+};
+
+// src/tasks/templates/clarification-instructions.ts
+var CLARIFICATION_INSTRUCTIONS = `
+## 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.
+
+### Step {{STEP_NUMBER}}.0: 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.
+
+### Step {{STEP_NUMBER}}.1: 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
+
+**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?
+
+### Step {{STEP_NUMBER}}.2: Assess Severity
+
+If ambiguity is detected, assess its severity:
+
+| Severity | Characteristics | Examples | Action |
+|----------|----------------|----------|--------|
+| \u{1F534} **CRITICAL** | Expected behavior undefined/contradictory; test outcome unpredictable; core functionality unclear; success criteria missing; multiple interpretations = different strategies | "Fix the issue" (what issue?), "Improve performance" (which metrics?), "Fix sorting in todo list" (by date? priority? completion status?) | **STOP** - Seek clarification before proceeding |
+| \u{1F7E0} **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** - Seek clarification before proceeding |
+| \u{1F7E1} **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] |
+| \u{1F7E2} **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 |
+
+### Step {{STEP_NUMBER}}.3: 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
+
+### Step {{STEP_NUMBER}}.4: 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
+
+**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.
+\`\`\`
+
+### Step {{STEP_NUMBER}}.5: Communicate Clarification Request
+
+**For Slack-Triggered Tasks:** Use team-communicator subagent:
+\`\`\`
+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
+## \u26A0\uFE0F Clarification Required Before Testing
+
+**Ambiguity:** [Description]
+**Severity:** [CRITICAL/HIGH]
+
+### Questions:
+1. **Question:** [First question]
+   - Context: [Provide context]
+   - Options: [If applicable]
+   - Impact: [Testing impact]
+
+**Action Required:** Provide clarification. Testing cannot proceed.
+**Current Observation:** [What exploration revealed - concrete examples]
+\`\`\`
+
+### Step {{STEP_NUMBER}}.5.1: 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
+
+\`\`\`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.
+
+### Step {{STEP_NUMBER}}.6: Wait or Proceed Based on Severity
+
+**CRITICAL/HIGH \u2192 STOP and Wait:**
+- Do NOT create tests, run tests, or make assumptions
+- Wait for clarification, resume after answer
+- *Rationale: Wrong assumptions = incorrect tests, false results, wasted time*
+
+**MEDIUM \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 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*
+
+### Step {{STEP_NUMBER}}.7: 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]
+\`\`\`
+
+---
+
+## Remember:
+
+\u{1F6D1} **Block for CRITICAL/HIGH** | \u2705 **Ask correctly > guess poorly** | \u{1F4DD} **Document MEDIUM assumptions** | \u{1F50D} **Check memory first** | \u{1F3AF} **Specific questions \u2192 specific answers**
+`;
+
+// src/tasks/library/generate-test-cases.ts
+var generateTestCasesTask = {
+  slug: TASK_SLUGS.GENERATE_TEST_CASES,
+  name: "Generate Test Cases",
+  description: "Generate manual test case documentation AND automated Playwright test scripts from test plan",
+  frontmatter: {
+    description: "Generate manual test case documentation AND automated Playwright test scripts from test plan",
+    "argument-hint": "--type [exploratory|functional|regression|smoke] --focus [optional-feature]"
+  },
+  baseContent: `# Generate Test Cases Command
+
+## SECURITY NOTICE
+**CRITICAL**: Never read the \`.env\` file. It contains ONLY secrets (passwords, API keys).
+- **Read \`.env.testdata\`** for non-secret test data (TEST_BASE_URL, TEST_OWNER_EMAIL, etc.)
+- \`.env.testdata\` contains actual values for test data, URLs, and non-sensitive configuration
+- For secrets: Reference variable names only (TEST_OWNER_PASSWORD) - values are injected at runtime
+- The \`.env\` file access is blocked by settings.json
+
+Generate comprehensive test artifacts including BOTH manual test case documentation AND automated Playwright test scripts.
+
+## Overview
+
+This command generates:
+1. **Manual Test Case Documentation** (in \`./test-cases/\`) - Human-readable test cases in markdown format
+2. **Automated Playwright Tests** (in \`./tests/specs/\`) - Executable TypeScript test scripts
+3. **Page Object Models** (in \`./tests/pages/\`) - Reusable page classes for automated tests
+4. **Supporting Files** (fixtures, helpers, components) - As needed for test automation
+
+## Arguments
+Arguments: $ARGUMENTS
+
+## Parse Arguments
+Extract the following from arguments:
+- **type**: Test type (exploratory, functional, regression, smoke) - defaults to functional
+- **focus**: Optional specific feature or section to focus on
+
+${KNOWLEDGE_BASE_READ_INSTRUCTIONS}
+
+## Process
+
+### Step 1: Gather Context
+
+#### 1.1 Read Test Plan
+Read the test plan from \`test-plan.md\` to understand:
+- Test items and features
+- Testing approach and automation strategy
+- Test Automation Strategy section (automated vs exploratory)
+- Pass/fail criteria
+- Test environment and data requirements
+- Automation decision criteria
+
+#### 1.2 Check Existing Test Cases and Tests
+- List all files in \`./test-cases/\` to understand existing manual test coverage
+- List all files in \`./tests/specs/\` to understand existing automated tests
+- Determine next test case ID (TC-XXX format)
+- Identify existing Page Objects in \`./tests/pages/\`
+- Avoid creating overlapping test cases or duplicate automation
+
+{{DOCUMENTATION_RESEARCHER_INSTRUCTIONS}}
+
+### Step 1.4: Explore Features (If Needed)
+
+If documentation is insufficient or ambiguous, perform adaptive exploration to understand actual feature behavior before creating test cases.
+
+${EXPLORATION_INSTRUCTIONS.replace(/{{STEP_NUMBER}}/g, "1.4")}
+
+### Step 1.5: Clarify Ambiguities
+
+If exploration or documentation review reveals ambiguous requirements, use the clarification protocol to resolve them before generating test cases.
+
+${CLARIFICATION_INSTRUCTIONS.replace(/{{STEP_NUMBER}}/g, "1.5")}
+
+**Important Notes:**
+- **CRITICAL/HIGH ambiguities:** STOP test case generation and seek clarification
+- **MEDIUM ambiguities:** Document assumptions explicitly in test case with [ASSUMED: reason]
+- **LOW ambiguities:** Mark with [TO BE CLARIFIED: detail] in test case notes section
+
+### Step 1.6: Organize Test Scenarios by Area
+
+Based on exploration and documentation, organize test scenarios by feature area/component:
+
+**Group scenarios into areas** (e.g., Authentication, Dashboard, Checkout, Profile Management):
+- Each area should be a logical feature grouping
+- Areas should be relatively independent for parallel test execution
+- Consider the application's navigation structure and user flows
+
+**For each area, identify scenarios**:
+
+1. **Critical User Paths** (must automate as smoke tests):
+   - Login/authentication flows
+   - Core feature workflows
+   - Data creation/modification flows
+   - Critical business transactions
+
+2. **Happy Path Scenarios** (automate for regression):
+   - Standard user workflows
+   - Common use cases
+   - Typical data entry patterns
+
+3. **Error Handling Scenarios** (evaluate automation ROI):
+   - Validation error messages
+   - Network error handling
+   - Permission/authorization errors
+
+4. **Edge Cases** (consider manual testing):
+   - Rare scenarios (<1% occurrence)
+   - Complex exploratory scenarios
+   - Visual/UX validation requiring judgment
+   - Features in heavy flux
+
+**Output**: Test scenarios organized by area with automation decisions for each
+
+Example structure:
+- **Authentication**: TC-001 Valid login (smoke, automate), TC-002 Invalid password (automate), TC-003 Password reset (automate)
+- **Dashboard**: TC-004 View dashboard widgets (smoke, automate), TC-005 Filter data by date (automate), TC-006 Export data (manual - rare use)
+
+### Step 1.7: Generate All Manual Test Case Files
+
+Generate ALL manual test case markdown files in the \`./test-cases/\` directory BEFORE invoking the test-code-generator agent.
+
+**For each test scenario from Step 1.6:**
+
+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 from Step 1.6)
+   - \`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
+
+### Step 2: Automate Test Cases Area by Area
+
+**IMPORTANT**: Process each feature area separately to enable incremental, focused test creation.
+
+**For each area from Step 1.6**, invoke the test-code-generator agent:
+
+#### Step 2.1: Prepare Area Context
+
+Before invoking the agent, identify the test cases for the current area:
+- Current area name
+- Test case files for this area (e.g., TC-001-valid-login.md, TC-002-invalid-password.md)
+- Which test cases are marked for automation (automated: true)
+- Test type: {type}
+- Test plan reference: test-plan.md
+- Existing automated tests in ./tests/specs/
+- Existing Page Objects in ./tests/pages/
+
+#### Step 2.2: Invoke test-code-generator Agent
+
+Use the test-code-generator agent for the current area with the following context:
+
+**Agent Invocation:**
+"Use the test-code-generator agent to automate test cases for the [AREA_NAME] area.
+
+**Context:**
+- Area: [AREA_NAME]
+- Manual test case files to automate: [list TC-XXX files marked with automated: true]
+- Test type: {type}
+- Test plan: test-plan.md
+- Manual test cases directory: ./test-cases/
+- Existing automated tests: ./tests/specs/
+- Existing Page Objects: ./tests/pages/
+
+**The agent should:**
+1. Read the manual test case files for this area
+2. Check existing Page Object infrastructure for this area
+3. Explore the feature area to understand implementation (gather selectors, URLs, flows)
+4. Build missing Page Objects and supporting code
+5. For each test case marked \`automated: true\`:
+   - Create automated Playwright test in ./tests/specs/
+   - Update the manual test case file to reference the automated test path
+6. Run and iterate on each test until it passes or fails with a product bug
+8. Update .env.testdata with any new variables
+
+**Focus only on the [AREA_NAME] area** - do not automate tests for other areas yet."
+
+#### Step 2.3: Verify Area Completion
+
+After the agent completes the area, verify:
+- Manual test case files updated with automated_test references
+- Automated tests created for all test cases marked automated: true
+- Tests are passing (or failing with documented product bugs)
+- Page Objects created/updated for the area
+
+#### Step 2.4: Repeat for Next Area
+
+Move to the next area and repeat Steps 2.1-2.3 until all areas are complete.
+
+**Benefits of area-by-area approach**:
+- Agent focuses on one feature at a time
+- POMs built incrementally as needed
+- Tests verified before moving to next area
+- Easier to manage and track progress
+- Can pause/resume between areas if needed
+
+### Step 2.5: Validate Generated Artifacts
+
+After the test-code-generator completes, verify:
+
+1. **Manual Test Cases (in \`./test-cases/\`)**:
+   - Each has unique TC-XXX ID
+   - Frontmatter includes \`automated: true/false\` flag
+   - If automated, includes \`automated_test\` path reference
+   - Contains human-readable steps and expected results
+   - References environment variables for test data
+
+2. **Automated Tests (in \`./tests/specs/\`)**:
+   - Organized by feature in subdirectories
+   - Each test file references manual test case ID in comments
+   - Uses Page Object Model pattern
+   - Follows role-based selector priority
+   - Uses environment variables for test data
+   - Includes proper TypeScript typing
+
+3. **Page Objects (in \`./tests/pages/\`)**:
+   - Extend BasePage class
+   - Use semantic selectors (getByRole, getByLabel, getByText)
+   - Contain only actions, no assertions
+   - Properly typed with TypeScript
+
+4. **Supporting Files**:
+   - Fixtures created for common setup (in \`./tests/fixtures/\`)
+   - Helper functions for data generation (in \`./tests/helpers/\`)
+   - Component objects for reusable UI elements (in \`./tests/components/\`)
+   - Types defined as needed (in \`./tests/types/\`)
+
+### Step 3: Create Directories if Needed
+
+Ensure required directories exist:
+\`\`\`bash
+mkdir -p ./test-cases
+mkdir -p ./tests/specs
+mkdir -p ./tests/pages
+mkdir -p ./tests/components
+mkdir -p ./tests/fixtures
+mkdir -p ./tests/helpers
+\`\`\`
+
+### Step 4: Update .env.testdata (if needed)
+
+If new environment variables were introduced:
+- Read current \`.env.testdata\`
+- Add new TEST_* variables with empty values
+- Group variables logically with comments
+- Document what each variable is for
+
+${KNOWLEDGE_BASE_UPDATE_INSTRUCTIONS}
+
+{{TEAM_COMMUNICATOR_INSTRUCTIONS}}
+
+### Step 5: Final Summary
+
+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: \`npx playwright test\`
+- Instructions to run specific test file
+- 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 (Step 1.7), then automate area-by-area (Step 2)
+- **Ambiguity Handling**: Use exploration (Step 1.4) and clarification (Step 1.5) 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`,
+  optionalSubagents: [
+    {
+      role: "documentation-researcher",
+      contentBlock: `#### 1.4 Gather Product Documentation
+
+Use the documentation-researcher agent to gather comprehensive product documentation:
+
+\`\`\`
+Use the documentation-researcher agent to explore all available product documentation, specifically focusing on:
+- UI elements and workflows
+- User interactions and navigation paths
+- Form fields and validation rules
+- Error messages and edge cases
+- Authentication and authorization flows
+- Business rules and constraints
+- API endpoints for test data setup
+\`\`\``
+    },
+    {
+      role: "team-communicator",
+      contentBlock: `### Step 4.5: Team Communication
+
+Use the team-communicator agent to notify the product team about the new test cases and automated tests:
+
+\`\`\`
+Use the team-communicator agent to:
+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: npx playwright test
+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`
+    }
+  ],
+  requiredSubagents: ["test-runner", "test-code-generator"]
+};
+
+// src/tasks/library/generate-test-plan.ts
+var generateTestPlanTask = {
+  slug: TASK_SLUGS.GENERATE_TEST_PLAN,
+  name: "Generate Test Plan",
+  description: "Generate a comprehensive test plan from product description",
+  frontmatter: {
+    description: "Generate a comprehensive test plan from product description",
+    "argument-hint": "<product-description>"
+  },
+  baseContent: `# Generate Test Plan Command
+
+## SECURITY NOTICE
+**CRITICAL**: Never read the \`.env\` file. It contains ONLY secrets (passwords, API keys).
+- **Read \`.env.testdata\`** for non-secret test data (TEST_BASE_URL, TEST_OWNER_EMAIL, etc.)
+- \`.env.testdata\` contains actual values for test data, URLs, and non-sensitive configuration
+- For secrets: Reference variable names only (TEST_OWNER_PASSWORD) - values are injected at runtime
+- The \`.env\` file access is blocked by settings.json
+
+Generate a comprehensive test plan from product description following the Brain Module specifications.
+
+## Arguments
+Product description: $ARGUMENTS
+
+${KNOWLEDGE_BASE_READ_INSTRUCTIONS}
+
+## Process
+
+### Step 1: Load project context
+Read \`.bugzy/runtime/project-context.md\` to understand:
+- Project overview and key platform features
+- SDLC methodology and sprint duration
+- Testing environment and goals
+- Technical stack and constraints
+- QA workflow and processes
+
+### Step 1.5: Process the product description
+Use the product description provided directly in the arguments, enriched with project context understanding.
+
+### Step 1.6: Initialize environment variables tracking
+Create a list to track all TEST_ prefixed environment variables discovered throughout the process.
+
+{{DOCUMENTATION_RESEARCHER_INSTRUCTIONS}}
+
+### Step 1.7: Explore Product (If Needed)
+
+If product description is vague or incomplete, perform adaptive exploration to understand actual product features and behavior.
+
+${EXPLORATION_INSTRUCTIONS.replace(/{{STEP_NUMBER}}/g, "1.7")}
+
+### Step 1.8: Clarify Ambiguities
+
+If exploration or product description reveals ambiguous requirements, use the clarification protocol before generating the test plan.
+
+${CLARIFICATION_INSTRUCTIONS.replace(/{{STEP_NUMBER}}/g, "1.8")}
+
+**Important Notes:**
+- **CRITICAL/HIGH ambiguities:** STOP test plan generation and seek clarification
+  - Examples: Undefined core features, unclear product scope, contradictory requirements
+- **MEDIUM ambiguities:** Document assumptions in test plan with [ASSUMED: reason] and seek async clarification
+  - Examples: Missing field lists, unclear validation rules, vague user roles
+- **LOW ambiguities:** Mark with [TO BE EXPLORED: detail] in test plan for future investigation
+  - Examples: Optional features, cosmetic details, non-critical edge cases
+
+### Step 3: Prepare the test plan generation context
+
+**After ensuring requirements are clear through exploration and clarification:**
+
+Based on the gathered information:
+- **goal**: Extract the main purpose and objectives from all available documentation
+- **knowledge**: Combine product description with discovered documentation insights
+- **testPlan**: Use the standard test plan template structure, enriched with documentation findings
+- **gaps**: Identify areas lacking documentation that will need exploration
+
+### Step 4: Generate the test plan using the prompt template
+
+You are an expert QA Test Plan Writer with expertise in both manual and automated testing strategies. Using the gathered information and context from the product description provided, you will now produce a comprehensive test plan in Markdown format that includes an automation strategy.
+
+Writing Instructions:
+- **Use Product Terminology:** Incorporate exact terms and labels from the product description for features and UI elements (to ensure the test plan uses official naming).
+- **Testing Scope:** The plan covers both automated E2E testing via Playwright and exploratory manual testing. Focus on what a user can do and see in a browser.
+- **Test Data - IMPORTANT:**
+  - DO NOT include test data values in the test plan body
+  - Test data goes ONLY to the \`.env.testdata\` file
+  - In the test plan, reference \`.env.testdata\` for test data requirements
+  - Define test data as environment variables prefixed with TEST_ (e.g., TEST_BASE_URL, TEST_USER_EMAIL, TEST_USER_PASSWORD)
+  - DO NOT GENERATE VALUES FOR THE ENV VARS, ONLY THE KEYS
+  - Track all TEST_ variables for extraction to .env.testdata in Step 7
+- **DO NOT INCLUDE TEST SCENARIOS**
+- **Incorporate All Relevant Info:** If the product description mentions specific requirements, constraints, or acceptance criteria (such as field validations, role-based access rules, important parameters), make sure these are reflected in the test plan. Do not add anything not supported by the given information.
+- **Test Automation Strategy Section - REQUIRED:** Include a comprehensive "Test Automation Strategy" section with the following subsections:
+
+  **## Test Automation Strategy**
+
+  ### Automated Test Coverage
+  - Identify critical user paths to automate (login, checkout, core features)
+  - Define regression test scenarios for automation
+  - Specify API endpoints that need automated testing
+  - List smoke test scenarios for CI/CD pipeline
+
+  ### Exploratory Testing Areas
+  - New features not yet automated
+  - Complex edge cases requiring human judgment
+  - Visual/UX validation requiring subjective assessment
+  - Scenarios that are not cost-effective to automate
+
+  ### Test Data Management
+  - Environment variables strategy (which vars go in .env.example vs .env)
+  - Dynamic test data generation approach (use data generators)
+  - API-based test data setup (10-20x faster than UI)
+  - Test data isolation and cleanup strategy
+
+  ### Automation Approach
+  - **Framework:** Playwright + TypeScript (already scaffolded)
+  - **Pattern:** Page Object Model for all pages
+  - **Selectors:** Prioritize role-based selectors (getByRole, getByLabel, getByText)
+  - **Components:** Reusable component objects for common UI elements
+  - **Fixtures:** Custom fixtures for authenticated sessions and common setup
+  - **API for Speed:** Use Playwright's request context to create test data via API
+  - **Best Practices:** Reference \`.bugzy/runtime/testing-best-practices.md\` for patterns
+
+  ### Test Organization
+  - Automated tests location: \`./tests/specs/[feature]/\`
+  - Page Objects location: \`./tests/pages/\`
+  - Manual test cases location: \`./test-cases/\` (human-readable documentation)
+  - Test case naming: TC-XXX-feature-description.md
+  - Automated test naming: feature.spec.ts
+
+  ### Automation Decision Criteria
+  Define which scenarios warrant automation:
+  - \u2705 Automate: Frequent execution, critical paths, regression tests, CI/CD integration
+  - \u274C Keep Manual: Rare edge cases, exploratory tests, visual validation, one-time checks
+
+### Step 5: Create the test plan file
+
+Read the test plan template from \`.bugzy/runtime/templates/test-plan-template.md\` and use it as the base structure. Fill in the placeholders with information extracted from BOTH the product description AND documentation research:
+
+1. Read the template file from \`.bugzy/runtime/templates/test-plan-template.md\`
+2. Replace placeholders like:
+   - \`[ProjectName]\` with the actual project name from the product description
+   - \`[Date]\` with the current date
+   - Feature sections with actual features identified from all documentation sources
+   - Test data requirements based on the product's needs and API documentation
+   - Risks based on the complexity, known issues, and technical constraints
+3. Add any product-specific sections that may be needed based on discovered documentation
+4. **Mark ambiguities based on severity:**
+   - CRITICAL/HIGH: Should be clarified before plan creation (see Step 1.8)
+   - MEDIUM: Mark with [ASSUMED: reason] and note assumption
+   - LOW: Mark with [TO BE EXPLORED: detail] for future investigation
+5. Include references to source documentation for traceability
+
+### Step 6: Save the test plan
+
+Save the generated test plan to a file named \`test-plan.md\` in the project root with appropriate frontmatter:
+
+\`\`\`yaml
+---
+version: 1.0.0
+lifecycle_phase: initial
+created_at: [current date]
+updated_at: [current date]
+last_exploration: null
+total_discoveries: 0
+status: draft
+author: claude
+tags: [functional, security, performance]
+---
+\`\`\`
+
+### Step 7: Extract and save environment variables
+
+**CRITICAL**: Test data values must ONLY go to .env.testdata, NOT in the test plan document.
+
+After saving the test plan:
+
+1. **Parse the test plan** to find all TEST_ prefixed environment variables mentioned:
+   - Look in the Testing Environment section
+   - Search for any TEST_ variables referenced
+   - Extract variables from configuration or setup sections
+   - Common patterns include: TEST_BASE_URL, TEST_USER_*, TEST_API_*, TEST_ADMIN_*, etc.
+
+2. **Create .env.testdata file** with all discovered variables:
+   \`\`\`bash
+   # Application Configuration
+   TEST_BASE_URL=
+
+   # Test User Credentials
+   TEST_USER_EMAIL=
+   TEST_USER_PASSWORD=
+   TEST_ADMIN_EMAIL=
+   TEST_ADMIN_PASSWORD=
+
+   # API Configuration
+   TEST_API_KEY=
+   TEST_API_SECRET=
+
+   # Other Test Data
+   TEST_DB_NAME=
+   TEST_TIMEOUT=
+   \`\`\`
+
+3. **Add helpful comments** for each variable group to guide users in filling values
+
+4. **Save the file** as \`.env.testdata\` in the project root
+
+5. **Verify test plan references .env.testdata**:
+   - Ensure test plan DOES NOT contain test data values
+   - Ensure test plan references \`.env.testdata\` for test data requirements
+   - Add instruction: "Fill in actual values in .env.testdata before running tests"
+
+${KNOWLEDGE_BASE_UPDATE_INSTRUCTIONS}
+
+{{TEAM_COMMUNICATOR_INSTRUCTIONS}}
+
+### Step 8: Final summary
+
+Provide a summary of:
+- Test plan created successfully at \`test-plan.md\`
+- Environment variables extracted to \`.env.testdata\`
+- Number of TEST_ variables discovered
+- Instructions for the user to fill in actual values in .env.testdata before running tests`,
+  optionalSubagents: [
+    {
+      role: "documentation-researcher",
+      contentBlock: `### Step 2: Gather comprehensive project documentation
+
+Use the documentation-researcher agent to explore and gather all available project information and other documentation sources. This ensures the test plan is based on complete and current information.
+
+\`\`\`
+Use the documentation-researcher agent to explore all available project documentation related to: $ARGUMENTS
+
+Specifically gather:
+- Product specifications and requirements
+- User stories and acceptance criteria
+- Technical architecture documentation
+- API documentation and endpoints
+- User roles and permissions
+- Business rules and validations
+- UI/UX specifications
+- Known limitations or constraints
+- Existing test documentation
+- Bug reports or known issues
+\`\`\`
+
+The agent will:
+1. Check its memory for previously discovered documentation
+2. Explore workspace for relevant pages and databases
+3. Build a comprehensive understanding of the product
+4. Return synthesized information about all discovered documentation`
+    },
+    {
+      role: "team-communicator",
+      contentBlock: `### Step 7.5: Team Communication
+
+Use the team-communicator agent to notify the product team about the new test plan:
+
+\`\`\`
+Use the team-communicator agent to:
+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`
+    }
+  ],
+  requiredSubagents: ["test-runner"]
+};
+
+// src/tasks/library/handle-message.ts
+var handleMessageTask = {
+  slug: TASK_SLUGS.HANDLE_MESSAGE,
+  name: "Handle Message",
+  description: "Handle team responses and Slack communications, maintaining context for ongoing conversations (LLM-routed)",
+  frontmatter: {
+    description: "Handle team responses and Slack communications, maintaining context for ongoing conversations",
+    "argument-hint": "[slack thread context or team message]"
+  },
+  baseContent: `# Handle Message Command
+
+## SECURITY NOTICE
+**CRITICAL**: Never read the \`.env\` file. It contains ONLY secrets (passwords, API keys).
+- **Read \`.env.testdata\`** for non-secret environment variables (TEST_BASE_URL, TEST_OWNER_EMAIL, etc.)
+- \`.env.testdata\` contains actual values for test data, URLs, and non-sensitive configuration
+- For secrets: Reference variable names only (TEST_OWNER_PASSWORD) - values are injected at runtime
+- The \`.env\` file access is blocked by settings.json
+
+Process team responses from Slack threads and handle multi-turn conversations with the product team about testing clarifications, ambiguities, and questions.
+
+## Arguments
+Team message/thread context: $ARGUMENTS
+
+${KNOWLEDGE_BASE_READ_INSTRUCTIONS}
+
+## Process
+
+### Step 0: Detect Message Intent and Load Handler
+
+Before processing the message, identify the intent type to load the appropriate handler.
+
+#### 0.1 Extract Intent from Event Payload
+
+Check the event payload for the \`intent\` field provided by the LLM layer:
+- If \`intent\` is present, use it directly
+- Valid intent values: \`question\`, \`feedback\`, \`status\`
+
+#### 0.2 Fallback Intent Detection (if no intent provided)
+
+If intent is not in the payload, detect from message patterns:
+
+| Condition | Intent |
+|-----------|--------|
+| Keywords: "status", "progress", "how did", "results", "how many passed" | \`status\` |
+| Keywords: "bug", "issue", "broken", "doesn't work", "failed", "error" | \`feedback\` |
+| Question words: "what", "which", "do we have", "is there" about tests/project | \`question\` |
+| Default (none of above) | \`feedback\` |
+
+#### 0.3 Load Handler File
+
+Based on detected intent, load the handler from:
+\`.bugzy/runtime/handlers/messages/{intent}.md\`
+
+**Handler files:**
+- \`question.md\` - Questions about tests, coverage, project details
+- \`feedback.md\` - Bug reports, test observations, general information
+- \`status.md\` - Status checks on test runs, task progress
+
+#### 0.4 Follow Handler Instructions
+
+**IMPORTANT**: The handler file is authoritative for this intent type.
+
+1. Read the handler file completely
+2. Follow its processing steps in order
+3. Apply its context loading requirements
+4. Use its response guidelines
+5. Perform any memory updates it specifies
+
+The handler file contains all necessary processing logic for the detected intent type. Each handler includes:
+- Specific processing steps for that intent
+- Context loading requirements
+- Response guidelines
+- Memory update instructions
+
+${KNOWLEDGE_BASE_UPDATE_INSTRUCTIONS}
+
+## 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
+
+## 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`,
+  optionalSubagents: [],
+  requiredSubagents: ["team-communicator"]
+};
+
+// src/tasks/library/process-event.ts
+var processEventTask = {
+  slug: TASK_SLUGS.PROCESS_EVENT,
+  name: "Process Event",
+  description: "Process external system events (Jira, GitHub, Linear) using handler-defined rules to extract insights and track issues",
+  frontmatter: {
+    description: "Process external system events (Jira, GitHub, Linear) using handler-defined rules to extract insights and track issues",
+    "argument-hint": "[event payload or description]"
+  },
+  baseContent: `# Process Event Command
+
+## SECURITY NOTICE
+**CRITICAL**: Never read the \`.env\` file. It contains ONLY secrets (passwords, API keys).
+- **Read \`.env.testdata\`** for non-secret environment variables (TEST_BASE_URL, TEST_OWNER_EMAIL, etc.)
+- \`.env.testdata\` contains actual values for test data, URLs, and non-sensitive configuration
+- For secrets: Reference variable names only (TEST_OWNER_PASSWORD) - values are injected at runtime
+- The \`.env\` file access is blocked by settings.json
+
+Process various types of events using intelligent pattern matching and historical context to maintain and evolve the testing system.
+
+## Arguments
+Arguments: $ARGUMENTS
+
+${KNOWLEDGE_BASE_READ_INSTRUCTIONS}
+
+## Process
+
+### Step 1: Understand Event Context
+
+Events come from integrated external systems via webhooks or manual input. Common sources include:
+- **Issue Trackers**: Jira, Linear, GitHub Issues
+- **Source Control**: GitHub, GitLab
+- **Communication Tools**: Slack
+
+**Event structure and semantics vary by source.** Do not interpret events based on generic assumptions. Instead, load the appropriate handler file (Step 2.4) for system-specific processing rules.
+
+#### Event Context to Extract:
+- **What happened**: The core event (test failed, PR merged, etc.)
+- **Where**: Component, service, or area affected
+- **Impact**: How this affects testing strategy
+- **Action Required**: What needs to be done in response
+
+### Step 1.5: Clarify Unclear Events
+
+If the event information is incomplete or ambiguous, seek clarification before processing:
+
+#### Detect Unclear Events
+
+Events may be unclear in several ways:
+- **Vague description**: "Something broke", "issue with login" (what specifically?)
+- **Missing context**: Which component, which environment, which user?
+- **Contradictory information**: Event data conflicts with other sources
+- **Unknown references**: Mentions unfamiliar features, components, or systems
+- **Unclear severity**: Impact or priority is ambiguous
+
+#### Assess Ambiguity Severity
+
+Classify the ambiguity level to determine appropriate response:
+
+**\u{1F534} CRITICAL - STOP and seek clarification:**
+- Cannot identify which component is affected
+- Event data is contradictory or nonsensical
+- Unknown system or feature mentioned
+- Cannot determine if this requires immediate action
+- Example: Event says "production is down" but unclear which service
+
+**\u{1F7E0} HIGH - STOP and seek clarification:**
+- Vague problem description that could apply to multiple areas
+- Missing critical context needed for proper response
+- Unclear which team or system is responsible
+- Example: "Login issue reported" (login button? auth service? session? which page?)
+
+**\u{1F7E1} MEDIUM - Proceed with documented assumptions:**
+- Some details missing but core event is clear
+- Can infer likely meaning from context
+- Can proceed but should clarify async
+- Example: "Test failed on staging" (can assume main staging, but clarify which one)
+
+**\u{1F7E2} LOW - Mark and proceed:**
+- Minor details missing (optional context)
+- Cosmetic or non-critical information gaps
+- Can document gap and continue
+- Example: Missing timestamp or exact user who reported issue
+
+#### Clarification Approach by Severity
+
+**For CRITICAL/HIGH ambiguity:**
+1. **Use team-communicator to ask specific questions**
+2. **WAIT for response before proceeding**
+3. **Document the clarification request in event history**
+
+Example clarification messages:
+- "Event mentions 'login issue' - can you clarify if this is:
+  \u2022 Login button not responding?
+  \u2022 Authentication service failure?
+  \u2022 Session management problem?
+  \u2022 Specific page or global?"
+
+- "Event references component 'XYZ' which is unknown. What system does this belong to?"
+
+- "Event data shows contradictory information: status=success but error_count=15. Which is correct?"
+
+**For MEDIUM ambiguity:**
+1. **Document assumption** with reasoning
+2. **Proceed with processing** based on assumption
+3. **Ask for clarification async** (non-blocking)
+4. **Mark in event history** for future reference
+
+Example: [ASSUMED: "login issue" refers to login button based on recent similar events]
+
+**For LOW ambiguity:**
+1. **Mark with [TO BE CLARIFIED: detail]**
+2. **Continue processing** normally
+3. **Document gap** in event history
+
+Example: [TO BE CLARIFIED: Exact timestamp of when issue was first observed]
+
+#### Document Clarification Process
+
+In event history, record:
+- **Ambiguity detected**: What was unclear
+- **Severity assessed**: CRITICAL/HIGH/MEDIUM/LOW
+- **Clarification requested**: Questions asked (if any)
+- **Response received**: Team's clarification
+- **Assumption made**: If proceeded with assumption
+- **Resolution**: How ambiguity was resolved
+
+This ensures future similar events can reference past clarifications and avoid redundant questions.
+
+### Step 2: Load Context and Memory
+
+#### 2.1 Check Event Processor Memory
+Read \`.bugzy/runtime/memory/event-processor.md\` to:
+- Find similar event patterns
+- Load example events with reasoning
+- Get system-specific rules
+- Retrieve task mapping patterns
+
+#### 2.2 Check Event History
+Read \`.bugzy/runtime/memory/event-history.md\` to:
+- Ensure event hasn't been processed already (idempotency)
+- Find related recent events
+- Understand event patterns and trends
+
+#### 2.3 Read Current State
+- Read \`test-plan.md\` for current coverage
+- List \`./test-cases/\` for existing tests
+- Check \`.bugzy/runtime/knowledge-base.md\` for past insights
+
+#### 2.4 Load System-Specific Handler (REQUIRED)
+
+Based on the event source, load the handler from \`.bugzy/runtime/handlers/\`:
+
+**Step 1: Detect Event Source from Payload:**
+- \`com.jira-server.*\` event type prefix \u2192 \`.bugzy/runtime/handlers/jira.md\`
+- \`github.*\` or GitHub webhook structure \u2192 \`.bugzy/runtime/handlers/github.md\`
+- \`linear.*\` or Linear webhook \u2192 \`.bugzy/runtime/handlers/linear.md\`
+- Other sources \u2192 Check for matching handler file by source name
+
+**Step 2: Load and Read the Handler File:**
+The handler file contains system-specific instructions for:
+- Event payload structure and field meanings
+- Which triggers (status changes, resolutions) require specific actions
+- How to interpret different event types
+- When to invoke \`/verify-changes\`
+- How to update the knowledge base
+
+**Step 3: Follow Handler Instructions:**
+The handler file is authoritative for this event source. Follow its instructions for:
+- Interpreting the event payload
+- Determining what actions to take
+- Formatting responses and updates
+
+**Step 4: If No Handler Exists:**
+Do NOT guess or apply generic logic. Instead:
+1. Inform the user that no handler exists for this event source
+2. Ask how this event type should be processed
+3. Suggest creating a handler file at \`.bugzy/runtime/handlers/{source}.md\`
+
+**Project-Specific Configuration:**
+Handlers reference \`.bugzy/runtime/project-context.md\` for project-specific rules like:
+- Which status transitions trigger verify-changes
+- Which resolutions should update the knowledge base
+- Which transitions to ignore
+
+### Step 3: Intelligent Event Analysis
+
+#### 3.1 Contextual Pattern Analysis
+Don't just match patterns - analyze the event within the full context:
+
+**Combine Multiple Signals**:
+- Event details + Historical patterns from memory
+- Current test plan state + Knowledge base
+- External system status + Team activity
+- Business priorities + Risk assessment
+
+**Example Contextual Analysis**:
+\`\`\`
+Event: Jira issue PROJ-456 moved to "Ready for QA"
++ Handler: jira.md says "Ready for QA" triggers /verify-changes
++ History: This issue was previously in "In Progress" for 3 days
++ Knowledge: Related PR #123 merged yesterday
+= Decision: Invoke /verify-changes with issue context and PR reference
+\`\`\`
+
+**Pattern Recognition with Context**:
+- An issue resolution depends on what the handler prescribes for that status
+- A duplicate event (same issue, same transition) should be skipped
+- Events from different sources about the same change should be correlated
+- Handler instructions take precedence over generic assumptions
+
+#### 3.2 Generate Semantic Queries
+Based on event type and content, generate 3-5 specific search queries:
+- Search for similar past events
+- Look for related test cases
+- Find relevant documentation
+- Check for known issues
+
+{{DOCUMENTATION_RESEARCHER_INSTRUCTIONS}}
+
+### Step 4: Task Planning with Reasoning
+
+Generate tasks based on event analysis, using examples from memory as reference.
+
+#### Task Generation Logic:
+Analyze the event in context of ALL available information to decide what actions to take:
+
+**Consider the Full Context**:
+- What does the handler prescribe for this event type?
+- How does this relate to current knowledge?
+- What's the state of related issues in external systems?
+- Is this part of a larger pattern we've been seeing?
+- What's the business impact of this event?
+
+**Contextual Decision Making**:
+The same event type can require different actions based on context:
+- If handler says this status triggers verification \u2192 Invoke /verify-changes
+- If this issue was already processed (check event history) \u2192 Skip to avoid duplicates
+- If related PR exists in knowledge base \u2192 Include PR context in actions
+- If this is a recurring pattern from the same source \u2192 Consider flagging for review
+- If handler has no rule for this event type \u2192 Ask user for guidance
+
+**Dynamic Task Selection**:
+Based on the contextual analysis, decide which tasks make sense:
+- **extract_learning**: When the event reveals something new about the system
+- **update_test_plan**: When our understanding of what to test has changed
+- **update_test_cases**: When tests need to reflect new reality
+- **report_bug**: When we have a legitimate, impactful, reproducible issue
+- **skip_action**: When context shows no action needed (e.g., known issue, already fixed)
+
+The key is to use ALL available context - not just react to the event type
+
+#### Document Reasoning:
+For each task, document WHY it's being executed:
+\`\`\`markdown
+Task: extract_learning
+Reasoning: This event reveals a pattern of login failures on Chrome that wasn't previously documented
+Data: "Chrome-specific timeout issues with login button"
+\`\`\`
+
+### Step 5: Execute Tasks with Memory Updates
+
+#### 5.1 Execute Each Task
+
+{{ISSUE_TRACKER_INSTRUCTIONS}}
+
+##### For Other Tasks:
+Follow the standard execution logic with added context from memory.
+
+#### 5.2 Update Event Processor Memory
+If new patterns discovered, append to \`.bugzy/runtime/memory/event-processor.md\`:
+\`\`\`markdown
+### Pattern: [New Pattern Name]
+**First Seen**: [Date]
+**Indicators**: [What identifies this pattern]
+**Typical Tasks**: [Common task responses]
+**Example**: [This event]
+\`\`\`
+
+#### 5.3 Update Event History
+Append to \`.bugzy/runtime/memory/event-history.md\`:
+\`\`\`markdown
+## [Timestamp] - Event #[ID]
+
+**Original Input**: [Raw arguments provided]
+**Parsed Event**:
+\`\`\`yaml
+type: [type]
+source: [source]
+[other fields]
+\`\`\`
+
+**Pattern Matched**: [Pattern name or "New Pattern"]
+**Tasks Executed**:
+1. [Task 1] - Reasoning: [Why]
+2. [Task 2] - Reasoning: [Why]
+
+**Files Modified**:
+- [List of files]
+
+**Outcome**: [Success/Partial/Failed]
+**Notes**: [Any additional context]
+---
+\`\`\`
+
+### Step 6: Learning from Events
+
+After processing, check if this event teaches us something new:
+1. Is this a new type of event we haven't seen?
+2. Did our task planning work well?
+3. Should we update our patterns?
+4. Are there trends across recent events?
+
+If yes, update the event processor memory with new patterns or refined rules.
+
+### Step 7: Create Necessary Files
+
+Ensure all required files and directories exist:
+\`\`\`bash
+mkdir -p ./test-cases .claude/memory
+\`\`\`
+
+Create files if they don't exist:
+- \`.bugzy/runtime/knowledge-base.md\`
+- \`.bugzy/runtime/memory/event-processor.md\`
+- \`.bugzy/runtime/memory/event-history.md\`
+
+## 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
+- Only take actions prescribed by the handler or confirmed by the user
+- 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
+
+${KNOWLEDGE_BASE_UPDATE_INSTRUCTIONS}`,
+  optionalSubagents: [
+    {
+      role: "documentation-researcher",
+      contentBlock: `#### 3.3 Use Documentation Researcher if Needed
+For events mentioning unknown features or components:
+\`\`\`
+Use documentation-researcher agent to find information about: [component/feature]
+\`\`\``
+    },
+    {
+      role: "issue-tracker",
+      contentBlock: `##### For Issue Tracking:
+
+When an issue needs to be tracked (task type: report_bug or update_story):
+\`\`\`
+Use issue-tracker agent to:
+1. Check for duplicate issues in the tracking system
+2. For bugs: Create detailed bug report with:
+   - Clear, descriptive title
+   - Detailed description with context
+   - Step-by-step reproduction instructions
+   - Expected vs actual behavior
+   - Environment and configuration details
+   - Test case reference (if applicable)
+   - Screenshots or error logs
+3. For stories: Update status and add QA comments
+4. Track issue lifecycle and maintain categorization
+\`\`\`
+
+The issue-tracker agent will handle all aspects of issue tracking including duplicate detection, story management, QA workflow transitions, and integration with your project management system (Jira, Linear, Notion, etc.).`
+    }
+  ],
+  requiredSubagents: [],
+  dependentTasks: ["verify-changes"]
+};
+
+// src/tasks/library/run-tests.ts
+var runTestsTask = {
+  slug: TASK_SLUGS.RUN_TESTS,
+  name: "Run Tests",
+  description: "Execute automated Playwright tests, analyze failures, and fix test issues automatically",
+  frontmatter: {
+    description: "Execute automated Playwright tests, analyze failures, and fix test issues automatically",
+    "argument-hint": '[file-pattern|tag|all] (e.g., "auth", "@smoke", "tests/specs/login.spec.ts")'
+  },
+  baseContent: `# Run Tests Command
+
+## SECURITY NOTICE
+**CRITICAL**: Never read the \`.env\` file. It contains ONLY secrets (passwords, API keys).
+- **Read \`.env.testdata\`** for non-secret environment variables (TEST_BASE_URL, TEST_OWNER_EMAIL, etc.)
+- \`.env.testdata\` contains actual values for test data, URLs, and non-sensitive configuration
+- For secrets: Reference variable names only (TEST_OWNER_PASSWORD) - values are injected at runtime
+- The \`.env\` file access is blocked by settings.json
+
+Execute automated Playwright tests, analyze failures using JSON reports, automatically fix test issues, and log product bugs.
+
+## Arguments
+Arguments: $ARGUMENTS
+
+## Parse Arguments
+Extract the following from arguments:
+- **selector**: Test selection criteria
+  - File pattern: "auth" \u2192 finds tests/specs/**/*auth*.spec.ts
+  - Tag: "@smoke" \u2192 runs tests with @smoke annotation
+  - Specific file: "tests/specs/login.spec.ts"
+  - All tests: "all" or "" \u2192 runs entire test suite
+
+${KNOWLEDGE_BASE_READ_INSTRUCTIONS}
+
+## Test Execution Strategy
+
+**IMPORTANT**: Before selecting tests, read \`.bugzy/runtime/test-execution-strategy.md\` to understand:
+- Available test tiers (Smoke, Component, Full Regression)
+- When to use each tier (commit, PR, release, debug)
+- Default behavior (default to @smoke unless user specifies otherwise)
+- How to interpret user intent from context keywords
+- Time/coverage trade-offs
+- Tag taxonomy
+
+Apply the strategy guidance when determining which tests to run.
+
+## Process
+
+**First**, consult \`.bugzy/runtime/test-execution-strategy.md\` decision tree to determine appropriate test tier based on user's selector and context.
+
+### Step 1: Identify Automated Tests to Run
+
+#### 1.1 Understand Test Selection
+Parse the selector argument to determine which tests to run:
+
+**File Pattern** (e.g., "auth", "login"):
+- Find matching test files: \`tests/specs/**/*[pattern]*.spec.ts\`
+- Example: "auth" \u2192 finds all test files with "auth" in the name
+
+**Tag** (e.g., "@smoke", "@regression"):
+- Run tests with specific Playwright tag annotation
+- Use Playwright's \`--grep\` option
+
+**Specific File** (e.g., "tests/specs/auth/login.spec.ts"):
+- Run that specific test file
+
+**All Tests** ("all" or no selector):
+- Run entire test suite: \`tests/specs/**/*.spec.ts\`
+
+#### 1.2 Find Matching Test Files
+Use glob patterns to find test files:
+\`\`\`bash
+# For file pattern
+ls tests/specs/**/*[pattern]*.spec.ts
+
+# For specific file
+ls tests/specs/auth/login.spec.ts
+
+# For all tests
+ls tests/specs/**/*.spec.ts
+\`\`\`
+
+#### 1.3 Validate Test Files Exist
+Check that at least one test file was found:
+- If no tests found, inform user and suggest available tests
+- List available test files if selection was unclear
+
+### Step 2: Execute Automated Playwright Tests
+
+#### 2.1 Build Playwright Command
+Construct the Playwright test command based on the selector:
+
+**For file pattern or specific file**:
+\`\`\`bash
+npx playwright test [selector]
+\`\`\`
+
+**For tag**:
+\`\`\`bash
+npx playwright test --grep "[tag]"
+\`\`\`
+
+**For all tests**:
+\`\`\`bash
+npx playwright test
+\`\`\`
+
+**Output**: Custom Bugzy reporter will create hierarchical test-runs/YYYYMMDD-HHMMSS/ structure with manifest.json
+
+#### 2.2 Execute Tests via Bash
+Run the Playwright command:
+\`\`\`bash
+npx playwright test [selector]
+\`\`\`
+
+Wait for execution to complete. This may take several minutes depending on test count.
+
+**Note**: The custom Bugzy reporter will automatically:
+- Generate timestamp in YYYYMMDD-HHMMSS format
+- Create test-runs/{timestamp}/ directory structure
+- Record execution-id.txt with BUGZY_EXECUTION_ID
+- Save results per test case in TC-{id}/exec-1/ folders
+- Generate manifest.json with complete execution summary
+
+#### 2.3 Locate and Read Test Results
+After execution completes, find and read the manifest:
+
+1. Find the test run directory (most recent):
+   \`\`\`bash
+   ls -t test-runs/ | head -1
+   \`\`\`
+
+2. Read the manifest.json file:
+   \`\`\`bash
+   cat test-runs/[timestamp]/manifest.json
+   \`\`\`
+
+3. Store the timestamp for use in test-debugger-fixer if needed
+
+### Step 3: Analyze Test Results from Manifest
+
+#### 3.1 Parse Manifest
+The Bugzy custom reporter produces structured output in manifest.json:
+\`\`\`json
+{
+  "bugzyExecutionId": "70a59676-cfd0-4ffd-b8ad-69ceff25c31d",
+  "timestamp": "20251115-123456",
+  "startTime": "2025-11-15T12:34:56.789Z",
+  "endTime": "2025-11-15T12:45:23.456Z",
+  "status": "completed",
+  "stats": {
+    "totalTests": 10,
+    "passed": 8,
+    "failed": 2,
+    "totalExecutions": 10
+  },
+  "testCases": [
+    {
+      "id": "TC-001-login",
+      "name": "Login functionality",
+      "totalExecutions": 1,
+      "finalStatus": "passed",
+      "executions": [
+        {
+          "number": 1,
+          "status": "passed",
+          "duration": 1234,
+          "videoFile": "video.webm",
+          "hasTrace": false,
+          "hasScreenshots": false,
+          "error": null
+        }
+      ]
+    },
+    {
+      "id": "TC-002-invalid-credentials",
+      "name": "Invalid credentials error",
+      "totalExecutions": 1,
+      "finalStatus": "failed",
+      "executions": [
+        {
+          "number": 1,
+          "status": "failed",
+          "duration": 2345,
+          "videoFile": "video.webm",
+          "hasTrace": true,
+          "hasScreenshots": true,
+          "error": "expect(locator).toBeVisible()..."
+        }
+      ]
+    }
+  ]
+}
+\`\`\`
+
+#### 3.2 Extract Test Results
+From the manifest, extract:
+- **Total tests**: stats.totalTests
+- **Passed tests**: stats.passed
+- **Failed tests**: stats.failed
+- **Total executions**: stats.totalExecutions (includes re-runs)
+- **Duration**: Calculate from startTime and endTime
+
+For each failed test, collect from testCases array:
+- Test ID (id field)
+- Test name (name field)
+- Final status (finalStatus field)
+- Latest execution details:
+  - Error message (executions[last].error)
+  - Duration (executions[last].duration)
+  - Video file location (test-runs/{timestamp}/{id}/exec-{num}/{videoFile})
+  - Trace availability (executions[last].hasTrace)
+  - Screenshots availability (executions[last].hasScreenshots)
+
+#### 3.3 Generate Summary Statistics
+\`\`\`markdown
+## Test Execution Summary
+- Total Tests: [count]
+- Passed: [count] ([percentage]%)
+- Failed: [count] ([percentage]%)
+- Skipped: [count] ([percentage]%)
+- Total Duration: [time]
+\`\`\`
+
+### Step 5: Triage Failed Tests
+
+After analyzing test results, triage each failure to determine if it's a product bug or test issue:
+
+#### 5.1 Triage Failed Tests FIRST
+
+**\u26A0\uFE0F IMPORTANT: Do NOT report bugs without triaging first.**
+
+For each failed test:
+
+1. **Read failure details** from JSON report (error message, stack trace)
+2. **Classify the failure:**
+   - **Product bug**: Application behaves incorrectly
+   - **Test issue**: Test code needs fixing (selector, timing, assertion)
+3. **Document classification** for next steps
+
+**Classification Guidelines:**
+- **Product Bug**: Correct test code, unexpected application behavior
+- **Test Issue**: Selector not found, timeout, race condition, wrong assertion
+
+#### 5.2 Fix Test Issues Automatically
+
+For each test classified as **[TEST ISSUE]**, use the test-debugger-fixer agent to automatically fix the test:
+
+\`\`\`
+Use the test-debugger-fixer agent to fix test issues:
+
+For each failed test classified as a test issue (not a product bug), provide:
+- Test run timestamp: [from manifest.timestamp]
+- Test case ID: [from testCases[].id in manifest]
+- Test name/title: [from testCases[].name in manifest]
+- Error message: [from testCases[].executions[last].error]
+- Execution details path: test-runs/{timestamp}/{testCaseId}/exec-1/
+
+The agent will:
+1. Read the execution details from result.json
+2. Analyze the failure (error message, trace if available)
+3. Identify the root cause (brittle selector, missing wait, race condition, etc.)
+4. Apply appropriate fix to the test code
+5. Rerun the test
+6. The custom reporter will automatically create the next exec-N/ folder
+7. Repeat up to 3 times if needed (exec-1, exec-2, exec-3)
+8. Report success or escalate as likely product bug
+
+After test-debugger-fixer completes:
+- If fix succeeded: Mark test as fixed, add to "Tests Fixed" list
+- If still failing after 3 attempts: Reclassify as potential product bug for Step 5.3
+\`\`\`
+
+**Track Fixed Tests:**
+- Maintain list of tests fixed automatically
+- Include fix description (e.g., "Updated selector from CSS to role-based")
+- Note verification status (test now passes)
+
+{{ISSUE_TRACKER_INSTRUCTIONS}}
+
+${KNOWLEDGE_BASE_UPDATE_INSTRUCTIONS}
+
+{{TEAM_COMMUNICATOR_INSTRUCTIONS}}
+
+### Step 6: Handle Special Cases
+
+#### If No Test Cases Found
+If no test cases match the selection criteria:
+1. Inform user that no matching test cases were found
+2. List available test cases or suggest running \`/generate-test-cases\` first
+3. Provide examples of valid selection criteria
+
+#### If Test Runner Agent Fails
+If the test-runner agent encounters issues:
+1. Report the specific error
+2. Suggest troubleshooting steps
+3. Offer to run tests individually if batch execution failed
+
+#### If Test Cases Are Invalid
+If selected test cases have formatting issues:
+1. Report which test cases are invalid
+2. Specify what's missing or incorrect
+3. Offer to fix the issues or skip invalid tests
+
+### Important Notes
+
+**Test Selection Strategy**:
+- **Always read** \`.bugzy/runtime/test-execution-strategy.md\` before selecting tests
+- Default to \`@smoke\` tests for fast validation unless user explicitly requests otherwise
+- Smoke tests provide 100% manual test case coverage with zero redundancy (~2-5 min)
+- Full regression includes intentional redundancy for diagnostic value (~10-15 min)
+- Use context keywords from user request to choose appropriate tier
+
+**Test Execution**:
+- Automated Playwright tests are executed via bash command, not through agents
+- Test execution time varies by tier (see strategy document for details)
+- JSON reports provide structured test results for analysis
+- Playwright automatically captures traces, screenshots, and videos on failures
+- Test artifacts are stored in test-results/ directory
+
+**Failure Handling**:
+- Test failures are automatically triaged (product bugs vs test issues)
+- Test issues are automatically fixed by the test-debugger-fixer subagent
+- Product bugs are logged via issue tracker after triage
+- All results are analyzed for learning opportunities and team communication
+- Critical failures trigger immediate team notification
+
+**Related Documentation**:
+- \`.bugzy/runtime/test-execution-strategy.md\` - When and why to run specific tests
+- \`.bugzy/runtime/testing-best-practices.md\` - How to write tests (patterns and anti-patterns)
+
+`,
+  optionalSubagents: [
+    {
+      role: "issue-tracker",
+      contentBlock: `
+
+#### 5.3 Log Product Bugs via Issue Tracker
+
+After triage in Step 5.1, for tests classified as **[PRODUCT BUG]**, use the issue-tracker agent to log bugs:
+
+For each bug to report, use the issue-tracker agent:
+
+\`\`\`
+Use issue-tracker agent to:
+1. Check for duplicate bugs in the tracking system
+   - The agent will automatically search for similar existing issues
+   - It maintains memory of recently reported issues
+   - Duplicate detection happens automatically - don't create manual checks
+
+2. For each new bug (non-duplicate):
+   Create detailed bug report with:
+   - **Title**: Clear, descriptive summary (e.g., "Login button fails with timeout on checkout page")
+   - **Description**:
+     - What happened vs. what was expected
+     - Impact on users
+     - Test reference: [file path] \u203A [test title]
+   - **Reproduction Steps**:
+     - List steps from the failing test
+     - Include specific test data used
+     - Note any setup requirements from test file
+   - **Test Execution Details**:
+     - Test file: [file path from JSON report]
+     - Test name: [test title from JSON report]
+     - Error message: [from JSON report]
+     - Stack trace: [from JSON report]
+     - Trace file: [path if available]
+     - Screenshots: [paths if available]
+   - **Environment Details**:
+     - Browser and version (from Playwright config)
+     - Test environment URL (from .env.testdata BASE_URL)
+     - Timestamp of failure
+   - **Severity/Priority**: Based on:
+     - Test type (smoke tests = high priority)
+     - User impact
+     - Frequency (always fails vs flaky)
+   - **Additional Context**:
+     - Error messages or stack traces from JSON report
+     - Related test files (if part of test suite)
+     - Relevant knowledge from knowledge-base.md
+
+3. Track created issues:
+   - Note the issue ID/number returned
+   - Update issue tracker memory with new bugs
+   - Prepare issue references for team communication
+\`\`\`
+
+#### 6.3 Summary of Bug Reporting
+
+After issue tracker agent completes, create a summary:
+\`\`\`markdown
+### Bug Reporting Summary
+- Total bugs found: [count of FAIL tests]
+- New bugs reported: [count of newly created issues]
+- Duplicate bugs found: [count of duplicates detected]
+- Issues not reported: [count of skipped/known issues]
+
+**New Bug Reports**:
+- [Issue ID]: [Bug title] (Test: TC-XXX, Priority: [priority])
+- [Issue ID]: [Bug title] (Test: TC-YYY, Priority: [priority])
+
+**Duplicate Bugs** (already tracked):
+- [Existing Issue ID]: [Bug title] (Matches test: TC-XXX)
+
+**Not Reported** (skipped or known):
+- TC-XXX: Skipped due to blocker failure
+- TC-YYY: Known issue documented in knowledge base
+\`\`\`
+
+**Note**: The issue tracker agent handles all duplicate detection and system integration automatically. Simply provide the bug details and let it manage the rest.`
+    },
+    {
+      role: "team-communicator",
+      contentBlock: `### Step 6: Team Communication
+
+Use the team-communicator agent to notify the product team about test execution:
+
+\`\`\`
+Use the team-communicator agent to:
+1. Post test execution summary with key statistics
+2. Highlight critical failures that need immediate attention
+3. Share important learnings about product behavior
+4. Report any potential bugs discovered during testing
+5. Ask for clarification on unexpected behaviors
+6. Provide recommendations for areas needing investigation
+7. Use appropriate urgency level based on failure severity
+\`\`\`
+
+The team communication should include:
+- **Execution summary**: Overall pass/fail statistics and timing
+- **Critical issues**: High-priority failures that need immediate attention
+- **Key learnings**: Important discoveries about product behavior
+- **Potential bugs**: Issues that may require bug reports
+- **Clarifications needed**: Unexpected behaviors requiring team input
+- **Recommendations**: Suggested follow-up actions
+
+**Communication strategy based on results**:
+- **All tests passed**: Brief positive update, highlight learnings
+- **Minor failures**: Standard update with failure details and plans
+- **Critical failures**: Urgent notification with detailed analysis
+- **New discoveries**: Separate message highlighting interesting findings
+
+**Update team communicator memory**:
+- Record test execution communication
+- Track team response patterns to test results
+- Document any clarifications provided by the team
+- Note team priorities based on their responses`
+    }
+  ],
+  requiredSubagents: ["test-runner", "test-debugger-fixer"]
+};
+
+// src/tasks/library/verify-changes.ts
+var verifyChangesTask = {
+  slug: TASK_SLUGS.VERIFY_CHANGES,
+  name: "Verify Changes",
+  description: "Unified verification command for all trigger sources with automated tests and manual checklists",
+  frontmatter: {
+    description: "Verify code changes with automated tests and manual verification checklists",
+    "argument-hint": "[trigger-auto-detected]"
+  },
+  baseContent: `# Verify Changes - Unified Multi-Trigger Workflow
+
+## SECURITY NOTICE
+**CRITICAL**: Never read the \`.env\` file. It contains ONLY secrets (passwords, API keys).
+- **Read \`.env.testdata\`** for non-secret environment variables (TEST_BASE_URL, TEST_OWNER_EMAIL, etc.)
+- \`.env.testdata\` contains actual values for test data, URLs, and non-sensitive configuration
+- For secrets: Reference variable names only (TEST_OWNER_PASSWORD) - values are injected at runtime
+- The \`.env\` file access is blocked by settings.json
+
+## Overview
+
+This task performs comprehensive change verification with:
+- **Automated testing**: Execute Playwright tests with automatic triage and fixing
+- **Manual verification checklists**: Generate role-specific checklists for non-automatable scenarios
+- **Multi-trigger support**: Works from manual CLI, Slack messages, GitHub PRs, and CI/CD
+- **Smart output routing**: Results formatted and delivered to the appropriate channel
+
+## Arguments
+
+**Input**: $ARGUMENTS
+
+The input format determines the trigger source and context extraction strategy.
+
+${KNOWLEDGE_BASE_READ_INSTRUCTIONS}
+
+## Step 1: Detect Trigger Source
+
+Analyze the input format to determine how this task was invoked:
+
+### 1.1 Identify Trigger Type
+
+**GitHub PR Webhook:**
+- Input contains \`pull_request\` object with structure:
+  \`\`\`json
+  {
+    "pull_request": {
+      "number": 123,
+      "title": "...",
+      "body": "...",
+      "changed_files": [...],
+      "base": { "ref": "main" },
+      "head": { "ref": "feature-branch" },
+      "user": { "login": "..." }
+    }
+  }
+  \`\`\`
+\u2192 **Trigger detected: GITHUB_PR**
+
+**Slack Event:**
+- Input contains \`event\` object with structure:
+  \`\`\`json
+  {
+    "eventType": "com.slack.message" or "com.slack.app_mention",
+    "event": {
+      "type": "message",
+      "channel": "C123456",
+      "user": "U123456",
+      "text": "message content",
+      "ts": "1234567890.123456",
+      "thread_ts": "..." (optional)
+    }
+  }
+  \`\`\`
+\u2192 **Trigger detected: SLACK_MESSAGE**
+
+**CI/CD Environment:**
+- Environment variables present:
+  - \`CI=true\`
+  - \`GITHUB_REF\` (e.g., "refs/heads/feature-branch")
+  - \`GITHUB_SHA\` (commit hash)
+  - \`GITHUB_BASE_REF\` (base branch)
+  - \`GITHUB_HEAD_REF\` (head branch)
+- Git context available via bash commands
+\u2192 **Trigger detected: CI_CD**
+
+**Manual Invocation:**
+- Input is natural language, URL, or issue identifier
+- Patterns: "PR #123", GitHub URL, "PROJ-456", feature description
+\u2192 **Trigger detected: MANUAL**
+
+### 1.2 Store Trigger Context
+
+Store the detected trigger for use in Step 6 (output routing):
+- Set variable: \`TRIGGER_SOURCE\` = [GITHUB_PR | SLACK_MESSAGE | CI_CD | MANUAL]
+- This determines output formatting and delivery channel
+
+## Step 2: Extract Context Based on Trigger
+
+Based on the detected trigger source, extract relevant context:
+
+### 2.1 GitHub PR Trigger - Extract PR Details
+
+If trigger is GITHUB_PR:
+- **PR number**: \`pull_request.number\`
+- **Title**: \`pull_request.title\`
+- **Description**: \`pull_request.body\`
+- **Changed files**: \`pull_request.changed_files\` (array of file paths)
+- **Author**: \`pull_request.user.login\`
+- **Base branch**: \`pull_request.base.ref\`
+- **Head branch**: \`pull_request.head.ref\`
+
+Optional: Fetch additional details via GitHub API if needed (PR comments, reviews)
+
+### 2.2 Slack Message Trigger - Parse Natural Language
+
+If trigger is SLACK_MESSAGE:
+- **Message text**: \`event.text\`
+- **Channel**: \`event.channel\` (for posting results)
+- **User**: \`event.user\` (requester)
+- **Thread**: \`event.thread_ts\` or \`event.ts\` (for threading replies)
+
+**Extract references from text:**
+- PR numbers: "#123", "PR 123", "pull request 123"
+- Issue IDs: "PROJ-456", "BUG-123"
+- URLs: GitHub PR links, deployment URLs
+- Feature names: Quoted terms, capitalized phrases
+- Environments: "staging", "production", "preview"
+
+### 2.3 CI/CD Trigger - Read CI Environment
+
+If trigger is CI_CD:
+- **CI platform**: Read \`CI\` env var
+- **Branch**: \`GITHUB_REF\` \u2192 extract branch name
+- **Commit**: \`GITHUB_SHA\`
+- **Base branch**: \`GITHUB_BASE_REF\` (for PRs)
+- **Changed files**: Run \`git diff --name-only $BASE_SHA...$HEAD_SHA\`
+
+If in PR context, can also fetch PR number from CI env vars (e.g., \`GITHUB_EVENT_PATH\`)
+
+### 2.4 Manual Trigger - Parse User Input
+
+If trigger is MANUAL:
+- **GitHub PR URL**: Parse to extract PR number, then fetch details via API
+  - Pattern: \`https://github.com/owner/repo/pull/123\`
+  - Extract: owner, repo, PR number
+  - Fetch: PR details, diff, comments
+- **Issue identifier**: Extract issue ID
+  - Patterns: "PROJ-123", "#456", "BUG-789"
+- **Feature description**: Use text as-is for verification context
+- **Deployment URL**: Extract for testing environment
+
+### 2.5 Unified Context Structure
+
+After extraction, create unified context structure:
+\`\`\`
+CHANGE_CONTEXT = {
+  trigger: [GITHUB_PR | SLACK_MESSAGE | CI_CD | MANUAL],
+  title: "...",
+  description: "...",
+  changedFiles: ["src/pages/Login.tsx", ...],
+  author: "...",
+  environment: "staging" | "production" | URL,
+  prNumber: 123 (if available),
+  issueId: "PROJ-456" (if available),
+
+  // For output routing:
+  slackChannel: "C123456" (if Slack trigger),
+  slackThread: "1234567890.123456" (if Slack trigger),
+  githubRepo: "owner/repo" (if GitHub trigger)
+}
+\`\`\`
+
+## Step 3: Determine Test Scope (Smart Selection)
+
+**IMPORTANT**: You do NOT have access to code files. Infer test scope from change **descriptions** only.
+
+Based on PR title, description, and commit messages, intelligently select which tests to run:
+
+### 3.1 Infer Test Scope from Change Descriptions
+
+Analyze the change description to identify affected feature areas:
+
+**Example mappings from descriptions to test suites:**
+
+| Description Keywords | Inferred Test Scope | Example |
+|---------------------|-------------------|---------|
+| "login", "authentication", "sign in/up" | \`tests/specs/auth/\` | "Fix login page validation" \u2192 Auth tests |
+| "checkout", "payment", "purchase" | \`tests/specs/checkout/\` | "Optimize checkout flow" \u2192 Checkout tests |
+| "cart", "shopping cart", "add to cart" | \`tests/specs/cart/\` | "Update cart calculations" \u2192 Cart tests |
+| "API", "endpoint", "backend" | API test suites | "Add new user API endpoint" \u2192 User API tests |
+| "profile", "account", "settings" | \`tests/specs/profile/\` or \`tests/specs/settings/\` | "Profile page redesign" \u2192 Profile tests |
+
+**Inference strategy:**
+1. **Extract feature keywords** from PR title and description
+   - PR title: "feat(checkout): Add PayPal payment option"
+   - Keywords: ["checkout", "payment"]
+   - Inferred scope: Checkout tests
+
+2. **Analyze commit messages** for conventional commit scopes
+   - \`feat(auth): Add password reset flow\` \u2192 Auth tests
+   - \`fix(cart): Resolve quantity update bug\` \u2192 Cart tests
+
+3. **Map keywords to test organization**
+   - Reference: Tests are organized by feature under \`tests/specs/\` (see \`.bugzy/runtime/testing-best-practices.md\`)
+   - Feature areas typically include: auth/, checkout/, cart/, profile/, api/, etc.
+
+4. **Identify test scope breadth from description tone**
+   - "Fix typo in button label" \u2192 Narrow scope (smoke tests)
+   - "Refactor shared utility functions" \u2192 Wide scope (full suite)
+   - "Update single component styling" \u2192 Narrow scope (component tests)
+
+### 3.2 Fallback Strategies Based on Description Analysis
+
+**Description patterns that indicate full suite:**
+- "Refactor shared/common utilities" (wide impact)
+- "Update dependencies" or "Upgrade framework" (safety validation)
+- "Merge main into feature" or "Sync with main" (comprehensive validation)
+- "Breaking changes" or "Major version update" (thorough testing)
+- "Database migration" or "Schema changes" (data integrity)
+
+**Description patterns that indicate smoke tests only:**
+- "Fix typo" or "Update copy/text" (cosmetic change)
+- "Update README" or "Documentation only" (no functional change)
+- "Fix formatting" or "Linting fixes" (no logic change)
+
+**When description is vague or ambiguous:**
+- Examples: "Updated several components", "Various bug fixes", "Improvements"
+- **ACTION REQUIRED**: Use AskUserQuestion tool to clarify test scope
+- Provide options based on available test suites:
+  \`\`\`typescript
+  AskUserQuestion({
+    questions: [{
+      question: "The change description is broad. Which test suites should run?",
+      header: "Test Scope",
+      multiSelect: true,
+      options: [
+        { label: "Auth tests", description: "Login, signup, password reset" },
+        { label: "Checkout tests", description: "Purchase flow, payment processing" },
+        { label: "Full test suite", description: "Run all tests for comprehensive validation" },
+        { label: "Smoke tests only", description: "Quick validation of critical paths" }
+      ]
+    }]
+  })
+  \`\`\`
+
+**If specific test scope requested:**
+- User can override with: "only smoke tests", "full suite", specific test suite names
+- Honor user's explicit scope over smart selection
+
+### 3.3 Test Selection Summary
+
+Generate summary of test selection based on description analysis:
+\`\`\`markdown
+### Test Scope Determined
+- **Change description**: [PR title or summary]
+- **Identified keywords**: [list extracted keywords: "auth", "checkout", etc.]
+- **Affected test suites**: [list inferred test suite paths or names]
+- **Scope reasoning**: [explain why this scope was selected]
+- **Execution strategy**: [smart selection | full suite | smoke tests | user-specified]
+\`\`\`
+
+**Example summary:**
+\`\`\`markdown
+### Test Scope Determined
+- **Change description**: "feat(checkout): Add PayPal payment option"
+- **Identified keywords**: checkout, payment, PayPal
+- **Affected test suites**: tests/specs/checkout/payment.spec.ts, tests/specs/checkout/purchase-flow.spec.ts
+- **Scope reasoning**: Change affects checkout payment processing; running all checkout tests to validate payment integration
+- **Execution strategy**: Smart selection (checkout suite)
+\`\`\`
+
+## Step 4: Run Verification Workflow
+
+Execute comprehensive verification combining automated tests and manual checklists:
+
+### 4A: Automated Testing (Integrated from /run-tests)
+
+Execute automated Playwright tests with full triage and fixing:
+
+#### 4A.1 Execute Tests
+
+Run the selected tests via Playwright:
+\`\`\`bash
+npx playwright test [scope] --reporter=json --output=test-results/
+\`\`\`
+
+Wait for execution to complete. Capture JSON report from \`test-results/.last-run.json\`.
+
+#### 4A.2 Parse Test Results
+
+Read and analyze the JSON report:
+- Extract: Total, passed, failed, skipped counts
+- For each failed test: file path, test name, error message, stack trace, trace file
+- Calculate: Pass rate, total duration
+
+#### 4A.3 Triage Failures (Classification)
+
+#### Automatic Test Issue Fixing
+
+For each test classified as **[TEST ISSUE]**, use the test-debugger-fixer agent to automatically fix the test:
+
+\`\`\`
+Use the test-debugger-fixer agent to fix test issues:
+
+For each failed test classified as a test issue (not a product bug), provide:
+- Test file path: [from JSON report]
+- Test name/title: [from JSON report]
+- Error message: [from JSON report]
+- Stack trace: [from JSON report]
+- Trace file path: [if available]
+
+The agent will:
+1. Read the failing test file
+2. Analyze the failure details
+3. Open browser via Playwright MCP to debug if needed
+4. Identify the root cause (brittle selector, missing wait, race condition, etc.)
+5. Apply appropriate fix to the test code
+6. Rerun the test to verify the fix
+7. Repeat up to 3 times if needed
+8. Report success or escalate as likely product bug
+
+After test-debugger-fixer completes:
+- If fix succeeded: Mark test as fixed, add to "Tests Fixed" list
+- If still failing after 3 attempts: Reclassify as potential product bug
+\`\`\`
+
+**Track Fixed Tests:**
+- Maintain list of tests fixed automatically
+- Include fix description (e.g., "Updated selector from CSS to role-based")
+- Note verification status (test now passes)
+- Reference .bugzy/runtime/testing-best-practices.md for best practices
+
+For each failed test, classify as:
+- **[PRODUCT BUG]**: Correct test code, but application behaves incorrectly
+- **[TEST ISSUE]**: Test code needs fixing (selector, timing, assertion)
+
+Classification guidelines:
+- Product Bug: Expected behavior not met, functional issue
+- Test Issue: Selector not found, timeout, race condition, brittle locator
+
+#### 4A.4 Fix Test Issues Automatically
+
+For tests classified as [TEST ISSUE]:
+- Use test-debugger-fixer agent to analyze and fix
+- Agent debugs with browser if needed
+- Applies fix (selector update, wait condition, assertion correction)
+- Reruns test to verify fix (10x for flaky tests)
+- Max 3 fix attempts, then reclassify as product bug
+
+Track fixed tests with:
+- Test file path
+- Fix description
+- Verification status (now passes)
+
+#### 4A.5 Log Product Bugs
+
+{{ISSUE_TRACKER_INSTRUCTIONS}}
+
+For tests classified as [PRODUCT BUG]:
+- Use issue-tracker agent to create bug reports
+- Agent checks for duplicates automatically
+- Creates detailed report with:
+  - Title, description, reproduction steps
+  - Test reference, error details, stack trace
+  - Screenshots, traces, environment details
+  - Severity based on test type and impact
+- Returns issue ID for tracking
+
+### 4B: Manual Verification Checklist (NEW)
+
+Generate human-readable checklist for non-automatable scenarios:
+
+#### Generate Manual Verification Checklist
+
+Analyze the code changes and generate a manual verification checklist for scenarios that cannot be automated.
+
+#### Analyze Change Context
+
+Review the provided context to understand what changed:
+- Read PR title, description, and commit messages
+- Identify change types from descriptions: visual, UX, forms, mobile, accessibility, edge cases
+- Understand the scope and impact of changes from the change descriptions
+
+#### Identify Non-Automatable Scenarios
+
+Based on the change analysis, identify scenarios that require human verification:
+
+**1. Visual Design Changes** (CSS, styling, design files, graphics)
+- Color schemes, gradients, shadows
+- Typography, font sizes, line heights
+- Spacing, margins, padding, alignment
+- Visual consistency across components
+- Brand guideline compliance
+\u2192 Add **Design Validation** checklist items
+
+**2. UX Interaction Changes** (animations, transitions, gestures, micro-interactions)
+- Animation smoothness (60fps expectation)
+- Transition timing and easing
+- Interaction responsiveness and feel
+- Loading states and skeleton screens
+- Hover effects, focus states
+\u2192 Add **UX Feel** checklist items
+
+**3. Form and Input Changes** (new form fields, input validation, user input)
+- Screen reader compatibility
+- Keyboard navigation (Tab order, Enter to submit)
+- Error message clarity and placement
+- Color contrast (WCAG 2.1 AA: 4.5:1 ratio for text)
+- Focus indicators visibility
+\u2192 Add **Accessibility** checklist items
+
+**4. Mobile and Responsive Changes** (media queries, touch interactions, viewport)
+- Touch target sizes (\u226544px iOS, \u226548dp Android)
+- Responsive layout breakpoints
+- Mobile keyboard behavior (doesn't obscure inputs)
+- Swipe gestures and touch interactions
+- Pinch-to-zoom functionality
+\u2192 Add **Mobile Experience** checklist items
+
+**5. Low ROI or Rare Scenarios** (edge cases, one-time migrations, rare user paths)
+- Scenarios used by < 1% of users
+- Complex multi-system integrations
+- One-time data migrations
+- Leap year, DST, timezone edge cases
+\u2192 Add **Exploratory Testing** notes
+
+**6. Cross-Browser Visual Consistency** (layout rendering differences)
+- Layout consistency across Chrome, Firefox, Safari
+- CSS feature support differences
+- Font rendering variations
+\u2192 Add **Cross-Browser** checklist items (if significant visual changes)
+
+#### Generate Role-Specific Checklist Items
+
+For each identified scenario, create clear, actionable checklist items:
+
+**Format for each item:**
+- Clear, specific task description
+- Assigned role (@design-team, @qa-team, @a11y-team, @mobile-team)
+- Acceptance criteria (what constitutes pass/fail)
+- Reference to standards when applicable (WCAG, iOS HIG, Material Design)
+- Priority indicator (\u{1F534} critical, \u{1F7E1} important, \u{1F7E2} nice-to-have)
+
+**Example checklist items:**
+
+**Design Validation (@design-team)**
+- [ ] \u{1F534} Login button color matches brand guidelines (#FF6B35)
+- [ ] \u{1F7E1} Loading spinner animation smooth (60fps, no jank)
+- [ ] \u{1F7E1} Card shadows match design system (elevation-2: 0 2px 4px rgba(0,0,0,0.1))
+- [ ] \u{1F7E2} Hover states provide appropriate visual feedback
+
+**Accessibility (@a11y-team)**
+- [ ] \u{1F534} Screen reader announces form errors clearly (tested with VoiceOver/NVDA)
+- [ ] \u{1F534} Keyboard navigation: Tab through all interactive elements in logical order
+- [ ] \u{1F534} Color contrast meets WCAG 2.1 AA (4.5:1 for body text, 3:1 for large text)
+- [ ] \u{1F7E1} Focus indicators visible on all interactive elements
+
+**Mobile Experience (@qa-team, @mobile-team)**
+- [ ] \u{1F534} Touch targets \u226544px (iOS Human Interface Guidelines)
+- [ ] \u{1F534} Mobile keyboard doesn't obscure input fields on iOS/Android
+- [ ] \u{1F7E1} Swipe gestures work naturally without conflicts
+- [ ] \u{1F7E1} Responsive layout adapts properly on iPhone SE (smallest screen)
+
+**UX Feel (@design-team, @qa-team)**
+- [ ] \u{1F7E1} Page transitions smooth and not jarring
+- [ ] \u{1F7E1} Button click feedback immediate (< 100ms perceived response)
+- [ ] \u{1F7E2} Loading states prevent confusion during data fetch
+
+**Exploratory Testing (@qa-team)**
+- [ ] \u{1F7E2} Test edge case: User submits form during network timeout
+- [ ] \u{1F7E2} Test edge case: User navigates back during submission
+
+#### Format for Output Channel
+
+Adapt the checklist format based on the output channel (determined by trigger source):
+
+**Terminal (Manual Trigger):**
+\`\`\`markdown
+MANUAL VERIFICATION CHECKLIST:
+Please verify the following before merging:
+
+Design Validation (@design-team):
+  [ ] \u{1F534} Checkout button colors match brand guidelines (#FF6B35)
+  [ ] \u{1F7E1} Loading spinner animation smooth (60fps)
+
+Accessibility (@a11y-team):
+  [ ] \u{1F534} Screen reader announces error messages
+  [ ] \u{1F534} Keyboard navigation works (Tab order logical)
+  [ ] \u{1F534} Color contrast meets WCAG 2.1 AA (4.5:1 ratio)
+
+Mobile Experience (@qa-team):
+  [ ] \u{1F534} Touch targets \u226544px (iOS HIG)
+  [ ] \u{1F7E1} Responsive layout works on iPhone SE
+\`\`\`
+
+**Slack (Slack Trigger):**
+\`\`\`markdown
+*Manual Verification Needed:*
+\u25A1 Visual: Button colors, animations (60fps)
+\u25A1 Mobile: Touch targets \u226544px
+\u25A1 A11y: Screen reader, keyboard nav, contrast
+
+cc @design-team @qa-team @a11y-team
+\`\`\`
+
+**GitHub PR Comment (GitHub Trigger):**
+\`\`\`markdown
+### Manual Verification Required
+
+The following scenarios require human verification before release:
+
+#### Design Validation (@design-team)
+- [ ] \u{1F534} Checkout button colors match brand guidelines (#FF6B35)
+- [ ] \u{1F7E1} Loading spinner animation smooth (60fps)
+- [ ] \u{1F7E1} Card shadows match design system
+
+#### Accessibility (@a11y-team)
+- [ ] \u{1F534} Screen reader announces error messages (VoiceOver/NVDA)
+- [ ] \u{1F534} Keyboard navigation through all form fields (Tab order)
+- [ ] \u{1F534} Color contrast meets WCAG 2.1 AA (4.5:1 for body text)
+
+#### Mobile Experience (@qa-team)
+- [ ] \u{1F534} Touch targets \u226544px (iOS Human Interface Guidelines)
+- [ ] \u{1F534} Mobile keyboard doesn't obscure input fields
+- [ ] \u{1F7E1} Responsive layout works on iPhone SE (375x667)
+
+---
+*Legend: \u{1F534} Critical \u2022 \u{1F7E1} Important \u2022 \u{1F7E2} Nice-to-have*
+\`\`\`
+
+#### Guidelines for Quality Checklists
+
+**DO:**
+- Make each item verifiable (clear pass/fail criteria)
+- Include context (why this needs manual verification)
+- Reference standards (WCAG, iOS HIG, Material Design)
+- Assign to specific roles
+- Prioritize items (critical, important, nice-to-have)
+- Be specific (not "check colors" but "Login button color matches #FF6B35")
+
+**DON'T:**
+- Create vague items ("test thoroughly")
+- List items that can be automated
+- Skip role assignments
+- Forget acceptance criteria
+- Omit priority indicators
+
+#### When NO Manual Verification Needed
+
+If the changes are purely:
+- Backend logic (no UI changes)
+- Code refactoring (no behavior changes)
+- Configuration changes (no user-facing impact)
+- Fully covered by automated tests
+
+Output:
+\`\`\`markdown
+**Manual Verification:** Not required for this change.
+All user-facing changes are fully covered by automated tests.
+\`\`\`
+
+#### Summary
+
+After generating the checklist:
+- Count total items by priority (\u{1F534} critical, \u{1F7E1} important, \u{1F7E2} nice-to-have)
+- Estimate time needed (e.g., "~30 minutes for design QA, ~45 minutes for accessibility testing")
+- Suggest who should perform each category of checks
+
+### 4C: Aggregate Results
+
+Combine automated and manual verification results:
+
+\`\`\`markdown
+## Verification Results Summary
+
+### Automated Tests
+- Total tests: [count]
+- Passed: [count] ([percentage]%)
+- Failed: [count] ([percentage]%)
+- Test issues fixed: [count]
+- Product bugs logged: [count]
+- Duration: [time]
+
+### Manual Verification Required
+[Checklist generated in 4B, or "Not required"]
+
+### Overall Recommendation
+[\u2705 Safe to merge | \u26A0\uFE0F Review bugs before merging | \u274C Do not merge]
+\`\`\`
+
+## Step 5: Understanding the Change (Documentation Research)
+
+{{DOCUMENTATION_RESEARCHER_INSTRUCTIONS}}
+
+Before proceeding with test creation or execution, ensure requirements are clear through ambiguity detection and adaptive exploration.
+
+**Note**: For detailed exploration and clarification protocols, refer to the complete instructions below. Adapt the depth of exploration based on requirement clarity and use the clarification protocol to detect ambiguity, assess severity, and seek clarification when needed.
+
+After clarification and exploration, analyze the change to determine the verification approach:
+
+### 5.1 Identify Test Scope
+Based on the change description, exploration findings, and clarified requirements:
+- **Direct impact**: Which features/functionality are directly modified
+- **Indirect impact**: What else might be affected (dependencies, integrations)
+- **Regression risk**: Existing functionality that should be retested
+- **New functionality**: Features that need new test coverage
+
+### 5.2 Determine Verification Strategy
+Plan your testing approach based on validated requirements:
+- **Priority areas**: Critical paths that must work
+- **Test types needed**: Functional, regression, integration, UI/UX
+- **Test data requirements**: What test accounts, data, or scenarios needed
+- **Success criteria**: What determines the change is working correctly (now clearly defined)
+
+## Step 6: Report Results (Multi-Channel Output)
+
+Route output based on trigger source (from Step 1):
+
+### 6.1 MANUAL Trigger \u2192 Terminal Output
+
+Format as comprehensive markdown report for terminal display:
+
+\`\`\`markdown
+# Test Verification Report
+
+## Change Summary
+- **What Changed**: [Brief description]
+- **Scope**: [Affected features/areas]
+- **Changed Files**: [count] files
+
+## Automated Test Results
+### Statistics
+- Total Tests: [count]
+- Passed: [count] ([percentage]%)
+- Failed: [count]
+- Test Issues Fixed: [count]
+- Product Bugs Logged: [count]
+- Duration: [time]
+
+### Tests Fixed Automatically
+[For each fixed test:
+- **Test**: [file path] \u203A [test name]
+- **Issue**: [problem found]
+- **Fix**: [what was changed]
+- **Status**: \u2705 Now passing
+]
+
+### Product Bugs Logged
+[For each bug:
+- **Issue**: [ISSUE-123] [Bug title]
+- **Test**: [test file] \u203A [test name]
+- **Severity**: [priority]
+- **Link**: [issue tracker URL]
+]
+
+## Manual Verification Checklist
+
+[Insert checklist from Step 4B]
+
+## Recommendation
+[\u2705 Safe to merge - all automated tests pass, complete manual checks before release]
+[\u26A0\uFE0F Review bugs before merging - [X] bugs need attention]
+[\u274C Do not merge - critical failures]
+
+## Test Artifacts
+- JSON Report: test-results/.last-run.json
+- HTML Report: playwright-report/index.html
+- Traces: test-results/[test-id]/trace.zip
+- Screenshots: test-results/[test-id]/screenshots/
+\`\`\`
+
+### 6.2 SLACK_MESSAGE Trigger \u2192 Thread Reply
+
+{{TEAM_COMMUNICATOR_INSTRUCTIONS}}
+
+Use team-communicator agent to post concise results to Slack thread:
+
+\`\`\`
+Use the team-communicator agent to post verification results.
+
+**Channel**: [from CHANGE_CONTEXT.slackChannel]
+**Thread**: [from CHANGE_CONTEXT.slackThread]
+
+**Message**:
+\u{1F9EA} *Verification Results for [change title]*
+
+*Automated:* \u2705 [passed]/[total] tests passed ([duration])
+[If test issues fixed:] \u{1F527} [count] test issues auto-fixed
+[If bugs logged:] \u{1F41B} [count] bugs logged ([list issue IDs])
+
+*Manual Verification Needed:*
+[Concise checklist summary - collapsed/expandable]
+\u25A1 Visual: [key items]
+\u25A1 Mobile: [key items]
+\u25A1 A11y: [key items]
+
+*Recommendation:* [\u2705 Safe to merge | \u26A0\uFE0F Review bugs | \u274C Blocked]
+
+[If bugs logged:] cc @[relevant-team-members]
+[Link to full test report if available]
+\`\`\`
+
+### 6.3 GITHUB_PR Trigger \u2192 PR Comment
+
+Use GitHub API to post comprehensive comment on PR:
+
+**Format as GitHub-flavored markdown:**
+\`\`\`markdown
+## \u{1F9EA} Test Verification Results
+
+**Status:** [\u2705 All tests passed | \u26A0\uFE0F Issues found | \u274C Critical failures]
+
+### Automated Tests
+| Metric | Value |
+|--------|-------|
+| Total Tests | [count] |
+| Passed | \u2705 [count] ([percentage]%) |
+| Failed | \u274C [count] |
+| Test Issues Fixed | \u{1F527} [count] |
+| Product Bugs Logged | \u{1F41B} [count] |
+| Duration | \u23F1\uFE0F [time] |
+
+### Failed Tests (Triaged)
+
+[For each failure:]
+
+#### \u274C **[Test Name]**
+- **File:** \`[test-file-path]\`
+- **Cause:** [Product bug | Test issue]
+- **Action:** [Bug logged: [ISSUE-123](url) | Fixed: [commit-hash](url)]
+- **Details:**
+  \`\`\`
+  [Error message]
+  \`\`\`
+
+### Tests Fixed Automatically
+
+[For each fixed test:]
+- \u2705 **[Test Name]** (\`[file-path]\`)
+  - **Issue:** [brittle selector | missing wait | race condition]
+  - **Fix:** [description of fix applied]
+  - **Verified:** Passes 10/10 runs
+
+### Product Bugs Logged
+
+[For each bug:]
+- \u{1F41B} **[[ISSUE-123](url)]** [Bug title]
+  - **Test:** \`[test-file]\` \u203A [test name]
+  - **Severity:** [\u{1F534} Critical | \u{1F7E1} Important | \u{1F7E2} Minor]
+  - **Assignee:** @[backend-team | frontend-team]
+
+### Manual Verification Required
+
+The following scenarios require human verification before release:
+
+#### Design Validation (@design-team)
+- [ ] \u{1F534} [Critical design check]
+- [ ] \u{1F7E1} [Important design check]
+
+#### Accessibility (@a11y-team)
+- [ ] \u{1F534} [Critical a11y check]
+- [ ] \u{1F7E1} [Important a11y check]
+
+#### Mobile Experience (@qa-team)
+- [ ] \u{1F534} [Critical mobile check]
+- [ ] \u{1F7E1} [Important mobile check]
+
+---
+*Legend: \u{1F534} Critical \u2022 \u{1F7E1} Important \u2022 \u{1F7E2} Nice-to-have*
+
+### Test Artifacts
+- [Full HTML Report](playwright-report/index.html)
+- [Test Traces](test-results/)
+
+### Recommendation
+[\u2705 **Safe to merge** - All automated tests pass, complete manual checks before release]
+[\u26A0\uFE0F **Review required** - [X] bugs need attention, complete manual checks]
+[\u274C **Do not merge** - Critical failures must be resolved first]
+
+---
+*\u{1F916} Automated by Bugzy \u2022 [View Test Code](tests/specs/) \u2022 [Manual Test Cases](test-cases/)*
+\`\`\`
+
+**Post comment via GitHub API:**
+- Endpoint: \`POST /repos/{owner}/{repo}/issues/{pr_number}/comments\`
+- Use GitHub MCP or bash with \`gh\` CLI
+- Requires GITHUB_TOKEN from environment
+
+### 6.4 CI_CD Trigger \u2192 Build Log + PR Comment
+
+**Output to CI build log:**
+- Print detailed results to stdout (captured by CI)
+- Use ANSI colors if supported by CI platform
+- Same format as MANUAL terminal output
+
+**Exit with appropriate code:**
+- Exit 0: All tests passed (safe to merge)
+- Exit 1: Tests failed or critical bugs found (block merge)
+
+**Post PR comment if GitHub context available:**
+- Check for PR number in CI environment
+- If available: Post comment using 6.3 format
+- Also notify team via Slack if critical failures
+
+## Additional Steps
+
+### Handle Special Cases
+
+**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 (Playwright not installed, env vars missing)
+- Suggest troubleshooting steps
+- Don't proceed with triage if tests didn't run
+
+${KNOWLEDGE_BASE_UPDATE_INSTRUCTIONS}
+
+## 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
+- For best results, ensure:
+  - Playwright is installed (\`npx playwright install\`)
+  - Environment variables configured (copy \`.env.testdata\` to \`.env\`)
+  - GitHub token available for PR comments (if GitHub trigger)
+  - Slack integration configured (if Slack trigger)
+  - Issue tracker configured (Linear, Jira, etc.)
+
+## Success Criteria
+
+A successful verification includes:
+1. \u2705 Trigger source correctly detected
+2. \u2705 Context extracted completely
+3. \u2705 Tests executed (or skipped with explanation)
+4. \u2705 All failures triaged (product bug vs test issue)
+5. \u2705 Test issues fixed automatically (when possible)
+6. \u2705 Product bugs logged to issue tracker
+7. \u2705 Manual verification checklist generated
+8. \u2705 Results formatted for output channel
+9. \u2705 Results delivered to appropriate destination
+10. \u2705 Clear recommendation provided (merge / review / block)`,
+  optionalSubagents: [
+    {
+      role: "documentation-researcher",
+      contentBlock: `#### Research Project Documentation
+
+Use the documentation-researcher agent to gather comprehensive context about the changed features:
+
+\`\`\`
+Use the documentation-researcher agent to explore project documentation related to the changes.
+
+Specifically gather:
+- Product specifications for affected features
+- User stories and acceptance criteria
+- Technical architecture documentation
+- API endpoints and contracts
+- User roles and permissions relevant to the change
+- Business rules and validations
+- UI/UX specifications
+- Known limitations or constraints
+- Related bug reports or known issues
+- Existing test documentation for this area
+\`\`\`
+
+The agent will:
+1. Check its memory for previously discovered documentation
+2. Explore workspace for relevant pages and databases
+3. Build comprehensive understanding of the affected features
+4. Return synthesized information to inform testing strategy
+
+Use this information to:
+- Better understand the change context
+- Identify comprehensive test scenarios
+- Recognize integration points and dependencies
+- Spot potential edge cases or risk areas
+- Enhance manual verification checklist generation`
+    },
+    {
+      role: "issue-tracker",
+      contentBlock: `#### Log Product Bugs
+
+For tests classified as **[PRODUCT BUG]**, use the issue-tracker agent to log bugs:
+
+\`\`\`
+Use issue-tracker agent to:
+1. Check for duplicate bugs in the tracking system
+   - The agent will automatically search for similar existing issues
+   - It maintains memory of recently reported issues
+   - Duplicate detection happens automatically - don't create manual checks
+
+2. For each new bug (non-duplicate):
+   Create detailed bug report with:
+   - **Title**: Clear, descriptive summary (e.g., "Login button fails with timeout on checkout page")
+   - **Description**:
+     - What happened vs. what was expected
+     - Impact on users
+     - Test reference: [file path] \u203A [test title]
+   - **Reproduction Steps**:
+     - List steps from the failing test
+     - Include specific test data used
+     - Note any setup requirements from test file
+   - **Test Execution Details**:
+     - Test file: [file path from JSON report]
+     - Test name: [test title from JSON report]
+     - Error message: [from JSON report]
+     - Stack trace: [from JSON report]
+     - Trace file: [path if available]
+     - Screenshots: [paths if available]
+   - **Environment Details**:
+     - Browser and version (from Playwright config)
+     - Test environment URL (from .env.testdata BASE_URL)
+     - Timestamp of failure
+   - **Severity/Priority**: Based on:
+     - Test type (smoke tests = high priority)
+     - User impact
+     - Frequency (always fails vs flaky)
+   - **Additional Context**:
+     - Error messages or stack traces from JSON report
+     - Related test files (if part of test suite)
+     - Relevant knowledge from knowledge-base.md
+
+3. Track created issues:
+   - Note the issue ID/number returned
+   - Update issue tracker memory with new bugs
+   - Prepare issue references for team communication
+\`\`\`
+
+**Note**: The issue tracker agent handles all duplicate detection and system integration automatically. Simply provide the bug details and let it manage the rest.`
+    },
+    {
+      role: "team-communicator",
+      contentBlock: `#### Team Communication
+
+Use the team-communicator agent to share verification results (primarily for Slack trigger, but can be used for other triggers):
+
+\`\`\`
+Use the team-communicator agent to:
+1. Post verification results summary
+2. Highlight critical failures that need immediate attention
+3. Share bugs logged with issue tracker links
+4. Provide manual verification checklist summary
+5. Recommend next steps based on results
+6. Tag relevant team members for critical issues
+7. Use appropriate urgency level based on failure severity
+\`\`\`
+
+The team communication should include:
+- **Execution summary**: Overall pass/fail statistics and timing
+- **Tests fixed**: Count of test issues fixed automatically
+- **Bugs logged**: Product bugs reported to issue tracker
+- **Manual checklist**: Summary of manual verification items
+- **Recommendation**: Safe to merge / Review required / Do not merge
+- **Test artifacts**: Links to reports, traces, screenshots
+
+**Communication strategy based on trigger**:
+- **Slack**: Post concise message with expandable details in thread
+- **Manual**: Full detailed report in terminal
+- **GitHub PR**: Comprehensive PR comment with tables and checklists
+- **CI/CD**: Build log output + optional Slack notification for critical failures
+
+**Update team communicator memory**:
+- Record verification communication
+- Track response patterns by trigger type
+- Document team preferences for detail level
+- Note which team members respond to which types of issues`
+    }
+  ],
+  requiredSubagents: ["test-runner", "test-debugger-fixer"]
+};
+
+// src/tasks/index.ts
+var TASK_TEMPLATES = {
+  [TASK_SLUGS.EXPLORE_APPLICATION]: exploreApplicationTask,
+  [TASK_SLUGS.GENERATE_TEST_CASES]: generateTestCasesTask,
+  [TASK_SLUGS.GENERATE_TEST_PLAN]: generateTestPlanTask,
+  [TASK_SLUGS.HANDLE_MESSAGE]: handleMessageTask,
+  [TASK_SLUGS.PROCESS_EVENT]: processEventTask,
+  [TASK_SLUGS.RUN_TESTS]: runTestsTask,
+  [TASK_SLUGS.VERIFY_CHANGES]: verifyChangesTask
+};
+function getTaskTemplate(slug) {
+  return TASK_TEMPLATES[slug];
+}
+function getAllTaskSlugs() {
+  return Object.keys(TASK_TEMPLATES);
+}
+function isTaskRegistered(slug) {
+  return TASK_TEMPLATES[slug] !== void 0;
+}
+function buildSlashCommandsConfig(slugs) {
+  const configs = {};
+  for (const slug of slugs) {
+    const task = TASK_TEMPLATES[slug];
+    if (!task) {
+      console.warn(`Unknown task slug: ${slug}, skipping`);
+      continue;
+    }
+    configs[slug] = {
+      frontmatter: task.frontmatter,
+      content: task.baseContent
+    };
+    console.log(`\u2713 Added slash command: /${slug}`);
+  }
+  return configs;
+}
+function getRequiredMCPsFromTasks(slugs) {
+  const mcps = /* @__PURE__ */ new Set();
+  for (const slug of slugs) {
+    const task = TASK_TEMPLATES[slug];
+    if (!task) continue;
+    for (const subagent of task.requiredSubagents) {
+      const mcpMap = {
+        "test-runner": "playwright",
+        "team-communicator": "slack",
+        "documentation-researcher": "notion",
+        "issue-tracker": "linear"
+      };
+      const mcp = mcpMap[subagent];
+      if (mcp) {
+        mcps.add(mcp);
+      }
+    }
+  }
+  return Array.from(mcps);
+}
+export {
+  TASK_SLUGS,
+  TASK_TEMPLATES,
+  buildSlashCommandsConfig,
+  getAllTaskSlugs,
+  getRequiredMCPsFromTasks,
+  getTaskTemplate,
+  isTaskRegistered
+};
+//# sourceMappingURL=index.js.map