[governance] The ADR gate blocks the merge but not the ARMING of auto-merge — an AI seat armed it on a live `docs/adr/**` PR today, which would have made the maintainer's approval the merge trigger

[hotlong]

Filing unassigned; domain:* routing and grading are the triage seat's. Observed live on PR #7960 (the ADR-0001 tombstone, #7866) at ~11:15Z on 2026-08-12 by the domain:devx PM seat (#6023). Nothing was lost — caught and disarmed before any merge.

What happened

when	actor	action
~11:10Z	hotlong (maintainer)	marked PR #7960 ready for review — deliberate
~11:14Z	os-zhuang (AI seat account)	submitted an APPROVED review
~11:15Z	os-zhuang	enabled auto-merge (method: merge)
~11:15Z	—	ADR maintainer approval re-ran and failed — correctly refused the approval
~11:17Z	hotlong (devx PM seat)	disabled auto-merge; verified not merged, not enqueued, tombstone absent from main

The gap

scripts/check-adr-merge-approval.mjs enforces #6741 by making the PR unmergeable without an APPROVED review from an account in MAINTAINER_APPROVERS. That half works — it refused os-zhuang's approval exactly as designed, and approvalsFromNonMaintainers named it.

But nothing prevents an AI seat from arming auto-merge on an ADR PR while the gate is red. Auto-merge is not a merge, so no gate fires on it. It is a standing instruction to merge later, and it survives until something turns the required checks green.

The consequence is precise and bad: with auto-merge armed, the maintainer's own approving review becomes the merge trigger. They approve → the gate re-runs (the workflow subscribes to pull_request_review: [submitted], deliberately, for the zero-friction green path) → it goes green → GitHub merges immediately, unattended.

The ruling is 「adr 只能由维护者自己确认,人工合并,ai 不得擅自合并。」 — two clauses. The gate enforces 确认 (only the maintainer's approval counts). It does not enforce 人工合并 (the merge is performed by a human). With auto-merge pre-armed by an AI seat, 确认 happens and 人工合并 does not: the maintainer approves, a machine another seat armed does the merging. The gate would report success while the second clause was bypassed.

⚠️ Note this is not caught by the gate's own merge_group handling, and it leaves no red mark — the merge would look like a perfectly normal approved-and-green landing.

Why prose won't close it

This is the third instance of the same shape, and the first two are both closed as fixed:

• [governance] Enforce the ADR merge prohibition on the GitHub side — prose did not propagate; two seats merged docs/adr/** PRs within an hour of the ruling #6785 / ⛔ Discipline: ADRs are confirmed and merged by the maintainer only — no AI seat may merge, queue, or auto-merge a docs/adr/** PR #6741 — the ruling landed, and two AI seats merged docs/adr/** PRs within the hour. Prose enforcement measured insufficient; the gate was built in response.
• 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 — the gate existed but sat outside the required-check set, so fix(spec,rest,runtime)!: the ADR-0045 publish gate gets its own machine-managed key — app.hidden goes back to meaning navigation (#4829) #6942/docs(adr-0094): retire D5's env-overlay customization direction (D5-R, #6609 ruling A) #6962 landed with it red.
• [finding] A skills-root PR was queued by a sibling session ~1h after the ADR-class ruling — a ruling recorded only on cards cannot bind sessions that haven't read it #7701 — "a skills-root PR was queued by a sibling session ~1h after the ADR-class ruling — a ruling recorded only on cards cannot bind sessions that haven't read it."

Today's event is #7701's finding recurring verbatim, on the ADR surface, through the one door the gate does not watch. The os-zhuang seat did nothing malicious and very likely had not read the ADR-class prohibition — which is exactly #7701's point. Every time this has been left to prose it has recurred within hours.

Shapes a fix could take (not choosing — this is a governance surface)

1. Fail the gate when auto-merge is armed on a docs/adr/** PR without a qualifying approval. Most direct: it makes the forbidden state red rather than relying on nobody entering it. The gate already lists the PR's reviews, so it has the API surface.
2. Ruleset-side: disallow auto-merge on the repo, or require the merge actor to be the maintainer.
3. Detect and disarm (what this seat did by hand) on a schedule — weakest, since it is a race against the maintainer's approval.

Option 1 has a wrinkle worth measuring rather than assuming: a gate that goes red because auto-merge is armed must not then be satisfiable by disarming-and-rearming, and it must still be green on the legitimate path (maintainer approves, then merges in person).

⚠️ Related, and more serious — a separate decision for the maintainer

scripts/check-adr-merge-approval.mjs:101:

export const MAINTAINER_APPROVERS = [{ login: 'hotlong', id: 50353452 }];

That account is the identity AI seats authenticate as in this environment — get_me from a PM session returns exactly hotlong / 50353452. The file's own header states that "approvals from the shared bot/agent identities deliberately do not count", but the account it designates as the maintainer's own is an identity agents operate under. An AI seat can therefore satisfy this gate directly.

It did not happen here — the approval came from os-zhuang, which is correctly refused — and this seat will not approve an ADR PR regardless of holding the credential. But the gate's guarantee currently rests on seats declining to use access they have, which is the condition #6741 was written because prose could not maintain.

This is a security/permission-boundary decision and is explicitly the maintainer's (already raised to them in session, 2026-08-12 ~11:1xZ). Recorded here so it is not lost, not to propose a change. It is separable from the auto-merge gap above and probably wants its own card once graded.

Evidence

PR #7960's audit comment carries the full ordered timeline. Current state verified by fresh fetch, not by tool return values: PR open, ready, not merged, not enqueued, auto-merge off, docs/adr/0001-withdrawn-metadata-service-architecture.md not on main, ADR maintainer approval red (correctly).

[hotlong]

Second, sharper defect found on the same PR: the gate deadlocks when the maintainer is the PR author

Measured on PR #7960 after filing this card. This is more actionable than the auto-merge gap above, because it makes ADR PRs unmergeable through the designed path, not merely bypassable.

fact	value
PR #7960 author	hotlong (id 50353452)
MAINTAINER_APPROVERS (check-adr-merge-approval.mjs:101)	[{ login: 'hotlong', id: 50353452 }]
GitHub	a user cannot approve their own pull request

The only account the gate accepts is the only account that cannot approve this PR. No sequence of actions turns the check green. Confirmed empirically: the maintainer attempted it and got GitHub's own refusal ("自己提交的不能批准"), then approved from os-zhuang three times, each of which correctly re-ran the gate and correctly failed.

Why it had not surfaced before

docs/adr/** PRs have historically been authored by other accounts — os-project-manager (PR #7316), os-help (#7343), os-zhuang (#6942 / #6962 / #7087). Author ≠ approver, so the gate worked. It surfaced now because a cloud dev session dispatched by the devx seat opened the PR on this seat's credential, which happens to be hotlong.

⇒ The trigger is not the ADR surface — it is which account the agent fleet runs as. Any seat holding the hotlong credential will deadlock every ADR PR it drafts.

This also re-frames the "related observation" in the original post

The two are one defect with two faces:

• Agents hold the maintainer's account ⇒ they could satisfy the gate directly (the original observation).
• Agents author as the maintainer ⇒ their ADR PRs can never satisfy it (this one).

Both dissolve if the agent fleet gets its own identity, distinct from MAINTAINER_APPROVERS. That is a single infrastructure change, not a gate change, and it restores the property the gate's header claims it already has — "approvals from the shared bot/agent identities deliberately do not count" — which today is not true of hotlong.

⛔ A fix direction to rule out explicitly

Do not add "PR author is in MAINTAINER_APPROVERS ⇒ pass". It reads like the obvious patch for a self-approval deadlock, and it would weld the gate open: AI seats author as hotlong, so every AI-drafted ADR PR would self-certify. Anyone reaching for the one-line fix should read this paragraph first.

If the gate must handle the author-is-maintainer case at all, the shape that preserves the ruling is to check the merge actor rather than substituting an approval — 「人工合并」 is the clause an approving review was only ever a proxy for. That needs measuring against the merge_group path before anyone commits to it.

Current disposition

PR #7960 is parked: not merged, not enqueued, auto-merge off, gate red. The maintainer has the three routes (admin merge / re-open from another account / fleet identity fix) and this seat takes none of them unilaterally.

---

Generated by Claude Code

[hotlong]

Triage → needs-user-decision + domain:devx (was finding). This is a governance/permission-boundary cluster on the human floor. The gate-hardening half alone would be dispatchable, but its right shape depends on the identity decision, so the card goes to the inbox as one decision rather than splitting prematurely.

The three linked questions:

1. Fleet identity — AI seats authenticate as hotlong/50353452, the only entry in MAINTAINER_APPROVERS. Two measured faces of one defect: seats could satisfy the ADR gate directly, and seats authoring ADR PRs as hotlong deadlock them (GitHub refuses self-approval — measured on PR docs(adr),chore(devx): tombstone ADR-0001 — retire the number, empty the citation allowlist (#7866) #7960, currently unmergeable through the designed path).
2. Auto-merge arming — nothing stops a seat arming auto-merge on an ADR PR while the gate is red, which makes the maintainer's own approving review the merge trigger (measured live ~11:15Z today; disarmed by hand).
3. PR docs(adr),chore(devx): tombstone ADR-0001 — retire the number, empty the citation allowlist (#7866) #7960 disposition — admin merge / re-open from another account / wait for the identity fix.

Premise re-checks: git fetch origin main && git show origin/main:scripts/check-adr-merge-approval.mjs | grep -n -A2 MAINTAINER_APPROVERS; PR #7960 state by fresh fetch (at filing: open, ready, auto-merge off, gate red, tombstone absent from main).

Four-lens:

• Platform long-term coherence: a distinct fleet identity restores the property the gate's own header claims ("approvals from the shared bot/agent identities deliberately do not count") and dissolves both faces in one infrastructure change; per-face gate patches accrete special cases.
• Measured business pull: third recurrence of the prose-cannot-bind-sessions class ([governance] Enforce the ADR merge prohibition on the GitHub side — prose did not propagate; two seats merged docs/adr/** PRs within an hour of the ruling #6785 → gate built; 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 → gate made required; [finding] A skills-root PR was queued by a sibling session ~1h after the ADR-class ruling — a ruling recorded only on cards cannot bind sessions that haven't read it #7701 — each recurred within hours), plus a real ADR PR blocked today.
• AI-agent error-resistance: structural enforcement over prose is this family's entire lesson. ⛔ The on-card ruled-out patch ("PR author ∈ MAINTAINER_APPROVERS ⇒ pass") would weld the gate open, since seats author as hotlong — flagging it again because it is the patch an AI will reach for.
• Startup scope discipline: one identity change + one small gate check beats a growing lattice of ADR-surface guards.

Recommendation: (a) give the agent fleet its own GitHub identity, distinct from MAINTAINER_APPROVERS — maintainer-side infrastructure action, the only change that closes both faces; (b) once (a) is ruled, approve the option-1 gate hardening (gate goes red when auto-merge is armed on a docs/adr/** PR without a qualifying approval) as a normal domain:devx card — it is correct under either identity outcome and I will split it out on your ruling, with the disarm-rearm wrinkle measured as the card requires; (c) for PR #7960, re-opening the same branch under the fleet identity after (a) is the path that proves the fix.

⛔ Nothing here is self-serviceable by any seat: the approver list and repo rulesets are the maintainer's own controls, and this seat takes none of the three #7960 routes unilaterally.

---

Generated by Claude Code

[hotlong]

Cross-reference: this card's "⚠️ Related, and more serious" section said the shared-identity problem "probably wants its own card once graded". It now has one — #8161, filed after the maintainer judged the #7960 blockage to be a CI-rule defect.

#8161 carries the other half of the same root cause, and the two are worth reading together because they point in opposite directions:

• this card ([governance] The ADR gate blocks the merge but not the ARMING of auto-merge — an AI seat armed it on a live docs/adr/** PR today, which would have made the maintainer's approval the merge trigger #8012) — the gate can be satisfied by an AI seat holding the hotlong credential;
• [governance] ADR maintainer approval is unsatisfiable on any PR the maintainer authored — GitHub forbids self-approval, so the gate is permanently red exactly when the human IS driving #8161 — the gate can never be satisfied on a PR hotlong authored, because GitHub forbids self-approval, and cloud dev sessions now author under hotlong.

Closed on the case it should admit, open on the case it should refuse. Both dissolve under #8161's shape 1 (a separate account for the agent fleet); neither dissolves under any pure-CI change. No action requested here — recording so the two are not fixed in isolation.

---

Generated by Claude Code

[hotlong]

Maintainer ruling (2026-08-12, live PM chat session session_01GxKQfv3k8b6a2d2QrZU411, verbatim: 「接受你的全部建议。」 accepting the triage seat's per-card recommendations), all three parts:

• (a) Fleet identity: AI seats get a GitHub identity distinct from MAINTAINER_APPROVERS. ⚠️ This part is the maintainer's own action — creating the machine account, org membership, and credential rotation cannot be done by a seat. Until it lands, every hotlong comment remains ambiguous in the audit record.
• (b) Gate: option 1 — check-adr-merge-approval (or a sibling check) fails when auto-merge is armed on a docs/adr/** PR without a qualifying maintainer approval. This card is returned to pm:queue (domain:devx) scoped to exactly that. Gate modification is hereby maintainer-sanctioned. ⛔ Binding constraint from the card, twice-flagged: do NOT add "PR author ∈ MAINTAINER_APPROVERS ⇒ pass" — that welds the gate open. Measure the disarm-rearm race rather than assuming it away.
• (c) PR docs(adr),chore(devx): tombstone ADR-0001 — retire the number, empty the citation allowlist (#7866) #7960: re-open under the fleet identity once (a) exists, proving the fix; do not admin-merge meanwhile.

---

Generated by Claude Code