Merge origin/main: keep both halves of the formula suite's tail

Both sides appended to the end of matches-filter-temporal-conformance.ts:
main added the note explaining why the token axis cannot apply to an RLS
`check` (it is a CEL expression, so a `{token}` string never reaches this
evaluator), and this branch added the Field.time sweep. They are
complementary, so both are kept — with one sentence added to the note
recording that the same reasoning covers the wall-clock cases, which carry no
token spelling at all because no date macro resolves to a time of day.

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

Author: claude

.changeset/ai-agents-fallback-envelope.md

@@ -0,0 +1,47 @@
+---
+"@objectstack/runtime": patch
+---
+
+fix(runtime): the `/ai/agents` degraded fallback answers in the declared envelope (#4053)
+
+`GET /ai/agents` was the last unenveloped SDK-addressable route. The framework's
+degraded fallback — what an open-source runtime with no `service-ai` answers —
+now returns `{ success: true, data: { agents: [] } }` via `deps.success`, and the
+route-envelope guard's last ratchet retires with it: **0 ratcheted on both
+surfaces.**
+
+## Why `data: { agents }` and not `data: []`
+
+#3983 set the precedent that `data` carries the payload directly, and following it
+here would have looked consistent. It would also have been wrong, and silently so.
+
+`AiAgentsResponseSchema` is a **declared** payload schema; share-links' `{ links }`
+was an ad-hoc wrapper with none. So this is the #3843 relocation — the declared
+payload moves under `data` unchanged, the way `SettingsNamespacePayload` did —
+rather than a reshape.
+
+That distinction decides the blast radius. `unwrapResponse` returns `body.data`
+when a body has a boolean `success` **and** a `data` key, so:
+
+| conversion | `client.ai.agents.list()` |
+|---|---|
+| `data: { agents }` (this one) | reads `.agents` off it — **works** |
+| `data: [...]` (flattened) | `.agents` is `undefined` → **`[]`** |
+
+An empty list is not a visible failure on this route. `useAiSurfaceEnabled` gates
+the entire AI surface on `agents.length > 0`, and an empty catalog is the *correct*
+answer for a seat-less user (ADR-0068) or a Community-Edition deployment. The
+broken state and the legitimate one are indistinguishable — no error, no 403, no
+log.
+
+## Consequence: no lockstep
+
+Because the SDK reads both shapes identically, **each surface converts on its own
+schedule**. Cloud's `service-ai` still answers unenveloped and keeps working
+unchanged; objectui already reads all four shapes (objectui#2992). The
+"three repos in one batch" framing #4053 opened with does not apply to this
+variant.
+
+Five tests in `@objectstack/client` pin it, including the road not taken: the
+flattened body asserts `[]`, so the cost of choosing it is recorded rather than
+rediscovered.

.changeset/app-runtime-hooks-artifact-boot.md

@@ -0,0 +1,53 @@
+---
+'@objectstack/cli': patch
+---
+
+**A config-booted app no longer loses its `onEnable` — every `script` action's
+handler reaches the engine again instead of 404'ing at dispatch (#4095).**
+
+`os serve <config>` calls `createStandaloneStack()`, which reads
+`dist/objectstack.json` and returns a ready-made `AppPlugin` for the app. That
+satisfied serve's "does the host already wrap itself with an AppPlugin?" guard,
+so the `new AppPlugin(config)` built from the LOADED MODULE — the only one
+carrying the module's `onEnable` — was skipped. A JSON artifact cannot hold a
+function, so the app booted with all of its metadata and none of its code.
+
+On `examples/app-todo` that meant eight declared `script` actions, zero
+registered handlers, and every button answering
+`404 Action 'complete_task' on object 'todo_task' not found`. The example is
+correctly authored: it declares `target: 'completeTask'`, registers
+`todo_task:completeTask`, and exports `onEnable`. serve carried that hook intact
+all the way to the branch that discarded it.
+
+Serve now grafts the module's executable members onto the app bundle already
+registered, rather than dropping them with the wrap:
+
+- Only members `AppPlugin` actually executes travel — `onEnable` and the
+  `functions` map that string-named hook/job handlers resolve against. (`onDisable`
+  is deliberately excluded: it is declared in `packages/spec` but no kernel,
+  runtime or service ever calls it, so grafting it would wire a hook nothing
+  runs.)
+- The artifact stays the metadata source of truth. Neither side is a superset —
+  the artifact carries compile-time enrichment the config never has (ADR-0046
+  packaged docs, which serve already grafts the other way) — so this moves code
+  only, and never metadata.
+- Targeting is by `manifest.id`, so a host composing several `AppPlugin`s can
+  never have one app's handlers attached to another. With no id to match, it
+  falls back to the single app bundle present and refuses when there are several.
+- A bundle's own value always wins, so a host that wrapped itself on purpose is
+  untouched.
+- Code that finds no bundle to land on is now reported with a boot warning naming
+  the consequence ("they 404 at dispatch") instead of vanishing. That silent drop
+  is what hid this.
+
+Verified end to end on `examples/app-todo`: `POST /api/v1/actions/todo_task/complete_task`
+went from `404 RESOURCE_NOT_FOUND` to `{"success":true}`, `export_csv` now returns
+real CSV, and the `[action-governance]` boot warning naming all eight actions is
+gone. 14 unit cases pin the graft and — as importantly — the cases where it must
+refuse; one end-to-end case boots a real stack through `bin/run-dev.js` and fails
+against the pre-fix command.
+
+Note that `os serve <config>` still cannot boot at all when `dist/objectstack.json`
+is absent (#4085, `Service 'manifest' is async - use await`). That was verified to
+be a **separate** defect on the other side of the same fork, not this one: the
+failure reproduces unchanged with this fix applied.

.changeset/connector-descriptors-meet-their-contract.md

@@ -0,0 +1,62 @@
+---
+"@objectstack/spec": minor
+"@objectstack/service-automation": patch
+"@objectstack/runtime": patch
+---
+
+fix(spec,runtime,service-automation): `IAutomationService` declares the connector registry it already serves (#4127)
+
+The fourth and last of the dispatcher call sites #4127 found calling a method its
+contract never declared. The first three shipped in #4143; this one was held back
+because the fix is a **type move**, not a type addition — `ConnectorDescriptor`
+was declared in `@objectstack/service-automation`'s engine, which is one
+*implementation* of `IAutomationService`. A contract cannot name a type that
+lives inside its own implementation, so `getConnectorDescriptors` could not be
+declared at all until the type had a home in the spec.
+
+**`IAutomationService` += `getConnectorDescriptors?()`.** It is the sibling of
+`getActionDescriptors`, which the contract has declared since ADR-0018: the two
+fill the flow designer's `connector_action` node together — node vocabulary from
+one, the connector → action → input pickers from the other. Only one of them was
+written down. `GET /api/v1/automation/connectors` has served the other since
+ADR-0022 by probing for the method and then re-typing its own result as `any` to
+filter on `?type=`, which is a filter on a field the type system did not know
+existed — one typo from silently matching nothing and answering an empty
+registry, which is also what this route legitimately returns when the method is
+absent, so the failure had no distinguishable symptom.
+
+Optional for the same reason `getActionDescriptors` is: a connector registry is a
+capability of the flow-engine implementation, not a property of every automation
+slot. A script-runner filling the slot has no connectors to describe, and the
+route answers an empty registry rather than a 404 — the `handlerReady` posture
+does not apply, since the slot is serveable and only this capability is absent.
+
+**`ConnectorDescriptor` / `ConnectorActionDescriptor` / `ConnectorOrigin` /
+`ConnectorState` move to `@objectstack/spec/integration`**, beside the ADR-0097
+provider contract, for the reason that file already states about itself: they are
+pure types, so a connector plugin — or a designer client, or the dispatcher —
+speaks about registered connectors depending only on the spec, with no runtime
+coupling to the engine. `ConnectorOrigin` is ADR-0097 §4 vocabulary and
+`ConnectorState` is #3017 vocabulary; neither was ever engine-private in meaning,
+only in location.
+
+Nothing is renamed and no shape changes. `@objectstack/service-automation`
+imports the four back and re-exports them from its index — the same names, from
+the same entry point — so every existing importer compiles unchanged.
+`ConnectorState` joins that re-export, which it should have been in all along: it
+is a required field of the descriptor the index has always exported.
+
+**The test fixture had already drifted, which is the concrete cost.** The
+dispatcher's connector mock declared `{ name, label, type, actions }` and omitted
+`origin` and `state` — both **required** on `ConnectorDescriptor`, and both the
+fields a designer reads to tell a live declarative instance from a plugin one
+(ADR-0097 §4), or a dispatchable connector from a degraded one that is listed
+honestly rather than hidden (#3017). Nothing caught it, because an undeclared
+return type cannot be checked against. The fixture is typed now, so it cannot
+drift again, and a new test pins that `origin` / `state` / `degradedReason`
+survive the hop through the route rather than only `name` and `type`.
+
+Verified: `@objectstack/spec` **7089 tests / 272 files** (2 new contract tests),
+`@objectstack/service-automation` **457 / 41**, `@objectstack/runtime`
+**218 http-dispatcher tests** (1 new), `tsc --noEmit`, `pnpm lint`, the liveness
+and empty-state gates, and the three generated-artifact gates — all clean.

.changeset/dispatcher-call-sites-meet-their-contracts.md

@@ -0,0 +1,70 @@
+---
+"@objectstack/spec": minor
+"@objectstack/runtime": patch
+"@objectstack/service-i18n": patch
+---
+
+fix(spec,runtime,service-i18n): the dispatcher domains and their service contracts describe the same surface (#4127)
+
+#4087 retired a `/storage` bridge that called `upload(key, data, options?)` as
+`upload(file, { request })` — a shape no implementation has. Sweeping the other
+dispatcher domains against `packages/spec/src/contracts/*` found the mirror-image
+gap in three places: the call site and the implementation agreed, and the
+**contract** was the thing that had never been written down. Each one was worked
+around at the call site with `typeof x.foo === 'function'` — a duck-type is what
+"the contract does not cover this" looks like when nobody fixes the contract.
+
+Fixed at the contract, per Prime Directive #12.
+
+**`INotificationService` — the inbox half.** `listInbox` / `markRead` /
+`markAllRead` now exist, with `InboxQuery` / `InboxNotification` /
+`InboxListResult` / `MarkReadResult`. Three SDK-expressed routes
+(`notifications.list` / `.markRead` / `.markAllRead`) have rested on them all
+along, implemented by `service-messaging`, while this contract described only
+`send`. The cost was not theoretical: the dev notification stub implements
+exactly `send` and `sendBatch` **because it followed the contract**, so the one
+implementation written to spec was the one the dispatcher had to duck-type past.
+
+They are optional, and the probe stays: an inbox needs a durable store, and a
+send-only provider (SMTP, Twilio, a Slack webhook) fills the slot legitimately
+without one. `handlerReady` cannot express that — the slot is serveable, one
+capability of it is absent. The `/notifications` domain now takes
+`INotificationService` instead of `as any`, and each write route probes its own
+method rather than riding the entry `listInbox` check (they are separately
+optional, so "has an inbox to read" never implied "has read-state to write").
+
+**`II18nService.getFieldLabels`.** Both serving surfaces — the dispatcher's
+`/i18n/labels/:object/:locale` and service-i18n's own mount — probed for it and
+both documented it as "optional on `II18nService`", which was not true. It is
+now. service-i18n's probe loses two casts with it (one through
+`Record<string, unknown>`, one re-declaring the signature inline).
+
+**`IAutomationService.getFlowRuntimeStates`** + the `FlowRuntimeState` type.
+`GET /automation/_status` (and the CLI boot summary, and the
+`kernel:bootstrapped` audit) already called it while the contract stopped at
+`listFlows(): string[]`. The dispatcher's inline cast declared it as
+`{ name, enabled, bound }` — a third copy of the shape and a narrower one than
+the engine returns, dropping the `status` / `triggerType` / `object` fields that
+say WHY a flow is unbound.
+
+Two runtime fixes fell out of the same sweep:
+
+- **`POST /automation/trigger/:name` now builds a real `AutomationContext`.**
+  It passed the raw HTTP body to `execute(name, body)`, so the
+  `{ recordId, objectName, params }` translation never ran and — the sharper
+  half — no caller identity was forwarded. A flow's default `runAs` is `'user'`,
+  and a `runAs:'user'` run whose trigger resolved no user has its data
+  operations REFUSED (#3760, fail-closed), so `client.automation.trigger()`
+  could not run a data-touching flow at all while `POST /:name/trigger` could.
+  service-automation's own comment claims "most trigger surfaces (REST action /
+  trigger endpoint) already resolve the full envelope"; for this endpoint it was
+  not true. Both routes share one context builder now.
+- **The dead `automationService.trigger(...)` probe is gone.** Nothing in the
+  repo has ever implemented `trigger` on the automation slot and the contract
+  never declared it, so the branch was unreachable on every deployment and its
+  `execute` "fallback" was the route. Declaring `trigger?` would have blessed a
+  second name for `execute`; the dead branch is deleted instead.
+
+No migration. Every added contract member is optional, so existing
+implementations stay valid; the two runtime fixes only make routes that were
+failing or degraded behave like their working twins.

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

@@ -0,0 +1,53 @@
+---
+"@objectstack/plugin-hono-server": minor
+---
+
+feat(plugin-hono-server): export `registerCurrentUserEndpoints` so a host without the plugin can still supply them (cloud#924)
+
+`GET /api/v1/auth/me/permissions`, `/api/v1/auth/me/localization` and
+`/api/v1/me/apps` are the platform's **sole** supply — neither
+`@objectstack/rest` nor `@objectstack/runtime` registers any `/me/*` route, the
+objectui console reads the first for its whole permission layer and the second
+for regional defaults, and `core`'s auth gate allow-lists the last two as
+endpoints a gated user MUST still reach. #4073/#4079 freed them from the
+`registerStandardEndpoints` flag, but left the supply welded to
+`HonoServerPlugin`: a host that stands up a bare `HonoHttpServer` and registers
+it as `http.server` itself — rather than mounting the plugin — got no provider at
+all, and the console's FLS / `apiOperations` had no server-side answer on that
+startup path.
+
+Registration needs a Hono app and a service locator, not ownership of the
+listening socket, so it is now a standalone module (`./current-user-endpoints`)
+that both shapes call:
+
+```ts
+import { registerCurrentUserEndpoints } from '@objectstack/plugin-hono-server';
+
+const httpServer = new HonoHttpServer();
+kernel.registerService('http.server', httpServer);
+registerCurrentUserEndpoints({
+  rawApp: httpServer.getRawApp(),
+  // any { getService, logger } — a PluginContext satisfies it structurally
+  ctx: { getService: (n) => { try { return kernel.getService(n); } catch { return undefined; } } },
+});
+```
+
+It is **idempotent**: it returns `false` and registers nothing when all three
+paths are already served, so a host may both call it eagerly on the raw app AND
+mount the plugin — the plugin's `kernel:ready` registration then no-ops instead
+of shadowing the host's routes with dead duplicates. Registering early matters,
+because Hono's only route precedence is first-registration-wins and plugin-auth
+mounts a `/api/v1/auth/*` wildcard that `/auth/me/*` must outrank.
+
+**No behaviour change for existing hosts.** `os serve` and every host that mounts
+`HonoServerPlugin` register the same three routes, in the same `kernel:ready`
+position, with the same response shapes — the plugin now delegates to the shared
+registrar instead of owning a private method.
+
+**Moved exports (same package, same names, no rename).** `foldWildcardSuperUser`,
+`clampManagedObjectWrites`, `seedSuperUserRestrictedObjects`,
+`annotateEffectiveApiOperations`, `ManagedSchemaLike` and `ApiExposureSchemaLike`
+now live in `./current-user-endpoints` alongside the endpoint they shape. Importing
+them from the package root (`@objectstack/plugin-hono-server`) is unchanged; only a
+deep import of `.../dist/hono-plugin` would need updating, and the package exposes
+no such subpath.

.changeset/retire-the-dev-stub-table.md

@@ -0,0 +1,33 @@
+---
+'@objectstack/plugin-dev': minor
+---
+
+feat(plugin-dev)!: the stub table is retired — DevPlugin assembles real plugins and registers no service implementations of its own (ADR-0115, #4093, #4104).
+
+DevPlugin used to fill every core-service slot no real plugin occupied with a dev stub. Every one of those stubs is gone. A slot nothing fills now stays EMPTY, exactly as in production: routes answer 404/501, discovery reports `unavailable`, and in-process consumers must handle absence — which production already required of them. FROM → TO per retired slot:
+
+| Slot | The stub did | Instead |
+|:---|:---|:---|
+| `security.permissions` | allow-all `checkObjectPermission()` | install `@objectstack/plugin-security` (already part of the default assembly) |
+| `security.rls` | compiled no row filter | same — `plugin-security` |
+| `security.fieldMasker` | returned results unmasked | same — `plugin-security` |
+| `auth` | `verify()` accepted everyone as admin | install `@objectstack/plugin-auth` (already part of the default assembly) |
+| `data` | accepted writes, stored nothing | install `@objectstack/objectql` (already part of the default assembly) |
+| `ui` | shapeless `{}` placeholder | nothing consumed it; handle the absent slot |
+| `ai` | placeholder chat/complete answers | install a real AI service |
+| `automation` | `execute()` reported success without running | install an automation engine plugin |
+| `notification` | claimed "sent", delivered nothing | install a notification service |
+| `file-storage` | in-memory files lost on restart | `@objectstack/service-storage` — now auto-wired by DevPlugin when installed (local-disk adapter) |
+| `realtime` | in-process pub/sub copy | `@objectstack/service-realtime` — now auto-wired by DevPlugin when installed (its default in-memory adapter) |
+| `search` | in-memory substring index | no consumer resolves this slot; a future search service ships its own dev strategy |
+| `workflow` | unvalidated state transitions | no consumer resolves this slot; a future workflow service ships its own dev strategy |
+| `metadata` | a second hand-written copy of core's `createMemoryMetadata` | no behavior change — the kernel pre-injects core's fallback for empty core slots (`CORE_FALLBACK_FACTORIES`), and ObjectQL registers the real metadata service in the default assembly |
+| `cache` / `queue` / `job` / `i18n` | re-registered core's `createMemory*` fallbacks | no behavior change — the kernel pre-injects the same core fallbacks automatically; install `@objectstack/service-cache` / `service-queue` / `service-job` for real engines, and i18n auto-wires from the stack's translations (unchanged) |
+
+Also new, from the same ADR:
+
+- **Production guard** (first shipped with the security-trio subset): `DevPlugin.init()` throws when `NODE_ENV === 'production'` — the assembly is built around a well-known default auth secret and a seeded dev admin. Escape hatch: `OS_ALLOW_DEV_PLUGIN=1`.
+- **Assembly auto-wire**: `@objectstack/service-storage` and `@objectstack/service-realtime` are wired as optional child plugins when installed (both ship with DevPlugin's dependencies), so dev keeps working file storage and realtime through real implementations.
+- `options.services` keys for the retired stubs are accepted and ignored; `'file-storage'` / `'realtime'` now toggle the real service wiring.
+
+One-line fix for an upgrading stack: if something you called in dev now throws "service not found" or 404s, that call was consuming a fabricated answer — install the real service for that slot (table above), or make the caller tolerate absence the way it already must in production.