The review pipeline

Every review is one trip through the same pipeline. A webhook enqueues a job; the worker claims it; the pipeline loads the PR, decides how much to spend, runs the review, filters the output, and posts. This page walks the whole path in order.

# The shape of it

GitHub PR opened / updated
   │  signed webhook (verified)
   ▼
inline webhook endpoint ──► review job queued
                              │  picked up by the worker
                              ▼
   ┌─ the review pipeline ──────────────────────────────────────┐
   │ 1. guard / skip checks (repo enabled? PR open? head fresh?) │
   │ 2. incremental base (diff only since last reviewed head)    │
   │ 3. path filters + diff compression                          │
   │ 4. project-type detection → guideline pack                  │
   │ 5. triage — a fast model (trivial vs substantive)           │
   │ 6. budget gate                                              │
   │ 7. deep review — a frontier model, agentic loop             │
   │ 8. validation gate (confidence, severity, dedup, anchoring) │
   │ 9. post GitHub review: summary + inline comments            │
   │ 10. persist review + findings + cost, absorb repo memory    │
   └────────────────────────────────────────────────────────────┘

The webhook path does almost nothing — it verifies the signature and queues a job. GitHub gives webhooks only a few seconds to respond, so all model work happens later in the worker. Reviewable PR actions are opened, synchronize, ready for review, and reopened; drafts are skipped; a closed PR triggers the feedback harvest.

# 1. Guards and skips

Before spending anything, the pipeline bails early when there’s nothing to do:

• Repo disabled — no review.
• PR no longer open, or the head moved since the job was queued — skip as stale (a newer push already queued a fresher job).
• Bot authors (e.g. Dependabot) — skip the review, but still sync the merge gate so a required check never gets stuck.

# 2. Incremental base

inline reviews only what’s new. It finds the last completed review for this PR and uses that review’s head as the comparison base, so a third push reviews only the third push’s changes — deduped against everything already flagged.

Commenting @inline full review on the PR forces a full re-review from scratch. A force-push that breaks the compare API falls back to a full diff automatically.

# 3. Path filters and diff compression

Two cost levers run here before a single token reaches a model:

• Path filters drop files that never deserve a review — lockfiles, build output, dependencies, generated code, minified JS, migrations, snapshots, images, fixtures. This is the cheapest lever: filtered files cost nothing. Defaults are combined with per-repo and per-workspace globs you set in review config.
• Diff compression ranks the surviving files by change volume, de-prioritizes enormous files, and clips the diff sent to the model. Anything omitted is noted so the review agent can pull it in later with its file-reading tools.

See Cost & two-tier models for the full lever list.

# 4. Project-type detection

inline detects whether the PR is TypeScript, React, React Native, C#, and so on, and selects the matching guideline pack — a language-specific set of review rules folded into the review.

# 5. Triage — a fast model

The first model call is cheap on purpose. A fast model reads the diff and returns a structured verdict:

{ "verdict": "substantive", "summary": "...", "riskAreas": ["auth", "db"] }

• trivial — no deep review. inline records the verdict, notes a low-risk line on the walkthrough, syncs the gate, and stops. This is where most of the cost savings come from.
• substantive — proceed to the deep review. When in doubt, triage chooses substantive.

# 6. The budget gate

Between triage and the expensive deep review, inline checks the workspace’s monthly budget. At 80% of the cap it fires a one-time alert. Past the cap, if budget-degrade is on, it stops at triage and records the review as incomplete — which excludes it from the incremental base, so the PR gets a real review next month instead of being silently skipped.

# 7. Deep review — a frontier model

The substantive review is an agentic loop on a frontier model. The model doesn’t just see a diff — it can act:

The loop is bounded by a step ceiling and a per-turn output cap. The explorer subagents run on a fast model at a fraction of the deep model’s price, carrying the token-heavy breadth work while the frontier model does the judgment. If the loop hits the step ceiling without submitting a review, the review is recorded incomplete and the incremental base is held so nothing is lost.

The model is told, emphatically, that a review with no findings is a success — never comment on style, formatting, naming, docs, or coverage, and refute your own finding before flagging it.

# 8. The validation gate

Everything the model submits passes through a validation gate before anything is posted. Findings are suppressed (never dropped — they’re stored with a reason and visible in the portal) when they are low-confidence, below the repo’s severity threshold, duplicates, un-anchorable to the diff, or beyond the comment cap. This is the machinery that keeps inline quiet — it has its own page: Noise control.

# 9. Post

inline posts a single GitHub review: a summary comment (the walkthrough sticky comment, finalized here) plus inline comments anchored to changed lines. If GitHub rejects the inline anchors, it falls back to a body-only review so the findings still land.

# 10. Persist and learn

Finally the pipeline records the review and its findings with full cost accounting, reopens any re-confirmed findings, auto-resolves threads for findings that are now addressed, syncs the merge gate, optionally enqueues a walkthrough page, sandbox tests, or an auto-fix PR — and folds this review’s summary and findings into the repo’s memory with a cheap model call.

# The worker

Jobs are drained by an in-process worker. It claims jobs atomically, serializes work per-PR so two jobs on the same PR never double-post, dispatches each job to the right handler by type, and continuously recovers stale jobs. Failed jobs retry with exponential backoff up to a bounded attempt count.