@bugzy-ai/bugzy 1.18.2 → 1.18.4

package/dist/tasks/index.js

@@ -135,20 +135,20 @@ Example structure:
     {
       inline: true,
       title: "Generate All Manual Test Case Files",
-      content: `Generate ALL manual test case markdown files in \`./test-cases/\` BEFORE invoking the test-code-generator agent.
+      content: `Generate ALL manual test case markdown files in \`./test-cases/\` BEFORE invoking the test-engineer agent.
 
 Create files using \`TC-XXX-feature-description.md\` format. Follow the format of existing test cases in the directory. If no existing cases exist, include:
 - Frontmatter with test case metadata (id, title, type, area, \`automated: true/false\`, \`automated_test:\` empty)
 - Clear test steps with expected results
 - Required test data references (use env var names, not values)`
     },
-    // Step 11: Automate Test Cases (inline - detailed instructions for test-code-generator)
+    // Step 11: Automate Test Cases (inline - detailed instructions for test-engineer)
     {
       inline: true,
       title: "Automate Test Cases Area by Area",
       content: `**IMPORTANT**: Process each feature area separately to enable incremental, focused test creation.
 
-**For each area**, invoke the test-code-generator agent:
+**For each area**, invoke the test-engineer agent:
 
 **Prepare Area Context:**
 Before invoking the agent, identify the test cases for the current area:
@@ -160,9 +160,9 @@ Before invoking the agent, identify the test cases for the current area:
 - Existing automated tests in ./tests/specs/
 - Existing Page Objects in ./tests/pages/
 
-**Invoke test-code-generator Agent:**
+**Invoke test-engineer Agent:**
 
-{{INVOKE_TEST_CODE_GENERATOR}} for the current area with the following context:
+{{INVOKE_TEST_ENGINEER}} for the current area with the following context:
 
 "Automate test cases for the [AREA_NAME] area.
 
@@ -176,7 +176,7 @@ Before invoking the agent, identify the test cases for the current area:
 - Existing page objects: [directory from ./tests/CLAUDE.md]
 
 **Knowledge Base Patterns (MUST APPLY):**
-Include ALL relevant testing patterns from the knowledge base that apply to this area. For example, if the KB documents timing behaviors (animation delays, loading states), selector gotchas, or recommended assertion approaches \u2014 list them here explicitly and instruct the agent to use the specific patterns described (e.g., specific assertion methods with specific timeouts). The test-code-generator does not have access to the knowledge base, so you MUST relay the exact patterns and recommended code approaches.
+Include ALL relevant testing patterns from the knowledge base that apply to this area. For example, if the KB documents timing behaviors (animation delays, loading states), selector gotchas, or recommended assertion approaches \u2014 list them here explicitly and instruct the agent to use the specific patterns described (e.g., specific assertion methods with specific timeouts). The test-engineer does not have access to the knowledge base, so you MUST relay the exact patterns and recommended code approaches.
 
 **The agent should:**
 1. Read the manual test case files for this area
@@ -235,7 +235,7 @@ Move to the next area and repeat until all areas are complete.
       content: `Provide a summary of created artifacts: manual test cases (count, IDs), automated tests (count, spec files), page objects and supporting files, coverage by area, and command to run tests (from \`./tests/CLAUDE.md\`).`
     }
   ],
-  requiredSubagents: ["browser-automation", "test-code-generator"],
+  requiredSubagents: ["browser-automation", "test-engineer"],
   optionalSubagents: ["documentation-researcher", "team-communicator"],
   dependentTasks: []
 };
@@ -422,10 +422,10 @@ After saving the test plan:
 var handleMessageTask = {
   slug: TASK_SLUGS.HANDLE_MESSAGE,
   name: "Handle Message",
-  description: "Handle team responses and Slack communications, maintaining context for ongoing conversations (LLM-routed)",
+  description: "Handle team messages, maintaining context for ongoing conversations",
   frontmatter: {
-    description: "Handle team responses and Slack communications, maintaining context for ongoing conversations",
-    "argument-hint": "[slack thread context or team message]"
+    description: "Handle team messages, maintaining context for ongoing conversations",
+    "argument-hint": "[team thread context or message]"
   },
   steps: [
     // Step 1: Overview (inline)
@@ -434,7 +434,7 @@ var handleMessageTask = {
       title: "Handle Message Overview",
       content: `# Handle Message Command
 
-Process team responses from Slack threads and handle multi-turn conversations with the product team about testing clarifications, ambiguities, and questions.`
+Process team messages and handle multi-turn conversations with the product team about testing clarifications, ambiguities, and questions.`
     },
     // Step 2: Security Notice (library)
     "security-notice",
@@ -448,19 +448,19 @@ Process team responses from Slack threads and handle multi-turn conversations wi
     "load-project-context",
     // Step 5: Knowledge Base Read (library)
     "read-knowledge-base",
-    // Step 5: Detect Intent (inline - task-specific)
+    // Step 6: Detect Intent (inline - simplified, no handler file loading)
     {
       inline: true,
-      title: "Detect Message Intent and Load Handler",
-      content: `Before processing the message, identify the intent type to load the appropriate handler.
+      title: "Detect Message Intent",
+      content: `Identify the intent type from the event payload or message patterns:
 
-#### 0.1 Extract Intent from Event Payload
+#### 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)
+#### Fallback Intent Detection (if no intent provided)
 
 If intent is not in the payload, detect from message patterns:
 
@@ -471,39 +471,125 @@ If intent is not in the payload, detect from message patterns:
 | Question words: "what", "which", "do we have", "is there" about tests/project | \`question\` |
 | Default (none of above) | \`feedback\` |
 
-#### 0.3 Load Handler File
+Then follow the matching handler section below.`
+    },
+    // Step 7: Process by Intent (all three handlers consolidated)
+    {
+      inline: true,
+      title: "Process Message by Intent",
+      content: `Based on the detected intent, follow the appropriate section:
+
+---
+
+## If intent = "feedback"
+
+### Step 1: Parse Feedback
+
+Extract the following from the message:
+
+| Field | Description |
+|-------|-------------|
+| **Type** | \`bug_report\`, \`test_result\`, \`observation\`, \`suggestion\`, \`general\` |
+| **Severity** | \`critical\`, \`high\`, \`medium\`, \`low\` |
+| **Component** | Affected area (e.g., "login", "checkout") |
+| **Description** | Core issue description |
+| **Expected** | What should happen (if stated) |
+| **Steps** | How to reproduce (if provided) |
+
+**Type Detection**:
+- \`bug_report\`: "bug", "broken", "doesn't work", "error", "crash"
+- \`test_result\`: "test passed", "test failed", "ran tests", "testing showed"
+- \`observation\`: "noticed", "observed", "found that", "saw that"
+- \`suggestion\`: "should", "could we", "what if", "idea"
+- \`general\`: Default for unclassified feedback
+
+### Step 2: Update Test Case Specifications
+
+**CRITICAL**: When feedback requests changes to test behavior (e.g., "change the expected result", "update the test to check for X", "the test should verify Y instead"), you MUST update the test case markdown files to reflect the requested changes.
+
+For each actionable feedback item:
+1. Identify which test case(s) are affected
+2. Read the test case markdown file
+3. Update the test steps, expected results, or assertions as requested
+4. Save the modified test case file
+
+This step updates the **specification** (markdown test case files) only. The \`sync-automation-from-feedback\` step that follows handles syncing the **implementation** (automation code) to match.
+
+### Step 3: Acknowledge and Confirm
+
+Respond confirming: feedback received, summary of what was captured, actions taken (including any test case updates), and follow-up questions if needed.
+
+---
+
+## If intent = "question"
+
+### Step 1: Classify Question Type
+
+| Type | Indicators | Primary Context Sources |
+|------|------------|------------------------|
+| **Coverage** | "what tests", "do we have", "is there a test for" | test-cases/, test-plan.md |
+| **Results** | "did tests pass", "what failed", "test results" | test-runs/ |
+| **Knowledge** | "how does", "what is", "explain" | knowledge-base.md |
+| **Plan** | "what's in scope", "test plan", "testing strategy" | test-plan.md |
+| **Process** | "how do I", "when should", "what's the workflow" | project-context.md |
+
+### Step 2: Load Relevant Context
 
-Based on detected intent, load the handler from:
-\`.bugzy/runtime/handlers/messages/{intent}.md\`
+Based on question type, load the appropriate files:
+- **Coverage**: Read test-plan.md, list ./test-cases/, search for relevant keywords
+- **Results**: List ./test-runs/ (newest first), read summary.json from relevant runs
+- **Knowledge**: Read .bugzy/runtime/knowledge-base.md, search for relevant entries
+- **Plan**: Read test-plan.md, extract relevant sections
+- **Process**: Read .bugzy/runtime/project-context.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
+### Step 3: Formulate Answer
 
-#### 0.4 Follow Handler Instructions
+- Be specific: quote relevant sections from source files
+- Cite sources: mention which files contain the information
+- Quantify when possible: "We have 12 test cases covering login..."
+- Acknowledge gaps if information is incomplete
+
+### Step 4: Offer Follow-up
+
+End response with offer to provide more detail and suggest related information.
+
+---
 
-**IMPORTANT**: The handler file is authoritative for this intent type.
+## If intent = "status"
 
-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
+### Step 1: Identify Status Scope
 
-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`
+| Scope | Indicators | Data Sources |
+|-------|------------|--------------|
+| **Latest test run** | "last run", "recent tests", "how did tests go" | Most recent test-runs/ directory |
+| **Specific test** | Test ID mentioned (TC-XXX) | test-runs/*/TC-XXX/, test-cases/TC-XXX.md |
+| **Overall** | "overall", "all tests", "pass rate" | All test-runs/ summaries |
+| **Task progress** | "is the task done", "what's happening with" | team-communicator memory |
+
+### Step 2: Gather Status Data
+
+Based on scope, read the appropriate test-runs/ directories and summary files. Calculate aggregate statistics for overall status requests.
+
+### Step 3: Format Status Report
+
+Present status clearly: lead with pass/fail summary, use bullet points, include timestamps, offer to drill down into specifics.
+
+### Step 4: Provide Context and Recommendations
+
+For failing tests: suggest review, note if new or recurring. For declining trends: highlight causes. For good results: acknowledge healthy state.`
+    },
+    // Step 8: Sync automation from feedback (conditional on test-engineer)
+    {
+      stepId: "sync-automation-from-feedback",
+      conditionalOnSubagent: "test-engineer"
     },
-    // Step 6: Post Response via Team Communicator
+    // Step 9: Post Response via Team Communicator
     {
       inline: true,
       title: "Post Response to Team",
       content: `## Post Response to the Team
 
-After processing the message through the handler and composing your response:
+After processing the message and composing your response:
 
 {{INVOKE_TEAM_COMMUNICATOR}} to post the response back to the team.
 
@@ -518,13 +604,13 @@ After processing the message through the handler and composing your response:
 - Ask the user whether to post \u2014 the message came from the team, the response goes back to the team
 - Compose a draft without sending it`
     },
-    // Step 7: Clarification Protocol (for ambiguous intents)
+    // Step 10: Clarification Protocol (for ambiguous intents)
     "clarification-protocol",
-    // Step 8: Knowledge Base Update (library)
+    // Step 11: Knowledge Base Update (library)
     "update-knowledge-base"
   ],
   requiredSubagents: ["team-communicator"],
-  optionalSubagents: [],
+  optionalSubagents: ["test-engineer"],
   dependentTasks: ["verify-changes"]
 };
 
@@ -1124,7 +1210,7 @@ If selected test cases have formatting issues:
 
 **Failure Handling**:
 - Test failures are automatically triaged (product bugs vs test issues)
-- Test issues are automatically fixed by the test-debugger-fixer subagent
+- Test issues are automatically fixed by the test-engineer 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
@@ -1141,7 +1227,7 @@ If selected test cases have formatting issues:
       conditionalOnSubagent: "team-communicator"
     }
   ],
-  requiredSubagents: ["browser-automation", "test-debugger-fixer"],
+  requiredSubagents: ["browser-automation", "test-engineer"],
   optionalSubagents: ["issue-tracker", "team-communicator"],
   dependentTasks: []
 };
@@ -1421,7 +1507,7 @@ Generate summary of test selection based on description analysis:
 - **Execution strategy**: [smart selection | full suite | smoke tests | user-specified]
 \`\`\``
     },
-    // Step 7b: Create Tests for Coverage Gaps (conditional - test-code-generator)
+    // Step 7b: Create Tests for Coverage Gaps (conditional - test-engineer)
     {
       inline: true,
       title: "Create Tests for Coverage Gaps",
@@ -1457,7 +1543,7 @@ If the Jira issue or PR references test accounts/data (e.g., TEST_PREMIUM_USER,
 
 ### Generate Automated Test Specs
 
-{{INVOKE_TEST_CODE_GENERATOR}} to create automated test specs:
+{{INVOKE_TEST_ENGINEER}} to create automated test specs:
 - Read the manual test cases you just created
 - Explore the feature in the browser to discover selectors and flows
 - Create page objects in the directory specified by \`./tests/CLAUDE.md\`
@@ -1468,7 +1554,7 @@ If the Jira issue or PR references test accounts/data (e.g., TEST_PREMIUM_USER,
 ### If Tests Already Cover the Feature
 
 Skip this step \u2014 proceed directly to running existing tests.`,
-      conditionalOnSubagent: "test-code-generator"
+      conditionalOnSubagent: "test-engineer"
     },
     // Step 8-11: Test Execution (library steps)
     "run-tests",
@@ -1657,8 +1743,8 @@ Post PR comment if GitHub context available.`,
 **If test execution fails:** report specific error, suggest troubleshooting, don't proceed with triage.`
     }
   ],
-  requiredSubagents: ["browser-automation", "test-debugger-fixer"],
-  optionalSubagents: ["documentation-researcher", "issue-tracker", "team-communicator", "changelog-historian", "test-code-generator"],
+  requiredSubagents: ["browser-automation", "test-engineer"],
+  optionalSubagents: ["documentation-researcher", "issue-tracker", "team-communicator", "changelog-historian"],
   dependentTasks: []
 };
 
@@ -1734,7 +1820,7 @@ This command orchestrates the complete test coverage workflow in a single execut
     },
     "generate-final-report"
   ],
-  requiredSubagents: ["browser-automation", "test-code-generator", "test-debugger-fixer"],
+  requiredSubagents: ["browser-automation", "test-engineer"],
   optionalSubagents: ["documentation-researcher", "team-communicator", "issue-tracker"],
   dependentTasks: ["run-tests", "generate-test-cases"]
 };
@@ -1843,7 +1929,7 @@ This task is triggered automatically when test results are submitted to the Bugz
     "normalize-test-results",
     // Step 7: Triage Failures (existing library step)
     "triage-failures",
-    // Step 8: Fix Test Issues (library — uses test-debugger-fixer)
+    // Step 8: Fix Test Issues (library — uses test-engineer)
     "fix-test-issues",
     // Step 9: Log Product Bugs (conditional — requires issue-tracker)
     {
@@ -1902,7 +1988,7 @@ Create a structured triage report as the task output. This report is stored in \
 Output this JSON as the final result of the task.`
     }
   ],
-  requiredSubagents: ["browser-automation", "test-debugger-fixer"],
+  requiredSubagents: ["browser-automation", "test-engineer"],
   optionalSubagents: ["issue-tracker", "team-communicator"],
   dependentTasks: []
 };
@@ -1959,12 +2045,14 @@ This step helps correlate what the tests cover with what the application actuall
     {
       inline: true,
       title: "Commit Analysis Results",
-      content: `Commit all analysis artifacts to the project repository:
+      content: `Commit analysis artifacts to the **parent project repository** (the workspace root).
 
-1. The test codebase analysis report (\`.bugzy/runtime/test-codebase-analysis.md\`)
-2. Any generated CLAUDE.md draft (if the external repo was missing one)
+**IMPORTANT \u2014 Do NOT stage the \`tests\` submodule.** The \`tests/\` directory is an external git submodule. Any changes made inside it (e.g., \`reporters/parse-results.ts\`, \`tests/CLAUDE.md\`) will be committed and pushed to the external repo automatically by the post-execution handler. Staging the submodule in the parent would record a local-only commit SHA that doesn't exist on the remote, causing a broken reference.
 
-Use a clear commit message: "chore: analyze external test codebase"
+**What to commit in the parent repo:**
+1. \`git add .bugzy/\` \u2014 the test codebase analysis report and runtime files
+2. Do NOT run \`git add .\` or \`git add tests\` \u2014 this would stage the submodule pointer
+3. \`git commit -m "chore: analyze external test codebase"\`
 
 These artifacts will be available to all future task executions for this project.`
     },