fix(platform-objects): offer Add Member only to a platform admin

[objectstack-fleet]

Fixes #21886
Clause-②: no

What changes

sys_member.add_member ("Add Member" on an organization's member list) is now offered only to a platform administrator. That is the one standing its endpoint admits.

• Before: the action was gated on the organization feature alone, so every member of the organization saw it: plain members, admins and owners. POST /api/v1/auth/organization/add-member then answered each of them 403 PERMISSION_DENIED, because the mount runs the ADR-0068 platform-admin gate before anything else.
• After: the action declares visible: 'current_user.isPlatformAdmin == true', the predicate the maintainer's ruling A-lite fixed (record 6019378035). ADR-0068 D4 names that predicate, and since PR fix(spec): EvalUser.isPlatformAdmin is the ADR-0095 D3 PLATFORM_ADMIN standing, not a deprecated alias #22018 EvalUserSchema.isPlatformAdmin describes it as the PLATFORM_ADMIN standing of ADR-0095 D3. requiresFeature: 'organization' composes onto it at parse time, so the served predicate is (current_user.isPlatformAdmin == true) && features.organization != false.

The door and the callers it admits are unchanged. No key, export or parameter is added, and the label is unchanged. That makes Clause-②: no, and the changeset is a @objectstack/platform-objects patch.

File surface, as the claim declared it. The producer is packages/platform-objects/src/identity/sys-member.object.ts. The other files are the lowering-matrix pin in packages/platform-objects/src/platform-objects.test.ts, one dogfood case in packages/qa/dogfood/test/org-admin-affordance-reach.dogfood.test.ts, and .changeset/21886-add-member-platform-admin-visibility.md. There is no packages/spec, plugin-auth or @objectstack/formula edit.

The dispatch's hypotheses, measured at 56c88446ea

• H1: confirmed. The two keys compose with AND, the authored term first. lowerRequiresFeature (packages/spec/src/kernel/public-auth-features.ts:352-419) turns an existing CEL visible into (existing) && gate (:415-418). The first-party precedent that carries both keys is sys_user.enable_two_factor (sys-user.object.ts:534-535), pinned at platform-objects.test.ts as (...) && features.twoFactor == true.
• H2: confirmed. The served visible is exactly (current_user.isPlatformAdmin == true) && features.organization != false. This was read from the parsed SysMember object in the matrix test, and from the served /meta/object/sys_member on a real boot through the dogfood case. EvalUserSchema.isPlatformAdmin (eval-user.zod.ts:225-241) now describes the ADR-0095 D3 standing.
• H3: confirmed, with one correction.
  • The console binds current_user through extra. At the current objectui pin a58626c88d:
    • fieldRules.ts:284 passes the scope as extra;
    • ExpressionProvider.tsx:190 builds one subject under current_user, user, ctx.user and os.user, with features beside it;
    • expressionUser.ts:176 forwards isPlatformAdmin from the session.
  • The session value is grants.posture === 'PLATFORM_ADMIN' (plugin-auth auth-manager.ts:4083, emitted at :4107).
  • Under user:, @objectstack/formula re-derives it from positions (stdlib.ts:417-430 through createEvalUser). Under extra, the bag is merged verbatim (stdlib.ts:462).
  • The correction: the file's existing owner principal is the harness's seeded dev admin, and on this boot its served session carries isPlatformAdmin: true. It is the platform-admin principal, reused. Nothing on this boot declares OS_PLATFORM_OWNER_EMAIL: it is unset in the environment, absent from the dogfood package and the showcase config, and the harness sets it only under a walled posture (packages/verify/src/harness.ts:481-497). By EvalUserSchema's definition, the rung therefore comes from the single posture's unscoped admin_full_access grant. The file had no org owner who is not a platform admin, so the case signs one up and sets its membership to owner, the way the file already sets grades.
  • The existing cases still bind through user:, unchanged.
• H4: confirmed. No server path evaluates an action visible.
  • rest, runtime, objectql, services, metadata, metadata-protocol, core and plugins have zero non-test hits for an action-visible evaluation.
  • The eight ExpressionEngine.evaluate / celEngine.evaluate call sites in package sources evaluate other things: formula fields and defaults (objectql/src/engine.ts:2263, :6190), hook conditions (hook-wrappers.ts:309), approval conditions, share-link gates and automation steps.
  • So nothing on the server binds current_user.isPlatformAdmin for this predicate, and the door stays the authority.

Tests

All runs below are at the final HEAD (bb53601015) unless marked otherwise.

• Pin (a), platform-objects: the lowering-matrix row SysMember#add_member now expects (current_user.isPlatformAdmin == true) && features.organization != false.
  • pnpm --filter @objectstack/platform-objects exec vitest run: 62 files, 996 passed.
  • The package typecheck passed, with 0 TS errors. Its main program does not compile platform-objects.test.ts. check:test-typecheck compiles it through tsconfig.test.json: --listFiles counts 1 hit there and 0 in the main program.
• Pin (b), one dogfood case on a real showcase boot: Add Member is offered to a platform admin alone — current_user bound as the console binds it — and the door agrees.
  • It reads each principal's served session, its own served /meta/object/sys_member and the served /auth/config flags.
  • It asserts each session's isPlatformAdmin: true for the seeded admin, false for the second owner, the admin, the delegated admin and the plain member. It also asserts that the second owner carries org_owner.
  • It evaluates the served predicate with celEngine, with current_user bound through extra the way the console binds it. Exactly the platform admin is offered the action.
  • It then probes the door on the same boot: the owner and the plain member get 403 PERMISSION_DENIED (envelope error.code) and no row is written; the platform admin gets 200 success: true and the sys_member row lands.
  • Result: test/org-admin-affordance-reach.dogfood.test.ts passed 14 of 14. The dogfood typecheck passed, and its program compiles the touched file (--listFiles: 1 hit).
• Builds: turbo run build --filter='@objectstack/dogfood^...' passed 63 of 63 after the merge of origin/main.

Reverse verification, on committed HEAD 57b18bf94e

• Mutation: scripts/ablation-replace.mjs deleted the line visible: 'current_user.isPlatformAdmin == true',. The anchor count went from 1 to 0 and the file's blob from 9beac68ce1c7 to b8792313cac4. An outer trap … EXIT INT TERM used absolute paths.
• Proof the mutation reached dist/: @objectstack/platform-objects was rebuilt, then scripts/ablation-dist-preflight.mjs @objectstack/platform-objects 'visible: "current_user.isPlatformAdmin == true"' --absent --source-marker=… reported the marker absent from all 66 built files. Before the mutation, the same spelling was present in dist/index.mjs:2219.
• (a) turned red, 1 failed of 127: expected 'features.organization != false' to be '(current_user.isPlatformAdmin == true) && features.organization != false'.
• (b) turned red, 1 failed of 14: the set offered "Add Member" was received as platform admin, org owner, not a platform admin, org admin, delegated admin and plain member, against the expected platform admin alone. So the owner and member cells (and the admin cells) went red.
• Direction: the run turned red, as predicted.
• Restore: git checkout HEAD -- on the absolute path. The blob after restore and the HEAD blob are both 9beac68ce1c7ed2b7143505916818a0a2e39a456, and git diff HEAD is empty. Both ablation-replace and the outer trap proved this.
• After the restore: the package was rebuilt, and the preflight in present mode found the marker in 6 built files on a clean tree. (a) passed 127 of 127 and (b) passed 14 of 14.

Gates

These ran locally at bb53601015, after the merge of origin/main (5cfd8661c4).

• The derived gates: node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack derives 67 commands for this change set (35 pnpm, 32 node). All 67 ran and exited 0. --ran reconciles them: 67 derived, 67 run, 0 NOT-MEASURED, 0 UNRUN.
  • check:dual-build-cjs-loads first answered PREREQUISITE NOT MET (exit 3), because the build had covered only the dogfood closure. It was rerun after a full workspace build (turbo run build, 72 of 72) and loaded 106 require entry points across 66 packages.
  • check:dts-closure, check:lean-entry-closure, check:published-files and check:sourcemap-no-sources-content were rerun on that full build too, and all four passed.
• The artifact-roster block: the derivation prints 53 more commands outside its total, and all 53 ran.
  • 50 exited 0.
  • Three answered NOT WIRED / NOT MEASURED (exit 2) because they need pull-request context: check-partof-closing-keyword, check-closing-target-claim and check-single-claim-paths. check-partof-closing-keyword was then run with this body as PR_BODY and passed. The other two need this PR's number and CI runs them on it.
  • check-sdui-manifest passed, but its objectui version comparison is NOT CHECKED, because the container has no objectui checkout.
  • check:console-injection is NOT MEASURED: there is no console dist/ here, so only its self-test ran. This diff touches neither surface.
• The four symbol-anchor sweeps: check:adr-symbol-anchors, check:scripts-symbol-anchors, check:spec-docblock-symbol-anchors and check:adr-anchors all passed.
• Lint, as a proven narrowing: pnpm exec eslint --no-inline-config --format json ran over the three touched TypeScript files.
  • The population is read from eslint's own config: --print-config resolves for each of the three, so none is ignored.
  • The JSON output counts 3 files, with 0 errors and 0 warnings.
  • The narrowing cannot hide a verdict elsewhere. Type-aware linting is off: the resolved configs carry no parserOptions.project or projectService, and eslint.config.mjs:327-328 states the repo never enables it. So this diff cannot move the verdict on any untouched file.
• Left to CI, as a declared narrowing: the type-check lanes, Test Core, Dogfood Regression Gate, Build Core and the repo-wide pnpm lint.

Acceptance notes

• The door also admits a legacy user.role === 'admin' scalar (platform-admin-gate.ts:80-84), and this predicate does not read it. A deployment that still carries that pre-ADR-0068-D2 scalar on a user who lacks the posture rung would be admitted by the door, but would not be offered the button. The gate's own header says nothing in ObjectStack writes that scalar for a platform admin, and that re-synthesizing it is vetoed. The predicate is the one the ruling fixed, so this is noted, not filed.
• Only one platform-admin route is exercised here. The dogfood boot uses the single posture, where the standing comes from the seeded admin's unscoped grant. The OS_PLATFORM_OWNER_EMAIL route of the walled postures is not exercised by this case.
• Only the new case binds through extra. The grade cases above it still bind through user:, as the dispatch required. Their predicates read only current_user.positions, which is identical under either binding.
• Out of this PR: identity: the platform-admin-gated actions on sys_user, sys_oauth_application and sys_sso_provider show no standing term in visible — the affordance family's closing card, with an enumeration pin (after #21886's ruling) #21903 (Blocked-by: #21886) remains open and carries the thirteen sibling platform-admin actions and the enumeration pin.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/platform-objects, touching 1 documentable anchor(s).

6 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/kernel/runtime-services/sharing-service.mdx (via platform_admin (literal, a string literal in a comment in actions))
• content/docs/permissions/authentication.mdx (via platform_admin (literal, a string literal in a comment in actions))
• content/docs/permissions/authorization.mdx (via platform_admin (literal, a string literal in a comment in actions))
• content/docs/permissions/permission-metadata.mdx (via platform_admin (literal, a string literal in a comment in actions))
• content/docs/permissions/positions.mdx (via platform_admin (literal, a string literal in a comment in actions))
• content/docs/permissions/sharing-rules.mdx (via platform_admin (literal, a string literal in a comment in actions))

⛔ 3 release-owned page(s) also name something this change touched. These are read-only:

• content/docs/releases/v14.mdx (via platform_admin (literal, a string literal in a comment in actions))
• content/docs/releases/v17/17-4.mdx (via platform_admin (literal, a string literal in a comment in actions))
• content/docs/releases/v17/17-5.mdx (via platform_admin (literal, a string literal in a comment in actions))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

What this run could not see

• 1 name(s) were too generic to anchor anything (single lowercase words)
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.
• a key NAME is not a key, so the hand re-read the line above prescribes can land on the wrong schema. The same spelling is authorable on one governed type and a [REMOVED] tombstone on another for each of active, aria, joins, objects, template, tools and version (censused on [finding] tools is a key on BOTH AgentSchema (tombstoned, dead) and SkillSchema (live, cloud-attested), so a name-based search attributes skill examples to the agent key — it produced a false stop-the-line alarm on PR #19059 #19093 over the liveness ledger's governed types, top-level keys); nothing in a search result distinguishes the two, so a grep hit on a LIVE example reads as evidence about the DEAD key. Measured on fix(spec): the agent.tools liveness row says dead — it claimed live on a key the schema tombstoned #19059: content/docs/ai/agents.mdx was reported as contradicting the agent.tools tombstone over its tools: example at :161, which is inside the defineSkill({ block opened at :155 — the page was already correct. Settle ownership by PARSING the value against both schemas, never by the name: that literal PASSES SkillSchema, and as an AgentSchema it FAILS at tools with the tombstone prescription. ⛔ These names are not the whole class — a key retired through a .strict() guidance map leaves no tombstone in the walked shape and none of them here (tool.category, live as AIToolDefinition.category).

Coarse fallback — 3 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 5cfd8661c4deef4716d1895883633003a54a9db7 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 572b062bc3a2d7cbdbd7df88c372a489ca1324a8 — the merge of head bb5360101575090406643fbbe3e6585ac78d2f8b into base 5cfd8661c4deef4716d1895883633003a54a9db7, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 572b062bc3a2d7cbdbd7df88c372a489ca1324a8 && git checkout 572b062bc3a2d7cbdbd7df88c372a489ca1324a8
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 5cfd8661c4deef4716d1895883633003a54a9db7 bb5360101575090406643fbbe3e6585ac78d2f8b && git checkout -B drift-repro 5cfd8661c4deef4716d1895883633003a54a9db7 && git merge --no-ff bb5360101575090406643fbbe3e6585ac78d2f8b

node scripts/docs-audit/affected-docs.mjs --json 5cfd8661c4deef4716d1895883633003a54a9db7

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 5cfd8661c4deef4716d1895883633003a54a9db7 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[objectstack-fleet]

ACCEPT (seat review) — PR #22064 at head bb53601015

domain:engine#1 · session_017ErfyP2Rx7XWHJA27QjyUi · read at 2026-10-07T08:06Z. The dev's report is os-dev-report on #21886 (6033238520). It lands under the maintainer's ruling A-lite (batch #281 item 2, 6019378035).

• The change is the ruling's, and nothing else. The seat read the diff:
  • The predicate. sys_member.add_member declares visible: 'current_user.isPlatformAdmin == true'. requiresFeature: 'organization' composes onto it at parse time with AND, authored term first (lowerRequiresFeature, the sys_user.enable_two_factor precedent). The served predicate is (current_user.isPlatformAdmin == true) && features.organization != false.
  • The comment names the standing (ADR-0068 D4, the ADR-0095 D3 rung) and forbids the positions form.
  • Unchanged: the door (organization-add-member.ts, the mount, platform-admin-gate.ts), packages/spec, @objectstack/formula and the label.
• Pins:
  • (a) the platform-objects lowering-matrix row now pins the composed predicate.
  • (b) one dogfood case on a real showcase boot. It binds current_user through extra from each principal's served session, the console's binding, so the platform admin alone is offered "Add Member". An org owner who is not a platform admin, an org admin, a delegated admin and a plain member are not. On the same boot, the door refuses the owner and the member (403 PERMISSION_DENIED, no row written) and admits the platform admin.
  • Reverse verification on the committed head deleted the visible line: (a) and (b) went red, with (b)'s offered set holding all five principals. It was restored by blob equality, with an empty git diff HEAD.
• H4: no server path evaluates an action visible, re-confirmed at 56c88446ea. Nothing server-side binds this predicate.
• Changeset, sentence by sentence against the diff:
  • "offered only to a platform administrator, the one standing its endpoint admits": matches the predicate and pin (b).
  • "the served predicate reads (…) && features.organization != false": matches pin (a).
  • "Nothing you author changes … no key, export or parameter is added": matches the file list.
• Clause-②: no, patch. The door's accept set is unchanged, and no packages/spec file is in the diff. No contract review is owed.
• Cross-lane: the dogfood case was declared to domain:cli on [PM seat] domain:cli — 🟢 os-warren · session_01RWZbGvPFcRKvUqASZtunCU #6024 (6032418205), and no reply came. domain:services' PR fix(plugin-email): the boot sweep reads stored templates in bulk and no longer rewrites an unchanged row #22065 adds a different dogfood file.
• CI on bb53601015: 32 success, and the 3 skips are in the roster.
• Readings against main at 5cfd8661c4: NOT governed (0 of 4 paths), 133 changed lines, and git merge-tree is clean.
• Noted, not filed (PR Acceptance notes):
  • the door also admits the legacy better-auth role === 'admin' scalar, which this predicate does not read. Nothing in-tree writes it, and no reach was measured;
  • the dogfood case covers the single-posture route to PLATFORM_ADMIN, not the walled postures' OS_PLATFORM_OWNER_EMAIL route. That is for identity: the platform-admin-gated actions on sys_user, sys_oauth_application and sys_sso_provider show no standing term in visible — the affordance family's closing card, with an enumeration pin (after #21886's ruling) #21903, the family's closing card, if it wants it.

---

Generated by Claude Code