## Impact Premise Refutation (Kill Mandate)

> Your goal is to refute the defect report. Only conclusive code evidence can refute.
> Core question: detection assumes the defect will cause severe business impact, but the actual impact does not hold — even if the defect technically exists, it does not constitute a business problem.

### Applicable Scenarios

- The defect assumes data is critical, but it is actually temporary/rebuildable data
- The defect assumes the impact is unacceptable, but the business can tolerate it
- The defect assumes the threat model holds, but the actual data/scenario is not sensitive

### Refutation Process

1. **Identify impact assumptions**: Analyze the implicit impact assumptions in detection's report
2. **Verify impact validity**: Use code evidence to verify whether the impact holds in the current business scenario
3. **Determination**: Impact does not hold → Kill; Impact holds → Not refuted

### Refutation Patterns

#### Data Criticality Premise Refutation

Detection assumes data is critical, but it is actually temporary/rebuildable data:

| Impact Assumption | Verification Method | Determination |
|---------|---------|------|
| Assumes data cannot be lost | `Read` to check data nature: cached data, temporary files, logs, rebuildable data | Temporary/rebuildable data → Kill |
| Assumes data consistency is critical | `Read` to check business requirements: eventual consistency is acceptable, reconciliation mechanism compensates | Eventual consistency is acceptable → Kill |
| Assumes data leakage has impact | `Read` to check data types: public information, non-sensitive logs, test data | Non-sensitive data → Kill |

#### Business Tolerance Premise Refutation

Detection assumes errors are unacceptable, but the business can tolerate them:

| Impact Assumption | Verification Method | Determination |
|---------|---------|------|
| Assumes operation requires atomicity | `Read` to check operation type: read operations, idempotent operations, retryable operations | Idempotent/retryable → Kill |
| Assumes errors are unacceptable | `Read` to check business tolerance: non-critical paths, degradation strategies, user can retry | Business can tolerate → Kill |
| Assumes severe performance impact | `Read` to check performance requirements: non-latency-sensitive paths, async processing, batch operations | Not a performance-critical path → Kill |

### Refutation Determination Rules

- **Kill condition**: Use code evidence to prove that the defect's assumed impact does not hold in the current business scenario
- **Not refuted condition**: The impact assumption holds in the current scenario
- **Downgrade condition**: Impact partially does not hold (e.g., data is partially rebuildable) → Do not Kill, but record the downgrade reason

### Degradation Strategy

- When unable to confirm the business scenario, infer based on code context (e.g., clues in class names, package names, module names)
- When unable to verify the degree of impact, mark "impact premise not verified", this strategy is determined as "not refuted"
