Merge remote-tracking branch 'origin/main' into claude/issue-7823-session-token-internal

Author: claude

.changeset/impersonation-bearer-rotation.md

@@ -0,0 +1,53 @@
+---
+"@objectstack/plugin-auth": patch
+---
+
+fix(plugin-auth): impersonation actually takes effect for bearer clients — rotate the caller's token, and let `stop-impersonating` recover the admin via bearer (#8243)
+
+`POST /api/v1/auth/admin/impersonate-user` answered **HTTP 200 and did nothing**
+for every bearer-authenticated client — the console after every normal sign-in,
+and every deployment where cookies are blocked, which is the exact context
+better-auth's `bearer()` plugin exists for.
+
+Two correct pieces of better-auth collided. `bearer()` authenticates a request by
+**overwriting the request's session cookie** with the bearer token. The admin
+plugin's impersonation route does the opposite: it mints the impersonation
+session and hands it over **as a cookie**, parking the admin's own session token
+in a signed `admin_session` cookie for the way back. A browser composes those
+two; a bearer client cannot. The client kept replaying its unchanged
+`Authorization: Bearer` header, that header kept being converted back into the
+**admin's** session, and the impersonation cookie was never read.
+
+Nothing reported this. The endpoint returned success, an impersonation session
+row existed, and every subsequent request — including every write, since the
+framework's data routes resolve identity through the same seam — was attributed
+to the **admin** rather than the impersonated user.
+
+**Impersonation now rotates the caller's credential.** When the caller
+authenticated with a bearer, the token it holds is invalidated as part of
+impersonating: a rotated admin session is minted, the caller is handed it as a
+recovery credential, and the original admin session is deleted. Afterwards the
+only token that resolves is the impersonated one better-auth already emits on
+`set-auth-token`. A client that adopts the rotation is the impersonated
+principal; a client that ignores it gets a loud 401 on its next request.
+"Impersonation succeeded but did not take effect" is no longer expressible.
+
+Refusing bearer-authenticated impersonation was considered and rejected: it
+would leave cookie-blocked deployments unable to impersonate at all.
+
+**The exit path ships with it.** `POST /admin/stop-impersonating` resolved the
+admin through the `admin_session` **cookie alone**, so it was dead in precisely
+the deployments this fix is about. The recovery credential is now emitted on a
+`set-admin-session-token` response header (exposed via
+`Access-Control-Expose-Headers`, alongside `set-auth-token`) and accepted back on
+an `x-admin-session-token` request header. Clients that already work through
+cookies need no change: a real `admin_session` cookie still wins, and the vendor
+route's own checks all still run — this adds a lane, it does not open one.
+
+For API clients, the flow is the same one `set-auth-token` already asks for:
+read both headers off the impersonation response, send `Authorization: Bearer`
+with the new token, and send the recovery credential back on
+`x-admin-session-token` when leaving impersonation.
+
+Unaffected: cookie-authenticated impersonation, which is unchanged byte for
+byte — a browser caller has no stale credential in hand to invalidate.

.changeset/mcp-record-resource-exposure-gate.md

@@ -0,0 +1,41 @@
+---
+"@objectstack/mcp": patch
+---
+
+fix(mcp): the stdio record resource honours the ADR-0049 `apiEnabled` / `apiMethods` exposure declaration (#8266)
+
+An object that declares `enable.apiEnabled: false` — or narrows `enable.apiMethods`
+so a single-record read is outside the whitelist — was refused by the `get_record`
+tool and **still readable** through the ADR-0101 record resource
+(`objectstack://objects/{objectName}/records/{recordId}`): same transport, same key,
+same declaration, two answers.
+
+**This is a surface-area declaration leak, not an authorization bypass.** The gate is
+a surface-area control by `api-exposure.ts`'s own ADR note, and this read passed the
+ObjectQL security middleware (CRUD / FLS / RLS) — under the key's `ExecutionContext`
+— before this change and after it. What was leaking is the author's *exposure
+declaration*, not the data guard.
+
+Why the resource was missed when the tool was fixed: the six object-CRUD verbs all
+flow through `createStdioDataBridge`, which has been gated since #8083. The record
+resource does not use that bridge — its reader is a separate closure built inline in
+the plugin that calls `ql.find` directly and is handed to `bridgeResources`. Gating
+the bridge therefore never reached it. That reader now applies the same gate, taking
+its decision from the same single source of truth every other enforcement point
+delegates to (the spec's `resolveEffectiveApiMethods` / `isApiOperationAllowed`), so
+the three-state whitelist and the derived verbs resolve identically on all surfaces.
+
+The gated action is `get`, matching what the HTTP path sends for a single-record
+read. Refusals carry the same machine codes the REST surface answers with —
+`OBJECT_API_DISABLED` and `OBJECT_API_METHOD_NOT_ALLOWED` — and reach an MCP client
+as the resource's `{ "error": ... }` body, which is how that resource has always
+reported a failed read. The behaviours matched to the HTTP path in #8083 are matched
+here for the same reasons: a system context bypasses, and unresolvable metadata fails
+open to the schema defaults.
+
+Unaffected: the object schema and object list resources stay ungated, because the
+HTTP bridge answers both straight off the metadata service — refusing a *schema* read
+here would be a fresh divergence pointing the other way. The remaining known
+divergences between the two MCP bridges (the protocol layer's ingress `readonly`
+strip, its existence probes, its spec-shaped receipts and `expand` / `select`) are
+unchanged and still filed as follow-up work.

.changeset/member-role-canonical.md

@@ -0,0 +1,47 @@
+---
+"@objectstack/plugin-auth": patch
+---
+
+fix(plugin-auth): canonicalise `sys_member.role` at the write, so an org admin can no longer remove an owner (#8317)
+
+**Security — authorization inversion.** A membership stored with a non-canonical
+role — `Owner`, `' owner'`, `OWNER` — was an **owner** to every ObjectStack-side
+check and a **plain member** to better-auth.
+
+better-auth `1.7.0-rc.2` reads that column with a raw `role.split(",")`, with no
+`trim()` and no `toLowerCase()`, in three branches of
+`dist/plugins/organization/routes/crud-members.mjs`: `removeMember`'s "only an
+owner may remove an owner", `updateMemberRole`'s creator protection, and
+`organization/leave`'s last-owner count. ObjectStack's own readers all trim and
+lower-case (the #5942 grade ladder, `mapMembershipRole`). So on such a row the
+vendor never entered its owner branch at all and fell through to
+`hasPermission({ member: ['delete'] })` — **which an org admin passes**. An org
+admin could remove, demote, or count out an owner that every ObjectStack check
+treated as an owner.
+
+Not reachable through the ordinary invite/accept path (better-auth's own writes
+are canonical). Reachable through anything else that writes the column: an
+operator SQL fix-up, a data import, a SCIM group mapping, a script.
+
+**The fix normalises at the write**, so the disagreement is unrepresentable
+rather than adjudicated per reader:
+
+- ObjectQL `beforeInsert` / `beforeUpdate` hooks on `sys_member` canonicalise
+  `role` on every write path, in every context (system and better-auth adapter
+  writes included — those are the paths this exists for). They run at priority
+  5, ahead of the ADR-0092 identity write guard and the ADR-0024 D5.2
+  break-glass guard, so both judge the value's normal form.
+- A **one-off convergent pass runs at boot** and canonicalises rows that already
+  exist. It is idempotent, safe to re-run, and logs a census of every distinct
+  non-canonical spelling it found with row counts.
+
+Canonicalisation is per token: a token that is a membership role (ADR-0108's
+closed vocabulary) is trimmed and lower-cased; any other token is preserved
+verbatim apart from trimming, because `mapMembershipRole` passes an unknown
+value through with its case and it becomes a position name a permission set may
+be bound to. A value carrying no known role at all is left completely untouched
+and only reported — it cannot produce the inversion.
+
+No API, schema or configuration change: `sys_member.role`'s option list is
+unchanged, and canonicalisation never moves a membership's grade, so no
+membership gains or loses authority as a result of this fix.

.changeset/metadata-protocol-batch-verb-driver-text.md

@@ -0,0 +1,33 @@
+---
+'@objectstack/metadata-protocol': patch
+---
+
+Stop putting caught driver text on the batch verbs' response payloads (#8333).
+
+`publishPackageDrafts`, the publish side effects and their materializer, the seed
+apply, `duplicatePackage`, `revertCommit`, `rollbackToPackageCommit` and
+`migrateStoredMetadata` each reported a failure by copying the caught error's
+sentence onto a field of the response — `failed[].error`, `materializeApplied`'s
+`failures[].error`, `seedApplied.error`, `rows[].reason`. Those are DATA, not
+messages, so no HTTP boundary's 5xx message withhold ever reached them: a
+`sys_metadata` outage shipped `SQLITE_ERROR: no such table: sys_metadata` to the
+client on an otherwise successful-looking response.
+
+All eight now follow the rule #8136 installed for the uninstall cluster: a caught
+sentence is quoted back only when that error **declared itself a client-facing
+refusal** (a 4xx `status` in the ADR-0112 envelope). Anything else gets a stable
+sentence and the original goes to the server log, which these sites did not
+previously write at all.
+
+Authoring feedback is unaffected, and that was measured before anything changed
+rather than assumed. Every authored refusal reaching these collectors already
+declares 4xx, so it is still quoted verbatim — a failed package publish still
+tells the author which field of which draft is wrong, with its `code` and
+structured `issues` intact.
+
+One producer needed declaring rather than converting: `applySeedBodies` parsed
+the seed request with `SeedLoaderRequestSchema.parse()`, so a malformed seed body
+surfaced as a raw `ZodError` that declared nothing. It is now a `safeParse` that
+raises a real `422 INVALID_METADATA` envelope, so `seedApplied.error` carries the
+same curated, path-pointing summary every other authoring surface produces
+instead of a multi-line dump of zod internals.

.changeset/nav-servability-prune.md

@@ -0,0 +1,60 @@
+---
+"@objectstack/spec": patch
+"@objectstack/rest": patch
+"@objectstack/lint": patch
+---
+
+fix(rest,lint,spec): prune nav entries whose destination object cannot serve, and refuse them at authoring time (#7912)
+
+A `type: 'object'` navigation entry pointing at an object that **cannot answer a
+list** was served to the client in the `/meta` payload anyway. The user saw a
+menu item that could not work, and the console rendered the failure as a generic
+empty state — so it read as *"you have no records"* rather than *"this page
+cannot work"*.
+
+Two independent conditions make a destination unservable, and **neither was
+expressible on a nav entry**:
+
+- `enable.apiEnabled: false` → the list answers `OBJECT_API_DISABLED` (404);
+- an `enable.apiMethods` whitelist without `list` → `OBJECT_API_METHOD_NOT_ALLOWED` (405).
+
+Both are pure functions of the object's own `enable` block — no user, no
+permissions, no request context — so the destination is dead for **every**
+persona, platform administrator included. That is why a `requiredPermissions`
+gate could never prune such an entry: the two are independent conditions, and no
+combination of permissions on the *entry* rescues an entry whose *object* is
+API-disabled. One shipped that way for a year and read as correct to reviewers,
+its in-code comment claiming a non-admin "403s server-side" — which implies an
+admin could list. None could.
+
+**The fact is now derived, not declared.** `filterAppForUser` consults the
+destination's `enable` block for every `type: 'object'` entry and drops the ones
+that cannot serve, on both the app-list and the by-name `/meta` routes and
+inside `children` and `areas[]` alike. No new authorable key was minted: the
+platform already knows this, on the object, in one place.
+
+**And the prune is never silent.** A prune the author cannot see is the same
+failure one layer over, so it is refused at authoring time: `os validate` /
+`os build` / `os lint` now **fail** with `nav-object-unservable`, naming the
+entry, the object, the offending `enable` key path and which of the two
+conditions fired. The serving side logs the same facts for an entry that reaches
+a running deployment anyway.
+
+The single two-step order these consumers share — `apiEnabled` first and
+independently, the whitelist second — is now declared once as
+`apiExposureDenialReason` / `canServeApiOperation` in `@objectstack/spec/data`,
+beside the `resolveEffectiveApiMethods` / `isApiOperationAllowed` primitives it
+composes. The REST data gate, the nav prune and the authoring rule all read that
+one export instead of re-spelling the order.
+
+**Deliberately unchanged:**
+
+- `requiresObject` keeps its client-only evaluation. It asks whether an object
+  is *registered*; this gate asks whether a registered object's `enable` block
+  lets it answer. An entry whose object this layer cannot find is **served**,
+  not pruned.
+- `visible` (CEL) is still client-side only.
+- Fail-open throughout: unreadable object metadata prunes nothing, so a cold
+  start or a metadata outage cannot empty a healthy deployment's sidebar.
+- Objects an authoring stack does not itself declare are not judged by the lint
+  rule — their `enable` block is not visible from there.

.changeset/read-scope-provenance-mark.md

@@ -0,0 +1,68 @@
+---
+"@objectstack/spec": minor
+"@objectstack/driver-sql": patch
+"@objectstack/driver-turso": patch
+"@objectstack/plugin-security": patch
+"@objectstack/service-analytics": patch
+---
+
+feat(spec): filter-subtree provenance — the cross-field refusal names an author's own columns again, without re-disclosing policy (#8220, A of the #7929 ruling)
+
+#8198 (B of the 2026-08-12 #7929 ruling) made the SQL family's cross-field
+`{ $field }` refusal withhold its operands from **every** caller, because the
+predicate reached the driver as a bare `FilterCondition`: an administrator's
+CEL sharing/permission rule and the author's own filter were indistinguishable
+there. The accepted, named cost was the author's diagnostic. This change is A
+— the sanctioned follow-up that pays it back behind a real mark instead of a
+guess.
+
+**The mark** (`@objectstack/spec/data`, `filter-subtree-provenance.ts`) is a
+spec-declared symbol on a filter subtree: `markFilterSubtreeProvenance(subtree,
+'author' | 'policy')`, read positionally by
+`resolveFilterSubtreeProvenance(root, node)` (innermost mark on the ancestor
+chain wins; located by object identity, never structural equality). It rides
+the `where` tree by reference across the `DriverQuery` boundary — no new slot,
+documented on `DriverQuery` itself — and is dropped by exactly the operations
+(serialize, copy, rewrite) after which no attestation could be trusted.
+
+**Set at both read-scope merge boundaries**: `plugin-security`'s CRUD RLS
+injection marks every injected scope `'policy'` and the caller's verbatim
+predicate `'author'` — the latter only under the identity vouch
+`ast.where === options.where`, so a tree a sibling middleware already rewrote
+is vouched for nobody. `service-analytics`' `ObjectQLStrategy.withReadScope`
+marks its scope `'policy'` and the strategy-built user filter `'author'` (and
+`resolveFkAttr`'s scope arm `'policy'`).
+
+**Consumed by the SQL family** (`driver-sql`, `driver-turso`'s
+`RemoteTransport`; `driver-sqlite-wasm` inherits): a refusal raised from a
+subtree positively marked `'author'` carries its full diagnostic on the wire
+again — both columns, the operator, the list index, the boundary reason —
+same identity (`INVALID_FILTER` / 400).
+
+**⚠️ The fail direction is closed, and it is the design**: unmarked or
+ambiguous — no mark anywhere, a mark lost to serialization, a node
+unreachable from the query's own `where`, conflicting aliased marks —
+withholds exactly like `'policy'`. The mark is permission to reveal, never a
+requirement to prove secrecy; a driver-side guess at provenance is the shape
+the #7929 triage rejected.
+
+**Two B-era pins were REWRITTEN deliberately, not weakened.** First,
+`service-analytics`' `cross-field-engine-fallback.test.ts` pinned B's blanket
+redaction on refusals of the caller's OWN `where` (no scope in play) — under A
+that caller is the vouched author, so those cases now assert the corpus's
+`diagnosticIncludes` fragments are back on the wire, while the
+policy-injected-scope case gains the explicit non-disclosure assertions as its
+fail-closed pair. Second, the sharper one:
+`packages/runtime/src/cross-field-refusal-operand-withhold.test.ts` pinned
+author-written and policy-injected refusals **byte-identical** — the strongest
+available statement of "the driver cannot tell them apart", and explicitly the
+assertion A was chartered to supersede. Its successor pins the three-way split
+#8220's "Done means" names: policy-injected withholds (unchanged), the vouched
+author's filter names its columns again (the messages now differ, by design),
+and an unmarked predicate still withholds **byte-identical to the policy
+case** — B's surviving half. Reading that diff as a regression is exactly what
+the old pin's comment warned against; the file header carries the full
+account.
+
+Unaffected: the REST boundary's 5xx-only withhold (#5367/#5667) and every
+refusal outside the cross-field family.