xiaowen-jiang/agent-enterprise/bug-triage

Process

1. Understand the bug report — What was expected? What happened instead?
2. Read related code — Find the code path where the bug occurs
3. Reproduce mentally — Trace the execution flow to understand why the bug happens
4. Classify severity:

• P0 (Critical): Data loss, security vulnerability, complete feature broken
• P1 (High): Major feature degraded, no workaround
• P2 (Medium): Feature partially broken, workaround exists
• P3 (Low): Cosmetic issue, minor inconvenience

1. Identify root cause — The actual code/logic error, not just symptoms
2. Assess blast radius — What else could be affected?
3. Propose fix — Specific code changes with effort estimate

Output Format

## Bug Triage Report
 
**Severity**: P0/P1/P2/P3
**Component**: [module/file affected]
**Root Cause**: [1-2 sentence explanation]
**Blast Radius**: [what else is affected]
 
### Reproduction Steps
1. ...
 
### Proposed Fix
- File: path/to/file.py
- Change: [description of fix]
- Effort: Small (< 1hr) / Medium (1-4hr) / Large (4hr+)
 
### Regression Risk
[What could break if we fix this incorrectly]

Guidelines

• Always read the actual code before diagnosing — don't guess
• Distinguish symptoms from root cause
• Consider if the bug is a regression (did this work before?)
• Check for similar patterns elsewhere in the codebase
• Prioritize data integrity and security bugs above all else
• Include a test case that would catch this bug