Next.js configuration

If you are running a Next.js app (App Router or Pages Router, in a monorepo or standalone), the configuration below is a sensible starting point. It is the same shape we use on our own marketing, dashboard, docs and status apps in this monorepo.

Drop this at the root of your repository as .sebastionai.yml.

# .sebastionai.yml — Next.js / TypeScript playbook
# https://docs.foundationmachines.ai/docs/playbooks/nextjs

severity_threshold: low

ignore_paths:
  # Generated artifacts — Sebastion can't fix what your bundler regenerates.
  - "**/.next/**"
  - "**/.turbo/**"
  - "**/.vercel/**"
  - "**/next-env.d.ts"
  - "**/*.tsbuildinfo"

  # Test fixtures — intentionally weird input lives here.
  - "**/__tests__/fixtures/**"
  - "**/*.test.ts"
  - "**/*.test.tsx"
  - "**/*.spec.ts"
  - "**/*.spec.tsx"

  # Vendored / generated code.
  - "**/node_modules/**"
  - "**/vendor/**"

review_event:
  on_critical: request_changes
  on_high: comment
  default: comment

What each block does

severity_threshold: low

Leaves the default in place. We do not recommend raising this above low on a Next.js app: the medium-severity bucket is where most real Next.js bugs live — stored XSS in non-privileged components (the classic example is dangerouslySetInnerHTML on user-controlled content without a sanitisation layer), weak input validation on server actions and route handlers, weak crypto in security-critical paths, and race conditions in non-privileged flows.

Sebastion's audit is LLM-driven, so not every instance of every pattern surfaces on every PR. That's another reason to keep the threshold at low: narrowing the floor on top of imperfect detection compounds the misses. Raising the threshold to high to "get less noise" usually means missing the findings you would most want to see.

If you genuinely want only critical + high, raise it explicitly:

severity_threshold: high

…but read the false positives and Learnings guide first. Targeted suppression beats a broad floor.

ignore_paths

Three categories, in order of importance:

1. Generated artifacts. .next/, .turbo/, .vercel/, next-env.d.ts, *.tsbuildinfo. Auditing build output is wasted spend and produces findings you can't fix without changing the generator.
2. Test fixtures. Test inputs are often deliberately malformed: weak crypto for round-trip tests, hardcoded "secret" strings the test asserts equality against, SQL strings that exercise an escape. Excluding fixture files keeps the signal:noise ratio reasonable. We exclude the whole *.test.ts / *.spec.ts family by default; if you write real production logic in those files, narrow the pattern.
3. Vendored code. node_modules/ should never show up in a diff review anyway, but exclude it explicitly in case a transitive tooling change starts including it. vendor/ is the same.

Glob syntax matches what Sebastion's filter pipeline expects: * within a segment, ** across segments. See config reference for the exact semantics.

review_event

The defaults — request_changes on critical, comment on high, comment otherwise — are what we recommend for the Next.js stack and why we leave the block visible rather than implicit:

• on_critical: request_changes turns a critical finding into a CHANGES_REQUESTED review on the PR. If branch protection requires passing reviews, this gates the merge. For a customer-facing app serving HTTP traffic, that is almost always the right behaviour: a critical Sebastion finding is on the order of "remote code execution" or "auth bypass" and you want the merge blocked until a human looks.
• on_high: comment posts the finding inline without blocking. High-severity findings on Next.js apps include things like SSRF on a fetch helper or a missing rate limit on a public endpoint. They are worth looking at this sprint, not necessarily worth blocking the release.
• default: comment covers medium/low/info. Inline comments only.

If you are an early-stage team and want to ship fast, you can soften the critical gate:

review_event:
  on_critical: comment
  on_high: comment
  default: comment

…but log this as a deliberate trade-off. You are choosing speed over "merge blocks on RCE-shaped findings". For most teams that lasts about one incident.

What we deliberately did not include

A few things you might expect to see, that are not in the recipe:

• disable_scanners is left empty. Disabling whole scanner classes saves cost but loses coverage. If you genuinely have a duplicate SCA scanner (Snyk, Dependabot doing the same job as our OSV scanner), then yes, add disable_scanners: [osv]. Otherwise leave it at default.
• disable_rules is left empty. Most teams should reach for AGENTS.md markers first — they are path-scoped, base-branch-trusted, and visible to your other agentic tools. See suppression strategy.

Companion AGENTS.md

If you do not already have one, drop this alongside the YAML:

# AGENTS.md

## Sebastion AI suppressions

# sebastion: ignore js.console-log in scripts/**

That one line treats scripts/ as a place where console.log is fine (it usually is — they're CLI scripts, not production code) and keeps the audit signal clean without touching disable_rules. Add more lines as you find legitimate per-path exceptions.

The AGENTS.md file is read from your base branch only, so a PR that adds a new suppression marker has no effect until that PR is merged. This is deliberate — see the base-branch trust boundary.

Related

• .sebastionai.yml reference — every key, every type, every default.
• Suppression strategy — when to use disable_rules vs AGENTS.md vs the chat command.
• Learnings hygiene — keeping your suppression set healthy as the repo evolves.