Reviews
Findings
A finding is one point inline raises about one place in your code. Every finding has a severity, a category, and the evidence behind it.
Anyone whose pull requests get reviewed reads findings. Admins also see the findings inline held back.
#What a finding tells you
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)
Every finding names the file and line it applies to, says what inline found there, and gives the reasoning that led to it. On the pull request it arrives as a comment on that exact line.
| Severity | What it means |
|---|---|
| High | Something that will bite. A bug, a security hole, data loss. |
| Medium | Worth fixing before merge, but the change works. |
| Low | A small improvement inline would make if it were writing the code. |
Severity is what the merge gate reads when it decides whether a finding can hold a merge.
#Categories
Alongside severity, every finding has a category, so you can tell at a glance whether inline is talking about correctness or about style.
| Category | What it means |
|---|---|
| bug | The code does something other than what it means to. |
| security | An exposure someone could use. |
| performance | Work the code does that it does not need to. |
| maintainability | Something that will make the next change harder. |
| style | A convention, including the ones you have taught it. |
| intent | A gap between the change and the Linear or Jira ticket it names: something the ticket asks for that the pull request does not do, or a change the ticket does not ask for. It never holds the merge gate. |
#Acting on a finding
Findings arrive as an ordinary GitHub review, so you already know how to handle them. Fix it and push, reply to argue with it, or resolve the thread if it does not apply.
Resolving is the signal inline reads. When the pull request closes, inline records how each finding ended up: fixed, accepted, dismissed, rejected, ignored, or addressed by a later push. Those outcomes drive the acceptance figures on The dashboard, and a pattern of dismissals becomes a proposed rule in Learnings.
#Findings inline held back
inline raises more than it posts. Before anything reaches your pull request it runs a validation gate, and a finding that does not clear it is stored with the reason instead of being posted.
| Reason | What happened |
|---|---|
| Below your severity threshold | Real, but quieter than the level you asked for. |
| Low confidence | inline was not sure enough to say it out loud. |
| Duplicate | The same point was already made on this pull request. |
| Comment cap | The pull request had already reached the posting limit. |
| Unanchored | The line it applies to is not part of this diff. |
Admins read the whole set under Suppressed by validation gate on the review. It is the fastest way to tell whether your severity threshold is where you want it, and Review config is where you move it.
#Letting inline fix it
Where a repository has auto-fix on, inline offers to write the fix itself, verify it, and open a separate pull request with it. See Auto-fix pull requests.