## Severity Calibration

**Goal**: Based on the report text content, calibrate whether the severity assigned by detection is reasonable. Only modify severity labels; do not judge the defect's true/false status.

**Pure metadata operation**: Only analyze report text; do not invoke code tools.

### Calibration Patterns

#### Severity Mismatch with Description

The severity labeled in the report is inconsistent with the actual impact described:

| Reported Severity | Actual Description Content | Calibration |
|----------------|-------------|------|
| High | General advice ("Recommend adding CSP headers"/"Recommend enabling HSTS") | → Low |
| High | Vague impact description ("May cause issues" without describing specific impact) | → Medium |
| High | File path is under test/mock/example directory | → Medium |
| Medium | Describes a specific exploitable vulnerability (with attack path) | → High |
| Low | Describes an injection-type vulnerability (SQL injection/command injection/XSS) | → Medium |

#### Speculative High Severity

Report is marked "high" but the reasoning is entirely uncertain language:

| Signal | Determination | Calibration |
|------|------|------|
| Reasoning contains many "possibly/maybe/theoretically" with no specific trigger path | Overstated | → Medium |
| Defect description is based solely on pattern matching without data flow analysis | Lacks depth | → Medium |
| Impact description is "may cause security issues" with no specific scenario | Vague impact | → Medium |

#### Defect Type vs. Severity Mismatch

Certain defect types have reasonable default severity ranges:

| Defect Type | Reasonable Range | Calibration Signal |
|---------|---------|---------|
| Static defects (indentation/naming/formatting) | Low | Marked "high" or "medium" → downgrade to "low" |
| Static defects (undefined symbols/type errors) | Medium-High | Keep |
| Security vulnerabilities (injection/XSS/path traversal) | High-Critical | Marked "low" → upgrade to "medium" |
| Security vulnerabilities (general advice with no specific scenario) | Low | Marked "high" → downgrade to "low" |
| Logic defects (transactions/concurrency/state) | Medium-High | Keep |
| Logic defects (non-critical paths) | Low-Medium | Marked "high" → downgrade to "medium" |

#### Multiple Downgrade Signals

When the report simultaneously shows multiple downgrade signals, make a综合 judgment:

| Signal Combination | Calibration |
|---------|------|
| Speculative language + vague impact description + non-critical path | Severe downgrade (high → low) |
| Speculative language + but defect type is high-risk (injection-type) | No downgrade, keep original severity |
| File in test/ directory + but describes security vulnerability (hardcoded key) | No downgrade, keep original severity |

### Calibration Rules

- **No overlap with validation's premise-challenge**: premise-challenge uses code evidence to verify whether the impact holds; here we only calibrate labels based on report text
- **Calibration only modifies severity labels**, it does not remove defects. Downgraded defects still enter the validation stage
- **Upgrade with caution**: Only upgrade when the report describes a clear exploitable vulnerability but the severity is clearly underestimated
