kReview

The problem

"AI finds bugs" is the least interesting claimand the most marketed (and the most marketed) a review bot can make. The interesting questions are operational: what happens when the diff is too big for the context windowthe text a model can consider in one request (the text a model can consider in one request), when a new push lands mid-review, or when the model only skimmed half the files? Most bots answer by pretending the problem does not exist. kReview answers in the review itself.

Architecture

kReview receives Forgejo webhooks (HMAC-verifieda keyed hash that authenticates a message (a keyed hash that authenticates a message) against the raw body), runs one or more model adapters, and maintains a single sticky review comment per pull request. Adapters cover the Codex and Claude Code CLIs, OpenCode, OpenRouter, and a generic JSON-over-stdin command; a multi-reviewer mode runs several concurrently and synthesizes their findings, falling back to a deterministic merge when synthesis fails.

Large diffs are the normal case, not the exception. Generated and vendoredthird-party code copied into the repository (third-party code copied into the repository) content is filtered out first; what remains is chunked under an estimated token budget (120k input tokens per chunk, up to 50 chunks, 4 in flight), with files split at unified-diff hunk boundariesseparate change blocks in a patch (separate change blocks in a patch) and a single oversized hunk divided into synthetic smaller ones rather than dropping the file. Chunk results are merged, deduplicated, and reranked into one report.

The honesty features are the point. Coverage state distinguishes fully reviewed, partially reviewed, deliberately excluded, and not reviewed files, and the posted comment says which is which. When a newer head arrives mid-review, the running model process is aborted immediately - the signal propagates through API calls, provider processes, and publishing - and the latest head takes its place. Bursts for the same PR collapse to the newest push; re-reviews receive previous findings so fixed issues disappear and surviving ones keep their identity. An adaptive router escalates to deep review (multi-reviewer, repository context, an independent verification pass) based on measurable facts like changed-file count and high-risk paths, never on untrusted PR prose - and in those modes, findings publish only when their quoted evidence can be anchored to the actual diff.

kReview identifies every response with a request ID and drains gracefully on shutdown. Health and readiness endpoints plus token-protected Prometheusa metrics system that scrapes and stores time-series data (a metrics system that scrapes and stores time-series data) metrics expose its state. Deployment is a single binary or hardened container.

Boundaries

kReview comments; humans merge. It has no authority over branches and no opinion it can enforce.

Everything a PR contains is treated as untrusted prompt data: content is fenced, adapters run hardened (read-only sandboxes, tools disabled, user configuration ignored), and provider output is size-capped before parsing. The optional repository context is read-only bare mirrorsrepositories containing Git data without a working tree (repositories containing Git data without a working tree) of the base branch only - PR-head files are never indexed, and repository code is read but never executed. Optional statistics store route, coverage, token, and cost metadata; deliberately never prompts, diffs, or secrets. Its findings are bounded by what its models saw, which is exactly why it reports coverage instead of implying completeness - an unreviewed file marked as unreviewed is useful; the same file silently skipped is a trapwe have all met that bot (we have all met that bot).