investigate: frontload Copilot review by requesting multiple passes before responding

[microsasa]

Hypothesis

Copilot code review drip-feeds ~2 comments per pass. If we request review 3 times before dispatching the responder, we might surface ~6-10 comments upfront. The responder could then fix them all in one shot instead of burning 3 attempts across 3 push-review cycles.

Community reports (GitHub Discussion #152385) confirm that re-requesting review surfaces comments on different files each time, even without a code change. This suggests Copilot's internal selection is non-deterministic and re-rolls each request.

What Needs Testing

Run a controlled experiment on a real PR:

1. Open a PR with ~5-10 changed files
2. Request Copilot code review → record comments (count, files, content)
3. Wait for review to complete
4. Re-request review (no push) → record NEW comments
5. Wait for review to complete
6. Re-request a third time → record NEW comments
7. Analyze:
   • Do comments accumulate or duplicate?
   • Does Copilot respect "already reviewed this unchanged code"?
   • What's the total unique comment count across 3 passes?
   • Are later passes higher or lower quality?

Open Questions

• Cost: Each review costs a premium request. 3x reviews per PR triples review cost. Is the tradeoff worth it?
• Deduplication: Does Copilot post the same comment twice if you re-request? Or does it skip already-posted comments?
• Timing: How long between requests? Does Copilot need to fully complete before re-requesting?
• Diminishing returns: If pass 1 gives 2 comments and pass 2 gives 2, does pass 3 give 0?
• API mechanism: Can we programmatically request re-review via the GitHub API, or does it require the UI?

Implementation (if experiment succeeds)

The orchestrator would change from:

PR opened → wait for review → dispatch responder

To:

PR opened → request review → wait → re-request → wait → re-request → wait → dispatch responder (with all accumulated comments)

This could be implemented as a pre-responder step in the orchestrator, or as a separate "review accumulator" workflow.

Related

• fix-forward: reduce drip-feed review rounds for implementer and responder #520 — Copilot drip-feed investigation (parent issue)
• orchestrator: severity-aware dispatch — stop re-dispatching responder for nits #782 — Orchestrator severity-aware dispatch (complementary optimization)
• GitHub Community Discussion #152385 — re-requesting surfaces different comments
• GitHub Community Discussion #189767 — drip-feed across multiple rounds