Rule Suppression

Silence rules at three levels: inline comments, project config, and CLI flags.

Every review tool needs a way to say “I know, shut up.” KERN gives you three levels of suppression — each with explicit rule IDs so nothing hides silently.

Inline comments

Add // kern-ignore with one or more rule IDs to suppress findings on the next line or same line.

Next-line suppression

Place the comment on its own line. It suppresses findings on the next non-blank, non-comment line.

// kern-ignore floating-promise
const data = fetch('/api/users');

Same-line suppression

Append the comment to the line with the finding.

const data = fetch('/api/users'); // kern-ignore floating-promise

Multiple rules

Comma-separate rule IDs to suppress more than one rule on the same line.

// kern-ignore floating-promise, empty-catch
try { fetch('/api'); } catch (e) {}

Python

Same syntax, different comment character.

# kern-ignore unguarded-effect
requests.get("https://api.example.com")

Rule ID is required. Bare // kern-ignore without a rule ID emits a warning. This prevents blanket suppression from hiding real bugs.

File-level suppression

Concept rules like unguarded-effect reason about relationships between code constructs, not individual lines. They only support file-level suppression.

// kern-ignore-file unguarded-effect
// ^ must appear in the first 5 lines of the file

import { db } from './db';
export async function seedDatabase() {
  // This file intentionally calls db without auth guards
  await db.insert(seedData);
}

If you try to use line-level suppression on a concept rule, KERN warns you and suggests the file-level syntax instead.

Concept rules

These rules only support kern-ignore-file:

• unguarded-effect — effect without auth/validation guard
• unrecovered-effect — effect with no error recovery
• ignored-error — error caught but silently dropped
• boundary-mutation — mutation crossing a container boundary
• illegal-dependency — disallowed import path

All other rules (AST, security, dead-logic, framework) support both line-level and file-level suppression.

Config-level suppression

Disable rules project-wide in kern.config.ts. These are team decisions checked into git.

// kern.config.ts
export default {
  target: 'nextjs',
  review: {
    disabledRules: [
      'config-default-mismatch',  // not relevant for our stack
      'confidence-missing',       // we don't use confidence props yet
    ],
  },
};

CLI flag

Disable rules from the command line. Merges with config.

# Disable one rule
kern review src/ --disable-rule=config-default-mismatch

# Disable multiple rules
kern review src/ --disable-rule=empty-catch --disable-rule=console-in-prod

CI strict mode

Teams want developers to suppress noisy rules locally while enforcing all rules in CI. The --strict flag controls which suppressions are honored.

Rationale: Config-level disabledRules are intentional team decisions (checked into git). Inline comments are individual developer decisions. --strict enforces the team contract while still allowing rules the team has collectively disabled.

# GitHub Actions example
- name: KERN Review
  run: kern review src/ --recursive --enforce --strict

Unused directive warnings

If a kern-ignore comment doesn’t match any finding, KERN emits a warning:

warning: kern-ignore-unused at src/api.ts:42
  Unused kern-ignore for 'floating-promise' — no matching findings

This prevents stale suppression comments from accumulating after refactors.

SARIF integration

Suppressed findings appear in SARIF output with suppressions metadata per the SARIF v2.1.0 spec. This preserves the audit trail in tools like GitHub Code Scanning and VS Code.

{
  "ruleId": "floating-promise",
  "suppressions": [{
    "kind": "inSource",
    "justification": "kern-ignore directive"
  }]
}

Quick reference