Follow-up reviews
After new commits, a follow-up review checks which findings were fixed and looks at what changed.
On this page
When a pull request was reviewed before, the next review does two jobs. It reviews what changed, and it checks each earlier finding against the code as it is now. You see, finding by finding, what was fixed, what is still open and why. Nothing is raised twice as if it were new.
The earlier findings are in the tab's one Findings list. Still-open ones are under Open, with the new findings, because they count towards the verdict. The rest are under Resolved or addressed. Each row says who raised it and, under it, what this review found.
#What is followed up
The follow-up reads the latest finished review of the pull request and takes its findings that:
- were posted to GitHub, whatever happened to them since; or
- are not posted yet and you have not ignored.
A finding you ignored, one already settled by an accepted reply, and a repeat of a comment already on GitHub are left out. The Findings list says so in one line under Open, for example "Left out: 1 ignored, 4 repeated posted comments."
When the author of the pull request reviewed it with their own Limn and posted that review, your follow-up checks the author's points too, and does not post them again. A teammate's review is followed up while their Request changes still stands on GitHub. See Reviewing as a team.
#The outcomes
Open
The retry path still calls send_receipt() a second time.
Resolved or addressed
allows() now rejects orders paid more than 30 days ago.
| Outcome | What it means |
|---|---|
| Addressed | The code now deals with it. |
| Partly addressed | Some of it is done. It is raised again, linked to the original. |
| Not addressed | Nothing changed for it. It is raised again, linked to the original. |
| No longer applies | The code it was about is gone or changed so much that the point no longer fits. |
| Reply accepted | Someone replied on the thread and the reply settles it. |
| Fix later | The reply says it will be fixed in later work, and that is reasonable. A blocker is never deferred. |
| Pushed back | Someone replied, but the point still stands. |
| Not checked | This review did not get to it. It is carried to the next review. |
Limn never invents "addressed". On the same commit, an outcome cannot change: only new commits change a judgement. A partly addressed, not addressed or pushed-back finding is raised again in the new review, marked Raised in the previous review, so you can post it again or fix it.
#The one-line how
Every outcome carries one short line in bold on the finding's row. For an addressed finding it says how it was dealt with. For a finding that is not, or only partly, addressed, it names the one thing still needed. For an accepted reply, it says why the reply settles it. The same line appears on the thread's card elsewhere in Limn, and in the reply Limn posts when it resolves a thread for you.
#Findings on the whole pull request
Some findings cannot be placed on a line, so they are posted as a comment on the pull request rather than as a thread. GitHub does not thread such comments, so the follow-up reads the pull request's conversation after the comment. An answer that links or quotes the finding counts as a reply to it. The same outcomes apply.
#The other model's findings
When a review runs on one model only, it also checks the other model's findings that are still open, for example when Codex has reached its usage limit and Claude reviews alone. Such a finding says Raised by Codex · checked by Claude. The checking model may find it fixed, but it never argues with it. See Claude and Codex together.
#Closing fixed threads
refunds/policy.py:12ResolvedAddressed in 4f1c2ab: allows() now rejects orders paid more than 30 days ago. Resolved by Limn’s Claude review.
On your own pull requests, Resolve my Limn threads when addressed (on by default) replies "Addressed in" and the commit, with the one-line how, then resolves the thread. It acts after any review you run, and only on your own Limn's findings. On other people's pull requests, Limn does the same after automatic reviews while posting is on (always, with no setting). Limn never resolves a teammate's or a person's thread. See Settings → AI review.
#When a point is still open
If a posted review finds an earlier point still open, it says where, on GitHub, so the author can act: one Still open: reply on the thread per commit. A thread that was resolved without a fix is reopened once, ever. If it is resolved again, a warning or blocker gets one new thread that links the old one; a nit, a question or a person's comment is left alone.
Warning: RefundPolicy.allows() never reads paid_at.