Define two separate records
A resolved discussion is not the same record as a merge decision. This article proposes two tracks: an interaction track for Copilot comments and suggestions, and an acceptance track for the reviewed branch, human judgment, rationale, and disposition. The rule is repository-authored: a merge decision must rely on recorded branch evidence and an independent human decision, rather than on the state of a Copilot conversation.
Copilot normally produces a comment-style review, and that default does not satisfy required approval counts.
The supplied GitHub guidance is treated here as related material, not as separate corroboration. This design excludes preview-only capabilities and is limited to the supplied excerpts and Python 3.14-series language documentation.
Use a repository decision table
The following table is a proposed control surface. Its merge outcomes, owners, escalation routes, and retained artifacts are local policy choices rather than platform guarantees.
| Case | Interaction state | Branch evidence | Documented meaning | Independent acceptance evidence | Merge decision | Inference to reject | Policy owner and bounded action |
|---|---|---|---|---|---|---|---|
| Unresolved Copilot comment | A comment remains open. | No branch remedy or disposition is assumed from that status. | Copilot comments can be handled as review discussions. | A human records either validation of a fix or a reasoned no-change disposition. | Hold or escalate until that record exists. | “Open” alone establishes that a defect exists. | The repository review owner assigns a reviewer, retains the comment identifier and decision, and escalates an overdue item. |
| Resolved comment, unchanged branch | The discussion is marked resolved. | The selected comparison shows no corresponding branch modification. | Resolving is an available action on a Copilot comment. | A human records why no modification is needed, or requests a change and review. | Keep acceptance pending. | “Resolved” means repaired and accepted. | The repository review owner preserves the resolution event, links the inspected comparison, and asks for a documented disposition. |
| Copilot suggestion incorporated | A suggested edit has been taken. | The resulting commit or diff is available for inspection. | Suggested edits may be accepted individually or assembled into a single commit. | A human examines the resulting branch and records an acceptance or rejection decision. | Do not merge on application alone; continue through human review. | A committed suggestion is necessarily correct. | The repository review owner retains the suggestion reference and reviewed revision, then routes uncertain changes for escalation. |
| Human acceptance with an open conversation | A Copilot discussion remains open. | A changed branch and the reviewed revision are identified. | The open discussion is retained as traceability context under this proposed policy. | A designated human records acceptance, scope, and rationale for that reviewed revision. | The recorded human decision controls, subject to the repository’s normal gate. | An open conversation automatically cancels a documented human decision. | The repository review owner keeps both records, assigns any follow-up, and reopens acceptance when later changes invalidate the chosen revision. |
Why comment state needs independent review
Copilot comments can be resolved, while suggested edits may be accepted singly or combined into one commit. Those interaction options are useful evidence to retain, but this article does not treat either option as a substitute for review of the resulting branch.
The supplied overview warns that Copilot can miss issues or be wrong and calls for careful checking alongside human review. That warning supports a local rule requiring a human acceptance record after inspection, not an inference that any particular comment or suggestion is accurate.
- Store the pull-request identifier, conversation identifier, reviewed commit or comparison, reviewer identity, decision, rationale, and any escalation reference.
- Specify who may accept a no-change disposition and who resolves an escalation.
- Invalidate an acceptance record when later commits alter the reviewed branch, then require a new human decision.
- Make the merge gate check for the repository’s acceptance artifact, not merely for a resolved-comment state.
Walk through the ellipsis failure mode
Consider a hypothetical pull request in which a Copilot comment identifies an attempted assignment to the Python ellipsis literal. The author marks the discussion resolved but makes no branch change. No execution, test, or observed result is asserted in this walkthrough.
Python documentation describes the ellipsis literal as an object for omitted material, and identifies assignment to that literal as a SyntaxError boundary. The name Ellipsis has different assignment treatment, so a reviewer must inspect the actual syntax rather than infer correctness from discussion status.
Under the proposed policy, the resolution event is retained, the actual branch comparison is inspected, and a human either records a validated correction or a documented disposition. Until then, the rejected conclusion is that resolving the discussion established both a fix and merge acceptance.
Choose boundaries deliberately
Conversation-led acceptance is simpler, but it collapses a discussion action, a branch-state question, and a human decision into one signal. The alternative proposed here costs additional recordkeeping, yet leaves each question independently reviewable.
This article does not prescribe retention duration, access controls, reviewer roles, override authority, or the exact gate implementation. A repository adopting the model should define those choices, the acceptable no-change dispositions, and the conditions that trigger re-review after later commits.
A resolved discussion is especially unsafe as an acceptance signal after a later push. The documented default is that Copilot does not automatically re-review new pushes, so a pull request can retain a resolved conversation while its current head contains unreviewed changes. Resolution therefore identifies an interaction event, not the revision that was examined.
Make this failure observable: store the resolved-comment identifier separately from an acceptance record bound to the exact head SHA (and inspected comparison). On every head change, invalidate or mark the acceptance record stale and block merge until a designated human records a new decision for the current revision. The recovery test should push a deliberately material follow-up change after resolution and confirm that the gate rejects the stale acceptance before permitting a newly recorded one.
This is consistent with GitHub’s description that Copilot comments may be resolved and that re-review after a push is not automatic by default: GitHub Copilot code review documentation.