## 影响前提推翻（Kill Mandate）

> 你的目标是推翻缺陷报告。只有找到确凿的代码证据才能推翻。
> 核心问题：detection 假设缺陷会导致严重业务影响，但实际影响不成立——即使缺陷技术存在，业务上不构成问题。

### 适用场景

- 缺陷假设数据是关键的，但实际是临时/可重建数据
- 缺陷假设影响不可接受，但业务上可以容忍
- 缺陷假设威胁模型成立，但实际数据/场景不敏感

### 推翻流程

1. **识别影响假设**：分析 detection 报告中隐含的影响假设
2. **验证影响成立性**：用代码证据验证该影响在当前业务场景是否成立
3. **判定**：影响不成立 → Kill；影响成立 → 未推翻

### 推翻模式

#### 数据关键性前提推翻

detection 假设数据是关键的，但实际是临时/可重建数据：

| 影响假设 | 验证方法 | 判定 |
|---------|---------|------|
| 假设数据不可丢失 | `Read` 检查数据性质：缓存数据、临时文件、日志、可重建数据 | 临时/可重建数据 → Kill |
| 假设数据一致性关键 | `Read` 检查业务要求：最终一致性可接受、对账机制补偿 | 最终一致性可接受 → Kill |
| 假设数据泄露有影响 | `Read` 检查数据类型：公开信息、非敏感日志、测试数据 | 非敏感数据 → Kill |

#### 业务容忍前提推翻

detection 假设错误不可接受，但业务上可以容忍：

| 影响假设 | 验证方法 | 判定 |
|---------|---------|------|
| 假设操作需要原子性 | `Read` 检查操作类型：读操作、幂等操作、可重试操作 | 幂等/可重试 → Kill |
| 假设错误不可接受 | `Read` 检查业务容忍度：非关键路径、降级策略、用户可重试 | 业务可容忍 → Kill |
| 假设性能影响严重 | `Read` 检查性能要求：非延迟敏感路径、异步处理、批量操作 | 非性能关键路径 → Kill |

### 推翻判定规则

- **Kill 条件**：用代码证据证明 defect 的假设影响在当前业务场景下不成立
- **未推翻条件**：影响假设在当前场景下成立
- **降级条件**：影响部分不成立（如数据部分可重建）→ 不 Kill，但记录降级理由

### 降级策略

- 无法确认业务场景时，基于代码上下文推断（如类名、包名、模块名中的线索）
- 无法验证影响程度时，标记"影响前提未验证"，该策略判定为"未推翻"
