Your code review policy belongs in your repository, not a dashboard

Most tools configure per-repository behaviour in a web dashboard. It is the obvious place to put it and it has three problems.

• It drifts. Someone raises a threshold to silence a noisy week and nobody remembers.
• It is invisible. A policy change never appears in a pull request, so it is never reviewed.
• It is unattributable. Six months later nobody knows who turned off the security category, or why.

The file

Pullora reads an optional .ai-review.yml from the root of your repository. It sets the review mode, confidence thresholds, which finding categories are enabled, which paths to ignore, and your team's own rules in plain English.

reviewMode: standard
minInlineConfidence: 0.85
categories: [BUG, SECURITY, PERFORMANCE, TESTING]
ignore:
  - "generated/**"
rules:
  - React components must not call HTTP APIs directly; use the service layer.
  - Every hook that registers a subscription or timer must clean it up.

Because it lives in git, changing the policy is a pull request. It is reviewed, attributed, and revertible, and every engineer on the team gets identical behaviour without touching a dashboard.

The rules field is the useful part

Thresholds and categories are housekeeping. The rules list is where a team's actual conventions go, in plain English, and it is injected into the review prompt. Good rules are specific and checkable — "DB access only through src/db/repository.ts" beats "write clean code", which the reviewer already tries to do.

Guardrails, because config can be weaponised

Settings layer in a documented order: system defaults, then organisation rules, then the repository file, then dashboard settings, then a one-time instruction typed when submitting a review.

That last layer is deliberately restricted. A one-time instruction can change the review mode and add guidance — it can never raise confidence thresholds, add ignore paths, or disable security checks. The SECURITY category can only be switched off at organisation level, and is re-added automatically if a repository file omits it.

The reason is simple: without that, "ignore the auth changes" typed into a text box would be a way to suppress exactly the findings that matter most.

Failing safely

The schema is strict — unknown keys are rejected, so a typo cannot silently do nothing. But an invalid file never fails the review. Pullora reviews with the remaining configuration layers and reports the config error in the run log, so you find out without losing the review.