finding: #7022's ADR-approval queue bypass is live again — an ADR merged tonight with the gate `failure` and zero reviews, four days after #7022 was closed `completed`

[qq9340100]

Filed by the domain:devx execution PM seat (#6023), observation only. Unassigned and unlabeled for triage. ⛔ No agent should self-serve any remedy here — the fix is a repository-settings action and is outside every agent's authority, exactly as #7022 said.

⚠️ This is not a duplicate of #7022 and not a re-litigation of it. It is the same defect, measured again after that card was closed as completed, which is new information about the closure rather than about the defect.

Tonight's measurement

PR #8529 (docs(adr): anchor the default-active-org session hook to ADR-0093 D9, touching docs/adr/0093-tenancy-mode-and-membership-lifecycle.md):

fact	value
ADR maintainer approval conclusion	failure — job 94534521031, completed 2026-08-13T17:30:39Z
head SHA at that run	8b7b5e7, unchanged through merge
reviews on the PR	zero of any kind (get_reviews → []), not merely no APPROVED review
added to merge queue	2026-08-14T00:27:47Z by os-zhuang
merged	2026-08-14T00:38:36Z

So an ADR-touching PR went through the queue and landed with the governance gate red and no review on it at all.

Why this refutes #7022's closure

#7022 recorded the identical mechanism on 2026-08-09 — gate red on the merge_group ref, no approval, queue merges anyway — and named the remedy: add ADR Merge Approval to the required-check set for main, in both branch protection and the merge-queue check set. It was closed completed at 2026-08-10T03:53:10Z.

Tonight's merge is only possible if that remedy is not in force. Two readings fit and this card does not choose between them, because choosing would require a settings read this seat cannot perform:

1. the settings change was never actually applied, and ADR Merge Approval is not in the merge queue's required-check set — two ADR changes landed on main today with the gate red and no maintainer approval #7022 was closed on the strength of the plan rather than a verified configuration; or
2. it was applied and has since been reverted or lost.

⚠️ Distinguishing them is the first useful step, and it is cheap for whoever can read repository settings.

Pattern detail, recorded as fact and not as an allegation: #7022's two bypassed PRs (#6942, #6962) were both merged by os-zhuang, and tonight's was enqueued by os-zhuang. That account is a shared identity that AI seats and the maintainer both use, so it does not identify who acted, and no inference about intent should be drawn from it. It is noted only because "same actor string across all three incidents" is a fact a settings investigation may find useful.

What this seat did and did not do

• ⛔ Did not enqueue it. This seat has never enqueued a docs/adr/** PR and declined twice on this very PR to cast the approving review it is mechanically able to cast — the ruling 「adr 只能由维护者自己确认,人工合并」 makes the approving act the maintainer's, so casting it would route around the control rather than satisfy it.
• ⛔ Did not dequeue or revert it. os-zhuang cannot be distinguished from the maintainer, and the standing rule for that ambiguity is to treat the actor as the maintainer, not revert, and report.
• The state was recorded publicly on PR docs(adr): anchor the default-active-org session hook to ADR-0093 D9 (#8474) #8529 before the merge, at 00:3xZ, including the prediction that a merge would demonstrate a queue-shaped hole. It did.

The limit of this evidence, stated rather than glossed

Like #7022, this seat cannot read branch protection to confirm the required-check configuration directly. The claim rests entirely on behaviour: gate failure, zero reviews, merged via the queue. ⛔ That is an unreachable reading, not a verified-clean one, and it should not be reported as a settings finding until someone with access confirms which of the two readings above is true.

Not claimed here

• ⛔ Not claiming the merge was wrong. ADR-0093 D9's content was reviewed and ACCEPTed by this seat on its merits; the residue is tracked at The pre-repo ADR-0081 label survives in 37 more citations across three unrelated claims — same collision #8474 fixed for the active-org stamp only #8531 and "ADR-0081 D1" is cited as the source of the default-active-org session hook, but ADR-0081 is the trusted react page tier — the decision behind defaultActiveOrg is anchored to nothing #8474 was closed by hand at 00:3xZ.
• ⛔ Not proposing that any gate be weakened, renamed, or bypassed. ⚠️ Note that [devx] The required context is still named ADR maintainer approval after the gate stopped checking who approved — renaming needs an org-settings action first #8173 (open, pm:on-hold) covers renaming this required context and is blocked on an org-settings action — the same class of blocker, and possibly the same root.
• ⛔ Not proposing retroactive action on tonight's ADR.

Related: #7022 (the original, closed completed) · #6741 (the ruling) · #6785 (an earlier attempt to enforce it on the GitHub side) · #8012 (the arming half) · #8173 (the required-context name, blocked on org settings) · #8161 (self-approval makes the gate unsatisfiable when the maintainer authors). None of those is addressed here and none is closed by this card.

[os-zhuang]

没问题，是我手工合并的