Outside-Diff Findings as Review Comments

Some of Optibot's most valuable findings are not in the code you changed. You rename a status string and the caller three directories away still hardcodes the old one. Optibot reads past the diff to catch these, but GitHub only allows a review comment on a file the pull request actually touches.

So those findings went to the bottom of the review body, in a "findings outside this PR's diff" section. Correct, complete, and easy to scroll past. No thread to reply in, nothing your teammates could resolve.

This release adds an opt-in way to post them as real review comments instead.

New

Post outside-diff findings as comments

A new repository setting under Settings → Reviews changes how these findings are delivered. Turn it on and each one becomes its own review thread rather than a paragraph in the summary.

Anchored to the nearest changed file, honest about where the code is

GitHub will not let a comment sit on an unchanged file, so Optibot anchors each thread to the changed file closest to the finding's real location. Because the file GitHub displays is deliberately not the file the issue is in, every comment opens with a 📍 Actual location line naming the true file and line range.

In practice the thread lands next to related code rather than somewhere arbitrary. A finding in src/stripe/stripe.ts attaches to the payments file you were editing, not to an unrelated README that happened to be in the same commit.

Resolving the thread dismisses the finding

Because these are real threads, they get the reply box and the Resolve conversation button that every other review comment has, and Optibot treats both as a verdict. Resolve the thread, or react 👎 to the comment, and the finding is dismissed: the next review will not raise it again. There is no separate Dismiss link in this mode, because the GitHub control you already reach for does the job.

Details worth knowing

• Committable suggestions are stripped. A code suggestion is applied to the file GitHub thinks the comment is on, which in this mode is the wrong file. Optibot removes suggestion blocks from anchored comments rather than offer a one-click change that would edit the wrong code.
• One thread per finding. Two findings covering the same file and line range share a dismissal, so they are posted once instead of as duplicate threads.
• Nothing is ever lost. If a comment cannot be posted, the finding still appears in the review summary with its Dismiss link intact.
• GitHub only, and off by default. GitLab already posts these findings as separate merge request notes, so the setting is hidden there. Existing repositories keep the review-body section until you turn it on.

Which one should you use?

The body section stays the better fit if you want the review summary to be the single place everything is reported, or if you find extra threads noisy on large PRs. Turn the new setting on if outside-diff findings have been getting scrolled past, or if you want your team to be able to resolve them the same way they resolve every other comment.

Also in this release

A rebuilt Seats tab

Organizations with hundreds of members from GitHub or GitLab but a handful of Optibot seats had no straightforward way to answer "who actually has access?" The member list was unsorted, unfiltered, and ten rows at a time. It has been rebuilt around that question.

• Filter by access with All, Has access and No access segments, each showing a live count for the whole organization.
• Sort and search any column, with search covering name, handle and email across the organization rather than just the page you are on.
• Renamed to "Seats" from "Members & Access", since the page is only about reviewer seats. Existing links still work.
• Clearer actions and labels. Assign seat, Buy seat and Remove seat now say what they do, the provider's own Role column is gone, and low-contrast text across the tab has been fixed.

Fixes

Reviews no longer get stuck behind a stale lock

Optibot holds a lock while reviewing a pull request so that two reviews cannot run at once. In rare cases that lock could be left behind after the review finished, blocking later reviews on the same pull request until it expired. It is now always released.