# Reporting Standards

Structured format for diagnostic and investigation reports. Sacrifice grammar for concision.

## When to Use

- After completing system investigation
- Summarizing debugging session findings
- Producing incident post-mortems
- Reporting performance analysis results

## Report Structure

### 1. Executive Summary (3-5 lines)

- **Issue:** One-line description
- **Impact:** Users/systems affected, severity
- **Root cause:** One-line explanation
- **Status:** Resolved / Mitigated / Under investigation
- **Fix:** What was done or recommended

### 2. Technical Analysis

**Timeline:**
```
HH:MM - Event description
HH:MM - Next event
...
```

**Evidence:**
- Relevant log excerpts (trimmed to essential lines)
- Query results with key metrics
- Error messages and stack traces
- Before/after comparisons

**Findings:**
- List each finding with supporting evidence
- Distinguish confirmed facts from hypotheses
- Note correlation vs causation

### 3. Actionable Recommendations

**Immediate (P0):**
- [ ] Critical fix with implementation steps

**Short-term (P1):**
- [ ] Follow-up improvements

**Long-term (P2):**
- [ ] Monitoring/alerting enhancements
- [ ] Architecture improvements
- [ ] Preventive measures

Each recommendation: what to do, why, expected impact, effort estimate (low/medium/high).

### 4. Supporting Evidence

- Relevant log excerpts
- Query results and execution plans
- Performance metrics
- Test results and error traces
- Screenshots or diagrams if applicable

### 5. Unresolved Questions

List anything that remains unclear:
- Items needing further investigation
- Questions for the team
- Assumptions that need validation

## Report File Naming

Use naming pattern from `## Naming` section injected by hooks. Pattern includes full path and computed date.

**Example:** `plans/reports/debugger-260205-2215-api-500-investigation.md`

## Writing Guidelines

- **Concise:** Facts and evidence, not narrative. Sacrifice grammar for brevity
- **Evidence-backed:** Every claim supported by logs, metrics, or reproduction steps
- **Actionable:** Recommendations are specific with clear next steps
- **Honest:** State unknowns explicitly. "Likely cause" vs "confirmed cause"
- **Structured:** Use headers, tables, and bullet points for scanability

## Template

```markdown
# [Issue Title] - Investigation Report

## Executive Summary
- **Issue:**
- **Impact:**
- **Root cause:**
- **Status:**
- **Fix:**

## Timeline
- HH:MM -
- HH:MM -

## Technical Analysis
### Findings
1.
2.

### Evidence
[logs, queries, metrics]

## Recommendations
### Immediate (P0)
- [ ]

### Short-term (P1)
- [ ]

### Long-term (P2)
- [ ]

## Unresolved Questions
-
```
