@object-ui/data-objectstack 17.5.0 → 17.7.0

package/CHANGELOG.md

@@ -1,5 +1,2316 @@
 # @object-ui/data-objectstack
 
+## 17.7.0
+
+### Minor Changes
+
+- 7b395d8: **BREAKING** — three more record ids that the objectui#9511 ruling's enumeration left out are
+  strings now (objectui#10078). `CommentSearchResult.recordId`, `RecordSubscription.recordId`
+  and `DataSourceMutationEvent.id` narrow **FROM** `string | number` **TO** `string`. ⚠️ Other
+  record ids in `@object-ui/types` still admit a number and are not touched here, among them
+  `DetailViewSchema.recordNavigation` (`recordIds`, `onNavigate`), `FeedItem.sourceId`, and the
+  `onNavigate` slots on `ObjectGridSchema`, `ObjectViewSchema` and `ListViewRuntimeProps`.
+  
+  ```ts
+  // before — compiled
+  const bell: RecordSubscription = { recordId: 42, subscribed: true };
+  // after — refused by the compiler; write the id the protocol carries
+  const bell: RecordSubscription = { recordId: '42', subscribed: true };
+  ```
+  
+  **Why.** objectui#9511 (director batch #195 item 1, letter A) ruled that a record id is a
+  string wherever **metadata** names one, and extended that, as 「the same principle」, to
+  `CommentEntry.recordId` and `MentionNotification.recordId`. It did not name these three, which
+  are runtime and API shapes rather than metadata. Carrying the rule to them is the `domain:spec`
+  seat's inheritance decision, recorded in the claim on objectui#10078: they hold the same id and
+  were left with the old spelling. `CommentSearchResult.recordId` is copied straight from
+  `CommentEntry.recordId`, `RecordSubscription.recordId` names the record a notification bell is
+  for, and `DataSourceMutationEvent.id` is the id the `update` / `delete` doors already take as a
+  string.
+  
+  **What changes at runtime.** `ValueDataSource` and `ObjectStackAdapter` now emit
+  `onMutation` events whose `id` is always a string. Both methods still accept a numeric id
+  through their own wider parameter, and each converts it at its own boundary before emitting —
+  the one place the rule says the conversion lives. An in-memory `value` source whose items
+  carry numeric keys therefore announces `'42'`, not `42`. A subscriber that compared
+  `event.id` against a number must compare against the string. The two in-repo subscribers
+  that read `event.id` already pass it through `String(...)`, so they see no difference.
+  
+  **Packages that narrow without a source change.** `@object-ui/collaboration` (`useCommentSearch`
+  returns `CommentSearchResult[]`) and `@object-ui/plugin-detail` (`SubscriptionToggleProps`
+  carries a `RecordSubscription`) publish the narrower type through their own `.d.ts`.
+  
+  **What a host has to do.** Code that builds a `RecordSubscription`, reads
+  `CommentSearchResult.recordId`, or implements `DataSource.onMutation` with numeric keys
+  converts once, where the number enters (its own adapter or data boundary), and passes the
+  string from there on. ⛔ Nothing converts silently on the reading side.
+  
+  **Disposition: ADR-0087 D7 — a published runtime TypeScript interface with no metadata
+  surface is carried by the compiler and needs no ledger entry; ⛔ no conversion entry, ⛔ not
+  a tombstone, ⛔ not an npm `major`.** None of the three has a zod mirror, none is authored into JSON, and no schema
+  references them, so there is no parse-time door and nothing for a conversion table to
+  rewrite: the compiler error at the numeric site is the delivery channel. The level is `minor`
+  because objectui marks its own breaking changes `minor` with this banner (AGENTS.md, version
+  alignment); `major` is refused outright because every publishable package sits in one `fixed`
+  group pinned to the `@objectstack` major (`scripts/check-changeset-no-major.mjs`).
+  
+  **Pin.** `record-id-string-survivors-10078.test.ts` in `@object-ui/types` asserts all three
+  members read `string` (not `any`), refuses a numeric literal at each, and keeps a
+  source-text census of the three declarations with controls that prove the census can fire.
+- 1563d3e: The object-metadata write guard now holds a `select` / `radio` field that has no option source.
+  
+  This is the objectui half of the maintainer's ruling A on objectstack#20827, which refuses a
+  `select` / `radio` with neither `options` nor `picklist` at the `FieldSchema` door and has objectui
+  stop sending one first. The rule lives in the existing door guard, so `MetadataClient.save`,
+  `importObjectDraft` and `MetadataService` all apply it, for every writer behind them.
+  
+  BREAKING (behaviour, released as `minor` per this repository's version policy):
+  `assertObjectMetadataWritable('object', …)`, and so `MetadataClient.save('object', …)`, now throws
+  BEFORE issuing the request when a `select` or `radio` field carries neither a non-empty `options`
+  list nor a `picklist` string. `options: []` counts as none, as the contract's own completeness rule
+  reads it. Unlike the relationship rule, this refuses a document the installed server still accepts:
+  the ruling orders the client first on purpose, and the door follows. The message names the field
+  and asks for an option, a shared `picklist`, or a non-choice type. A field that names a `picklist`
+  is never refused by this rule.
+  
+  The Studio data page and the metadata-admin object editor already surface the refusal in their
+  error banner and send the next autosave once an option exists, including for an object that already
+  stores such a field.
+  
+  New export: `CHOICE_TYPES_REQUIRING_OPTIONS`, derived by this package's pin from the installed
+  `@objectstack/spec`'s `field/choice-without-options` completeness rule.
+- d893290: `formatMetadataError` and `formatMetadataIssue` are exported from `@object-ui/data-objectstack`: the one reader of a failed metadata save (objectui#11302).
+  
+  A save the spec refuses answers `422 INVALID_METADATA` with a headline message (a count plus `path [code]` locators) and the author's prescription in structured issues, which `MetadataClient` puts on `MetadataError.issues`. `formatMetadataError(err)` lists those issues one field per line (`• fields.amount.type — Required`) and falls back to the error's message when there are none; `formatMetadataIssue(issue)` is that one-line grammar, for callers that format a list of failures. Render the result with a whitespace class that keeps newlines.
+  
+  The reader moved here from `@object-ui/app-shell`, where it was internal, so every surface that saves through `MetadataClient` can render a refusal the same way. Additive: nothing existing changed.
+- 993f312: Parse a write-strip's `reason` against the spec enum at the boundary
+  (objectui#4934).
+  
+  `notifyDroppedFields` filtered a create/update response's `droppedFields` on
+  SHAPE alone — a hand-written `e is DroppedFieldsEvent` guard that checked
+  `Array.isArray(fields)` and nothing else — so a `reason` outside
+  `'readonly' | 'readonly_when' | 'primary_key'` reached every subscriber typed as
+  though it were inside the union. A deployed client normally runs BEHIND the
+  server it talks to, so a reason from the future is the expected skew direction,
+  not a corrupt payload; the interior was typed to trust a union no one had
+  checked, and nothing in the repo could say so. `notifyBatchDroppedFields` did
+  the same through its `entry as DroppedFieldsEvent & { index?: number }` cast.
+  
+  Both paths now read `reason` against `DroppedFieldsEventSchema.shape.reason` —
+  the enum the installed pin declares, derived rather than restated, so a pin bump
+  that adds an arm widens the accept set on its own:
+  
+  - **Every entry is kept.** Dropping the unparsable ones would tell the user
+    nothing about fields the server really did strip, which is exactly the silence
+    objectui#3484 removed.
+  - An unrecognized `reason` arrives on a named skew arm,
+    `UnrecognizedDropReasonEvent`, carrying `UNRECOGNIZED_DROP_REASON` plus the
+    wire value **verbatim** in `unrecognizedReason` — never coerced onto a known
+    arm, because claiming `readonly` for a reason we cannot name is a false
+    statement about the user's data.
+  - `WriteWarningEvent['droppedFields']` is therefore the two-arm
+    `DroppedFieldsNotice`. The spec type stays the canonical arm and is not
+    widened to `string` (objectui#3160): the skew arm is not assignable to
+    `DroppedFieldsEvent`, so a consumer branching on `reason` now hears about
+    server skew from `tsc` instead of from a per-consumer discipline.
+  
+  Runtime wording is unchanged: the one reader, the app shell's write-warning
+  toast, already answered an unrecognized reason with its cause-free line.
+  
+  **Blast radius — the compile error IS the intended signal, not a regression.** A
+  consumer that branches exhaustively on `reason` — a parameter, a `Map` key or a
+  `Record` annotated `DroppedFieldsEvent['reason']` — stops compiling against this
+  release, with a `TS2345` at each such site. That error is the notification, and
+  the only one: the skew arm is deliberately NOT assignable to the spec union, so
+  `tsc` reports server skew at the one place the wire is read rather than leaving
+  it to a per-consumer discipline. Do not cast it away. Widen the annotation to
+  `DroppedFieldsNotice['reason']`, and where the two arms have to be told apart,
+  narrow with `entry.reason === UNRECOGNIZED_DROP_REASON` and read the wire value
+  verbatim from `unrecognizedReason`.
+  
+  Widen the LOOKUPS, not the table. A `Record` that must stay exhaustive over the
+  SPEC arms keeps its `DroppedFieldsEvent['reason']` key: widening that one would
+  trade away the guarantee that a newly pinned spec reason fails `type-check`
+  unworded (objectui#3935).
+  
+  In this repo the entire blast radius is the app shell's write-warning toast —
+  two type annotations, no runtime change. Its executable JavaScript is byte-identical
+  and its wording tests pass unchanged, because the file was already written for
+  this value: its own docstring says the runtime `reason` may sit outside the spec
+  union and that the cause-free fallback is reachable, not dead. Only the parameter
+  and the `Map` key had been left narrower than that documented contract.
+- 41b7ce3: **View configuration is explicitly org-wide, and its write path is now gated (objectstack#7494's
+  ruling, maintainer 2026-08-12).** The `sort` / `hiddenFields` / `columnState` / `rowHeight` that a
+  list toolbar persists were never per-user: they are one shared row on the view, so an ordinary user
+  dragging a column or cycling density was re-styling that view for the entire organization. Nothing
+  in the console said so, and nothing stopped it. A per-user scope stays parked (objectstack#7611,
+  v18) and is deliberately not built here — which is precisely why the write has to be gated rather
+  than narrowed: there is no second, private store for it to fall back to.
+  
+  `ObjectStackAdapter.updateViewConfig` now refuses when the session's **reported** ADR-0066 capability
+  set does not contain `manage_metadata`, throwing the new `ViewConfigPermissionDeniedError`
+  (`VIEW_CONFIG_PERMISSION_DENIED`, with `isViewConfigPermissionDeniedError` and the
+  `VIEW_CONFIG_CAPABILITY` constant alongside it). The gate is the **first** statement in the method —
+  before `connect()`, before the payload is assembled — so a refused call puts nothing on the wire.
+  It is on the write rather than on the toolbar button on purpose: withholding the affordance would
+  leave the method still accepting the call from anything else holding the adapter, whereas a gate on
+  the write is inherited by every caller, present and future.
+  
+  `manage_metadata` is not a newly minted name. It is the capability this repo already treats as
+  metadata-authoring authority — `HomePage`'s `AUTHORING_CAPABILITY`, the one the server itself
+  refuses metadata writes without — and the gated write goes through `client.meta.saveItem`, the very
+  same ADR-0005 metadata door, so this applies the authority the server is already applying instead of
+  inventing a parallel one.
+  
+  **Unknown fails open, by doctrine.** A capability set that was never reported (a backend predating
+  ADR-0066, or no permission provider mounted) is not a denial: the server enforces regardless, so a
+  client-side refusal on missing data cannot protect anything and can only break a permitted user. A
+  *reported* empty grant gates strictly. Hosts push the session's capabilities in with the new
+  `setSystemCapabilities`; `ObjectView` wires it from `usePermissions()`.
+  
+  The refusal is also **said out loud**. `ObjectView`'s persist path previously swallowed every failure
+  into `console.error`, which for a debounced toggle whose UI has already moved would have left the
+  operator looking at a density they did not get; a denied write now raises a toast. And the "View
+  settings" popover — where density and field visibility are actually changed — now states the scope
+  before the operator acts: *"Grouping, color, density, and visible fields. Applies to everyone who
+  uses this view."*, translated in all ten packs.
+- 94e2fa7: `MetadataClient.layered()` validates the ADR-0010 protection envelope against the
+  producer's own schema at the boundary, instead of casting ten wire fields through
+  unchecked (objectui#5676, triage adjudication 2026-08-22).
+  
+  The envelope arrived by ten `as` assertions over a raw `res.json()` body — no parse, no
+  allowlist, no default. The consumer that reads it opens the metadata lock banner on
+  `layered?.lock && layered.lock !== 'none'`, true for **any** non-`none` value, so a server
+  sending a lock state this console had never heard of opened the amber box, drew the padlock
+  and the border, and rendered an empty title. No fifth state ever had to be added to this
+  repo for that to happen: a union types what this repo writes and constrains nothing about
+  what a server sends.
+  
+  The boundary now runs `GetMetaItemLayeredResponseSchema.safeParse`. On the conforming path
+  every value is the producer's schema output and the ten assertions are gone. `safeParse`
+  and never `parse`: a metadata console that rejected every dialect it had not been compiled
+  against would answer a newer server with a blank page, which is strictly worse than the
+  wrong render being fixed. Values the schema rejects are still **forwarded** — dropping them
+  would be that same refused rejection wearing different clothes — and are named in a new
+  optional `MetadataLayered._unrecognized`, absent whenever everything parsed. This extends
+  to the whole envelope the "pass through and label" treatment objectui#5672 chose for `lock`
+  alone; the banner's existing unrecognised-token title is unchanged and needed no edit.
+  
+  The labelling is per field, which is the part that makes it a degrade rather than a subtler
+  version of the same bug. Measured on the installed spec (17.2.0):
+  `GetMetaItemLayeredResponseSchema.safeParse(body)` is all-or-nothing — one unknown `lock`
+  returns `success: false` with `data` undefined — so the failure branch re-checks each key
+  against that schema's own `shape[key]`, where only the offending field fails and the other
+  six still arrive typed. Absence is never "unrecognised": the four resolved verdicts are
+  required upstream on this path, so a pre-ADR-0010 backend takes the failure branch with
+  nothing flagged and behaves exactly as before.
+  
+  One consequence of the same ruling, fixed alongside because it defeats it: a 200 answer
+  whose body was a bare JSON string or number **rejected** the promise with a
+  `TypeError: Cannot use 'in' operator`, from the envelope-detection guard's bare truthiness
+  check. A malformed body must degrade, never throw.
+- f07b976: `aggregate()`'s spec-shape branch now REFUSES an unlowered `where` instead of
+  posting it (objectui#6825, maintainer ruling 2026-08-30 — option A).
+  
+  **Breaking for callers that were already broken, so read this if you call
+  `aggregate()` with a `where`.** `aggregate()` has two branches. The analytics
+  branch takes `filter` and lowers a rule-shaped array before the wire (#6302).
+  The spec-shape branch — entered when `params` carries an array `groupBy`, an
+  array `aggregations`, or ANY `where` key — takes `where` and posts it to
+  `POST /data/:object/query` verbatim. It never lowered, and it still does not:
+  it now says so.
+  
+  **What now throws that previously went through.** A `where` that is an ARRAY
+  the spec's own `isFilterAST` gate rejects — an unlowered
+  `[{ field, operator, value }, ...]` above all, plus the infix join dialect
+  (`[condA, 'or', condB]`), a tuple whose operator is outside the AST vocabulary,
+  `['and']` with nothing to join, and an element that is not a condition. The
+  throw is an `UnloweredAggregateWhereError` (exported), carrying the same
+  `code: 'INVALID_FILTER'` / `httpStatus: 400` pair as `MalformedFilterError`, so
+  `isMalformedFilterError()` recognises it and a failed widget renders "this
+  filter is malformed" rather than "check your connection".
+  
+  **This adds no new failure — it relocates one.** Every shape now refused is one
+  the receiving engine already refused (`is not a filter`, 400 `INVALID_FILTER`,
+  before the store is touched). What changed is WHERE you find out and whether you
+  can act on it: previously the predicate was lost on the wire — or dropped
+  outright, leaving a chart rendering confident, wrong numbers with no signal to
+  its author. The refusal is now raised at the producer, names the value it
+  received, names the shape expected and where the spec declares it, and says
+  nothing was sent.
+  
+  **What an affected caller should send instead.** Lower the rules to a filter AST
+  BEFORE calling `aggregate()`:
+  
+  ```diff
+  - adapter.aggregate('opportunity', {
+  -   groupBy: ['stage'], aggregations: [...],
+  -   where: [{ field: 'stage', operator: 'equals', value: 'won' }],
+  - })
+  + adapter.aggregate('opportunity', {
+  +   groupBy: ['stage'], aggregations: [...],
+  +   where: ['stage', '=', 'won'],
+  + })
+  ```
+  
+  Or keep using the analytics branch, which lowers for you: pass the rules under
+  `filter` with the legacy `field` / `function` / `groupBy` params.
+  
+  **Unchanged, deliberately.** The analytics branch still lowers `filter` exactly
+  as #6302 left it. On the spec-shape branch a `FilterCondition` object
+  (`{ stage: 'won' }` — what `QuerySchema.where` actually declares), an empty
+  array (`[]` is "no filter", and the engine agrees), and every already-valid
+  filter AST all reach `client.data.query` byte-unchanged.
+- 503cd8b: `aggregate()`'s spec-shape branch now REFUSES the analytics branch's `filter` /
+  `field` / `function` instead of dropping them (extending the
+  maintainer ruling of 2026-08-30 on objectui#6825 — option A, refuse at the
+  producer).
+  
+  **Breaking for callers that were already broken, so read this if you call
+  `aggregate()` with an ARRAY `groupBy`.** The spec-shape branch — entered when
+  `params` carries an array `groupBy`, an array `aggregations`, or any `where`
+  key — builds its request from exactly four keys: `groupBy`, `aggregations`,
+  `where`, `limit`. `filter`, `field` and `function` are the OTHER branch's
+  parameters, and they were neither read, nor refused, nor warned about: they
+  were simply absent from the body that went to `POST /data/:object/query`.
+  
+  **Why that was worse than the `where` half #6825 fixed.** `field` + `function`
+  are the analytics branch's whole measure, and this branch takes a measure only
+  out of `aggregations`. So the legacy shape `{ field, function, groupBy, filter }`
+  whose `groupBy` happened to be an ARRAY produced a query carrying a `groupBy`
+  and **no aggregations at all** — a grouping with no measure — with the author's
+  filter gone as well. The chart rendered, the numbers were wrong, and there was
+  nothing on screen or on the wire to look at.
+  
+  **What now throws that previously went through.** A spec-shape call carrying a
+  non-nullish `filter`, `field` or `function` throws the new
+  `AnalyticsKeysOnSpecShapeError`. It carries the `INVALID_FILTER` / 400 pair its
+  siblings carry (so `isMalformedFilterError()` recognises it and a failed widget
+  renders "this filter is malformed" rather than "check your connection"), plus
+  `keys` — the offending key names — and `received`, what each one carried. The
+  message names each key, says what its spec-shape equivalent is, states which
+  `looksLikeSpecShape` disjunct put the call on this branch, and says outright
+  when the resulting query would have had no measure. Nothing is sent to the
+  server, so no unfiltered numbers come back.
+  
+  **What is deliberately NOT refused.** The legacy analytics shape (a STRING
+  `groupBy`) is untouched and still lowers `filter` and still fuses
+  `field` + `function` into its measure — the refusal lives inside the spec-shape
+  branch only. A key that is present but nullish (`filter: undefined`) carries
+  nothing to drop and passes, so params built by spreading possibly-absent
+  authored values keep working. And keys outside those three (`orderBy`, a future
+  spec key, any host extra) are not refused: the gate names three keys, and only
+  those.
+  
+  **Migration.** Pick one shape per call. Spec-shape: `{ groupBy: GroupByNode[],
+  aggregations: AggregationNode[], where?, limit? }`, with `where` already lowered.
+  Analytics: `{ field, function, groupBy: string, filter? }`, which lowers `filter`
+  for you. `AnalyticsKeysOnSpecShapeError` is exported from
+  `@object-ui/data-objectstack`.
+- ce986aa: Studio's "publish whole app" reports the runtime authoring gate's per-draft
+  advisories (server half objectstack#9343).
+  
+  `POST /packages/:id/publish-drafts` began answering `advisories` on each
+  `published[]` element when objectstack#9343 landed, but the author publishing a
+  whole app was still told nothing: both client call sites bypassed the data-layer
+  seam — a bare `fetch` in `usePublishAllDrafts` and the page-private `apiJson` in
+  `PackagesPage`, whose declared response type held two counts and `failed[]`, with
+  no `published[]` at all. The same button's own client-side capability lint was
+  raising a toast the whole time, so a finding from the server was the one thing
+  that could not reach the person pressing it.
+  
+  - `MetadataClient.publishPackageDrafts(packageId)` expresses the route and emits
+    one advisory event per advised `published[]` element — each naming that
+    element's own `type` / `name` — into the sink, event and renderer the save and
+    single-item publish doors already use. Both call sites go through it.
+  - The batch door reports `door: 'publish'` rather than a third discriminator
+    value: every item the event names really was published, and the renderer's
+    only door-dependent output is that verb. The per-item identity the author
+    needs rides `type` / `name`, one event per item.
+  - It renders only what the server sent where `PublishPackageDraftsResponseSchema`
+    declares it. A half-shaped finding, an element that cannot name its item, and a
+    top-level `advisories` the ruled shape does not put there all report nothing —
+    pinned, alongside the presence, in `metadata-client.publishAdvisories.test.ts`,
+    whose absence pin this flips.
+  - `publishPackageDrafts` returns the batch body derived from the spec schema, so
+    a caller reading `failed[]` / `publishedCount` reads a declared shape. Non-2xx
+    raises the usual `MetadataError`; the 2xx batch verdict stays the caller's to
+    judge, because `success: false` is not a refusal on this route.
+- 512bc90: `aggregate()` reads the analytics answer in ONE spelling: `rows` on the `AnalyticsResult` that `client.analytics.query` resolves to (objectui#7028). The `{ success, data: { rows } }` envelope is no longer accepted at this site.
+  
+  `@objectstack/client` 17.3.0 converged `analytics.query` on `unwrapResponse` (objectstack#13079): the method resolves to the payload, and the caller reads `result.rows`. The maintainer's ruling on that card ordered this adapter's tolerant row ladder tightened in the same wave. The ladder read five spellings (a bare array, `rows`, `data` as an array, `data.data.rows` and `results`) and answered any other shape with `[]`, which a chart renders as "no data" and a KPI as a confident zero.
+  
+  What changes:
+  
+  - **Only `rows` is read.** Any other value now throws the new `AnalyticsResultShapeError` (`code: 'ANALYTICS_RESULT_SHAPE_INVALID'`, with `envelope: true` when the value is the pre-17.3.0 envelope). It is not answered by the client-side `find()` fallback, because analytics did answer: degrading would put plausible numbers from a different code path over a contract violation.
+  - **Minimum version: `@objectstack/client` 17.3.0.** The dependency range moves from `^17.0.0` to `^17.3.0`, the first release that unwraps this method. A client older than that resolved `analytics.query` to the whole envelope, which this site no longer reads. The console's own `@objectstack/client` range moves with it, so the workspace declares one client floor.
+  - **No server is dropped.** The envelope has only ever been a client-side question: every `@objectstack` 17.x server answers `POST /analytics/query` with the same `{ success, data }` envelope, and the client decides whether it is unwrapped. The server version is not the variable here.
+  - The measure-missing fallback is unchanged: rows that come back without the requested measure are still re-aggregated client-side from a scoped `find()`.
+  
+  The objectui#7122 changeset recorded these branches as kept "rather than deleted" and left the compatibility question open. The objectstack#13079 ruling answers it, and this change removes them.
+- e2b3826: Grid grouping is now **server-side** (objectui#7189, maintainer ruling A): the
+  set of groups and every number in a group header — the count and any per-group
+  aggregation — come from the query, and the rows inside a group are paged by the
+  server.
+  
+  Before, a grouped grid fetched one window and bucketed it in the browser, so
+  both the group set and every header number were properties of the page. On a
+  store of 186 records over five business units sized 86 / 61 / 31 / 7 / 1 with a
+  100-row page it rendered **two** headers (86, 14) when the rows were stored
+  contiguously and five page slices (31 / 31 / 30 / 7 / 1) when interleaved — and
+  the records past the window were not on a second page, they were unreachable.
+  The same store now renders five headers reading 86 / 61 / 31 / 7 / 1 in either
+  order, and every record is reachable through its group's own pager.
+  
+  - **`@object-ui/types`** — `DataSource` gains an optional
+    `queryGroupHeaders(resource, query)`: it answers the group header query
+    `@objectstack/spec/ui`'s `compileListViewGroupQuery` compiles (an
+    `EngineAggregateOptions`) with one header row per group. Presence is the
+    capability; a source that cannot answer it leaves it undeclared.
+  - **`@object-ui/data-objectstack`** — `ObjectStackAdapter.queryGroupHeaders`
+    posts the compiled query verbatim to the existing `POST /data/:object/query`
+    door and answers its `records`. It never degrades: a refusal throws, and a
+    body without `records` is refused rather than read as "no groups".
+  - **`@object-ui/plugin-grid`** — a grouped grid that fetches its own rows from a
+    source declaring `queryGroupHeaders` asks for its headers (one compiled query
+    per grouping level) and pages each **open** group's rows with the group's
+    own compiled row query (`compileListViewGroupRowsQuery`: the view's filter AND
+    the group key, `limit` / `offset` per group); a collapsed group costs no row
+    query, `aggregations` are the header query's numbers, and a reference-typed
+    grouping key is labelled from the referenced record. Such a grid's column
+    sort is the server's, and it no longer shows the `Partial` marker: its counts
+    are the query's own. Rows handed in whole are still grouped in the browser
+    (exact), and a source with no header query still groups the page it fetched
+    and still marks it partial.
+  - **`@object-ui/plugin-list`** — `ListView` hands a grouped grid its own fetch,
+    with the view's effective filter, when the data source can answer the header
+    query, and draws no record-count bar over it. While a toolbar search is
+    active it keeps hosting the rows as before: `$search` has no counterpart on
+    the header query.
+  
+  **Breaking semantics (declared `minor` per this repo's version policy):**
+  
+  - A grouped grid over a capable source sends different requests: one header
+    query per grouping level plus one row query per open group, instead of one
+    window. A host that counted or mocked the single window sees the new shape.
+  - `useGroupedData` takes an optional fifth argument (the server's header rows).
+  - `GroupEntry` gains two REQUIRED members: `count` (the group's size — use it
+    instead of `rows.length`, which is empty on a server-grouped grid) and
+    `keyValues`. Code that only READS a `GroupEntry` is unaffected; code that
+    CONSTRUCTS a `GroupEntry` literal no longer type-checks until it supplies
+    both.
+  - `AggregationResult.value` is `number | null`, `null` being what the server's
+    aggregate answered over no values (rendered as a dash, never invented as 0).
+  - `@object-ui/plugin-grid` and `@object-ui/data-objectstack` now require
+    `@objectstack/spec` `^17.4.0`, the first release that ships the group-query
+    compilers.
+  
+  This supersedes the last paragraph of the pending
+  `7189-grouped-grid-partial-disclosure` changeset, which said server-side
+  grouping was not built: it now is, and the `Partial` marker described there
+  remains only for the data sources that cannot answer the header query.
+  
+  ⚠️ **Dated note, 2026-09-28 — a source with no header query now refuses
+  grouping — objectui#10881.** Later in this same release two sentences above
+  stopped describing the grid: that a source with no header query still groups
+  the page it fetched and still marks it partial, and that the `Partial` marker
+  remains for the data sources that cannot answer the header query. Maintainer
+  ruling F retired both. Over such a source a grouped grid that fetches its own
+  rows, and a `ListView` hosting a grouped grid, refuse grouping with an error
+  naming `queryGroupHeaders`, and the marker is gone everywhere. Rows handed in
+  whole are still grouped in the browser. The rest of this entry is kept as the
+  reading of this change; the `10881-grouping-needs-header-query` entry states
+  what ships.
+- 6a99bb2: `createObjectStackAdapter` declares the adapter it returns, not the shared `DataSource`
+  interface (objectui#7323).
+  
+  The factory returned `new ObjectStackAdapter(config)` while declaring `DataSource<T>`.
+  A wider value is assignable to a narrower annotation, so nothing ever failed to compile
+  — the loss was entirely on the reading side. Measured against the shipped
+  `dist/index.d.ts` with the doc-snippet gate's own compiler options, nine reads through
+  `ReturnType<typeof createObjectStackAdapter>` failed with TS2339: `getClient`,
+  `getCacheStats`, `invalidateCache`, `clearCache`, `getConnectionState`, `isConnected`,
+  `onConnectionStateChange`, `onBatchProgress` and `setSystemCapabilities`. Eight of those
+  nine reads are on this package's README API Reference list, and four whole README
+  sections are built on them; the ninth measured read is the one the factory's own JSDoc
+  links to (`[ADR-0066] See {@link ObjectStackAdapter.setSystemCapabilities}`). The README
+  list is itself **nine** adapter-only members, not eight — `connect()` is adapter-only
+  too and was documented all along; it simply was not one of the reads the card's
+  reproduction measured. So the file's own doc comment pointed the reader at a method its
+  declared return hid, and the two documented ways to obtain the same object — the factory
+  and `new ObjectStackAdapter(…)` — handed back different type surfaces.
+  
+  **What the declared return now is: the whole class, not those nine reads.** The nine
+  above are what the reproduction measured, not the size of this change. The factory's
+  declared return is now `ObjectStackAdapter<T>` itself, so **every public member of the
+  class** is part of what the factory promises. Against `DataSource` that is **20**
+  members, not nine — `tsc`-computed as
+  `Exclude<keyof ObjectStackAdapter<unknown>, keyof DataSource<unknown>>`: `clearCache`,
+  `connect`, `getCacheStats`, `getCached`, `getClient`, `getConnectionState`,
+  `getDiscovery`, `getItems`, `invalidateCache`, `invalidateViewKeys`, `isConnected`,
+  `listImportMappings`, `onBatchProgress`, `onConnectionStateChange`, `onSaveAdvisory`,
+  `onWriteWarning`, `probeAppAccess`, `queryDataset`, `setSystemCapabilities`,
+  `updateDashboard`. The eleven past the documented nine were already in the shipped class
+  type — none is `@internal` or `@deprecated`, `stripInternal` is not set, and all were
+  already reachable through `new ObjectStackAdapter(…)` and through every
+  `ObjectStackAdapter`-typed seam in `@object-ui/react` and `app-shell` — so what widens
+  here is what the **factory declares**, not what the package ships. Two are escape-hatch
+  shaped and worth knowing before building on them: `getCached(key)` is a raw cache read,
+  and `getDiscovery()` reaches an internal property of the underlying `ObjectStackClient`.
+  
+  **Branch taken: A (widen the factory's declared return), and why.** The card offered
+  three. B — moving caching, connection state and batch progress onto `DataSource` — was
+  rejected because those are this adapter's concerns, not every data source's; every other
+  `DataSource` implementation would then declare members it does not have. C — documenting
+  a cast — teaches a cast around a declaration that is merely narrower than the value,
+  which is the opposite of `declared = enforced`. A is one line and makes declared match
+  shipped for every documented member at once.
+  
+  Two questions decided the shape and both were answered from the code before the diff.
+  `ObjectStackAdapter` was **already** exported from the package's only entry
+  (`src/index.ts`, tsup's single entry; the class is in the shipped `dist/index.d.ts`
+  export list, two pin tests assert the exported spelling, and `apps/console` re-exports it
+  by name) — so widening the return exports nothing by implication. And the narrow return
+  was **not** a deliberate swappability guarantee: no comment, ADR or test pinned it, and
+  the commit that added `autoReconnect` / `maxReconnectAttempts` / `reconnectDelay` to the
+  factory's own config bag left the members that observe those features off the factory's
+  declared return in the same change.
+  
+  **One caller shape breaks: a structural stand-in for the factory's return.** A
+  hand-written object literal annotated `ReturnType<typeof createObjectStackAdapter>` no
+  longer satisfies that type, because it is now a class with private members (TS2740) —
+  annotate such a fake as `DataSource` instead, which is what it was standing in for.
+  Nothing else moves: a wider return is assignable to the narrower annotation, so
+  `const ds: DataSource = createObjectStackAdapter(…)` keeps compiling and keeps giving
+  the narrow surface to anyone who wants it.
+  
+  The README's note saying the page could not yet teach the factory's shape is removed, and
+  the four sections built on the adapter-only members (Metadata Caching, Connection State
+  Monitoring, Batch Operation Progress, Troubleshooting → Cache Issues) now continue from
+  Basic Setup's `createObjectStackAdapter(…)` call instead of declaring the class by hand.
+  The docs-site page `content/docs/utilities/data-objectstack.mdx` is corrected the same
+  way: its prose, its factory signature fragment and its "hold the class type to reach
+  these" section described the old narrow return, and its Mutations and Troubleshooting
+  examples told the reader to construct the class by hand to reach members the factory now
+  declares. `src/adapterFactoryReturn.types.test.ts` pins the card's TS2339 reproduction
+  inverted,
+  with two controls: the adapter-only members stay absent from `DataSource` (fires on
+  option B), and the widened return stays assignable to `DataSource` (swappability kept).
+- a915064: `listImportMappings` no longer renders a refused door as "no mapping is registered"
+  (objectui#7741).
+  
+  `ObjectStackAdapter.listImportMappings` degrades every failure to an empty list, and the
+  import wizard hides its saved-mapping selector on an empty list. So "the server served
+  zero mappings" and "the server refused, or broke" produced the identical UI on every
+  deployment — the feature simply absent — with a `console.warn` as the only
+  discriminator, in the browser console, with nothing pointing at it. That silence did not
+  merely hide a fault: it produced a confident WRONG diagnosis in a careful reporter
+  (objectstack#14026 was filed, routed and worked by two seats against a wizard that had
+  been correct since `@object-ui/data-objectstack@17.1.0`).
+  
+  **The empty-list return is unchanged.** `listImportMappings` still answers
+  `Promise<any[]>` and still never throws, on every arm including the loud ones — this is
+  a channel added ALONGSIDE that contract, not a change to it.
+  
+  - **New: `ObjectStackAdapter.onMetadataReadWarning(cb)`** — a subscribe/unsubscribe
+    channel, sibling in shape to `onWriteWarning` and `onSaveAdvisory`. It fires when a
+    metadata read failed in a way that is NOT the supported "this deployment does not
+    serve that kind" shape, carrying `MetadataReadWarningEvent`: which read it was, the
+    object, whether the server `refused` this caller or the answer was `unreadable`, and
+    the server's own ADR-0112 code, HTTP status and message.
+  - **New: `classifyImportMappingsFailure(err)`** and `ImportMappingsFailureKind`, exported
+    so a consumer can apply the same verdict. It reads the ERROR — the ADR-0112 `code`
+    first, the status only where no code was declared — and never "is the result an empty
+    array", which is what both conditions produce and so can never tell them apart.
+  - **The older-server case stays quiet.** A deployment that does not serve the `mapping`
+    kind (404/501 with no route, `ROUTE_NOT_FOUND`, `NOT_IMPLEMENTED`, or the metadata list
+    door's 400 `INVALID_REQUEST`) still degrades to an empty list with no selector and no
+    event. That is a real, supported deployment shape and it must not become a visible
+    fault.
+  - **The console now says so.** `AdapterProvider` subscribes to the new channel and
+    renders a warning toast naming the object, the remedy and the server's own words, so a
+    user without devtools open can tell "there are none" from "we could not find out".
+    Three new `console.importMappings*` keys ship in all ten locale packs.
+  
+  This applies framework objectstack#13906 decision 1 option A — *a thing that could not be READ is
+  not a thing that is ABSENT* — at this seam. It is an already-adopted discrimination, not
+  a new principle.
+- 53ded82: Array filters on analytics aggregates were posted un-lowered and refused by the runtime with 400; they are now lowered to the canonical `FilterCondition` before the wire.
+  
+  An `element:number` or an `object-metric` whose filter is authored as an array (`[{ field, operator, value }, ...]`, a comparison tuple, or an `and`/`or` group) reached `POST /analytics/query` as an array. That route parses the body with `AnalyticsQueryRequestSchema` first, and its `where` is a `FilterCondition`, so the widget answered `400 Invalid AnalyticsQuery body: where: ...` instead of its number — leaving the MongoDB-style record as the only authoring form that still worked.
+  
+  `aggregate()` now lowers the array through `parseFilterAST`, the single sink `@objectstack/spec` names for turning a `FilterArray` into a `FilterCondition`, so the posted `where` is the shape the wire declares. An empty array posts no `where` at all, a record-shaped filter is unchanged, and an array the sink cannot lower — an infix join such as `[condA, 'or', condB]` — is refused with this adapter's `INVALID_FILTER` / 400 error rather than posted or silently dropped into an unfiltered aggregate.
+- 9662aca: Apply the object-metadata write invariant at the write DOORS instead of at the writers.
+  
+  objectui#7714 ruled that a half-filled relationship stays client-side and the PUT body never
+  carries one without a non-empty `reference`, and implemented that ruling by naming the two
+  writers it knew of. The identical defect was then reproduced on a third (fixed in `9073cf018`); a
+  sweep found nine more. The doors — the three places in this repo that actually PUT `/meta/:type/:name` —
+  now apply the invariant themselves, so every writer is covered without any list of writers
+  existing anywhere, and a new door is caught by a gate that derives the door set from the
+  tree rather than restating it.
+  
+  Behaviour change for consumers: `MetadataClient.save('object', …)` now throws BEFORE issuing
+  the request when the body carries a relationship field with a missing, empty or whitespace-only
+  `reference`. The same document is refused by the server with a 422 on `fields.NAME.reference`,
+  so nothing that previously succeeded now fails — the refusal moves earlier, names the field,
+  and leaves the draft in the client instead of wedging every later save of that object. Writes
+  of every other metadata type are untouched.
+  
+  New export from `@object-ui/data-objectstack`: `assertObjectMetadataWritable`,
+  `RELATIONSHIP_TYPES_REQUIRING_REFERENCE` and `OBJECT_METADATA_TYPE`.
+- abf710d: Lower the TRUE-identity filter combinators to "no constraint" instead of handing the
+  caller's own object back (objectui#8770).
+  
+  `convertFiltersToAST({ $and: [] })`, `{ $or: [{}] }` and `{ $and: [{}] }` returned the
+  INPUT OBJECT unchanged. `lowerLogicalGroup` correctly answers `undefined` for a group
+  that reduces to the TRUE identity — objectstack#5322 rules all three "every row", and a
+  childless `['and']` would be `isFilterAST` FALSE — but when such a group was the only
+  thing in the filter, that `undefined` fell through to the general tail
+  (`if (conditions.length === 0) return filter`) and the group reappeared one level up, in
+  the `$` dialect, in the slot the AST occupies. The same function already lowered the
+  fourth identity, `{ $or: [] }`, correctly, so this was an internal inconsistency rather
+  than an open question; the consumer half was settled by objectui#8513.
+  
+  **This widens what those three filters return, and that is the point.** Measured against
+  `@objectstack/spec` 17.4.0 and `@objectstack/client` 17.4.0 before the change: the
+  returned object is not sent as a filter and refused — `client.data.find()` tests the
+  value with `isFilterAST` and its else branch spreads a plain object's entries as query
+  parameters, so `{ $and: [] }` left as `?$and=` with **no `filter` parameter at all**, and
+  the server answered `400 UNSUPPORTED_QUERY_PARAM` for the unknown `$`-prefixed
+  parameter. A filter whose ruled answer is EVERY ROW was a **failed list**, not a narrowed
+  one — so nothing could have been relying on it to scope data. On the sibling
+  `$expand` / `$search` route the same object travelled as `filter={"$and":[]}`, which the
+  server accepts as a `FilterCondition` and already answers with every row; the two routes
+  disagreed about one filter and now agree.
+  
+  **`@object-ui/core`.** `convertFiltersToAST`'s declared return type gains `undefined`,
+  which is what `toFilterNode`, `mergeFilterNodes` and `data-objectstack`'s
+  `translateFilterToAST` already mean by "no filter, skip the slot". Every call site
+  already acted on it. The fold is scoped to a filter whose EVERY key is such a group:
+  the same tail also serves `{}`, an all-null filter and an empty operator map, and those
+  keep the object they always returned — a null-valued key is this converter's own
+  tolerance rather than a ruled identity, and the object it hands back reaches the server
+  as a REAL `a IS NULL` predicate on the `$expand` route, so folding it in would return
+  more rows on a path the ruling said nothing about.
+  
+  `{ $or: [] }` is untouched: FALSE is not "no constraint", the AST has no contradiction
+  literal, and its `['$or', '=', []]` leaf answers FALSE at both consumers.
+  
+  **`@object-ui/data-objectstack`.** `convertQueryParams` skips the `filters` slot when the
+  lowering answers `undefined`, the same answer the raw-GET route's
+  `if (translated !== undefined)` already gave, so the two `find()` routes cannot disagree
+  about one filter.
+  
+  **Migration.** A TypeScript caller that stored `convertFiltersToAST(...)` in a
+  `FilterNode | Record<string, any>` slot must widen it with `| undefined` and skip the
+  filter when it is absent — the same handling `toFilterNode` has always needed. At
+  runtime, a filter that is nothing but TRUE-identity combinators now returns every row
+  (what objectstack#5322 rules) instead of failing the request.
+  
+  ⚠️ **Dated note, 2026-09-27 — an empty operator map no longer keeps the object — objectui#9164.**
+  Later in this same release `convertFiltersToAST` refuses an empty operator map that is all
+  a filter says (`{ a: {} }`, `{ a: {}, b: undefined }`, `{ $and: [], a: {} }`) with a
+  `FilterOperatorError` instead of returning the object, so the sentence above that it
+  "keeps the object" no longer holds for it; an all-null filter had already moved to
+  `undefined` with objectui#9020. Only `{}` still comes back as itself. The rest of this
+  entry is kept as the reading of this change; the objectui#9164 entry states what an empty
+  operator map now answers.
+- 2bf34f7: The console's "app not available" screen now says what it measured, and the by-name app
+  probe stopped folding four answers into one (objectui#9262).
+  
+  **BREAKING for consumers of the published `AppAccessVerdict` type.** `probeAppAccess`
+  widens by two members ruled by the maintainer: `granted | denied | unknown` becomes
+  `granted | denied | not_found | unreachable | unknown`. A consumer that exhaustively
+  switches on the verdict gains two cases. The meaning of `unknown` also narrows — it no
+  longer means "an absent app, an unreachable server, or an adapter that cannot ask", it
+  means only that nothing was asked (a host DataSource without this probe). Code that read
+  `unknown` as a positive absence must move to `not_found`.
+  
+  **What users see.** The sentence `This app is not available yet — it may still be
+  publishing. Try again in a moment.` is retired from all ten locale packs. It was asserted
+  for seven distinct causes, only one of which is a publish, and it is the screen an author
+  lands on after any of them — the same defect objectui#4252 split `denied` off this screen
+  for. In its place: `This app can't be opened` for a measured absence, `Couldn't reach the
+  server` for a probe that got no answer, the unchanged denial screen for a permission
+  refusal, and a neutral `App not available` when nothing was measured. All but the denial
+  keep the Retry button, because all but the denial can change on their own. A genuine
+  post-publish lag reads as an absence, and the one forced metadata refresh that gives that
+  lag its chance to resolve is unchanged.
+  
+  **Measured before the branches were written.** On a real server the by-name route answers
+  `200` with the declared envelope MINUS its `item` for a name that does not exist — not the
+  `404` this code assumed — so `probeAppAccess` returned `granted` for every typo, every
+  never-created app and every unpublished draft. `granted` fell through to the same screen as
+  `unknown`, which is why nothing showed. Absence is therefore read from the envelope as well
+  as from the `404` code; a `not_found` branch keyed on the status alone would have been dead
+  for the commonest case.
+- b253c4e: The import wizard's "Download template" button now downloads the server's import template, an Excel workbook, instead of building a CSV of every field (objectui#9600).
+  
+  The old CSV listed every field the wizard was handed, including the system and read-only columns every object carries (created by, owner, and so on). The server strips those columns on import without an error, so a user who filled them in lost that data silently. The server's template (`GET /api/v1/data/:object/export?template=true`, objectstack 17.6.0) lists only the columns this caller can import. It marks required ones with `*`, adds dropdowns for select and boolean columns, and includes an instructions sheet.
+  
+  - **`@object-ui/types`: new optional `DataSource.downloadImportTemplate(resource)`**, resolving to the template file as a `Blob`. Additive. When a data source lacks it, no template is offered: there is no client-side fallback.
+  - **`@object-ui/data-objectstack`: `ObjectStackAdapter.downloadImportTemplate(resource)`** sends `template=true` on the export route, on the same request path as `exportDownload`. When the client has a locale set (`getClient().setLocale`), the request carries it as `Accept-Language`, the way the import request does. The template's labels are written in the request's locale, and the import accepts a translated label only in its own request's locale, so the two requests must match.
+  - **`@object-ui/plugin-grid`: `ImportWizard` offers the template** when its data source has `downloadImportTemplate` and the user can create records of the object (`usePermissions().can(object, 'create')`, the server's own gate). A 405 (object not open for import), a 403 (no create permission) and any other failure each show a message on the upload step, and no file is saved. The client-built CSV is deleted, with its helpers (`buildImportTemplateCsv`, `exampleForField`, `firstOptionValue`, `downloadTextFile`). The column mapping step is unchanged.
+  - **`@object-ui/app-shell`**: the identity-import data source (`sys_user`) withholds `downloadImportTemplate`, because the server's template describes the generic import door, not the identity pipeline.
+  - **`@object-ui/i18n`**: `grid.import.downloadTemplateHint` describes the Excel template in all ten packs, and `grid.import.templateDownloadFailed` and `grid.import.templateNotPermitted` are new.
+- d5c1f52: `classifyAnalyticsFailure` now reads a 400 as a refusal of the query body we
+  sent regardless of which ADR-0112 `code` it carries, so `aggregate()` no
+  longer answers a rejected filter with client-side numbers from a different
+  door (objectui#7755).
+  
+  Before this fix, only 400 `VALIDATION_FAILED` (and a code-less 400) threw
+  `AnalyticsQueryRejectedError`. Any OTHER coded 400 — `service-analytics` ships
+  its own 400 `INVALID_FILTER` on a filter shape it refuses — matched none of
+  `classifyAnalyticsFailure`'s branches and fell through to `unknown`, which
+  `aggregate()`'s catch has no arm for, so it silently degraded to
+  `aggregateViaFind`: a re-read through `find()`'s `$filter` query-string
+  contract, which accepts array shapes the analytics request body does not. A
+  filter the analytics route refused could still be answered — with a
+  plausible, wrong number, and no sign the request had a defect.
+  
+  The fix is a floor UNDER the existing code branches, not a replacement for
+  them: `NOT_IMPLEMENTED` / `ROUTE_NOT_FOUND` still win `not-installed`,
+  `VALIDATION_FAILED` / `UNAUTHENTICATED` / `CUBE_NOT_FOUND` still win their own
+  outcomes first (objectui#5721). Only a 400 that none of those four already
+  claimed now falls to the new floor instead of past it. An unmatched NON-400
+  coded error (e.g. a coded 5xx) is unaffected and keeps degrading exactly as
+  before — this fix is scoped to the 400 case only.
+- b2065e7: Classify `/analytics/query` failures by their ADR-0112 `code` rather than their HTTP status, so a chart is no longer answered from a different code path behind the wrong explanation.
+  
+  `classifyAnalyticsFailure` tested `status === 404 || status === 501` before the code operands on the same line, so the status short-circuited every one of them: any 404 on this face was classified "the analytics capability is not installed" whatever code it carried, and `NOT_IMPLEMENTED` / `ROUTE_NOT_FOUND` were unreachable for the conditions they name. Three unrelated conditions answer 404 on this url, so the status cannot tell them apart — the `code` is the contract.
+  
+  Two conditions change behaviour:
+  
+  - **404 `CUBE_NOT_FOUND`** (a misspelled or unregistered cube — an authoring mistake) now **throws** the server's own error verbatim, keeping `code` and the producer's repair instructions. It previously warned "install `@objectstack/service-analytics`" and silently degraded to `find()` + client-side aggregation — which cannot answer it anyway, because the fallback re-reads the same name through `/data`, where an unregistered object is a 404 `OBJECT_NOT_FOUND`.
+  - **401 `UNAUTHENTICATED`** (an anonymous or lapsed session) now **throws** `AnalyticsUnauthenticatedError` instead of degrading silently behind a `find()` that is about to be refused the same way.
+  
+  Unchanged: `NOT_IMPLEMENTED` / `ROUTE_NOT_FOUND` and code-less 404/501 answers still degrade loudly to the client-side fallback, 400 `VALIDATION_FAILED` still throws, and 5xx / network failures still degrade silently.
+- b470e91: The metadata designer states its package on the publish step, not only on the save
+  
+  Studio's designer save→publish loop bound the draft to a software package on the
+  save (`PUT ?mode=draft&package=<id>`) and then sealed it with a publish that named
+  no package at all. objectstack `9e04c3e35` (shipped in `@objectstack/rest` 17.2.0) taught
+  `POST /meta/:type/:name/publish` to accept `?package=<id>`, so the second call can now
+  state the same binding the first one already states.
+  
+  - `MetadataClient.publish()` accepts `packageId` and sends `?package=<id>`, the same
+    wire spelling and the same `encodeURIComponent` treatment `save()` gives it.
+  - `MetadataResourceEditPage` reads the binding for BOTH steps from one derivation
+    (`readActivePackageBinding`), so the two calls of one loop cannot drift apart. The
+    `?package=all` "show everything" scope keeps folding to "no package".
+  
+  The parameter is **omitted**, never sent empty, when the designer holds no binding.
+  Empty and absent are the same to the framework's normaliser today, but absent is the
+  shape the save door already followed, and the framework's promotion path branches on
+  the key being present downstream.
+  
+  What this buys is **reachability**, not speed: it lets `#9612`'s package-closure
+  narrowing at the runtime publish gate fire on an HTTP-driven promotion at all. That
+  narrowing has a second, independent gate this does not touch — objects carrying no
+  `_packageId` provenance are kept unconditionally — so on a tenant-authored overlay
+  corpus stating the package still narrows nothing.
+  
+  ⚠️ **Dated note, 2026-09-29 — the publish-gate narrowing is an objectstack card — objectui#11016.** The last paragraph
+  names the package-closure narrowing by a bare number, which in this repository
+  resolves to an unrelated objectui pull request. It is
+  objectstack-ai/objectstack#9612, the runtime publish gate's rule snapshot. The text above is kept as the reading of this change.
+- fffa30d: `listViews` no longer renders a refused metadata read as "this object has no saved views"
+  (objectui#8151).
+  
+  `ObjectStackAdapter.listViews` degrades every failure to an empty list, and every consumer
+  reads only the return. So "the server served zero saved views" and "the server refused, or
+  broke" produced the identical UI — with a `console.warn` as the only discriminator, in the
+  browser console, with nothing pointing at it. It is the same defect objectui#7741 removed
+  from `listImportMappings` one method over, and the user-visible cost is the higher one: an
+  empty `listViews` is an object's **view switcher**, so a user whose token lapsed
+  mid-session could be shown an object that appears to have no saved views at all —
+  including views they created themselves.
+  
+  **The empty-list return is unchanged.** `listViews` still answers `Promise<any[]>` and
+  still never throws, on every arm including the loud ones — this is a channel added
+  ALONGSIDE that contract, not a change to it. `listImportMappings` is likewise unchanged,
+  down to its wording.
+  
+  - **`ObjectStackAdapter.listViews` now emits on `onMetadataReadWarning`** — the channel
+    objectui#7741 added — when the read failed in a way that is not the supported "this host
+    mounted no metadata door" shape. The event carries the object, whether the server
+    `refused` this caller or the answer was `unreadable`, and the server's own ADR-0112
+    code, HTTP status and message.
+  - **New: `classifyViewsFailure(err)`.** A SEPARATE reading, deliberately not a second
+    caller of `classifyImportMappingsFailure`: `view`'s quiet set is strictly smaller. The
+    arm the mapping classifier is built around — 400 `INVALID_REQUEST`, the metadata list
+    door's "this deployment carries no such kind" — is unreachable for `view`, which is in
+    the platform's static spelling contract, so reading it as kind-absence would swallow a
+    real refusal. On `view`, only a host with no `/meta` door at all stays quiet.
+  - **`MetadataReadWarningEvent`'s `operation` and `kind` gain their second members**
+    (`'listViews'` / `'view'`). This is the additive, reviewed widening the single-member
+    unions were designed for, and it worked as designed: the consumer that renders these
+    events had a `switch` naming one operation, so the widening turned "a views failure is
+    toasted as an import-mapping failure" into a compile error rather than a runtime lie.
+  - **New: `MetadataReadFailureKind`**, the neutral spelling of the three verdicts.
+    `ImportMappingsFailureKind` is now an alias of it — identical members, so existing
+    consumers are unaffected in both directions.
+  - **The console says which list it was.** `metadataReadWarningToast` picks its title and
+    its remedy by `operation`, so a failed view read reads *"Saved views for {{object}}
+    could not be loaded … not because this object has no saved views"*. Three new
+    `console.savedViews*` keys ship in all ten locale packs; the `console.importMappings*`
+    copy is untouched.
+  
+  This applies framework objectstack#13906 decision 1 option A — *a thing that could not be READ is not
+  a thing that is ABSENT* — at the second seam that needed it.
+- 8e00bfd: **Breaking (published surface):** remove `options.actor` from `MetadataClient`'s
+  `save`, `reset`, `publish` and `rollback`, and stop emitting the `X-Actor`
+  request header.
+  
+  The server stopped honouring that header. objectstack#7941 ruled that the
+  recorded actor is the identity the request was authorized as, and removed the
+  header limb from the `/meta` write resolver — attribution cannot drift from
+  authorization. The option therefore typed cleanly, sent a header, and could not
+  influence the audit or history row it appeared to address: a false affordance
+  that promised attribution and silently failed to deliver it.
+  
+  Three declarations go: `MetadataClientSaveOptions.actor` (inherited by
+  `MetadataDeleteOptions` via `extends`, so it served both `save` and `reset`),
+  and the inline `{ actor?: string }` on each of `publish` and `rollback`.
+  `MetadataAuditEntry.actor` is unaffected — that is the server's read-back of
+  who acted, and it remains the way to see attribution.
+  
+  Marked `minor` rather than `major` per this repo's version-alignment policy
+  (the fixed group's major tracks `@objectstack`, and `major` in a changeset
+  would drag all 39 packages off that cadence).
+  
+  No caller in this repo passed `actor`; the census found the only in-repo
+  occurrence was the client's own unit test. Callers outside this repo that still
+  pass it are unaffected at runtime beyond losing a header the server already
+  ignored — the property is dropped rather than forwarded, pinned by
+  `metadata-actor-retired-4834.pin.test.ts`.
+- fd8dace: Studio surfaces the runtime authoring gate's advisory findings after a **publish**, not only after a save
+  
+  objectui#4133 / PR #4236 wired the gate's advisories to the save door and recorded, honestly, what that left unsurfaced: Studio's designer stages every edit as a `mode: 'draft'` save, drafts are never gated (the framework returns at its D1 early-return before a single rule runs), and the publish step that *is* gated returned no `advisories` field at all. So on the flow most tenants actually use, the author was told nothing at either door — for two different reasons, only one of which was objectui's.
+  
+  The second reason has expired. `PublishMetaItemResponseSchema` now declares the same optional, omitted-when-empty `advisories` key that `SaveMetaItemResponseSchema` has carried since #4717, and `publishMetaItem` populates it. Measured against the installed `@objectstack/spec` (17.2.0) rather than inferred from the version number: the key survives a `safeParse`, a half-shaped finding is rejected, and a clean publish omits the key entirely. That reading is now a test rather than a note, so a spec drift fails CI instead of silently re-muting the door.
+  
+  ⚠️ **Dated note, 2026-09-29 — the save response's advisories key came from an objectstack card — objectui#11016.** The
+  paragraph above dates the save response's `advisories` key by a bare number,
+  which in this repository resolves to an unrelated objectui item. It is
+  objectstack-ai/objectstack#4717, the card that put the runtime authoring gate's
+  advisory findings on the response. The text above is kept as the reading of this change.
+  
+  `MetadataClient.publish` and `MetadataClient.publishDraft` — the two methods over the single-item publish route `POST /meta/:type/:name/publish` — now report through the **same** sink, the same event and the same renderer the save door already used. No new UI shape: same warning tier, same 10s duration, same per-finding `rule` + `message` + `hint` formatting, findings still rendered verbatim as server prose. The wiring lands in the data layer rather than at the call sites, so `ResourceEditPage`'s Publish button and the runtime `RuntimeDraftBar` promotion (ObjectView / ReportView / DashboardView) are covered by one change, as are future ones.
+  
+  One thing had to differ, and it is the frame's verb. Save and Publish are two different buttons in this product, so a toast that says "Saved" after a Publish tells the author their change is still a draft — the opposite of what happened. `MetadataSaveAdvisoryEvent` therefore gains a required `door: 'save' | 'publish'` and the renderer picks `console.publishAdvisoryTitle` (added to all ten locale packs) accordingly. `door` exists because `mode` cannot answer this: a direct active save and a draft promotion both report `mode: 'publish'`, since both land the body in the active overlay. It is required rather than optional so a future third door cannot be wired without saying which one it is, and the renderer branches on it through an exhaustive switch with a `never` check, so adding a third member is a compile error rather than a silently wrong verb.
+  
+  **BREAKING for event constructors — `MetadataSaveAdvisoryEvent.door` is required.** Reading the event is unaffected: a listener that ignores `door` behaves exactly as before, and every other member is unchanged. Constructing one is a compile break — a door-less event literal that type-checked before now fails with TS2741, `Property 'door' is missing`. Measured on the emitted `dist/index.d.ts` of `@object-ui/data-objectstack` on both sides: that single required member is the entire non-comment delta of the package's published surface. **Migration:** add `door: 'save'` or `door: 'publish'` to the literal, whichever write it models — `'save'` for `PUT /meta/:type/:name`, `'publish'` for `POST /meta/:type/:name/publish`. Scored `minor` rather than `major` per the repo's version policy: objectui's major is pinned to `@objectstack`'s so that "same major means compatible" holds across the two repos, so objectui's own breaking changes ship as `minor` with the break named here (`scripts/check-changeset-no-major.mjs`). Every publishable package sits in one `fixed` group, so this entry carries the group.
+  
+  Unchanged, deliberately: the **batch** door. "Publish whole app" (`POST /packages/:id/publish-drafts`) discarded per-draft advisories server-side when this change was written — objectstack#9343, open and unruled at the time — and nothing here compensated for that from the client side. A test pinned the absence, so a later traversal of a batch-shaped `published[]` could not be added without turning it red.
+  
+  *Corrected before release (`ce986aafc`): both present-tense claims in the paragraph above went false after it was written — objectstack#9343 landed, the batch response now carries per-draft advisories, and `ce986aafc` routes that door through the same seam and flips the absence pin to a presence pin. The paragraph is kept in the past tense as the record of what this change did and did not do; this note is what the CHANGELOG publishes instead of a sentence that was true only while it sat here.*
+- 2d36552: Pins `@objectstack/spec`, `@objectstack/client`, `@objectstack/formula` and `@objectstack/lint` to `17.1.0`, and adapts the two consumer surfaces the new build moves.
+  
+  The pin itself is a lockfile refresh — every manifest already declared `^17.0.0`, which admits `17.1.0`, so no dependency range changed. All four move together: a split resolution is what produced the dual-version spec graph that reddened `check:spec-symbols` in this repo's history.
+  
+  **A `icontains` filter now reaches the driver as a filter.** `icontains` is a canonical `VIEW_FILTER_OPERATORS` member as of `17.1.0`, so an author can declare it on a `ViewFilterRule` and the spec validates it — but `@object-ui/data-objectstack`'s alias table had no row for it, and an unmapped operator is how this adapter shipped an unfiltered query before (objectstack#3948). It is an identity row like `contains`: `icontains` is itself a member of `VALID_AST_OPERATORS`, so the spelling the author writes is the spelling the AST takes, and no case-sensitivity is translated away. Declared rather than left to the table's `?? op` fall-through, on the rule its own parity test states — the AST gate accepting a spelling is not the driver compiling it into a `WHERE` clause.
+  
+  The same operator reaches the list view's own bridge: `@object-ui/plugin-list`'s `mapOperator` gains an explicit `icontains` arm. The emitted spelling is identical to the input, but the arm is written out rather than left to the `default` passthrough — `icontains` is its own member of `VALID_AST_OPERATORS`, so a raw passthrough is accepted *today*, and depending on that coincidence is what the bridge's own parity test records as how it once stopped discriminating.
+  
+  `@object-ui/core` adds `onSuccess` to its spec key inventory, so an author writing the key `17.1.0` now declares is no longer warned that it is unknown. That is a diagnostic statement only — the four declared action surfaces still drop the key before it reaches the runner, which is tracked separately.
+  
+  **A stored view filtering case-insensitively still shows that operator when it is reopened.** `@object-ui/plugin-view`'s canonical-to-builder table is keyed by `ViewFilterOperator`, so `17.1.0` adding `icontains` failed to compile rather than letting the operator reach the FilterBuilder as a raw spelling its dropdown cannot select. It maps to the builder's `containsCaseInsensitive` — the id that authors the spec's `$icontains` — and deliberately not to `contains`, which would quietly rewrite a case-insensitive filter into a case-sensitive one the next time the view was saved.
+  
+  **The page-editor palette keeps one entry per renderer.** `17.1.0` retires `element:filter` from `PageComponentType` and adds `record:discussion`, leaving the member count at 34 either side — so the swap is invisible to any count-based reading. The stale `element:filter` exclusion is dropped, and `record:discussion` is excluded because it is the *same renderer* as the already-offered `record:chatter`, not because it is unauthorable. Nothing the palette offers changes.
+  
+  **The console eager-closure ceiling is re-baselined, by maintainer ruling.** The release is roughly 930 KB larger uncompressed and nearly all of it lands in `vendor-objectstack-*.js`, which put the closure past a ceiling that was deliberately sized to catch a 89 KiB regression — the gate refused the bump, correctly. Raising it was escalated rather than taken locally, because gate-strength policy had been ruled the maintainer's; the ruling on objectui#5531 authorised the raise. `MAX_EAGER_CLOSURE_GZIP_BYTES` and the `BASELINE` it is derived from move together in one commit, keeping headroom at 2.00% and below the 91,136-byte regression size the gate must still catch. The gate's *sensitivity* is untouched: a repeat of that regression from the new baseline still fails. No behaviour ships from this file — it is CI policy, recorded here because the version it governs is the one this changeset publishes.
+
+### Patch Changes
+
+- 9ec8ceb: Views that an earlier "Edit view config → Save" made read-only recover on read, and keep
+  their edits (objectui#10210).
+  
+  A view row now counts as a personalization overlay only when it carries the `_isOverride`
+  marker. The view list used to treat a flat row carrying `viewKind: 'list'` as an overlay
+  too, a shape guess kept for toolbar rows written before the marker existed. A config save
+  on a code-defined view stored exactly that shape, so the view dropped out of the saved
+  views and its tab turned read-only, for good once the draft was published. With the guess
+  retired, such a row reads back as the saved view it is: its tab is editable again and shows
+  what the save stored. Nothing is rewritten at rest; the next read is enough.
+  
+  ⚠️ This exposes one class of row: overlay rows written before the marker
+  (objectui#4227, closed 2026-08-15) and never touched since. They have the same shape, so
+  they now also read as plain rows, and their frozen label, columns and filter copy covers
+  the code definition again. No deployment is named as holding one.
+- f812f37: fix(data-objectstack): the object-metadata write refusal no longer points at an issue that answers 404
+  
+  `assertObjectMetadataWritable` throws when an object-metadata write carries a relationship
+  field with no usable target, and a host surfaces that message on screen or in a log. Its
+  reason ended with two issue pointers, and one of them answers 404, so a reader who followed
+  it found nothing. The message now cites only objectui#7714, the ruling the refusal enforces.
+  
+  Nothing else in the message moves: the door name it opens with, the field it names, the
+  target state it describes and the advice it closes with are unchanged, and the guard refuses
+  exactly the writes it refused before.
+- ac15833: fix(data-objectstack, plugin-dashboard): a dataset tile the viewer may not read shows a localized "no access" state (objectui#10899)
+  
+  When the analytics read admission refused a dashboard dataset query — `403`
+  with ADR-0112 `PERMISSION_DENIED` — `queryDataset` had no branch for that code,
+  so it threw the generic `Dataset query failed: 403 Forbidden — [Analytics]
+  Access denied: …` string, and `DatasetWidget` printed it verbatim in a red
+  alert. The list view over the same object already says 「无权访问」.
+  
+  - `queryDataset` now throws a typed `AnalyticsForbiddenError` for that code,
+    carrying `httpStatus: 403` and `code: 'PERMISSION_DENIED'` (plus the server's
+    code and message for diagnostics). A code-less 403 — no ObjectStack route
+    wrote it — keeps the generic error.
+  - `DatasetWidget` classifies a failed query with the shared `classifyLoadError`
+    and, for `forbidden`, renders a localized no-access state
+    (`dashboard.widgetForbiddenTitle` / `dashboard.widgetForbiddenMessage`, new in
+    all ten packs) instead of the exception text. Every other failure keeps the
+    detailed alert.
+- 3c13675: **The console reads a saved view by the spellings `@objectstack/spec` declares, and stops reading the keys nothing writes (objectui#11013).** This is the console end of the ruling on objectstack#20051: the spec now declares the keys the console writes onto a stored view and reads back (`VIEW_CONSOLE_ROUND_TRIP_KEYS`), and the console reads a stored view under those spellings.
+  
+  **A saved view keeps its switcher state across a reload.** A view saved as a record (the "+" tab's create, or "Edit view config → Save") used to come back from `listViews()` with only its configuration, name, label and default flag. It now also comes back with its pin (`isPinned`), its position among saved views (`sortOrder`), its switcher group (`visibility`), its column layout (`columnState`) and its bound `object`. Visible effect: a saved view you dragged to a new position keeps that position after a reload, including in a browser that never saw the drag. The carried keys are read off the spec's record, not hand-listed.
+  
+  **Keys a saved view no longer steers.** No console surface writes any of these onto a view, no view in this repository authors one, and the spec's view schema refuses each by name. A stored view that still carries one now behaves as if it did not:
+  
+  | key on the stored view | what changes for the user |
+  | --- | --- |
+  | `allowExport` | A view carrying `allowExport: false` no longer hides the list's export control or drops its `exportOptions`. Whether a list offers export is the page's setting (the `list-view` / `object-view` node's `allowExport`); which formats it offers is the view's `exportOptions.formats`. |
+  | `wrapHeaders` | Column-header wrapping follows the page's setting, not the view's. |
+  | `editRecordsInline` | On the object page this was read as a second spelling of `inlineEdit`. A view carrying only it no longer turns inline editing on; write `inlineEdit`. |
+  | `clickIntoRecordDetails`, `addRecordViaForm`, `addDeleteRecordsInline`, `collapseAllByDefault`, `fieldTextColor`, `prefixField` | Relayed into the list, which drew nothing from them. No visible change. |
+  
+  The same keys authored on the `object-view` node itself are unchanged: that node's own values still reach the list.
+  
+  **The toolbar policy is read as `userActions`.** The `object-view` node the object page builds, and `@object-ui/plugin-view`'s own kanban / calendar / gallery / timeline / gantt / map route (a host that renders the `object-view` node without `renderListView`), read a view's search, sort and filter toggles from `userActions.search`, `.sort` and `.filter`, where they used to read the bare `showSearch`, `showSort` and `showFilters` flags. On that plugin route, a view that declared `userActions: { search: false }` now hides the search control; the object page's list already honoured it. A stored view that still carries a bare flag keeps its answer: `normalizeListViewSchema` folds it onto `userActions`.
+  
+  **A stored view is bound and identified by its declared keys only.** A view row is matched to its object by `object` (or its configuration's `data.object`), and no longer by `objectName`; it is identified by `name`, and no longer by a top-level `id` or `_id`. This holds in the view switcher (`listViews()` / `listViewOverrides()`), in Studio's view picker for `interfaceConfig.sourceView`, and in Studio's view preview. Every console write stamps both `object` and `name`, and the metadata door refuses a view record or overlay row bound by `objectName` alone, so a row the console wrote is unaffected. The console also no longer stamps an undeclared `objectName` onto the rows it reads, which a saved view's toolbar save used to write back into the stored row.
+  
+  **BREAKING (TypeScript only) — `NamedListView.allowExport` is retired.** It is now a `?: never` tombstone, like the seventeen members objectui#7924 retired: a TypeScript author who writes it gets a compile error there. Ruling A on objectui#7924 had kept it declared only because both relays read it off a view, and those reads are gone.
+- f61dab1: `reference` is now the only spelling ObjectUI writes or reads for a relational field's target object (objectui#11070, round 4, under the objectui#6837 ruling: 「objectui不是前端的项目吗？后端的元数据只要对，前端按协议执行就行了呀」).
+  
+  - **Types.** `LookupFieldMetadata`, `MasterDetailFieldMetadata` and `DetailViewField` (with its zod mirror `DetailViewFieldSchema`) declare `reference` and no longer declare `reference_to`. On the two field metadata types the member is typed by reference to `@objectstack/spec`'s `FieldSchema.reference`. `@object-ui/plugin-form`'s `FieldDefaultsSchemaLike` drops its `reference_to` member the same way.
+  - **Readers.** `LookupField`, `UserField`, `LookupCellRenderer`, `UserCellRenderer`, the inline editor's reference fallback, the form's `current_user` seeding and the inline-subform parent lookup read `reference` alone.
+  - **Emitters.** Every in-repo producer that builds a field definition or a widget `field` prop writes `reference`: the action-param dialog (`paramToField`), the bulk-action dialog, the record detail page, drawer, footer, related list and synthesised page, the gallery card, the form's section-field override and the flow designer's reference picker. The grid's and the dashboard's relational copy sets carry `reference` and no longer copy `reference_to`.
+  - **Ingestion.** `normalizeFieldReferenceKeys` (behind `ObjectStackAdapter.getObjectSchema` and `MetadataProvider`) still folds a legacy `reference_to` / `referenceTo` onto `reference` when `reference` is absent, and still warns in dev. It no longer stamps `reference_to` onto every relational definition, and it still never drops or overwrites a key.
+  
+  `@objectstack/spec`'s `FieldSchema` refuses `reference_to` by name, and objectstack#13847 rewrites stored ones on the serve path and in `os migrate meta`, so a definition served by an ObjectStack backend is unaffected.
+  
+  ## ⚠️ BREAKING for a host that hands `reference_to` to the widgets directly
+  
+  The type change is a compile error for TypeScript that writes `reference_to` on `LookupFieldMetadata`, `MasterDetailFieldMetadata` or `DetailViewField`: rename it to `reference`.
+  
+  At runtime the break reaches exactly one kind of host: one that serves object definitions spelling the target only as `reference_to` through a `DataSource` other than `ObjectStackAdapter`, or that passes such a definition straight into `LookupField`, `UserField` or a cell renderer. Those definitions never pass the ingestion fold. Measured with an object-bound lookup field on `ObjectForm` and a lookup column on `ObjectGrid`, both fed by a hand-written `DataSource` whose `getObjectSchema` returns `{ type: 'lookup', reference_to: 'account' }`:
+  
+  - before this change, opening the picker queried `account` and the cell resolved the record's name;
+  - after it, the picker has no object to query (no `find` call is made) and the cell shows the raw id beside the unresolved-reference marker.
+  
+  The same definition served through `ObjectStackAdapter.getObjectSchema` still works, before and after: the fold adds `reference`, the picker queries `account`, the cell resolves the name, and the dev warning names the field. **Fix:** spell the target `reference` in the definition your `DataSource` serves.
+  
+  ⚠️ **Dated note, 2026-09-30 — the break reaches more than the paragraph above states — objectui#11070.** Two corrections from the contract review of this change, appended rather than edited in; neither changes what ships.
+  
+  - "The break reaches exactly one kind of host" above is too narrow. Host code that read `reference_to` off a definition after ingestion — from `ObjectStackAdapter.getObjectSchema()` or `useMetadata().objects` — also loses that key, because the ingestion pass no longer stamps it (the **Ingestion** bullet above states the fact, and `reference_to` was never a declared member of those definitions). **Fix:** read `reference`.
+  - The measured break above is a `lookup` field's. A `user` field handed a `reference_to`-only definition directly does not end at "no query": `UserField` falls back to `sys_user`, so its picker queries `sys_user` rather than the object `reference_to` named. **Fix:** spell the target `reference` there too.
+  
+  The text above is kept as the reading of this change.
+- 81f8498: objectui now resolves `@objectstack/*` 17.5.0 and `zod` 4.6.5, and follows every contract move that release makes (objectui#11073). `@objectstack/spec` 17.5.0 and `@objectstack/core` 17.5.0 require `zod ^4.6.1`, so objectui's own `zod` resolves to the same 4.6.5: two zod minors do not type-check against each other.
+  
+  ⚠️ Breaking in places, marked `minor` under this repo's version-alignment rule (a `major` in the fixed group would move all of it off the `@objectstack` major). Every narrowing below is the spec's own, and already reaches any consumer that resolves `@objectstack/spec ^17.5`.
+  
+  - `@object-ui/types`: declares `@objectstack/spec ^17.5.0` and `zod ^4.6.1`. A named list view's `pageName` and `tabs` are retired, as the spec retired them: typed `never` and refused by name at parse. `DashboardWidgetSchema` attaches the spec's two new checks (`checkDashboardWidgetStageOrder`, `checkDashboardWidgetMetricMeasureArity`), so a widget the spec refuses is refused here too. Where a strict object is an arm of a plain union, its unknown-key refusal is terminal again (the spec's own mechanism, needed under zod 4.6): the union answers with every arm instead of the one that failed only on unknown keys. That changes the error shape, never the verdict (measured on every objectui union). Two by-name named-view checks that can no longer run are retired; the spec's refusal answers those documents.
+  - `@object-ui/core`: declares `@objectstack/spec ^17.5.0`. `page` leaves the list-view kinds the normalizer knows, as the spec removed `type: 'page'`. `isRefusedTextComparand` and `textComparandRefusalReason` are re-exported from `@objectstack/spec/data`, whose copies are byte-identical. `SPEC_ACTION_KEYS` lists `execution`, which `ActionSchema` now declares.
+  - `@object-ui/data-objectstack`: declares `@objectstack/spec ^17.5.0`, up from `^17.4.0`. Its bundle carries `@object-ui/core`'s filter converter, which now takes `isRefusedTextComparand` and `textComparandRefusalReason` from `@objectstack/spec/data`. `@objectstack/spec` 17.4.0 exports neither, so the old range admitted a spec under which the shipped module names exports that are not there (objectui#5793's floor gate). Nothing moves at runtime in this repository, because the lockfile already resolves 17.5.0. `patch`, as the floor raise of objectui#10864 was.
+  - `@object-ui/fields`: the percent and number `scale` clamp is gone, at the sunset its own test named. The spec now refuses a `scale` above 100 at the declaration, so the width a formatter cannot render no longer arrives, and every face passes the declared width through as it did before the clamp.
+  - `@object-ui/components`: two module-local prop interfaces of the action renderers are renamed (`ActionButtonRendererProps`, `ActionIconRendererProps`), because the spec now exports the old names for its authored props. Neither is reachable through the package's exports map; only the shipped per-file declarations change.
+  - `@object-ui/plugin-list`: the README's view-type example no longer lists the retired `page` kind.
+  - `@object-ui/app-shell`: the flow designer follows 17.5.0 (maintainer ruling on objectui#11088, decision 2). A new `wait` node is seeded `waitEventConfig: { eventType: 'timer', timerDuration: 'PT1H' }`, because the spec now refuses a timer wait with no duration; the inspector shows the Duration at once and it can be changed. The decision form offers the spec's new `mode` (exclusive or inclusive), with no default declared because the spec applies none. The screen form's `mode` states `create` again, because the spec now applies that default. `minor` because the decision form gains a control.
+  - `@object-ui/app-shell`: declares `@objectstack/spec ^17.5.0`, up from `^17.4.0`, and `zod ^4.6.1`, up from `^4.4.3`. The designer now states 17.5.0 behaviour. The screen form's declared `create` default equals a default the spec applies only since 17.5.0, and objectui#9109 requires the two to be equal, so a range that admitted 17.4.0 claimed more than the designer holds to. The resolved versions do not move.
+  - `@object-ui/console`: the bundle inlines the 17.5.0 packages, so its client-side validation answers as the published 17.5.0 contract does. The flow preview sample's script nodes use the 17.5.0 script contract. The eager-closure budget is re-baselined for the release's growth, under the maintainer ruling on objectui#11088 (decision 1).
+- 490d9a9: Grid headers offer a sort click only on columns the PLATFORM says it will order by
+  (objectui#5729 — the consumer leg of objectstack#10235, maintainer ruling A, 2026-08-23:
+  the platform serves an explicit per-column sortability signal and the grid reads it,
+  rather than re-deriving "virtual ⇒ unsortable" from field type).
+  
+  `GET /api/v1/meta/object/:name` now answers with a `sortability` projection on its
+  ENVELOPE — `{ fields: { [name]: { sortable, reason?, caveat? } } }`, computed at serve
+  time from the platform's own storage predicates, deliberately beside `item` rather than
+  inside it so the key stays un-authorable. The signal was reaching the browser and being
+  discarded one line before its only consumer: `ObjectStackAdapter.getObjectSchema` unwraps
+  the envelope to `item`, so every UI reader saw a document with no signal on it. It now
+  survives that unwrap, carried on the schema under a symbol key — invisible to
+  `JSON.stringify`, to `Object.keys` and to a spread, so a schema handed back at a metadata
+  write endpoint can never take it into a body the server parses strictly.
+  
+  `@object-ui/core` gains the one spelling of the consumer contract:
+  `isPlatformSortableField(projection, name)` is `true` iff an entry EXISTS for the name and
+  says `sortable: true`. Absence is a refusal — it is how the platform encodes an unknown
+  name, a dotted path and an unprovisioned audit column, all three of which the runtime
+  doors reject — so the `!== false` spelling every other optional flag in this repo uses
+  would get exactly that family backwards. A projection that is absent ALTOGETHER is a
+  different question with a different answer (`undefined`: no signal was served) and is
+  typed apart from an empty one, so a deployment older than the upstream change keeps the
+  behaviour it had rather than being told, falsely, that nothing on the object is sortable.
+  
+  Three things follow in the grid. The header click on a refused column ceases to exist, so
+  neither the old silent-unordered result nor the `400 INVALID_SORT` that replaced it is
+  reachable from it. A sort PERSISTED before the signal existed is filtered out of both what
+  the grid renders and what it emits, so a restored personalization cannot ride back into
+  the next `persistViewPatch({ sort })` — the half-fix where the affordance is gone and the
+  PUT still fires. And the relational carve-out is untouched and deliberately not delegated
+  to this signal: the platform answers `sortable: true` for a `lookup` (it has a stored
+  foreign key and both runtime doors accept ordering by it), while the grid withholds that
+  header for a different reason — a column of names ordered by an invisible id.
+  
+  Columns carrying `caveat: 'unprovisioned-anchor'` keep their click. The runtime accepts
+  those sorts; refusing what the platform does not refuse would recreate declared-≠-enforced
+  drift in mirror image.
+- a26b9e4: `packages/core/src/adapters/README.md` now documents the adapters that are actually in that
+  directory, and the ObjectStack material it carried moved to the package that owns the behaviour
+  (objectui#6213). Both files ship to consumers — `@object-ui/core` publishes its `src/`, and a
+  README rides every tarball — so this was published documentation describing the wrong package.
+  
+  The page had been left behind when the ObjectStack adapter moved out to
+  `@object-ui/data-objectstack`: its headings, feature list, filter-operator table and
+  query-parameter table were all about that adapter, and its one-entry "Available Adapters" list
+  told a reader Object UI has exactly one adapter and that it comes from `@object-ui/core`.
+  `ApiDataSource`, `ValueDataSource`, `resolveDataSource`, `runBatchTransaction` and
+  `emulateBatchTransaction` — the five exports that directory really ships — were named nowhere.
+  
+  - **`@object-ui/core`**: the page now opens with what the directory holds, gives each export a
+    usage snippet and a `provider` mapping, and points at `@object-ui/data-objectstack` for the
+    ObjectStack adapter. `## Creating Custom Adapters` is unchanged — it is the one section that was
+    always about this directory.
+  - **`@object-ui/data-objectstack`**: gains a `## Query Translation` section carrying the
+    filter-operator and query-parameter mapping tables, the AST conversion example and the sorting
+    example. That material existed **only** in the `core` copy — this package's README documented
+    query translation as a single feature bullet — so it is ported, not dropped.
+  
+  No runtime behaviour changes; the duplicate copy of one package's documentation living under
+  another package is what goes away.
+- 5127378: `ObjectStackAdapter.aggregate()` lowers rule-shaped filter arrays before the
+  analytics wire, reusing the lowering `find()` already runs (objectui#6302).
+  
+  `find()` has translated `[{ field, operator, value }, ...]` into the server's
+  filter AST for as long as `convertQueryParams` has existed. The analytics path
+  did not: `aggregate()` assigned `payload.where = params.filter` verbatim and
+  posted it to `/analytics/query`.
+  
+  The two doors are not equally forgiving, so the gap had a user-visible end.
+  `lowerAnalyticsWhere` in `@objectstack/service-analytics` — shared by both
+  aggregation strategies — accepts AST tuples and throws on an array of rule
+  objects. A stored `ViewFilterRule[]` that a LIST renders correctly therefore
+  rendered `element:number` into its error state on every analytics-capable
+  deployment, which is the default one because the CLI always loads analytics.
+  
+  An array filter now goes through the same `translateFilterArray` the `find()`
+  path uses — one lowering, so the two paths cannot disagree about one stored
+  filter. Rules spread into a logical node (`['and', ...rules, ...tuples]`, the
+  commonest composite there is) are lowered at depth, as they already were on
+  `find()`. Non-array filters are untouched: the MongoDB-style object this branch
+  was written for is what `/analytics/query` already accepts, and translating it
+  would be a semantic change this fix does not make. Already-AST arrays,
+  record-shaped filters, and the no-filter case are byte-unchanged.
+- 5961030: `@object-ui/core` and `@object-ui/data-objectstack` now declare
+  `"@objectstack/spec": "^17.2.0"` rather than `^17.0.0`, which is the lowest published
+  spec that carries every symbol each package's own build output references
+  (objectui#6361).
+  
+  `packages/core/dist/utils/column-sortability.d.ts` references
+  `FIELD_SORTABLE_UNPROVISIONED_ANCHOR`, `FIELD_UNSORTABLE_VIRTUAL_TYPE`,
+  `FieldSortability` and `ObjectSortability` from `@objectstack/spec/api`, and
+  `packages/data-objectstack/dist/index.js` references the first two — none of which
+  `@objectstack/spec@17.0.0` exports. Measured against the published tarballs rather than
+  the installed tree, by `scripts/check-spec-range-floors.mjs`: six `floor-too-low`
+  findings across the two packages, and `^17.2.0` is that gate's own computed answer for
+  both. So the old range was a claim neither package could honour: any consumer
+  resolution that lands 17.0.0 — a sibling pinning it exactly, an `overrides` entry, a
+  mirror two minors behind — satisfied `^17.0.0` and got a dangling reference.
+  
+  Nothing a consumer installs today changes: normal resolution already picks the newest
+  17.x, and `pnpm-lock.yaml` still resolves `17.2.0` on both edges after the bump — only
+  the recorded `specifier:` moves. No source and no behaviour changes, which is why this
+  is scored `patch`, on the reasoning `111741454` used for the same remediation on
+  `@object-ui/plugin-detail`.
+  
+  The bump is release-blocking rather than cosmetic. `check:spec-floors` is deliberately
+  not a `pull_request` job, so every PR stayed green while its blocking copy on the
+  publish path — `pnpm changeset:publish` runs it before a single tarball reaches npm —
+  would have cancelled the next release.
+- 639114c: Reconcile `@object-ui/data-objectstack` with the `@objectstack/*` family at
+  17.3.0 (objectui#7122).
+  
+  `@objectstack/client`, `core`, `formula` and `lint` each pin `@objectstack/spec`
+  EXACTLY, so resolving the spec alone to 17.3.0 left the console bundling TWO
+  copies of it. Moving the family with it in `pnpm-lock.yaml` collapses the
+  duplicate; every declared range already admitted 17.3.0, so no manifest moved.
+  
+  The one source change the family bump forces is a type reconciliation, not a
+  behaviour change. `client.analytics.query` resolved to `Promise<any>` at 17.2.0
+  and resolves to `Promise<AnalyticsResult>` at 17.3.0, so the pre-envelope
+  branches of `aggregate`'s row-shape fallback stopped type-checking. Those
+  branches are read through a widened alias rather than deleted: the client's own
+  docblock records the runtime change behind the narrower type ("BREAKING since
+  objectstack#13079 — read `result.rows`, not `result.data.rows`"), and deleting
+  them is a runtime compatibility decision about servers older than that, not a
+  type repair. The alias restores exactly the compile-time latitude 17.2.0 gave
+  the same expression and changes no runtime byte of it.
+- f57ca75: fix(studio): one draft-envelope reader, and it strips the framework's read decorations
+  
+  `client.getDraft()` serves a DECORATED body — the draft branch stamps
+  `_draft: true` and then `decorateMetadataItem` attaches `_diagnostics` for any
+  type with a registered Zod schema. The spec names both READ-TIME decorations
+  precisely because a served body "is NOT a valid input to the schema that
+  produced it until these are removed" (`METADATA_READ_DECORATIONS`).
+  
+  objectui#7603 taught `ResourceEditPage` to strip them. It could only teach one
+  site, because `extractDraftBody` existed **four times** — three verbatim copies
+  plus a hand-rolled one in `ObjectHooksPanel` — and six more consumers unwrapped
+  the envelope inline. Ten readers, one of which knew the rule.
+  
+  **The user-visible half.** The pending-changes sheet's per-entry diff compares
+  the published body against the draft body key by key. Those two reads are
+  decorated ASYMMETRICALLY — only the draft branch stamps `_draft` — so the sheet
+  listed `_draft` under "Also changed:" on every entry that has a published
+  counterpart, and `_diagnostics` alongside it whenever the two read-time verdicts
+  differed. Framework-internal keys were being presented to the author as their
+  own edits, on the screen where they decide whether to publish.
+  
+  **The rest.** Six sites merged a decorated body into a document they then wrote
+  back through `save(..., { mode: 'draft' })` — the Studio app / page / object /
+  flow surfaces, the package OWD panel, the object hooks panel, and the
+  adapter's `updateView`. Today's server absorbs that (it strips read decorations
+  on ingress, before its own schema gate), so nothing 400s; this is still a client
+  emitting a body its own spec calls invalid, and the fix belongs at the producer.
+  
+  The cure is one function rather than ten strips: `extractDraftBody` is now
+  exported from `@object-ui/data-objectstack`, beside the `getDraft` whose
+  envelope it decodes. The key list is the spec's exported
+  `stripReadDecorations` — never a second hand-maintained copy in this repo. The
+  presence verdict still runs BEFORE the strip, so removing our own annotations
+  can never turn a served draft into "nothing pending", and the ADR-0010
+  protection envelope (`_lock`, `_provenance`, `_packageId`, `_packageVersion`)
+  is deliberately untouched: those keys are declared by the closed schemas.
+  
+  No schema was loosened, and no gate was taught to tolerate `_diagnostics`.
+- 0b8c638: fix(data-objectstack): the rule-entry filter form refuses an empty or non-string `icontains` comparand
+  
+  `@objectstack/spec`'s `FILTER_TEXT_CASES` declares two shapes REFUSED for the
+  case-insensitive contains operator: an empty comparand, and one that is not a
+  string. This adapter already refused both when a filter arrived as an object
+  (`{ name: { $icontains: '' } }`), but a filter in the rule-entry form
+  (`[{ field: 'name', operator: 'icontains', value: '' }]`) was lowered to
+  `['name', 'icontains', '']` and sent. So the same condition was refused or sent
+  depending on which form it was written in. An empty comparand matches every
+  row, so the entry form returned the whole table where the author asked for a
+  subset.
+  
+  The entry form now asks the spec's own `isRefusedTextComparand` after the
+  operator alias fold, so a case variant such as `ICONTAINS`, or the operator
+  given under the `op` key, is judged too. It throws `MalformedFilterError`
+  (`INVALID_FILTER` / 400) carrying the spec's `textComparandRefusalReason`
+  unchanged, before any request is sent, on `find()` (both routes) and on
+  `aggregate()`, and for a rule nested under a logical node as well as at the top
+  level. `convertFiltersToAST` and `ValueDataSource` read the same two functions,
+  so all three now refuse the same set: an empty string and any non-string,
+  including a missing `value`. A missing value used to go out as JSON `null`.
+  
+  `MalformedFilterError`'s public signature is unchanged: the refusal sentence is
+  seated inside this module. Building its message no longer throws for an entry
+  that carries a BigInt (such a value is shown as its literal, e.g. `3n`), and its
+  text is otherwise the same as before. The README's "Rule-shaped arrays" section
+  documents the refusal. The case-sensitive `contains` family is untouched: the
+  table declares no such row for it.
+- 72d6587: A record id is a `string` everywhere in the published types, as
+  `@objectstack/spec` has always declared it. Three published declarations that
+  admitted `number` no longer do.
+  
+  ⚠️ **BREAKING if your code hands a numeric primary key to any of these three:**
+  
+  - **`RecordContextValue.recordId`** (`@object-ui/react`) — the value
+    `useRecordContext()` gives you is now a `string`, never a `number`.
+  - **`DataSource.update`'s `id` parameter** (`@object-ui/types`) — a call that
+    passes a `string | number` is now a type error. Adapters that *implement*
+    `DataSource` are unaffected (see Migration).
+  - **`TransactionOperation.id`** (`@object-ui/core`) — the operation record you
+    hand to `TransactionManager.recordOperation()` must carry a `string` id. If
+    you build that object from a numeric key, convert it where you build it. This
+    type is exported from the package root, so this is a breaking change for
+    `@object-ui/core` consumers in its own right, not just a knock-on.
+  
+  Ships as `minor` per the launch-window convention: objectui's
+  `major` is a cross-repo pin to `@objectstack`'s so that "same major means
+  compatible" holds across the two repos
+  (`scripts/check-changeset-no-major.mjs`), and objectui's own breaking changes
+  ship as `minor` with the break named where it lands — this entry is the channel
+  that carries it.
+  
+  ## What changed
+  
+  - `RecordContextValue.recordId` (`@object-ui/react`) was
+    `string | number | null | undefined`; it is now `string | null | undefined`.
+  - `DataSource.update`'s `id` parameter (`@object-ui/types`) was
+    `string | number`; it is now `string`.
+  - `TransactionOperation.id` (`@object-ui/core`) was `string | number`; it is now
+    `string`. Its sibling `BatchTransactionOperation.id` was already a `string`,
+    so the two operation records finally agree.
+  - `LineItemsPanel` (`@object-ui/plugin-form`) drops the type assertion
+    objectui#9304 left on its parent id. That assertion was the only thing making
+    the context declaration and `buildMasterDetailEditBatch(parentId: string)`
+    meet; the declaration now does it, so the evidence is discharged.
+  
+  ## Why the protocol, and not a wider consumer type
+  
+  `@objectstack/spec` declares a record id as `z.string()` on every record door —
+  get, update, delete and the batch operation. A consumer type may not be wider
+  than the protocol: a declaration that admits `number` promises callers something
+  the wire never carries, and the promise is kept only by an assertion at the far
+  end, which is what this card was filed about.
+  
+  ## Internal consumers repaired at the same time (no public contract moves)
+  
+  Narrowing an interface **parameter** never reaches implementors — TypeScript
+  compares method parameters bivariantly, so an adapter that still declares
+  `id: string | number` keeps satisfying `DataSource`. It reaches **callers**. A
+  full local type-check of every workspace type-check program found exactly six,
+  in three packages, and each was red because a further declaration one layer in
+  was itself wider than the protocol. All three are narrowed here, types only, with
+  no runtime change and no coercion added at any call site:
+  
+  - `UserPreferenceRecord.id` and the `cachedRowId` it feeds
+    (`@object-ui/data-objectstack`) are `string`. Module-local, not published —
+    these rows are read back off the protocol, so the union was a claim the wire
+    never makes.
+  - `resolveRecordId`'s return type (`@object-ui/plugin-grid`) is
+    `string | undefined`. Module-local, not published — it annotates `any`-typed
+    row data, so the union was an assertion rather than a measurement.
+  
+  ## Migration — no `String(...)` at your call sites
+  
+  `RecordContextProvider` still **accepts** `string | number | null | undefined`
+  and narrows it once, itself. A host that mounts a record with a numeric primary
+  key therefore changes nothing: the conversion is paid at that injection
+  boundary, typed, in one place. Consumers of `useRecordContext()` read a
+  `string`.
+  
+  `DataSource` implementors are unaffected — TypeScript compares method parameters
+  bivariantly, so an adapter that still declares `id: string | number` continues
+  to satisfy the interface. What changes is the **caller** side: a call that passes
+  a `string | number` to `dataSource.update` is now a type error. A backend whose
+  primary keys are numeric maps them at its own adapter boundary rather than
+  pushing the union through every caller.
+  
+  For `TransactionOperation`, the same rule applies one level up: build the
+  operation record with a `string` id. If the id arrives from a numeric-keyed
+  backend, convert it in your adapter — the one place that knows the backend's key
+  type — rather than at each `recordOperation()` call. Nothing about this change
+  alters what is sent over the wire; only the declarations moved.
+- 269880a: Read the flat REST error envelope in `ObjectStackAdapter`, so a denial that names the
+  missing grant stops arriving as a bare HTTP status word (objectui#9594).
+  
+  A console operator who clicked "export to CSV" without the `allowExport` grant was
+  shown one word: `Forbidden`. The server had answered a full sentence — which object,
+  which user, which axis — and the adapter threw it away.
+  
+  **Why it was thrown away.** `exportDownload` read its failure through a ladder that
+  knew two envelope dialects: the ADR-0112 nested `error: { message }`, and the flat shape
+  that carries a `message` key. The REST export gate writes a third one — flat, with the
+  sentence in a bare string `error` and no `message` key anywhere — so every rung missed
+  and the ladder fell through to `res.statusText`. The same ladder had been hand-copied at
+  four sites in the module (`searchAll`, `rawFindWithPopulate`, `exportDownload`,
+  `fetchObjectSchemaFresh`), and the two upload paths (`uploadFile`, `uploadFiles`) read a
+  narrower version of it, so all six were blind to the same dialect.
+  
+  **The fix is one reader, not six patches.** A single internal `readErrorEnvelope` now
+  holds the dialect knowledge and every one of those six sites routes through it. It is
+  deliberately **not** exported from the package entry point — the published face of
+  `@object-ui/data-objectstack` is unchanged by this release.
+  
+  **The rung order is load-bearing.** `message` is consulted before a string-valued
+  `error`, because the REST 401 body is flat *and* carries both keys, with the code word in
+  `error` and the sentence in `message`. Reading `error` first would make an
+  unauthenticated response render the word `UNAUTHENTICATED` instead of its sentence. The
+  401/403 pair is pinned as a control for exactly that inversion.
+  
+  **The machine code now reaches the caller too.** The four `res.ok` ladders attach the
+  server's `code` to the thrown error (`EXPORT_NOT_PERMITTED`, `PERMISSION_DENIED`, …), so
+  a surface has something to discriminate on and an operator has something to search for.
+  `rawFindWithPopulate` already did this; the other three now match it rather than drifting
+  from it. The code is read from `code` or a nested `error.code` and **never** promoted out
+  of a string `error` — a sentence is not a code, and `@objectstack/core`'s own guidance
+  names that chain as where an envelope regression hides. The upload paths keep their
+  declared `UPLOAD_ERROR` code and their own fallback text; only the dialect reading is
+  shared, because their envelope is genuinely a different shape.
+  
+  **Not a lenient fallback.** ADR-0112's 2026-07-30 amendment records the flat and the
+  wrapped envelopes as the two live, sanctioned shapes, and D5 leaves the flat one's
+  permanent position an open maintainer question. Every site routed through the reader calls
+  a `/data` route, whose declared answer is the flat family, so reading it is conformance
+  rather than tolerance. The server envelope is untouched — that belongs to the producer's
+  ratchet card in the `objectstack` repo.
+  
+  **Blast radius.** Not one route: the REST package answers a wide family of these
+  `{ code, error }` bodies, and `VALIDATION_ERROR` / `PERMISSION_DENIED` / `INVALID_FILTER`
+  arriving as `Bad Request` / `Forbidden` is the same loss with a much wider audience than
+  the export button. The affected-code count quoted on objectui#9594 is a reading taken
+  against one published `@objectstack/rest` version by the scan that card records; nothing
+  in this repo re-derives it, so it is not restated here as a live figure.
+- b2e85a9: `ObjectStackAdapter.getApp` and `getPage` now address the `app` / `page` metadata
+  types in the singular, matching the other twelve `client.meta.*` call sites in this
+  file (objectui#4940).
+  
+  `getApp` (`getItem('apps', …)`) and `probeAppAccess` (`getItem('app', …)`) addressed
+  the same metadata type sixty lines apart, and only `probeAppAccess`'s comment argued
+  its singular spelling was deliberate — the plural site was silent. Both plural sites
+  resolved today only because the server folds plural → singular
+  (`RestServer.metaTypeSingular` via `PLURAL_TO_SINGULAR` from `@objectstack/spec/shared`,
+  confirmed by reading both the mapping and the by-name route handler that calls it), so
+  this is consistency restoration rather than a behavior change — nothing a user hits was
+  broken, and nothing a user hits changes.
+  
+  `appAccessProbe.test.ts` (objectui#4252's local pin for this same spelling) is extended
+  with two new cases asserting `getApp`/`getPage` pass the singular type to
+  `client.meta.getItem`, so a future revert to the plural spelling fails a test instead of
+  depending on the server-side fold staying in place.
+- c7cd2b6: `ObjectStackAdapter.queryDataset` now maps a failed dataset query by the server's
+  ADR-0112 error `code`, not by the HTTP status, so an unknown dataset and an
+  unauthenticated session stop being reported as a missing analytics capability
+  (objectui#5663).
+  
+  Two unrelated conditions answer **404** on `POST /api/v1/analytics/dataset/query`:
+  the runtime dispatcher's `ROUTE_NOT_FOUND` when the route was never mounted, and
+  the route's own `NOT_FOUND` when `body.datasetName` matches no saved dataset. The
+  mapping tested `res.status === 501 || res.status === 404` and called all of it
+  "the analytics capability is not installed", so every unknown dataset produced a
+  banner telling the operator to install `@objectstack/service-analytics` and mount
+  `AnalyticsServicePlugin`. Measured live on a prod tenant, that banner was shown on
+  four HotCRM Executive Overview widgets while the analytics service was installed
+  and answering — the real condition was an installed `app.objectstack.hotcrm` at
+  1.3.0 whose datasets ship in 2.2.2, i.e. a package upgrade, the opposite corner of
+  the system from the remedy the banner named.
+  
+  Three conditions now get three answers, each keyed on the code the framework
+  declares for it:
+  
+  - `NOT_IMPLEMENTED` (501, route mounted with no analytics service) and
+    `ROUTE_NOT_FOUND` (404, route not mounted) keep the existing
+    `AnalyticsNotInstalledError` and its copy — one remedy, one message.
+  - `NOT_FOUND` (404, unknown `datasetName`) throws the new
+    `AnalyticsDatasetNotFoundError` (`ANALYTICS_DATASET_NOT_FOUND`), naming the
+    dataset and pointing at the installed app's version rather than at the server.
+  - `UNAUTHENTICATED` (401, `enforceAuth`) throws the new
+    `AnalyticsUnauthenticatedError` (`ANALYTICS_UNAUTHENTICATED`), which says the
+    request was refused before it ran and therefore says nothing about the
+    capability.
+  
+  The banner also used to print the server's own message in a parenthetical while
+  contradicting it in the headline — it quoted `Dataset "opportunity_metrics" not
+  found.` under a headline claiming a missing capability. That is now structurally
+  impossible rather than merely fixed: the headline is a pure function of `code` and
+  the parenthetical is a verbatim quote of `message`, both read off the same
+  response, and a test walks every branch asserting each message carries its own
+  headline and none of the others'.
+  
+  Additive only. `AnalyticsNotInstalledError` keeps its `code`, its copy and its
+  constructor signature (it gains an optional third `serverCode` argument and a
+  `serverCode` field), so consumers matching `ANALYTICS_NOT_INSTALLED` — including
+  the metadata-admin dataset preview — are unaffected. A 404 carrying a code this
+  client does not recognise, such as the analytics cube gate's `CUBE_NOT_FOUND`, now
+  keeps its server detail instead of being relabelled as a missing capability; a 404
+  or 501 carrying no code at all is still read as the capability being absent, since
+  the route's own `NOT_FOUND` always ships a code.
+- 617707a: `convertFiltersToAST` lowers the `$and` / `$or` combinators to real ObjectQL AST
+  group nodes (objectui#6948).
+  
+  `FilterCondition` declares `$and` / `$or` / `$not`, and this repo's one lowering
+  had no branch for any of them. `$and` / `$or` fell through to the
+  simple-equality branch and became a leaf naming a field literally called `$and`
+  / `$or`. That leaf reached the server intact — `parseFilterAST` reads
+  `['$or', '=', [...]]` back as a real `$or`, so the wire condition was correct
+  and is unchanged by this release — but it is a well-formed *comparison* node, so
+  every AST evaluator in this repo read `$or` as a field name, found no such key
+  on any record, and returned an EMPTY list with no error. Producers that reach
+  this today include `mergeFilters` (dashboard scope broadcast, dataset report
+  blocks), `FilterConditionField`, and `Field.relatedListFilter`.
+  
+  `minor` rather than `patch`: shipped results move. A list filtered by a
+  combinator through any in-process data source went from zero rows to the rows
+  the author asked for, and an unknown or refused operator *inside* a combinator
+  branch — which used to travel to the wire unchecked inside the leaf's value slot
+  — is now refused at the same door as every other operator.
+  
+  `$not` is refused with an accurate message instead of translated: the AST has no
+  negation keyword (`FILTER_ARRAY_LOGIC_KEYWORDS` is `['and', 'or']`) and several
+  operators it carries have no negated counterpart, so a rewrite would be silently
+  partial. It threw before this change too, naming the author's own nested field
+  as a bogus operator; the verdict is unchanged, only the diagnostic.
+- 8d37efb: The metadata lock banner can no longer render an amber, padlocked box with no
+  title, and the ADR-0010 §3.6 lock vocabulary is declared once instead of three
+  times (objectui#5024).
+  
+  `MetadataLayered.lock` and `MetadataAuditEntry.lockState` each spelled the four
+  states out by hand, 42 lines apart in one file, compared by no gate. They are now
+  one exported `MetadataLockState` — derived from `GetMetaItemLayeredResponseSchema`'s
+  `z.enum` in `@objectstack/spec`, which already owns this vocabulary, so the copies
+  were restating a schema rather than filling a gap.
+  
+  The user-visible half is the banner. Its title was three independent `&&` branches
+  with no fallback, while the switch that opens the banner is true for any non-`none`
+  value — so a lock state outside the four opened the box and left the headline
+  empty. That is reachable without a fifth state ever being added here:
+  `MetadataClient.layered()` casts the wire value through unchecked, so a newer
+  server reaches this banner as-is. Measured, not assumed — feeding `no-publish`
+  through the page rendered the padlock, the border and an empty title. The title is
+  now a keyed lookup with a loud fallback that names the unrecognised token, so a
+  fifth state fails `type-check` here and, if one arrives from a server anyway, the
+  operator reads a sentence instead of a blank box.
+- 9118a31: Preserve the producer's `userMessage` marking when `normaliseClientError` re-wraps a refusal.
+  
+  `ApiErrorSchema.userMessage` (objectstack `79c46da90`) is the opt-in channel an application author
+  sets at throw time to say "this text is for the end user", and the contract states it
+  status-agnostic — any refusal status may carry it. Both of the shapes this adapter re-wraps
+  into typed errors dropped the marking: a hook that refused a write with `VALIDATION_FAILED`
+  or `CONCURRENT_UPDATE` and marked its own sentence had that sentence discarded at the
+  adapter boundary, before any surface could render it. Nothing threw and the typed error was
+  otherwise correct, so the only symptom was the user reading a generic string instead of the
+  sentence their administrator wrote.
+  
+  The marking now rides both re-wraps, in the form the shared reader (`declaredUserMessage`)
+  already looks for: on the details bag for `DataApiValidationError`, exactly the way `fields`
+  already survives, and on a new readonly `userMessage` member for `ConcurrentUpdateError`,
+  which has no details bag. Unmarked refusals are untouched — they carry no key and still read
+  as `null`, so nothing a producer did not opt into can reach a user.
+- 7b43319: **Fix:** `MetadataClient.publishDraft` no longer unwraps a `{ success, data }`
+  envelope, so it and `MetadataClient.publish` hold ONE belief about the route
+  they share.
+  
+  The two methods sit ~250 lines apart in `metadata-client.ts` and both POST
+  `/api/v1/meta/:type/:name/publish`. `publishDraft` tolerated a dispatcher-shaped
+  envelope and returned the inner object; `publish` returned the body as parsed.
+  Nothing said which was right, and the card explicitly refused to settle it from
+  `PublishMetaItemResponseSchema` alone — an inference from a declaration is not a
+  measurement of the server.
+  
+  So the producer was read instead, in the framework checkout:
+  
+  - `POST /api/v1/meta/:type/:name/publish` has exactly ONE mount,
+    `packages/rest/src/rest-server.ts`, whose handler ends
+    `res.json(await p.publishMetaItem(publishRequest))` — the protocol object
+    verbatim, no envelope branch on any arm. The ADR-0006 project-scoped base
+    re-mounts that same handler.
+  - The `{ success, data }` envelope has ONE producer, `HttpDispatcher.success()`,
+    and it does not serve this route: no publish branch in `runtime`'s `/meta`
+    domain (its three-segment arm is `/published`, GET only), no row in the
+    dispatcher's route ledger, and a three-segment `/meta` path that is not
+    `/published` terminates in a located `routeNotFound`. That holds for the
+    dispatcher-only Hono adapter as much as for a full `rest` +
+    `plugin-hono-server` boot, where the REST mount shadows the catch-all.
+  - `packages/spec` declares the split in so many words:
+    `PublishMetaItemResponseSchema` documents "the FULL body" of this route and
+    records that the REST route hands the producer's object to `res.json()`
+    verbatim, while the batch sibling `PublishPackageDraftsResponseSchema`
+    documents a body answered "inside the dispatcher's `{ success, data }`
+    envelope".
+  
+  The route never envelopes, so the tolerance was a dialect with no producer —
+  Commandment #0.1's lenient fallback, and the kind that fails in the direction
+  that hides the problem: a body arriving enveloped is one this door did not
+  serve, and unwrapping it presents that as a successful promotion.
+  
+  **Behaviour delta, stated plainly.** Handed an enveloped body, `publishDraft`
+  used to return the inner object and now returns the body as-is. Graded `patch`
+  because that input is not one any measured configuration emits: on a conformant
+  response — which has no `data` member at all — the removed branch was already a
+  no-op, so `seedApplied`, `version` and `seq` read off both methods exactly as
+  before. Sibling tolerances in the same file are untouched and still correct:
+  `listDrafts` reads `data?.data?.drafts` because `GET /meta/_drafts` really is a
+  dispatcher route, and `publishHealthFromResponse` unwraps because the batch
+  publish door really is enveloped. The rule is per-route, not per-file.
+- f75810e: Parse a `droppedFields` wire entry's `fields` elements and its `object` at the
+  write-warning boundary instead of asserting them.
+  
+  The structural gate checked `Array.isArray(fields) && fields.length > 0` and then
+  asserted the entry into a type declaring `fields: string[]` and a required
+  `object: string` — reading neither. A response carrying `fields: [42]` reached
+  `onWriteWarning` subscribers typed as a field name (the shell rendered it as the
+  label `42`), and an entry that omitted `object` arrived claiming a string that was
+  not there.
+  
+  Now the wire type declares only what the gate establishes, and the notice is
+  parsed: non-string `fields` elements are refused, an entry naming no field at all
+  is dropped as `fields: []` already was, and a missing or non-string `object` is
+  healed from the object the write targeted. Warnings are never silenced for a
+  field the server really did name. No published type changes — `WriteWarningEvent`
+  and `DroppedFieldsNotice` keep their shapes, and a subscriber's `fields: string[]`
+  is now true rather than asserted.
+- Updated dependencies [97abedc]
+- Updated dependencies [b46c58f]
+- Updated dependencies [ad694ac]
+- Updated dependencies [6f96fca]
+- Updated dependencies [c131d9e]
+- Updated dependencies [5f00ff4]
+- Updated dependencies [c9e073a]
+- Updated dependencies [7b395d8]
+- Updated dependencies [0879812]
+- Updated dependencies [8cedb0d]
+- Updated dependencies [6cc910b]
+- Updated dependencies [061f5e8]
+- Updated dependencies [2dd4d3f]
+- Updated dependencies [4ab4f1b]
+- Updated dependencies [e3ea4f9]
+- Updated dependencies [8b1f066]
+- Updated dependencies [af243c1]
+- Updated dependencies [961ceaa]
+- Updated dependencies [f3f4e4c]
+- Updated dependencies [a05c350]
+- Updated dependencies [8c10f4f]
+- Updated dependencies [90dac98]
+- Updated dependencies [6096f20]
+- Updated dependencies [544aca2]
+- Updated dependencies [ea02938]
+- Updated dependencies [a14fb23]
+- Updated dependencies [ae98f1d]
+- Updated dependencies [f98eddf]
+- Updated dependencies [ce6bd99]
+- Updated dependencies [a5b08c9]
+- Updated dependencies [86982ac]
+- Updated dependencies [ff14e29]
+- Updated dependencies [9b28151]
+- Updated dependencies [64563a9]
+- Updated dependencies [1a5003f]
+- Updated dependencies [8acc51b]
+- Updated dependencies [3261e64]
+- Updated dependencies [d22b37b]
+- Updated dependencies [1daf477]
+- Updated dependencies [6c2f3c5]
+- Updated dependencies [fb13e85]
+- Updated dependencies [c2d8659]
+- Updated dependencies [e0f8202]
+- Updated dependencies [c3a26cc]
+- Updated dependencies [a66e58e]
+- Updated dependencies [d89492c]
+- Updated dependencies [9a5f998]
+- Updated dependencies [9327397]
+- Updated dependencies [17cc3a3]
+- Updated dependencies [4758b33]
+- Updated dependencies [9c78ebe]
+- Updated dependencies [12809a5]
+- Updated dependencies [f9c06ef]
+- Updated dependencies [5ad3b88]
+- Updated dependencies [f9d772b]
+- Updated dependencies [97b6c21]
+- Updated dependencies [baac95a]
+- Updated dependencies [29b45f6]
+- Updated dependencies [39b8d51]
+- Updated dependencies [17b323e]
+- Updated dependencies [b956e69]
+- Updated dependencies [33e58d8]
+- Updated dependencies [256b4c9]
+- Updated dependencies [fec3b1a]
+- Updated dependencies [b8e0941]
+- Updated dependencies [0c50f18]
+- Updated dependencies [1dae95a]
+- Updated dependencies [e32dae1]
+- Updated dependencies [30b11ad]
+- Updated dependencies [4aebea0]
+- Updated dependencies [f976774]
+- Updated dependencies [3d6badf]
+- Updated dependencies [25cb364]
+- Updated dependencies [c6678b1]
+- Updated dependencies [0638322]
+- Updated dependencies [e3782d2]
+- Updated dependencies [db0beb2]
+- Updated dependencies [997ce38]
+- Updated dependencies [ae0b9d3]
+- Updated dependencies [3b469c8]
+- Updated dependencies [990a2d6]
+- Updated dependencies [6650259]
+- Updated dependencies [4f8b7f8]
+- Updated dependencies [9e6619f]
+- Updated dependencies [f6ae5e2]
+- Updated dependencies [7343376]
+- Updated dependencies [b2683a2]
+- Updated dependencies [dded788]
+- Updated dependencies [b45d463]
+- Updated dependencies [54a7830]
+- Updated dependencies [f3135a4]
+- Updated dependencies [b5696d3]
+- Updated dependencies [3f9d926]
+- Updated dependencies [e978ed5]
+- Updated dependencies [6a7f24e]
+- Updated dependencies [b3c96d6]
+- Updated dependencies [8d0ca91]
+- Updated dependencies [c30c8dd]
+- Updated dependencies [328abeb]
+- Updated dependencies [24d3e65]
+- Updated dependencies [95a7c8d]
+- Updated dependencies [e227156]
+- Updated dependencies [cc4e476]
+- Updated dependencies [92970c4]
+- Updated dependencies [d570eaa]
+- Updated dependencies [42687ba]
+- Updated dependencies [6cd8f66]
+- Updated dependencies [24a0f14]
+- Updated dependencies [797a30f]
+- Updated dependencies [b4075c0]
+- Updated dependencies [9b85600]
+- Updated dependencies [99878d8]
+- Updated dependencies [3c13675]
+- Updated dependencies [63ab761]
+- Updated dependencies [0eb9f36]
+- Updated dependencies [ae582b7]
+- Updated dependencies [db11afd]
+- Updated dependencies [154075a]
+- Updated dependencies [582edef]
+- Updated dependencies [19f484f]
+- Updated dependencies [0a78a20]
+- Updated dependencies [615346d]
+- Updated dependencies [75dcc81]
+- Updated dependencies [55a12a8]
+- Updated dependencies [edfcf5a]
+- Updated dependencies [0a3e540]
+- Updated dependencies [f61dab1]
+- Updated dependencies [b0a05dd]
+- Updated dependencies [dd5ff19]
+- Updated dependencies [81f8498]
+- Updated dependencies [a782fa7]
+- Updated dependencies [76e9df0]
+- Updated dependencies [6158e4c]
+- Updated dependencies [c27b575]
+- Updated dependencies [0e6e76b]
+- Updated dependencies [bf43afa]
+- Updated dependencies [858eafb]
+- Updated dependencies [cd5b19a]
+- Updated dependencies [17dc167]
+- Updated dependencies [20d23be]
+- Updated dependencies [20d23be]
+- Updated dependencies [e6bc087]
+- Updated dependencies [a7557a7]
+- Updated dependencies [7d074ba]
+- Updated dependencies [6158e4c]
+- Updated dependencies [6158e4c]
+- Updated dependencies [52aad5c]
+- Updated dependencies [58da8ae]
+- Updated dependencies [138ad45]
+- Updated dependencies [138ad45]
+- Updated dependencies [5262f7d]
+- Updated dependencies [6aa029b]
+- Updated dependencies [770cc5b]
+- Updated dependencies [1a88ce2]
+- Updated dependencies [a1a44d6]
+- Updated dependencies [e0a9c67]
+- Updated dependencies [5638529]
+- Updated dependencies [5638529]
+- Updated dependencies [c476be0]
+- Updated dependencies [c82ff39]
+- Updated dependencies [6c3da53]
+- Updated dependencies [31987bd]
+- Updated dependencies [3c3ce15]
+- Updated dependencies [063119f]
+- Updated dependencies [e100589]
+- Updated dependencies [304f611]
+- Updated dependencies [e46ee77]
+- Updated dependencies [f9c8c4e]
+- Updated dependencies [6e9c8d2]
+- Updated dependencies [9547063]
+- Updated dependencies [3f6efd6]
+- Updated dependencies [c4ab6d0]
+- Updated dependencies [0e9058b]
+- Updated dependencies [5988b6b]
+- Updated dependencies [00ccdf7]
+- Updated dependencies [9d9ed54]
+- Updated dependencies [ca3de72]
+- Updated dependencies [83e3f83]
+- Updated dependencies [401611b]
+- Updated dependencies [2c0ddf2]
+- Updated dependencies [4abc0aa]
+- Updated dependencies [f560ded]
+- Updated dependencies [2b188fa]
+- Updated dependencies [f68e0a0]
+- Updated dependencies [aea682a]
+- Updated dependencies [fcdc8ec]
+- Updated dependencies [2d576e4]
+- Updated dependencies [8366acc]
+- Updated dependencies [95e58a3]
+- Updated dependencies [9d7419b]
+- Updated dependencies [fc7db05]
+- Updated dependencies [9ed8d0f]
+- Updated dependencies [c73cdb5]
+- Updated dependencies [6f5719e]
+- Updated dependencies [64dae8e]
+- Updated dependencies [06a8af5]
+- Updated dependencies [6a91586]
+- Updated dependencies [a04d7c6]
+- Updated dependencies [f3c2bb0]
+- Updated dependencies [9801765]
+- Updated dependencies [9cebfca]
+- Updated dependencies [460575f]
+- Updated dependencies [d88e20f]
+- Updated dependencies [2d7304d]
+- Updated dependencies [636b236]
+- Updated dependencies [d6d8fb9]
+- Updated dependencies [64d624d]
+- Updated dependencies [053fdc8]
+- Updated dependencies [ae476b8]
+- Updated dependencies [95bad12]
+- Updated dependencies [d2fb6ef]
+- Updated dependencies [fda49e5]
+- Updated dependencies [490d9a9]
+- Updated dependencies [fc62bb4]
+- Updated dependencies [41df893]
+- Updated dependencies [0cba1b7]
+- Updated dependencies [00f3eb5]
+- Updated dependencies [1ec291c]
+- Updated dependencies [453dbaa]
+- Updated dependencies [69a2163]
+- Updated dependencies [24e027e]
+- Updated dependencies [2c3cd1b]
+- Updated dependencies [90665e0]
+- Updated dependencies [7e19d03]
+- Updated dependencies [1e946c9]
+- Updated dependencies [546ddf7]
+- Updated dependencies [864154e]
+- Updated dependencies [b023625]
+- Updated dependencies [75bd83d]
+- Updated dependencies [44d075b]
+- Updated dependencies [40c479a]
+- Updated dependencies [971d387]
+- Updated dependencies [ee851c3]
+- Updated dependencies [6414dfd]
+- Updated dependencies [a8d5c71]
+- Updated dependencies [905b21f]
+- Updated dependencies [88e9109]
+- Updated dependencies [2c45966]
+- Updated dependencies [db3a600]
+- Updated dependencies [3a3db76]
+- Updated dependencies [0d723a3]
+- Updated dependencies [0c95d3d]
+- Updated dependencies [3e4fa2c]
+- Updated dependencies [b5b928a]
+- Updated dependencies [52a43de]
+- Updated dependencies [195052f]
+- Updated dependencies [e4559d1]
+- Updated dependencies [2c71482]
+- Updated dependencies [a26b9e4]
+- Updated dependencies [5ef9c4f]
+- Updated dependencies [46f0bb4]
+- Updated dependencies [06b82b8]
+- Updated dependencies [6f81384]
+- Updated dependencies [8f1d995]
+- Updated dependencies [dddb942]
+- Updated dependencies [29754cf]
+- Updated dependencies [3c2b6f7]
+- Updated dependencies [b84dc18]
+- Updated dependencies [ac8abb0]
+- Updated dependencies [9d86e1d]
+- Updated dependencies [3a5817f]
+- Updated dependencies [99a3c2d]
+- Updated dependencies [5961030]
+- Updated dependencies [c8ea8af]
+- Updated dependencies [3190414]
+- Updated dependencies [4e480f5]
+- Updated dependencies [38a123c]
+- Updated dependencies [299102e]
+- Updated dependencies [d7acad6]
+- Updated dependencies [45a9aeb]
+- Updated dependencies [713db46]
+- Updated dependencies [bf3a03c]
+- Updated dependencies [cb55718]
+- Updated dependencies [831be72]
+- Updated dependencies [29cb85b]
+- Updated dependencies [3e028c8]
+- Updated dependencies [d0889e2]
+- Updated dependencies [ce503e5]
+- Updated dependencies [f20dcf0]
+- Updated dependencies [4ca30d0]
+- Updated dependencies [7a5da14]
+- Updated dependencies [2c1c967]
+- Updated dependencies [4d5f9b4]
+- Updated dependencies [d6ceb8d]
+- Updated dependencies [7977ff9]
+- Updated dependencies [3beef6d]
+- Updated dependencies [2acd8e1]
+- Updated dependencies [045d20b]
+- Updated dependencies [a2d2515]
+- Updated dependencies [adb2a86]
+- Updated dependencies [3619792]
+- Updated dependencies [3561bd2]
+- Updated dependencies [bf97b98]
+- Updated dependencies [b0d308d]
+- Updated dependencies [40f34b4]
+- Updated dependencies [8063bcb]
+- Updated dependencies [b74a859]
+- Updated dependencies [d4493fd]
+- Updated dependencies [240b80f]
+- Updated dependencies [77cb489]
+- Updated dependencies [bfaa158]
+- Updated dependencies [777e5c6]
+- Updated dependencies [0c386dd]
+- Updated dependencies [9e37d9b]
+- Updated dependencies [5ad86dd]
+- Updated dependencies [16a725f]
+- Updated dependencies [4dfdcc3]
+- Updated dependencies [446d93d]
+- Updated dependencies [ecd9cb2]
+- Updated dependencies [98d4108]
+- Updated dependencies [0e3b3be]
+- Updated dependencies [a29ae2d]
+- Updated dependencies [4388f71]
+- Updated dependencies [0b1ac58]
+- Updated dependencies [c93b4d5]
+- Updated dependencies [c1fe272]
+- Updated dependencies [8ad218d]
+- Updated dependencies [3e41187]
+- Updated dependencies [5f78953]
+- Updated dependencies [639114c]
+- Updated dependencies [1f31d3a]
+- Updated dependencies [351eb31]
+- Updated dependencies [20c04b2]
+- Updated dependencies [48c19bd]
+- Updated dependencies [a6d8b8d]
+- Updated dependencies [b652514]
+- Updated dependencies [adbda1b]
+- Updated dependencies [e2b3826]
+- Updated dependencies [2e32ed4]
+- Updated dependencies [e75f4c9]
+- Updated dependencies [19f1639]
+- Updated dependencies [47547d0]
+- Updated dependencies [1bee5d0]
+- Updated dependencies [858cd72]
+- Updated dependencies [cfc9b6d]
+- Updated dependencies [554f2b6]
+- Updated dependencies [669d71b]
+- Updated dependencies [ed27d7c]
+- Updated dependencies [52c8cf7]
+- Updated dependencies [2ceb43a]
+- Updated dependencies [7cdd2b9]
+- Updated dependencies [52c8cf7]
+- Updated dependencies [81a2eb1]
+- Updated dependencies [caa0cd3]
+- Updated dependencies [25c7d58]
+- Updated dependencies [00d2fa6]
+- Updated dependencies [c6198c2]
+- Updated dependencies [721d1e0]
+- Updated dependencies [1237ae4]
+- Updated dependencies [51eb515]
+- Updated dependencies [c354ce5]
+- Updated dependencies [8fe8e5c]
+- Updated dependencies [feac439]
+- Updated dependencies [efbd566]
+- Updated dependencies [9587fc9]
+- Updated dependencies [e62c44e]
+- Updated dependencies [5d0876c]
+- Updated dependencies [b041b9c]
+- Updated dependencies [ce2aaef]
+- Updated dependencies [544ecba]
+- Updated dependencies [bc640ec]
+- Updated dependencies [1e215c4]
+- Updated dependencies [da6e191]
+- Updated dependencies [3e377c9]
+- Updated dependencies [a3eb5d0]
+- Updated dependencies [4ce14f1]
+- Updated dependencies [aef97e5]
+- Updated dependencies [2af1fa7]
+- Updated dependencies [a137d0c]
+- Updated dependencies [caf477f]
+- Updated dependencies [f6375da]
+- Updated dependencies [967e5d8]
+- Updated dependencies [a4611b3]
+- Updated dependencies [20316ba]
+- Updated dependencies [d3499b3]
+- Updated dependencies [309c75e]
+- Updated dependencies [c9f9bae]
+- Updated dependencies [18897a4]
+- Updated dependencies [8b7ea39]
+- Updated dependencies [dcbf0b2]
+- Updated dependencies [52cac38]
+- Updated dependencies [93fea2e]
+- Updated dependencies [1422a92]
+- Updated dependencies [d05fe17]
+- Updated dependencies [a480f79]
+- Updated dependencies [f08d1a8]
+- Updated dependencies [64a252d]
+- Updated dependencies [786bc91]
+- Updated dependencies [75fca96]
+- Updated dependencies [7ca6ddd]
+- Updated dependencies [f1cd290]
+- Updated dependencies [5a41ce7]
+- Updated dependencies [8d50bc2]
+- Updated dependencies [604476d]
+- Updated dependencies [335abea]
+- Updated dependencies [0f5cadf]
+- Updated dependencies [4f9f1ee]
+- Updated dependencies [66e8b2a]
+- Updated dependencies [aa083cd]
+- Updated dependencies [12b5992]
+- Updated dependencies [b93e245]
+- Updated dependencies [c842594]
+- Updated dependencies [290de37]
+- Updated dependencies [8c8da45]
+- Updated dependencies [8cd8eb5]
+- Updated dependencies [cf1d29e]
+- Updated dependencies [1bd79c8]
+- Updated dependencies [af9e957]
+- Updated dependencies [c974edf]
+- Updated dependencies [ad852b6]
+- Updated dependencies [ee4d19f]
+- Updated dependencies [496d31d]
+- Updated dependencies [0ea7054]
+- Updated dependencies [9a853f2]
+- Updated dependencies [cb847fd]
+- Updated dependencies [ee70287]
+- Updated dependencies [3e98e13]
+- Updated dependencies [fc32921]
+- Updated dependencies [4eaa835]
+- Updated dependencies [8f9d87a]
+- Updated dependencies [b1777ae]
+- Updated dependencies [24845c4]
+- Updated dependencies [6f864cf]
+- Updated dependencies [24d1edd]
+- Updated dependencies [645087c]
+- Updated dependencies [33f4a19]
+- Updated dependencies [5323168]
+- Updated dependencies [841dd2b]
+- Updated dependencies [3014fc0]
+- Updated dependencies [dacb402]
+- Updated dependencies [846cec0]
+- Updated dependencies [91facae]
+- Updated dependencies [b38014e]
+- Updated dependencies [474797d]
+- Updated dependencies [704e695]
+- Updated dependencies [a407bd6]
+- Updated dependencies [317dbce]
+- Updated dependencies [3a43a15]
+- Updated dependencies [f76f436]
+- Updated dependencies [ce45a03]
+- Updated dependencies [421544b]
+- Updated dependencies [fb01022]
+- Updated dependencies [e9d9212]
+- Updated dependencies [ecfb693]
+- Updated dependencies [abc1b18]
+- Updated dependencies [81a51db]
+- Updated dependencies [67749c7]
+- Updated dependencies [507b61b]
+- Updated dependencies [512c84b]
+- Updated dependencies [fb3a101]
+- Updated dependencies [d4733f2]
+- Updated dependencies [f391ede]
+- Updated dependencies [f5cfbbd]
+- Updated dependencies [f5cfbbd]
+- Updated dependencies [8b532cb]
+- Updated dependencies [64c3cdd]
+- Updated dependencies [4d65991]
+- Updated dependencies [c42554e]
+- Updated dependencies [555b4ec]
+- Updated dependencies [1ccfc23]
+- Updated dependencies [542718f]
+- Updated dependencies [7f27bc5]
+- Updated dependencies [0a174f3]
+- Updated dependencies [f95b140]
+- Updated dependencies [541ce4e]
+- Updated dependencies [6479086]
+- Updated dependencies [d79f525]
+- Updated dependencies [d1865d2]
+- Updated dependencies [f1190b0]
+- Updated dependencies [561abef]
+- Updated dependencies [6a4680b]
+- Updated dependencies [c3a4273]
+- Updated dependencies [abf710d]
+- Updated dependencies [093af32]
+- Updated dependencies [1bd1be7]
+- Updated dependencies [d234fa9]
+- Updated dependencies [adf5812]
+- Updated dependencies [5058336]
+- Updated dependencies [2f6b2bf]
+- Updated dependencies [2028b31]
+- Updated dependencies [63601ab]
+- Updated dependencies [c372b29]
+- Updated dependencies [8693b85]
+- Updated dependencies [58b7b3d]
+- Updated dependencies [84defab]
+- Updated dependencies [681d3f1]
+- Updated dependencies [969d4f2]
+- Updated dependencies [f3bc481]
+- Updated dependencies [b79aac2]
+- Updated dependencies [93fc0e7]
+- Updated dependencies [a4b723f]
+- Updated dependencies [2b10ca0]
+- Updated dependencies [7db4a81]
+- Updated dependencies [19a0b0e]
+- Updated dependencies [526fc11]
+- Updated dependencies [f8e3e9a]
+- Updated dependencies [3b6bc69]
+- Updated dependencies [6732df4]
+- Updated dependencies [fe9e0d0]
+- Updated dependencies [63fb72c]
+- Updated dependencies [804831c]
+- Updated dependencies [279e48e]
+- Updated dependencies [8700d6d]
+- Updated dependencies [8db2a0f]
+- Updated dependencies [30443fb]
+- Updated dependencies [da45e6b]
+- Updated dependencies [835f0f3]
+- Updated dependencies [ed35b44]
+- Updated dependencies [729e851]
+- Updated dependencies [96919a4]
+- Updated dependencies [20b507a]
+- Updated dependencies [2e471dc]
+- Updated dependencies [be50942]
+- Updated dependencies [775e079]
+- Updated dependencies [7e8b3c0]
+- Updated dependencies [53374dc]
+- Updated dependencies [f6fb83f]
+- Updated dependencies [2049b03]
+- Updated dependencies [7cbc724]
+- Updated dependencies [fb91ac9]
+- Updated dependencies [8524372]
+- Updated dependencies [7cbefa5]
+- Updated dependencies [72d6587]
+- Updated dependencies [a272a4f]
+- Updated dependencies [55f39ee]
+- Updated dependencies [0970a0e]
+- Updated dependencies [e427e9c]
+- Updated dependencies [bbc9dc3]
+- Updated dependencies [02f1813]
+- Updated dependencies [ba0b61a]
+- Updated dependencies [ac716ff]
+- Updated dependencies [f0f3cd5]
+- Updated dependencies [ab856ed]
+- Updated dependencies [20f3e65]
+- Updated dependencies [bbba098]
+- Updated dependencies [87af769]
+- Updated dependencies [3be720e]
+- Updated dependencies [43c0d17]
+- Updated dependencies [c3df43a]
+- Updated dependencies [d16d0e9]
+- Updated dependencies [bbe57fd]
+- Updated dependencies [272a530]
+- Updated dependencies [1779e8d]
+- Updated dependencies [f0f4d6c]
+- Updated dependencies [4128188]
+- Updated dependencies [b253c4e]
+- Updated dependencies [78a9c67]
+- Updated dependencies [4a7ef0d]
+- Updated dependencies [dea17b4]
+- Updated dependencies [89bb77a]
+- Updated dependencies [06611e4]
+- Updated dependencies [dc3893d]
+- Updated dependencies [1bbaa16]
+- Updated dependencies [6ee259a]
+- Updated dependencies [e708426]
+- Updated dependencies [3b6d53b]
+- Updated dependencies [276d174]
+- Updated dependencies [2982ed9]
+- Updated dependencies [a8198de]
+- Updated dependencies [05a49f2]
+- Updated dependencies [a78cd37]
+- Updated dependencies [5ea623e]
+- Updated dependencies [5eabe86]
+- Updated dependencies [ca5d671]
+- Updated dependencies [32bf2d6]
+- Updated dependencies [af4fb29]
+- Updated dependencies [ff5ef1c]
+- Updated dependencies [9a97800]
+- Updated dependencies [6bca0e4]
+- Updated dependencies [81c0bc4]
+- Updated dependencies [60500cb]
+- Updated dependencies [2fcefb9]
+- Updated dependencies [b55a346]
+- Updated dependencies [065bba7]
+- Updated dependencies [6791717]
+- Updated dependencies [100547e]
+- Updated dependencies [6d1c155]
+- Updated dependencies [d7573b3]
+- Updated dependencies [bf3edfe]
+- Updated dependencies [0e05aac]
+- Updated dependencies [5aed9e4]
+- Updated dependencies [83c77dc]
+- Updated dependencies [18a8e7d]
+- Updated dependencies [e7957ab]
+- Updated dependencies [f7e34ca]
+- Updated dependencies [e719ebd]
+- Updated dependencies [516583b]
+- Updated dependencies [f9e4f91]
+- Updated dependencies [6ef48b1]
+- Updated dependencies [fa429cf]
+- Updated dependencies [ed8df3e]
+- Updated dependencies [8b446f5]
+- Updated dependencies [8e74b27]
+- Updated dependencies [8ebd57f]
+- Updated dependencies [617707a]
+- Updated dependencies [7357447]
+- Updated dependencies [199d31b]
+- Updated dependencies [3e01cb5]
+- Updated dependencies [7138bc1]
+- Updated dependencies [cef27e2]
+- Updated dependencies [4e8622b]
+- Updated dependencies [dffd752]
+- Updated dependencies [06973aa]
+- Updated dependencies [50798f3]
+- Updated dependencies [105f3c5]
+- Updated dependencies [3ccd9e8]
+- Updated dependencies [689b979]
+- Updated dependencies [e546222]
+- Updated dependencies [fd13f52]
+- Updated dependencies [fb336df]
+- Updated dependencies [0fce2ef]
+- Updated dependencies [42df928]
+- Updated dependencies [0e2ddd4]
+- Updated dependencies [b7479ab]
+- Updated dependencies [b2ea297]
+- Updated dependencies [5b5a5c3]
+- Updated dependencies [14582b8]
+- Updated dependencies [51e144e]
+- Updated dependencies [a691c0b]
+- Updated dependencies [af3861f]
+- Updated dependencies [515f171]
+- Updated dependencies [1f4e029]
+- Updated dependencies [258d264]
+- Updated dependencies [c00bf28]
+- Updated dependencies [93127bd]
+- Updated dependencies [f2158ec]
+- Updated dependencies [759606e]
+- Updated dependencies [a51fa0c]
+- Updated dependencies [51f3d8d]
+- Updated dependencies [78cbdb5]
+- Updated dependencies [b7543a9]
+- Updated dependencies [6c6cee7]
+- Updated dependencies [83fe6e7]
+- Updated dependencies [d1ab06f]
+- Updated dependencies [91783c4]
+- Updated dependencies [ca39427]
+- Updated dependencies [2d36552]
+- Updated dependencies [c9327c9]
+- Updated dependencies [920165d]
+- Updated dependencies [968dc1e]
+- Updated dependencies [3c73d99]
+- Updated dependencies [ed71d9e]
+- Updated dependencies [7776fc2]
+- Updated dependencies [e76634c]
+- Updated dependencies [1170ed1]
+- Updated dependencies [92814db]
+- Updated dependencies [4d73b07]
+  - @object-ui/core@17.7.0
+  - @object-ui/types@17.7.0
+
+## 17.6.0
+
+### Minor Changes
+
+- a8411ad: data-objectstack: retire the four remaining `v3.0.0 Deep Integration` modules — `IntegrationManager`, `SecurityManager`, the studio canvas helpers (`createDefaultCanvasConfig` / `snapToGrid` / `calculateAutoLayout`), and the contract helpers (`validatePluginContract` / `generateContractManifest`) — for having zero code consumers outside this package
+  
+  `src/index.ts`'s `// v3.0.0 Deep Integration modules` banner introduced five
+  modules. objectui#4152 / PR #4239 already retired the first,
+  `CloudOperations`, for fabricating a plausible success against a client
+  namespace that does not exist. This closes out the other four:
+  `contracts.ts`, `integration.ts`, `security.ts`, `studio.ts`.
+  
+  **Not a repeat of #4152's urgency limb.** None of these four fabricated
+  anything — `SecurityManager.generateCSPHeader()` really composes a header,
+  `snapToGrid` really snaps, `validatePluginContract` really validates. What
+  they shared with `CloudOperations` was the other limb: published surface of
+  `@object-ui/data-objectstack` with a measured **zero** code consumers outside
+  this package, across `packages/`, `apps/` and `examples/` (`.ts`/`.tsx`,
+  excluding `node_modules`). The two apparent hits on re-measurement were
+  homonyms, not consumers — `packages/plugin-designer/src/PageDesigner.tsx`
+  declares its own local `snapToGrid` callback with no import from this
+  package, and the `SecurityManager` hits outside this file are prose in
+  `CHANGELOG.md`. Under the startup-focus principle a declared capability with
+  no producer, no consumer and no business pull is retired, not kept on the
+  chance it becomes useful.
+  
+  **Breaking, in FROM → TO form.** The following are no longer exported from
+  `@object-ui/data-objectstack`:
+  
+  - `IntegrationManager` and its types (`IntegrationConfig`, `IntegrationTrigger`,
+    `IntegrationProvider`, `SlackIntegrationConfig`, `EmailIntegrationConfig`,
+    `WebhookIntegrationConfig`)
+  - `SecurityManager` and its types (`SecurityManagerPolicy`, `CSPConfig`,
+    `AuditLogConfig`, `AuditEventType`, `DataMaskingConfig`, `DataMaskingRule`,
+    `AuditLogEntry`)
+  - `createDefaultCanvasConfig`, `snapToGrid`, `calculateAutoLayout` and their
+    types (`StudioCanvasConfig`, `StudioPropertyEditor`,
+    `StudioThemeBuilderConfig`, `StudioColorPalette`, `StudioTypographyPreset`,
+    `StudioShadowPreset`)
+  - `validatePluginContract`, `generateContractManifest` and their types
+    (`PluginContract`, `PluginExport`, `PluginAPIContract`,
+    `ContractValidationResult`, `ContractValidationError`)
+  
+  It is a `minor` under this repo's version policy (objectui's own breaking
+  changes never declare `major`). Nothing broke that was working: the only
+  in-repo construction sites were this package's own `v3-compat.test.ts` (which
+  exercised the modules directly) and `spec-symbol-batch6.test.ts` (which only
+  guarded `SecurityManagerPolicy`'s name against colliding with the spec's
+  unrelated `SecurityPolicy` — that guard is removed along with its subject).
+  
+  **No compile-compat stub was left**, for the same reason #4152 left none: with
+  no consumer to keep compiling, a stub would be a second phantom surface
+  guarding the first.
+  
+  **The banner and the compat-test title stop claiming a v3.** `index.ts`'s
+  `// v3.0.0 Deep Integration modules` banner had nothing left under it once
+  these four went, so it is removed rather than retitled.
+  `v3-compat.test.ts` — titled "v3.0.0 compatibility tests for @objectstack
+  dependencies" against a resolved `@objectstack` family of `17.0.0-rc.6` even
+  before this change — is not an empty shell (one block, `PaginatedResult API`,
+  never depended on any of the five retired modules), so it stays and is
+  retitled instead of deleted.
+  
+  A negative pin
+  (`src/v3-deep-integration-retired-4241.pin.test.ts`) replaces the retired
+  `v3-compat.test.ts` cases and fails if any of the thirty retired names
+  returns — reading both the runtime export list (which catches the seven
+  class/function exports) and `index.ts`'s source text (the only instrument
+  that can catch a returning `export type`).
+
+### Patch Changes
+
+- 1ef236e: `@object-ui/data-objectstack` stops publishing its `src/` tree
+  
+  The manifest's `files` array listed `src` alongside `dist`, so every published tarball carried all 43 source files — 38 of them `*.test.ts`. It had been that way since the package's first commit (`780a1b993`), never added for a consumer, and objectui#4006 recorded the same shape without acting on it: its scope was the `*.test.d.ts` half that the build program emitted into `dist`, and its own triage note graded this half as tarball weight rather than a break.
+  
+  Nothing in the published surface reached those files, which is why no consumer changes in either direction. Measured on a cleanly rebuilt `dist`, all four ways in are closed: the `exports` map has one entry (`.`) and every condition under it targets `dist`; `main` / `module` / `types` are `./dist/index.js`, `./dist/index.js`, `./dist/index.d.ts`; the repo and the docs teach only the root specifier, and no `@object-ui/data-objectstack/src/...` deep import exists anywhere (the `src` paths in sibling `vite.config.ts` / `vitest.config.mts` files are workspace aliases resolved through `path.resolve()` against the source tree, which no `files` array shapes); and the tarball holds no sourcemap that could point back at `src`, since `tsup.config.ts` sets `sourcemap: false` and its bundled `dts` writes no `.d.ts.map` — the built `dist` contains four files, zero `.map` among them, and zero occurrences of `sourceMappingURL` or `../src/`.
+  
+  `npm pack --dry-run` across the change, on the same `dist`:
+  
+  | | before | after |
+  | --- | --- | --- |
+  | entries | 51 | 8 |
+  | unpacked | 1356830 B | 719876 B |
+  | tarball | 393379 B | 222157 B |
+  
+  43 files leave, none arrives, and every surviving entry is byte-identical apart from the edited `package.json`: `dist/index.{js,cjs,d.ts,d.cts}`, `README.md`, `CHANGELOG.md`, `LICENSE`, `package.json`. The 43 are the 38 tests plus the five modules they cover (`index.ts`, `errors.ts`, `metadata-client.ts`, `userState.ts`, `cache/MetadataCache.ts`), whose published form remains the bundled `dist/index.js`.
+- cf4f8a6: `MetadataClient.layered()` now reads the three-layer view from its declared path,
+  `GET /meta/:type/:name/layers`, instead of flagging the ordinary item read.
+  
+  The consumer half of objectstack#5882 (ruled B by the maintainer; the server half
+  landed in objectstack#6596 and shipped in `@objectstack/spec@17.0.0`). The layered
+  projection — packaged baseline vs tenant overlay vs merged effective, which is
+  what the Studio metadata editor's comparison tabs render — used to be reached by
+  hanging a query flag on `GET /meta/:type/:name`. One route therefore answered two
+  unrelated representations chosen by a query parameter, while `packages/spec`
+  declared only the unflagged one: anything generating a client from the route
+  table produced a parser that was simply wrong for the flagged call. The
+  projection now has a path of its own and a response schema of its own
+  (`GetMetaItemLayeredResponseSchema`).
+  
+  Same body, same envelope, so nothing in the editor changes shape: `code`,
+  `overlay`, `overlayScope`, `effective`, the load-time `_diagnostics` and the full
+  ADR-0010 protection envelope all still arrive on one round trip, and `?package=`
+  (ADR-0048) is still threaded — the two entry points are served by ONE handler
+  upstream precisely so the deprecation window's promise holds. The retired
+  spelling still answers during that window, marked with RFC 9745 `Deprecation` and
+  an RFC 8288 `Link: rel="successor-version"` pointing here, so this migration is
+  safe against a lagging backend for as long as the window stays open, and it is
+  what lets the maintainer close it.
+  
+  One behaviour delta rides along, and it is the server's design rather than a
+  choice made here: the retired flag FELL THROUGH to the plain item read when the
+  backend's protocol implementation had no layered support, answering the
+  `{ type, name, item }` envelope. A dedicated path refuses to answer a different
+  resource under this one's declared shape and returns 501 `NOT_IMPLEMENTED`, which
+  surfaces as a failed read instead of a comparison view whose `code` and `overlay`
+  are silently blank.
+  
+  The request is built in this package rather than delegated to
+  `@objectstack/client` because the SDK expresses no layered read in either
+  spelling — the framework's REST route ledger records the route as `server-only`,
+  "consumed by objectui over plain HTTP", and whether the SDK should express it is
+  an open upstream product call. The new path expectation is derived from the
+  installed `@objectstack/spec` route table, and a ratchet keeps any shipped source
+  file or skills guide from reaching the projection by query flag again.
+- 3d053bb: The Studio's overlay-layer badge stops printing the producer's raw scope value
+  
+  objectui#4982. `MetadataLayered.overlayScope` was typed `string | null` under a comment naming its
+  vocabulary as `organization | environment | package` — three spellings the producer has never
+  emitted. The real vocabulary lives in `@objectstack/spec`'s `GetMetaItemLayeredResponseSchema`
+  (`z.enum(['org', 'env']).nullable()`), and the framework's two assignment sites write `'org'` /
+  `'env'`. Because the declared type was `string`, no compiler anywhere had an opinion, so the wrong
+  comment was the only description of the field a reader had.
+  
+  `overlayScope` is now the spec union, derived by indexing the published response type rather than
+  restated locally (a restatement is the fork `check:spec-symbol-derivation` rejects); the alias ships
+  as `MetadataOverlayScope`.
+  
+  User-visible half: `LayeredDiff`'s overlay badge rendered that value straight to screen while the
+  sibling artifact / none / merged badges all went through `translateConsoleValue`, and
+  `CONSOLE_VALUE_ZH.layer` had no entry for either value the field can hold. One badge therefore had
+  two languages depending on the data — a zh-CN admin opening any overlaid metadata item read `org` /
+  `env`, while an un-overlaid one read 「已设」. The badge now translates like its three siblings, with
+  「组织」/「环境」 added to the layer table. That table's overlay-scope half is keyed by the spec union,
+  so a scope the spec adds later fails `type-check` until it has a label instead of quietly reaching a
+  badge in English. `translateConsoleValue` remains zh-only for every group, as before — extending it
+  to the other locale packs is a separate decision and not part of this change.
+- d871f8e: A view personalization overlay no longer freezes the view it was laid over. `ObjectView`'s
+  `persistViewPatch` sends `{ ...baseViewDef, ...patch }`, so a row written by a mere column
+  drag or sort change stored the view's whole body — its effective `filter`, `columns`,
+  `label`, `type`, `isDefault` — as of that moment, and the display merge
+  (`{ ...source, ...override }`) then let that snapshot outrank the source view indefinitely:
+  an admin edited a view's filter and everyone who had ever resized a column silently kept the
+  old filter, with nothing reporting it.
+  
+  An overlay now contributes only the keys it owns — `rowHeight`, `sort`, `hiddenFields`,
+  `columnState`, `inlineEdit` (`VIEW_OVERLAY_OWNED_KEYS`, new export from
+  `@object-ui/data-objectstack` alongside `narrowPersonalizationOverlay`) — so a later change
+  to the source view reaches every user, including those whose stored row still carries the
+  old snapshot: rows written before this change stop shadowing the source on the next read,
+  with no migration to run and nothing rewritten at rest. A genuine saved view's own body is
+  untouched — it is classified by the same predicate `listViews()` already excludes overlay
+  rows by, so a row cannot be an overlay for one reader and a saved view for the other
+  (objectui#5233, ruled on objectstack#7494).
+- a0b9e91: A system (code-defined) view's personalization overlay row no longer masquerades as a user-created saved view.
+  
+  Toggling density / sort / hidden columns / column widths / inline-edit on a code-defined view persists a row under the same `type='view'` metadata namespace a genuinely saved view lives in, keyed by the same id (`ObjectStackAdapter.updateViewConfig`). `listViews()` previously returned that row indistinguishably from a real saved view, so `ObjectView`'s `isSystem = !saved` check flipped to `false` and the tab gained Rename / Delete / Set-default / Pin against a view that lives in code — `handleDeleteView` would even call `dataSource.deleteView` on it.
+  
+  Two layers now keep the two kinds of rows apart:
+  
+  - **Write side**: `updateViewConfig` — the only production writer of personalization overlays — stamps an explicit `_isOverride: true` discriminant on every row it saves, UNLESS the write targets an already-saved view's own row (see below).
+  - **Read side**: `listViews()` excludes any row carrying that marker, and (for rows already persisted before this fix shipped) a best-effort legacy shape: a flat body with a `viewKind` the platform can only have server-side-backfilled from a registry (code-defined) baseline — a genuine runtime-created saved view never has one.
+  
+  `listViewOverrides()` (the reader `ObjectView` uses to merge these settings back into the live view for display) is unchanged — it is supposed to keep seeing overlay rows.
+  
+  The overlay this stores is **org-wide shared view settings**, not a per-user preference (a true per-user scope is a parked platform-side v18 direction) — comments describing it as "personal" have been corrected to say so.
+  
+  **Follow-up fix (same card, post-review):** `updateViewConfig`'s ONE call site (`ObjectView`'s toolbar-driven toggle) fires for a toggle on EITHER a system view OR an already-saved view — a saved view whose own toolbar the user toggles writes to that same view's own row. Stamping the overlay marker unconditionally there would flag the user's own saved view as an overlay and make `listViews()` exclude it on the very next read, i.e. the saved view would vanish from the switcher the moment its density was adjusted. `updateViewConfig` gains an optional `opts.isSavedView` parameter (also added to the `DataSource` interface in `@object-ui/types`); `ObjectView` passes it from the same `isSavedViewId` classification its readonly gate and mutating handlers already use, and the marker is withheld when it's true.
+- Updated dependencies [88085e3]
+- Updated dependencies [2533ec5]
+- Updated dependencies [bbe8b86]
+- Updated dependencies [8477be5]
+- Updated dependencies [279fb13]
+- Updated dependencies [ad07b65]
+- Updated dependencies [41f498b]
+- Updated dependencies [e1d4251]
+- Updated dependencies [1184192]
+- Updated dependencies [a2a9747]
+- Updated dependencies [ac600e5]
+- Updated dependencies [c1ef923]
+- Updated dependencies [af5e292]
+- Updated dependencies [7f96b10]
+- Updated dependencies [167ec42]
+- Updated dependencies [f1d4748]
+- Updated dependencies [b1119ec]
+- Updated dependencies [9f23d2b]
+- Updated dependencies [578e025]
+- Updated dependencies [af025ee]
+- Updated dependencies [598c89a]
+- Updated dependencies [b8b9af4]
+- Updated dependencies [31676be]
+- Updated dependencies [9ce096f]
+- Updated dependencies [e05db88]
+- Updated dependencies [5ffcc14]
+- Updated dependencies [d971e51]
+- Updated dependencies [97abb24]
+- Updated dependencies [deb157a]
+- Updated dependencies [d2ce342]
+- Updated dependencies [9695da7]
+- Updated dependencies [58b8346]
+- Updated dependencies [dfc6975]
+- Updated dependencies [3cf4de0]
+- Updated dependencies [c9dc811]
+- Updated dependencies [a0b9e91]
+- Updated dependencies [99bd015]
+  - @object-ui/types@17.6.0
+  - @object-ui/core@17.6.0
+
 ## 17.5.0
 
 ### Minor Changes