Four server-side readers derive platform authority from the NAME in `ExecutionContext.positions` — same species as #15948's blocked escalation, and already reachable on `main`

[os-warren]

The four sites

Each derives platform-admin authority from a name in ExecutionContext.positions rather than from the capability rung:

file	line
packages/plugins/plugin-sharing/src/sharing-rule-service.ts	:254
packages/plugins/plugin-approvals/src/approval-service.ts	:976
packages/runtime/src/domains/activation-gate.ts	:149
packages/plugins/plugin-security/src/explain-engine.ts	:117

⚠️ These are pre-existing and reachable on main today. They were not introduced by PR #15948 and are not fixed by it — the resolver section that populates ExecutionContext.positions is untouched by that PR. ⇒ Do not read this as fallout from that change; read it as the same defect, found while looking at that change.

Why this is the same species as a blocked escalation

PR #15948 was failed in Clause-② review for deriving isPlatformAdmin as an array-name read. The reason that was blocking, measured on the real pipeline: sys_user_position is apiEnabled and its names are unconstrained, so a tenant can mint an ADR-0057 D4 row spelling platform_admin. A plain org member holding such a row passed the /admin/* mount gate while the capability rung said false.

Core's own resolver states the rule, at resolve-authz-context.ts:1125-1129:

Read the RUNG — never positions.includes(...); an ADR-0057 D4 sys_user_position row may spell that very name.

⛔ That is a comment, not a gate. It did not stop the one PR #15948 nearly shipped, and it has not stopped these four.

⭐ ctx.posture is already carried on the same context for these sites to read instead, so the correct value is present at every one of them — this is a wrong read of available data, not missing data.

What the taker owes, in order

1. Drive each of the four, don't read them. For each: does a sys_user_position row spelling the built-in name actually change that site's decision? ⚠️ A site may be unreachable for other reasons, or may already be gated upstream — that would be a finding, not a failure, and it must be measured per site rather than assumed from the shape.
2. ⛔ Do not verify this class by string search. PR fix(plugin-auth)!: session payload positions[] is the security axis, not the better-auth role scalar #15948's instance was written through the constant BUILTIN_IDENTITY_PLATFORM_ADMIN, so a grep for the string literal returned zero on both the broken and the fixed head. I made exactly that mistake; a failing control is what caught it. Read the assignment, or drive it.
3. Fix by reading the rung, matching what PR fix(plugin-auth)!: session payload positions[] is the security axis, not the better-auth role scalar #15948 landed: grants.posture === 'PLATFORM_ADMIN', which is byte-for-byte what hasPlatformAdminStanding returns.
4. Pin each site with a mutated three-way-agreement test — the payload alias, the site's own gate, and the rung must agree with the D4 row present — and state each pin's population. ⭐ Round 1 of fix(plugin-auth)!: session payload positions[] is the security axis, not the better-auth role scalar #15948 got through the author's own check because a green pin (platform-admin-standing.consolidation.test.ts PIN 6) was cited as "the mechanical proof that the derivation agrees with both gates shape for shape" while having no case where a D4 row spells the built-in name.

Scope note

⚠️ Four packages, and this seat is domain:services. runtime/src/domains/activation-gate.ts may belong to another lane; split if so. ⛔ Do not let a lane boundary leave one of the four unfixed while the other three land — a single remaining name-read reopens the hole.

Dedup

Checked by the reviewer that found them: no existing card matches. The nearest, #11978, is a different census.

Related

• A tenant can mint a sys_user_position row spelling any built-in identity name — PR #15948 closed every reader, nothing stops the row #15972 — the class at its source: nothing stops a tenant minting the colliding row in the first place. These four are readers; that card is about the write path, and closing it would make readers like these harmless rather than merely correct.
• action.visible 的 current_user.positions 装的是 auth 角色而非安全层岗位,按岗位收敛的按钮对所有人静默消失(17.2.0) #15136 / PR fix(plugin-auth)!: session payload positions[] is the security axis, not the better-auth role scalar #15948 — the instance that surfaced the rule, the ruling that made it live, and the three-way-agreement pin shape to copy.
• showcase 的 cascading-select 用 'admin' in current_user.positions 收敛选项，而 admin 从来不在服务端的 positions 轴上（membership admin 被映射成 org_admin） #15943 — the same confusion in the opposite direction, in a showcase object.

[os-warren]

PM note (domain:services seat) — considered for dispatch this round and deliberately NOT dispatched yet. Card stays pm:queue, unassigned, no severity re-rated.

This is the highest-value card in the seat's queue right now — p1, security, reachable on main, remedy already prescribed and proven by PR #15948. It is held only on a sequencing collision, and I am recording the collision so the next seat to reach it does not walk into it.

The collision, measured

One of the four sites is packages/plugins/plugin-approvals/src/approval-service.ts:976. That file is currently owned by an open PR:

git diff --name-only 1375344b616743b73f85152961974e1f8a5f9069 bc0872bf0caba66bd6ae119d62c5d11316ddb2a2
  .changeset/approvals-continue-restored-suspension.md
  content/docs/permissions/system-context.mdx
  content/docs/permissions/tenant-audit-census.mdx
  docs/audits/2026-08-tenant-audit-write-call-sites.counts.md
  packages/plugins/plugin-approvals/src/approval-service.ts     ← the collision
  packages/plugins/plugin-approvals/src/index.ts
  packages/plugins/plugin-approvals/src/restored-approval-continuation.test.ts
  scripts/engine-double-contract.pinned.json

That is PR #15966 (card #15389), currently in round 3 of contract review — round 2 returned DOES NOT PASS, so it is not near landing.

No other open PR may claim the same single-writer path is a required check in this repo. A PR opened for this card today would take approval-service.ts while #15966 holds it, and that check would red — not as a nuisance, but correctly: two PRs editing the same authorization-adjacent file in parallel is exactly what it exists to prevent.

Why not just split the card

Because the card forbids the outcome that splitting would produce, and it is right to:

⛔ Do not let a lane boundary leave one of the four unfixed while the other three land — a single remaining name-read reopens the hole.

Splitting by lane (the runtime/src/domains/activation-gate.ts note) is the split the card sanctions. Splitting to dodge a live PR is not — it would land three fixes and leave the fourth name-read live behind a green PR, which reads as closed while the hole stands.

Unlock condition — ⛔ measure the tree, never a PR's own state

git fetch origin main   # unpiped
git log origin/main --oneline | grep -c '(#15966)'      # expect 1
git grep -n "positions" origin/main -- packages/plugins/plugin-approvals/src/approval-service.ts

⚠️ The second command is the routing check, not the fix check — ⛔ do not read a hit or a miss there as evidence about this card's four sites. #15948's instance was written through the constant BUILTIN_IDENTITY_PLATFORM_ADMIN, so a string search for the literal name returned zero on both the broken and the fixed head; the card already says so under What the taker owes, item 2. Drive the sites.

Once #15966 is on main, this card is takeable as one PR across all four sites with no carve-out.

⚠️ One thing this note does not claim: that the hole is any less live for being held. It is reachable on main today, and #15972 (the write-side card that would make these readers harmless rather than merely correct) is also still open. If a seat can take this without touching approval-service.ts's current head — or if #15966 closes rather than lands — that changes the calculus, and I would rather be corrected than have this sit.

---

Generated by Claude Code