@bugzy-ai/bugzy 1.19.3 → 1.20.0

package/dist/cli/index.cjs

@@ -31,12 +31,12 @@ var __toESM = (mod, isNodeMode, target) => (target = mod != null ? __create(__ge
 ));
 var __toCommonJS = (mod) => __copyProps(__defProp({}, "__esModule", { value: true }), mod);
 
-// node_modules/.pnpm/tsup@8.5.1_postcss@8.5.6_typescript@5.9.3/node_modules/tsup/assets/cjs_shims.js
+// node_modules/.pnpm/tsup@8.5.0_postcss@8.5.6_typescript@5.9.3/node_modules/tsup/assets/cjs_shims.js
 var getImportMetaUrl, importMetaUrl;
 var init_cjs_shims = __esm({
-  "node_modules/.pnpm/tsup@8.5.1_postcss@8.5.6_typescript@5.9.3/node_modules/tsup/assets/cjs_shims.js"() {
+  "node_modules/.pnpm/tsup@8.5.0_postcss@8.5.6_typescript@5.9.3/node_modules/tsup/assets/cjs_shims.js"() {
     "use strict";
-    getImportMetaUrl = () => typeof document === "undefined" ? new URL(`file:${__filename}`).href : document.currentScript && document.currentScript.tagName.toUpperCase() === "SCRIPT" ? document.currentScript.src : new URL("main.js", document.baseURI).href;
+    getImportMetaUrl = () => typeof document === "undefined" ? new URL(`file:${__filename}`).href : document.currentScript && document.currentScript.src || new URL("main.js", document.baseURI).href;
     importMetaUrl = /* @__PURE__ */ getImportMetaUrl();
   }
 });
@@ -551,7 +551,7 @@ 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\` |
+| Keywords: "bug", "issue", "broken", "doesn't work", "failed", "error", "wrong triage", "incorrect classification", "dispute", "that was wrong" | \`feedback\` |
 | Question words: "what", "which", "do we have", "is there" about tests/project | \`question\` |
 | Default (none of above) | \`feedback\` |
 
@@ -587,7 +587,26 @@ Extract the following from the message:
 - \`suggestion\`: "should", "could we", "what if", "idea"
 - \`general\`: Default for unclassified feedback
 
-### Step 2: Update Test Case Specifications
+### Step 2: Check for Dispute Intent
+
+Before processing other feedback types, check if the message is disputing a prior triage finding (e.g., "that triage was wrong", "the login timeout is actually CI flakiness not a product bug", "incorrect classification for...").
+
+**If dispute detected:**
+1. Call \`bugzy-findings list\` to retrieve recent findings
+2. Match the customer's message to a specific finding by test name, description, or ID
+3. If ambiguous (multiple possible matches), list recent findings and ask the customer to clarify which one they're disputing
+4. Once matched, call:
+   \`\`\`bash
+   bugzy-findings dispute --finding-id <matched-finding-id> --explanation "<customer's explanation>"
+   \`\`\`
+5. Confirm the dispute was recorded: "Dispute recorded for [finding title]. A triage credit has been applied and the finding is now marked as disputed. This feedback will help improve future triages."
+6. Skip the remaining feedback steps (the dispute is the action)
+
+If \`bugzy-findings\` is not available (command not found), inform the customer that dispute functionality is not available for this project and suggest contacting support.
+
+**If NOT a dispute**, continue with the standard feedback flow below.
+
+### Step 3: 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.
 
@@ -599,7 +618,7 @@ For each actionable feedback item:
 
 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
+### Step 4: 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.
 
@@ -892,7 +911,11 @@ Use these as reference patterns for common events. The webhook routing system al
 
 **Jira Events:**
 - **Status \u2192 "Ready to Test" / "In Testing" / "Ready for QA"**: Propose \`/verify-changes\` with issue context
-- **Resolution: "Not a Bug" / "Won't Fix" / "User Error"**: Update knowledge base directly with the learning (no queue needed)
+- **Resolution: "Not a Bug" / "Won't Fix" / "User Error"**: Update knowledge base directly with the learning (no queue needed). Additionally, if the issue was linked to a triage finding (check via \`bugzy-findings list\` matching by issue tracker key), auto-dispute the finding:
+  \`\`\`bash
+  bugzy-findings dispute --finding-id <matched-finding-id> --explanation "Issue resolved as Not a Bug/Won't Fix in issue tracker"
+  \`\`\`
+  This applies a triage credit automatically when the issue tracker confirms the triage was incorrect. If \`bugzy-findings\` is not available, skip the dispute and only update the knowledge base.
 - **Bug created with relevant labels**: Propose \`/generate-test-cases\` to update related test coverage, confirm with team
 - **Backlog \u2192 To Do**: No QA action needed, log to event history only
 
@@ -6498,6 +6521,16 @@ After analyzing test results, triage each failure to determine if it's a product
 
 **IMPORTANT: Do NOT report bugs without triaging first.**
 
+### 0. Read Disputed Findings (Learning Context)
+
+Before triaging, check for prior disputed findings to avoid repeating past mistakes:
+
+\`\`\`bash
+cat .bugzy/runtime/disputed-findings.md 2>/dev/null || echo "No disputed findings found"
+\`\`\`
+
+If the file exists, read it carefully. It contains past triage mistakes and lessons learned. Use this context to improve classification accuracy for similar failures.
+
 ### 1. Check Failure Classification
 
 **Before triaging any failure**, read \`new_failures\` from the latest \`test-runs/*/manifest.json\`:
@@ -6555,7 +6588,42 @@ For each failed test (from \`new_failures\` or all failures if field is missing)
 | Test ID | Test Name | Last Passed Run |
 |---------|-----------|-----------------|
 | TC-003 | Search | 20260210-103045 |
-\`\`\``,
+\`\`\`
+
+### 4. Record Findings
+
+After triaging, record each classified failure as a structured finding via the \`bugzy-findings\` CLI. This stores findings in the platform database for tracking, disputes, and dashboard visualization.
+
+For each triaged failure, run:
+
+\`\`\`bash
+bugzy-findings add \\
+  --title "<concise failure description>" \\
+  --description "<detailed analysis including error message and root cause>" \\
+  --severity <critical|high|medium|low> \\
+  --classification <product-bug|test-issue> \\
+  --test-case-id "<test ID from triage table>" \\
+  --test-run-timestamp "<timestamp from manifest.json>"
+\`\`\`
+
+**Severity Guidelines:**
+- **critical**: Application crash, data loss, security vulnerability
+- **high**: Major feature broken, blocking workflow
+- **medium**: Feature partially broken, workaround exists
+- **low**: Minor cosmetic issue, edge case
+
+Example:
+\`\`\`bash
+bugzy-findings add \\
+  --title "Checkout form returns 500 on submit" \\
+  --description "POST /api/checkout returns HTTP 500 when submitting with valid payment data. Stack trace shows null reference in payment processor." \\
+  --severity high \\
+  --classification product-bug \\
+  --test-case-id "TC-002" \\
+  --test-run-timestamp "20260219-103045"
+\`\`\`
+
+If \`bugzy-findings\` is not available (command not found), skip this step silently \u2014 findings recording is optional and does not block triage.`,
   tags: ["execution", "triage", "analysis"]
 };