What happened (all times 2026-08-21 UTC, all facts measured)
PR #10483 touches .claude/workflows/docs-accuracy-audit.js — governed surface (check:pm-governed-merges --test: GOVERNED, .claude/** x1, recorded in the PR body itself, which also states "No seat should flip this ready, enqueue it, or arm auto-merge"). Under the #9495 regime a human merge is the review record for this class; no seat may ready/enqueue/arm it.
Timeline:
00:38 PR created as draft by the authoring seat.~03:05 PM seat read the PR: still draft: true.- Between
03:26 and 03:39:35 (PR updated_at) the PR was flipped ready and added to the merge queue. Nobody claims the action: the maintainer states on record it was not them (live PM session, 2026-08-21); it was not the PM session coordinating at the time nor either of its two dev agents; the authoring seat's own PR body forbids exactly this. ~03:40 a dev pushing an authorized commit to the branch was rejected with GH006 — branch locked by the merge queue. This rejection is the ONLY reason the incident was noticed before merge; no guard fired.~03:5x the maintainer manually removed the PR from the queue (their statement, recorded in the PM session).~04:0x PM converted the PR back to draft; the authorized commit (a746b55) then pushed normally.
Impact: none landed — dequeued before the queue could merge. Had it merged, a .claude/** change would have reached main with no human review record, which is precisely what the governed regime exists to prevent. The check:pm-governed-merges audit is post-merge and would have flagged it only after the fact.
What needs investigating
- Attribution. The PR timeline events (
ready_for_review, auto_merge_enabled / added_to_merge_queue) carry the actor — but all agent sessions share one GitHub identity, so the actor field alone may not resolve which session or automation; correlate event timestamps (03:26–03:39:35 window) against session/workflow activity. Candidate classes: another agent session violating seat discipline; an automation or workflow with ready/enqueue side effects; a UI mis-click from a shared login. - Guard gap. Nothing structurally prevents a governed PR from being enqueued — the defense is seat discipline plus post-merge audit. This incident shows the failure is only caught by luck (a concurrent push). Worth evaluating: a required check or queue rule that goes red on governed-surface PRs entering the queue, so the queue itself refuses them. (Filed as a question, not a design — the guard's shape is a decision.)
Re-check commands
Filed unassigned for triage routing. Maintainer is already aware (the dequeue was their manual action).
What happened (all times 2026-08-21 UTC, all facts measured)
PR #10483 touches
.claude/workflows/docs-accuracy-audit.js— governed surface (check:pm-governed-merges --test: GOVERNED,.claude/** x1, recorded in the PR body itself, which also states "No seat should flip this ready, enqueue it, or arm auto-merge"). Under the #9495 regime a human merge is the review record for this class; no seat may ready/enqueue/arm it.Timeline:
00:38PR created as draft by the authoring seat.~03:05PM seat read the PR: stilldraft: true.03:26and03:39:35(PRupdated_at) the PR was flipped ready and added to the merge queue. Nobody claims the action: the maintainer states on record it was not them (live PM session, 2026-08-21); it was not the PM session coordinating at the time nor either of its two dev agents; the authoring seat's own PR body forbids exactly this.~03:40a dev pushing an authorized commit to the branch was rejected with GH006 — branch locked by the merge queue. This rejection is the ONLY reason the incident was noticed before merge; no guard fired.~03:5xthe maintainer manually removed the PR from the queue (their statement, recorded in the PM session).~04:0xPM converted the PR back to draft; the authorized commit (a746b55) then pushed normally.Impact: none landed — dequeued before the queue could merge. Had it merged, a
.claude/**change would have reachedmainwith no human review record, which is precisely what the governed regime exists to prevent. Thecheck:pm-governed-mergesaudit is post-merge and would have flagged it only after the fact.What needs investigating
ready_for_review,auto_merge_enabled/added_to_merge_queue) carry the actor — but all agent sessions share one GitHub identity, so the actor field alone may not resolve which session or automation; correlate event timestamps (03:26–03:39:35 window) against session/workflow activity. Candidate classes: another agent session violating seat discipline; an automation or workflow with ready/enqueue side effects; a UI mis-click from a shared login.Re-check commands
node scripts/pm/check-governed-merges.mjs --test <paths>→ GOVERNED, exit 3.node scripts/pm/check-governed-merges.mjs --since <date>.Filed unassigned for triage routing. Maintainer is already aware (the dequeue was their manual action).