Review output and severities

A finished review is a flat list of issues. Each issue (sometimes called a finding) carries the same fixed set of fields, so the results view always has the same data to draw from no matter which lens produced it. This page documents that data model: the severity levels, the categories, the fields on a single issue, and the built-in profiles that decide which lenses run.

If you want to know how issues get produced in the first place, read the review pipeline. This page is about what comes out the other end.

Every issue has exactly one severity. There are five, listed here from most to least severe:

Internally, severities are ranked by their position in that order, and the rank counts up as severity goes down. Blocker ranks lowest, nit ranks highest, so "lower rank means more severe." That rule drives the severity filter in the results list and the sort order of the issue list, where blockers float to the top.

The terminal UI colors each severity differently, and the exact color depends on the active theme. Blocker is red, high is orange, medium is yellow or amber, low is blue, and nit is a muted gray. The high-contrast palette keeps the same hue assignments but brightens them. Treat the hue as a quick severity cue, not a precise value; the palettes pick theme-appropriate shades rather than one fixed code per level.

Each issue is also tagged with one category, describing what kind of problem it is. There are seven:

A single issue follows a fixed shape. The results view spreads these across a few tabs, but the underlying record is one object:

Patch and Trace tabs follow the same binary rule. The results view includes Patch exactly when suggested_patch contains a patch, and includes Trace exactly when trace contains at least one step. A null patch, a missing trace, and an empty trace omit their respective tabs. For how each renders, see reading results.

Evidence references

Every evidence item keeps its title, source identifier, and excerpt in saved reviews. The web and terminal result views render all four supported types:

code evidence is always extracted from the diff the review ran on and listed first, so an excerpt shown as code is the reviewed source rather than text the model wrote. Provider-supplied references of the other three types are kept as given.

A profile is a named preset that picks which lenses run and, optionally, a minimum severity to keep. Four ship built in:

quick is the fast path: it runs only the correctness lens and drops anything below high severity, so you see blockers and high-severity issues and nothing else. strict is the broad pass across correctness, security, and tests, but it still respects the configured severityThreshold. perf pairs the performance lens with a correctness baseline and hides anything below medium. security leads with the security lens, backed by correctness, and also respects the configured threshold.

The configured severityThreshold is always a floor. A profile minimum can tighten that floor, but it cannot relax it. To keep the full range down to nit, set severityThreshold to nit; profiles without their own minimum, such as strict and security, then inherit that wider range.

• Reading results shows how these fields render across the issue tabs.
• The review pipeline explains how issues get produced.
• Reference: providers covers the models that generate them.
• Reference: environment variables lists the variables Diffgazer reads.