> After reading this file, load the corresponding strategy files based on the characteristics of the defect reports and execute them as needed.

## Core Philosophy

**management handles the metadata of defect reports, it does not touch code.**

The goal is to maximize the reduction of invalid noise and calibrate report quality before report generation. All strategies only operate on report text and metadata; they do not invoke code tools such as Grep/Read/find_definition.

## Strategy Loading Guide

Select the corresponding strategy file to load and execute based on the **characteristics** of the defect report.

| Strategy | Core Question | Load Signal | Execution Guide |
|------|---------|---------|---------|
| [deduplication.md](deduplication.md)<br>Defect Deduplication | Are there duplicate reports? | - More than 1 input defect<br>- Multiple defects involve the same file or similar descriptions<br>- Branch scan mode has historical records to query | Identify and merge defects with the same root cause into a single report; query historically reported defects for deduplication. **Must be executed first** |
| [scope-validation.md](scope-validation.md)<br>Scope Validation | Are defects within the scan scope? | - Defects report file paths and line numbers<br>- Scan mode limits scope (branch/file/directory)<br>- Line numbers may not be within diff change range | Validate whether file paths and line numbers of defects are within the scan scope. Filter or correct line numbers if out of scope |
| [noise-filter.md](noise-filter.md)<br>Noise Filter | Is the report a genuine defect? | - Report describes code style/naming/indentation issues<br>- Defects are in test/mock/example directories<br>- Described as general advice or theoretical speculation<br>- Defect type is generic scanner-style security tips | Quickly eliminate invalid noise based on report text: code style, non-production code, general advice, documentation comments, speculative issues, etc. |
| [severity-calibration.md](severity-calibration.md)<br>Severity Calibration | Is the severity label correct? | - Report marked "high" but description is just general advice<br>- Report marked "high" but reasoning contains uncertain language<br>- Static defects (indentation/naming) marked "high"<br>- Security vulnerabilities (injection/XSS) marked "low" | Calibrate severity labels based on report text: downgrade overstated ones, upgrade understated ones. Only modify labels, do not judge true/false |
| [defect-clustering.md](defect-clustering.md)<br>Defect Clustering | Are there systemic issues? | - Multiple independent defects in the same file/function<br>- Multiple security-type defects on the same API<br>- Multiple defects involve the same data flow path | Identify relationships among surviving defects, mark independent but related defects as clusters to indicate systemic risk |

## Execution Dependencies

```
deduplication (must execute first)
     │
     ├─→ scope-validation ──────┐
     ├─→ noise-filter ──────────┤  Execute in parallel (after dedup)
     └─→ severity-calibration ──┘
     │
     └─→ defect-clustering (execute last, on surviving defects)
```

**Loading Rules**:
- deduplication must be executed first, outputting the deduplicated defect list
- scope-validation, noise-filter, severity-calibration are independent of each other and can execute in parallel
- If any strategy determines "filter", that defect is removed (downgrade by severity-calibration does not count as filtering)
- defect-clustering executes after all filtering is complete, operating on surviving defects
