Found while re-verifying the platform-admin doc claims against merged code for #11976 (L7). Not a runtime defect on either site — both are comments — but both ship or steer, and both now describe a gate that #11974 (L4) retired.
1. packages/types/src/email-verified.ts — the module docblock names a retired consumer
The docblock over isEmailVerifiedUserRow still says, verbatim:
ONE resolution, two consumers, by design (#12751): the walled platform-admin elevation gate (plugin-securitybootstrapPlatformAdmin, where the check REFUSES an unverified owner match) and the walled owner-verification boot diagnostic (plugin-authwalled-owner-verification-path.ts …)
After L4 the walled arm of bootstrapPlatformAdmin writes no grant row and performs no elevation — it reports. The predicate's real consumers now include matchesConfiguredPlatformAdmin in packages/core/src/security/platform-admin.ts (the derivation site) and resolvePlatformAdminStanding in plugin-security/src/platform-admin-service.ts (the audit surface).
Why it is worth a card rather than a shrug: this docblock is exported prose — it reaches consumers in the package's type declarations — and it tells the next reader that the drift risk is between two named callers, when the real set is larger and includes the authorization derivation itself. The "two must answer identically or a boot warning forecasts a refusal the gate will not make" argument now under-describes the invariant.
2. packages/plugins/plugin-auth/src/last-admin-guard.ts — the active reasoning is grant-only
The comment above PERMISSION_SET_STANDING_KEYS says:
It now drops a DEACTIVATED set before any derivation, so active: false on admin_full_access un-makes every platform admin at once
That is true for the grant anchor only. resolve-authz-context.ts §6b-config sets hasPlatformAdminGrant from configuration and the caller's own sys_user row without consulting psRows or isRowActive at all, and its capability envelope comes from the shipped ADMIN_FULL_ACCESS_CAPABILITIES declaration rather than the stored set row. So deactivating the set does not un-make a configured, verified administrator.
The guard's behaviour is unaffected and correct: keeping active in the standing keys is an over-approximation, which fails in the safe direction, and the enumeration in resolveAdminUserIds does have a config-derived arm. It is the stated reason that is now wrong, and it is the reason a future reader would use to decide whether the key can be dropped.
Suggested shape
One comment-only change touching both files, no behaviour. Worth pairing with whichever leg next edits these files rather than a standalone PR.
Scope note
Deliberately not fixed inside #11976: that card is docs-body-prose only and declared no packages/ surface, so touching either file there would have been unrecorded scope creep.
Context: #11663 (design), #11970 (L2), #11974 (L4).
Generated by Claude Code
Found while re-verifying the platform-admin doc claims against merged code for #11976 (L7). Not a runtime defect on either site — both are comments — but both ship or steer, and both now describe a gate that #11974 (L4) retired.
1.
packages/types/src/email-verified.ts— the module docblock names a retired consumerThe docblock over
isEmailVerifiedUserRowstill says, verbatim:After L4 the walled arm of
bootstrapPlatformAdminwrites no grant row and performs no elevation — it reports. The predicate's real consumers now includematchesConfiguredPlatformAdmininpackages/core/src/security/platform-admin.ts(the derivation site) andresolvePlatformAdminStandinginplugin-security/src/platform-admin-service.ts(the audit surface).Why it is worth a card rather than a shrug: this docblock is exported prose — it reaches consumers in the package's type declarations — and it tells the next reader that the drift risk is between two named callers, when the real set is larger and includes the authorization derivation itself. The "two must answer identically or a boot warning forecasts a refusal the gate will not make" argument now under-describes the invariant.
2.
packages/plugins/plugin-auth/src/last-admin-guard.ts— theactivereasoning is grant-onlyThe comment above
PERMISSION_SET_STANDING_KEYSsays:That is true for the grant anchor only.
resolve-authz-context.ts§6b-config setshasPlatformAdminGrantfrom configuration and the caller's ownsys_userrow without consultingpsRowsorisRowActiveat all, and its capability envelope comes from the shippedADMIN_FULL_ACCESS_CAPABILITIESdeclaration rather than the stored set row. So deactivating the set does not un-make a configured, verified administrator.The guard's behaviour is unaffected and correct: keeping
activein the standing keys is an over-approximation, which fails in the safe direction, and the enumeration inresolveAdminUserIdsdoes have a config-derived arm. It is the stated reason that is now wrong, and it is the reason a future reader would use to decide whether the key can be dropped.Suggested shape
One comment-only change touching both files, no behaviour. Worth pairing with whichever leg next edits these files rather than a standalone PR.
Scope note
Deliberately not fixed inside #11976: that card is docs-body-prose only and declared no
packages/surface, so touching either file there would have been unrecorded scope creep.Context: #11663 (design), #11970 (L2), #11974 (L4).
Generated by Claude Code