@bugzy-ai/bugzy 1.18.1 → 1.18.3

package/dist/cli/index.cjs

@@ -89,6 +89,7 @@ var init_constants = __esm({
       RUN_TESTS: "run-tests",
       VERIFY_CHANGES: "verify-changes",
       TRIAGE_RESULTS: "triage-results",
+      EXPLORE_TEST_CODEBASE: "explore-test-codebase",
       /** @deprecated Use ONBOARD_TESTING instead */
       FULL_TEST_COVERAGE: "onboard-testing"
     };
@@ -2052,6 +2053,103 @@ Output this JSON as the final result of the task.`
   }
 });
 
+// src/tasks/library/explore-test-codebase.ts
+var exploreTestCodebaseTask;
+var init_explore_test_codebase = __esm({
+  "src/tasks/library/explore-test-codebase.ts"() {
+    "use strict";
+    init_cjs_shims();
+    init_constants();
+    exploreTestCodebaseTask = {
+      slug: TASK_SLUGS.EXPLORE_TEST_CODEBASE,
+      name: "Explore Test Codebase",
+      description: "Analyze external test repository to understand framework, coverage, and conventions",
+      frontmatter: {
+        description: "Analyze external test codebase for BYOT onboarding",
+        "argument-hint": "--focus [area]"
+      },
+      steps: [
+        // Step 1: Overview (inline)
+        {
+          inline: true,
+          title: "Explore Test Codebase Overview",
+          content: `Analyze the external test repository to understand the testing framework, test coverage, conventions, and codebase structure. This task is triggered during BYOT (Bring Your Own Tests) onboarding to help Bugzy understand the customer's existing test suite.`
+        },
+        // Step 2: Security Notice
+        "security-notice",
+        // Step 3: Arguments (inline)
+        {
+          inline: true,
+          title: "Arguments",
+          content: `**Arguments**: $ARGUMENTS
+
+**Parse:**
+- **focus**: specific area to analyze (default: comprehensive)`
+        },
+        // Setup
+        "load-project-context",
+        "read-knowledge-base",
+        // Core analysis
+        "analyze-test-codebase",
+        // Generate results parser for normalizing test output
+        "create-results-parser",
+        // Optional: explore the app itself if URL is available
+        {
+          inline: true,
+          title: "App Exploration (Optional)",
+          content: `If the project has an app URL configured (check \`.bugzy/runtime/project-context.md\` or env vars for TEST_APP_HOST), {{INVOKE_BROWSER_AUTOMATION}} to briefly explore the application:
+
+1. Navigate to the app URL
+2. Identify main navigation and key pages
+3. Map discovered features to test coverage from the codebase analysis
+4. Note any features that appear untested
+
+This step helps correlate what the tests cover with what the application actually contains. Skip if no app URL is available.`,
+          conditionalOnSubagent: "browser-automation"
+        },
+        // Generate output
+        {
+          inline: true,
+          title: "Commit Analysis Results",
+          content: `Commit analysis artifacts to the **parent project repository** (the workspace root).
+
+**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.
+
+**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.`
+        },
+        // Team Communication (conditional)
+        {
+          inline: true,
+          title: "Team Communication",
+          content: `{{INVOKE_TEAM_COMMUNICATOR}} to notify the team about the test codebase analysis:
+
+\`\`\`
+1. Post a summary of the analysis findings
+2. Include key information:
+   - Test framework and runner identified
+   - Number of test files and estimated test cases
+   - Feature areas covered by existing tests
+   - Any gaps or areas without test coverage
+3. Ask if the analysis looks accurate
+4. Use appropriate channel and threading
+\`\`\``,
+          conditionalOnSubagent: "team-communicator"
+        },
+        // Maintenance
+        "update-knowledge-base"
+      ],
+      requiredSubagents: ["browser-automation"],
+      optionalSubagents: ["team-communicator"],
+      dependentTasks: []
+    };
+  }
+});
+
 // src/tasks/index.ts
 var tasks_exports = {};
 __export(tasks_exports, {
@@ -2088,6 +2186,7 @@ var init_tasks = __esm({
     init_onboard_testing();
     init_explore_application();
     init_triage_results();
+    init_explore_test_codebase();
     init_constants();
     TASK_TEMPLATES = {
       [TASK_SLUGS.GENERATE_TEST_CASES]: generateTestCasesTask,
@@ -2098,7 +2197,8 @@ var init_tasks = __esm({
       [TASK_SLUGS.VERIFY_CHANGES]: verifyChangesTask,
       [TASK_SLUGS.ONBOARD_TESTING]: onboardTestingTask,
       [TASK_SLUGS.EXPLORE_APPLICATION]: exploreApplicationTask,
-      [TASK_SLUGS.TRIAGE_RESULTS]: triageResultsTask
+      [TASK_SLUGS.TRIAGE_RESULTS]: triageResultsTask,
+      [TASK_SLUGS.EXPLORE_TEST_CODEBASE]: exploreTestCodebaseTask
     };
   }
 });
@@ -5834,6 +5934,90 @@ Requirements clear? \u2192 YES \u2192 Quick Exploration \u2192 Matches? \u2192 Y
   tags: ["exploration", "protocol", "adaptive"]
 };
 
+// src/tasks/steps/exploration/analyze-test-codebase.ts
+init_cjs_shims();
+var analyzeTestCodebaseStep = {
+  id: "analyze-test-codebase",
+  title: "Analyze Test Codebase",
+  category: "exploration",
+  content: `## Analyze External Test Codebase
+
+Thoroughly analyze the customer's external test repository to understand their testing framework, conventions, coverage, and codebase structure.
+
+### Step 1: Check for CLAUDE.md
+
+Look for a \`CLAUDE.md\` file in the test repository root (\`./tests/CLAUDE.md\` or \`./CLAUDE.md\`). If it exists, read it to understand the project's documented conventions, setup instructions, and testing patterns.
+
+### Step 2: Scan Directory Structure
+
+Examine the repository structure to understand organization:
+- List top-level directories and files
+- Identify test directories (e.g., \`tests/\`, \`__tests__/\`, \`e2e/\`, \`spec/\`, \`cypress/\`)
+- Note configuration files (e.g., \`playwright.config.ts\`, \`cypress.config.ts\`, \`jest.config.js\`, \`vitest.config.ts\`)
+- Check \`package.json\` for test scripts and dependencies
+
+### Step 3: Identify Test Framework
+
+Determine the testing framework from configuration files and dependencies:
+- **Playwright**: \`playwright.config.ts\`, \`@playwright/test\` in dependencies
+- **Cypress**: \`cypress.config.ts\`, \`cypress\` in dependencies
+- **Jest**: \`jest.config.js\`, \`jest\` in dependencies
+- **Vitest**: \`vitest.config.ts\`, \`vitest\` in dependencies
+- **Other**: Check for \`mocha\`, \`ava\`, \`tap\`, custom runners
+
+Note the test runner, assertion library, and any additional tooling (e.g., \`msw\`, \`testing-library\`, page objects).
+
+### Step 4: Catalog Test Coverage
+
+Analyze test files to understand what's being tested:
+- Read test file names and directory organization
+- Parse \`describe()\` / \`it()\` / \`test()\` blocks to understand test structure
+- Group tests by feature area (e.g., authentication, checkout, user management)
+- Count total test files and approximate number of test cases
+- Note any skipped or pending tests
+
+### Step 5: Document Conventions
+
+Identify testing patterns and conventions:
+- **Naming patterns**: How test files are named (e.g., \`*.spec.ts\`, \`*.test.ts\`, \`*.e2e.ts\`)
+- **Page Objects / Fixtures**: Look for page object patterns, custom fixtures, or helper utilities
+- **Data management**: How test data is handled (fixtures, factories, seeds)
+- **Environment configuration**: How environments are configured (.env files, config objects)
+- **CI integration**: Check for CI config files (GitHub Actions, CircleCI, etc.)
+
+### Step 6: Generate Summary
+
+Create a structured summary of findings and commit it to the project repository:
+
+\`\`\`
+File: .bugzy/runtime/test-codebase-analysis.md
+
+Contents:
+- Framework: [name and version]
+- Test runner: [runner]
+- Total test files: [count]
+- Estimated test cases: [count]
+- Feature areas covered: [list]
+- Key conventions: [summary]
+- Directory structure: [overview]
+- Notable patterns: [page objects, fixtures, etc.]
+\`\`\`
+
+### Step 7: Generate CLAUDE.md (if missing)
+
+If the external test repository does NOT have a \`CLAUDE.md\`, generate a framework-appropriate draft based on the analysis findings:
+- Include discovered framework and runner
+- Document build/run commands from package.json
+- Note key conventions discovered
+- Include directory structure overview
+- Save as a draft for customer review
+
+**Important**: Do NOT use the Playwright-specific template \u2014 generate content based on what was actually discovered in the repository.
+
+Commit the analysis results to the project repo so they are available for future task executions.`,
+  tags: ["exploration", "byot", "analysis"]
+};
+
 // src/tasks/steps/clarification/clarification-protocol.ts
 init_cjs_shims();
 var clarificationProtocolStep = {
@@ -7037,6 +7221,7 @@ var STEP_LIBRARY = {
   "gather-documentation": gatherDocumentationStep,
   // Exploration
   "exploration-protocol": explorationProtocolStep,
+  "analyze-test-codebase": analyzeTestCodebaseStep,
   // Clarification
   "clarification-protocol": clarificationProtocolStep,
   // Execution