## Problem Statement When a developer pushes new commits to address feedback from an initial Duo code review and re-requests review, Duo performs a completely fresh review. It leaves new comments, may re-raise findings already addressed, and has no awareness of what it previously said or what has changed since. The trigger exists — the re-request review action already surfaces in the UI — but the behavior it produces is wrong for a follow-up context. This creates a single core problem: **Duo has no concept of a follow-up review.** Every review it performs is treated as a first review. This means: - Prior comments are not checked for resolution. Duo may re-raise the same issues, creating duplicate threads. - There is no distinction between "verify my fixes" and "review everything new." The author has no way to communicate their intent, and Duo makes no attempt to infer it. - Existing open threads from the prior review are left untouched regardless of whether the underlying code changed. The result is a poor experience for authors who have genuinely addressed feedback and expect a targeted, context-aware second pass rather than a fresh flood of potentially redundant comments. ## Proposal ### 1. Detecting a follow-up review Two existing surfaces signal that a follow-up review is being requested, and Duo should treat both as triggers for context-aware follow-up behavior rather than a fresh first-pass review: - **Re-request review action** — the existing UI button already triggers Duo. The change needed is in what Duo does with that signal: instead of starting a new review from scratch, it should detect that a prior Duo review exists for this MR and enter follow-up mode. - **Comment-to-agent** — mentioning `@GitLabDuo` in the MR thread with intent to trigger a review (e.g. "please verify my changes" or "do a full review"). This ties to the intent service ([&21555](https://gitlab.com/groups/gitlab-org/-/work_items/21555)), which parses the comment and routes to the appropriate flow — verification mode or full re-review — based on what the author is asking for. The work here is not building new triggers — it is making Duo aware of its own review history so it can respond appropriately when those triggers fire. ### 2. Agent-determined review scope Once a follow-up review is triggered, Duo should inspect the diff between the last-reviewed commit SHA and the current HEAD to determine the appropriate review mode, rather than always defaulting to one or the other. **Verification mode** (default): Checks whether Duo's own prior review comments have been addressed. Surfaces a structured summary of which of Duo's comments appear resolved, which appear partially addressed, and which remain open. Does not re-review the entire PR from scratch, and does not attempt to evaluate the status of human reviewer threads — that judgment requires the context and expertise of the reviewer who left the feedback. This is the right mode when the new commits are narrow in scope and clearly responsive to Duo's prior feedback. **Full re-review mode**: Treats the changes since the last review as a new diff requiring fresh analysis. Appropriate when the scope of changes goes significantly beyond what was flagged. Duo should escalate to this mode automatically based on heuristics (see below), and authors should also be able to request it explicitly. ### 3. Automatic escalation heuristics Duo should escalate from verification mode to full re-review mode when one or more of the following conditions hold: - **Net-new files or entry points** are included in the diff since the last review. These were never reviewed and cannot be interpreted as responses to prior feedback. - **Diff volume significantly exceeds what was flagged.** If the new commits touch substantially more lines than were commented on — a rough proxy being the ratio of new diff size to prior comment surface area — it's likely the author has made broader changes that warrant fresh analysis. - **Changes occur outside flagged locations.** If new commits modify functions, files, or sections that weren't mentioned in any prior comment, those changes fall outside the scope of verification and need to be reviewed. These heuristics should be tunable over time as we gather signal on false positives. The author should always be able to override the inferred mode explicitly via `@GitLabDuo`, with the intent service determining the appropriate flow from natural language. ### 4. Thread resolution When Duo determines in verification mode that one of its prior comments has been adequately addressed, it should resolve that thread. This mirrors what a first-level human reviewer would do — if the fix is clear and the concern is closed, there's no reason to leave the thread open. Where Duo is uncertain whether the feedback was fully addressed, it should leave the thread open and note what's still ambiguous. Duo should not resolve threads it did not author. ## What's Out of Scope - Push-based automatic re-review triggering (intentionally excluded; see problem statement) - Cross-MR history and pattern learning (follow-on work; Duo should focus on the current MR's review history first) ## Success Criteria - When a developer re-requests review after addressing feedback, Duo does not repeat comments that appear resolved and does not treat the review as a first pass. - In the default case (focused fixups), the follow-up review does not re-raise comments that were already surfaced and appear addressed. - When an author has made substantial net-new changes, Duo either automatically escalates to a full re-review or clearly communicates that the changes exceed the scope of a verification pass. - Developers can explicitly control review scope when the automatic determination is wrong. ## Open Questions - Should the re-request review action trigger Duo by default, or should it be opt-in per MR or per project? - How do we define the last-reviewed commit SHA — the commit at the time of the first Duo review, or the most recent commit at the time of any prior Duo comment? - What's the right escalation threshold for diff volume? This likely needs data from early rollout to calibrate. - Verification scope is intentionally limited to Duo's own prior comments. Validating whether human reviewer feedback was adequately addressed requires the domain context of the reviewer who left it, which Duo does not have. Human thread resolution remains the responsibility of human reviewers.