@bugzy-ai/bugzy 1.18.0 → 1.18.2

package/dist/cli/index.js

@@ -20,12 +20,12 @@ var __copyProps = (to, from, except, desc) => {
 };
 var __toCommonJS = (mod) => __copyProps(__defProp({}, "__esModule", { value: true }), mod);
 
-// node_modules/.pnpm/tsup@8.5.0_postcss@8.5.6_typescript@5.9.3/node_modules/tsup/assets/esm_shims.js
+// node_modules/.pnpm/tsup@8.5.1_postcss@8.5.6_typescript@5.9.3/node_modules/tsup/assets/esm_shims.js
 import path from "path";
 import { fileURLToPath } from "url";
 var getFilename, getDirname, __dirname;
 var init_esm_shims = __esm({
-  "node_modules/.pnpm/tsup@8.5.0_postcss@8.5.6_typescript@5.9.3/node_modules/tsup/assets/esm_shims.js"() {
+  "node_modules/.pnpm/tsup@8.5.1_postcss@8.5.6_typescript@5.9.3/node_modules/tsup/assets/esm_shims.js"() {
     "use strict";
     getFilename = () => fileURLToPath(import.meta.url);
     getDirname = () => path.dirname(getFilename());
@@ -81,6 +81,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"
     };
@@ -785,7 +786,29 @@ Read \`.bugzy/runtime/memory/event-history.md\` to:
 - List \`./test-cases/\` for existing tests
 - Check \`.bugzy/runtime/knowledge-base.md\` for past insights
 
-#### 2.4 Event-Action Reference Patterns
+#### 2.4 Knowledge Base: Drafted vs Real Tests (BYOT)
+
+When the project uses an external test repository, maintain two sections in \`.bugzy/runtime/knowledge-base.md\`:
+
+**Drafted Tests** (Open PRs \u2014 tests not yet merged):
+\`\`\`markdown
+### Drafted Tests
+| PR | Branch | Tests Added | Status | Date |
+|----|--------|-------------|--------|------|
+| #12 | bugzy/verify-changes-a1b2c3d4 | login.spec.ts, checkout.spec.ts | Open | 2026-02-13 |
+\`\`\`
+
+**Active Tests** (Merged \u2014 tests are part of the test suite):
+\`\`\`markdown
+### Active Tests
+| File | What it tests | Source PR | Merged |
+|------|---------------|-----------|--------|
+| login.spec.ts | Login flow with valid/invalid credentials | #12 | 2026-02-13 |
+\`\`\`
+
+Move entries from Drafted \u2192 Active Tests when PRs are merged. Remove entries when PRs are closed without merge.
+
+#### 2.5 Event-Action Reference Patterns
 
 Use these as reference patterns for common events. The webhook routing system already handles events with specific default tasks (e.g., deployment_status \u2192 /run-tests). Process-event receives events that need analysis.
 
@@ -804,6 +827,23 @@ Use these as reference patterns for common events. The webhook routing system al
 - **QA-relevant content found**: Propose appropriate follow-up tasks (e.g., \`/generate-test-cases\`, \`/verify-changes\`)
 - **No QA content** (HR meeting, offsite planning, etc.): Skip \u2014 log to event history only
 
+**External Test Repo Events** (BYOT - events from the customer's external test repository):
+- **PR opened by Bugzy** (\`com.github.external_repo.pull_request\`, \`action: "opened"\`, branch starts with \`bugzy/\`):
+  Log to Knowledge Base under "Drafted Tests". No action task needed \u2014 just record the PR number, branch, and what tests were added.
+- **PR review submitted** (\`com.github.external_repo.pull_request_review\`):
+  If changes were requested \u2192 queue \`/verify-changes\` with \`{"existingPrBranch": "{head.ref}", "context": "PR review feedback: {review.body}"}\`.
+  The execution will iterate on the existing branch, push fixes, and skip PR creation.
+- **PR comment** (\`com.github.external_repo.pull_request_comment\`):
+  Read the comment. If it contains actionable feedback, queue \`/verify-changes\`
+  with \`{"existingPrBranch": "{issue.pull_request.head.ref}"}\`.
+- **PR merged** (\`com.github.external_repo.pull_request\`, \`action: "closed"\`, \`merged: true\`):
+  Update Knowledge Base: move entries from "Drafted Tests" to "Active Tests". Notify team of new test coverage.
+  The submodule pointer update happens automatically via the container (\`updateSubmoduleToLatest\`).
+- **PR closed without merge** (\`com.github.external_repo.pull_request\`, \`action: "closed"\`, \`merged: false\`):
+  Remove from Knowledge Base "Drafted Tests". Notify team that tests were rejected.
+- **Direct push to main** (\`com.github.external_repo.push\`, ref is main/master):
+  Update Knowledge Base if test files were affected. Submodule pointer update is automatic.
+
 **Other Events:**
 - Analyze for QA relevance based on knowledge base and project context
 - If action needed, propose appropriate task. If not, log and skip.
@@ -2005,6 +2045,101 @@ 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_esm_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 all analysis artifacts to the project repository:
+
+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)
+
+Use a clear commit message: "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, {
@@ -2041,6 +2176,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,
@@ -2051,7 +2187,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
     };
   }
 });
@@ -5787,6 +5924,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_esm_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_esm_shims();
 var clarificationProtocolStep = {
@@ -6990,6 +7211,7 @@ var STEP_LIBRARY = {
   "gather-documentation": gatherDocumentationStep,
   // Exploration
   "exploration-protocol": explorationProtocolStep,
+  "analyze-test-codebase": analyzeTestCodebaseStep,
   // Clarification
   "clarification-protocol": clarificationProtocolStep,
   // Execution