Merge origin/main into the /storage bridge retirement (#4087)

#4058 step 2 (#4086) landed in between and touched the same ground: it gave
every dispatcher domain the shared `isServiceServeable` predicate, `/storage`
among them. Resolution:

- `domains/storage.ts` — deletion stands. #4086 gated the bridge; it did not
  fix the call, which is still `upload(file, { request })` against
  `upload(key, data, options?)`. Gating a handler that cannot serve either
  answer only changes which failure a caller gets.
- `http-dispatcher.ts` discovery — take main's `isServiceServeable` and drop
  the local `filesServeable` this branch had introduced. Same predicate, better
  home. The comment records why `file-storage` stays gated even though its
  surface is no longer a dispatcher domain: `handlerReady` is not standing in
  for anything there, it IS the fact the advert needs.
- The two `/storage` cases #4086 added to the handlerReady block go with the
  domain. The `degraded store keeps serving` one asserted a 200 off `upload`
  mocked to resolve `{ key }` — a return value `Promise<void>` does not have,
  the same imagined contract every other retired storage test encoded.
- `metadata-protocol` — `file-storage` stays in `DISPATCHER_GATED_SERVICES`;
  its comment no longer cites a `/storage` bridge that exists.

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

Author: claude

.changeset/degraded-boot-stderr-premise.md

@@ -0,0 +1,46 @@
+---
+'@objectstack/types': patch
+'@objectstack/objectql': patch
+'@objectstack/runtime': patch
+'@objectstack/cli': patch
+---
+
+**Correct the stale premise left behind by #4012: the degraded-boot stderr copy
+survives the operator's LOG LEVEL, not `os serve`'s boot-quiet window.**
+
+`emitDegradedBootBanner` writes the `OS_ALLOW_DRIVER_CONNECT_FAILURE` banner to
+stderr in addition to `logger.warn`, and every comment and test name explaining
+why cited the same reason: `os serve` swallowed all of stdout while the kernel
+booted, and `Logger` routes `warn` to stdout. #4012 fixed that — the boot window
+now buffers and replays `warn`-and-above — which retires the *stated*
+justification for a duplicate that is nonetheless still load-bearing:
+
+`Logger.write()` returns before touching a stream when the record is below
+`config.level`, so at `--log-level error`, `fatal` or `silent` the banner's
+`logger.warn` reaches **no** stream at all. A production host at `error` is
+exactly the deployment this escape hatch exists for, and exactly where a
+logger-only banner would vanish. Removing the stderr copy on the strength of
+#4012 would therefore have been a regression — so this documents the reason that
+is still true, in the places someone would read before deleting it:
+`degraded-boot.ts`, the engine's emit site, and all three parity tests
+(objectql, runtime, service-datasource), which are renamed off "which `os serve`
+boot-quiet cannot swallow" to "which the operator log level cannot filter away".
+
+The objectql parity test now proves the claim instead of asserting around it: it
+drives a **real** `ObjectLogger` at `level: 'error'` and requires the banner on
+stderr *and* nothing on stdout. Set the level to `warn` and it fails — so the
+test is pinned to the level filter rather than passing for any reason.
+
+Also corrected in the same sweep, all comment-only, all previously overstating
+what #4012 had not yet fixed:
+
+- the automation wiring summary (`format.ts`, `serve.ts`, its test) claimed the
+  boot window swallowed the engine's binding warnings. Its real justification is
+  stronger and unchanged: a flow that silently fails to arm emits **no** log line
+  at any level, so binding state has to be read off the live engine — absence of
+  a warning was never evidence of a bound flow.
+- the seed summary (`seed-summary.ts`, `format.ts`, its test) and `AppPlugin`'s
+  seed-outcome note attributed the silence to the boot window; the operative
+  gate is that `SeedLoader`'s result logs are `info`, under the default `warn`.
+
+No behavior changes.

.changeset/dispatcher-envelope-shared-predicate.md

@@ -0,0 +1,17 @@
+---
+---
+
+`domain-handler-registry.test.ts` now uses `envelopeViolations` instead of its own
+copy of the rule. Deliberately empty frontmatter: test-only, this releases nothing.
+
+That test hand-rolled "no key beside the envelope's own may hold the payload" for
+#4038. #4090 promoted the rule into the spec so it would stop having two
+definitions; leaving the local copy would have recreated the exact failure this
+line has been closing — one rule, two places, only one updated next time.
+
+The two were also not equivalent. The local set allowed any body whose top-level
+keys were `success` / `data` / `meta`, so it passed a success body with no `data`
+at all and one carrying an `error` beside `success: true`. The shared predicate
+rejects both, which makes this a strict tightening rather than a refactor:
+injecting `{ success: true }` into the producer now fails the suite, and used to
+pass it.

.changeset/dispatcher-handler-ready-gate.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/envelope-violations-predicate.md

@@ -0,0 +1,46 @@
+---
+"@objectstack/spec": minor
+---
+
+**`envelopeViolations` — the conformance check `BaseResponseSchema` cannot express.**
+
+Every conformance suite from the #3843 line leads with
+`BaseResponseSchema.safeParse(body)`, under a comment claiming it is "the contract
+itself, imported — not a restatement of it". That overclaimed, and the gap is
+demonstrable:
+
+```ts
+BaseResponseSchema.safeParse({ success: true })                        // passes
+BaseResponseSchema.safeParse({ success: true, data: link, link })      // passes
+```
+
+The schema declares no `data` — each response type adds its own via
+`.extend({ data })` — and a plain `z.object` strips unknown keys rather than
+rejecting them. So it catches the one drift it was added for (a missing or
+non-boolean `success`, the flag `unwrapResponse` keys on) and nothing else. The
+second body above is exactly the duplicate-payload drift `/share-links` shipped
+until #4038 / #4049 removed it, and `safeParse` passed it the whole time.
+
+`envelopeViolations(body)` returns every departure from the declared envelope as
+readable reasons, empty when conformant:
+
+- `success` must be a **boolean**
+- a success body must carry `data` (`undefined` only — `null`, `[]`, `{}`, `0`
+  and `''` are payloads, not absences)
+- a failure body must carry `error` with a string `code` and `message` — the
+  nested form, not the pre-#3675 bare string
+- no top-level key outside `success` / `data` / `error` / `meta`, which is the
+  general form of the duplicate-payload drift
+
+It deliberately does **not** check the shape of `data`: that is each route's own
+payload schema, and conflating the two is what let `SettingsNamespacePayload`
+describe a whole body before #3843 and only `data` after it.
+
+The ten conformance suites now assert it beside `safeParse`, and their comments
+say what each of the two actually proves. Reintroducing the `/share-links`
+duplicate key is caught by the new assertion and still passes the old one — which
+is the demonstration that the pairing is the point.
+
+Placed in `contract.zod.ts` beside the schema it completes, alongside the other
+plain predicates `spec/api` already exports (`standardErrorCodeForHttpStatus`,
+`readServiceSelfInfo`). No new package.

.changeset/retire-dispatcher-storage-bridge.md

@@ -53,9 +53,11 @@ Two follow-on corrections keep `declared === enforced`:
   every other path under it — service-storage's protocol above all — got the
   bridge's own 404 rather than falling through. Storage is ordinary catch-all
   traffic now.
-- Discovery advertises `routes.storage` only when the `file-storage` slot's
-  occupant actually mounts HTTP handlers (`handlerReady`, the predicate #4000
-  gave analytics), and plugin-dev's in-memory implementation now self-declares
-  `handlerReady: false` — with the bridge gone, nothing routes HTTP to it. It
-  keeps working for in-process callers; it is simply no longer advertised as a
-  reachable HTTP capability.
+- Discovery keeps gating `routes.storage` on `isServiceServeable` — the shared
+  `handlerReady` predicate #4058 step 2 introduced — and plugin-dev's in-memory
+  implementation now self-declares `handlerReady: false`. #4058 deliberately
+  left that one serving because the `/storage` bridge was still there to serve
+  it; with the bridge retired nothing routes HTTP to that slot, so `false` is
+  the honest value — the position `realtime` has held since ADR-0076 D12. The
+  implementation keeps working for in-process callers; it is simply no longer
+  advertised as a reachable HTTP capability.

.changeset/savemeta-persists-normalized-operators.md

@@ -0,0 +1,50 @@
+---
+"@objectstack/metadata-protocol": minor
+---
+
+feat(metadata): `saveMeta` persists the operator spellings the spec normalized (objectui#2945)
+
+`ViewFilterRuleSchema.operator` is `z.preprocess(normalizeFilterOperator, …)`, so
+a stored `notEquals` / `gt` / `isNull` is folded to its canonical form during
+save-time validation — and then the result was thrown away. `saveMetaItem`
+persists the authored body verbatim, deliberately: `parsed.data` strips the
+Studio-only auxiliary fields (`isPinned`, `isDefault`, `sortOrder`) that ride
+along with an overlay document (ADR-0005 §Validation).
+
+The consequence is that **every save mints new legacy-alias rows.** The ~30
+entries in `VIEW_FILTER_OPERATOR_ALIASES` are documented as *"a migration bridge
+[that] may be dropped in a future major"*, but there is no point at which the
+last alias row is behind you, so the bridge can never be dismantled — a
+migration that rewrote every existing row would be obsolete the moment the next
+console personalization PUT landed. That is prerequisite 2 of the vocabulary
+consolidation blocked in objectstack-ai/objectui#2945.
+
+`graftNormalizedOperators` grafts the normalization back on without giving up the
+verbatim body. It walks the authored value and `parsed.data` in lockstep **by
+structure** and copies across exactly one thing: an `operator` whose parsed value
+differs from the authored one.
+
+- **No key list to maintain.** `ViewFilterRule[]` appears at five declared sites
+  today (view `filter`, `ViewTab.filter`, page `filterBy`, and two
+  `component.zod.ts` block props) and the structural walk covers all of them,
+  plus any added later. Enumerating paths would have reproduced in this file the
+  exact duplication #2945 exists to remove.
+- **Nothing else moves.** Only an `operator` string is rewritten, and only where
+  both sides are strings — so a `$`-token `FilterCondition`, a different operator
+  vocabulary entirely, cannot be reshaped by accident. No key is added, removed,
+  reordered or defaulted; the unary `{field, operator}` form does not acquire a
+  `value` even though the schema's own output would give it one.
+- **Nothing is allocated when nothing changed**, so a body already written in
+  canonical form is returned by identity.
+
+Behaviour change worth stating plainly: a `GET` after a `PUT` now returns the
+canonical spelling rather than the one the author sent. That is the spelling the
+spec defines, every renderer accepts it (objectstack-ai/objectui#2974,
+objectstack-ai/objectui#2989 pinned all three of objectui's translation tables to
+the full vocabulary), and it is the point of the change. Existing rows are not
+touched — this stops the bleeding, it is not the migration.
+
+Verified: 11 new tests, including one that drives **every** alias the spec still
+folds through the real `ViewMetadataSchema` and asserts the persisted body comes
+out canonical; full `@objectstack/metadata-protocol` suite 110 tests / 18 files
+green.

.changeset/showcase-legacy-rowactions-specimen.md

@@ -0,0 +1,10 @@
+---
+---
+
+test(showcase): a specimen for legacy string rowActions (objectui#2960)
+
+Releases nothing. The change is confined to `@objectstack/example-showcase`,
+which is `"private": true` and never published — it adds the
+`showcase_task.legacy_row_actions` view (a fixture for the objectui#2960 bug
+class) and `recordIdParam` on `showcase_recalc_estimate`, so no consumer-facing
+package changes.

.changeset/temporal-conformance-matrix.md

@@ -0,0 +1,33 @@
+---
+"@objectstack/spec": minor
+"@objectstack/service-analytics": patch
+---
+
+feat(spec): a shared temporal conformance matrix, and the `$between` gap it found (ADR-0053 D-A3, #4081)
+
+`@objectstack/spec/data` gains `TEMPORAL_ROWS` and `TEMPORAL_CASES` — the
+single set of temporal filter cases every backend is checked against, the twin
+of the existing `FILTER_LOGIC_CASES`. Five backends consume it and assert **row
+results**: `driver-sql` (and, through the live-dialect CI job, real Postgres and
+MySQL), `driver-memory`, `driver-mongodb` (real MongoDB), the analytics preview
+evaluator, and `formula`'s RLS write-side `check`.
+
+This is the regression backstop ADR-0053 D-A3 has asked for since 2026-06 and
+the last of its decisions to be actioned. Four separate incidents — #3650,
+#3773, #3777, #4047 — were each found by a human by accident, and each left a
+suite proving only its own issue against its own fixture. Nothing held the
+backends to one standard, so the fifth divergence had nowhere to fail.
+
+**`service-analytics` — a real fix the matrix found on its first run.** The
+draft-preview evaluator had no `$between` case, so it fell through to its
+permissive `default` and matched **every** row: a drafted dashboard carrying a
+range filter charted the entire dataset, then changed its numbers at publish —
+the exact continuity the preview exists to provide. It now evaluates
+`$between`, sharing the upper-bound helper with `$lte` so the whole-day
+calendar-day rule (#3777) applies to a range's max as well.
+
+Also recorded (ADR-0053 D-A3.1): `$gt` with a bare-day comparand on a
+`datetime` column cannot agree between typed and type-blind backends, and the
+gap is irreducible without field types. It is asserted in the shared matrix on
+`date` only, with the `datetime` cell left to the typed drivers' own suites,
+rather than papered over.

.changeset/unknown-key-strictness-step2.md

@@ -0,0 +1,44 @@
+---
+"@objectstack/spec": major
+---
+
+feat(spec)!: reject unknown keys on RLS policies, sharing rules, and positions (#4001 step 2)
+
+Second click of the unknown-key strictness ratchet (first: flow + permission,
+#4071), extending `.strict()` + the `strictUnknownKeyError` fixable-error
+factory to the remaining small security-class authoring surfaces, per
+`docs/audits/2026-07-unknown-key-strictness-ledger.md`:
+
+- **`security/rls.zod.ts`** — `RowLevelSecurityPolicySchema` is `.strict()`.
+  A silently dropped key on an RLS policy meant a row-level restriction the
+  author wrote was never compiled into the filter. The runtime shapes
+  (`RLSUserContextSchema`, `RLSEvaluationResultSchema`) stay tolerant. The
+  retired `priority` key keeps its existing tombstone.
+- **`security/sharing.zod.ts`** — the sharing-rule surface is `.strict()`
+  (base + criteria extension + the `sharedWith` recipient shape). A silently
+  dropped key meant a share the author intended was never materialised.
+- **`identity/position.zod.ts`** — `PositionSchema` is `.strict()`, and gains
+  the author-facing `protection` block plus the ADR-0010 runtime protection
+  envelope (`_lock`, `_packageId`, `_provenance`, …) — closing the sibling
+  gap the #4071 ledger flagged: `applyProtection` stamps every registered
+  metadata type, and position was the last one whose schema could not
+  represent the stamp.
+
+**Migration.** Any key these schemas now reject was previously stripped and
+had **no runtime effect** — removing or renaming it never changes behavior.
+The error carries the fix; FROM → TO mappings baked in include:
+
+- RLS policy: `roles`/`role` → `positions` (ADR-0090 D3 rename),
+  `withCheck` → `check` (the PostgreSQL spelling), `condition`/`filter`/`where`
+  → `using`. `priority` stays a tombstone (#3896: OR-combined policies have no
+  precedence to order — delete the key).
+- Sharing rule: `criteria` → `condition` (the persisted row spells the
+  compiled predicate `criteria_json`; the authored key is the CEL
+  `condition`), `access`/`level` → `accessLevel`,
+  `recipient`/`shareWith`/`sharedTo` → `sharedWith`, `enabled` → `active`;
+  recipient `id`/`target` → `value`. `ownedBy` carries the removed
+  owner-type-rule prescription (only `criteria` rules are authorable).
+- Position: `title` → `label`; `permissionSets` / `users` are runtime
+  bindings (`sys_position_permission_set` / `sys_user_position`), never
+  authored on the position; `parent` is rejected with the flatness rule
+  (ADR-0090 D3 — hierarchy is the business-unit tree, not a position tree).

AGENTS.md

@@ -312,8 +312,9 @@ export default {
    working tree.
 3. **Add a changeset for feature work.** When the change is a feature or functional improvement, run `pnpm changeset` (or add a `.changeset/*.md` entry) describing it before committing. Pure bug fixes do **not** require a changeset.
    **Breaking changesets must carry their migration.** If the change removes or renames anything an author can write (a spec key, an export, a config field), the changeset body must state the FROM → TO mapping and the one-line fix — this text ships to consumers as `CHANGELOG.md` inside the npm package and is what an upgrading agent greps after the tombstone error. Removing an authorable spec key also requires a tombstone so the rejection itself carries the prescription — `retiredKey()` (`packages/spec/src/shared/retired-key.ts`) on a non-strict schema, or an entry in the relevant `UNKNOWN_KEY_GUIDANCE` / `*_RETIRED_KEY_GUIDANCE` map (see `object.zod.ts`, `ai/tool.zod.ts`) when the schema is `.strict()`. The changeset is one of fourteen surfaces a retirement touches — follow the `spec-property-retirement` skill (`.claude/skills/`) rather than reconstructing the kit, and note the two routes imply **opposite** liveness-ledger dispositions.
-4. Update `CHANGELOG.md` / `ROADMAP.md` if user-facing or architectural.
-5. **Delete temporary artifacts** — screenshots, traces, scratch logs, `.playwright-mcp/`, throwaway `tmp*.ts`, ad-hoc scripts. Repo must look identical to before, minus intended changes.
+4. **Added or removed a `packages/spec` export? Run `pnpm --filter @objectstack/spec gen:api-surface` and commit the result.** The `TypeScript Type Check` job diffs spec's built export surface against `api-surface.json`; a new export makes the snapshot stale and turns the job red. It reads the **built `dist` declarations**, so `OS_SKIP_DTS=1` — the flag you reach for to make local builds fast — skips exactly the artifact the gate inspects, and the check passes locally while failing in CI. Same shape for the other generated-artifact gates in that job (`check:docs`, `check:skill-refs`, `check:react-blocks`), which read `src/` and so do reproduce locally.
+5. Update `CHANGELOG.md` / `ROADMAP.md` if user-facing or architectural.
+6. **Delete temporary artifacts** — screenshots, traces, scratch logs, `.playwright-mcp/`, throwaway `tmp*.ts`, ad-hoc scripts. Repo must look identical to before, minus intended changes.
 
 ---