## Defect Deduplication (The Deduplication)

**Goal**: Avoid duplicate reports through a two-level deduplication mechanism: (1) consolidate similar defects from the current input (internal deduplication); (2) filter historically reported defects (external deduplication).

### Internal Deduplication: Similar Defect Merging

Identify and merge multiple defect reports with the same root cause, avoiding duplicate noise from the same issue.

#### Similarity Decision Tree

For any two defects A and B, determine whether they should be merged using the following decision tree:

```
Should two defects be merged?
├─ Same defect type?
│  ├─ No → Do not merge
│  └─ Yes → Same root cause?
│     ├─ No → Do not merge
│     └─ Yes → Same or highly similar fix?
│        ├─ No → Do not merge (may be different fix strategies for the same root cause)
│        └─ Yes → Merge
```

**Criteria for same root cause**:
- The same logical error in the same function/method, affecting different callers
- Missing parameter validation on the same API, causing different downstream issues
- Inconsistent handling of the same data structure, manifesting on different code paths

**Criteria for same or highly similar fix**:
- A single code modification can fix both defects simultaneously
- Adding the same type of defense mechanism (e.g., parameter validation at the same location)
- Not similar: one requires adding a lock, the other requires adding a transaction (even if root causes are related)

#### Merge Strategy

Merge the identified similar defects **into a single defect report**.

**Code location selection** (considered in order of priority from high to low):
1. **Priority 1**: Select the scenario with the highest severity
2. **Priority 2**: Select the function with the highest call frequency or the most typical usage
3. **Priority 3**: If severity and call frequency are comparable, prefer the location in the core business flow

**Describe the full impact scope in the final report**:
- In the **Analysis** section, explicitly list all affected code locations and line numbers
- In the **Impact Assessment** section, explain the differences in impact across locations
- In the **Fix Code** section, provide a unified fix (applicable to all affected locations)

#### Information Retention Rules After Merging

When merging defects, the following information must be retained:
- Complete list of line numbers for all affected locations
- Impact assessment of the most severe scenario (must not be downgraded)
- Code variants at each location (if the problematic code differs slightly across locations)
- Unified fix code (must cover all variants across affected locations)

#### Cross-File Root Cause Analysis Guide

- **Different callers of the same API reported as different defects**: Check whether the API itself has issues
  - API lacks parameter validation → Merge into an API defect
  - Callers pass invalid parameters → Do not merge, report separately
- **Multiple missing validations for the same field**: Check whether it is the absence of the same validation logic
  - The same required validation missing in multiple places → Merge
  - Different dimensions of validation (type vs. range vs. format) → Do not merge

### External Deduplication: Historical Defect Filtering

**Pre-check**: Before attempting any tool calls, **must** first check whether the MCP tool `mcp__issue__query_existing_issues` is available in the current environment. If not available, **skip this entire step directly**.

1. Use `mcp__issue__query_existing_issues` with the `merge_request_url` parameter (only available in branch scan mode)
2. **Deduplication criteria** (considered duplicate if any of the following conditions are met):
   * Same file path + overlapping line number range (at least 50% overlap)
   * Same defect type + same root cause + same or similar file path
   * Title contains the same key error type and file path
   * If determined to be a duplicate defect, **immediately mark as [existing] and remove**

3. **Exception handling**: If the tool returns an error, **do not interrupt the process**, log a warning and continue, and note in the conclusion that "historical deduplication check was not performed".
