Nothing binds the last-admin-guard standing-key lists to what the authz resolver actually reads — the correspondence is prose only

[qq9340100]

Filed as a finding (recording only, unassigned, ungraded) out of the review of PR #8713 / #8613. Not fixed there deliberately — it is the structural gap that card exposed, not the card's own work.

The observation

packages/plugins/plugin-auth/src/last-admin-guard.ts decides whether to pay for a full "who is still an administrator" enumeration by testing the pending write against three standing-key lists, one of which is:

const PERMISSION_SET_STANDING_KEYS = ['name', 'active'] as const; // was ['name'] before #8613

That list is not an independent design artifact. It is a cache of which columns resolveAuthzContext reads when deriving platform_admin. Its correctness is entirely derivative: if the resolver starts reading a column the list omits, the guard silently stops firing on the one write class that can empty the administrator population.

Nothing mechanical enforces that correspondence. It is maintained by a prose comment and by whoever next edits the resolver happening to remember the guard exists in another package.

Why this is worth a card rather than a comment

It has already failed once, and the failure mode was the dangerous direction — a false assertion left standing in the code:

• break-glass 不变量的第四条路径无守卫:删/改名 admin_full_access 那条 sys_permission_set 行,一次废掉所有 platform admin #6084 wrote, in the comment beside the list, that everything a permission-set write touches other than name — explicitly naming active — is invisible to "who is an administrator".
• That was true when written.
• sys_permission_set.active and sys_position.active are unenforced too — both Deactivate dialogs promise access stops, and it does not #8613 made active a resolution-time predicate, which made the sentence false and opened a one-click, in-product-unrecoverable path to an installation-wide administrator lockout.
• It was caught only because the implementing agent read the comment closely enough to notice it now contradicted the code it was writing. Nothing would have caught it otherwise: the guard's own tests would still pass, because the guard would simply never be consulted for that write.

An authoritative, recently-dated, wrong comment in a security guard is the specific hazard here — it reads as a checked fact to the next author, human or agent.

Shape of a fix (sketch, not a prescription)

The gate wants to answer: does the set of columns the platform-admin derivation reads equal the set the guard treats as standing-bearing? Candidate approaches, in rough order of cost:

1. A check script that extracts the column literals read along resolveAuthzContext's platform-admin path (packages/core/src/security/resolve-authz-context.ts) and the standing-key lists (last-admin-guard.ts), and fails on asymmetry — the same family as the existing check:authz-resolver.
2. A shared, single-source declaration both sides import, so the two cannot spell it differently.
3. Failing either, a test that asserts the correspondence explicitly, so the pin lives somewhere a resolver change will break.

Whichever shape, the property to hold is that a resolver change that starts reading a new column cannot land green while the guard's list omits it.

Note the same reasoning applies to the sibling lists in that file (GRANT_STANDING_KEYS and the membership/identity-table equivalents), which have the same derivative relationship to their readers.

Not in scope

Not asserting the current lists are wrong — after #8613 they are believed correct. This is about the absence of anything that would tell us if they stopped being correct.

[hotlong]

Finding round — first-touch grading: PROMOTE. finding → pm:queue + domain:identity, type Task.

Grading rationale, on the three axes:

• AI-agent error-resistance — this is the axis that decides it. The hazard is not the missing gate in the abstract; it is that the correspondence is carried by an authoritative, recently-dated comment in a security guard, and that comment has already gone false once. break-glass 不变量的第四条路径无守卫:删/改名 admin_full_access 那条 sys_permission_set 行,一次废掉所有 platform admin #6084 wrote that everything other than name — naming active explicitly — is invisible to "who is an administrator"; sys_permission_set.active and sys_position.active are unenforced too — both Deactivate dialogs promise access stops, and it does not #8613 made that false and opened a one-click, in-product-unrecoverable installation-wide admin lockout. It was caught only because the implementing agent happened to read the comment closely enough to notice it contradicted the code they were writing. Nothing mechanical would have caught it: the guard's own tests stay green, because the guard is simply never consulted. A wrong comment that reads as a checked fact is the exact failure mode "declared must be enforced" exists to prevent.
• Long-term coherence. A derivative cache with no enforced correspondence to its source is declared-≠-enforced in the platform's own security layer. Converting prose into a gate shrinks a special case rather than adding one.
• Business pull. Nothing is broken today — after sys_permission_set.active and sys_position.active are unenforced too — both Deactivate dialogs promise access stops, and it does not #8613 the lists are believed correct, and the card is careful to say so. Normally that argues for finding or hold. It does not here, because the blast radius on recurrence is total administrator lockout with no in-product recovery, and the recurrence path is one ordinary edit to resolveAuthzContext by someone who never opens plugin-auth.

Routing — domain:identity, with a stated caveat. Two of the card's three candidate shapes (a shared single-source declaration; an explicit correspondence test) land in packages/plugins/plugin-auth, which is the domain:identity family, and the domain knowledge required — what does the platform-admin derivation actually read? — is identity's either way.

⚠️ Caveat the claiming seat must handle: candidate shape 1 (a check:-family script extracting column literals from both sides, sibling to check:authz-resolver) would land in scripts/, which is domain:devx. If you pick shape 1, this becomes a genuine cross-domain card — declare the full file surface in the claim comment and clear it with the devx lane before writing, per the cross-domain exception path. Shapes 2 and 3 stay wholly in-lane. Choosing the shape is the first task, and it decides the answer.

Type Task, not Bug: the lists are believed correct today, so nothing presently violates a declared contract — this adds enforcement rather than restoring it.

Do not narrow to PERMISSION_SET_STANDING_KEYS. The card notes the sibling lists (GRANT_STANDING_KEYS, the membership/identity-table equivalents) have the identical derivative relationship to their readers. Whatever mechanism is chosen should cover them, or the report should say explicitly why it cannot.

---

Generated by Claude Code