`delegated_admin` can issue invitations but can no longer read them via the data API — the #8095 narrowing lands on owner/admin only

[os-zhuang]

Recording a consequence of #8095's narrowing that the ruling did not decide either way. Measured, not inferred.

What changed and what it left behind

#8095 ruled that sys_invitation read goes to owner/admin, plus a row-scope carve-out for the addressee. The implementation states the admin admission as an RLS policy in organization_admin domained by positions to the two built-in org-administration identities:

positions: [BUILTIN_IDENTITY_ORG_OWNER, BUILTIN_IDENTITY_ORG_ADMIN] // 'org_owner', 'org_admin'

delegated_admin normalizes to neither. mapMembershipRole (packages/spec/src/identity/eval-user.zod.ts) maps only owner / admin / member, and unknown values pass through unchanged — so the role reaches current_user.positions as the literal delegated_admin, matching no listed identity. It also does not receive organization_admin from the auto-grant: auto-org-admin-grant.ts tests roles.includes('owner') || roles.includes('admin') against the comma-split list, and ['delegated_admin'] contains neither as an element.

Net effect: a delegated_admin reads only invitations addressed to their own email.

Measured

Stock showcase boot, single posture, four personas against GET /api/v1/data/sys_invitation with two invitations in the org:

owner 200 total: 2 (both rows, with role + inviter_id)
member 200 total: 0
invitee 200 total: 1 (their own row)
delegated_admin 200 total: 0

Why it may matter

delegated_admin exists precisely as the invitation-issuing principal that is not an org admin (ADR-0105 D8 / #3697: better-auth grants invitation: ["create"] to owner/admin only, and under a wall-enforcing posture those two are auto-elevated to tenant admins, so the delegated grade is the one caller the scope-bounded issuance path has). It can create invitations it then cannot list. better-auth's own list-invitations route is owner/admin-gated too, so there is no second path back.

Also note docs/qa/platform-checklist/areas/identity-auth.json (the ADR-0105 D8 item) has steps phrased as "as the delegated_admin ... capture the created sys_invitation row via the data API" and "immediately read sys_invitation via the API and verify NO row was left behind". Those reads now return nothing for that persona. The item's preferred lane — the pinned packages/qa/dogfood/test/delegated-admin-invite.dogfood.test.ts — is unaffected, because it reads through ql.find under a system context. Left alone rather than edited: whether the checklist wording or the permission changes depends on the decision below.

The decision

Either:

• A. Intended. delegated_admin issues invitations without reviewing the ledger; the checklist steps get re-phrased to read as owner/admin. Cheapest, and consistent with a literal reading of the [finding] org_member can read every sys_invitation row in the org — other people's emails, granted roles, inviter — intended? #8095 ruling.
• B. Add delegated_admin to the admin-side admission (one entry in the positions domain of sys_invitation_org_admin). Gives the issuing grade visibility of what it can issue. Widens the ledger's audience by one role beyond what [finding] org_member can read every sys_invitation row in the org — other people's emails, granted roles, inviter — intended? #8095 ruled, which is why it is not being done unilaterally.
• C. Narrower than B — let a delegated_admin see the invitations they themselves issued (inviter_id == current_user.id), not the whole ledger. Matches the "scope-bounded issuance" shape of ADR-0105 D8 more closely than B, at the cost of a third policy.

No option is being taken here; #8095's PR ships A by default (the status quo of the ruling as written).

Filed from the #8095 implementation. Not assigned.

[hotlong]

Triage: lands in plugin-security / default permission sets if B or C is taken, checklist prose only if A ⇒ domain:identity; type Feature (B/C widen a read admission beyond what #8095 ruled — accept-set expansion routes to the human floor). ⇒ needs-user-decision: even taking A decides a permission boundary ("delegated_admin shall not read the ledger"), which is not auto-adjudicable.

Recommendation: A now, with C as the named reopen trigger.

• Platform long-term coherence: A keeps [finding] org_member can read every sys_invitation row in the org — other people's emails, granted roles, inviter — intended? #8095's ruling as the single statement of sys_invitation read admission; B widens the ledger's audience by a role the ruling deliberately did not include; C is the most D8-faithful widening but adds a third policy for one persona.
• Measured business pull: zero today — the only thing that noticed is the QA checklist wording; no user workflow reads the ledger as delegated_admin. (docs/qa/platform-checklist/areas/identity-auth.json steps get re-phrased to read as owner/admin under A.)
• AI-agent error-resistance: A changes prose only. C's inviter_id == current_user.id row scope is a new predicate shape on the policy surface agents must reason about — cheap, but not free (see [finding] adding an RLS narrowing to member_default silently narrows ORG ADMINS on the default single posture — both of their widening mechanisms are absent there #8241 for how policy composition on this exact object already bit once).
• Startup scope discipline: remove/defer over declare-and-maintain. Reopen trigger for C: a real delegated-admin workflow (UI page or API consumer) that needs to track issued invitations.

If A is taken, the residue is a small Task (checklist re-phrase) that can go straight to pm:queue.

---

Generated by Claude Code

[hotlong]

Maintainer ruling — Option C

Ruled by the maintainer in a live PM session, 2026-08-13 (session session_015XyMgCSMGGn9oSwbQEeWYg), verbatim: 「其他全部接受你的建议。」 — accepting option C as recommended.

Ruling: C — a delegated_admin sees the invitations they themselves issued (inviter_id == current_user.id), not the whole ledger. This matches ADR-0105 D8's scope-bounded issuance shape: the issuing principal can confirm and review its own work without widening the ledger's audience beyond what #8095 ruled (B rejected for exactly that widening; A rejected because an issuer that cannot even confirm its own issuance is a broken shape).

Implementation notes for dispatch:

• One additional row-scope policy on sys_invitation, same declarative pattern as the addressee carve-out that [finding] org_member can read every sys_invitation row in the org — other people's emails, granted roles, inviter — intended? #8095 already shipped. Owner/admin visibility unchanged.
• Pleasant consequence, verify it in coverage: the ADR-0105 D8 checklist steps ("as the delegated_admin ... capture the created sys_invitation row via the data API") become correct again as written — no checklist rewording needed. Pin the four-persona matrix from this card's measurement with delegated_admin now seeing exactly their own rows.

Label swap: needs-user-decision → pm:queue.

---

Generated by Claude Code

[os-zhuang]

Claim — implementing the ruled Option C

• Session: session_01PEVB6w7D7uCszR9Mw1BL73
• Branch: claude/issue-8240-delegated-admin-own-invitations
• Base: origin/main @ 884091c19

Comments re-read before starting; no prior claim comment from another session on this issue.

Declared file surface (plugin-security only — the row-scope policy layer):

• packages/plugins/plugin-security/src/objects/default-permission-sets.ts
• packages/plugins/plugin-security/src/objects/default-permission-sets.test.ts (or a sibling test file)
• .changeset/*.md

Disjointness verified against the three in-flight cards (measured from their live worktrees, git diff --name-only origin/main...HEAD, not assumed):

Card	Its surface	Overlap with mine
#8317 (sys_member role normalisation)	plugin-auth/src/{auth-plugin,index,member-role-canonical}.ts	none
#8243 (impersonation bearer rotation)	plugin-auth hooks + runtime/src/security/resolve-session-principal.ts	none
#8119 (plugin-sharing phantom-anchor mint)	plugin-sharing/**	none

Note on #8317 specifically, since it is the nearest neighbour: its canonicalisation is per-token trim + lower-case against the ADR-0108 closed vocabulary, and delegated_admin is already in that vocabulary — so it normalises to delegated_admin unchanged, and the position name this card's policy domains on is stable under that card landing either before or after mine.

---

Generated by Claude Code