A result belongs to the code that was examined
A pull-request number is a stable conversation identifier. It is not a complete description of the code being proposed. The author can push another commit, update the branch, or change the target. Meanwhile, other changes can land in the destination branch. A review written earlier must be interpreted against the comparison it actually examined.
This distinction matters for both people and tools. A finding that was correct yesterday may refer to removed code today. A clean result may predate a new failure path. Keeping the old result is useful for history, but presenting it as current can lead a reviewer to approve code that the result never covered.
The head is only one part of the comparison
Consider a feature branch that calls a helper from its target branch. Another change alters that helper before the feature merges. The feature's own head commit may be unchanged, yet the behavior of the eventual combination deserves another look. Similarly, retargeting a change from a development branch to a release branch changes the assumptions around it.
GitHub's protected-branch documentation describes controls for stale approvals when relevant changes affect the reviewed diff. The exact policy depends on repository configuration. The general lesson is straightforward: current approval and historical approval answer different questions, and the repository should make that difference visible.
Read stale findings as historical evidence
When a tool marks a review stale, do not immediately erase the old findings or assume the original concern disappeared. Inspect whether the issue was fixed, moved, or remains in the new code. The prior review can guide the investigation even though it no longer establishes coverage of the current revision.
AntiCode tracks the reviewed head commit, base commit, and target branch. After syncing a changed comparison, the workspace can show that a new review is needed. This is an explicit request to re-evaluate the code, not a claim that the change is broken. Freshness and defect severity are different dimensions.
Handle changes that arrive during a review
A review takes time. The author may push another commit after analysis starts but before it finishes. A result should not be silently attached to whichever version happens to be current when the response arrives. The review system needs to confirm that its result still describes the intended comparison.
AntiCode checks revision identity around a managed review and rejects a result when the pull request changes during the run. A failed or incomplete attempt preserves prior successful results. Read the error and the revision status together: preserved results are history, not evidence that the interrupted run succeeded.
- Sync before starting a review of recently changed code.
- Confirm the intended pull request and target branch.
- If the comparison changes during review, sync and run again.
- Check the final revision before using the result in a merge decision.
Make freshness part of the handoff
When handing a change to another reviewer, identify the revision you examined and what changed afterward. A short note such as a description of the follow-up patch is more useful than saying everything was reviewed. If a later edit affects the original reasoning, reopen that discussion explicitly.
Keep repository enforcement separate from review-tool status. AntiCode's current manual review results do not create a GitHub merge gate. Configure your repository's approval rules independently and verify their behavior. The aim is for every final decision to have a clear answer to one question: which version of this change did we actually evaluate?
Further reading
Put it into practice
Start with a small change you are authorized to review. Follow the AntiCode setup guide, inspect each finding, and keep your tests and human approval in the loop.