Reviews
Reviews in the portal
Every pull request inline processes leaves a record. Reviews is where you go back to a review: what it found, and what it held back.
What you see here follows your role. Admins see every pull request in the workspace. Everyone else sees the pull requests they opened, under the title My reviews.
#Finding a review
Reviews
Every pull request the agent has processed, newest first. Open one to see posted findings, suppressed findings, and cost.
| Pull request | Verdict | Findings | Cost | When |
|---|---|---|---|---|
| inline#482Cache review results per head SHA | Substantive | 3 | $•.•• | 2h ago |
| inline#481Bump tedious to 18.6.1 | Trivial | 0 | $•.•• | 5h ago |
| inline#479Rework the merge gate summary | Substantive | 1 | $•.•• | yesterday |
Search narrows the list as you type, matching pull request title, author or number. The Repo and verdict filters cut it down the same way, and With findings drops the pull requests inline had nothing to say about.
A row marked High risk or Med risk has a risk score inline worked out from four things: how large the change is, how severe its findings are, how fragile the touched files are, and how familiar the author is with them.
#Reading the verdict
| Verdict | What happened |
|---|---|
| Substantive | The change warranted a full pass, so inline read the code around it. |
| Trivial | Triage found nothing a deeper read would add, so the pass stopped there. |
| Skipped | Nothing left to review once path filters and already-reviewed commits were taken out. |
| Incomplete | The pass stopped early. Your next push re-reviews the pull request. |
For what leads to each verdict, see How a review works.
#Inside a review
inline#482
Cache review results per head SHA · by rojitha · typescript · 2 Sep
Cost
$•.••
Input tokens
184,220
Cached reads
151,008
Output tokens
6,412
Duration
1m 52s
Summary
Caches the review payload against the head SHA. The invalidation path misses force-pushes that keep the same tree.
A force-push that rewrites history without changing the tree reuses the cached review, so the new commit is never read.
bug · confidence 0.82The cache key omits the severity threshold, so lowering it does not produce a fresh review.
bug · confidence 0.74Suppressed by validation gate (2)
The header links out to the pull request, and to the walkthrough and sandbox tests when the review produced them. The summary is inline's account of the change as a whole, and the findings follow it in severity order.
Once a pull request closes, each finding picks up an outcome: fixed, accepted, dismissed, rejected, ignored, or a note that a later push addressed it. Those outcomes feed the acceptance figures on The dashboard. Findings explains each outcome.
#Findings that were held back
Admins also see a Suppressed by validation gate section. Everything inline raised but chose not to post is kept there, each finding with the reason it was held back.
Reading that section is the quickest way to tell whether your severity threshold is set where you want it. If findings you would have wanted are waiting there, widen what gets posted in Review config.