Frazer Reviewer

Frazer Reviewer reviews what people and agents write, with models of other families than the author’s and evidence before opinions. It has three kinds: code review of pull requests and diffs, security review of changes and repositories, and cold review of plans and documents. All three run on one engine, with one set of settings, one findings model and one ledger, so a finding is never posted twice and every kind learns from the same calibration. Inline comments appear only for findings with evidence: a test failed at the pull request’s head, a verifier of another model family traced the code, a rule you approved matched, or a tool found something new in the diff. Everything else is folded into one summary that is edited in place.

The Reviewer works natively on Fir, as a GitHub App on GitHub, and on any diff or file through the CLI and the API, including on its own with nothing else on Frazer and without write access to your code. Product overview: Frazer Reviewer.

Three kinds, one Reviewer

Kind	Reviews	Deterministic first	What comes back
Code review	Pull requests and stack layers at each version; workspace snapshots; local diffs; any diff by API	Build, lint, type check and tests; secrets, licenses and advisories	Findings with an evidence grade, the verdict and Would approve, the expected effects of the change, and a run passport
Security review	Diffs through security lenses; repository and folder scans on a schedule, and deep scans; threat models; plans of risk class R2 and R3; lockfile and dependency diffs; agent configuration; findings imported from other scanners	Static analysis rules, secrets, advisories, licenses, release age, install-script and binary diffs	Findings with their CWE, the attack path, validation evidence and a suggested patch, as SARIF 2.1.0, with a revision stamp
Cold review	Plans and every engineering record or document (specs, decision records, runbooks, postmortems, agent instruction files), in Fir, on GitHub or as any file; the conformance pass before a plan closes	The plan checks’ static stages	Questions and verdicts, a coverage map and the readings of each criterion compared (The planning flow)

Tests, architecture and design rules, docs accuracy, performance, infrastructure and UI with a preview are lenses inside code review, not kinds of their own. Frazer Context’s verify keeps its own name and runs on this engine, and so do the panels of Frazer Decisions and the verifier of conflict repairs; one fix to the engine reaches them all, and every finding lands in one calibration.

Kind	In Fir	On GitHub	Any file or diff, outside both
Code review	Native: findings are objects and the merge policy reads the verdict	The Frazer Reviewer App: review comments and a check run	frazer review <patch, directory or --remote>; reviews_request with a patch; zero retention available
Security review	Native; scans on a schedule per repository; findings on the pull request and in the Security page	The same App; SARIF uploaded to code scanning; on a public repository a finding posts only “a security finding is open, details in Frazer” to people with access	frazer review scan <dir>; SARIF out; frazer review triage <findings.sarif>
Cold review	The plan/cold-review check, the record’s page and the Reviewer’s pages	Plan files in a GitHub repository through the Reader App	frazer review plan.md, the kind inferred from a Markdown record; request_cold_review with a file

How a code review works

Each pull request version gets one review:

1. Static first. Build, lint, type check and tests run in Frazer CI, with each class’s preconditions, secrets, licenses and advisories. If any fails, the author fixes it first and the model passes are held, with what they would have cost (“held · 1 test failing · saves $0.14”).
2. Triage, without a model: bots, releases, dependency bumps, generated code and stale bases are detected; risk from paths, owners, blast radius and runtime signals picks the depth and whether to run code.
3. Lanes: code; manifests (a GitOps diff for pull requests to environment repositories); dependencies (advisories, changelogs, lockfile-only changes); contracts (proto and OpenAPI changes checked for breaking changes, with the consumers they touch).
4. Context through Frazer Context: what is in force for the diff, the plan item and its done agreement, the hunks and full files, your rules and guideline files, earlier threads, neighbors in the code graph, and by default the other repositories that consume what the change touches.
5. A two-stage screen. A fast pass over every changed hunk marks what needs a deep pass; deep passes run on the flagged hunks and on always-deep paths, on the same cached prefix. Security lenses read the code before the pull request’s description: the description is untrusted data, and a finding that disappears once it is read is kept, marked framing-sensitive.
6. Verify. Every candidate of Medium severity or higher goes to a verifier of another family than the one that found it and than the author’s; the executor tries to write a test that reproduces it. The outcome is Reproduced, Verified, Refuted or Unknown.
7. Rank and merge. Findings merge through the ledger; repeated instances of one pattern are one finding with its locations; a finding against a decision in force cites the decision and reads “revisit the decision?”, never “a defect”. Would approve is decided by blockers (a High finding, a failing proof, a scope breach), and weighted items (tests, scope discipline, style, standards) score.
8. Post, then watch. One review and one check run. The review writes its expected effects (what should move and what must not, from the plan’s success metrics and the handlers the diff touches); after the deploy, Frazer Releases’ canary compares them, a regression is an escape that labels the review, and at the Merge stage it reverts.

Agent-written pull requests are always reviewed, bots included, with no size limit: a large pull request is reviewed in child jobs whose findings post as they finish, with a suggestion to split. A clean review lists what it checked and says that no findings is not proof of no defects; a check without its result line means “no verdict”, never zero findings.

Depth is the panel’s ladder, the same for every kind:

Depth	What a code review runs
off	The deterministic checks only
light	One pass by another family, and the screen
standard	Two passes by two other families, and a verifier of a third on Medium-or-higher candidates
deep	Four passes, two file orders per family, a verifier on the strongest tier, reproducing tests and mutation evidence on the changed lines; with reads: preview, smoke tests and screenshots on a preview environment
exhaustive	Every family, two rounds, every candidate reproduced or refuted, the estimate first

Where code runs. Reviews run in a sandbox, or a microVM when tests need containers or services. Tests run in your project’s devbox image, built from the same devcontainer.json or devbox template your engineers use, so “works on my box” means “works in review”; test commands are detected from the devcontainer, CI workflows and Makefiles, or pinned in .frazer/review.yaml. A sandbox gets no secrets beyond declared test credentials, no write tokens, and egress only to the package cache and the LLM gateway; one organization per VM node. A preview review uses the preview your environment’s preview policy creates on the project’s staging cluster through Frazer GitOps, behind Frazer sign-in, torn down on merge or close.

One set of settings

One review: block has the same fields for every kind: in the review policy (code and security), in a plan type and the plan approval policy (cold review), and in .frazer/review.yaml for the keys a policy marks overridable. Layers go from organization to project, repository or record type, path and target; the stricter wins, and a locked floor cannot be lowered.

# acme-production · review policy default@v7 (the same keys in a plan type's review: block)
review:
  code:
    depth:      {R0: light, R1: standard, R2: standard, R3: deep}    # the panel's ladder
    strictness: {R0: advise, R1: ask, R2: ask, R3: block}            # what a finding does
    threshold:  normal                                                # quiet | normal | thorough: what is shown inline
    reads:      [diff, repository, history, plan, runtime, other_repositories]
    loop:       {on: agent_authors, max_turns: 8, budget_usd: {R0: 0.50, R1: 2, R2: 4, R3: 15}, final_pass: true}
  security:
    depth:      {R0: light, R1: standard, R2: deep, R3: deep}
    strictness: {R0: ask, R1: ask, R2: block, R3: block}
    scans:      {schedule: weekly, deep: monthly, paths: ["services/payments/**"]}
    blind_first: true                                                 # the description is read after the first pass
  cold:         {inherit: plan_type}                                  # the planning flow's defaults by risk class
  panel:        acme@3                                                # uses code_review, security_review, cold_review
  budget:       {per_project_month_usd: none}                        # the estimate shows before every run

Setting	Values	What it does for code review
depth	off, light, standard, deep, exhaustive	How hard the models look (above)
strictness	advise, ask, block	advise: the check is neutral. ask: posted findings of Medium or above need a resolution before merge (fixed, answered, contested with evidence, or dismissed by a person), enforced by Fir. block: calibrated findings at or above the policy’s severity fail the check, and a Reproduced High always does
threshold	quiet, normal, thorough	What goes inline, at precision targets of 90 %, 80 % and 65 %; new organizations start on quiet, and normal unlocks after 50 judged findings with less than 25 % refuted
reads, lenses	Per kind	Code: diff, repository, history, plan, runtime, preview, other_repositories
panel	The panel with the uses code_review, security_review and cold_review	Families by lineage, never replaced by another family
budget, loop	Per review, per loop, per project-month; the loop’s turns and budget	The estimate shows before every review and every loop turn

The defaults by risk class for every kind sit on the panel’s one settings screen beside decisions and context verify, so a team sees one policy.

Findings

• One shape for every kind: its kind (defect, question or verdict), class (with its CWE for security.*), severity, anchor and quote, evidence and its grade (reproduced, verified, rule, analyzer, diff, runtime, citation), a suggested fix, who raised it (sealed, member, family, tier), agreement (“2 of 3”), a fingerprint, its calibrated p_valid and p_act with their counts, what it blocks, its state and its resolution. Exports: SARIF 2.1.0, annotations and the check’s JSON line.
• One ledger per target, across passes, loop turns, the layers of a stack and the kinds, so code review and security review never post the same finding twice. A finding’s fingerprint follows its anchor through moves and renames; near-duplicates whose wording only partly overlaps are confirmed by an adjudicator of another family.
• Dismissals need a reason and carry a scope (this finding, this pattern in this repository, this rule) and an expiry (180 days by default for security classes). A dismissal is context for later reviews, never a suppression of a class or a path, and it stops a finding from returning only while its code is unchanged. A share of dismissals each month is adjudicated again, because a dismissal is also a label.
• An agent’s pull request carries five facts: a bounded scope, a rationale with links, evidence beyond CI, the responsible agent and person, and the owner after merge. A missing fact is a deterministic finding before any model pass.

Security review

Part	What it does
On every pull request	Security lenses (where input enters and where it ends up), the description read only after a first pass, at deep three families on the strongest tier; exploits reproduced as exploration tasks in Frazer CI; the CWE, the attack path and a patch
Thresholds	Calibrated per class like every finding; until a class has 50 labels, automatic reviews post High and Critical and a requested review posts Medium and above
Scans	A repository or a folder on a schedule; deep scans run several independent scans and combine them; each report carries a revision stamp: the commit, the depth, whether uncommitted changes were read, and how thoroughly it was verified
Threat models as records	A typed engineering record per repository (assets, trust boundaries, assumptions), versioned and reviewed like a plan; reviews and scans read the version in force, and without one a scan proposes a draft
Threat review of plans	The cold review of an R2 or R3 plan runs a security lens against the threat model and the plan’s design: new trust boundaries, data flows, secrets, tenancy
Supply chain and agent configuration	Lockfile diffs, release age, provenance, install scripts and binaries, advisories; instruction files, MCP configuration, skills, hooks and tool grants
Other scanners’ findings	Imported SARIF is a backlog of unproven claims: each one is checked for reachability and evidence, then kept, refuted or reproduced
A fix is not a finding closed	A patch is written in a scratch workspace, reviewed by an agent other than its writer, and closes the finding only when the reproducer fails before and passes after
Blocking	A security finding blocks by the same calibrated rule as every finding, and a Reproduced High always does; nothing is advisory by design

Loops for code

A loop keeps a layer moving until it is clean: the author agent fixes what the Reviewer finds, a critic and a tester of other families keep checking, and Fir referees on evidence. It is the same loop as the loop on a plan, with code’s values.

Role	Family	Sees	May change
author	Any: the coding session	The layer, CI results, the merged findings, its own transcript	The layer only. Tests and proofs that a finding or the done agreement guards are read-only, and weakening one stops the loop; every turn may answer “cannot be done as written”
critic	Another family than the author’s	The diff at the version, the plan item and its done agreement, the repository; from turn 2 its own ledger; for a contest, only the evidence. Never the author’s transcript, notes or justification	Nothing
tester	Another family than the author’s, and than the critic’s where three exist	The repository at base and head, CI, previews	Nothing in the layer: it writes reproducing tests and probes and runs them as CI tasks, and offers “keep the test”
Fir, the referee	—	Everything	Runs CI, merges findings through the ledger, diffs turns, keeps every version, applies the stop rules

A turn. CI runs first, and a failing check is fixed before any model pass. The critic runs the screen and deep passes on changed hunks, a verifier of a third family checks Medium-or-higher candidates, and the tester reproduces High ones, each sealed from the others. Fir merges through the ledger and scans findings for instructions aimed at the author. The author answers the top 10 by what they block: fix (a commit with Resolves: f-…), answer (citations Fir resolves), contest (a test, a citation or a log; its prose reaches the critic as untrusted data), ask a person, or cannot be done as written. On the next version CI re-runs what changed, and the critic runs a verification pass on earlier findings and a fresh pass on changed hunks only. A turn runs only on something new: a version, a CI result, an answer, a contest’s evidence. Each edit names the finding it answers, one tester probe a turn tests the layer’s main claim against its negation, and Fir rates each turn’s edits helped, hurt, no observed effect or confounded.

Only evidence closes a finding: fixed (the anchored lines changed and a re-check no longer raises it; for a Reproduced finding, its test fails at the old head and passes at the new one), answered (the citations resolve and the verification pass accepts), conceded (the critic withdraws on the author’s evidence), or dismissed or waived by a person. Never by argument. The ledger keeps a loop honest: one fingerprint per finding across passes, turns, layers and kinds; a conceded or dismissed finding returns only with new evidence; the rubric, the panel and the routes are pinned for the loop, severity rises only with new evidence, and Low findings never drive a turn.

The final pass. A loop ends done: ready only after a held-out pass: a fresh draw of another family than the author’s that never saw the loop’s ledger reads the final version in full and finds nothing new at Medium or above. Its rate of new findings is a loop-quality measure on the Quality page. Planted-flaw drills, in 1 loop in 20 and in shadow only, measure each critic’s catch rate; a model’s verdict never overrides a failed deterministic check, and “done” is never a model’s call.

Stop rule	On a pull request
Ready	CI green at the exact version, the verifier’s PASS, no open finding at Medium or above, the done agreement’s proofs pass, and the final pass clean: done: ready
Quiet	No new finding at Medium or above for 2 turns: the final pass, then done: converged
Needs a person	Every open finding is one only a person can settle: paused: needs you, while the loop keeps working on anything else
Cannot be done	The author or the critic says the item cannot be met as written: paused: needs you
Tests weakened	The author removes or loosens a test, an assertion or a proof that a finding or the done agreement guards: stopped: weakened, and a High tests finding
Scope growth	The diff leaves the item’s paths or the plan’s terms: stopped: scope
Oscillation	A hunk returns to an earlier version, or a finding reopens after two resolutions: that hunk is frozen and becomes one question
Regression	A check that passed fails: the next turn fixes it first; a repeat restores the best version and stops
Diminishing returns	No finding resolved for 2 turns while edits continue: done: converged, then the final pass
Budget, time, turns	By risk class: R0 $0.50 and 20 minutes, R1 $2 and 30 minutes, R2 $4 and 1 hour, R3 $15 and 4 hours; 8 turns
Fresh start	A finding fixed twice and still raised restarts the author from the item and the finding, not from its transcript

When a person is asked: one card with both sides (the finding and the critic’s evidence, the author’s evidence, the view of an adjudicator of a third family, and a recommended answer), after two contests on one finding, on oscillation, when a budget is spent with blocking findings open, or for a question only a person can answer, which becomes a decision row. A credential, a purchase or a registration becomes a person task. A question already open on the same subject elsewhere is linked, never asked twice.

How a loop starts: by default on every layer an agent writes, in every class and repository (loop: {on: agent_authors} is the default, and one setting turns it off); by hand (Fix until clean, frazer review loop, reviews_loop); inside the agent’s own session before the pull request exists, as self-review over MCP; and on any file through the API. People’s own pull requests get one review with fixes offered, never pushed, unless they start a loop. When funds run out, a loop stops between turns as “Paused: no funds” and keeps its best version; it never runs cheaper. Lanes, verdicts, the review ledger and outcomes: Lanes, verdicts and outcomes.

Findings become static checks. Findings that people and agents keep fixing in the same shape become rule drafts: a pattern or CEL rule that reproduces the class’s findings on history, with a backtest on a frozen, labeled set at a precision of at least 0.9 before it may block as a deterministic check. The rules’ owners approve each draft, a rule that finds nothing for 180 days is proposed for retirement, and the rules run in CI’s static stage, so the model pass that used to find these is not paid for again.

Demo (pellwyn/admin#2318 “Release a hold from the console”, item P12.3 of plan #414, risk class R2; author coder in session s-3e9a; critic and tester of two other families; Oct 17; product UI, demo data):

Time	Turn	What happened
10:02	v1	CI green. The screen flags 6 of 31 hunks. Turn 1 at standard: 14 raw candidates merge into 5 findings. F1 High security.authz “release checks the role, not the hold’s tenant”, reproduced by the tester (TestReleaseHoldOtherTenant fails at v1); the description says “tenant checked in middleware”, and one member withdrew F1 after reading it without citing code, so F1 stays, marked framing-sensitive. F2 Medium “releasing twice writes two ledger entries” (2 of 2). F3 Medium “no timeout on the ledger call”. F4 “May a support agent release a hold above $10,000 without a second approver?”: already open as decision #414 §D1 from the plan’s own loop, so linked, not asked again
10:09 to 10:16	v2	coder fixes F1 (and keeps the tester’s test) and F2 (an idempotency key), contests F3 with ledgerclient/client.go:41 (a 2 s timeout set in New), and ships the safe default for F4
10:16	—	CI: TestReleaseAudit fails, so the model passes are held; coder fixes it in v3 at 10:19
10:20	Turn 2	Verification: F1 fixed (its test fails at v1 and passes at v3), F2 fixed, F3 conceded on the citation. A fresh pass on changed hunks finds F6 Medium “the key uses the hold ID only; two releases of different amounts collide”
10:26	v4, turn 3	F6 fixed: the key adds the hold’s version. Nothing new at Medium or above
10:30	Final pass	A fresh draw reads v4 in full, with no ledger: clean. done: ready at 10:33

Three turns, four versions, 31 minutes, nothing to a person but a decision that was already open; the layer merges inside the plan’s terms on its proofs and the verifier’s PASS.

At 10,000 to 50,000 a day

At tens of thousands of pull requests a day, the Reviewer decides what it may alone, summarizes the rest, and brings a person only what needs one:

The Reviewer decides alone	It summarizes	It brings to a person
The verifier’s verdict on every layer	Exception groups by cause (“the same missing timeout in 37 layers of the ledger-client campaign” is one row and one decision)	Findings at Medium or above that a loop could not resolve, on paths that need a person
Approvals and merges in classes past their gates	A daily digest per scope: lanes, top classes, escapes, loops by stop reason, cost	Disputes after two contests, oscillations, budgets spent with blocking findings open
Resolving findings with the author agent in loops	What merged without the person and on what evidence, with one sample to read	Never-automated paths, policy changes, promotions, lifting a kill switch
Grouping, ranking, suggesting what to close (never closing it)	Rule drafts with their backtests	Audit samples of automated approvals; decisions raised by findings; person tasks

Every pull request ends in one outcome: merged on its receipt (inside an approved plan’s terms, with the verdict’s pass), merged by an autonomy stage, with agents (a loop or CI running), batch (clean, its class not automated yet: one approval for a group inside one plan’s terms), needs you, audit, or closed. The Inbox opens with its counts (“45 need you · 17,600 merged · 1,947 with agents · 8 need others · 400 closed · 20,000 today”, priya at Pellwyn on Nov 17, demo data), a strip of what each kind needs, Needs you as exception groups with “covers 37” and the one action, the budget line (“2 of 25 decided · 8 of 90 min”), and an outcomes table that rolls up by plan level and stack; the Comfortable rows stay as the small team’s view. Agents read the same view as data with reviews_inbox. A campaign’s shards are reviewed as one pattern at the campaign’s approval, so they reach a person as one daily campaign review.

In the console

Engineering › Reviewer has nine pages, one job each:

Page	Job	Key
Inbox	What needs me now, at any volume	g i
Reviews	Any review of any kind; Pull requests is a saved view (kind:code)	g v
Security	Scans, the findings backlog with triage and dismissals, threat models	g s
Lanes	The catalog and your lanes by group, with their states, owners, harness profiles, backtests and learning numbers; learned rules and custom checks are lanes or parts of lanes	g l
Loops	Every loop with its turns, stop reason and cost; exceptions first	g o
Outcomes	Outcome links (told, missed, partial, outside), miss analysis reports and lookbacks	g c
Autonomy and audit	Classes by stage, gates, promotions, kill switches, sampled approvals and adjudications	g a
Quality	One analytics surface for every kind and loop: precision with its interval per kind and class, escapes, reliability diagrams, the cold review’s catch rate, loops’ turns and stop reasons, the final pass’s new-finding rate, dismissals, the model passes static checks held	g q
Settings	One settings model for every kind; repositories are its tab	g t

Install and turn on review

You need to be an admin of the GitHub organization and of your Frazer organization.

1. Install the GitHub App. Open Engineering › Reviewer in the console and choose Connect GitHub, or install Frazer Reviewer from the GitHub Marketplace. Choose the repositories. Frazer binds the installation to your organization after it checks that you are an admin in both places. Before you install, Try on a public PR runs a shadow review that shows only in the console and is never posted.

   The App asks for these permissions:

   Permission	Access
   Contents, metadata, Actions, commit statuses, members	Read
   Pull requests, checks, issues (for pull request comments)	Write

   It listens to pull requests, reviews and review comments, issue comments, check runs, pushes to the default branch and installation changes.

2. Turn on automatic review for the repositories you chose.

   CLI

   frazer reviewer enable --repos 'acme/*' --depth standard --trigger open,push

   Console

   On Engineering › Reviewer › Inbox, once the App is installed, pick a policy for the repositories you chose. Settings › Repositories then lists each repository with its policy, trigger, depth and coverage.

   Automatic review is set by the policy, not by a file in each repository, so every repository the policy matches is reviewed from the first pull request.

3. Open a pull request. The Frazer Reviewer check run shows the current step and an estimate of the time left (“Verifying 4 candidates”). When it finishes, the pull request gets one summary review, and inline comments only for findings with evidence. A push edits the same summary; a new inline comment appears only for a new finding on a changed line.

4. Answer it. Reply /frazer wrong <why> or /frazer useful on a finding, or ask @frazer-reviewer <question> in the thread. Every reply reaches the findings ledger, and a refuted finding is not raised again while its code is unchanged.

Configure a repository

A review policy sets the defaults for the repositories it matches. A repository can change the keys the policy marks overridable with .frazer/review.yaml, read from the base branch, so a pull request cannot change how it is reviewed:

.frazer/review.yaml

version: 1
trigger: { on_open: true, on_push: incremental, drafts: false, skip_authors: ["renovate[bot]"] }
depth: { default: standard, deep_when: { risk: high, paths: ["services/billing/**"] }, light_when: { lines_lt: 20 } }
execute: { tests: auto, preview: on_label("preview"), fork_prs: never }
post: { inline_min_grade: verified, inline_min_severity: medium, max_inline: 8, nits: summary }
paths: { ignore: ["**/*.pb.go", "gen/**"], instructions: [{ glob: "migrations/**", text: "Every migration is reversible." }] }
lanes: { manifests: { app_pattern: "{env}-{service}", policies: [frazer-policy] }, contracts: { buf: true } }
memory: { learn: drafts } # off | drafts
privacy: inherit # the stricter of org and repo wins

Apply a policy from a file, and read the plan first:

frazer reviewer review-policies apply -f review-policy.yaml --dry-run

Review policies are also resources in the Terraform and OpenTofu provider.

Guideline files are read automatically: REVIEW.md, AGENTS.md, CLAUDE.md and the instruction files of other coding agents and review tools, each scoped to the folder it sits in and each with its own switch. A review lists the guideline files that applied to it. Where a setting came from: /frazer config on a pull request, and Settings › Repositories in the console, show the effective configuration with the origin of every key (policy, .frazer/review.yaml or default). Keys the policy locks show the policy.

Read a review

The summary is one review per head, at most 15 visible lines, edited in place on every push with a “Since last review” line:

Summary review

**Frazer Reviewer** · deep · 3 findings with evidence · 1 should be fixed before merge
ConfirmStream skips the new coupon validation and panics (reproduced by a test). The memory limit in platform-envs#322
drops below live p95. One proto field was renumbered.

| Severity | Finding                                | Evidence                              | Where                              |
| -------- | -------------------------------------- | ------------------------------------- | ---------------------------------- |
| High     | ConfirmStream panics without coupons   | Reproduced · test fails at head       | `internal/checkout/confirm.go:142` |
| Medium   | Production memory limit below live p95 | GitOps diff · p95 611 MiB             | `values.yaml:31` (#322)            |
| Medium   | `coupon_code` renumbered 7 → 9         | Analyzer · breaking change · 2 consumers | `checkout.proto:58`             |

<details><summary>Walkthrough · 7 files · effort 3/5 · related: #1902, issue #1877</summary> … </details>
<details><summary>Checks · 4 passed · 1 warning (Linked issue: 1 requirement not covered)</summary> … </details>
<details><summary>What we checked · Not verified (9) · Pre-existing (2)</summary> … </details>
<details><summary>Run passport</summary> models · sandbox · tests · cost · time · fallback · engine · config origin </details>

With no findings, the summary is one line, or nothing when the policy sets post_clean: false; the check run always reports.

Inline findings carry a header (severity, category and evidence badge), a title, why in at most 3 lines, a folded evidence block, a suggestion block when the fix is at most 15 lines in one hunk, and a folded Prompt for AI agents with the file, line, intent and the name of an acceptance test. At most max_inline findings go inline (8 by default), anchored on new lines only. The six badges:

Badge	Meaning	It carries
Reproduced	A test or command ran and failed at the head	The command, the output tail and an artifact link
Verified	A verifier from another model family traced the code	2 to 4 path:line citations, including callers and guards
Rule · name	A rule your organization approved matched	The rule’s precision and a link to it
Analyzer · tool	A tool found something that is new in this diff	The tool and its rule ID
GitOps diff	The change rendered against live state	The object, the live value and the cost change
Runtime	Metrics or an incident on the code it touches	The series, the window and a chart link

Check runs. Frazer Reviewer follows the policy’s strictness, and carries the findings table and one machine-readable line:

Check run summary

<!-- frazer-review {"high":1,"medium":2,"low":0,"pre_existing":2,"grades":{"reproduced":1,"verified":0,"rule":0,"analyzer":1,"gitops":1}} -->

Paused, capped, skipped and failed are explicit conclusions with the reason, such as “Skipped: generated code only”. Frazer checks has one row per pre-merge check (Pass, Warn, Fail or Inconclusive, with the reason) and fails only for checks set to Block.

Pull request commands:

• /frazer review [light|standard|deep] [full]: review now, at a depth.
• /frazer pause, /frazer resume, /frazer cancel; /frazer ignore in the description skips the pull request.
• /frazer summary, /frazer explain [n], /frazer diagram.
• /frazer check [name]: run one pre-merge check.
• /frazer wrong|useful|resolve [n]: feedback that reaches the ledger.
• /frazer remember <rule>: create a rule draft.
• /frazer config: the effective configuration, with the origin of each key.
• /frazer fix [n|all], /frazer tests, /frazer docstrings, /frazer preview: work by an agent, below.
• /frazer run: let a pull request from a fork run code.
• /frazer help; @frazer-reviewer <question> is chat.

Teach it rules and checks

Rules from feedback. After three similar replies, Frazer drafts a rule and records where it came from. Before an admin can approve it, a backtest replays the rule over the findings of the last 50 pull requests in its scope (“would silence 11 findings, 9 of them refuted”). An approved rule’s precision is measured from then on, and a rule that falls below 60 % retires. Nothing is learned silently.

frazer reviewer review-rules list --state draft
frazer reviewer review-rules approve <rule>

/frazer remember <rule> on a pull request creates a draft the same way. Rules are served over the Frazer MCP server, so a coding agent on a devbox sees them before it opens a pull request.

Checks in plain language. Write a pre-merge check of up to 2,000 characters, choose its scope and the evidence it may use, and set it to Off, Warn or Block. Save is enabled only after a backtest on the last 20 merged pull requests in scope. A Block check stops merges only when your branch protection requires Frazer checks. Built-in checks cover the title convention, the description template, whether the linked issue (GitHub Issues or Linear) is satisfied, reversible migrations, touched tests, contract compatibility, manifest safety (GitOps diff and Frazer Policy) and new secrets.

Rules and checks in the console lists drafts, active rules, retired rules, path instructions, guideline files and silenced fingerprints; Unsilence brings a silenced finding back.

Request reviews and fix findings

Review your local diff, a directory or a branch you have not cloned. Each prints its estimate before it starts, and --format json or --format agent gives an agent the result with exit codes from the one table: 0 clean, 11 findings at or above --fail-on, 2 a usage error, 7 when it could not finish in time, and 13 when only a person can unblock it (Not run: no funds, or an approval):

frazer review . --base main --format agent
frazer review --remote acme/storefront --source-branch lena/retry-errors
frazer review scan services/payments --deep
frazer review triage findings.sarif
frazer review loop . --budget 2 --max-turns 8

Request a review of a pull request at a depth:

frazer reviewer reviews request acme/storefront#1931 --depth deep --execute

From a finding:

• Commit suggestion applies GitHub’s suggestion block under your own identity. The Reviewer App writes nothing.
• Fix with agent and Fix all open a confirm sheet in the console with a cost estimate, then start a loop through the separate Frazer Agents App: tests first, up to 8 turns with a held-out final pass, delivered as a stacked pull request. A link never changes anything until you confirm.
• Keep the test commits the test that reproduced the finding.
• Open in devbox opens the file and line with the prompt loaded.

Pull requests from forks never run code until a maintainer types /frazer run.

Choose models and privacy

Models are reached only through the LLM gateway, with your organization’s key or billed by Frazer. The panel picks the families for each use, so the members who find, verify and review never share the author’s family; Settings › Models pins model versions and caps monthly spend. “No silent fallback” is on: when a model is unavailable, reviews pause instead of switching models, and every review’s run passport records the models, served deployment, fallback, prompt hash, cost and time.

Mode	Code	Index	Findings text kept	Models
Standard	In the sandbox only, deleted when the session ends	Encrypted per organization, rebuilt from Git, deletable	180 days	Providers that do not train on inputs
Zero retention	Same	None; rebuilt for every review, which is slower	Counts and fingerprints only; the text lives on GitHub	Zero-data-retention providers only
Private placement	Runs on your own server pool	In your pool	Your choice	Your key or your own model endpoint

When a repository’s file and the policy disagree on privacy, the stricter one wins. Secrets are redacted from everything sent out.

Access and audit

• The App reads and comments. It never pushes, approves or merges; fixes go through the separate Frazer Agents App, only after you confirm.
• Every review session is an agent principal acting for your organization; it cannot approve or merge.
• Trusted base, untrusted pull request. Policy, rules and sandbox templates come from the base branch and the Frazer API; the pull request’s text, diff and files are data, never instructions.
• Review policies are edited by the admins of the project that owns them, and are read-only for the projects they are shared with. Each repository is linked to one project.
• Rules are approved by admins after a backtest; an agent can never dismiss a blocking finding or lift a kill switch.
• The record: every review has a run passport; replies, reactions and /frazer commands reach the findings ledger next to the rule drafts they produce.
• Retention: findings text is kept 180 days in Standard mode; in Zero retention, only counts and fingerprints.

Limits and quotas

Setting	Default
Reviews per pull request head	1, edited in place
Summary length	At most 15 visible lines
Inline findings per review (max_inline)	8
Committable suggestion	At most 15 lines in one hunk
Rule draft	After 3 similar replies
Rule backtest	The last 50 pull requests in scope
Check backtest	The last 20 merged pull requests in scope
Precision for a rule finding to go inline	At least 80 %
Rule retirement	Below 60 % precision
Check instruction	At most 2,000 characters
A loop	8 turns, and the budget of its risk class
Dismissal of a security finding	Expires after 180 days
Rollout watch after merge	30 minutes
Spend alerts	50, 80 and 100 % of the monthly cap
Findings text	180 days

There are no hourly limits per developer. Caps are in dollars only: a monthly cap pauses new reviews and never posts half a review, and organizations get a fair share of capacity.

Pricing

Frazer Reviewer is priced two ways, by who opened the pull request.

• People’s pull requests are priced per active human committer a month, and the seat costs less when you bring your own model key. Each paid committer adds light and standard reviews to a monthly pool that the whole organization shares. Reviews above the pool are billed per review, and so are deep reviews and reviews with a preview, each with its cost estimate before it starts.
• Agents’ pull requests take no seat and no share of the pool. Each review pays its model tokens at the LLM gateway’s price, or nothing for tokens on your own key, plus a fee by depth: light $0.01, standard $0.05, deep $0.20, exhaustive $0.50. A security review costs 2 times the fee, and later loop turns 40 % of it. A pull request is an agent’s when the identity that opened it is an agent, including an agent acting for a person, and that is fixed when the review is priced. Campaign shards that match their reviewed pattern pay the fee once per pattern.
• The estimate first. frazer review estimate <pr> (MCP billing_estimate) returns the estimate, and the check row shows it while the review is queued (“est. $0.29 · p90 $0.52 · tokens + $0.05 fee”); the review reserves it, and the receipt gives the tokens by model actually served and the fee. A review that pauses, fails or is canceled before posting bills nothing.

Reviews on public repositories are free.

Every review shows what it cost in its run passport, and the monthly dollar cap pauses reviews before spend surprises you. Models are reached through the LLM gateway, with your organization’s key (the lower seat price) or with Frazer’s.

Frazer Reviewer	On your servers	On the Frazer fleet
seats	$15 per active committer / month · $7.50 with your own model key	Same · agent pull requests take no seat · public repositories free
reviews	100 per paid committer a month, pooled, then $0.20 each · Deep $1, Deep + Preview $3, estimate first	Same, plus agent runtime for a Deep + Preview sandbox on the fleet
agents' pull requests	Model tokens at the gateway's price, or your own key at no fee, plus a fee per review: light $0.01, standard $0.05, deep $0.20, exhaustive $0.50 · security reviews 2× the fee · later loop turns 40 % of the fee · estimate first	Same

Every line, with the estimator: pricing.

Troubleshooting

Symptom	Cause	Fix
A pull request got no review	The policy does not cover the repository, the pull request is a draft, the author is skipped, or it changes generated code only	Read the check run’s conclusion and /frazer config; type /frazer review to review it anyway
“Held · 1 test failing”	A deterministic check failed, so the model passes wait	Fix the failing check; the review runs on the next version
“Paused: monthly cap reached”	The organization’s monthly review cap is used	Raise the cap in Settings › Spend; nothing was half posted
“Paused, fallback is off by policy”	The pinned model is unavailable and fallback is off	Wait for the provider, or allow a fallback model in Settings › Models
A finding is wrong	The evidence did not hold for your code	Reply /frazer wrong <why>; it is dismissed with your reason and becomes a label for its class
A loop stopped with “weakened”	The author removed or loosened a test that a finding guards	Restore the test, or ask the plan’s approver to change it as its own layer
A pull request from a fork has no test results	Forks never run code by default	A maintainer types /frazer run
A finding shows Verified where you expected Reproduced	The sandbox image failed to build, so the finding fell back to the verifier’s trace	Check the reason in the run passport; pin test commands in .frazer/review.yaml
A Block check does not stop a merge	Branch protection does not require Frazer checks	Add Frazer checks to the required checks of the branch

Reference

CLI

Command	What it does
frazer reviewer enable	Turn on automatic review for the repositories that match a pattern, with a depth and triggers.
frazer reviewer review-policies apply -f	Create or change a review policy from a YAML file; --dry-run shows the plan.
frazer review	Review a diff, a directory, a branch or any file as code, security or cold review; the estimate prints first.
frazer review loop	Loop on a target until it is clean, ending with a held-out pass.
frazer review estimate	The estimate of a review before it runs (tokens by model and the fee for an agent's pull request), with its p90, at the price list's version.
frazer reviewer review-rules approve	Approve a rule draft after its backtest.

All of them: CLI reference.

MCP tools

Tool	What it does
reviews_request	Request a review of a diff, a directory or a file, of a kind, the estimate first. Writes become a plan that waits for approval.
reviews_loop	Start a review loop on a target, with its budget and turns. Writes become a plan that waits for approval.
findings_list	List the findings of reviews.
findings_resolve	Resolve a finding with a fix, an answer or a contest with evidence. Writes become a plan that waits for approval.
rules_list	List the review rules that apply, so a coding agent sees them before it opens a pull request.
rules_propose	Propose a rule draft. Writes become a plan that waits for approval.

All of them: MCP tools reference.

Events

Event type	When it is sent
frazer.review.completed.v1	A review finished and was posted to the pull request.

All of them: Events reference.

Related

• Frazer Reviewer product overview
• The planning flow: cold review of plans, and Loops and learned checks
• Decisions: the panel every review draws its members from
• LLM gateway: the models every review uses
• Environments and GitOps: the manifest lane’s GitOps diff
• Devboxes: the image reviews run tests in
• Frazer Agents: the agents that fix findings
• Frazer app: Reviewer findings next to your session