Bug Triage

Bring the bug backlog back under control. Read every open bug, refresh priorities against current reality, group by symptom, and assign each bug an owner and a sprint.

Phase 1: Inventory

Glob production/qa/bugs/BUG-*.md. Read each whose Status is Open, In Progress, or Reopened. Skip Closed, WontFix, Duplicate.

Capture per bug:

• ID, title
• Current severity, priority, status
• Affected platforms
• Affected build (and whether that build is still relevant)
• Frequency
• File date
• Suspected area / module
• Last update date

Optional argument --since=<date> filters to bugs filed after a date.

Phase 2: Re-evaluate Each Bug

For every bug, ask whether the current severity/priority still fits. Drivers of re-evaluation:

• Build relevance — if the affected build is now several releases old, can the bug still be reproduced? Surface for user to confirm.
• Workaround stability — if a documented workaround has stopped working, severity goes up.
• Frequency drift — telemetry numbers (Crashlytics, Sentry) may show the bug occurring more or less often than at filing time.
• Business context — paywall bugs near a marketing push, auth bugs near an enterprise rollout, push bugs near a re-engagement campaign all elevate priority.
• Age — open longer than 30 days at S2 or above is a smell.

Read recent telemetry summary if present (production/qa/telemetry-summary.md) and use it to inform the calls.

For each bug, propose new severity/priority. Use AskUserQuestion in batches:

question: "BUG-NNN: [title]\nCurrent: S[X]/P[Y] — proposed: S[A]/P[B]\nReason: [reason]"
options:
  - "Accept proposal"
  - "Keep current"
  - "Override — let me set values"
  - "Close — fixed / not reproducible / wontfix (specify)"

Phase 3: Detect Systemic Trends

Cluster the open bugs:

• By module (auth, paywall, sync, push, navigation).
• By symptom (crash, ANR, freeze, layout, copy, network, payment).
• By platform (iOS-only, Android-only, both).
• By cause hypothesis (race condition, leaked subscription, missing null check, deprecated API).

If a cluster has 3+ bugs, flag it as a systemic trend and propose:

• An ADR or refactor story to address the root.
• A regression test family for the cluster.
• A specific subagent or specialist to drive the fix.

Phase 4: Assign Sprints

For each open bug remaining, propose a sprint slot:

• P0 -> active sprint (interrupts current work).
• P1 -> active sprint or next sprint (capacity-permitting).
• P2 -> next sprint.
• P3 -> backlog with revisit-by date (default +60 days).

Read the active sprint plan to estimate available capacity. If a sprint is full, flag overflow and ask the user to choose between bumping P3s, deferring P2s, or expanding the sprint.

Use AskUserQuestion to confirm the schedule per cluster.

Phase 5: Update Bug Files

For each bug whose severity, priority, or sprint changed, ask: "May I update [bug path]?"

On approval, edit:

• Severity: S[N]
• Priority: P[N]
• Status: [In Progress / Open / Closed / WontFix]
• Append a ## Triage [date] note with the reasoning.
• If assigned to a sprint, add Sprint: [sprint-id].

For closed bugs, add a ## Resolution [date] note with the closing reason (Fixed in [commit], Not Reproducible, Duplicate of BUG-NNN, WontFix because [reason]).

Phase 6: Render the Triage Report

# Bug Triage Report — [date]

Bugs reviewed: [N]
- Severity changes: [count]
- Priority changes: [count]
- Closed during triage: [count]
- New systemic trends flagged: [count]

## By Severity
| Severity | Open count | New since last triage |
|----------|------------|------------------------|
| S1 | 0 | 0 |
| S2 | 3 | 1 |
| S3 | 11 | 4 |
| S4 | 7 | 2 |

## Systemic Trends
- Cluster: [description] — [N] bugs — recommend [action]

## Sprint Assignments
| Bug | Title | Severity | Priority | Sprint |
|-----|-------|----------|----------|--------|

## Closed During Triage
| Bug | Reason |

## Backlog (P3)
[N] bugs, revisit by [date]

## Recommendations
- [action]
- [action]

Ask: "May I write this to production/qa/triage-[date].md?"

Phase 7: Update Session State

Append to production/session-state/active.md:

## Bug Triage — [date]
- Reviewed: [N]
- Open S1/S2: [count]
- Trends flagged: [count]
- Triage report: [path]
- Next sprint impact: [N bugs added]

Quality Gates / PASS-FAIL

• PASS — every Open bug has a current severity, priority, and either a sprint assignment or a backlog flag with a revisit date. No S1 is unassigned.
• FAIL — any S1 bug remains unassigned, or any bug older than 30 days has not been re-evaluated.

Examples

Example 1 — sprint-04 kickoff: Reads 22 open bugs. Closes 4 (3 not-reproducible, 1 duplicate). Promotes 2 to S2 due to telemetry spike. Detects an "Android keyboard insets" cluster (4 bugs) and recommends ADR to standardize. Assigns 9 bugs to sprint-04.

Example 2 — backlog cleanup: --since=2025-12-01 triages 38 stale entries. Closes 11 as WontFix-due-to-rewrite, archives the rest with revisit dates.

Next Steps

• Systemic trend -> /architecture-decision or refactor story.
• High-severity remaining -> /hotfix [bug].
• Sprint-assigned bugs -> include in /sprint-plan.