Merge origin/main into claude/exported-types-any-resolution-1x1erg

Two conflicts, both in code #4165 ("reject unknown keys across the app shell
and navigation tree") rewrote underneath this branch:

- `packages/spec/src/ui/app.zod.ts` — main turned the nav union into a
  `z.discriminatedUnion('type', …)` with `.strict()` members and kept the
  `z.ZodType<any>` annotation; this branch replaced that annotation with the
  real `NavigationItem`. Both are kept. Reconciling them needed one addition:
  main widens the member array (`as unknown as readonly [ZodObject<ZodRawShape>,
  …]`) because the members are lazySchema Proxies and a superRefine-wrapped
  variant, and `discriminatedUnion` then reports the union's output as
  `Record<string, unknown>` — which fits `z.ZodType<any>` and nothing sharper.
  The union therefore takes a matching cast back to `z.ZodType<NavigationItem>`,
  documented at the declaration: every branch of the type is still
  `z.infer<typeof XNavItemSchema>`, so only the MEMBERSHIP of the list is
  unchecked, and app.test.ts parses all nine variants.

- `AGENTS.md` — main added the `check:generated` aggregate section; this branch
  added `check:exported-any` to the "pure checks with no generator" list. Both
  are kept.

Also registers `check:exported-any` in `check-generated.ts`'s ledger, which
main added and which reconciles itself against package.json on every run.

Registers `check:variant-docs` in the same ledger while here: #4177 added the
script and #4183 added the reconciliation, neither PR could see the other, so
`check:generated` was already failing on `main` itself. One line, in a file this
branch was editing anyway.

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

Author: claude

.changeset/adr-0053-temporal-matrix-skewed-zone.md

@@ -0,0 +1,17 @@
+---
+---
+
+ci(temporal): run the non-SQL temporal backends under a skewed process zone too (#4081)
+
+The `temporal-conformance` job pinned `TZ: America/New_York` on the live
+Postgres/MySQL sweep only. `core`, `formula`, `driver-memory`, `driver-mongodb`
+and `service-analytics` — the backends where a stray `getFullYear()` or a
+local-midnight `new Date(y, m, d)` is easiest to write and hardest to see — kept
+running in the runner's default UTC, where every offset bug is invisible because
+the offset is zero.
+
+They now run in the same skewed zone, and both TZ-skewed steps carry a
+non-vacuity guard that fails the job if the process zone is UTC or the offset is
+zero, so the coverage cannot silently evaporate if the runner image changes.
+
+CI configuration only; releases nothing.

.changeset/adr-0104-remaining-flips-evidence.md

@@ -0,0 +1,4 @@
+---
+---
+
+docs(adr): ADR-0104 addendum — evidence for the remaining #3438 strict flips (D1 references/structured JSON gate on a per-deployment `os migrate value-shapes` scan; fresh datastores attest both flags at creation; the D2 action-param flip rides the 18.0 major with an escape hatch) — releases nothing.

.changeset/analytics-or-not-combinators.md

@@ -0,0 +1,40 @@
+---
+"@objectstack/service-analytics": patch
+---
+
+fix(service-analytics): a `$or` / `$not` filter no longer vanishes from an analytics query (#4128 follow-up)
+
+The last of the silently-dropped filter family. `normalizeAnalyticsFilters`
+produced a flat **array**, which cannot carry a disjunction, so both strategies
+skipped `$or` and `$not` outright — a widget or dataset whose filter used
+either compiled a WHERE clause that simply did not contain it, and drew every
+row. That is #3650's symptom, and unlike a rejected query it looks like a
+working chart.
+
+The normalizer now produces a **tree** (`normalizeAnalyticsFilterTree`), and
+each strategy compiles it the way its own backend expresses a disjunction:
+
+- **`NativeSQLStrategy`** builds the WHERE recursively, routing every leaf
+  through its existing clause emitter — so the storage-form coercion and the
+  calendar-day upper-bound rule (#3777) apply at every depth, including inside
+  an `$or`. Parentheses are explicit rather than relying on SQL precedence.
+- **`ObjectQLStrategy`** hands `$or` / `$not` to the engine, which speaks them
+  natively. AND-ed leaves still merge per field exactly as before, so a query
+  without combinators produces byte-identical engine input.
+- **`/analytics/sql`** renders the same tree, so the echoed statement keeps
+  reproducing what executes rather than showing a conjunction where the engine
+  runs a disjunction.
+- The **cross-object envelope check** now sees members nested inside an `$or`.
+  It rejects cross-object filters, so a member it could not see was a filter it
+  could not reject.
+
+Empty `$and` / `$or` arrays now throw instead of being ignored, matching the
+fail-closed stance of `read-scope-sql.ts` — the compiler in this same package
+that has always handled the full tree, and whose semantics the tree walker now
+mirrors deliberately.
+
+Cover is `native-sql-filter-logic-conformance.test.ts`, which runs the shared
+combinator table (`FILTER_LOGIC_CASES`, #3774) against a real SQLite engine and
+asserts row ids. The analytics raw-SQL path now stands beside `driver-sql`,
+`driver-memory`, `formula` and `read-scope-sql` under that one standard; 14 of
+its 17 cases fail without this change.

.changeset/app-navigation-strict.md

@@ -0,0 +1,48 @@
+---
+"@objectstack/spec": major
+"@objectstack/platform-objects": patch
+---
+
+feat(spec)!: reject unknown keys across the app shell and navigation tree (#4001 app step, PR B)
+
+Closes the last high-traffic authorable surface in the unknown-key strictness
+ratchet (flow + permission #4071, RLS / sharing / position #4099, approval
+#4119, App dead-key tombstones #4142). The app shell is the densest
+hand-authored surface on the platform — a navigation tree is where an author
+or AI is most likely to write a key from memory — so a silent strip here was
+the most probable instance of the #3405 trap.
+
+- **`AppSchema`** and its sub-schemas (`AppBrandingSchema`,
+  `NavigationAreaSchema`, `AppContextSelectorSchema` + its `optionsSource` /
+  `filter` blocks, `NavigationContributionSchema`) are `.strict()`.
+- **`NavigationItemSchema` becomes a DISCRIMINATED union on `type`.** This is
+  what makes strict readable: a plain union of strict members answers one
+  unknown key with an `invalid_union` aggregate naming all nine branches,
+  while discriminating on `type` first yields a single `unrecognized_keys`
+  issue against the branch the author actually wrote — at an exact path
+  through nested `children` — and a mistyped `type` gets its own "Invalid
+  discriminator value". Each variant carries its own suggestion pool, so a
+  `url` item is never told about `dashboardName`.
+- **Still OPEN by design:** `PageNavItem.params`, `ComponentNavItem.params`
+  and `ActionNavItem.actionDef.params` — per-target payloads owned by the
+  page / component / action, not by the nav item.
+
+**A real defect the gate caught, in the platform's own app:** `ACCOUNT_APP`
+declared `defaultOpen` on three navigation groups. That was never a schema
+key — `expanded` is — so all three shipped COLLAPSED while their author
+believed they opened by default. Fixed at the producer (contract-first) and
+`defaultOpen` / `open` / `collapsed` / `isOpen` now alias to `expanded`.
+
+**Migration.** Any key now rejected was previously stripped and had no
+runtime effect. The error carries the fix; mappings include
+`menu`/`sidebar`/`tabs`/`items` → `navigation`, `title` → `label`,
+`permissions` → `requiredPermissions`, `sort`/`position` → `order`,
+`defaultOpen` → `expanded`, `args` → `params` (actionDef), `primary` →
+`primaryColor`, `url` → `endpoint` (options source), plus wrong-layer
+pointers: `pages`/`views`/`flows` are not App fields, and a payload named on
+the wrong variant points at the `type` that owns it.
+
+The `visibleWhen` → `visible` alias is the load-bearing one: ADR-0089 made
+`visibleWhen` canonical on view/page schemas, so an author who learned it
+there would silently lose a nav entry's visibility gate — a capability gate
+failing open, the worst shape of the silent-strip bug.

.changeset/authoring-key-lint-full-coverage.md

@@ -0,0 +1,54 @@
+---
+"@objectstack/spec": minor
+---
+
+feat(spec): the unknown-authoring-key lint covers every metadata collection, not just objects (#3786)
+
+#4148 introduced the lint for `object` and `field` — the two surfaces #4120
+caught real drift on. Those two were a sample, not the population: of the
+authorable metadata types, only a handful are `.strict()` (`flow` / `permission`
+/ `position` / `tool` from #4001 Tier-A, joined mid-review by `app` via #4165).
+Every other type strips an
+undeclared key exactly the way `field` did — an author who misspells a key on a
+`page`, an `agent` or a `dashboard` got the same parse-clean-value-gone silence,
+with no lint watching.
+
+`lintUnknownAuthoringKeys` now walks **every metadata collection** — 16 today:
+object, page, dashboard, report, dataset, action, job, agent, skill, hook,
+mapping, datasource, view, email_template, doc, book — and its coverage is
+**derived, not listed**: which collections exist comes from `PLURAL_TO_SINGULAR`
+(the same boundary map the normalizer uses), which schema judges each comes from
+the canonical type→Zod registry, and whether linting is even meaningful is read
+off each schema's own unknown-key posture. A third hand-written "types the lint
+covers" list would have been the #3786 shape all over again, inside the tool
+built to end it.
+
+The posture rules keep the lint from ever disagreeing with the parse:
+
+- **strip** (zod default) → lint: the parse drops unknown keys silently, and
+  that silence is what gets reported.
+- **strict** → skip: the parse already rejects loudly with the schema's own
+  tombstone guidance; a second, possibly disagreeing voice helps nobody. This
+  bucket GROWS as #4001 tiers graduate schemas — `app` graduated (#4165) while
+  this change was in review, and the derivation adapted without an edit.
+- **passthrough** → skip: unknown keys survive the parse, nothing is dropped.
+- **unions** (`view`) → the union of member keys; lintable only when a member
+  strips and none passes unknowns through.
+
+`defineStack`, `os validate` and `os build` pick the wider coverage up with no
+code change of their own. Verified against the three first-party example apps
+(28 pages, 29 flows, 11 actions and friends in the showcase): all clean, zero
+false positives. Verified by mutation: dropping union handling, inverting the
+strict filter, and skipping a collection each turn the tests red.
+
+New root/kernel exports: `listLintableAuthoringCollections` (+
+`LintableAuthoringCollection`) — the derived coverage as data, so tooling can
+report what the evidence base for the #4001 strict tiers actually spans.
+
+One import-site change: `lintUnknownAuthoringKeys` moved from the `/data`
+subpath to the package root and `/kernel` (`@objectstack/spec` root import is
+unchanged and remains the canonical site). Covering every type means importing
+every schema, and `/data` is consumed by frontend bundles — the walker moving
+out keeps that chunk from inheriting the whole schema universe. If you imported
+it from `@objectstack/spec/data`, import from `@objectstack/spec` instead. The
+comparator, guidance tables and finding types stay in `/data`, unchanged.

.changeset/job-placeholder-migrates-to-db-adapter.md

@@ -0,0 +1,7 @@
+---
+'@objectstack/service-job': patch
+---
+
+Jobs registered before `kernel:ready` now survive the placeholder→DbJobAdapter upgrade.
+
+Business plugins `start()` before the JobServicePlugin's `kernel:ready` hook, so every schedule they register lands on the placeholder IntervalJobAdapter. That placeholder silently ignores `cron` schedules, and the upgrade used `replaceService` without migrating anything — so in the default configuration a plugin's cron jobs never ran at all, while its interval timers kept running on the orphaned placeholder, invisible to `sys_job`. The upgrade now snapshots every early registration, stops the placeholder, and re-schedules them on the DbJobAdapter (whose croner-backed cron routing makes the cron entries actually fire). The IntervalJobAdapter also warns per cron registration, and the no-engine path summarizes stranded cron jobs instead of staying silent.

.changeset/measure-emits-what-it-declares.md

@@ -0,0 +1,58 @@
+---
+"@objectstack/service-analytics": minor
+---
+
+fix(analytics)!: a measure emits what it declares, instead of `COUNT(*)` (#4157)
+
+`NativeSQLStrategy.resolveMeasureSql` answered `COUNT(*)` to three different
+questions it could not otherwise answer — each time aliased under the name the
+caller asked for, so the result looked like an answer:
+
+1. **A measure the cube does not declare.** `lookupMember`'s synthetic
+   relation fallback is dimension-only, so any undeclared or mistyped measure
+   name landed here. `measures: ['revenue']` against a cube without it returned
+   `COUNT(*) AS "revenue"` — a row count presented as revenue.
+2. **A `number`/`string`/`boolean` metric.** `AggregationMetricType` documents
+   these as *"Custom SQL expression returning a number / string / boolean"*: the
+   measure's `sql` **is** the computation — a ratio, a `CASE`, a window
+   function. The expression was discarded and replaced by a row count.
+3. **An unrecognised `type`.** Same silent substitution.
+
+Now: an undeclared measure and an unrecognised type **throw**, naming the
+declared measures and both accepted vocabularies respectively; a custom-
+expression type emits its expression unwrapped. The six aggregates are
+unchanged.
+
+**A dot no longer implies a relationship hop.** `qualifyAndRegisterJoin` split
+any dotted string into a join chain, so the expression `SUM(account.amount)`
+became `"SUM(account"."amount)"` *plus* a `LEFT JOIN "SUM(account"` — invalid
+SQL naming a table that does not exist. Harmless only while the result was
+being thrown away for `COUNT(*)`; emitting the expression makes it matter. A
+dotted string is now treated as a path only when every segment is a bare
+identifier, so `account.amount` still lowers to a qualified column and a join,
+and an expression is emitted as written. That also fixes the same mangling for
+an *aggregate* measure whose `sql` is an expression — `type: 'sum'` with
+`sql: 'SUM(account.amount)'` was producing the same garbage.
+
+**Breaking, narrowly.** Two inputs that used to produce SQL now raise: a query
+naming an undeclared measure, and a cube measure with a type outside
+`AggregationMetricType`. Both were returning a wrong number rather than data,
+so nothing correct can depend on them — but a caller that was silently getting
+row counts will now see an error, which is the point. This is the trade #3948
+settled for the drivers.
+
+Datasets are unaffected: `aggregateToMetricType` only ever emits an
+`AggregationFunction` member, so a compiled dataset never had a
+custom-expression measure or an unknown type. The reachable path is a
+hand-authored Cube.
+
+`metric-type-coverage.test.ts` asserts the aggregate and expression sets
+*partition* `AggregationMetricType`, so a tenth metric type fails a test rather
+than reaching the throw. Both sets are named, not derived as each other's
+complement — deriving would classify a new *aggregate* as an expression and emit
+a bare column, a different silent wrong answer.
+
+Verified: **460 tests across 35 files** green, including the four suites that
+assert `COUNT(*)` — all of them use a *declared* `type: 'count'` metric, so none
+relied on a fallback. The 14 new tests were confirmed to fail against the old
+behaviour (6 of 10 in the behaviour suite) before the fix.

.changeset/messaging-declares-its-event-object.md

@@ -0,0 +1,36 @@
+---
+"@objectstack/service-messaging": patch
+"@objectstack/plugin-audit": patch
+---
+
+fix(service-messaging,plugin-audit): the service that writes `sys_notification` is the one that declares it (#4154)
+
+`MessagingService.emit()` writes `sys_notification` on every call — it is the
+pipeline's single ingress (ADR-0030 L2). But the object was contributed to the
+manifest by **`AuditPlugin`**, parked there with a comment saying it would stay
+"until that [ADR-0030] migration lands". The migration landed; the parking did
+not move.
+
+That left a real deployment hole, because `AuditPlugin` is an **optional** pair
+in the CLI's plugin table. Install messaging without audit and nothing registers
+the object, so the engine has no schema to issue DDL from and every `notify()`
+fails with `no such table: sys_notification`. AuditPlugin never wrote the row
+itself — it deliberately routes through this service's `emit()` ingress
+(`getMessaging()` in `audit-writers.ts`), and its own exclusion list already
+annotates the object as "messaging-owned (ADR-0030)".
+
+The contribution now lives with the writer, matching how every other
+service-owned platform object is handled in this repo — `service-job` imports
+`SysJob`/`SysJobRun`, `service-queue` imports `SysJobQueue`, `rest` imports
+`SysImportJob`. Ownership of the *definition* is unchanged: the object stays in
+`@objectstack/platform-objects` and in `PLATFORM_OBJECTS_BY_PACKAGE`, because
+owning a definition and contributing it to a running kernel are different
+things. It is also added to the service's `provisionSystemTables`, so the table
+is created with the rest of the pipeline it heads rather than lazily on the
+first write.
+
+Found while migrating `notifications.hono.integration.test.ts` to in-memory
+SQLite in #4065: that suite had to register the object itself to boot, which was
+the deployment bug in miniature. The workaround is deleted in this change — the
+suite now boots messaging alone and passes, which is the proof the product
+declares what it writes.

.changeset/plugin-ordering-declared-contract.md

@@ -0,0 +1,55 @@
+---
+"@objectstack/core": minor
+"@objectstack/spec": minor
+"@objectstack/runtime": minor
+"@objectstack/objectql": patch
+"@objectstack/metadata": patch
+---
+
+feat(core,runtime): plugin ordering is a declared, kernel-enforced contract (ADR-0116, #4131)
+
+`kernel.use()` registration order was never a contract — the kernel resolves
+init/start order from the plugin dependency graph — but a plugin that needed a
+service at init *when its provider is composed* while also booting *without*
+the provider had no way to declare that. `AppPlugin` was the standing example:
+it grabs `manifest`/`objectql` synchronously in `init()`, declared nothing
+(a hard dependency would break empty-env / metadata-only / mock-engine
+kernels), and so its correctness rode on which array slot each caller put it
+in. That convention failed the same way twice (`DefaultDatasourcePlugin`'s
+first cut; then #4085, disguised for months as "crashes when the artifact is
+missing").
+
+The kernel `Plugin` contract gains three additive fields, enforced by both
+`ObjectKernel` and `LiteKernel` through one shared implementation
+(`plugin-order.ts` — the previously duplicated topological sort is unified
+there):
+
+- **`optionalDependencies: string[]`** — order-if-present: hoisted ahead
+  exactly like `dependencies` when composed (real topology edges, including
+  cycle detection), silently skipped when absent.
+- **`requiresServices: string[]`** — services resolved synchronously during
+  `init()` with no fallback. Validated **before Phase 1**: a required service
+  whose only declared provider initializes later fails the boot with an error
+  naming both plugins, both slots, and the fix — before any init side
+  effects. Re-checked immediately before the plugin's own init, where a still-
+  missing service becomes a named composition error exactly where the old
+  bare `Service not found` crash fired.
+- **`providesServices: string[]`** — services a plugin's `init()`
+  unconditionally registers; powers the validation and the diagnostics.
+
+Plugins that declare nothing get the diagnosis too: a `getService` miss
+during Phase 1 now appends which plugin was initializing and — when a
+composed plugin declares the service — who provides it and how to declare the
+ordering. The `Service '<name>' not found` prefix and the factory-backed
+`is async - use await` message are unchanged.
+
+First adopters: `AppPlugin` declares
+`optionalDependencies: ['com.objectstack.engine.objectql']` +
+`requiresServices: ['manifest']` (cleared on the empty-env no-op path), so
+the #4085 composition — AppPlugin registered before the engine — now boots
+correctly in every slot; `ObjectQLPlugin` declares
+`providesServices: ['objectql', 'data', 'manifest', 'lifecycle']` and
+`MetadataPlugin` declares `providesServices: ['metadata']`.
+
+Everything is additive — plugins that declare nothing keep their exact
+ordering semantics; no existing declaration changes meaning.