finding: #5617's standing "never require" list is stale on `Console Pin Freshness` — #6121 added the `merge_group:` trigger that was the stated reason

[os-project-manager]

Observation-class. Found while re-verifying #5617's audit exclusions for #6865 (PR #6983); not carried in that PR. No settings change is proposed here — required-set configuration is maintainer-only.

Fact

#5617's closing ruling (2026-08-09 05:42Z) re-affirms three standing exclusions from main's required-status-check set. Re-measured against origin/main at 55011af, two are still accurate and one is not:

context	workflow	stated reason	still true?
Spec property liveness	spec-liveness-check.yml	PR-side paths: filter	✅ yes — pull_request: still carries paths: (packages/spec/**, content/docs/**, …)
Validate Package Dependencies	validate-deps.yml	both faults	✅ yes — pull_request: carries paths:, and there is no merge_group: at all
Console Pin Freshness	objectui-pin-freshness.yml	"no merge_group trigger — requiring it deadlocks the queue"	❌ no longer true

objectui-pin-freshness.yml now has both structural preconditions:

• on: carries merge_group: — added by objectui-pin-freshness.yml 的注释在邀请把 Console Pin Freshness 加进 required 集,而它没有 merge_group 触发器——照做即合并队列全死锁(observation) #6121, the observation card the audit itself spun out, closed since;
• on: pull_request: branches: [main] with no paths: / paths-ignore:;
• the job carries no if:, no matrix and no continue-on-error, and the file states this is deliberate ("Advisory mode is expressed in the EXIT CODE, not by skipping").

The file's own header now documents the fix and instructs future editors accordingly:

⚠️ THE PRECONDITION IS THE merge_group: TRIGGER BELOW (#6121). Adding this context to a required set is safe ONLY BECAUSE that trigger now exists.

Why this matters

The exclusion and its fix were both produced by the #5617 audit thread, but the exclusion list was re-affirmed verbatim on 2026-08-09 while #6121 had already removed its premise. The cost is asymmetric and quiet: a stale ⛔ keeps a gateable context advisory forever, and nothing will ever surface that — the list is prose in a closed issue, so no gate re-checks it. This is the same shape as #6865 itself (a contract that lives only in prose), one level up.

What is NOT claimed

• Not that Console Pin Freshness should be required. The structural preconditions being met answers "would requiring it deadlock the queue?" (no, not any more). It does not answer "is blocking the right lane for pin drift on ordinary PRs?" — the workflow deliberately splits blocking vs reporting inside the pin-freshness step, and whether the blocking lane belongs in branch protection is a maintainer judgement about release process, not a structural fact.
• Not readable from any agent seat: whether the context is currently in the required set cannot be checked from here (GET /repos/.../branches/main/protection answers HTTP 403 for every agent seat). Only the repo-side half is measurable, and that is what is measured above.

Suggested disposition

A maintainer re-reads the one row on the next Settings visit; if Console Pin Freshness is still wanted out, record the current reason (a release-process judgement) rather than the retired one, so the next audit does not re-derive a premise that no longer exists.

If it is brought in, note that PR #6983 (#6865) adds check:required-contexts, whose registry is where the name would then be pinned — its assertions 6 and 7 are exactly the machine-readable form of the two structural preconditions above, so an enrollment that would deadlock the queue fails in the ESLint job instead.

Related: #5617 (audit + rulings), #6121 (the fix that made this row stale), #6865 / PR #6983.