Observation filed unassigned by the dev seat that implemented #8161 (PR #8172). Not a defect — nothing is broken today. Recording it so the stale name is a decision rather than a thing nobody noticed.
The state after #8161
Per the maintainer ruling of 2026-08-12 (「门禁改成只要求「APPROVED review 存在」」/「不要指定具体的人」), scripts/check-adr-merge-approval.mjs no longer judges WHO approved. Its check context is still published under the job name:
adr-merge-approval:
name: ADR maintainer approval
The word "maintainer" now over-claims: any account with review rights satisfies the gate. A reader who trusts the context name will believe a guarantee the check does not provide.
Why it was not renamed in that PR, measured
The name is not cosmetic — it is the required-status-context string, in two coupled places:
Renaming the job alone leaves the ruleset waiting for a context that never reports, which hangs the merge queue until the ruleset's 60-minute timeout — the objectui#3523 failure shape. So the rename is gated on a settings change nobody in CI can perform, and the ordering is: update the ruleset first (or add the new context alongside the old), then rename the job, then update the registry.
A comment on the job in .github/workflows/adr-merge-approval.yml records this, so the next reader does not "fix" the name in a code PR.
If it is taken up
Candidate spellings, all honest about what runs: ADR approval required, ADR review approval, ADR merge gate. Whether it is worth an org-settings round-trip is a judgement call — leaving it is defensible, since the header prose in both files now states plainly what the gate does and does not guarantee.
Related: #8161 (the ruling), #8012 (the auto-merge arming gap, open).
Observation filed unassigned by the dev seat that implemented #8161 (PR #8172). Not a defect — nothing is broken today. Recording it so the stale name is a decision rather than a thing nobody noticed.
The state after #8161
Per the maintainer ruling of 2026-08-12 (「门禁改成只要求「APPROVED review 存在」」/「不要指定具体的人」),
scripts/check-adr-merge-approval.mjsno longer judges WHO approved. Its check context is still published under the job name:The word "maintainer" now over-claims: any account with review rights satisfies the gate. A reader who trusts the context name will believe a guarantee the check does not provide.
Why it was not renamed in that PR, measured
The name is not cosmetic — it is the required-status-context string, in two coupled places:
mainruleset requires the literal contextADR maintainer approval(ADR Merge Approvalis 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, maintainer settings action);scripts/check-required-contexts.mjsregisters that exact spelling, and its own self-test carries a fixture (rename ADR maintainer approval) that goes red if the job name changes.Renaming the job alone leaves the ruleset waiting for a context that never reports, which hangs the merge queue until the ruleset's 60-minute timeout — the objectui#3523 failure shape. So the rename is gated on a settings change nobody in CI can perform, and the ordering is: update the ruleset first (or add the new context alongside the old), then rename the job, then update the registry.
A comment on the job in
.github/workflows/adr-merge-approval.ymlrecords this, so the next reader does not "fix" the name in a code PR.If it is taken up
Candidate spellings, all honest about what runs:
ADR approval required,ADR review approval,ADR merge gate. Whether it is worth an org-settings round-trip is a judgement call — leaving it is defensible, since the header prose in both files now states plainly what the gate does and does not guarantee.Related: #8161 (the ruling), #8012 (the auto-merge arming gap, open).