## Design Intent Refutation (Kill Mandate)

> Your goal is to refute the defect report. Only conclusive code evidence can refute.
> Core question: The "defect" reported by detection is actually intentional design in the code — the developer is aware of this behavior and intended it.

### Applicable Scenarios

- There is explicit evidence in the code expressing design intent
- The problematic behavior flagged by the defect is consistent with intent markers in the code
- The developer has explicitly expressed the expected behavior of the code through naming, annotations, documentation, etc.

### Refutation Process

1. **Search for intent markers**: Search for explicit design intent markers in and around the problematic code
2. **Verify intent coverage**: Determine whether the marker covers the issue reported by detection
3. **Determination**: Found clear design intent that covers the reported issue → Kill; No intent marker or intent is irrelevant → Not refuted

### Refutation Patterns

#### Explicit Suppression Markers

The developer explicitly suppressed a certain type of check through tool directives:

| Suppression Marker | Search Command | Determination |
|---------|---------|------|
| TypeScript suppression | `Grep` to search for `@ts-ignore`/`@ts-expect-error`/`@ts-nocheck` | Suppression marker covers the problematic code → Kill |
| Java suppression | `Grep` to search for `@SuppressWarnings` | Suppression annotation covers the issue → Kill |
| ESLint suppression | `Grep` to search for `eslint-disable`/`eslint-disable-next-line` | Suppressed rule covers the issue → Kill |
| Compiler pragma | `Grep` to search for `#pragma warning disable`/`#![allow(...)]` | Compiler allows it → Kill |

#### API Signature Intent

Function signatures explicitly express design intent:

| Signature Intent | Search Command | Determination |
|---------|---------|------|
| Declares potential exception | `Read` to check `throws Exception`/`raise`/`Result<T, E>` return type | Exception behavior declared → Kill |
| Declares nullable return | `Read` to check `Optional<T>`/`@Nullable`/`T \| null`/`Option[T]` return type | Nullable declared → Kill |
| Declares unsafe operation | `Read` to check `unsafe`/`@Unsafe`/`@Dangerous` markers | Marked as unsafe → Kill |
| Declares experimental API | `Grep` to search for `@Experimental`/`@Beta`/`#[experimental]` | Experimental API → Kill |

#### Naming Intent

Design intent expressed through naming conventions:

| Naming Pattern | Search Command | Determination |
|---------|---------|------|
| unsafe prefix | `Grep` to search for function names starting with `unsafe_`/`unsafe` | Naming indicates known unsafe behavior → Kill |
| raw prefix | `Grep` to search for function names starting with `raw_`/`raw` | Naming indicates raw operation → Kill |
| unvalidated prefix | `Grep` to search for function names starting with `unvalidated_`/`unvalidated` | Naming indicates known unvalidated → Kill |
| test/createTest prefix | `Grep` to search for `test*`/`createTest*`/`mock*`/`fake*` | Test/mock code → Kill |
| internal prefix | `Grep` to search for function names with `internal_`/`_` prefix (convention for internal use) | Internal function → Kill |

#### Configuration Constant Intent

Configuration values in the code are intentional design, not defects:

| Configuration Type | Verification Method | Determination |
|---------|---------|------|
| Business config values | `Read` to check constant definitions: `MAX_RETRY=3`/`TIMEOUT=30`/`PAGE_SIZE=20` | Business configuration → Kill |
| Test fixed values | `Read` to check fixed values in test code: `mockUserId`/`testPassword` | Test fixed values → Kill |
| Environment-specific values | `Grep` to search for environment values in configuration: `dev-port`/`staging-url` | Environment-specific → Kill |
| Magic numbers but named constants | `Grep` to search for named constants defined with `const`/`final`/`readonly` | Named constants → Kill |

#### Framework Convention Intent

Implementation patterns required by frameworks, not defects:

| Framework Convention | Verification Method | Determination |
|---------|---------|------|
| Object base methods | `Read` to check `__init__`/`toString`/`hashCode`/`equals`/`__str__` | Framework requirement → Kill |
| Serialization methods | `Read` to check `__repr__`/`toJSON`/`serialize`/`@Serializable` | Serialization requirement → Kill |
| Lifecycle methods | `Read` to check `setUp`/`tearDown`/`componentDidMount`/`ngOnInit` | Lifecycle method → Kill |
| Design pattern implementations | `Read` to check standard implementations of factory method, builder pattern, strategy pattern, etc. | Standard pattern implementation → Kill |

#### TODO/FIXME Markers

Issues already known to the developer:

| Marker Type | Search Command | Determination |
|---------|---------|------|
| TODO marker | `Grep` to search for `TODO`/`FIXME`/`HACK`/`XXX` covering the problematic code | Developer already marked → Kill |
| Comment explanation | `Read` to check comments above the problematic code explaining a known issue | Comment explains known issue → Kill |
| Changelog | `Grep` to search for explanations of this behavior in `CHANGELOG`/`MIGRATION` | Change already recorded → Kill |

### Refutation Determination Rules

- **Kill condition**: Found explicit design intent markers in the problematic code, and the marker covers the issue reported by detection
- **Not refuted condition**: No intent marker found, or intent marker is irrelevant (e.g., `@SuppressWarnings("unchecked")` cannot refute a SQL injection report)
- **Weak refutation**: Found indirect intent markers (naming conventions, comments) but not fully certain → Mark "weak refutation", recommend manual confirmation

### Degradation Strategy

- When unable to read code context, judge based only on clues in the report text
- When indirect clues are found but cannot be confirmed, mark "intent not fully verified", this strategy is determined as "not refuted"
