Remove code-level suppression — only config-level severityOverrides may silence findings

[CodeDeficient]

Policy

KarpeSlop must never suppress findings because of source-code comments.

These comments must not hide findings:

• eslint-disable
• eslint-disable-line
• eslint-disable-next-line
• @ts-ignore
• @ts-expect-error

Findings may be suppressed only through reviewed configuration (severityOverrides in .karpesloprc.json).

Comments and strings that contain assertion-like text are still excluded from AST detection as non-code. That is text parsing, not suppression — it must remain.

Evidence

Two separate suppression paths exist:

1. AST path (ai-slop-detector.ts:183-201): lineIsSuppressed() checks the current and previous lines for directive substrings. Called at lines 232, 269, 286, and 303 before emitting assertion findings.

2. Regex path (ai-slop-detector.ts:1049-1057): The generic pattern loop skips matches when the same or previous line contains a directive substring.

Both paths must be removed.

Requirements

• Same-line eslint-disable-line must not suppress any finding.
• Previous-line eslint-disable-next-line must not suppress any finding.
• @ts-ignore and @ts-expect-error must not suppress any finding.
• The policy applies to all assertion types (direct, chained, object, array) and all regex-pattern findings.
• severityOverrides: { "rule": "off" } must still suppress findings.
• Disabling unsafe_double_type_assertion must not disable an independent unsafe_type_assertion finding.
• .d.ts, test-file, mock-file, and configured path exclusions must remain.
• Comments and strings containing assertion-like text must still produce no AST findings (text parsing, not suppression).

Constraints

• Do not add a replacement comment convention.
• Do not change default severities.
• Do not remove test-file, mock-file, .d.ts, or configured path exclusions.
• Do not weaken AST protections against comments, strings, and template literals.
• Do not modify unrelated detector rules.
• Do not silently mutate configuration.

Validation

Before implementation, tests exist that expect code-level suppression to work (e.g., findUnsafeAssertions does not report as any when preceded by eslint-disable-next-line). These must be converted to expect findings to remain visible.

Add new tests proving:

1. Same-line eslint-disable-line does not suppress.
2. Previous-line eslint-disable-next-line does not suppress.
3. @ts-ignore does not suppress.
4. @ts-expect-error does not suppress.
5. All assertion forms (direct, chained, object, array) are affected.
6. A representative regex-pattern finding is also affected.
7. severityOverrides still suppresses the configured rule.
8. Disabling one chained rule does not disable independent findings.
9. Comments/strings with assertion text are still not parsed as code.

Rollback

A single reverted commit restores both suppression paths.

Relationship to Original Scope

This issue was originally filed as "findUnsafeAssertions suppression matching is substring-based, not directive-aware" — a narrow accuracy fix. The user has since decided that code-level suppression should not work at all. The scope is upgraded to match that policy decision.

[coderabbitai]

🔗 Related PRs

#9 - fix: resolve all false positives (issues #2, #6, #7, #8) [closed]
#23 - feat: detect unsafe TypeScript type assertions via AST (issue #22) [open]
#24 - feat: migrate unsafe_type_assertion from regex to AST detection [open]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!