The PR analysis view

Click any pull request in the list and you land on its analysis view — everything Firetrail found about this change, on one page. Here's a tour, in the order you'd naturally read it.

The score and its breakdown (left side)

The Future Debug Cost card shows the 0–100 score, its band, and a one-line plain-language summary of the change (something like "This change carries some structural risk worth a look").

Below it, the score breakdown lists every risk driver — each finding that added (or subtracted) points, with its point value. The drivers sum to the score, so nothing about the number is a mystery. This list is the most useful thing on the page: it's your pre-review checklist, telling you exactly where the risk is concentrated before you read a single line of the diff. Future Debug Cost explains how to act on each band.

The patch coverage card sits here too: an estimate of how much of the PR's new code is exercised by its tests, with a prominent warning when a production-code change ships with no tests at all.

Said vs. did

If the diff quietly does something the PR's description never mentioned, you'll see it here. Firetrail compares the PR's stated intent — its title and description — against what the analysis actually detected, and sorts the change into three buckets:

• Claimed and delivered — what the description promised and the diff confirms. This is the happy bucket.
• Delivered but not described — behavior that shipped without being mentioned. This is the dangerous bucket: a future maintainer reading the PR page will never know these decisions were made. When an undisclosed change touches something with a wide blast radius — configuration or dependencies — the page shows a loud undisclosed high-blast-radius warning.
• Claimed but not detected — things the description promised that the analysis couldn't find. Sometimes a stale description; occasionally a forgotten TODO.

The fix for a scary "said vs. did" result is usually cheap: update the PR description so it tells the truth. Future-you will be grateful.

The review team

On paid plans, the review team section shows a card for each AI reviewer with their verdict (✅ yes, 🤔 meh, ❌ no, or ➖ not applicable). Click a card to open the full review: the reviewer's overall take, their satisfaction and confidence, and their specific findings sorted by severity, each pointing at the files that triggered it. A line under the team says how their verdicts relate to the score — the reviewers rate the code as written, the score rates how the change is packaged — so a happy team next to a high score reads as what it is, not as a contradiction.

The Code review tab lists the same findings from every reviewer in one place, most serious first: who raised each one, what the issue is, why it matters, what happens if it isn't fixed, a possible solution, and the files involved. It is the fastest way to turn the team's review into a to-do list.

Check results and evidence

The classifier results table lists every check that ran: its verdict, risk level, and confidence. Checks that didn't clear the confidence bar are shown here too — visible, but excluded from the score. On Free and Starter plans, checks that require Pro appear as locked rows so you can see what a full analysis would include.

Expand a row to read the finding the way Firetrail coaches it: the cause (what in this diff creates the risk), the consequence (what breaks later if it ships as-is), and the solution (the one action that removes it) — followed by the file evidence and the reasons it might be a false positive. The same three lines appear under "What to watch" in the GitHub comment.

Evidence by file flips the view around: each changed file, with the checks that flagged it. When a reviewer or a driver points at "the risky part", this is where you see exactly which files that means.

Risky history

If this PR edits code that a past bugfix traced back to — code that has already bitten your team once — a callout appears at the top of the page linking to those earlier bugfix PRs. It's Firetrail saying: be a little more careful here; this exact area has caused pain before. The connection comes from origin tracing.

Re-running

• ↻ Re-run analysis — fetches the latest commit and produces a fresh result. Use it after pushing commits, or to refresh a PR analyzed before a feature (like the review team) was available on your plan.
• ⚡ Turbo Analysis — for very large PRs that were analyzed partially, this re-runs the whole pipeline on a model that can read the entire diff in one pass. Your plan includes a monthly allowance per seat.