## 缺陷去重 (The Deduplication)

**目标**：通过两级去重机制避免重复报告：（1）整合当前输入的相似缺陷（内部去重）；（2）过滤历史已报告的缺陷（外部去重）。

### 内部去重：相似缺陷合并

识别并合并根本原因相同的多个缺陷报告，避免同一问题的重复噪音。

#### 相似度判断决策树

对任意两个缺陷 A 和 B，按以下决策树判断是否应合并：

```
两个缺陷是否应合并？
├─ 缺陷类型相同？
│  ├─ 否 → 不合并
│  └─ 是 → 根本原因相同？
│     ├─ 否 → 不合并
│     └─ 是 → 修复方案相同或高度相似？
│        ├─ 否 → 不合并（可能是同一根因的不同修复策略）
│        └─ 是 → 合并
```

**根本原因相同的判定**：
- 同一函数/方法中的同一逻辑错误，影响不同调用者
- 同一 API 的参数校验缺失，导致不同下游问题
- 同一数据结构的不一致处理，在不同代码路径上表现

**修复方案相同或高度相似的判定**：
- 同一处代码修改即可同时修复两个缺陷
- 同一类防御机制的添加（如同一位置添加参数校验）
- 不相似：一个需要加锁、另一个需要加事务（即使根因相关）

#### 合并策略

将识别出的多个相似缺陷**合并为一个缺陷报告**。

**代码位置选择**（按优先级从高到低依次考虑）：
1. **优先级1**：选择严重程度最高的场景
2. **优先级2**：选择调用频率最高或最典型的函数
3. **优先级3**：如果严重程度和调用频率相当，优先选择核心业务流程中的位置

**在最终报告中说明完整影响范围**：
- 在**问题分析**部分明确列出所有受影响的代码位置及行号
- 在**影响评估**部分说明不同位置的影响差异
- **修复代码**部分提供统一的修复方案（适用于所有受影响位置）

#### 合并后信息保留规则

合并缺陷时，必须保留以下信息：
- 所有受影响位置的完整行号列表
- 最严重场景的影响评估（不可降级）
- 每个位置的代码变体（如果问题代码在不同位置略有不同）
- 统一的修复代码（必须覆盖所有受影响位置的变体）

#### 跨文件根因分析指引

- **同一 API 的不同调用者被报为不同缺陷**：检查 API 本身是否有问题
  - API 缺少参数校验 → 合并为 API 缺陷
  - 调用者传入非法参数 → 不合并，分别报告
- **同一字段的多个验证缺失**：检查是否为同一验证逻辑的缺失
  - 同一必填校验在多处缺失 → 合并
  - 不同维度的验证（类型 vs 范围 vs 格式） → 不合并

### 外部去重：历史已报告缺陷过滤

**前置检查**：在尝试任何工具调用之前，**必须**先检查 MCP 工具 `mcp__issue__query_existing_issues` 在当前环境中是否可用。如果不可用，**直接跳过整个此步骤**。

1. 使用 `mcp__issue__query_existing_issues` 传入 `merge_request_url`（仅分支扫描模式下可用）
2. **去重判定**（满足以下任一条件即视为重复）：
   * 相同的文件路径 + 重叠的行号范围（至少50%重叠）
   * 相同的缺陷类型 + 相同的根本原因 + 相同或相近的文件路径
   * 标题包含相同的关键错误类型和文件路径
   * 如果判定为重复缺陷，**立即标记为[已存在]并移除**

3. **异常处理**：如果工具返回错误，**不要中断流程**，记录警告继续执行，在结论中说明"未进行历史去重检查"。
