Merge origin/main into claude/dispatcher-handler-ready-1odd28 — reconcile with #4082 (#4058 step 1)

#4082 landed the classification half of #4058 while this branch was open, and did
it better: `DEV_STUB_SELF_INFO` is one reviewable table, it covers the kernel's
OWN fallbacks too (the `_fallback: true` marker no consumer recognized — filed
from this branch as #4089, now fixed at the source), it drops the blanket
`_dev: true` from plugin-dev rather than keeping it as a provenance tag, and it
sets `handlerReady: false` on the surfaceless `degraded` fallbacks
(`cache`/`queue`/`job`/`realtime`) — a refinement this branch missed.

So this branch keeps only what #4082 explicitly left open: step 2, the gate.

Dropped from this branch as superseded:
- the per-stub `devDegraded`/`devStub` markers and their tests (main's table wins);
- retiring the `automation` / `notification` / `ai` stubs. Step 1 classes them
  `stub`, so the gate already answers their HTTP surface as an empty slot without
  deleting anything — verified end to end below. Whether the fabricating class
  should be registered at all is the wider evaluation in #4093 (A tier), which is
  where that deletion belongs alongside `data`/`auth`/`security.*`.

Kept: `isServiceServeable` + the six domain gates, the discovery `routes`/
`features` alignment, the metadata-protocol route suppression, their tests, and
the ADR/docs/changeset text — the ADR annotation now reads as step 2 on top of
step 1 instead of re-claiming the classification.

The gate is compatible with step 1's table by construction, because it reads
`handlerReady` and not `status`: `file-storage` / `i18n` / `metadata` / `workflow`
declare `degraded` with `handlerReady` defaulting to true and keep serving, while
the surfaceless `degraded` fallbacks have no dispatcher domain to gate.

Verified against a real plugin-dev slate after the merge: `automation` /
`notification` / `ai` are registered and classed `stub` ⇒ no route advertised,
`GET /automation` and `GET /notifications` unhandled, `POST /ai/chat` 404, and
`GET /ai/agents` still answers `{ agents: [] }`; `file-storage` / `i18n` /
`workflow` / `metadata` keep their routes and serve. runtime 923, plugin-dev 8,
objectql 1183, metadata-protocol 99, core 415 all pass.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018UNGqBQcdJ2RYHtWgntJ9B

Author: claude

.changeset/auth-catchall-yields-unowned-paths.md

@@ -0,0 +1,36 @@
+---
+"@objectstack/plugin-auth": patch
+---
+
+fix(plugin-auth): the auth catch-all yields paths better-auth does not own (#4088)
+
+`registerAuthRoutes` mounts `rawApp.all('${basePath}/*')` over the whole auth
+namespace (`/api/v1/auth` by default), and that handler was **terminal**: it
+returned better-auth's response unconditionally, including the 404 better-auth
+produces for a path it does not implement. Any other plugin's route under that
+prefix was therefore reachable only if it happened to register **first** — Hono
+runs handlers matching a path in registration order and the first to return a
+Response wins.
+
+That put a load-bearing surface at the mercy of `kernel.use()` order.
+`@objectstack/plugin-hono-server` mounts `/auth/me/permissions` and
+`/auth/me/localization` from its own `kernel:ready` hook; objectui's entire
+permission layer reads the former and `core`'s auth gate allow-lists the latter
+as an endpoint a gated user must still reach. Register `AuthPlugin` before
+`HonoServerPlugin` and all of it silently 404s.
+
+A 404 from better-auth now means "this path is not mine" and the catch-all yields
+to whatever else matched, in either registration order. Deliberately narrow:
+
+- **Only 404 falls through.** 401/403 are real better-auth answers, not
+  disclaimers of ownership.
+- **Precedence still favours the namespace owner.** better-auth wins every path
+  it implements; only its leftovers are up for grabs.
+- **The unclaimed-path wire shape is unchanged.** When nothing downstream
+  answers, better-auth's own 404 is returned verbatim rather than Hono's
+  `404 Not Found`.
+
+No configuration changes and no new routes. The only behavioural difference for
+an existing deployment is that a route another plugin mounts under
+`/api/v1/auth/*` now answers regardless of plugin order — previously it answered
+only in the lucky order.

.changeset/calendar-day-primitive-to-spec.md

@@ -0,0 +1,32 @@
+---
+"@objectstack/spec": minor
+"@objectstack/formula": patch
+"@objectstack/core": patch
+---
+
+fix(formula,spec,core): the RLS write-side `check` evaluator honours calendar-day upper bounds (ADR-0053 D-D)
+
+`@objectstack/formula`'s `matchesFilterCondition` — the evaluator behind RLS
+write-side `check` policies (ADR-0058 D4) — compared a bare `YYYY-MM-DD` `$lte`
+bound literally. On a `datetime` post-image that meant a policy of the shape
+`{ signed_on: { $lte: '{today}' } }` **denied every write made after 00:00**:
+the write-side twin of the read-side data loss #3777 fixed, and the last of the
+platform's filter backends that disagreed about what a bare day means as a
+bound.
+
+`$lte` and a `$between` max now evaluate half-open against the next calendar
+day, matching the SQL compiler, the memory and mongo drivers, and the analytics
+preview evaluator. Unchanged, per the same semantics table: full-ISO bounds keep
+exact-instant semantics, `$gte`/`$gt`/`$lt` keep their midnight anchoring, and a
+plain `YYYY-MM-DD` value compares identically (string ordering makes the two
+forms equivalent). The evaluator stays fail-closed on a null bound.
+
+**Where the rule now lives.** `nextUtcCalendarDay` moved from
+`@objectstack/core` to `@objectstack/spec/data` — beside `date-macros.zod.ts`,
+whose vocabulary it interprets. `formula` cannot depend on `core`, and a second
+copy of the rule is exactly the divergence #3777 catalogued; `spec` is the one
+package all six consumers already depend on, so this adds no dependency edge.
+
+No import changes are required: `@objectstack/core` re-exports the symbol, so
+existing `import { nextUtcCalendarDay } from '@objectstack/core'` keeps working.
+New code should prefer `@objectstack/spec/data`.

.changeset/control-flow-form-zod-ledger.md

@@ -0,0 +1,32 @@
+---
+---
+
+Tests only — no package changes, nothing to release.
+
+Reconciles the designer form against the Zod for the region-bearing flow nodes
+(#4045). `loop` / `parallel` / `try_catch` each carry two descriptions of the same
+config — a hand-written `configSchema` on the descriptor and a Zod schema in
+`control-flow.zod.ts` — and nothing compared them. #4064 pinned the shape of the
+first; this pins the relationship, so neither side can gain or lose a key without
+the other noticing.
+
+The two are **not** merged into one source, because measurement says that does not
+work here: generating from the Zod emits 9–17× more schema at +9 levels of depth
+(`loop` 597 → 5,537 chars, `parallel` 294 → 5,112, `try_catch` 737 → 10,739), with
+no `$defs`/`$ref` — `FlowNodeSchema` is inlined at every region key, so a loop body
+would arrive as the whole node/edge definition instead of the opaque array the
+designer needs for a canvas-edited sub-graph. A projection pruning ~90% back off
+would leave three things to maintain instead of two.
+
+So the divergence is legitimate, and what is enforced is that it stays declared: a
+`DELIBERATELY_SHALLOW` ledger names each shallow key with a reason, and every entry
+must name a key both sides still declare, so it cannot rot.
+
+Compares key sets rather than generated shapes on purpose — generating needs
+`z.toJSONSchema`, and `service-automation` does not depend on `zod`. The Zod's key
+set is reachable via `schema.shape` without that dependency, and the key set is
+where the drift that matters shows up.
+
+Verified to bite in all three directions: a Zod key the form does not offer, a form
+key the Zod rejects, and a ledger entry pointing at a renamed key each turn the
+suite red with the offending name in the message.

.changeset/dispatcher-handler-ready-class-wide.md

@@ -0,0 +1,15 @@
+---
+'@objectstack/runtime': patch
+'@objectstack/metadata-protocol': patch
+---
+
+Gate every dispatcher service domain on `handlerReady` instead of on slot occupancy (#4058 step 2).
+
+#4000 made the `/analytics` domain execute ADR-0076 D12's third conclusion ("consumers treat only `handlerReady: true` as a real capability"); every other domain still gated on "is a service registered", so a self-declared stub occupying `automation` / `notification` / `ai` / `file-storage` / `i18n` was called like a real implementation and its fabricated answer went out as a 200. Step 1 (#4082) made the two kinds of dev implementation distinguishable; this is the gate that reads the distinction.
+
+- The `/analytics`, `/automation`, `/notifications`, `/ai`, `/storage` and `/i18n` domains, the route-mount gate, discovery's `routes`/`features`, and the metadata-protocol builder's route advertisement now share one predicate (`isServiceServeable`): a slot whose occupant self-declares `handlerReady: false` is answered exactly as an empty slot is — the domain's existing 404, or the explicit 501 `/storage` and `/i18n` use. One predicate, so what is advertised and what is served cannot disagree.
+- `handlerReady`, not `status`, is the test. An implementation that declares `degraded` defaults to `handlerReady: true` and keeps serving — which is why the in-memory `file-storage` and `i18n` implementations are unaffected.
+- `discovery.services.*` stays presence-gated: a registered stub still reports `{ enabled: true, status: 'stub', handlerReady: false }` (with no `route`), which says strictly more than collapsing it to `unavailable` would.
+- `/ai` improves for the stub case: an occupied-but-unserveable slot used to fall through to a 503 "AI service routes not yet initialized" and lose the `GET /ai/agents` empty-list answer the console polls for on every navigation. Both are restored.
+
+No change for a host whose services are real implementations. If you register your own stub under one of those six slots and relied on the dispatcher calling it, either drop the `handlerReady: false` self-declaration (declare `degraded` if it genuinely serves) or install the real service. Not gated, deliberately: `/data`, `/meta`, `/auth` and the security path — their dev stubs back the dev stack's own core loop, and gating them would 404 the dev stack itself.

.changeset/dispatcher-handler-ready-gate.md

@@ -0,0 +1,23 @@
+---
+'@objectstack/core': patch
+'@objectstack/plugin-dev': patch
+'@objectstack/runtime': patch
+---
+
+Every in-memory fallback and dev stub now self-describes with the standard `__serviceInfo` descriptor, classified by what it actually is (#4058 step 1).
+
+ADR-0076 D12 gave services one way to say "I am not the real thing", but the producers never converged on it:
+
+- The kernel's own fallbacks (`createMemoryCache` / `Queue` / `Job` / `I18n` / `Metadata`) carried `_fallback: true` — a marker **no** consumer recognized, `readServiceSelfInfo` included — so both discovery builders reported them as fully `available`.
+- `plugin-dev` marked all of its implementations with the same `_dev: true`, normalized to `status: 'stub', handlerReady: false`. That declared a working in-memory search index exactly as fake as an AI stub returning invented text.
+
+Both now carry `__serviceInfo`, split by a rule that holds across the whole set:
+
+- **`degraded`** — really does the work, with reduced capability: `cache`, `queue`, `job`, `file-storage`, `search`, `i18n`, `metadata`, `workflow`, `realtime`. Its answers are true answers; the `message` names what is missing (no persistence, no scheduling timer, no state-machine validation, …).
+- **`stub`** — the answer is fabricated: `ai`, `automation`, `notification`, `data`, `auth`, `security.permissions`, `security.rls`, `security.fieldMasker`. Never to be mistaken for a capability.
+
+`handlerReady: false` is set independently wherever no HTTP handler serves the slot (`cache` / `queue` / `job` / `realtime`, and every `stub`).
+
+Discovery output changes accordingly — a kernel fallback that used to report `status: 'available'` now reports `degraded` with an explanatory message. No routing, gating, or dispatch behavior changes: every dispatcher domain still resolves services exactly as before. Consumers reading `discovery.services.*` get the truth instead of a uniform claim.
+
+For anything that duck-typed the old markers: `svc._fallback` / `svc._dev` → `readServiceSelfInfo(svc)` from `@objectstack/spec/api` (the legacy `_dev` key is still understood by that reader, so third-party stubs carrying it keep working).

.changeset/honest-service-self-description.md

@@ -0,0 +1,42 @@
+---
+"@objectstack/plugin-hono-server": minor
+---
+
+fix(plugin-hono-server): stop gating the current-user endpoints behind `registerStandardEndpoints` (#4073)
+
+`registerStandardEndpoints` gated two unrelated things behind one flag:
+
+- **Duplicate supply** — raw `POST/GET /api/v1/data/:object` (create + read
+  only), which `@objectstack/rest` also serves and, registering first, is what
+  actually answers; plus `GET /api/v1/discovery` and
+  `/.well-known/objectstack`, which the dispatcher and REST own and which this
+  surface already cedes to them (#4018).
+- **Sole supply** — `GET /api/v1/auth/me/permissions`,
+  `/api/v1/auth/me/localization` and `/api/v1/me/apps`. Nothing else in the
+  platform mounts these: neither `@objectstack/rest` nor `@objectstack/runtime`
+  registers any `/me/*` route, the console's entire permission layer reads
+  `/auth/me/permissions`, the console reads `/auth/me/localization` for regional
+  defaults, and `core`'s auth gate allow-lists `/me/apps` + `/me/localization`
+  as endpoints a gated user MUST still reach to bootstrap the remediation UI.
+
+`os serve` gets all of it only because the flag defaults to `true` — the CLI
+constructs `new HonoServerPlugin({ port })`. So `registerStandardEndpoints:
+false`, whose documented job is the optional CRUD/discovery convenience surface,
+silently took the console's permissions and localization down with it.
+
+The three current-user endpoints now register **unconditionally**, and the flag
+covers the duplicate half only — what its name and docs always claimed.
+
+**FROM → TO.** If you set `registerStandardEndpoints: false` and worked around
+the missing endpoints (proxying `/auth/me/permissions` yourself, or pinning the
+flag to `true` purely to keep them), you can drop that workaround: the endpoints
+are now present either way. No route is removed and no response shape changes,
+so a host that left the flag at its default sees no difference. If you relied on
+`false` meaning "this plugin mounts no `/api/v1` routes at all", that is no
+longer true — it never was for `os serve`, which is the only host that shipped
+the flag's default.
+
+Also removes three unreferenced `*_ENDPOINT_PRIORITY` constants;
+`DISCOVERY_ENDPOINT_PRIORITY = 900` in particular implied a route-priority
+mechanism that does not exist (precedence here is Hono's
+first-registration-wins).

.changeset/hono-current-user-endpoints-ungated.md

@@ -0,0 +1,68 @@
+---
+"@objectstack/spec": major
+---
+
+refactor(spec)!: retire three orphan operator vocabularies (objectui#2945 Track A)
+
+An audit of every comparison/aggregation vocabulary the spec ships
+(objectstack-ai/objectui#2901) found the operator vocabularies had multiplied
+past what any code consults. Three had **no importer at all** — not in this
+repo, not in objectui, not in cloud — and each contradicted the vocabulary that
+is actually enforced. Removed rather than reconciled: a second name for one
+concept is how they drifted apart in the first place.
+
+**`AggregationFunctionEnum`** (`shared/enums.zod.ts`). Its own doc comment
+claimed it was *"used across query, data-engine, analytics, field"*. It was used
+by nothing. `AggregationFunction` (`data/query.zod.ts`) is the vocabulary the
+query engine, `service-analytics`' dataset compiler and the native-SQL strategy
+all gate on — and the two disagreed: this one carried
+`percentile`/`median`/`stddev`/`variance`, that one carries
+`array_agg`/`string_agg`. It also exported a *type* named `AggregationFunction`
+while `data/query.zod.ts` exports a *value* of that name, so the two occupied
+the same identifier in different declaration spaces with different members.
+
+**`FilterOperator`** + `EventFilterCondition` + `EventFilterSchema`
+(`api/websocket.zod.ts`), reached from `EventSubscriptionSchema.filters`. No
+runtime ever evaluated an event filter — `matchesSubscription` matches on object
+name and event type only (`contracts/realtime-service.ts`) — and the
+subscription shape the transports actually carry is the separate, deliberately
+unvalidated `filters: z.unknown()` on `SubscriptionEventSchema`
+(`api/realtime.zod.ts`). So this was a *second* modelling of event filtering
+that described a capability no code provided: a subscriber who set `filters`
+received every event regardless.
+
+The `filters` **key stays**, now typed `z.unknown()` with the same
+NOT-YET-ENFORCED marker as its `api/realtime.zod.ts` counterpart. Retiring an
+object key requires a tombstone plus a conversion (ADR-0104), which is the right
+rule and the wrong trade here — there is no author to migrate for a shape nothing
+validated, and Track A is meant to carry no migration. The two subscription
+surfaces now describe event filtering identically, and neither implies an
+enforcement that does not exist. Whichever grows real filtering should lower onto
+`AST_OPERATOR_MAP` rather than reintroduce a vocabulary of its own.
+
+**`ODataFilterOperatorSchema`** (`api/odata.zod.ts`). Nothing parses an OData
+`$filter` against it — `$filter` is carried as an opaque string on
+`ODataQuerySchema` and as the `odata` adapter template in
+`query-adapter.zod.ts` — and an enum mixing operators with `(`/`)` could not
+validate an expression anyway, since it describes tokens, not a grammar. A real
+implementation needs a parser, and that parser should lower onto
+`AST_OPERATOR_MAP` like every other entry point.
+
+**Breaking, in the narrowest sense.** All three were reachable as public
+exports (`@objectstack/spec/shared` and `@objectstack/spec/api`), so this is a
+`major`. No consumer exists to break: verified by grep across framework
+`packages/` + `apps/`, objectui, and cloud. Nothing is *narrowed* — no accepted
+value stops being accepted, so no already-stored metadata or in-flight payload
+changes meaning. That is what made this the one track of objectui#2945 that was
+safe to start; narrowing `VALID_AST_OPERATORS` or retiring a
+`VIEW_FILTER_OPERATORS` alias is not, and remains blocked on #3948.
+
+The generated artefacts move with the deletions, as the ratchets require:
+`json-schema.manifest.json` drops the five unpublished schemas,
+`authorable-surface.json` the seven keys of the two deleted objects,
+`api-surface.json` the eight exports, and the three reference-doc pages are
+regenerated.
+
+Verified: full `@objectstack/spec` suite **6917 tests across 266 files**, plus
+`tsc --noEmit`, `check:docs`, `check:api-surface`, `check:authorable-surface` and
+`check:skill-docs`, all clean.