@@ -0,0 +1,93 @@
+---
+'@objectstack/spec': minor
+'@objectstack/runtime': minor
+---
+
+**BREAKING for action handlers** — `ActionEngineFacade.find` takes the engine's query ENVELOPE; the bare-filter parameter shape is withdrawn (#15124)
+
+Clause-②: yes (narrowing)
+
+`ctx.engine.find(object, query)` now takes `EngineQueryOptions` — the same
+options bag `IDataEngine.find` and ObjectQL's own `engine.find` take, named by
+identity rather than restated. **One platform, one query shape.**
+
+### Migration — FROM → TO
+
+| You wrote | Write instead |
+| --- | --- |
+| `ctx.engine.find('task', { status: 'open' })` | `ctx.engine.find('task', { where: { status: 'open' } })` |
+| `ctx.engine.find('task', { amount: { $gt: 100 } })` | `ctx.engine.find('task', { where: { amount: { $gt: 100 } } })` |
+| `ctx.engine.find('task', {})` | unchanged — an empty envelope is still the unfiltered read |
+
+The rewrite is lossless and mechanical: the filter moves under `where`, verbatim.
+`tsc --noEmit` over your handlers finds every unmigrated call — see below.
+
+### Why the shape was withdrawn rather than the bar closed
+
+Until now this parameter was the `where` HALF of a query while every other
+`find` on the platform took the whole envelope, and the runtime wrapped what it
+was given. That made the most natural spelling the wrong one, silently: an
+author who passed the engine's own envelope reached the engine as
+`{ where: { where: … } }` — a filter on a field named `where` — which matches no
+row and resolves to `[]` with **no error at all**. A handler that made the
+mistake ran to completion over zero rows for as long as it shipped, and its own
+hand-written test double, written to the same belief, passed every assertion.
+Because an empty `{}` skipped the wrap, one unfiltered read kept working under
+either belief, so a dead handler looked partially alive.
+
+Refusing `where` at the top level instead — intersecting the old parameter with
+`{ where?: never }` — was rejected: it asserts a vocabulary fact the spec
+declares nowhere, reserving the field name `where` across every customer's data
+model to buy one parameter's compile-time check. Aligning the parameter removes
+the ambiguity at its root and reserves nothing.
+
+### What the new declaration refuses, measured
+
+If your handler is typed with the published `ActionHandlerContext`, a bare filter
+no longer type-checks on **either** path you can reach it by:
+
+- an object literal (`{ status: 'completed' }`) fails the excess-property check —
+  a field name is not an envelope key;
+- a filter held in a `FilterCondition` variable fails **TS2559** — every envelope
+  key is optional, so a bag of field names has no property in common with it.
+
+The envelope's own keys are typed too: `where: 'a = b'`, `fields: 'id,subject'`
+and `limit: '50'` are each refused.
+
+**If your handler is NOT typed with it** — a handler in an `objectstack.config.js`
+/ `.mjs`, one annotated with your own copy of the context type, or a `(ctx: any)`
+handler — nothing above reaches you, so the facade refuses the withdrawn shape at
+**runtime** instead, before the engine, with the same prescription:
+
+```
+find('task') was given a key 'status' the query envelope does not carry.
+ctx.engine.find(object, query) takes the engine QUERY ENVELOPE, not a bare
+filter — move the filter under `where`: find(object, { where: { … } }).
+Envelope keys: context, cursor, distinct, expand, fields, limit, offset,
+orderBy, search, searchFields, top, where.
+```
+
+⚠️ **That refusal matters most for a filter whose value is `null`.** The engine's
+own unknown-option check exempts a `null` value, because on an option bag a
+`null` is a withdrawal. On a filter it is the "rows with no X" idiom, so
+`{ deleted_at: null }` would have been dropped unexecuted and the read would have
+widened to **every row** — including the ones you were excluding — with no error
+at all. It is refused instead.
+
+### What this opens
+
+`fields`, `orderBy`, `limit`, `offset` and `expand` are reachable from an action
+handler for the first time — under the old parameter there was nowhere to carry
+them. A caller-supplied `context` is **ignored**: this facade is trusted and
+context-less by design, and the runtime stamps its own elevated
+`ExecutionContext` last. Do not write one — it reads as authorization and is
+none.
+
+### Checking a migrated handler
+
+Do not settle for "it still resolves". A handler that had been passing the
+envelope was returning `[]` on **every** call, so a suite written against the
+mistake passes and the row count is the only witness. Re-run each migrated
+handler against seeded data and assert it returns the rows its filter selects.
+
+<!-- adr-0087: registered action-engine-facade-find-query-envelope -->
@@ -0,0 +1,38 @@
+---
+'@objectstack/spec': minor
+---
+
+fix(spec)!: `CronSchedule.timezone` is judged by the `iana_time_zone` membership predicate (#16292)
+
+**BREAKING** — an accept-set narrowing on a published authoring key.
+`CronScheduleSchema.timezone` was a bare `z.string().optional().default('UTC')`, so
+`defineJob` and `JobSchema.parse` took `timezone: 'UTC+8'` at authoring and build time
+and said nothing. It is now judged by `isValueDomainMember('iana_time_zone', …)` — the
+predicate `@objectstack/spec/shared` already exports, and the same judge the four
+`valueDomain: 'iana_time_zone'` columns (`sys_business_unit.timezone`,
+`sys_organization.timezone`, `sys_job.timezone`, `sys_report_schedule.timezone`) are
+written against. Shipped as `minor` under the repo's launch-window convention for
+accept-set narrowings.
+
+No job that ran yesterday stops running. The value was already carried unchanged to
+`CronJobAdapter.schedule`, where croner — constructed with a callback — throws on a
+non-member and `AppPlugin` records a per-job `FAILED TO SCHEDULE` at `error` level plus
+a `jobScheduleFailuresTotal` increment: the job was declared and never ran. What moves
+is WHEN its author is told, from the first environment that boots to `defineJob` /
+`os build`. So a stack whose job carries a zone the platform cannot honour now stops
+building instead of booting-and-not-running.
+
+Membership is the `Intl.DateTimeFormat` probe rather than a checked-in list, so the
+accepted set is the host's own tz database — deliberately, and identically to those four
+columns, the settings door and `resolveAuthzContext`. It is what every `Intl`-based
+consumer downstream accepts, so the parse-time answer and the schedule-time answer
+cannot disagree on one host. `UTC`, the key's own declared default, is a member on every
+conforming runtime, so an omitted key is untouched.
+
+`interval` and `once` schedules carry no zone and are unaffected. The boundary type
+`JobSchedule.timezone` on `@objectstack/spec/contracts` is a third, separate door and is
+deliberately left out of this change.
+
+Clause-②: yes (narrowing)
+
+<!-- adr-0087: not-required (no-migration-prescription) No key, export, config field or stored shape is added, removed, renamed or re-spelled, and no metadata document has to be rewritten into a different one. The narrowing is value-level and undecidable in the upgrade direction: an offset spelling such as `UTC+8` names no zone at all, so nothing can derive whether its author meant `Asia/Shanghai`, `Asia/Singapore` or `Australia/Perth` — the answer is a fact about the deployment, never about the refused string. `objectstack migrate meta` therefore has nothing mechanical it could apply, and a ledger row would carry an empty mapping. The sibling column-tier narrowing of the same concept is already recorded as `platform-timezone-columns-iana-domain-refused`; this authoring-tier door is a different door and is deliberately not filed under that id. -->
@@ -0,0 +1,48 @@
+---
+'@objectstack/spec': minor
+'@objectstack/lint': minor
+---
+
+**BREAKING** — a dataset-bound dashboard widget's `chartConfig` carries appearance only: `type`, `xAxis`, `yAxis` and `series` are refused by name, each refusal naming the dataset selection the intent belongs in.
+
+Clause-②: yes (narrowing)
+
+`DashboardWidgetSchema.dataset` is REQUIRED, so **every** dashboard widget is dataset-bound, and ADR-0021 already made the dataset the owner of the chart's structure: it decides which series exist and which column each one reads. `chartConfig` nonetheless declared `type` / `xAxis` / `yAxis` / `series`, and the two answers met with no rule between them. That was not merely inert. An authored `yAxis[].field` was a live MEMBERSHIP channel — the renderer synthesised a series from the authored axes when the chart declared none — so one authored axis could silently re-point a dataset-bound series at a different column while the chart still drew, which reads as a true statement about the data. Maintainer ruling 2026-09-12, decision batch #121 item 1, verbatim 「同意」, on options C+D together: state the ownership split in the protocol AND refuse the four keys by name.
+
+## FROM → TO
+
+| you wrote inside `chartConfig` (17.4 and earlier) | write instead |
+| --- | --- |
+| `type: 'line'` | `type: 'line'` on the WIDGET, beside `dataset` — the widget's own `type` is the chart family and it always won; nothing on this face ever read the chart config's |
+| `xAxis: { field: 'stage' }` | `dimensions: ['stage']` on the widget — the dataset dimension the category axis plots |
+| `yAxis: [{ field: 'amount' }]` | `values: ['amount']` on the widget — the dataset measures, one entry per mark. A second axis is a second measure, not a second axis declaration |
+| `series: [{ name: 'amount' }]` | `values` (plus a second `dimensions` entry to split) — series membership follows the selection; an entry naming a measure outside it was already being ignored |
+
+**The one-line fix:** delete the four keys; the widget's `type` and its `dimensions` / `values` are the chart's structure.
+
+`os migrate meta --from 17` lists the mechanical edits for existing sources; apply them by hand.
+
+## What is NOT retired
+
+The keys stay authorable on `ChartConfigSchema` itself, and that is the half a blanket refusal would have broken. A react-tier `<ObjectChart data={…} />` binds inline rows with no dataset behind them, so its axes are the author's and are unchanged — `react-blocks.ts` still publishes all four in that block's `dataProps`. `ReportChartSchema` keeps its own `xAxis` / `yAxis`, narrowed to its bound dataset's dimension and measure names. The refusal lives on a new per-carrier `DashboardWidgetChartConfigSchema` (`ChartConfigSchema.extend(…)`, the `ReportChartSchema` spelling) precisely so it cannot reach those two.
+
+## What this costs, stated rather than discovered
+
+`xAxis` / `yAxis` / `series` carried presentation alongside the binding — axis titles, number formats, bounds, grid lines, log scale, and per-series labels, colours, stacking and mark types. Refusing the keys takes the presentation with the binding: a dataset-bound chart takes those from the dataset's own dimension and measure declarations, and `colors` on the chart config remains the palette channel. **The combo chart a dataset-bound widget could author through `series[].type` has no authoring channel on this face any more.** That capability loss is ruled, not incidental — the option that kept it was on the table and was not taken.
+
+## Accept-set movement, both directions
+
+Narrowing, on a dataset-bound widget: the four keys move from accepted to refused. **And one widening, which is forced by the ruling rather than chosen:** `ChartConfigSchema.type` is REQUIRED, so before this change a `chartConfig` without a `type` was refused as incomplete. Refusing `type` while keeping the bag authorable for appearance — which ruling item 1 requires in as many words — means absence must now be legal. So `chartConfig: { title: 'Revenue' }` on a dashboard widget moves from refused to accepted. That is why the declaration reads `yes (narrowing)` rather than `no`.
+
+## The retirement kit
+
+- **Four `retiredKey()` tombstones on the widget carrier**, registered as `ui/DashboardWidgetChartConfig:type` / `:xAxis` / `:yAxis` / `:series` under protocol 18. `tsc` types each key `never`, so every authoring site in a consumer's tree fails to compile before anything runs, and a value that reaches a parse raises the prescription rather than a bare unrecognized-key report.
+- **The ADR-0087 pair.** The D2 conversion `dashboard-widget-chart-config-structure-removed` strips the four keys from stored dashboard widgets (dashboards only — reports and the react tier keep theirs); the D3 semantic entry `dashboard-widget-chart-config-structure-refused` carries the judgement, because moving what the keys MEANT into the dataset selection needs facts the widget does not hold — an authored axis field can name a dataset dimension the widget never selected.
+- **The liveness rows stay and are regraded `dead`**, the `retiredKey` route's discipline: the tombstone keeps the key in the walked shape, so the row remains and records why. Three of them were graded `live` on their presentation half on 2026-09-12 and that measurement is recorded as overridden, not withdrawn.
+- **`chart-config-missing` is withdrawn from `@objectstack/lint`.** It advised a `combo` widget with no `chartConfig` to declare `chartConfig: { series: [{ name, type }] }` — metadata the schema now refuses — and after the ruling there is nothing a `combo` author can do about the finding. The rule ID stays exported, so an existing `suppressWarnings: ['chart-config-missing']` entry keeps parsing. `chart-field-unknown` still fires on a legacy document and its hints now say delete-and-migrate instead of describing what the keys used to carry.
+
+## What an operator with a STORED dashboard sees
+
+A `sys_metadata` `dashboard` row written before this release can carry any of the four. Nothing breaks at read: the conversion replays on rehydration and strips them, so the row is served canonical, and `os migrate meta --stored --apply` rewrites the rows. ⚠️ The strip is the mechanical half only. A widget whose authored axes AGREED with its selection renders identically afterwards — that is the expected case. A widget that renders differently was relying on the membership channel this removes, which is the case the ruling was made about.
+
+<!-- adr-0087: registered dashboard-widget-chart-config-structure-removed, dashboard-widget-chart-config-structure-refused -->
@@ -0,0 +1,36 @@
+---
+'@objectstack/spec': minor
+---
+
+Gallery, kanban and timeline view configs declare an author-settable row ceiling.
+
+`GalleryConfigSchema`, `KanbanConfigSchema` and `TimelineConfigSchema` each gain a
+`limit` member — a positive integer, default **100** — saying how many records the
+view fetches. The default is APPLIED by the schema rather than only described, and
+the key's own text states the other half of the contract: when the ceiling applies,
+the renderer must show a visible truncation signal, because a bounded view that
+looks complete is worse than an unbounded one. `DEFAULT_VIEW_ROW_LIMIT` is exported
+so a consumer reads that number instead of re-declaring it.
+
+The knob belongs in the protocol because two renderers already cap by author choice
+off keys the protocol never declared: objectui's kanban board fetches
+`$top: schema.limit ?? DEFAULT_KANBAN_LIMIT` with `limit` declared in
+`@object-ui/types` alone, its timeline does the same off a component props
+interface, and its gallery caps not at all. `limit` is the name those consumers
+already read, so this declaration absorbs the consumer-local keys instead of
+introducing a second spelling of one concept.
+
+Nothing is removed, renamed or narrowed, and no document that parsed before is
+refused now. Two things to know when upgrading:
+
+- a parsed gallery / kanban / timeline config carries `limit: 100` where the author
+  wrote no ceiling, so code that compares a parsed config against a literal object
+  sees the new member;
+- `KanbanConfigParsed` is now declared (ADR-0122) because that schema has two shapes
+  for the first time; `KanbanConfig` is unchanged and remains the author state.
+
+The non-grid four — gantt, calendar, map and tree — are deliberately untouched:
+their rows stay bounded by a platform ceiling the renderer owns, because a gantt's
+range, a map's camera fit and a tree's parent chain are computed over the whole set.
+
+Clause-②: yes (widening)