platform-admin re-anchor (L5 removal half): delete the legacy grant-row read — one minor after L4's landing

[os-steve]

The removal half of L5 of the accepted #11663 platform-admin re-anchor design, filed at L4's landing exactly as #11975 and the design prescribe (design document = #11663 comment 5394453215, §5 step 6 and §6 row L5: "the dual read is deleted, one minor after step 4. Card filed at step 4's landing, not later"; maintainer acceptance = #11663 comment 5404675670, 2026-08-25, verbatim 「接受你的建议，继续」). Filed by the L4 dev at PR #13514's creation, per the L4 card's own definition of done. #11975 remains open and carries the window's discipline; this card is the window's EXIT.

Blocked-by: #11975

Timing constraint (the minor boundary): lands one minor after the release that carries L4 (PR #13514, @objectstack/plugin-security walled bootstrap stops minting the grant row + deprecation pointer live). The exit PR's body must name the minor boundary it honours (#11975's acceptance criterion).

Content — delete the legacy path, as its own reviewed change (never a rider on another leg):

• packages/core/src/security/resolve-authz-context.ts §6b: the legacy arm that flips hasPlatformAdminGrant from an unscoped, in-window admin_full_access USER grant row stops conferring PLATFORM_ADMIN — after this card, only the §6b-config anchor confers it (walled AND single postures per whatever state platform-admin re-anchor follow-up (Choice 4B): config-anchor the single posture — first-user promotion becomes development-only fallback #11979 / Choice 4B is in at that time; if 4B has not landed, the single posture's row-derived standing must be carved out explicitly, not deleted with the window).
• reportLegacyPlatformAdminGrant and its boot-side detection in plugin-security/bootstrap-platform-admin.ts retire with the read they warn about (the pointer's job is done when the row confers nothing).
• Re-derive the readers at that time: last-admin-guard (re-priced by L3 platform-admin re-anchor L3 (plugin-auth): re-point ensure-default-organization; re-price last-admin-guard as its own reviewed step #11973), explain provenance, the standing surface — none may silently change answer for single-posture rigs.

Acceptance criterion: on a walled rig, a seeded legacy org-less admin_full_access grant confers NOTHING (posture resolves without PLATFORM_ADMIN unless the config anchor matches); the exit is a reviewed change on origin/main whose PR body names the minor boundary; single-posture first-user standing is unchanged unless #11979 landed first.

---

Generated by Claude Code

[os-steve]

The minor boundary this card must honour: land no earlier than 17.4.0

Established on #11975 (the window's discipline card, this card's Blocked-by: target) and recorded here because this card's acceptance criterion requires its PR body to name the boundary. Measured on origin/main at 5364d2e5e, not recalled.

fact	evidence
latest released minor	@objectstack/plugin-security@17.2.0 and @objectstack/core@17.2.0, tag commit e7d2cc67f, 2026-08-23
L4's landing	b9972720f (PR #13514), 2026-08-31 — git merge-base --is-ancestor b9972720f '@objectstack/plugin-security@17.2.0^{commit}' is false, so L4 is not in 17.2.0
L4's bump, still unconsumed	.changeset/walled-bootstrap-stops-granting.md is present on main and declares "@objectstack/plugin-security": minor
no major pending	grep -l '": major' .changeset/*.md matches 0 files out of 528 pending changesets, so the next release is a minor, not 18.0.0
L2 rides the same train	the core-side config anchor landed 2026-08-30, also after the tag

⇒ L4 ships in 17.3.0. "One minor after L4's landing" therefore means this card's PR must not ride the 17.3.0 release train — it may be cut only once 17.3.0 is tagged, landing in 17.4.0.

⚠️ The boundary is anchored to the release that carries L4, not to a date. If the next release is cut as something other than 17.3.0 (an rc line, or a major ruled between now and then), re-derive rather than reusing the literal 17.4.0 — the rule is "the minor after whichever release consumed walled-bootstrap-stops-granting.md".

Two readings from #11975 that change what this card has to do

1. The entry half is complete and correctly disciplined. All three disciplines were measured against the tree: derivation prefers env (precedence, not exclusion — the ruled additive shape of design §5 step 3); the deprecation pointer's latch is module-scope, so "once per process" and "every boot" coincide and a restart re-announces (measured over three fresh module instances: 1 line each); and no silent dual-track path was found — hasPlatformAdminGrant is written in exactly two places and consumed once by derivePosture, with no third route to PLATFORM_ADMIN. Details and evidence are in test(core): pin that the legacy platform-admin deprecation latch dies with the process (L5) #13666.

2. The single-posture carve-out this card already anticipates has a live symptom today, filed as [finding] The #11663 P5 legacy-grant deprecation pointer fires on single-posture rigs, where ruled Choice 4A says the row is NOT going away #13667: the request-side pointer is posture-independent, so single rigs — the default posture — already receive a deprecation notice telling them their first-user promotion row "is removed in a later release", which under ruled Choice 4A is not true for them. Worth reading before this card's re-derivation of last-admin-guard, explain provenance and the standing surface, because it is the same seam: the boot-side detector is posture-gated and the request-side one is not.

---

Generated by Claude Code