## Noise Filter (The Filter)

**Goal**: Directly eliminate invalid noise before conducting in-depth analysis.

### Filter Categories

If a defect falls into any of the following categories, **immediately mark as [filter] and remove**:

#### 1. Code Style and Conventions

| Determination | Example |
|------|------|
| Filter | "Use camelCase naming instead of snake_case" |
| Filter | "Indentation should use 2 spaces instead of 4" |
| Filter | "Single line length exceeds 80 characters" |
| Filter | "Missing blank lines for separation" |
| Do not filter | "Same variable name in different scopes causes symbol conflicts" (this is a real bug) |
| Do not filter | "Imported module name has a typo" (this is a missing dependency) |

#### 2. Non-Production Code

| Determination | Example |
|------|------|
| Filter | Test assertion style issues under `test/` directory |
| Filter | Mock data issues under `mock/` directory |
| Filter | Example code issues under `example/` directory |
| Do not filter | Security vulnerabilities in test files (hardcoded passwords, keys) |
| Do not filter | Issues in test files that would cause CI build failures |

#### 3. General/Theoretical Advice

| Determination | Example |
|------|------|
| Filter | "Strategy pattern could be used to optimize here" |
| Filter | "Consider introducing a cache layer to improve performance" (not a bottleneck path) |
| Filter | "Code readability could be improved" |
| Do not filter | "O(n^2) algorithm on a hot path will severely impact performance as data grows" |
| Do not filter | "Missing necessary error handling causing potential uncaught exceptions" |

#### 4. Documentation and Comments

| Determination | Example |
|------|------|
| Filter | "Missing Javadoc comments" |
| Filter | "TODO not completed" |
| Filter | "Typo in comments (does not affect runtime)" |
| Do not filter | "TODO for missing error handling in critical business logic" (if the TODO implies incomplete security handling) |

#### 5. Generic Scanner-Style Security Tips

| Determination | Example |
|------|------|
| Filter | "Recommend adding CSP headers" (no specific attack scenario) |
| Filter | "Recommend enabling HSTS" (no specific attack scenario) |
| Do not filter | "Exploitable XSS vulnerability exists (with specific attack path)" |

#### 6. Low-Impact Input Validation Issues

| Determination | Example |
|------|------|
| Filter | "Username field lacks maximum length limit" (will not cause crash/injection/data corruption) |
| Filter | "Date format not validated (has default value fallback)" |
| Do not filter | "SQL query parameters not validated leading to injection" |
| Do not filter | "File path parameters not validated leading to path traversal" |

#### 7. Low-Impact Logging Issues

| Determination | Example |
|------|------|
| Filter | "Inappropriate log level usage (debug should be info)" |
| Filter | "Missing method entry logging" |
| Do not filter | "Sensitive data (passwords/tokens) written to logs" |
| Do not filter | "Error logs contain full user input (potential log injection)" |

#### 8. Speculative Issues Without Evidence

| Determination | Example |
|------|------|
| Filter | "Theoretically there could be a race condition" (no specific trigger path) |
| Filter | "This parameter might be null" (no evidence that callers would pass null) |
| Do not filter | "This read-modify-write sequence will cause data inconsistency under high concurrency" (with specific trigger path and reproduction conditions) |

**Key determination rule**: **Must have a clear trigger path and reproduction conditions**, otherwise filter. Issues whose descriptions contain uncertain words such as "possibly", "maybe", "potentially", "theoretically" are filtered unless a specific trigger path is also provided.

> **Note**: False positive patterns specific to defect types (such as framework auto-managing transactions, ORM parameterized queries, etc.) require tool calls to determine and are not handled by this strategy. These patterns are checked by the respective refutation strategies in the validation stage.
