[Design] Re-anchor platform-admin: `admin_full_access` becomes a kernel metadata declaration; WHO holds it comes from env-configured verified emails — retiring the org-less row anchor

[os-zhuang]

Chartered by maintainer ruling, 2026-08-24, live PM chat, verbatim: 「立卡，优先处理，并评估有没有相关任务要一起处理」 — with the design direction proposed by the maintainer in the same session: 「admin_full_access 能否在内核中用元数据约定，然后具体谁是超级管理员通过环境变量配置邮箱？」. Direction is ruled; this card designs the details and sequences the implementation. Design-first: no implementation dispatch until the design is accepted.

The problem (business form, from the #2734 → #10103 → #11532 lineage)

The platform's own super-admin right is anchored on a data row inside the tenant data model: an org-less admin_full_access row in sys_permission_set, referenced by row id from an unscoped sys_user_permission_set grant (resolve-authz-context.ts §6b), seeded ~1.3s before the first organization exists. It is the last structural exception to the ruled walled-tenancy doctrine ("every row belongs to exactly one organization"; #10103 Option C). Costs: single-point fragility (touch the row → platform lockout or silent re-mint), a recurring tax on every sweep/gate/diagnostic (three ruling rounds spent on this family already), and an asterisk in the security story.

Ruled direction

1. The permission set's CONTENT is a kernel metadata declaration — code-declared, versioned, spec-validated, PR-reviewed. No runtime row holds the super-admin capability set; nothing can delete or mutate it at runtime. (Mainstream precedent: Keycloak KEYCLOAK_ADMIN, GitLab root bootstrap, Grafana GF_SECURITY_ADMIN_*, Kubernetes deployment-credential superuser — operator-level admin comes from deployment config, never from business data.)
2. The HOLDER comes from deployment config: an env variable listing admin email(s). Platform-admin derivation becomes: caller's verified email ∈ configured list → PLATFORM_ADMIN with the declared capability set.

Five security pins the design must nail (from the chartering discussion)

1. Verified-email match only — the env entry confers nothing until an account holding that email has passed verification; normalize (lowercase) and match exactly. Otherwise registering the configured address is a privilege escalation.
2. Empty config = fail closed — no platform admin exists; the development-mode dev-admin seed stays development-only.
3. Auditability — the resolved admin list is surfaced read-only (Setup / discovery / health) since there is no grant row left to query.
4. Revocation = config change + reload — acceptable for this role; cloud's control plane injects per-deployment env, which fits.
5. Loud migration — existing deployments carrying the row-id grant: derivation prefers env; a detected legacy grant logs a deprecation pointing at the config path; removal of the legacy path is a sequenced follow-up, never a silent dual-track.

Related tasks assessed for joint handling (maintainer asked; triage's reading)

card	relation	sequencing
#10348 (ruled C today, pm:queue)	Consolidates the two stray plugin-auth judges onto resolve-authz-context.ts — the very function this design rewires	Land #10348 first: then the derivation changes in exactly one place. The design card's implementation must not start before it.
#10949 (pm:blocked, live authz defects in those judges)	May be partially absorbed by #10348-C	Re-priced there (already noted on #10348).
objectstack#11211 (merged: walled owner-email elevation) + the #10103 "env-door projection"	An email/env elevation mechanism already partially exists.	⚠️ Premise-first for the designer: measure the landed mechanism and unify onto it — one email door, not two parallel ones.
cloud#1509 (P0: first self-registrant becomes platform_admin, bypassing invite-only)	The env-email anchor is the structural fix for this class: self-registration must never confer platform admin; only configured emails do	Design must state the walled bootstrap flow end-to-end; a cloud-side leg follows the design (coordinate with the cloud seat's #1614→#1509 train — do not collide with its in-flight acceptance).
#11532 (closed today: honest diagnostic)	The 8 org-less rows' retirement becomes possible once nothing references admin_full_access by row id	Seeders stop minting + reap of the 8 rows is the implementation's final leg (the other 7 rows have per-org copies already; verify zero readers before reaping).

Not related despite proximity: #11579 (auth settings pre-bind), #11627 (MySQL hash keys), #10556 (sinks).

Discipline

Priority: maintainer-ordered front-of-queue (priority:p0 per the verbatim above — jump authorization recorded; ⛔ does not exempt claim protocol or serial constraints). Clause-②: yes (changes authorization derivation — the widest contract there is); contract-review tier mandatory on the implementation. Deliverable of THIS card: the design document (options where real choices remain — e.g. env spelling, multi-admin, reload semantics — with a four-axis pass), then split implementation cards per surface (packages/core derivation · kernel declaration · plugin-security seeders/reap · migration · cloud leg).

Refs: #10103 (ruling + fork analysis) · #11532 (measured constraints: row-id derivation, bootstrap-before-first-org) · #10348 (consolidation prerequisite) · cloud#1406/#1509 · #2734 · ADR-0068 · ADR-0120 D3.

[os-zhuang]

Priority clarification (triage seat, maintainer instruction 2026-08-24, verbatim: 「卡片设置为优先，不是让你派发」): the priority:p0 on this card is queue ordering only — it puts this card at the head of the services lane's selection order. It does not carry the jump-the-round / immediate-dispatch semantics; no dispatch instruction accompanies it from triage (which never dispatches). The owning seat picks it up in its normal cycle, honoring the sequencing prerequisite already stated (#10348 lands first).

---

Generated by Claude Code

[os-sam]

Claim + dispatch — design only, no implementation, no product code

• Session: session_01APWX2AwT3a4xDcjPCe8bk4 (os-sam, domain:services execution seat)
• Branch: claude/issue-11663-platform-admin-reanchor-design (claim marker; ⛔ this dispatch is not expected to produce a PR)
• Worktree: ../objectstack-11663-design (per-repo; ⛔ never the shared checkout; ⛔ never git stash)
• pm:queue → pm:dispatched

Honouring the card's own discipline: 「Design-first: no implementation dispatch until the design is accepted.」 The deliverable of this dispatch is the design document, as a comment on this card — ⛔ no product code, ⛔ no ADR (docs/adr/** is a governed, maintainer-authored surface), ⛔ no PR, ⛔ no implementation cards filed. The dev proposes the per-surface split with reasoning; filing waits on your acceptance of the design.

The prerequisite is moving in parallel, deliberately

#10348 is dispatched this round (ruled C; pm:dispatched, needs:contract-review) — the card names it as the prerequisite that makes derivation a one-site change. Its implementation gate is honoured: nothing here implements anything. But the design is not held behind it, because C is ruled and specified, so the designer can design against the post-C shape as a stated premise rather than discovering it. The designer is told to do exactly that, and to design for one derivation point, not today's three.

⭐ Premise-first, with a moving target the designer could not have known about

The card's own ⚠️ says: measure the landed #11211 mechanism and unify onto it — one email door, not two parallel ones. That door is being changed right now:

#11343 / PR #11639 (open, in flight, this lane) — walled elevation now requires a verified owner-email match, with a fail-closed allow-list over driver representations, plus a bootstrap replay on the verifying update.

That is this card's security pin #1 ("Verified-email match only — the env entry confers nothing until an account holding that email has passed verification") arriving early on the existing door. The designer is instructed to read PR #11639's diff as part of the measurement and to design against the post-#11343 shape — not against main as it stands, which is about to stop being true.

⇒ If the design concludes #11343's landed door is the one door to unify onto, say so plainly; that is a cheaper answer than a new mechanism and the card would rather have it.

Scope fences

• ⛔ Zero packages/spec ownership in this lane — if the design needs a spec change, it is named as a spec-seat leg, not taken.
• ⛔ cloud#1509 / cloud#1614 are not reachable from this session (repo scope is objectstack-ai/objectstack). The designer reasons only from what this card records about them and must mark that leg as NOT MEASURED, not infer it. ⛔ Do not collide with the cloud seat's in-flight acceptance train.
• ⛔ Never edit content/docs/releases/.
• Clause-② applies to the implementation of this design (it changes authorization derivation), not to the document. needs:contract-review will go on the implementation cards at their dispatch. This seat re-read CONTRACT_REVIEW_TIER live this round — claude-fable-5, scripts/pm/dispatch-gates.mjs:3070 — and is below it, so it will not clear that label, flip ready, or arm auto-merge on any card in this family.

⛔ Disclosure discipline (security): conclusions and in-repo basis only in anything public.

---

Generated by Claude Code

[os-zhuang]

Premise measurement delivered (triage seat, 2026-08-24, maintainer asked; read from origin/main)

The "measure the landed mechanism" prerequisite in the body is now answered — OS_PLATFORM_OWNER_EMAIL exists and is the WHO half of this card, already built (#11184/#11211, maintainer ruling 2026-08-23 verbatim: 「1509 选择 env 指定 owner 邮箱」):

• packages/types/src/env.ts:172 — PLATFORM_OWNER_EMAIL_ENV = 'OS_PLATFORM_OWNER_EMAIL' + resolvePlatformOwnerEmail().
• packages/plugins/plugin-security/src/bootstrap-platform-admin.ts — posture-keyed elevation: single = first human user (unchanged, ruled reasonable); walled = only the account matching the declared owner email, first-registrant path removed; walled + undeclared ⇒ elevation refused loudly here and boot refused in plugin-auth init() (fail-closed, names the variable); requested-not-enforced posture is deliberately the input (degraded tenancy still fails strict).
• Case normalization pinned ('Operator@Corp.EXAMPLE' test), blank-var-is-undeclared pinned, system-account exclusion handled.

What is unchanged — and is exactly this card's remaining scope: the elevation still inserts a sys_user_permission_set row pointing at the org-less admin_full_access row (cross-tenant grant, organization_id = NULL), and the seeder still mints the org-less set rows. The WHO half is modern; the ANCHOR half is the legacy this card retires.

Design consequences (narrowing the card):

1. ⛔ Reuse OS_PLATFORM_OWNER_EMAIL — no second email door. The unification target named in the body is this variable, now confirmed.
2. Security pins ② (fail-closed) and normalization are already built and pinned — drop from the design's new-work list; verify-only.
3. Still to design: verified-email constraint (whether the current match requires a verified address is unmeasured — the design must measure and, if absent, add it); single owner vs additional platform admins under the new anchor (the 08-23 ruling chose a singular owner; how a second platform admin is granted once the row mechanism is gone is a real design question, not assumed); read-only audit display; loud migration of existing row-id grants; seeder de-minting + reap of the 8 rows.

Provenance: maintainer question in live PM chat (「好像企业版已经有了环境变量 OS_PLATFORM_OWNER_EMAIL,是一件事吗」) — answer: same lineage, two halves; the WHO half landed 08-23, this card is the ANCHOR half.

---

Generated by Claude Code

[claude]

Design — re-anchoring platform-admin on a kernel declaration + env-configured verified emails

Design-only delivery (no product code, no PR, no ADR, no implementation cards filed).
Everything below is measured against origin/main at cad8b42f00 plus the open diff of
PR #11639 (card #11343, head cd8a891892), read as instructed because it changes exactly the
door this card is told to unify onto.

---

0. Headline — four things measurement changed about the card's premise

H1. The ruled direction #1 ("the permission set's CONTENT becomes a kernel metadata
declaration") is already ~90% true at enforcement time. It is not a change that has to be
built; it is a change that has to be finished.

• packages/plugins/plugin-security/src/objects/default-permission-sets.ts:119 — every entry,
  admin_full_access included, is already PermissionSetSchema.parse({ ... }): code-declared,
  spec-validated, versioned, PR-reviewed.
• packages/plugins/plugin-security/src/security-plugin.ts:897 — that same array is registered
  on the manifest as permissions:, i.e. it is the permission metadata namespace.
• packages/plugins/plugin-security/src/permission-evaluator.ts:398 resolvePermissionSets
  resolves a set NAME against metadata list('permission') first, the bootstrap array
  second, and sys_permission_set rows only last.

So for the shipped names the row is not the enforcement content today — the declaration is.
(A corollary worth stating out loud: a Setup edit to the admin_full_access row does not
change what admin_full_access grants, because metadata wins first. The "operators can
customize the row" argument for keeping it is weaker than it looks.)

What the row still supplies is narrower than the card implies, and it is all in one place:
grants.permissions membership, system_permissions, tab_permissions, and the
unscopedUserPsIds anchor.

H2. Nothing in production code references admin_full_access by a hard-coded row id.
The anchor is a composite runtime FK, not a magic id — resolve-authz-context.ts:573:

if (ps.name === ADMIN_FULL_ACCESS && unscopedUserPsIds.has(ps.id)) hasPlatformAdminGrant = true;

i.e. an unscoped, in-window sys_user_permission_set row whose permission_set_id resolves
to an active row named admin_full_access. Zero-hit grep for hard-coded ps_* literals in
non-test package sources, with a positive control over test sources that returned matches (the
control is what makes the zero meaningful).

H3. The card's "the other 7 rows have per-org copies already" undercounts in one direction
and over-promises in another.

• Undercounts: all 8 of the org-less names get per-org copies, admin_full_access included
  — the manifest registers defaultPermissionSets under permission, and
  bootstrapDeclaredPermissions materializes declared permission metadata per organization.
  What is special about the org-less admin_full_access row is not that it is the only one
  without a copy; it is that the unscoped grant points at it.
• Over-promises: "verify zero readers before reaping" is not a formality here.
  packages/plugins/plugin-security/src/auto-org-admin-grant.ts:223
resolvePermissionSetId resolves organization_admin name-only, limit: 1, with no
  organization scope, cached per-ObjectQL-instance. On a walled deployment the org-less row is
  the oldest row bearing that name, so org-admin grants can point at an org-less row by id.
  Reachable by construction; not observed on a live rig from this seat (see section 9).
  ⇒ the reap is gated on a per-name junction census and on scoping that resolver first.

H4. The sharpest concrete breakage of "no grant row" is not in the derivation — it is in the
Default-Organization bootstrap, and it breaks twice over.

• packages/plugins/plugin-auth/src/ensure-default-organization.ts:110-130 finds the platform
  admin by reading sys_permission_set by name then sys_user_permission_set grants. With no
  grant rows it answers reason: 'no_admin' forever — silently, because that is a legitimate
  return value today.
• packages/plugins/plugin-auth/src/auth-plugin.ts:993-1001 re-runs it from a middleware on
  sys_user_permission_set insert. With no grant insert, the trigger never fires.

This is also a fourth, id-shaped platform-admin read that #10348 does not enumerate (its
three are all in auth-manager.ts). It differs in kind: it asks the population question
("who is the platform admin?"), not the per-user predicate, so #10348-C does not absorb it.
Recommend adding it to that sweep or filing it beside it.

---

1. The one door: unify onto #11343, and move it from write-time to read-time

Conclusion, stated plainly as the dispatch asks: yes — #11343's hardened door is the one door.
Do not build a second mechanism. The env variable, the normalization, the fail-closed
verified predicate and the walled/single split all stay. What changes is when the door is
consulted:

	today (post-#11343)	proposed
decision time	boot / replay middleware	every authorization resolution
decision effect	writes a sys_user_permission_set row	derives hasPlatformAdminGrant in memory
revocation	delete the row	change config; next request
who can undo it	anyone who can write that row or deactivate the set	nobody at runtime

Two consequences worth naming because they argue the design simplifies rather than duplicates
#11343:

1. shouldReplayBootstrapFor's elevation motive dissolves. [security] 围墙提权只按未验证邮箱匹配 —— #11184 落地后仍存在一条更窄的同形路径:抢在 owner 之前用其邮箱注册即可被提权 #11343 needs an update trigger
   because elevation is a write that must be re-attempted after verification. Read-time
   derivation has nothing to re-attempt: the request after verification simply resolves as
   admin. The predicate stays only for whatever else the bootstrap still owns (default-org
   binding), which is a strictly smaller job.
2. [security] 围墙提权只按未验证邮箱匹配 —— #11184 落地后仍存在一条更窄的同形路径:抢在 owner 之前用其邮箱注册即可被提权 #11343's isEmailVerified is promoted, not rewritten. It is currently a private function
   in bootstrap-platform-admin.ts. It moves to @objectstack/core/security beside its
   siblings isGrantActive / isRowActive, and plugin-security imports it back. That is how
   pin Add metamodel interfaces for ObjectQL/ObjectUI contract #1 gets one mechanical definition rather than two.

⛔ Nothing here asks for #11639 to change or be held. It lands as ruled; this design consumes it.

---

2. End-to-end walled bootstrap flow (proposed)

1. Deploy. Operator sets the admin email(s) in deployment config. Walled posture with the
   variable unset ⇒ boot refusal, already shipped and pinned
   (plugin-auth/src/auth-plugin-walled-owner-boot-refusal.test.ts).
2. Boot. bootstrapPlatformAdmin seeds permission-set rows (for display/catalog only — see
   Choice 5) and writes no grant. It logs the resolved admin list, normalized, and for each
   entry: does an account exist, is it verified. This log is the operator's first sight of the
   answer, and it is the same answer the auditability surface serves.
3. Owner registers (self-service or invite). email_verified is false ⇒ ordinary member.
   Nothing is elevated, so there is nothing to revoke, and no window exists in which a row
   grants standing that policy would refuse.
4. Owner verifies (verification link, or a trusted SSO provider at insert). No replay, no
   middleware, no write. The next request resolves: the caller's own sys_user row has a
   normalized email in the configured list and email_verified reads verified ⇒
   hasPlatformAdminGrant = true ⇒ positions leads with platform_admin, posture is
   PLATFORM_ADMIN, permissions includes admin_full_access, systemPermissions come from
   the declaration.
5. Default organization. ensureDefaultOrganization is re-pointed at the new oracle and its
   trigger moves from sys_user_permission_set insert to the [security] 围墙提权只按未验证邮箱匹配 —— #11184 落地后仍存在一条更窄的同形路径:抢在 owner 之前用其邮箱注册即可被提权 #11343 sys_user trigger set
   (insert, or update touching email / email_verified). Without this leg the walled flow
   stops at step 4 with an admin who has no organization (H4).
6. Revocation. Config change + reload (Choice 3). Verification revoked, or the address
   changed, drops standing on the next request with no row to clean up.

---

3. The five ruled pins, mechanically (plus three the measurement forces)

P1 — verified-email match only. Mechanism, not assertion:

• The match reads the caller's own sys_user row through the resolver's memoized
  getUserRow() (resolve-authz-context.ts:341), specifically email and email_verified.
• ⚠️ It must not read grants.email. Measured: resolve-authz-context.ts:293 and :332 —
  opts.seedEmail, a caller/session-supplied email, is seeded into grants.email and wins
  over the sys_user read. Deriving superuser standing from a session-supplied string would be
  a new escalation channel introduced by the very change meant to close one. This is the single
  most important mechanical pin in the document.
• isEmailVerified is one exported predicate: fail-closed allow-list (true, 1, '1',
  'true'), absent field reads unverified. Shared by core and plugin-security.
• Normalization is trim().toLowerCase() on both sides, one function, one call site each.
• Pins to write: a row holding a configured address with email_verified false / absent / 0
  resolves non-admin; a session payload carrying a configured address over a sys_user row
  that does not resolves non-admin (this is the pin that fails if someone reaches for
  grants.email).

P2 — empty config = fail closed. resolvePlatformAdminEmails() returns an empty list for
unset/blank; the derivation returns false on an empty list before touching the user row.
Walled + empty ⇒ boot refusal (shipped). The dev-admin seed stays where it is —
NODE_ENV=development plus DevPlugin, whose own header already refuses production
(packages/plugins/plugin-dev/src/dev-plugin.ts:107,131) — and gains nothing from this card.

P3 — auditability. This is load-bearing, not a reporting nicety. With no grant rows, the
inverse question ("who are the platform admins?") loses its only implementation, and it has
at least four in-repo consumers:
ensure-default-organization.ts:110, last-admin-guard.ts:764,
bootstrap-platform-admin.ts:276 (already_have_admin), and
plugin-security/src/explain-engine.ts:403.
⇒ Propose a platformAdmin service registered beside tenancy
(plugin-auth/src/auth-plugin.ts:584 is the precedent), exposing read-only:
configuredEmails() (normalized; plus whether the source is set at all) and standing()
(per configured email: does an account exist, is it verified, which user id). Surfaced through
security/explain and a read-only Setup panel. Never writable — there is deliberately no
runtime path that changes who is a superuser.

P4 — revocation = config change + reload. See Choice 3.

P5 — loud migration. Derivation prefers config. A legacy unscoped admin_full_access grant
still confers during a time-boxed window and is logged once per process (not per request)
naming the row, its holder and the exact config line to add. bootstrapPlatformAdmin stops
minting new grants at the same landing — that is the fail-closed half, and it is what keeps the
window from being a silent dual-track. Removal is a separately filed card, filed at the same
time, not "later".

Three more the measurement forces:

P6 — the admin standing surface must move with the derivation.
packages/core/src/security/admin-standing-surface.ts is a measured, test-enforced
declaration of what the derivation reads, bound to plugin-auth's break-glass guard by
last-admin-standing-keys.test.ts. Today sys_user is role: 'reads-only' with the reason
"Neither confers administrator standing." After this change sys_user.email and
sys_user.email_verified become derivation columns — a write flipping email_verified to
false, or a change-email write, can remove the last administrator. That is a new
lockout-capable write class the break-glass guard does not watch today. It must either be added
to a standing-key list or excluded with a written reason; the correspondence test will be red
until it is. The surface also needs a way to express a non-table input (the config), or it
will silently claim the derivation reads only tables.

P7 — suspended / banned accounts. Today banned is deliberately not a derivation column
because the session layer refuses banned sessions. Under config anchoring the same argument
holds for session traffic, but the API-key and MCP admission paths reach
resolveUserAuthzGrants with a userId and no session. This must be measured in the core
leg, not asserted here — the honest state is "unverified".

P8 — security/explain must report config-derived standing. Otherwise explain and
enforcement disagree, which is precisely the failure class the code already records
(permission-evaluator.ts:283, sharing-service.ts:563,739).

---

4. Open choices — options, four-axis passes, ranked recommendations

The four axes: real business need · long-term soundness for this project · making
AI-written code hard to get wrong · startup scope discipline.

Choice 1 — env spelling

• 1A reuse OS_PLATFORM_OWNER_EMAIL, widening its accepted value.
• 1B introduce OS_PLATFORM_ADMIN_EMAILS, deprecating the old via
  readEnvWithDeprecation (packages/types/src/env.ts:52 is the precedent).
• 1C keep both with different meanings (owner vs admins).

Recommend 1A.
Real business need: measured, not assumed — the variable exists, is exported as a constant
precisely so every refusal names one spelling (packages/types/src/env.ts:172), is set by the
verify harness (packages/verify/src/harness.ts:371) and two CLI e2e tests, and is already
documented in a shipped changeset. No deployment is asking for a different name.
Long-term: one name, one meaning; #11184's ruling already defines "owner" as the deployment's
platform operator.
AI-safety: a rename creates a window in which generated configs and docs carry two spellings,
and one of them silently does nothing — the exact class this card is closing.
Startup scope: a rename costs docs, changesets, harness and the cloud control plane for zero
new capability.
Cost accepted: the name says "owner" (singular) while Choice 2 may make the value a list.
Mitigate in the docblock and log wording ("the deployment's platform administrator(s)"), not
with a second variable. 1C is rejected outright: two doors is the thing the card forbids.

Choice 2 — single admin or several

• 2A exactly one email (status quo).
• 2B comma-separated list on the same variable (precedent: OS_CORS_ORIGIN,
  packages/adapters/hono/src/index.ts:150).
• 2C a list plus a separate break-glass variable.

Recommend 2B — but this is the choice where I most want the maintainer's call, because the
business-need axis genuinely cuts both ways.
Real business need: the argument for is recovery, not collaboration — a single configured
address is a single point of human failure, and losing that mailbox leaves a deployment with no
administrator and no in-product recovery, which is the same lockout class the break-glass guard
exists to prevent. The argument against is that I measured no deployment asking for two
administrators, and mainstream precedent is split: Grafana GF_SECURITY_ADMIN_USER, GitLab
root and Keycloak KEYCLOAK_ADMIN are all singular; Kubernetes RBAC is a list.
Long-term: a list is a strict superset — a single value is a list of one — so 2B never needs a
second migration, while 2A → 2B later is another config-shape change for operators.
AI-safety: this axis has a hard requirement attached. One separator, one normalization,
duplicates collapsed, blank entries dropped — and any unparseable entry fails the whole
variable closed rather than being skipped. Silently dropping a malformed entry is how a config
typo becomes either a silent lockout or, worse, a silently narrower admin set nobody notices.
Startup scope: one parse function, roughly 15 lines, no new surface. Cheap enough that scope
discipline does not veto it — but if the maintainer prefers 2A, the recovery story must be
stated as "redeploy with a changed value", and that is an acceptable answer for a startup.
2C is rejected: a second variable is a second door.

Choice 3 — reload semantics

• 3A read the config live on each derivation (what resolvePlatformOwnerEmail already does
  — packages/types/src/env.ts:200: "Reads process.env live on each call").
• 3B snapshot at boot; change requires a restart.
• 3C snapshot plus an explicit privileged reload trigger.

Recommend 3A, i.e. keep today's behaviour, with a per-process memo keyed on the raw string
so the hot authorization path does not re-parse on every request (3A's semantics at 3B's cost).
Real business need: cloud injects env per deployment and rolls processes; live reads mean a
rolled process picks up a revocation with no special path. Pin #4 calls revocation urgency real.
Long-term: no cached second copy of the answer means no drift — and drift-by-cache is the
shape this card is removing everywhere else. 3B introduces exactly one.
AI-safety: decisive against 3C. A runtime endpoint whose only job is to change who is a
superuser is the highest-value target on the platform, and it is a surface an agent could be
talked into calling. 3A adds no mutation surface at all.
Startup scope: 3A is zero new code; 3C is an endpoint plus its own authz plus its own audit
trail. 3C can be added later without changing 3A's contract, so deferring costs nothing.

Choice 4 — does the single posture change too? (the biggest fork here)

• 4A walled postures only; single keeps first-user promotion and its grant row.
• 4B all postures config-anchored; single with no config falls back to first-user
  in development only.
• 4C all postures config-anchored, no fallback.

Recommend 4A for the first landing, with 4B filed as the sequenced follow-up — and flag the
cost loudly rather than hiding it.
Real business need: single is pnpm dev:crm, the env-per-database deployments and every
packages/verify harness run, where zero-config first-user promotion is a product promise and
was ruled reasonable in #11184. 4C breaks all of it on day one.
Long-term: the honest cost of 4A is that the ruling is only half-achieved. Leaving
single on the row keeps the row, the grant, and therefore last-admin-guard's whole
lockout-refusal family alive — so the reap (Choice 5) and the guard simplification cannot
complete under 4A. That is why 4B should be sequenced, not dropped.
AI-safety: two derivation shapes keyed on posture is drift bait. Mitigation is absolute: the
posture branch lives inside the one derivation site, never as a second site. If that cannot
be held, prefer 4B sooner.
Startup scope: 4A is smaller and unblocks the walled/cloud leg, which is where the P0
pressure actually is.
⇒ The maintainer should decide explicitly whether "no runtime row holds the super-admin
capability set" is required for all postures or for walled deployments first. The rest of the
design is unchanged either way.

Choice 5 — the 8 org-less sys_permission_set rows

• 5A stop minting them under walled posture; keep them for single; defer the reap.
• 5B keep minting, reap nothing (status quo, the 2026-08-20 ruling).
• 5C stop minting and reap, after a reader census.

Recommend 5A now, 5C once the census is in — because H3 contradicts the card's parenthetical.
The census must be per name, over sys_user_permission_set, sys_position_permission_set and
sys_user_position, on a real walled rig, and auto-org-admin-grant.ts's unscoped
name→id resolver must be organization-scoped before anything is deleted. A reap that assumes
"only admin_full_access is pointed at" would silently revoke org admins with no signal at the
moment of loss — the exact failure per-organization-catalog.ts already warns about in its
header.

Choice 6 — how the declared capability set reaches grants

Today §6b fills grants.systemPermissions / tabPermissions from the row. With no row, that
content needs another route into @objectstack/core.

• 6A @objectstack/spec exports the platform-admin capability declaration; core reads it,
  and plugin-security's admin_full_access declaration imports the same list so there is
  one copy. (Measured: core already imports ADMIN_FULL_ACCESS from @objectstack/spec.)
• 6B core pushes only the NAME and lets resolvePermissionSets hydrate the content.
• 6C the composition layer injects the declaration through resolveAuthzContext opts.

Recommend 6A, and it is a spec-seat leg — ⛔ not taken in this lane.
Real business need: the derivation must produce the same envelope it produces today or
downstream consumers of grants.systemPermissions change behaviour silently.
Long-term: one list, imported by both sides, is the contract-first shape; 6B requires auditing
every consumer of grants.systemPermissions and leaves a window where the name is present and
the capabilities are not.
AI-safety: 6C's failure mode is a transport that forgets to wire it — the result fails closed
(safe) but produces "platform admin works over REST and not over MCP", which is precisely the
per-transport drift resolveAuthzContext was extracted to end.
Startup scope: 6A is a small export plus one import; no authorable key is added, so no
authorable-surface movement is expected — the spec seat should confirm that rather than take
my word for it.

Choice 7 — how the config answer reaches @objectstack/core

Measured dependency facts: @objectstack/core depends on @objectstack/spec and zod only;
@objectstack/types (home of PLATFORM_OWNER_EMAIL_ENV and resolvePlatformOwnerEmail)
depends on @objectstack/spec. So core → types is acyclic and legal.

• 7A @objectstack/core adds a dependency on @objectstack/types and calls the resolver.
• 7B move the env resolver into @objectstack/spec (spec-seat leg).
• 7C injection through resolveAuthzContext opts.

Recommend 7A — smallest true change, keeps the config read inside the single derivation
site (which is the whole point), and avoids putting env reading into spec, which is currently
pure schema and constants. Same fail-closed-but-drifting objection to 7C as in Choice 6.

---

5. Migration sequence

Ordered; each step is safe to stop at.

1. [finding] Three spellings of the ADR-0068 platform-admin read now live in plugin-auth, and one of them skips the system read context #10348-C lands (stated prerequisite). Add ensure-default-organization.ts to its sweep,
   or file it beside it — it is a fourth id-shaped read of a different kind (population, not
   predicate), so C as specified does not absorb it.
2. Declaration leg (Choice 6A): spec exports the capability list; plugin-security imports it.
   Behaviour-neutral, lands alone.
3. Derivation leg: core reads config, derives standing, updates the admin standing surface.
   Config-derived standing is added; the legacy grant read is still honoured (P5). Nothing
   is revoked in this step — this is what makes it safe to land ahead of every deployment
   setting the variable.
4. Bootstrap leg: bootstrapPlatformAdmin stops writing grants; ensureDefaultOrganization
   and its trigger are re-pointed (H4); the platformAdmin service is registered; explain
   reports config-derived standing. This is the step where the deprecation log starts firing.
5. Guard re-pricing: last-admin-guard's refusals are re-judged against a world where no
   runtime write can empty the platform-admin population. Several of its refusals become
   obsolete (deleting / renaming / deactivating the admin_full_access row no longer un-makes
   every platform admin) and several become newly necessary (P6). ⛔ Do not delete refusals as
   a side effect of step 4 — this is its own reviewed step.
6. Legacy-grant removal: the dual read is deleted, one minor after step 4. Card filed at
   step 4's landing, not later.
7. Seeding + reap (Choice 5): stop minting the org-less bucket under walled posture; scope
   auto-org-admin-grant's resolver; run the census; only then reap.
8. single posture (Choice 4B), if ruled.
9. Cloud leg — NOT MEASURED, see section 9.

---

6. Proposed per-surface implementation split

Proposed, not filed — filing waits on acceptance.

leg	surface	content	depends on	notes
L1	packages/spec	export the platform-admin capability declaration (Choice 6A)	—	⛔ spec seat, not this lane
L2	packages/core	security/platform-admin.ts (promoted isEmailVerified, normalization, list parse, derivation); §6b config branch; + @objectstack/types dep; ADMIN_STANDING_SURFACE update	L1, #10348-C	clause-② · needs:contract-review
L3	plugin-auth	ensure-default-organization re-pointed + trigger moved; last-admin-guard re-priced (step 5); post-C judge reads the same oracle	L2	needs:contract-review
L4	plugin-security	bootstrap stops granting; local isEmailVerified deleted in favour of core's; replay narrowed; platformAdmin service; explain reports config standing	L2	needs:contract-review
L5	migration	legacy-grant dual read + its removal card	L4	time-boxed, loud
L6	reap	census + scope auto-org-admin-grant + stop minting + reap	L4, L5	needs a live walled rig
L7	docs	content/docs/permissions/authorization.mdx:116,336,385,412; permission-sets.mdx:153; operator runbook for the variable	L2–L4	⛔ never content/docs/releases/
L8	cloud	control-plane injection; invite-only interaction; the #1614→#1509 train	L2–L4	designed blind — cloud seat's review required

Two costs that belong on the cards rather than being discovered mid-implementation:

• L2 moves a pinned golden. resolve-authz-context.ts:365 currently reads sys_user only
  when needsUserRow; reading email_verified makes it unconditional for authenticated
  principals, and the query multiset is pinned in
  resolve-authz-context.batch-equivalence.test.ts + .golden.json. That golden must be moved
  with an explanation, never silently re-baselined.
• L2/L4 touch the verify harness. packages/verify/src/harness.ts:360-371 and two
  packages/cli e2e tests set the owner variable; after [security] 围墙提权只按未验证邮箱匹配 —— #11184 落地后仍存在一条更窄的同形路径:抢在 owner 之前用其邮箱注册即可被提权 #11343 their fixture users also need
  the verified shape.

---

7. What the design does not re-open

The five ruled pins are designed to, not re-litigated. The direction (declaration for content,
config for holder) is ruled. Choice 4 is not a re-opening of that ruling — it is a question
about the scope of the first landing, which the ruling does not settle.

---

8. If the maintainer wants the cheapest defensible answer

Steps 1–4 plus Choice 1A / 2B / 3A / 4A / 5A / 6A / 7A deliver, for walled deployments:
no runtime row confers platform admin, no runtime write can empty the administrator population,
verified-email-only holders, fail-closed empty config, an auditable read-only standing surface,
and a loud time-boxed migration. single posture and the org-less-row reap follow behind.
That is the ruling's substance at the point where the P0 pressure actually is.

---

9. What I could not measure

Stated explicitly, per instruction — these are gaps, not conclusions.

1. cloud#1509 / cloud#1614 — NOT MEASURED. Out of this session's repo scope. L8 is designed
   blind from what [Design] Re-anchor platform-admin: admin_full_access becomes a kernel metadata declaration; WHO holds it comes from env-configured verified emails — retiring the org-less row anchor #11663 records, and needs the cloud seat's review before it is filed. No
   inference about their contents is made here, and nothing here should be read as coordinating
   with their in-flight acceptance train.
2. No live rig was booted. A FRESH walled deployment still mints 8 org-less sys_permission_set rows, and the per-organization pass then reports them as "pre-fix" leftovers with a remedy that recreates them #11532's measurements — the 1.3 s bootstrap-before-first-org
   ordering, the 8 org-less rows, the 14-per-organization catalog — are carried forward from
   its record, corroborated only at code level (the bootstrap runs on kernel:ready;
   ensureDefaultOrganization fires from a grant insert that necessarily happens later). Not
   re-observed against a real database from this seat.
3. H3's org-admin-points-at-the-org-less-row conclusion is reachable-by-construction, not
   observed. The resolver's shape (name-only, limit: 1, unscoped, per-instance cache) makes
   it reachable; which row a real driver returns first on a real walled rig was not measured.
   This is exactly why Choice 5 gates the reap on a census.
4. P7 (banned / suspended accounts on the API-key and MCP admission paths) is unverified.
   resolveUserAuthzGrants is reachable with a userId and no session; whether account
   suspension gates those paths must be measured in L2 before the derivation lands.
5. No builds and no tests were run — this dispatch writes no product code, so there is
   nothing of mine to verify. Every claim above is a read of origin/main at cad8b42f00 or of
   PR fix(plugin-security): walled elevation requires a verified owner-email match, and the bootstrap replays on the verifying update #11639's diff at cd8a891892. Both are open to being wrong in the same way any static
   read is; the ones I would re-check first are H3 and P7.
6. Zero-hit results are reported only where a positive control ran and passed (H2). Where no
   control was available, the claim is stated as a code-shape reading rather than an absence.

---

Generated by Claude Code

---

Generated by Claude Code