Bug Report

---
name: bug-report
description: Classify a bug's severity × priority and format a developer-ready issue body for it (any tracker) — from a failed test (WAY 1 Phase 4, WAY 2 Phase 3) or from the WAY 3 quick-report shorthand ("report it", "log this", "raise this", "file this issue"). Replaces the former severity-classifier and bug-reporter agents.
---

# bug-report

Turns one bug into: a **Severity × Priority** pair, a **label set**, a
**title**, and an **issue body** in Markdown (the provider skill converts it where needed). Apply it in the main session, once per
bug — the failure data (or the user's shorthand) is already in context, so no
sub-agent is needed. Filing the issue afterwards follows the `tracker`
skill.

## Input

One of:
- **A failed scenario** from `test-execution-agent`'s results YAML: scenario, spec, status, error, failing step, a11y violations, artifact paths (screenshot, console/network log, `api-responses/` capture)
- **WAY 3 shorthand** from the user: `[Area], [Precondition], [Step 1 > Step 2 > Observe: what you saw]`

### Parsing the WAY 3 shorthand

Split on the first two commas:
- `Area` → title prefix `[Area]`
- `Precondition` → step 1 of Steps to Reproduce (e.g. "Log in as a standard user")
- The rest, split on `>` → numbered steps; the segment starting with `Observe:` becomes **Actual Result** and the last numbered step ("Observe: …")

Derive **Expected Result** from the area and steps (what a correct app does). If it can't be derived with confidence, ask the user one question rather than inventing it. If the shorthand is missing the Observe part, ask for it — a bug without an observed result can't be filed.

## Step 1 — Classify

### Severity × Priority matrix

| Severity | Definition | Default Priority |
|---|---|---|
| Sev-1 (Critical) | Data loss, security breach, auth bypass, production down, payment failure | P1 — Immediate |
| Sev-2 (High) | Core feature broken for all users, major data corruption, PII exposed | P1 — Immediate |
| Sev-3 (Medium) | Feature broken for some users, incorrect data displayed, workaround exists | P2 — This sprint |
| Sev-4 (Low) | Cosmetic issue, minor UX friction, edge case rarely hit | P3 — Backlog |

### Auto-escalation (always apply, override the matrix)
- Any XSS, IDOR, auth bypass, or injection vulnerability → Sev-1
- Any PII exposed in a response or log → Sev-2 minimum
- Any data permanently deleted unexpectedly → Sev-1
- Any payment flow failure → Sev-1
- An axe violation with impact `critical` or `serious` → Sev-2

### Rules
- When in doubt between two severities, choose the higher one
- Never Sev-1 for a cosmetic issue; never Sev-4 for a security issue

### Labels
`bug`, `sev-<n>`, `p<n>`, plus the context label: `e2e` (browser), `api` (API), `accessibility` (axe violation). Use only labels from the `tracker` skill's label conventions.

Write down the classification with a one-sentence rationale. It goes in the issue body and in the session summary.

## Step 2 — Title

`[Area] Short description of the problem`, under 80 characters. It describes
the symptom, not the suspected cause.

## Step 3 — Issue body

```markdown
## Bug Report

**Summary:** [One sentence — what is wrong and where]

---

## Steps to Reproduce

1. Navigate to [URL]
2. [Action with specific UI element name — or the exact API call]
3. [Action]
4. Observe: [what you saw]

## Expected Result
[What should have happened]

## Actual Result
[What actually happened — error messages quoted verbatim]

## Environment
- URL: [tested URL]
- Browser: [Chromium / API]
- Date: [ISO timestamp]
- Test Case: [Test#<nn> — path to its .feature, or "manual report" for WAY 3]

## Artifacts
- Screenshot: [snippet returned by `file.attach`, see the `tracker` skill → Attachments] (or "No screenshot captured")
- Console log: `[key error lines]` (if available)
- Network log: `[endpoint + status]` (if available)
- API exchange: `[api-responses/… path]` (API bugs)

## Severity / Priority
Sev-[N] ([label]) / P[N] ([label]) — [one-sentence rationale]

---
🤖 _Generated by DevOps QA Agent — review before acting on this._
```

## When NOT to file

Check `test-execution-agent`'s result fields first. These are not product bugs:
- `reason: "baseline created"`: the first run of a `@visual` step
- `quarantined: true`: known flaky, tracked by `flaky-triage`
- `failure_kind: locator`: run `test-healer` first. File only if it says `not-healable: element missing` (or the user rejects the heal)
- `status: blocked` for network or setup reasons: report it in the session summary, but don't file it

## Rules
- Steps are numbered and reproducible by someone who wasn't present
- Quote error messages verbatim
- Never include real personal data — replace any with placeholders (`user@test.local`)
- The body always ends with the watermark footer (CLAUDE.md's Output Watermark) — it is part of the content passed to `create_issue`, not added afterward