Review findings that arrive after merge are stranded: the thread-resolution gate cannot see them

[kyle-sexton]

This was generated by AI after a post-merge review left six findings stranded on a merged PR.

Context

chatgpt-codex-connector posted six review findings on #1720 at 2026-07-29T19:24:03Z — 46
seconds after that PR merged at 19:23:17Z. One was P1.

Nothing was bypassed. The base ruleset's required_review_thread_resolution was satisfied at merge
time because the threads did not yet exist. The gate is a merge-time predicate, and the review
arrived after it.

The findings then sat unread for a day. They surfaced only because a later session happened to audit
what the merge batch carried, and they turned out to be six real defects — including one that would
let an unattended consumer log healthy scheduler ticks forever while processing nothing (fixed in
#1759 / #1760).

The gap

A review that lands after merge has nowhere to go.

• The merge gate cannot see it — it already passed.
• No queue holds it — the babysit lane works open PRs, and a merged PR leaves that queue.
• The morning brief does not report it.
• Nothing on a merged PR surfaces open threads; GitHub shows the merge, not the findings.

This is structural, not a one-off. Any review that is slower than the merge — a bot that queues
behind CI, a human reviewing after auto-merge fires — produces it. The window is exactly "review
latency minus time-to-merge", and squash-merge-on-green makes that window routinely positive.

Why it is worth closing rather than accepting

The whole point of the review-thread merge gate is that no finding merges unaddressed. A finding that
arrives 46 seconds late is not less real than one that arrives 46 seconds early — but the first is
enforced and the second is invisible. The gate creates a false sense that "merged" implies "no open
findings", which is exactly the belief that let these six sit.

Acceptance criteria

• A sweep exists that finds unresolved review threads on recently merged PRs — recency
  window configurable, defaulting to something that comfortably covers bot review latency.
• Each finding it surfaces becomes an actionable item (issue, queue row, or brief line) rather
  than a log entry, since the thread itself is already proven not to surface anywhere.
• It distinguishes threads that arrived after merge from ones resolved before it, so the
  output is the genuinely-stranded set and not every historical thread.
• It runs somewhere unattended — a lane cycle, the morning brief, or a scheduled task — because
  the failure mode is precisely that nobody looks.
• Severity is preserved end to end: a P1 stranded on a merged PR must not read like a P3.

Notes for whoever picks this up

• gh api graphql over pullRequest.reviewThreads exposes isResolved and each comment's
  createdAt; comparing that against the PR's mergedAt is what separates "arrived late" from
  "was ignored". That comparison is the core of the check.
• Consider whether the right fix is partly preventive — e.g. not auto-merging while a review is
  known to be in flight. source-control already has a merge-gate notion of a "current-head review
  in flight" (fix(source-control): hold the merge gate while a current-head review is in flight #1634); this may be the same problem one step later in the timeline.
• The six findings this came from are claude-ops/restart-consumer: six post-merge review findings on #1720 never reached triage #1759, fixed in fix(claude-ops): correct six restart-consumer defects found after #1720 merged #1760, if you want a concrete worked example
  of what gets stranded.

Related

Refs #1720
Refs #1759
Refs #1634