Merge origin/main into claude/issue-11819-adr-0125-record-drift

Resolve AGENTS.md: re-apply the PD #15 trigger correction onto the reflowed
120-byte layout. The corrected sentence is longer and the paragraph has zero
lossless rewrap headroom, so the correction costs one line; CEILINGS raises
AGENTS.md 1149 -> 1150 with the maintainer's 2026-08-25 ruling quoted in place.

Author: claude

.changeset/action-doubled-redirect-refusal.md

@@ -0,0 +1,53 @@
+---
+"@objectstack/spec": minor
+"@objectstack/runtime": patch
+---
+
+feat(spec,runtime): refuse the doubled post-success navigation channel on a `type: 'script'` action (#11519)
+
+**BREAKING** accept-set narrowing on `ActionSchema`, shipped as `minor` under
+the repo's launch-window convention for breaking changes.
+
+Two independent channels could name a post-success destination for one
+`type: 'script'` action: the declared `onSuccess` block (`{ navigate, openIn }`,
+validated and visible in metadata) and the handler-returned `{ redirectUrl }`
+convention (runtime-only). The spec ruled each surface's default in isolation
+and said nothing about an action carrying both — so the renderer had to pick,
+and the pick lived only in one renderer's implementation (declared `onSuccess`
+wins, objectstack-ai/objectui#5933). Maintainer ruling 2026-08-24: refuse the
+doubled channel; ⛔ no `precedence` contract field.
+
+The measured static-knowability partition:
+
+- **Authoring-time refine (spec):** "the handler can return `redirectUrl`" is
+  runtime-only in general (`target` names an opaque registry entry;
+  `HookBodySchema` declares no return contract) — but `opensInNewTab: true` is
+  a schema-visible declaration of the handler-redirect channel (its contract is
+  "pre-open a tab, then drive it to the handler's returned `redirectUrl`").
+  A `type: 'script'` action declaring `onSuccess` beside `opensInNewTab: true`
+  is now **rejected at parse time**, with guidance naming both channels and the
+  remedy. Previously the pair parsed clean and one declaration was silently
+  dead at render.
+- **Dispatch-seam diagnostic (runtime):** the runtime-only remainder — a
+  handler that actually returns `{ redirectUrl }` while the action declares
+  `onSuccess` — now logs a loud `[action-contract]` warning at both dispatch
+  surfaces (the REST `/actions` route and the MCP `run_action` bridge), naming
+  the action, both channels, the interim winner and the remedy. Observe-only:
+  the wire is untouched and the interim renderer precedence stands until the
+  author takes the remedy.
+
+Single-channel declarations are untouched and pinned byte-identically: only
+`onSuccess`, only `opensInNewTab` (with or without `newTabUrl`), and
+`opensInNewTab: false` beside `onSuccess` all parse exactly as before. The
+corpus was measured at zero doubled producers (this repo's examples and
+platform metadata, objectui metadata, and the cloud SSO handoff producers per
+the #11519 measurement), so no shipped metadata is affected.
+
+**Migration.** An action refused by the new refine must pick its one
+destination: keep `onSuccess` and drop `opensInNewTab` (and stop returning
+`redirectUrl` from the handler), or keep `opensInNewTab` + the handler
+redirect and drop `onSuccess`. Which channel is right is an authoring decision
+the metadata cannot make for you, and zero such actions exist in any measured
+corpus.
+
+<!-- adr-0087: not-required (no-migration-prescription) A validity narrowing over a pair of existing keys: no key is removed, renamed or re-shaped, so there is no tombstone and nothing mechanical for `objectstack migrate meta` to rewrite. The refusal is the channel that reaches an affected author, at the parse site, carrying the remedy; choosing which of the two declared destinations to keep is an authoring decision no migration entry can perform on an upgrader's behalf — and the measured population of affected sources is zero in every corpus. -->

.changeset/action-newtaburl-requires-opensinnewtab.md

@@ -0,0 +1,36 @@
+---
+"@objectstack/spec": minor
+---
+
+feat(spec): enforce the documented `newTabUrl` / `opensInNewTab` co-constraint on `ActionSchema` (#11842)
+
+**BREAKING** accept-set narrowing on `ActionSchema`, shipped as `minor` under
+the repo's launch-window convention for breaking changes.
+
+`newTabUrl`'s doc has always said "Only valid together with `opensInNewTab`",
+and every renderer read point agrees: objectui's pre-opened-tab wrapper reads
+the key only behind `action.opensInNewTab && newTabUrl`, and no other path
+reads it at all. Nothing on the refine chain enforced the pairing, so an
+action declaring `newTabUrl` without `opensInNewTab: true` parsed clean and
+the key was silently inert — the ADR-0078 declared-but-unenforced shape,
+arriving through a documented co-constraint rather than a missing key.
+
+`ActionSchema` now **rejects at parse time** an action declaring `newTabUrl`
+whose `opensInNewTab` is not `true`, with guidance naming the pre-opened-tab
+contract and both remedies (declare the flag if a pre-opened tab is intended;
+otherwise delete the inert key — behavior is unchanged either way it was
+already behaving, because the lone key was never read). An explicit
+`opensInNewTab: false` beside `newTabUrl` is refused too, deliberately:
+unlike the #11519 doubled-channel rule, `newTabUrl` has no meaning outside
+the pre-opened-tab flow, so a declared-off channel leaves the key exactly as
+dead as an undeclared one.
+
+The legal pairing is untouched and pinned byte-identically: `opensInNewTab:
+true` + `newTabUrl`, `opensInNewTab` alone, and `opensInNewTab: false` alone
+all parse exactly as before. The corpus was measured at zero lone-`newTabUrl`
+producers (this repo's examples and platform metadata, objectui's fixtures
+and renderer read points, and the cloud SSO producers, which declare the pair
+correctly — re-measured at claim per the triage requirement), so no shipped
+metadata is affected.
+
+<!-- adr-0087: not-required (no-migration-prescription) A validity narrowing over a pair of existing keys: no key is removed, renamed or re-shaped, so there is no tombstone and nothing mechanical for `objectstack migrate meta` to rewrite. The refusal is the channel that reaches an affected author, at the parse site, carrying both remedies; whether a lone `newTabUrl` meant "add the flag" or "delete the leftover" is authoring intent no migration entry can decide on an upgrader's behalf — and the measured population of affected sources is zero in every corpus. Mirrors the disposition of the adjacent #11519 narrowing on the same schema. -->

.changeset/admin-remove-user-gate-ordering.md

@@ -0,0 +1,40 @@
+---
+"@objectstack/plugin-auth": patch
+---
+
+fix(auth): authorize before the break-glass guard on `POST /api/v1/auth/admin/remove-user` (#11477)
+
+The break-glass last-local-credential guard is registered as a global better-auth
+`hooks.before`, which runs ahead of an endpoint's own middleware. On
+`/admin/remove-user` — served directly by better-auth's router, whose
+`adminMiddleware` establishes only a session, with the role decision landing
+later inside the vendor's handler — that ordering let the guard's lookup and its
+distinctive refusal be reached by any **authenticated** caller before either
+authorization layer had run. Because that refusal is target-dependent, the
+refusal itself carried a per-record fact about a user the caller was not
+entitled to ask about.
+
+`/admin/ban-user` already ran the same guard **after** authorization: #9652
+shades that path with an ObjectStack raw mount whose platform-admin gate fires
+first. One guard, two routes, opposite orders, and nothing asserting either.
+
+`/admin/remove-user` now carries the same shading, converging the whole
+`/admin/*` family on **authorization before the guard**. The mount reuses the
+landed #9652 / #9653 pattern and introduces no new mechanism.
+
+What changes is **when** the guard decides, never **what** it decides:
+
+- an anonymous caller still gets `401 UNAUTHENTICATED`;
+- an authenticated non-admin now gets `403 PERMISSION_DENIED` for every target,
+  so the guard is unreachable before authorization and its answer no longer
+  varies with the named user;
+- a platform admin is unaffected in every respect — the mount **delegates** into
+  better-auth rather than re-implementing removal, so the path-keyed hook still
+  fires and the guard still refuses the removal of the last local password
+  login, and admission remains the vendor's own decision (#9969).
+
+An ordering pin ships with the fix so the sequence is mechanically checkable
+rather than re-argued: it asserts that one authenticated non-admin naming two
+different targets receives **indistinguishable** responses, and — so the pin
+cannot be satisfied by deleting the guard — that an admitted platform admin
+still hits the guard's refusal, and still succeeds on an ordinary user.

.changeset/analytics-measure-filter-crossobject-refusal.md

@@ -0,0 +1,9 @@
+---
+"@objectstack/service-analytics": minor
+---
+
+`ObjectQLStrategy` now refuses a cross-object leaf in a compiled measure's own `filter`, on both of its doors, instead of sending it to an engine that cannot join (#11461). This is the third producer of a predicate on that path — after the caller's `where` and the dataset's definition-level `filter` (#10861) — and the one `filterMemberView` did not fold in: #10413 phase 2 lowers `measureFilters[m]` onto that measure's `aggregations[].filter` entry (#10576), and the envelope check enumerated only two origins while its `query.measures` arm read each measure's resolved *field* and never its filter.
+
+Measured on one fixture before the change, both doors in one run: a measure declaring `filter: { 'account.region': 'West' }` on a cube with `include: ['account']` was ACCEPTED, `engine.aggregate` received `{field:"*",method:"count",alias:"west_count",filter:{"account.region":"West"}}`, and an honest evaluator answered `west_count: 0` where the truthful answer was `2` — beside a correct `total_count: 3`, so the wrong number came back wearing the same response shape as the right one. The `/analytics/sql` echo rendered `COUNT(CASE WHEN account.region = $1 THEN 1 END)` over a `FROM` carrying no join at all. Both doors now answer `INVALID_FIELD`/400 before the engine is reached, naming the offending field, the dataset, and — the locator neither sibling refusal has — the measure whose declaration holds the leaf.
+
+Ordinary per-measure filters are unaffected and still reach the engine carrying their own `aggregations[].filter`, and a cross-object filter declared on a measure a query does not ask for changes nothing: only the measures in `query.measures` are judged, which is exactly the set both doors lower. The same definition remains valid on a native-SQL driver, which the refusal says.

.changeset/approval-snapshot-docstring-audit-evidence.md

@@ -0,0 +1,40 @@
+---
+"@objectstack/plugin-approvals": patch
+---
+
+Correct what `sys_approval_request.payload_json` is documented to be FOR — it is audit evidence served redacted per reader, not a notification source
+
+The object's module docstring — which ships to consumers in the package's type
+declarations — justified the snapshot column with: *"used by notifications so
+they can render before the record is locked or changed."* That consumer does
+not exist. Measured against every `this.notify(...)` call site in
+`approval-service.ts`, all **12** of them, each passes a payload of
+`{ title, message, actionUrl }` (two also carry `actions`), built from
+`object_name` / `record_id` and the caller's own comment. **None** reads
+`payload_json` or the parsed `payload`.
+
+This is more than tidiness: that sentence was the only documented
+justification for the column holding a *full* row, and it was cited as such
+during the #10749 consumer inventory before anyone checked it. The docstring
+now states the real reason — the snapshot is retained as **audit evidence of
+what was actually submitted**, so the column stays whole at rest, and is served
+**redacted per reader** by the subject object's field-level read controls via
+`getReadableFields`, on the approvals-inbox door and the generic data door
+alike (#11039).
+
+The field's own `description` is deliberately unchanged: `Record snapshot at
+submission time` is accurate, and it — unlike the JSDoc — is the string
+extracted into the four generated i18n bundles, so no translation leaf moves
+and no locale is left holding an English seed.
+
+Also carried in the same pass, the residual documentation the #10749 closure
+assigned to the next docs touch in this lane: `payload-redaction.ts` recorded
+`hidden`-vs-serialization as an **open** `packages/spec` question, and it has
+since been ruled (maintainer, 2026-08-24, applying the 2026-08-12 lineage).
+That paragraph now states the ruling — **`hidden: true` stays UI-only;
+`internal: true` is the serialization primitive** — so an author who needs a
+field kept out of read results is pointed at `internal: true` (#7728,
+ADR-0049) rather than at `hidden`, which never governed serialization.
+
+Documentation only: no runtime behaviour, no schema field, and no public type
+signature changes.

.changeset/audience-posture-invite-only-default.md

@@ -0,0 +1,19 @@
+---
+'@objectstack/spec': minor
+'@objectstack/plugin-auth': minor
+'@objectstack/verify': patch
+---
+
+feat(spec,plugin-auth)!: one declared audience posture — `invite_only | email_domain | open`, default `invite_only`
+
+**BREAKING CHANGE (ships as `minor` under the launch-window rule; every publishable package rides the fixed group).** "Who may become a user of an environment's apps" is now ONE declaration instead of an emergent property of five switches — and its default flips to the safe end.
+
+- New authorable surface `auth.audience` on `AuthConfig` (`@objectstack/spec/system`): `posture` (`invite_only` | `email_domain` | `open`), `allowedEmailDomains` (required non-empty for `email_domain`), `selfRegistrationPermissionSet` (required whenever the posture permits self-registration; `admin_full_access` refused). Off-vocabulary postures and inert declarations (domains outside `email_domain`, a permission set under `invite_only`) are refused at parse AND at plugin-auth's config entry — never coerced.
+- **FROM:** an undeclared audience meant open email/password self-registration with no email verification, and self-registrants implicitly fell back to the `member_default` permission set. **TO:** an undeclared audience IS `invite_only` — self-serve sign-up (email/password, social-provider OAuth JIT, magic-link/OTP/phone/anonymous, and any unclassified creation method) is refused `403 SELF_REGISTRATION_CLOSED` unless the address holds a pending `sys_invitation` (the first account on a fresh install is exempt — the bootstrap bypass). One-line fix for deployments that mean to stay open: declare `auth: { audience: { posture: 'open', selfRegistrationPermissionSet: 'member_default' } }`.
+- `email_domain` admits only allowlisted domains (`403 EMAIL_DOMAIN_NOT_ALLOWED` otherwise; exact case-insensitive match, subdomains not implied, `+tag` local parts irrelevant). Any self-registration-permitting posture FORCES `requireEmailVerification` on (an explicit `false` beside it is refused at boot) and grants each self-registrant the DECLARED permission set (`sys_user_permission_set`); a declaration that cannot be resolved refuses admission (`403 AUTH_CONFIG_ERROR`) rather than admitting ungranted.
+- Operator-driven creation is never posture-gated: admin create-user / bulk import, SCIM provisioning, and JIT through operator-registered identity providers (`oidcProviders`, `@better-auth/sso`) keep working under every posture.
+- `/api/v1/auth/config` now serves `features.audiencePosture` and mirrors the forced verification flag; `SELF_REGISTRATION_CLOSED` and `EMAIL_DOMAIN_NOT_ALLOWED` are registered in the ADR-0112 ledger.
+- The BOOTSTRAP bypass counts non-system HUMANS, not `sys_user` rows, so a database still carrying the legacy `usr_system` service row is still a fresh install; the same predicate now backs the dev-admin seed's own precondition. The `emailAndPassword.disableSignUp` bootstrap bypass reads it too.
+- `@objectstack/verify`: `stack.signUp(...)` seeds a pending `sys_invitation` for the address before signing up, so harness fixtures that mint a second/third identity enter through the invitation carve-out under the new default. Fixtures asserting on their environment's pending invitations should filter by their own `organization_id` (the harness rows carry `org_verify_audience_gate`).
+
+<!-- adr-0087: registered audience-posture-default-invite-only -->

.changeset/autorestart-covers-thrown-health-checks.md

@@ -0,0 +1,30 @@
+---
+"@objectstack/core": patch
+---
+
+fix(core): `autoRestart` now fires for a health check that throws or times out, not only for one that returns a failure (#11852)
+
+`PluginHealthMonitor.performHealthCheck` reaches its failure handling by two
+disjoint routes, and only one of them could ever restart the plugin.
+
+A check that **returned** a failure (`false` or `{ status: 'unhealthy' }`)
+incremented `failureCounters`, cleared `successCounters`, and — once
+`failureThreshold` consecutive failures accumulated — consulted `autoRestart`
+and restarted the plugin. A check that **threw** took a separate `catch` block
+that incremented `failureCounters` and stopped there: it never cleared
+`successCounters` and never read `autoRestart`. Because `raceCheckTimeout`
+rejects rather than resolving, every `timeout` overrun lands in that `catch`,
+so a plugin that hung was marked `failed` and never restarted no matter how
+many rounds passed or what `autoRestart` said. The severer of the two failure
+modes was the one that could not trigger recovery.
+
+Both routes now funnel into one `recordFailedRound` step that owns the
+counters, the `failureThreshold` comparison and the `autoRestart` decision, so
+a thrown or timed-out check is restart-eligible on exactly the same terms as a
+returned failure.
+
+The per-route *status* label is deliberately unchanged: a throw is still the
+separate `failed` status applied immediately with no threshold, as
+`content/docs/protocol/kernel/lifecycle.mdx` documents. Only the counters and
+the restart decision are shared — those are what `failureThreshold` and
+`autoRestart` declare, and neither names a route.

.changeset/boolean-aggregand-ruled-answers.md

@@ -0,0 +1,5 @@
+---
+'@objectstack/driver-sql': patch
+---
+
+Boolean aggregands now answer the ruled #11249 contract on every SQL dialect. On Postgres, `sum`/`avg`/`min`/`max` over a declared `boolean` field are lowered with a cast (`avg(cast("flag" as int))`) instead of reaching the server as `avg("flag")` — which PostgreSQL refuses with SQLSTATE `42883`, so those aggregations previously failed with `DATABASE_ERROR`/500. On every dialect, `min`/`max` results over a declared boolean are now presented as JSON booleans (`false`/`true`) at the driver boundary — previously MySQL (`tinyint(1)` storage) answered `0`/`1`. `sum`/`avg` answer arithmetic (`3` / `0.5` over a 3-true/3-false column); `count`/`count_distinct` are unchanged, and `min`/`max` over an empty window still answer `null`.