## Behavior Unreachable Refutation (Kill Mandate)

> Your goal is to refute the defect report. Only conclusive code evidence can refute.
> Core question: The defect report describes a problem, but the behavior cannot actually be triggered at runtime.

### Applicable Scenarios

- The defect involves a specific trigger path or conditional branch
- The defect assumes an execution path is reachable, but it is actually blocked
- The defect involves environment restrictions or configuration constraints
- The trigger conditions of the defect are impossible to satisfy in business scenarios

### Refutation Process

1. **Trace the execution path**: From user input/call entry to the problematic code, trace the complete execution path
2. **Check for path blocking**: Identify whether there are blocking conditions on the path that make the defect untriggerable
3. **Determination**: All actual execution paths unreachable → Kill; reachable path exists → Not refuted

### Refutation Patterns

#### Conditional Blocking

Early return/throw/guard statements exist before the problematic code, blocking the execution path:

| Blocking Method | Verification Method | Determination |
|---------|---------|------|
| Early return | `Read` to get the complete function, check whether `return`/`throw` is before the problematic code | Early return makes problematic code unreachable → Kill |
| Guard statement | `Read` to check guard statements: `if (!condition) return`/`guard let`/`early return` | Guard blocks the path → Kill |
| Validation interrupt | `Read` to check validation logic: `if (!isValid(input)) throw new Error(...)` | Validation failure directly interrupts → Kill |
| Assertion intercept | `Grep` to search for `assert`/`check`/`validate`/`precondition` | Assertion intercept → Kill |

**Tool chain**:
- `Read` to get the complete function body and analyze control flow
- `find_references` to trace callers and check whether callers have already performed pre-validation

#### Environment Restrictions

The defect trigger depends on a specific runtime environment or configuration, but the actual environment does not satisfy it:

| Environment Restriction | Verification Method | Determination |
|---------|---------|------|
| Conditional compilation | `Grep` to search for `#ifdef`/`#ifndef`/`#if` wrapping the problematic code | Only effective under specific compilation conditions → Kill |
| Environment variable guard | `Grep` to search for `process.env`/`os.environ`/`System.getenv` guarding the problematic code | Controlled by environment variable and not enabled in production → Kill |
| Configuration switch | `Grep` to search for feature flags/configuration switches wrapping the problematic code | Configuration defaults to off → Kill |
| Platform restriction | `Read` to check platform detection: `process.platform`/`os.name`/`RuntimeInformation.IsOSPlatform` | Only triggers on specific platforms → Kill |
| Dev/test environment only | `Grep` to search for `process.env.NODE_ENV`/`@Profile`/`Spring profiles` conditional guard | Only effective for dev/test profiles → Kill |
| Debug code guard | `Read` to check whether code is inside `if (process.env.NODE_ENV === 'development')` | Only runs in development environment → Kill |
| Production config override | `Read` to check configuration file override chain: `application-prod.yml` overriding `application.yml` | Production config overrides the problematic config → Kill |
| Log level restriction | `Grep` to search for log configuration, check production environment log level | Production level is info or above, debug logs not output → Kill |

#### Caller Pre-Validation

The defect assumes a condition is unsafe, but the caller has already guaranteed it:

| Validation Method | Verification Method | Determination |
|---------|---------|------|
| Parameter validation | `find_references` to trace callers → `Read` to check whether callers have parameter validation | Caller already validated → Kill |
| State validation | `find_references` to trace callers → `Read` to check whether callers have state checks | Caller already checked state → Kill |
| Middleware validation | `Grep` to search for validation logic in middleware/interceptors | Middleware already intercepted → Kill |
| Decorator/annotation validation | `Grep` to search for `@Valid`/`@Validated`/`@NotNull` and other validation annotations | Annotation validation covers it → Kill |

#### Business Scenario Restrictions

The defect is theoretically valid, but business scenarios make it practically untriggerable:

| Business Restriction | Verification Method | Determination |
|---------|---------|------|
| Single-threaded scenario | `Read` to check whether code runs in a single-threaded environment such as scheduled tasks/admin backend/CLI | Single-threaded, no race conditions → Kill |
| Single-user scenario | `Read` to check whether the endpoint is an internal management endpoint/ops endpoint | Single-user, no concurrency → Kill |
| Single-instance deployment | `Grep` to search for deployment configuration, check for instance count/concurrency limits | Single instance, no distributed race conditions → Kill |
| User-level locking | `Read` to check whether the operation has user-level locking (e.g., button disabled after form submission) | User-level locking eliminates contention window → Kill |
| Internal service call | `Read` to check whether the endpoint is only called by internal services (not external API) | Internal services have trusted input → Kill |
| Internal network isolation | `Read` to check network isolation configuration: VPC, service mesh, firewall rules | Network isolation makes external attacks unreachable → Kill |
| Immutable data | `Grep` to check whether the data source is a constant/configuration/read-only data | Immutable data has no injection risk → Kill |

#### Permission Restrictions

Defect triggering requires specific permissions, reducing actual risk:

| Permission Restriction | Verification Method | Determination |
|---------|---------|------|
| Admin permission | `Grep` to search for `@PreAuthorize`/`@RolesAllowed`/`requireAdmin`/`adminOnly` | Requires admin permission → Downgrade (not Kill, record permission requirement) |
| Authentication requirement | `Grep` to search for authentication middleware/interceptors | Requires authentication → Downgrade |
| Internal network restriction | `Read` to check service deployment configuration | Only accessible from internal network → Downgrade |

### Refutation Determination Rules

- **Kill condition**: Found conclusive path-blocking evidence; all actual execution paths are unreachable
- **Not refuted condition**: At least one reachable path exists
- **Downgrade condition**: Permission restrictions reduce but do not completely eliminate risk → Do not Kill, but record the downgrade reason

### Degradation Strategy

- When `find_references` is unavailable, infer call relationships based on already-read code context
- When unable to confirm a path is unreachable, mark "path not fully verified" and this strategy is determined as "not refuted"
