@bugzy-ai/bugzy 1.16.0 → 1.18.0

package/dist/tasks/index.js

@@ -134,27 +134,12 @@ Example structure:
     {
       inline: true,
       title: "Generate All Manual Test Case Files",
-      content: `Generate ALL manual test case markdown files in the \`./test-cases/\` directory BEFORE invoking the test-code-generator agent.
-
-**For each test scenario from the previous step:**
-
-1. **Create test case file** in \`./test-cases/\` with format \`TC-XXX-feature-description.md\`
-2. **Include frontmatter** with:
-   - \`id:\` TC-XXX (sequential ID)
-   - \`title:\` Clear, descriptive title
-   - \`automated:\` true/false (based on automation decision)
-   - \`automated_test:\` (leave empty - will be filled by subagent when automated)
-   - \`type:\` exploratory/functional/regression/smoke
-   - \`area:\` Feature area/component
-3. **Write test case content**:
-   - **Objective**: Clear description of what is being tested
-   - **Preconditions**: Setup requirements, test data needed
-   - **Test Steps**: Numbered, human-readable steps
-   - **Expected Results**: What should happen at each step
-   - **Test Data**: Environment variables to use (e.g., \${TEST_BASE_URL}, \${TEST_OWNER_EMAIL})
-   - **Notes**: Any assumptions, clarifications needed, or special considerations
-
-**Output**: All manual test case markdown files created in \`./test-cases/\` with automation flags set`
+      content: `Generate ALL manual test case markdown files in \`./test-cases/\` BEFORE invoking the test-code-generator agent.
+
+Create files using \`TC-XXX-feature-description.md\` format. Follow the format of existing test cases in the directory. If no existing cases exist, include:
+- Frontmatter with test case metadata (id, title, type, area, \`automated: true/false\`, \`automated_test:\` empty)
+- Clear test steps with expected results
+- Required test data references (use env var names, not values)`
     },
     // Step 11: Automate Test Cases (inline - detailed instructions for test-code-generator)
     {
@@ -239,76 +224,14 @@ Move to the next area and repeat until all areas are complete.
     {
       inline: true,
       title: "Team Communication",
-      content: `{{INVOKE_TEAM_COMMUNICATOR}} to notify the product team about the new test cases and automated tests:
-
-\`\`\`
-1. Post an update about test case and automation creation
-2. Provide summary of coverage:
-   - Number of manual test cases created
-   - Number of automated tests created
-   - Features covered by automation
-   - Areas kept manual-only (and why)
-3. Highlight key automated test scenarios
-4. Share command to run automated tests (from \`./tests/CLAUDE.md\`)
-5. Ask for team review and validation
-6. Mention any areas needing exploration or clarification
-7. Use appropriate channel and threading for the update
-\`\`\`
-
-The team communication should include:
-- **Test artifacts created**: Manual test cases + automated tests count
-- **Automation coverage**: Which features are now automated
-- **Manual-only areas**: Why some tests are kept manual (rare scenarios, exploratory)
-- **Key automated scenarios**: Critical paths now covered by automation
-- **Running tests**: Command to execute automated tests
-- **Review request**: Ask team to validate scenarios and review test code
-- **Next steps**: Plans for CI/CD integration or additional test coverage
-
-**Update team communicator memory:**
-- Record this communication
-- Note test case and automation creation
-- Track team feedback on automation approach
-- Document any clarifications requested`,
+      content: `{{INVOKE_TEAM_COMMUNICATOR}} to share test case and automation results with the team, highlighting coverage areas, automation vs manual-only decisions, and any unresolved clarifications. Ask for team review.`,
       conditionalOnSubagent: "team-communicator"
     },
     // Step 17: Final Summary (inline)
     {
       inline: true,
       title: "Final Summary",
-      content: `Provide a comprehensive summary showing:
-
-**Manual Test Cases:**
-- Number of manual test cases created
-- List of test case files with IDs and titles
-- Automation status for each (automated: yes/no)
-
-**Automated Tests:**
-- Number of automated test scripts created
-- List of spec files with test counts
-- Page Objects created or updated
-- Fixtures and helpers added
-
-**Test Coverage:**
-- Features covered by manual tests
-- Features covered by automated tests
-- Areas kept manual-only (and why)
-
-**Next Steps:**
-- Command to run automated tests (from \`./tests/CLAUDE.md\`)
-- Instructions to run specific test file (from \`./tests/CLAUDE.md\`)
-- Note about copying .env.testdata to .env
-- Mention any exploration needed for edge cases
-
-**Important Notes:**
-- **Both Manual AND Automated**: Generate both artifacts - they serve different purposes
-- **Manual Test Cases**: Documentation, reference, can be executed manually when needed
-- **Automated Tests**: Fast, repeatable, for CI/CD and regression testing
-- **Automation Decision**: Not all test cases need automation - rare edge cases can stay manual
-- **Linking**: Manual test cases reference automated tests; automated tests reference manual test case IDs
-- **Two-Phase Workflow**: First generate all manual test cases, then automate area-by-area
-- **Ambiguity Handling**: Use exploration and clarification protocols before generating
-- **Environment Variables**: Use \`process.env.VAR_NAME\` in tests, update .env.testdata as needed
-- **Test Independence**: Each test must be runnable in isolation and in parallel`
+      content: `Provide a summary of created artifacts: manual test cases (count, IDs), automated tests (count, spec files), page objects and supporting files, coverage by area, and command to run tests (from \`./tests/CLAUDE.md\`).`
     }
   ],
   requiredSubagents: ["browser-automation", "test-code-generator"],
@@ -475,28 +398,7 @@ After saving the test plan:
     {
       inline: true,
       title: "Team Communication",
-      content: `{{INVOKE_TEAM_COMMUNICATOR}} to notify the product team about the new test plan:
-
-\`\`\`
-1. Post an update about the test plan creation
-2. Provide a brief summary of coverage areas and key features
-3. Mention any areas that need exploration or clarification
-4. Ask for team review and feedback on the test plan
-5. Include a link or reference to the test-plan.md file
-6. Use appropriate channel and threading for the update
-\`\`\`
-
-The team communication should include:
-- **Test plan scope**: Brief overview of what will be tested
-- **Coverage highlights**: Key features and user flows included
-- **Areas needing clarification**: Any uncertainties discovered during documentation research
-- **Review request**: Ask team to review and provide feedback
-- **Next steps**: Mention plan to generate test cases after review
-
-**Update team communicator memory:**
-- Record this communication in the team-communicator memory
-- Note this as a test plan creation communication
-- Track team response to this type of update`,
+      content: `{{INVOKE_TEAM_COMMUNICATOR}} to share the test plan with the team for review, highlighting coverage areas and any unresolved clarifications.`,
       conditionalOnSubagent: "team-communicator"
     },
     // Step 18: Final Summary (inline)
@@ -618,59 +520,7 @@ After processing the message through the handler and composing your response:
     // Step 7: Clarification Protocol (for ambiguous intents)
     "clarification-protocol",
     // Step 8: Knowledge Base Update (library)
-    "update-knowledge-base",
-    // Step 9: Key Principles (inline)
-    {
-      inline: true,
-      title: "Key Principles",
-      content: `## Key Principles
-
-### Context Preservation
-- Always maintain full conversation context
-- Link responses back to original uncertainties
-- Preserve reasoning chain for future reference
-
-### Actionable Responses
-- Convert team input into concrete actions
-- Don't let clarifications sit without implementation
-- Follow through on commitments made to team
-
-### Learning Integration
-- Each interaction improves our understanding
-- Build knowledge base of team preferences
-- Refine communication approaches over time
-
-### Quality Communication
-- Acknowledge team input appropriately
-- Provide updates on actions taken
-- Ask good follow-up questions when needed`
-    },
-    // Step 10: Important Considerations (inline)
-    {
-      inline: true,
-      title: "Important Considerations",
-      content: `## Important Considerations
-
-### Thread Organization
-- Keep related discussions in same thread
-- Start new threads for new topics
-- Maintain clear conversation boundaries
-
-### Response Timing
-- Acknowledge important messages promptly
-- Allow time for implementation before status updates
-- Don't spam team with excessive communications
-
-### Action Prioritization
-- Address urgent clarifications first
-- Batch related updates when possible
-- Focus on high-impact changes
-
-### Memory Maintenance
-- Keep active conversations visible and current
-- Archive resolved discussions appropriately
-- Maintain searchable history of resolutions`
-    }
+    "update-knowledge-base"
   ],
   requiredSubagents: ["team-communicator"],
   optionalSubagents: [],
@@ -1097,38 +947,7 @@ Create files if they don't exist:
 - \`.bugzy/runtime/memory/event-history.md\``
     },
     // Step 14: Knowledge Base Update (library)
-    "update-knowledge-base",
-    // Step 15: Important Considerations (inline)
-    {
-      inline: true,
-      title: "Important Considerations",
-      content: `## Important Considerations
-
-### Contextual Intelligence
-- Never process events in isolation - always consider full context
-- Use knowledge base, history, and external system state to inform decisions
-- What seems like a bug might be expected behavior given the context
-- A minor event might be critical when seen as part of a pattern
-
-### Adaptive Response
-- Same event type can require different actions based on context
-- Learn from each event to improve future decision-making
-- Build understanding of system behavior over time
-- Adjust responses based on business priorities and risk
-
-### Smart Task Generation
-- NEVER execute action tasks directly \u2014 all action tasks go through blocked-task-queue for team confirmation
-- Knowledge base updates and event history logging are the only direct operations
-- Document why each decision was made with full context
-- Skip redundant actions (e.g., duplicate events, already-processed issues)
-- Escalate appropriately based on pattern recognition
-
-### Continuous Learning
-- Each event adds to our understanding of the system
-- Update patterns when new correlations are discovered
-- Refine decision rules based on outcomes
-- Build institutional memory through event history`
-    }
+    "update-knowledge-base"
   ],
   requiredSubagents: ["team-communicator"],
   optionalSubagents: ["documentation-researcher", "issue-tracker"],
@@ -1394,33 +1213,13 @@ Store the detected trigger for use in output routing:
       title: "Coverage Gap vs. Ambiguity",
       content: `### Coverage Gap vs. Ambiguity
 
-When the trigger indicates a feature has been implemented and is ready for testing (Jira "Ready to Test", PR merged, CI/CD pipeline):
-
-**Missing test coverage for the referenced feature is a COVERAGE GAP, not an ambiguity.**
-
-- The developer/team is asserting the feature exists and is ready for testing
-- "Not yet explored" or "out of scope" in the test plan means the QA team hasn't tested it yet \u2014 it does NOT mean the feature doesn't exist
-- Do NOT classify as CRITICAL based on stale documentation or knowledge base gaps
-- If project-context.md or the Jira issue references the feature, assume it exists until browser exploration proves otherwise
-- Coverage gaps are handled in the "Create Tests for Coverage Gaps" step below \u2014 do NOT block here
+When the trigger indicates a feature is ready for testing (Jira "Ready to Test", PR merged, CI/CD):
 
-### If You Browse the App and Cannot Find the Referenced Feature
+**Missing test coverage is a COVERAGE GAP, not an ambiguity.** The trigger asserts the feature exists. Do NOT block based on stale docs or knowledge base gaps. Coverage gaps are handled in "Create Tests for Coverage Gaps" below.
 
-Apply the Clarification Protocol's **"Execution Obstacle vs. Requirement Ambiguity"** principle:
+**If you can't find the referenced feature in the browser:** Apply the Clarification Protocol's execution obstacle principle. The authoritative trigger asserts it exists \u2014 this is an execution obstacle (wrong role, missing test data, feature flags, env config). PROCEED to create tests, add placeholder env vars, notify team about the access issue. Tests may fail until resolved \u2014 that's expected.
 
-This is an **execution obstacle**, NOT a requirement ambiguity \u2014 because the authoritative trigger source (Jira issue, PR, team request) asserts the feature exists. Common causes for not finding it:
-- **Missing role/tier**: You're logged in as a basic user but the feature requires admin/premium access
-- **Missing test data**: Required test accounts or data haven't been configured in \`.env.testdata\`
-- **Feature flags**: The feature is behind a flag not enabled in the test environment
-- **Environment config**: The feature requires specific environment variables or deployment settings
-
-**Action: PROCEED to "Create Tests for Coverage Gaps".** Do NOT BLOCK.
-- Create test cases and specs that reference the feature as described in the trigger
-- Add placeholder env vars to \`.env.testdata\` for any missing credentials
-- Notify the team (via team-communicator) about the access obstacle and what needs to be configured
-- Tests may fail until the obstacle is resolved \u2014 this is expected and acceptable
-
-**Only classify as CRITICAL (and BLOCK) if NO authoritative trigger source claims the feature exists** \u2014 e.g., a vague manual request with no Jira/PR backing.`
+**Only BLOCK if NO authoritative trigger source claims the feature exists** (e.g., vague manual request with no Jira/PR backing).`
     },
     // Step 6: Clarification Protocol (library)
     "clarification-protocol",
@@ -1811,44 +1610,11 @@ Post PR comment if GitHub context available.`,
     {
       inline: true,
       title: "Handle Special Cases",
-      content: `**If no tests found for changed files:**
-- Inform user: "No automated tests found for changed files"
-- Recommend: "Run smoke test suite for basic validation"
-- Still generate manual verification checklist
-
-**If all tests skipped:**
-- Explain why (dependencies, environment issues)
-- Recommend: Check test configuration and prerequisites
-
-**If test execution fails:**
-- Report specific error (test framework not installed, env vars missing)
-- Suggest troubleshooting steps
-- Don't proceed with triage if tests didn't run
-
-## Important Notes
-
-- This task handles **all trigger sources** with a single unified workflow
-- Trigger detection is automatic based on input format
-- Output is automatically routed to the appropriate channel
-- Automated tests are executed with **full triage and automatic fixing**
-- Manual verification checklists are generated for **non-automatable scenarios**
-- Product bugs are logged with **automatic duplicate detection**
-- Test issues are fixed automatically with **verification**
-- Results include both automated and manual verification items
-
-## Success Criteria
-
-A successful verification includes:
-1. Trigger source correctly detected
-2. Context extracted completely
-3. Tests executed (or skipped with explanation)
-4. All failures triaged (product bug vs test issue)
-5. Test issues fixed automatically (when possible)
-6. Product bugs logged to issue tracker
-7. Manual verification checklist generated
-8. Results formatted for output channel
-9. Results delivered to appropriate destination
-10. Clear recommendation provided (merge / review / block)`
+      content: `**If no tests found for changed files:** recommend smoke test suite, still generate manual verification checklist.
+
+**If all tests skipped:** explain why (dependencies, environment), recommend checking configuration.
+
+**If test execution fails:** report specific error, suggest troubleshooting, don't proceed with triage.`
     }
   ],
   requiredSubagents: ["browser-automation", "test-debugger-fixer"],