Found while implementing #13661 (which corrects four sites in two files). Comment-only drift, no runtime defect — but the same dead premise survives at roughly six more sites the card did not scope, and one of them ships in a package's type declarations.
The dead premise
The #11663 platform-admin re-anchor (legs L2 and L4, both landed) retired the walled platform-admin elevation gate. Under a walled posture bootstrapPlatformAdmin writes no grant row and elevates nobody — it reports. Standing is derived per request at resolve-authz-context.ts §6b-config, from a config-anchored verified email or the legacy unscoped grant row.
Comments that still name "the elevation gate" in the present tense therefore point a reader at a mechanism that no longer exists. Measured on origin/main at 46b53a25b:
| Site | Quote (verbatim) | Note |
|---|
packages/types/src/env.ts:169 | "the walled boot guard in plugin-auth, the elevation refusal in plugin-security's bootstrapPlatformAdmin" | Docblock over the exportedPLATFORM_OWNER_EMAIL_ENV, so it ships in @objectstack/types.d.ts — the same reason #13661 singled out email-verified.ts |
packages/core/src/security/platform-admin.ts:117 | "the elevation gate's by-email sys_user lookup queries the verbatim spelling alongside the normalized one" | The two-spelling lookup is real, but it now lives in resolvePlatformAdminStanding; the referent moved, the name did not |
packages/core/src/security/platform-admin.ts:287 | "the elevation gate (plugin-security/bootstrap-platform-admin.ts) must keep the two halves SEPARATE" | ⚠️ Only the NAME is stale here. bootstrap-platform-admin.ts still emits walled_owner_not_registered / walled_owner_not_verified as separate answers, so the reasoning is correct and must survive the rename |
packages/plugins/plugin-security/src/platform-owner-wall-bypass.ts:37-39 | "walled-owner-operator-stamp.ts (plugin-auth) and the elevation gate ask the same parser for the same reason. The sites MUST agree — an account the stamp verifies is one the gate must elevate and the wall must recognise." | "the gate must elevate" describes an action nothing performs any more |
packages/plugins/plugin-security/src/security-plugin.ts:5822 | "the canonical declared-owner email match (the elevation gate's twin, platform-owner-wall-bypass.ts)" | "the twin" of a retired thing |
packages/plugins/plugin-auth/src/last-admin-guard.test.ts:1613 | "deleting it — or calling it something else — un-makes every platform admin in one write" | The same sentence #13661 corrects in the source file, restated in the test file's section header. False for a config-anchored administrator |
packages/plugins/plugin-auth/src/walled-owner-operator-stamp.test.ts (lines 11, 15, 23, 24, 91, 257, 395, 443) | e.g. "a green here IS 'the elevation gate would accept this'" | One test docblock family; the assertions are unaffected, the stated justification is not |
Deliberately NOT on this list
Two sites already read correctly and must not be "fixed":
packages/plugins/plugin-security/src/platform-admin-service.ts:21 — "The standing answer mirrors the DERIVATION, not the retired elevation gate".packages/plugins/plugin-security/src/platform-admin-service.ts:99 — "the same two-spelling discipline the elevation gate used" (past tense).
That split is the point of filing this rather than a blanket search-and-replace: some of these comments are wrong about the mechanism, some are only wrong about the name, and two are already right.
Why it is worth a card
The env.ts site ships in the types package declarations, which is the argument #13661 accepted for email-verified.ts. The rest steer the next author of the platform-admin surface, and #13661 has already demonstrated that a stale reason is the thing a reader reaches for when deciding whether a guard key can be dropped.
Suggested shape
One comment-only PR, no behaviour, verified the same way #13661 was: a non-comment diff that is empty, and a throw census identical before and after. Not urgent; a good rider for whichever leg next edits platform-admin.ts or plugin-security.
Same dead premise as #13661. Context: #11663 (design), #11970 (L2), #11974 (L4).
Generated by Claude Code
Found while implementing #13661 (which corrects four sites in two files). Comment-only drift, no runtime defect — but the same dead premise survives at roughly six more sites the card did not scope, and one of them ships in a package's type declarations.
The dead premise
The #11663 platform-admin re-anchor (legs L2 and L4, both landed) retired the walled platform-admin elevation gate. Under a walled posture
bootstrapPlatformAdminwrites no grant row and elevates nobody — it reports. Standing is derived per request atresolve-authz-context.ts§6b-config, from a config-anchored verified email or the legacy unscoped grant row.Comments that still name "the elevation gate" in the present tense therefore point a reader at a mechanism that no longer exists. Measured on
origin/mainat46b53a25b:packages/types/src/env.ts:169bootstrapPlatformAdmin"PLATFORM_OWNER_EMAIL_ENV, so it ships in@objectstack/types.d.ts— the same reason #13661 singled outemail-verified.tspackages/core/src/security/platform-admin.ts:117sys_userlookup queries the verbatim spelling alongside the normalized one"resolvePlatformAdminStanding; the referent moved, the name did notpackages/core/src/security/platform-admin.ts:287plugin-security/bootstrap-platform-admin.ts) must keep the two halves SEPARATE"bootstrap-platform-admin.tsstill emitswalled_owner_not_registered/walled_owner_not_verifiedas separate answers, so the reasoning is correct and must survive the renamepackages/plugins/plugin-security/src/platform-owner-wall-bypass.ts:37-39walled-owner-operator-stamp.ts(plugin-auth) and the elevation gate ask the same parser for the same reason. The sites MUST agree — an account the stamp verifies is one the gate must elevate and the wall must recognise."packages/plugins/plugin-security/src/security-plugin.ts:5822platform-owner-wall-bypass.ts)"packages/plugins/plugin-auth/src/last-admin-guard.test.ts:1613packages/plugins/plugin-auth/src/walled-owner-operator-stamp.test.ts(lines 11, 15, 23, 24, 91, 257, 395, 443)Deliberately NOT on this list
Two sites already read correctly and must not be "fixed":
packages/plugins/plugin-security/src/platform-admin-service.ts:21— "The standing answer mirrors the DERIVATION, not the retired elevation gate".packages/plugins/plugin-security/src/platform-admin-service.ts:99— "the same two-spelling discipline the elevation gate used" (past tense).That split is the point of filing this rather than a blanket search-and-replace: some of these comments are wrong about the mechanism, some are only wrong about the name, and two are already right.
Why it is worth a card
The
env.tssite ships in the types package declarations, which is the argument #13661 accepted foremail-verified.ts. The rest steer the next author of the platform-admin surface, and #13661 has already demonstrated that a stale reason is the thing a reader reaches for when deciding whether a guard key can be dropped.Suggested shape
One comment-only PR, no behaviour, verified the same way #13661 was: a non-comment diff that is empty, and a
throwcensus identical before and after. Not urgent; a good rider for whichever leg next editsplatform-admin.tsorplugin-security.Same dead premise as #13661. Context: #11663 (design), #11970 (L2), #11974 (L4).
Generated by Claude Code