Inline findings
Inline findings are Qodex review comments attached to specific changed lines in a pull request.
They are meant to be actionable. Each one explains what looks risky, why it matters, how confident Qodex is, and what the author can do next.
How inline findings work
Each finding names a file path and line number. If that line is part of the PR diff, Qodex posts the finding as an inline review comment. If the line is outside the diff, Qodex moves the finding into the walkthrough body because GitHub rejects inline comments outside changed lines.
An inline comment can include:
- Severity and category.
- A confidence-filtered explanation.
- A suggested change when Qodex can safely anchor one.
- A verification badge when Qodex checked the finding against a preview deployment.
- A collapsible evidence block when a probe ran.
Severity model
Severity describes the impact if the issue ships. It is separate from confidence.
| Severity | Meaning |
|---|
| Critical | Data loss, security breach, crash on common path, broken auth, irreversible state corruption. |
| Major | Wrong behavior under realistic conditions, user-visible performance regression, or an edge case the team would page on. |
| Minor | Real correctness issue that is unlikely to surface often. |
| Nitpick | Style or naming. Disabled by default; Qodex is instructed not to return these. |
| Info | Helpful context with no required action. |
Confidence floor
Every finding carries a confidence score between 0.7 and 1.0. Anything below 0.7 is dropped before it reaches the PR.
The confidence floor runs before the .qodex.yaml severity_threshold and before paths.exclude, so low-confidence comments never appear just because they match repo policy.
When a first high-precision pass produces no findings on a non-trivial diff, Qodex can run one deeper escalation pass. Findings from that pass still go through severity, path, and disabled-rule filters before they are shown.
Consistency checks
Qodex compares sibling code shapes inside the diff. If a PR introduces similar branches, guards, filters, metrics, or return objects, Qodex checks whether one of them is missing a predicate, null check, returned key, or other contract that its siblings keep.
This catches issues that look reasonable line by line but become suspicious when compared with the parallel cases around them.
Categories
| Category | What it covers |
|---|
bug | Wrong behavior under realistic inputs. |
security | Auth, injection, SSRF, secrets, headers, sensitive data exposure. |
performance | Visible regressions, accidental quadratic loops, N+1 queries. |
maintainability | Dead code, duplication, dangerous patterns the next person may misread. |
style | Naming, formatting, conventions. Disabled by default through nitpick severity. |
Critical **Missing auth check on profile read** - _security_ - Verified
The handler reads the user ID from `req.params.id` and queries the
profile row without comparing it to the session user. Any logged-in
user can read any other user's profile by changing the URL.
```suggestion
const id = req.params.id;
if (id !== req.session.userId) return res.status(403).end();
const profile = await db.profiles.findUnique({ where: { id } });
```
<details><summary>Probe evidence</summary>
**Request** `GET https://pr-42.preview.acme.app/api/profile/9999`
**Response** `200 OK` in 142ms
~~~
{"id":"9999","email":"victim@example.com",...}
~~~
**Verdict** response status 200 matched expected 200
</details>
Suggestion blocks
When Qodex provides a suggested_change, it wraps it in a GitHub suggestion block so the author can apply it from the PR UI.
The suggestion must be a literal replacement for the cited line, not a diff. Multi-line replacements are allowed.
Qodex only renders a suggestion when the anchor looks safe. If the cited line is a comment, blank line, import, or brace-only line, the suggestion is stripped so GitHub does not offer to replace the wrong code.
Anchor uncertain badge
Before posting an inline comment, Qodex checks the actual source text at the cited line. If the line is clearly non-code, the comment gets an Anchor uncertain badge and the suggestion block is removed.
The finding still posts because the explanation may be useful, but the author should treat the exact line anchor as advisory.
Probe badges
When Qodex runs a verification probe, the inline heading can include one of these badges:
Verified: the response matched the expected signal, so the finding is reproducible on the preview deployment.Unverified by probe: the probe ran, but the response did not match the expected signal.Probe failed: Qodex could not reach the preview because of DNS, timeout, refused origin, or another execution error.
Findings without a probe spec, or PRs without a discovered preview deployment, render without a probe badge.
On the roadmap
Slash-command resolution per finding is on the roadmap. A reviewer will be able to comment @qodex resolve <id> or @qodex false-positive <id> on an inline finding to close it out and train the per-project filter.
