Reading results

Once a review finishes, the web environment drops you on a summary screen and then into a two-pane results view where you read each issue in detail. This page is for the part that comes after the run completes: making sense of what the review found and deciding what to act on. It assumes you have already started a review, so if you have not, see reviewing in the web environment first.

The summary is the first thing you see when a review completes. It opens with a single line: how many issues turned up and how many files contain those issues. If anything came back at blocker severity, that count is called out separately in red so you do not miss it.

Below that are two panels side by side. The first is a severity breakdown, so you can tell at a glance whether you are looking at a handful of nits or a wall of blockers. The second groups the issues by category: correctness, security, performance, and so on. Under the panels, the summary previews the top three issues so you have something concrete before you commit to reading the full list. If a model's answer came back incomplete, the review keeps the findings it could validate and says so: the headline reads "Review Partially Complete" and the per-lens list shows how many candidate findings were dropped.

A review that finishes with nothing to report — every lens reported in full, no findings — shows a different summary. In place of the panels and the preview you get a single verdict line — "Passed — no issues found", or "No issues at or above" the minimum severity you set, when the run did filter findings out below it — followed by the run receipt: the scope that was read, the lenses that read it, the model that answered, how long the run took, and the run's own id and timestamp. Any notices the run collected sit under the receipt. There is no issue list to open, so this screen is the whole result. The terminal UI draws the same receipt for a clean run.

When you are ready, view results from the summary to open the full results. The summary is a snapshot; the two-pane view is where the actual reading happens.

The results screen splits into two panes. The left pane is the list of every issue in the review, with multi-select severity chips at the top. When one or more chips are selected, results include exactly those severities and exclude every unselected severity. High by itself does not include Blocker, so select Blocker explicitly when you want to see it. Reset clears the selection and shows every severity again. Pick an issue in the list and its full detail loads in the right pane, which takes up most of the width.

The list and the chips work together. If none of the issues has a selected severity, the details pane tells you no issues match and suggests choosing another severity. If the review itself came back clean with no issues at all, the pane says so rather than leaving you staring at a blank panel.

Each issue carries a fixed shape, so the detail pane always has the same fields to draw from. The model behind a single issue includes its severity and category, a title, the file and line range it points at, the reasoning behind it, a recommendation, a confidence score, and optional extras like a fix plan, a suggested patch, evidence excerpts, and a tool trace. You do not need to memorize that list. The pane lays it out for you across a few tabs. For the full field-by-field breakdown and what every severity level means, see review output.

The top of the detail pane shows the issue title, colored by its severity, with the exact file:start-end range underneath. Category and rounded confidence are shown beside that location, so the same metadata is visible whether you open a live result or a saved review. Below the header are tabs: Details and Explain are always present, while Trace and Patch appear only when the review contains their data.

The Details tab is the main read. It walks through the symptom (what is wrong), why it matters, and, when the review supplied them, a fix plan, better alternatives, and tests worth adding. When the issue includes a code excerpt as evidence, it renders inline so you can see the offending lines in place rather than jumping to the file yourself.

The fix plan inside the Details tab is an interactive checklist, not a static list. Every row preserves the review's step number and action, plus its risk and affected files when supplied. You can tick a step as you work through it, and completed steps get struck through. It is a scratchpad for tracking your own progress against the suggested fix; nothing is written back to your code.

The Explain tab is the shorter read: the rationale for the issue followed by the recommendation, in prose. Reach for it when you want the reasoning without the full breakdown.

The Trace tab shows the steps the agent took to reach the issue, each one naming the tool it used and a short summary of what came back. It only shows up when the review supplied at least one agent step; an issue without trace data has no Trace tab at all.

The Patch tab only shows up when the review actually generated a suggested fix for that issue. When the patch is a clean single-file diff, it renders as a proper diff view with the change in context. If the patch does not parse that way, it falls back to a plain code block with added and removed lines marked, so the suggestion is always readable either way.

• Reviewing in the web environment covers starting a review and watching it run.
• Review history lists past reviews so you can reopen results later.
• Review output documents the full issue data model and the severity levels.
• The review pipeline explains how these issues get produced in the first place.