Lane: babysit, observed 2026-07-20 on issue #653 (linked to PR #652, source-control plugin).
Triggering example: #653's own body states "After #504's fix landed (PR #652)..." and the issue was closed with stateReason: COMPLETED at 09:03:16Z. At that same moment, PR #652 was still OPEN and unmerged — it has since flipped to a real CONFLICTING mergeability state against main, meaning the fix #653 describes is not actually on main yet.
Observed vs expected: an issue that exists specifically to track a follow-up on an in-flight PR got closed as done before that PR merged, apparently on the assumption that "PR pushed" == "fix landed." Expected: closing an issue whose completion depends on a specific PR merging should gate on that PR's state == MERGED, not on the PR simply existing or having a commit pushed.
Category: process/operational. This is a new, distinct failure mode from the #645 race-condition family (concurrent-lane collisions producing contradictory thread state) — this one is about premature issue closure based on an unverified merge assumption, which could silently drop real follow-up work if nobody happens to notice the gap (as this lane did here only incidentally, while checking #652's merge readiness for an unrelated reason).
Not proposing a specific fix mechanism (issue-closing isn't a single script this lane could patch) — flagging the pattern so whichever lane/actor is closing issues based on PR activity can add a merged-state check before marking COMPLETED.
Lane: babysit, observed 2026-07-20 on issue #653 (linked to PR #652, source-control plugin).
Triggering example: #653's own body states "After #504's fix landed (PR #652)..." and the issue was closed with
stateReason: COMPLETEDat 09:03:16Z. At that same moment, PR #652 was still OPEN and unmerged — it has since flipped to a realCONFLICTINGmergeability state againstmain, meaning the fix #653 describes is not actually onmainyet.Observed vs expected: an issue that exists specifically to track a follow-up on an in-flight PR got closed as done before that PR merged, apparently on the assumption that "PR pushed" == "fix landed." Expected: closing an issue whose completion depends on a specific PR merging should gate on that PR's
state == MERGED, not on the PR simply existing or having a commit pushed.Category: process/operational. This is a new, distinct failure mode from the #645 race-condition family (concurrent-lane collisions producing contradictory thread state) — this one is about premature issue closure based on an unverified merge assumption, which could silently drop real follow-up work if nobody happens to notice the gap (as this lane did here only incidentally, while checking #652's merge readiness for an unrelated reason).
Not proposing a specific fix mechanism (issue-closing isn't a single script this lane could patch) — flagging the pattern so whichever lane/actor is closing issues based on PR activity can add a merged-state check before marking COMPLETED.