@object-ui/plugin-calendar 17.6.0 → 17.7.0

package/CHANGELOG.md

@@ -1,5 +1,2796 @@
 # @object-ui/plugin-calendar
 
+## 17.7.0
+
+### Minor Changes
+
+- 2124d04: A standalone `object-calendar` honours `navigation: { mode: 'page' }`, and a `navigation` block written without `mode`, by opening the record page (objectui#11293).
+  
+  An event click under either spelling used to open nothing on a calendar no parent view navigates for, and the `navigation` input description of the `object-calendar` and `calendar` registrations warned about it. The shared `useNavigationOverlay` now hands that click to the record navigator the host publishes, and the console publishes one on its custom pages, record pages and list views. The description drops the warning and says where `page` goes: through the host's record navigator, and nowhere under a host that publishes none. An overlay mode still keeps the click from a parent view's handlers, and any other mode still hands it to them.
+- 7c3df8f: A non-grid view's fetch now carries a platform row ceiling, and crossing it is
+  never silent (objectui#7210, maintainer ruling a′, 2026-09-02).
+  
+  Before this, `ObjectGantt`, `ObjectCalendar`, `ObjectMap` and `ObjectTree` each
+  issued a `find` with **no `$top` at all**, so the request returned the entire
+  filtered result set. At the 186 rows the card was filed from that is invisible;
+  on an object with 100k scheduled rows it is the whole table into the browser,
+  and nothing an author could write — `pagination.pageSize` included — could
+  bound a request that never carried a cap to begin with.
+  
+  **What changed.** Those four fetches now ask for `NON_GRID_ROW_CEILING_TOP`
+  rows, draw at most `NON_GRID_ROW_CEILING` of them, and when the result set was
+  larger they render a footnote naming both numbers, verbatim as it renders:
+  *"Showing the first 2000 of 41234 records. Narrow the filter."* Below the
+  ceiling nothing changes: the full set draws and no footnote appears.
+  
+  The four view packages take a **minor**, not a patch: a result set above the
+  ceiling is no longer drawn in full, which is a behaviour break whatever the
+  fixed group does to the released version number.
+  
+  **The ceiling is a platform constant, not an authorable key** — `2000`, exported
+  from `@object-ui/react` as `NON_GRID_ROW_CEILING`. An authored `limit` or
+  `dataSource: { limit }` still does not reach these queries, by the same ruling;
+  three alternatives were rejected with it (a documentation note only — still the
+  whole table; truncating at `pageSize` — silent, and a complete schedule capped
+  at one page; an authorable `maxRows` — a new permanent key every author sets).
+  
+  **Why 2,000.** One constant for all four, so the binding view sets it. Measured
+  in this repo's jsdom lane: gantt, calendar and map hold their DOM flat as rows
+  grow (virtualised task list; four events per day cell; auto-clustering above
+  100 markers), while `ObjectTree` flattens every expanded node into the document
+  at a linear **5.2 DOM elements per record** with no virtualisation. 2,000 rows
+  is where the worst of the four lands at ~10,400 elements — an order of
+  magnitude above Lighthouse's "excessive DOM size" warning, and still ~10x the
+  real application result set this card came from.
+  
+  New exports on `@object-ui/react`: `NON_GRID_ROW_CEILING`,
+  `NON_GRID_ROW_CEILING_TOP`, `applyNonGridRowCeiling`, `NonGridRowCeilingNote`
+  and the type `NonGridCeilingResult`. Two new `common.*` i18n keys carry the
+  footnote copy in all ten packs.
+- b041b9c: `@object-ui/core` publishes `resolveRecordSourceObjectName`, the ONE reader for "which
+  object is this block bound to".
+  
+  Six view plugins each spelled that resolution locally — `ObjectCalendar` twice,
+  `ObjectGantt`, `ObjectTree` twice, `ObjectMap`, `ObjectGrid` — and had drifted: three
+  wrote `?? schema.objectName`, one `|| ''`, one `: undefined`, one an `'object' in
+  dataConfig` test. They now delegate to one function that states the published
+  record-source ladder `77cb489b4` declared (`data`, then `staticData`, then `objectName`) once.
+  
+  **No behaviour changes.** Each site's pre-collapse expression is transcribed verbatim
+  into `record-source.behaviourNeutrality-7627.test.ts` and asserted equal to its
+  post-collapse spelling across the whole contract-valid input matrix — both bindings
+  present, data only, `objectName` only, empty `objectName`, empty `data.object`, the
+  `api` / `value` / `staticData` / array-shorthand providers, and nothing bound.
+  
+  **Two questions stay two questions.** `normalizeListViewSchema`'s gap-fill (#7477,
+  ruling B, landed as `00d2fa682`) is untouched and is NOT re-pointed at the new reader: it answers
+  how `objectName` gets POPULATED when absent, where an already-present `objectName` wins.
+  The new reader answers which object a block RESOLVES, where the `data` block wins — the
+  order declared on both published faces in `@object-ui/types` and pinned by
+  `objectql-record-source-refinement-6939.test.ts`. Merging them would silently override
+  one standing ruling or the other.
+  
+  **`ObjectGantt`'s `persistLayoutKey` is deliberately excluded** and keeps its inverted
+  order, with an in-place comment saying why: its receiver is a localStorage key
+  (`gantt-layout:KEY:filters`), not a record source, so re-pointing it would orphan every
+  saved layout and filter-chip set of a view carrying both bindings. Two more sites the
+  finding listed are not object-name readers at all and were struck: `ObjectGantt`'s
+  refresh-handler predicate (`object` OR `api`) and `plugin-dashboard`'s `isObjectProvider`
+  type-guard over a widget's `data`.
+  
+  `useSettledSchema`'s doc comment stops prescribing the hand-written ladder at all four
+  lines that taught it, so the copies cannot re-seed from the hook that replaced them.
+- 7ef3867: Retire the `filter.calendar` configuration spelling on `object-calendar` (objectui#7711).
+  
+  **Breaking, deliberately.** `getCalendarConfig` no longer probes `schema.filter` for a
+  `calendar` key. A calendar whose configuration was written as
+  `filter: { calendar: { startDateField: … } }` no longer resolves a configuration at all
+  and now renders the component's existing "Calendar configuration required" refusal
+  screen. Write the configuration under
+  the declared `calendar` container instead — the read for it already existed, directly
+  below the retired arm.
+  
+  `filter` is the query filter and nothing else. `@objectstack/spec`'s
+  `ComponentPropsMap['object-calendar']` declares `calendar` as the configuration
+  container and `filter` as the base query filter, and admits no `filter.calendar`
+  spelling; the renderer nevertheless read the config out of the filter FIRST, and the
+  comment on the canonical read below called *that* one the "backward compatibility"
+  branch — the contract inverted in a source comment. The arm and the comment are both
+  gone. No compatibility rung and no deprecation window, per AGENTS.md #0.1: a tolerant
+  fallback fossilizes the wrong convention into a second de-facto contract.
+  
+  **The bug this closes is not only the retired spelling.** One authored key was being
+  read twice with two incompatible meanings. `filter: { calendar: 'team' }` — a
+  legitimate condition on a field literally named `calendar` — was returned as the
+  `CalendarConfig` while the same object still went to `$filter` on the wire. `'team'` is
+  truthy, so the refusal screen did not fire either: `startDateField` destructured off a
+  string is `undefined`, every record fell into "unscheduled", and the grid rendered empty
+  while the author's declared `calendar` block sat unread. Such a filter now reaches
+  `$filter` untouched and the declared container is what configures the calendar.
+  
+  The calendar twin of the `filter.map` retirement in objectui#4034, with one measured
+  difference: there is no `Array.prototype.calendar`, so `'calendar' in schema.filter` was
+  never true for an array-shaped filter the way `'map' in schema.filter` was true for
+  every one of them. Only an object-shaped filter with an own `calendar` key ever reached
+  the retired arm, and the calendar answers the loss of a configuration with a named
+  refusal on screen rather than the map's silent fallback to default field names — so this
+  retirement carries no dev-time diagnostic rider.
+  
+  **Migration.** A census of this repo found **zero** authored `filter: { calendar: … }`
+  sites (both the object-literal and JSON spellings, with positive controls and a planted
+  fixture proving the search fires).
+  
+  Also in this change: the `calendarConfig` memo's dependency list drops `schema.filter`,
+  which the function no longer reads, and gains the three flat keys it does read but the
+  list never named — `startDateField`, `endDateField` and `allDayField`. Dropping `filter`
+  removed an accidental co-trigger that used to pick those up whenever a filter changed
+  alongside them.
+- 0ead1f6: Declare the `filter` input on every `object-kanban` / `object-calendar`
+  registration (objectui#7712) — the html tier stops reporting `unknown-prop` on a
+  key the spec declares and both renderers read.
+  
+  `ObjectKanban.tsx` sends the authored key to the query as `$filter: schema.filter`
+  and `ObjectCalendar.tsx` does the same, and `@objectstack/spec`'s
+  `ComponentPropsMap` declares `filter` on both blocks (measured: `safeParse`
+  accepts it, and refuses an undeclared key by name on the same call). But none of
+  the four registrations that publish those two renderers listed `filter` in
+  `inputs`, and `sdui-parser`'s `validateTree` reports `unknown-prop` for every key
+  no `inputs` entry claims. So an author writing the one spelling that WORKS was
+  told it was unknown — objectui#6678's shape, where a correct write draws the same
+  diagnostic as a write that does nothing. That is worse than an inert key: it
+  actively punishes the correct behaviour, and the honest response to it is to
+  delete working metadata.
+  
+  ADR-0049 enforce-or-remove resolves toward **declare**, not remove: the key has
+  live readers on both ends, so the registrations were the side that was wrong. The
+  declaration is `type: 'array'` on all four, matching the `filter` that
+  `object-grid`'s `GRID_QUERY_INPUTS` and `object-metric` already publish, and it is
+  writable as one shape only because objectui#7711 landed first and retired the
+  object-shaped `filter.calendar` spelling — `filter` is the query filter and
+  nothing else.
+  
+  Declared per key against the spec rather than derived from the
+  `ElementDataSourceMapping` sitting beside these registrations, even though that
+  mapping already asserts `filter` is a live query key. Measured, that derivation
+  would be wrong: the kanban mapping also carries `limit`, and the spec's strict
+  `ComponentPropsMap['object-kanban']` **rejects** `limit` by name, so emitting it
+  would publish a key the save gate refuses.
+  
+  ⚠️ Note for whoever meets this class next: `check:react-blocks-declaration-parity`
+  runs manifest → spec, one direction. A key the SPEC declares and the manifest
+  omits is structurally outside what that ratchet measures, so fixing these four
+  registrations does **not** make the next omission loud. Making that ratchet
+  bidirectional is its own card.
+- edea22a: **BREAKING** — `SchemaRendererProvider`'s `dataSource` prop, and the context
+  type every `useSchemaContext()` consumer reads back, are the published
+  `DataSource` contract instead of `any`.
+  
+  **FROM** `dataSource={anything}` **TO** `dataSource={adapter}` — a `DataSource`
+  from `@object-ui/types`, or `null` / `undefined` when the host has no adapter
+  bound.
+  
+  ```ts
+  // before — compiled, and failed at runtime on the first find()
+  <SchemaRendererProvider dataSource={'not-an-adapter'}>
+  // before — compiled, and no reader can do anything with it
+  <SchemaRendererProvider dataSource={{}}>
+  // after
+  <SchemaRendererProvider dataSource={adapter}>       // a DataSource
+  <SchemaRendererProvider dataSource={undefined}>     // "I have no adapter"
+  ```
+  
+  Both sites are typed `DataSource | null | undefined` — the spelling
+  `useSettledSchema` in this same package already used. The two absences are part
+  of the contract, not a weakening of it: a Studio preview, a `kind:'react'` page
+  rendered before the host's adapter connects, and a widget probe driving
+  `apiFetch` alone all render with nothing bound, and every reader in the tree
+  already guards for it. What the union refuses is everything that is not an
+  adapter: a string, an empty object, a plain data bag, a partial adapter missing
+  a required member.
+  
+  The measured cost, both halves, because the two `any`s have different blast
+  radii (measured separately on `origin/main`, whole-repo type-check over the 33
+  packages that depend on `@object-ui/react`):
+  
+  - the **context type** — the `any` that reaches every `useSchemaContext()`
+    reader — reds **7 diagnostics at 7 sites in 4 packages**, all of them
+    production code or a mocked module factory.
+  - the **provider prop** — the injection points — reds **52 diagnostics at 27
+    sites in 11 packages**, all but one of them test doubles.
+  
+  That ordering is the reverse of the prediction on the card: the context `any`
+  was expected to be the expensive one because it infects the whole tree, and it
+  is the cheap one, because every reader in the tree already guarded and none of
+  them ever reached past `find` / `getObjectSchema`. The prop is the expensive
+  one, because the injection points are overwhelmingly test doubles that were
+  never complete adapters. The full accounting is on objectui#7912.
+  
+  Two runtime behaviours change, both in the "no adapter" direction and both
+  strictly closer to what the surrounding code already intended:
+  
+  - `@object-ui/components`' `kind:'react'` page passed an empty object as its
+    "no adapter yet" stand-in. An empty object is TRUTHY, so it walked past every
+    `if (!dataSource)` guard written to catch exactly that state and failed later,
+    at the call. It now passes the absent adapter itself, so the guard fires where
+    it was meant to. The module-constant identity that stand-in existed for is
+    preserved: `null` is a primitive, so the provider's memo is unaffected.
+  - `@object-ui/plugin-calendar`, `@object-ui/plugin-gantt` and
+    `@object-ui/plugin-kanban` collapse a `null` adapter from the context to
+    `undefined` before handing it to their widget, whose prop declares the single
+    spelling `dataSource?: DataSource`.
+  
+  Nothing else moves at runtime: no value flowing through this key changes, and
+  no data path is touched. A TypeScript consumer outside this repo that handed
+  this prop something other than an adapter now gets a compile error naming the
+  key (TS2322 / TS2739 / TS2740), which is why the FROM/TO is spelled out above.
+  
+  Five `as any` reads of this context in `@object-ui/fields` are gone — they were
+  redundant the moment the seam became honest — and `LookupField`'s local
+  re-declaration of the imported context as a `Context` of `any`, which laundered
+  its `dataSource` read while looking typed, is gone with them. Both directions of
+  the contract are pinned against the real compiler in
+  `SchemaRendererContext.dataSourceType.pin.test.ts`, and the card's planted
+  documentation probe (a bare string in `packages/react/README.md`'s provider
+  example) now fails `pnpm check:doc-snippets`, where it used to exit 0 with zero
+  diagnostics.
+  
+  objectui#7912.
+- f84760f: `object-calendar` now READS the `allDayField` it already resolved (objectui#8026).
+  
+  **The defect.** `getCalendarConfig` put `allDayField` into the `CalendarConfig` it
+  returns, and the memo that builds that config named the key among its dependencies —
+  but the events pass destructured four keys and computed the flag as `!endDate`. An
+  author who wrote `calendar: { allDayField: 'is_all_day' }` therefore got the flag
+  derived from whether the record happened to carry an end date, and a record with a
+  real end date that IS flagged all-day rendered as an ordinary timed event, with no
+  diagnostic. The value was arriving: `ListView`'s `collectViewFields` already collects
+  this field into the fetch, and `ObjectView`'s `calendarViewOptions` forwards the
+  authored `calendar` block verbatim.
+  
+  **No default field name — the deliberate divergence from `calendar-view`.** The
+  sibling `calendar-view` renderer spells `schema.allDayField || 'allDay'`.
+  `object-calendar` does **not** take that default, and an unauthored `allDayField`
+  changes nothing: the existing `!endDate` inference stands, so every calendar that
+  never declared the key renders exactly as before. The sibling's five field-name
+  defaults describe the canonical authored EVENT shape a `calendar-view` node carries
+  in its `data`; `object-calendar` draws ObjectQL records of a business object, where
+  nothing makes `allDay` a field name — and this renderer honours none of those five
+  defaults, refusing rather than guessing when `startDateField` is absent
+  (objectui#7029). Importing one of the five would put the last fabricated field
+  binding back into the renderer whose refusal screen exists to refuse guessing.
+  
+  **Behaviour change, scoped.** Only calendars that DID author `allDayField` change,
+  and they change in the direction the declaration asked for. Where the key is
+  declared it is now the whole answer: a record whose flag is absent or false is not
+  all-day, because letting the inference run behind a declared key would silently
+  overrule the author.
+  
+  **Not spec surface.** `@objectstack/spec`'s `CalendarConfigSchema` is a strict object
+  of four keys and refuses `allDayField` by name — the same way it refuses objectui's
+  own sanctioned `defaultView`. The key rides objectui's deliberate `.passthrough()` on
+  the `CalendarConfig` mirror in `@object-ui/types`, whose comment names it: "the
+  renderers grow config knobs ahead of the protocol (calendar's `allDayField`, for
+  one), and stripping them here would silently disable a shipped capability." Nothing
+  in this change widens any accept set.
+  
+  **Correction, 2026-10-01 (objectui#8831).** The "Not spec surface" paragraph above is false against `@objectstack/spec` 17.5.0, which this same release installs. That release's `CalendarConfigSchema` declares five keys, `allDayField` among them, and accepts it. It still refuses `defaultView`. The key no longer rides the `.passthrough()` of the `CalendarConfig` mirror in `@object-ui/types`: that mirror derives from the spec schema, so `allDayField` is now a declared member of it. objectui#11073's bump to 17.5.0 made the paragraph false, not this entry and not objectui#8831. The paragraphs about the renderer still hold: `object-calendar` takes no default field name for `allDayField`, and a declared one is the whole answer.
+- 35e6366: Declare the `sort` input on both `object-calendar` registrations
+  (objectui#8171) — the html tier stops reporting `unknown-prop` on a key the spec
+  declares and `ObjectCalendar` already reads.
+  
+  objectui#7712's defect, one key over. `ObjectCalendar.tsx` lowers the authored
+  key onto its own query as `$orderby: convertSortToQueryParams(schema.sort)`, and
+  `@objectstack/spec`'s `ComponentPropsMap['object-calendar']` declares `sort`
+  (measured on 17.2.0: `safeParse({ objectName, sort })` returns `success: true`,
+  while the same strict schema on the same call refuses `bogusProp` by name — that
+  control is what makes the acceptance a verdict). But neither of the two
+  registrations that publish this renderer — `plugin-calendar:object-calendar` and
+  `view:calendar` — listed `sort` in `inputs`, and `sdui-parser`'s `validateTree`
+  reports `unknown-prop` for every key no `inputs` entry claims. So an author
+  writing the one spelling that WORKS was told it was unknown — objectui#6678's
+  shape, where a correct write draws the same diagnostic as a write that does
+  nothing.
+  
+  ADR-0049 enforce-or-remove resolves toward **declare**, not remove: the key has
+  live readers on both ends, so the registrations were the side that was wrong.
+  Declared `type: 'array'`, matching the `filter` entry objectui#7712 put beside
+  it and the `sort` that `object-grid`'s `GRID_QUERY_INPUTS` publishes — measured,
+  that arm is the repo-wide convention for this key, all seven existing `sort`
+  declarations write it.
+  
+  ⛔ Not derived from the `ElementDataSourceMapping` sitting six lines above,
+  which already asserts `sort: true`. That structure maps query keys for
+  `ElementDataSourceGate`; it is not an authoring declaration, and objectui#7712
+  measured why a mechanical derivation would be wrong — kanban's mapping also
+  carries `limit`, which the spec refuses by name.
+  
+  ⚠️ Carried forward from objectui#7712, because it stays true here:
+  `check:react-blocks-declaration-parity` runs manifest → spec, one direction. A
+  key the SPEC declares and the manifest omits is structurally outside what that
+  ratchet measures, so declaring this key does **not** make the next omission
+  loud. Making that ratchet bidirectional is objectui#8176.
+  
+  Rider carried by the same change, because objectui#8212 landed first: the
+  console's `registry-inputs-spec-parity` ledger is updated in step with the
+  declaration — the `object-calendar.sort` unpublished-key exemption is deleted
+  (its cover expires the moment the key is declared), the shrink-only objectui#8176
+  backlog ceiling drops 16 to 15, and `sort` gets a `MEMBER_PINS` entry rather than
+  a member-pin exemption. `MEMBER_PIN_EXEMPTION_CEILING` is untouched by this
+  change; it read 62 at the commit that wrote this paragraph (`35e63669d6`,
+  2026-09-07), and that reading is dated on purpose — see the closing note.
+  
+  ⚠️ That member pin is deliberately NOT the identity-forwarding shape the two
+  `filter` pins use. `ObjectCalendar.tsx` writes
+  `$orderby: convertSortToQueryParams(schema.sort)`, which builds a new
+  `field -> direction` map, so this key is lowered rather than passed through and
+  `toBe` on `$orderby` is false about it. The pin asserts what is READ inside a
+  member instead — `field`, `order`, an omitted `order` meaning ascending, and a
+  member with no usable `field` dropped rather than invented.
+  
+  No version bump is declared for `@object-ui/console`: its only edit here is that
+  test file's ledger data, which publishes nothing.
+  
+  ⚠️ Closing note, written while this declaration was still pending
+  (objectui#9781) — why the `MEMBER_PIN_EXEMPTION_CEILING` reading above is DATED
+  rather than corrected. The sentence was authored as
+  "`MEMBER_PIN_EXEMPTION_CEILING` is untouched at 62", and both of its halves
+  were true at `35e63669d6`: this change did not touch that constant, and 62 was
+  its value there. "Is untouched" is a closed statement about THIS change and
+  cannot rot, so it is kept as written. "At 62" is an absolute reading of a
+  SHARED constant, which somebody ELSE's change falsifies — objectui#8071 slice 1
+  (`240c605939`, 2026-09-09) lowered it 62 -> 58, and later slices of that issue
+  moved it again while this declaration sat pending.
+  
+  ⛔ The reading is deliberately NOT restated at whatever that constant reads
+  today: today's number is true today and false again at the next slice, so
+  writing it would be this same defect authored a second time. ⇒ The rule this
+  repair carries, and the line between this paragraph and every sibling changeset
+  in the family: state your OWN change's bounded transition ("lowers 62 to 58",
+  "follows 31 to 28 in the same change", "drops 37 to 33") or state that you did
+  not touch the constant, and ⛔ never state what its value currently is. The
+  first is a finished fact about something the author controlled; the second is a
+  live claim about a world the author does not.
+- 0ea7054: Remove 37 runtime dependencies that no file in the declaring package consumes, and gate
+  the direction so the next one cannot land (objectui#8198).
+  
+  `check:phantom-deps` judges imports that are not declared; nothing judged the reverse,
+  so a declaration could outlive its last consumer indefinitely. That is what happened to
+  `recharts` in `@object-ui/components` after objectui#7397 deleted its only importer — it
+  was removed by hand on objectui#7625, and nothing would have reported the next one. The
+  new `pnpm check:unused-deps` asks the reverse question over `dependencies` and
+  `optionalDependencies` of every released package.
+  
+  **Potentially breaking, for consumers relying on hoisting.** Nothing these packages ship
+  changes: their Vite `external` predicates are path-based and never read `dependencies`,
+  so no built artifact moves. What changes is the install graph — a project that imports
+  one of the removed packages while depending only on the ObjectUI package that used to
+  drag it in will no longer resolve it. Declare it directly; that is the correct
+  dependency edge in either case. The removals, by package:
+  
+  - `@object-ui/plugin-designer`: `@dnd-kit/core`, `@dnd-kit/sortable`, `@dnd-kit/utilities`, `@object-ui/fields`
+  - `@object-ui/plugin-chatbot`: `react-markdown`, `react-syntax-highlighter`, `remark-gfm` (and the orphaned `@types/react-syntax-highlighter`)
+  - `@object-ui/plugin-report`: `@object-ui/plugin-grid`, `clsx`, `react-i18next`, `tailwind-merge`
+  - `@object-ui/plugin-map`: `@objectstack/spec`, `lucide-react`, `zod`
+  - `@object-ui/runner`: `class-variance-authority`, `clsx`, `tailwind-merge`
+  - `@object-ui/core`: `lodash`, `zod`
+  - `@object-ui/layout`: `clsx`, `tailwind-merge`, and `react-dom` — which it pinned at an exact version in `dependencies` while also declaring it as a peer range, i.e. a library hard-depending on the renderer it asks its host to supply
+  - `@object-ui/plugin-dashboard`: `clsx`, `tailwind-merge`, and the same `react-dom` defect
+  - `@object-ui/plugin-ai`: `@object-ui/react`, `clsx`, `tailwind-merge`
+  - `@object-ui/fields`: `clsx`, `tailwind-merge`
+  - `@object-ui/console`: `@object-ui/react-runtime`, `sucrase`
+  - `@object-ui/auth`: `@object-ui/types`
+  - `@object-ui/plugin-calendar`: `@object-ui/fields`
+  - `@object-ui/plugin-editor`, `@object-ui/plugin-markdown`: `@object-ui/react`
+  - `@object-ui/react`: `react-hook-form`
+  
+  Every one was verified by a whole-package grep before removal — the name appeared nowhere
+  under the package but its own manifest and CHANGELOG — and the whole workspace builds,
+  type-checks and tests green afterwards.
+- 91facae: **Breaking behaviour change — a view block now honours only the `data` spelling its published row declares.**
+  
+  Maintainer ruling, decision batch #83 (2026-09-08), verbatim 「8348 以协议为准」: the contract decides. What `os validate` and the save gate refuse under `data`, the renderer refuses too. The shared record-source ladder (`resolveRecordSourceConfig` in `@object-ui/core`) now takes the arm the calling block's row declares, and rung 1 applies only on that arm.
+  
+  ⚠️ **`object-calendar` documents authored against the tolerated spelling stop rendering those rows.** The ladder falls past `data` to `staticData`, then to `objectName` — so such a calendar queries its object instead, or draws nothing when it names neither. This is accepted, with no transition window and no staged deprecation (the standing 2026-08-27 posture).
+  
+  **Per block — what the published row says, and what actually moves:**
+  
+  - **`object-calendar`** — row: `ComponentPropsMap['object-calendar'].data` is `z.array(z.unknown())` ("Pre-fetched records — skips the internal fetch"). A record-source **config object** under `data` — `{ provider: 'value', items }`, `{ provider: 'object', object }`, `{ provider: 'api', … }` — is no longer honoured, and this is a real end-to-end change: that object had exactly one carrier into the block, so an authored calendar written that way now queries its object (or draws nothing) instead of drawing the authored rows. There is no longer an api-provider branch to reach here. An **array** under `data` is unchanged, as are `staticData` and `objectName`.
+  - **`object-grid`** — row: the `ViewData` union, whose own description says "the bare-array shortcut is refused". `getDataConfig`'s `Array.isArray(schema.data)` head is removed, so the array is no longer a record source at the ladder. ⛔ Measured: this is **not** an end-to-end change for a node rendered through `SchemaRenderer`. An authored `data` array also arrives on the **props channel** (`SchemaRenderer` spreads node keys as props; `ObjectGrid`'s `passedData` lifts an array at higher priority), so such a grid still drew its rows when this landed. The removal took the second read, not the last one; objectui#9571 closed the props carrier afterwards.
+  - **`object-map`** — no `ComponentPropsMap` row existed when this landed; the governing row was this repo's own `ObjectMapSchema.data`, `ViewDataSchema.optional()` (the protocol row has since been published, and is the `ViewData` union too). Its array-shorthand head is removed on the same terms, with the same measured caveat at the time: through `SchemaRenderer` the props channel still drew an authored array, until objectui#9571. `data: { provider: 'value', items }` and `staticData` are unchanged.
+  - **`object-gantt`** — no `ComponentPropsMap` row when this landed; the governing row was `ObjectGanttSchema.data`, `ViewDataSchema.optional()` (the protocol row has since been published, and is the `ViewData` union too). A bare array under `data` is no longer a record source. Nothing observable moves: this block never lifted one, the array carried no `provider` and matched no fetch branch, and its renderer forwards no host props.
+  - **`object-tree`** — **unchanged by this change.** When it landed, no published face declared a `data` row for this block: not `ComponentPropsMap`, not `ObjectTreeSchema` (which declares `objectName` required and no `data`), not its registration `inputs`. Neither arm of the ruling reached it, so its rung 1 kept its previous behaviour and the block was reported rather than guessed at. Once the protocol published `ComponentPropsMap['object-tree']`, the tree moved to the `ViewData` arm too — see the separate `object-tree` entry for objectui#8348.
+  
+  The `data` **prop** — the pre-fetched rows a host such as `ObjectView` or `ListView` passes down — is a different carrier and is untouched on every block. That it is also reachable from an authored node key, because `SchemaRenderer` spreads node keys as props, is what limits the grid and map halves above; it is reported on objectui#8348 rather than changed here.
+- 474797d: **BREAKING** — the calendar date aliases `dateField` and `endField` are retired
+  at both faces (objectui#8355). They are now **declared refusals**: an authored
+  value is rejected **by name**, at its own key path, pointed at `startDateField` /
+  `endDateField`.
+  
+  **FROM** `calendar: { dateField, endField }` — accepted in silence, read by
+  `ObjectCalendar`'s alias ladder — **TO** a by-name refusal at validation, with
+  `startDateField` / `endDateField` as the only spellings that bind the axis.
+  
+  ```ts
+  // before — parsed green, drew a calendar
+  { type: 'list-view', objectName: 'task', calendar: { dateField: 'kickoff', endField: 'wrapup' } }
+  // after  — refused at validation, naming the canonical keys
+  { type: 'list-view', objectName: 'task', calendar: { startDateField: 'kickoff', endDateField: 'wrapup' } }
+  ```
+  
+  **The refusal an author now meets**, verbatim from the arms' own messages (one
+  string per arm feeds both the parse-time issue and the `.describe()` metadata):
+  
+  ```text
+  Unrecognized key(s) on this calendar configuration: `dateField`. Did you mean
+  `dateField` → `startDateField`? `dateField` and `endField` are the pre-#2231
+  objectui spellings of the calendar date axis, retired at both faces by
+  objectui#8355. `@objectstack/spec` spells the axis `startDateField` and
+  `endDateField` only. ⚠️ This package accepted BOTH legacy spellings green until
+  that retirement — they rode a `.passthrough()` straight through
+  `safeValidateSchema` into `ListView`'s calendar branch, which flattened them onto
+  the generated `object-calendar` node where the renderer's alias ladder read them.
+  That ladder is gone, so the key is refused here instead of being kept and then
+  ignored. Write `startDateField` for the event start. Kept rather than refused, an
+  authored `dateField` binds nothing: the calendar falls through to "Calendar
+  configuration required", a screen that names the canonical keys and never the key
+  you wrote.
+  ```
+  
+  ⚠️ **The consequence clause is per key, because the two spellings fail
+  differently.** `endField` gets the same stem and this tail instead — measured on
+  the renderer, not assumed:
+  
+  ```text
+  …Write `endDateField` for the event end. Kept rather than refused, an authored
+  `endField` fails even more quietly than its sibling: a calendar that also carries
+  a start binding still DRAWS, and only the end of every event is silently dropped.
+  ```
+  
+  On the flat node face the surface noun is `this object-calendar node`. ⚠️ **The
+  element's own `calendar` container carries a different tail for `dateField`**,
+  because it fails differently and was measured doing so: `getCalendarConfig` reads
+  that container WHOLE, so a retired spelling there never reaches the refusal
+  screen — the calendar mounts and simply places nothing, every record landing
+  under "Unscheduled". `endField` keeps one clause, because it reads the same on
+  both.
+  
+  ```text
+  …Write `startDateField` for the event start. Kept rather than refused, an
+  authored `dateField` fails without even reaching that refusal screen: this
+  container is read WHOLE, so the calendar still mounts and simply places nothing —
+  every record ends up under "Unscheduled" with no date to draw it on.
+  ```
+  
+  **ADR-0087 disposition — D2 tombstone, no conversion entry and no migration
+  prescription.** The keys stay DECLARED and unwritable rather than being deleted,
+  which is the whole of the ruling: every calendar block here ends `.passthrough()`
+  and `BaseSchema` does too, so a deleted key is not refused — it is KEPT
+  unexamined and then ignored. Nothing in `@objectstack/spec` converts these two
+  (the protocol never declared either: `CalendarConfigSchema` is a strict object of
+  `startDateField` / `endDateField` / `titleField` / `colorField`, measured on the
+  installed pin 17.4.0 with a nonsense-key control on the same call), so there is
+  no ledger entry to register and no `objectstack migrate meta` step to ship. The
+  channel that reaches an author is the validator, and it now names the key and the
+  remedy on all five authoring surfaces this vocabulary has: a list view's
+  `calendar` block and its legacy `options.calendar` twin, a named view's two
+  nestings under `listViews`, the flat `object-calendar` node face, and that
+  element's own `calendar` container. ⚠️ Stated as five surfaces rather than
+  "every author" on purpose: a host that builds the node in TypeScript and hands it
+  to `SchemaRenderer` never parses the mirror at all — `SchemaRenderer` runs the
+  structural core validator, which is dev-only and names no key — so the compiler
+  is that population's channel, not this one.
+  
+  ⚠️ **Dated note, 2026-09-28 — a named view's `options.calendar` nesting is no longer
+  judged inside — objectui#7928.** Later in this same release `ObjectViewSchema.listViews`
+  became the protocol's strict `ObjectListViewSchema` record, by reference, and that
+  record refuses a named view's `options` bag whole (`unrecognized_keys` at
+  `listViews.KEY`, naming `options`). So an alias written under
+  `listViews.KEY.options.calendar` no longer draws an issue naming the key or the remedy.
+  The named view's `calendar` block still does: the protocol refuses the alias there as an
+  unrecognized key, and this entry's check adds the pointer at the key beside it. A stored
+  body that `@object-ui/app-shell`'s `ViewPreview` relays has its `options.calendar` folded
+  onto the `calendar` block first (`foldStoredListOptions`). The list view's two nestings
+  and both `object-calendar` surfaces are unchanged; `calendar-date-alias-refusal-8355.test.ts`
+  in `@object-ui/types` re-derives each surface. `.changeset/7928-listviews-by-reference-fold.md`
+  (PR objectui#10821) states what ships; the text above is kept as the reading of this change.
+  
+  ⚠️ **Why this is `minor` and not `major`.** This repository forbids `major` in a
+  changeset: the fixed release group's major tracks `@objectstack`'s, so any
+  `major` here would push all of it off that cadence
+  (`scripts/check-changeset-no-major.mjs` enforces it). objectui's own breaking
+  changes ship as `minor` with the break spelled out, which is what this entry is.
+  
+  **What broke silently before, and why the two halves ship together.** An earlier
+  attempt removed the renderer's alias ladder on its own. The producer kept
+  spreading the authored block flat onto the generated `object-calendar` node, so
+  the alias still arrived, nothing read it, and the author met a generic "Calendar
+  configuration required" screen naming keys they had not written. A live authoring
+  path stopped rendering with every gate green (recorded on objectui#8651). The
+  refusal at the declaration is what turns that silence into a loud, by-name
+  failure — so the ladder removal, the producer strip and the tombstones are one
+  change and must stay one.
+  
+  **The four moving parts:**
+  
+  - `@object-ui/types` — `aliasKeyRefusal()` arms on the view-level `calendar`
+    block, on the legacy `options.calendar` nesting (a check, since an open record
+    declares no member — `custom` there, `invalid_type` at the declared slot), on
+    the flat `object-calendar` node face, and on that element's own `calendar`
+    container; plus a `.check()` on `ObjectViewSchema` for a named view's two
+    nestings. `z.input` of each arm is `undefined`, so the TypeScript face carries
+    `dateField?: never` / `endField?: never` and `tsc` refuses the key at the
+    authoring site as well.
+  - `@object-ui/plugin-calendar` — `getCalendarConfig` reads the declared
+    spellings only; the `CalendarAliasRungs` cast target and both read sites are
+    gone, and the config memo's dependency list loses the two entries with them.
+  - `@object-ui/plugin-list` — the `calendar` branch destructures the two
+    spellings out of the merged block and spreads only the remainder onto the node,
+    exactly as the kanban branch strips its own stray `groupBy` (objectui#8365).
+  - `@object-ui/plugin-view` — **the SECOND route**, and the reason this entry
+    moved four packages rather than three. `generateViewSchema` runs when no host
+    supplied `renderListView` — the authored `object-view` element — so a named
+    view never passes through `ListView`. Its calendar branch spread the authored
+    block raw, so removing the renderer's ladder turned a document that DREW into
+    one that shows "Calendar configuration required" and nothing else. Measured end
+    to end before the fix was written. It now strips the two spellings like its
+    sibling, and the `ObjectViewSchema` check is what makes an authored alias loud
+    there instead of mute.
+  
+  ⚠️ **`ObjectViewSchema.listViews` stays UNMIRRORED, and this entry does not
+  change that.** That key waits on a maintainer decision about its VALUE TYPE —
+  neither the spec's strict `ObjectListViewSchema` nor the local `NamedListView`
+  can be the declared value without losing documented behaviour or enforcing 43
+  unread members. A `.check()` decides none of it: it declares no value type, puts
+  no key in the object's `shape`, requires no `columns`, and refuses neither an
+  undeclared key nor the legacy `options` bag. It judges exactly the two spellings
+  this entry retires, at the two nestings the producer merges — with pins on each
+  of those non-effects.
+  
+  ⚠️ **Dated note, 2026-09-28 — `listViews` has since been mirrored — objectui#7928.** Later
+  in this same release the maintainer's ruling A chose the value type this paragraph waits
+  on: `ObjectViewSchema.listViews` is now `@objectstack/spec`'s own
+  `ViewSchema.shape.listViews`, a record of the strict `ObjectListViewSchema`, by reference
+  on both faces. It is in the object's `shape`, a named view needs `columns`, and the
+  record refuses an undeclared key and the legacy `options` bag whole. The named-view check
+  described here and in the `@object-ui/types` bullet above now reads the protocol's own
+  refusal at `listViews.KEY.calendar` and adds the pointer at the key; it no longer walks
+  the `options.calendar` nesting, so "a named view's two nestings" and "at the two nestings
+  the producer merges" now hold for the `calendar` block only.
+  `.changeset/7928-listviews-by-reference-fold.md` (PR objectui#10821) states what ships;
+  the text above is kept as the reading of this change.
+  
+  ⛔ **Not a producer-side fold.** Normalising `dateField` to `startDateField` in
+  `ListView` (option A) was put to the director seat and refused as the end state:
+  it keeps a second spelling alive at the producer, which is the lenient alias
+  AGENTS.md #0.1 names. The aliased view therefore produces **no** date binding,
+  and the author is told why at the door instead.
+  
+  ⚠️ **Upstream's refusal suggests the wrong canonical key for `dateField`, and it
+  is a typo-distance suggester rather than a declaration.** Re-derived by running
+  the installed pin (`@objectstack/spec` 17.4.0), with controls in the same pass:
+  `CalendarConfigSchema`'s `strictObject` options carry `surface` and `history` and
+  no `aliases` entry, so the protocol declares nothing about either spelling. The
+  "Did you mean `dateField` → `endDateField`?" an author meets is a fallback
+  `findClosestMatches` Levenshtein suggestion budgeted `max(2, floor(len/3))`:
+  `endDateField` is 3 edits from `dateField` and inside its budget of 3, while
+  `startDateField` is 5 and outside it — and `endField`, budgeted 2, reaches
+  nothing, which is why it and a nonsense control key both draw no suggestion at
+  all. A one-character typo of the canonical key does resolve to `startDateField`,
+  so the suggester is working as designed; it simply has no opinion to offer about
+  a legacy alias.
+  
+  ⇒ **nothing upstream says `dateField` means the end of an event.** The hazard is
+  author-facing rather than contractual: someone who copies that suggestion writes
+  `endDateField` and binds the END of an event to the date they meant as the START,
+  which every layer accepts. Every objectui read site folds this spelling onto the
+  **start** — the retired ladder did, `normalizeListViewSchema`'s `timeline` fold
+  does, `resolveTimelineDateBinding` documents it as "the pre-#2231 alias for
+  `startDateField`", and this package has published "Deprecated alias for
+  startDateField" for releases. So these arms name `startDateField` and a control
+  pin holds that line. The remedy upstream needs is an explicit `aliases` (or
+  `guidance`) entry for the two spellings so the suggester never answers for them;
+  that is upstream's formatter, on upstream's card, and is not fixed here.
+  
+  ⛔ **The timeline alias is NOT retired by this change.** `timeline.dateField`
+  stays a live, accepted alias with live consumers (`normalizeListViewSchema` folds
+  it onto `startDateField`, `ObjectView` reads it, and app-shell pins that it still
+  renders). The card's own boundaries put the map / gantt / timeline / kanban
+  ladders on their own cards; a pin in `@object-ui/types` asserts the timeline
+  spelling still parses green, so a later sweep has to say so rather than carrying
+  it in silently.
+  
+  **Pinned** by `calendar-date-alias-refusal-8355.test.ts` (`@object-ui/types`, all
+  five surfaces, the per-surface consequence split, the compile-time face, and the
+  structural guard that `listViews` stays out of the object's `shape`),
+  `ListView.calendarAliasRefused-8355.test.tsx` (`@object-ui/plugin-list`) and
+  `ObjectView.calendarAliasRefused-8355.test.tsx` (`@object-ui/plugin-view`) — both
+  reading the node their producer really emits through a spy registration, which is
+  the only census that can see a key arriving through a spread — and the inverted
+  ledger rows in `calendarUnionReads-8651.test.tsx` (`@object-ui/plugin-calendar`).
+  
+  ⚠️ **Dated note, 2026-09-28 — a named view now refuses `timeline.dateField`, and the
+  shape guard is inverted — objectui#7928.** Later in this same release the protocol's
+  strict named-view record refuses `timeline.dateField` on a named view as an unrecognized
+  key; the `list-view` route still accepts it, and that route is the one the timeline pin
+  reads. The structural guard in `calendar-date-alias-refusal-8355.test.ts` now asserts
+  the opposite of "`listViews` stays out of the object's shape": `listViews` is a member
+  of `ObjectViewSchema.shape`. `.changeset/7928-listviews-by-reference-fold.md` (PR
+  objectui#10821) states what ships; the text above is kept as the reading of this change.
+- d79f525: `navigation` is declared on the `object-kanban` and `object-calendar` blocks, by reference to `@objectstack/spec` (objectui#8652). This is the objectui half of the maintainer ruling on that card: the spec declares the key on both element entries from 17.5.0, and objectui now mirrors it.
+  
+  - `@object-ui/types`: `ObjectKanbanSchema.navigation` and `ObjectCalendarSchema.navigation` are declared on both published faces with the spec's `NavigationConfig` type — the same type the grid, view, gantt and map schemas use. Until now the key was admitted and never examined: `navigation: { mode: 'not-a-mode' }` passed both faces while the spec refused it. It is now refused at `navigation.mode`, and a member the spec does not declare inside the block is refused too. A parse adds no default to the block, so a board or calendar without the key still opens a record in a drawer.
+  - `@object-ui/plugin-kanban`: the `object-kanban` registration publishes `navigation` in its `inputs`, so the designer offers it.
+  - `@object-ui/plugin-calendar`: the `object-calendar` and `calendar` registrations publish `navigation` in their `inputs`, and `ObjectCalendar` reads the key without a cast.
+  
+  What a click does with each member is unchanged. `page`, and a block written without `mode` (which resolves to `page`), open the record page through the record navigator the host publishes (objectui#11293); under a host that publishes none, such as an embedded renderer, they still open nothing. The published input descriptions say so.
+- a984600: Honour `filter`, `sort` and the platform row ceiling on a calendar's and a map's
+  inline (`provider: 'value'`) data (objectui#9061) — the port of objectui#8769's
+  repair off `ObjectGantt`.
+  
+  **The defect was fail-open.** Both renderers' fetch effect short-circuited the
+  inline provider: it set the authored rows and returned BEFORE the adapter query,
+  which is the one site in each file that lowers `schema.filter` to `$filter`,
+  `schema.sort` to `$orderby` and the objectui#7210 ceiling to `$top`. So an
+  inline calendar or map that declared a `filter` drew **every** authored row, with
+  no diagnostic. The key that was dropped is the key that NARROWS, which is why
+  this matters: the view answered a wider question than the author asked. Nothing
+  was exposed that was not already in the authored schema — this is a correctness
+  defect, not a data-access one.
+  
+  **What changed.** Each renderer resolves a `ValueDataSource` for the inline
+  provider and issues the same query the `object` arm issues. The `api` arm is
+  untouched, and no dependency array moves. `ValueDataSource` already implements
+  `$filter` / `$orderby` / `$skip` / `$top` / `$select` over its own array, so no
+  filter combinator was written for this change.
+  
+  **Behaviour you may notice.**
+  
+  - An authored `filter` / `sort` now narrows and orders inline rows. Every
+    spelling reaches it: `data: { provider: 'value', items }` and `staticData` on
+    both renderers, plus the map's bare-array `data` shorthand.
+  - The row ceiling now applies to inline rows: past 2,000 drawn rows the view
+    draws 2,000 and shows the footnote naming both numbers, as it already did for
+    fetched rows. It is applied to the **filtered** set, so a large inline array
+    that a `filter` cuts below the ceiling draws every matching row and stays
+    quiet. Rows a host passes down through the `data` React prop are still never
+    capped — those are not ours to cap.
+  - Inline rows now reach the view as the adapter's own deep copy rather than as
+    the authored array's object identities. Code comparing a row handed to
+    `onEventClick` / `onMarkerClick` against the authored array with `===` needs
+    `id` equality instead.
+  - That copy is a JSON round-trip, so inline rows must be JSON-serializable.
+    A record graph carrying a back-reference, or a `BigInt` id, now renders an
+    error panel instead of the view. `ObjectGantt` has refused the same input
+    since before objectui#8769; `ObjectMap` did not, and pinned that it need not
+    (objectui#6018). ⚠️ That pin is left RED and untouched in this change — see
+    the pull request body.
+- 7098eed: One record-overlay shell: all five list-type renderers honour all four overlay
+  `navigation.mode` values (objectui#9299, director seat decision batch #128 item
+  1, 2026-09-13).
+  
+  `ObjectGantt`, `ObjectKanban` and `ObjectCalendar` rendered one drawer for every
+  authored mode — `modal`, `split` and `popover` silently WERE the drawer, with no
+  diagnostic. `RecordDetailDrawer`'s payload is extracted into the new
+  `RecordDetailPanel` (shell-free by construction) and mounted through the shared
+  `NavigationOverlay`, which is what `ObjectGrid` and `ObjectTree` already used.
+  
+  User-visible on published surfaces:
+  
+  - **`modal` / `split` / `popover` now do what they say** on the gantt, the
+    kanban and the calendar.
+  - **`split` renders.** Each renderer passes its own view as `mainContent`, so
+    the board / calendar / chart / tree / grid sits beside the record panel.
+    Authored `split` used to render NOTHING on `ObjectTree` — and, measured while
+    fixing this, on `ObjectGrid` too.
+  - **`popover` is anchored to the element the user clicked** — row, node, bar,
+    card, event — instead of degrading to a centred dialog. It was honoured on no
+    surface before.
+  - **Drawer chrome converges** on the shared shell's header (breadcrumb title,
+    close, optional expand) for the three renderers that brought their own.
+  - **Drawer widths carry over, they are not reset.** The two drag-resize
+    implementations become one: a width persisted under the retired
+    `objectui.drawerWidth.OBJECT` is read once, written forward to
+    `ov:drawer-width:OBJECT` and removed. One key per object across every view
+    type. The default width is unchanged at every viewport (objectui#6584); an
+    authored width below `min(60vw, 880px)` now widens to it, which is the shell's
+    long-standing policy on grid and tree.
+  - **Richer record body on grid and tree** — typed widgets, declared labels,
+    honoured `hidden` — wherever the object declares its fields. With nothing
+    declared those two renderers keep their own value-inference reading, which is
+    what preserves the locale-aware date fallback (objectui#4541), the localized
+    empty placeholder (objectui#8491) and the `format` hint (objectui#8920); the
+    overlay shell is the shared one on that path too.
+  
+  New published API: `RecordDetailPanel`, `buildRecordDetailFields`,
+  `RECORD_OVERLAY_DEFAULT_WIDTH` (`@object-ui/plugin-detail`);
+  `useOverlayAnchor`, `recordOverlayWidthStorageKey`,
+  `legacyRecordDrawerWidthKey` and the `popoverAnchorRef` / `legacyStorageKey`
+  props on `NavigationOverlay` (`@object-ui/components`). `RecordDetailDrawer`
+  keeps its props and is now a thin wrapper over the shared shell. ⛔ No spec
+  change.
+- 502eb58: The row/card click props on the view components now declare the modifier
+  payload they have always been invoked with (objectui#9357).
+  
+  `useNavigationOverlay`'s `handleClick` invokes the handler it is given with two
+  arguments — the record, and an optional modifier payload (`metaKey` / `ctrlKey`
+  / `button`) a host needs to implement Cmd/Ctrl/middle-click. objectui#9360 made
+  the hook's own option say so. These components pass a host-supplied prop
+  straight into that option, so the value a host writes against them is invoked
+  with two arguments too — and every one of these props declared only the record.
+  The payload was therefore invisible on the one line a host reads, exactly as it
+  had been on the hook.
+  
+  Thirteen declarations across nine packages now name both parameters:
+  
+  - `ObjectGridComponentProps.onRowClick`
+  - `ObjectKanbanComponentProps.onRowClick` (its sibling `onCardClick`, the other
+    arm of the same fallback, already declared both)
+  - `KanbanRendererProps.schema.onCardClick`
+  - `ObjectCalendar`, `ObjectGantt`, `ObjectMap`, `ObjectTree`: `onRowClick`
+  - `ObjectTimeline`: `onRowClick` and `onItemClick`, the two arms of one fallback
+  - `ListView.onRowClick`
+  - `ObjectGallery`: `onRowClick` and `onCardClick`, likewise two arms of one
+  - `RelatedList.onRowClick`
+  
+  **Source-compatible, and with no refused class.** A one-parameter handler is
+  still assignable to the widened signature, and a handler written against the
+  widened signature was already assignable to the narrow one — its minimum
+  argument count is still one. The second parameter is spelled `any` rather than
+  `HandleClickModifiers`, which is the difference that matters for callers: the
+  hook's own option names that interface and therefore refuses a handler whose
+  second parameter is annotated narrower (objectui#9360 documents that class and
+  the one-line remedy). These faces refuse nothing. A host that discovered the
+  payload from the implementation and annotated it `React.MouseEvent` — which is
+  what actually arrives — keeps compiling. `any` is also the spelling
+  `ObjectKanbanSchema.onCardClick` already carries for this same payload
+  (objectui#9341) and the one `BaseSchema`'s own `onClick` / `onChange` /
+  `onSubmit` use, and it is forced on the published twins in `@object-ui/types`,
+  which may not name a type that lives in a package depending on them.
+  
+  **Runtime behaviour is unchanged.** Nothing is newly called and nothing newly
+  passes an argument; only the declarations move.
+  
+  Three declarations that share the name and the shape are deliberately NOT
+  widened, because the value flowing through them is not invoked with the
+  payload: `VirtualGrid.onRowClick`, whose second parameter is a row index;
+  `ManageViewsDialog.onRowClick`, which receives a view id; and the `data-table`
+  family (`DataTableSchema.onRowClick`, `ObjectDataTableSchema.onRowClick`),
+  whose renderer invokes with one argument. Widening those would have declared a
+  payload that never arrives.
+- ab856ed: **`resolveRecordSourceConfig`'s `data` parameter now follows the arm it is already told, instead of contradicting it.**
+  
+  The shared record-source ladder in `@object-ui/core` takes a REQUIRED `dataArm` argument precisely because blocks declare `data` differently — its own docblock says there is no repo-wide default, "because the answer differs per block and a default is how the second de-facto contract got in" (ruling objectui#8348, decision batch #83, 「8348 以协议为准」). Its parameter nevertheless declared a flat `data?: ViewData` — a discriminated union over four strict OBJECT arms, with no array member — while its rung-1 predicate `authoredDataIsOnTheDeclaredArm` takes `unknown` and admits an ARRAY on the `'array'` arm. The declaration contradicted the contract the same function documents and implements.
+  
+  The `data` member is now `AuthoredRecordSourceData<Arm>`, a new exported conditional type keyed on the arm:
+  
+  - `'view-data'` → `ViewData`. **Unchanged** — this is what the flat declaration said, and it was right for the three blocks on this arm (`object-grid`, `object-map`, `object-gantt`).
+  - `'array'` → `unknown[]`, the shape `ComponentPropsMap['object-calendar'].data` declares (`z.array(z.unknown()).optional()`, "Pre-fetched records").
+  - `'undeclared'` → `unknown`, since no published face declares a `data` row for such a block and rung 1 keeps its pre-8348 verbatim behaviour there.
+  
+  ⚠️ **Type-level only — no runtime accept set moves.** Nothing in the ladder's body changed: `authoredDataIsOnTheDeclaredArm` still takes `unknown` and still decides rung 1 on the value's KIND, so every resolved config — including the off-arm ones that fall through to `staticData` and then `objectName` — is what it was. The emitted JavaScript of both packages is unchanged by this card.
+  
+  ⚠️ **One compile-time refusal is new**, and it is the half that keeps this from being a mere widening: a caller that declares a `ViewData` provider block under `data` while passing `'array'` no longer type-checks. That document was already refused at runtime by objectui#8348, and by `os validate` and the save gate before that; only the signature still accepted it. A caller that holds the arm as a `RecordSourceDataArm` variable rather than a literal is unaffected — the conditional type distributes to `unknown` there, which a set of literal-armed overloads would not have done.
+  
+  `@object-ui/plugin-calendar` loses the cast that stood in for the missing declaration: `ObjectCalendar`'s ladder call passed `data: schema.data as ViewData | undefined`, in a comment reporting an upstream defect in `@object-ui/core`. The three members are still passed one by one — they are what the ladder documents itself as reading — but the member is now `data: schema.data`, and `packages/plugin-calendar` type-checks green without the assertion.
+  
+  Two stale docblock passages in `record-source.ts` and `record-source-config.behaviourNeutrality-7632.test.ts` explained `ObjectCalendar`'s retired `'data' in schema` guard by the props union `ObjectGridSchema | CalendarSchema`, which objectui#8651 retired — `ObjectCalendarComponentProps.schema` is the published `ObjectCalendarSchema` today. Both now say that the clause is history rather than a reading anyone can re-derive from `main`.
+- 51e144e: fix(plugin-calendar): type `ObjectCalendar` at the published `object-calendar` schema, and declare the `calendar` container
+  
+  `ObjectCalendarComponentProps.schema` was the union `ObjectGridSchema | CalendarSchema` — a grid's schema, plus a plugin-local interface absent from this package's barrel. Neither arm is the schema of the element this renderer is registered as. Measured with the TypeScript checker: of the fifteen keys the renderer reads off the node, seven were undeclared on that union and had to be read through a cast, while five more resolved only through `ObjectGridSchema`'s index signature and were therefore typed `any` — admitted, never examined. `ObjectCalendarSchema` already declared eleven of the fifteen.
+  
+  - `ObjectCalendarComponentProps.schema` is now `ObjectCalendarSchema`. **Breaking for a React host that passed an `object-grid` node or a `type: 'calendar'` literal to `ObjectCalendar`** — neither was ever a node this renderer is registered for. `ObjectCalendarProps`, the deprecated alias, follows it.
+  - `ObjectCalendarSchema.calendar` is declared on both published faces. The spec declares the KEY; it does **not** declare its shape — `ComponentPropsMap['object-calendar'].calendar` is `z.unknown().optional()` and accepts anything at that position — so the member list is objectui's own: the four `CalendarConfigSchema` names plus objectui's `allDayField`, which is what the renderer reads out of the block. The container keeps `.passthrough()`, so no KEY that parsed before is refused — an unexamined key inside the block still parses, and so do `calendar.dateField` and `calendar.defaultView`. What is new is VALUE validation: `calendar: 42` and `calendar: { startDateField: 42 }` are refused where both were admitted unexamined.
+  - `@object-ui/types` now exports the type `ObjectCalendarBlockConfig`, so that published member has a name an importer can write.
+  - ⚠️ The `dateField` / `endField` alias rungs in `getCalendarConfig` are **kept**, and routed to the producer. An earlier revision of this change retired them on a census that was false: `ListView` flattens an authored `calendar` block onto the node it emits, and `resolveTimelineDateBinding` in that same file documents `dateField` as the pre-#2231 alias for `startDateField` and honours it — so a view authored that way renders today and would have drawn "Calendar configuration required". (objectui's own `ListViewSchema` also accepts `calendar.dateField`, but only weakly: that block is `.passthrough()` and admits nonsense too, so the load-bearing half is the producer and the read site, not the accept.) No behaviour changes for either spelling. The alias question already has a carrier — objectui#8355, open and undecided — and the producer-side remedy belongs in `ListView`'s calendar branch.
+  
+  **Correction, 2026-10-01 (objectui#8831).** Two statements in this entry are false against the tree this release ships, for two different reasons.
+  
+  - "the four `CalendarConfigSchema` names plus objectui's `allDayField`": `@objectstack/spec` 17.5.0, which this same release installs, declares all five on `CalendarConfigSchema`, so the container's members are the spec's five. objectui#11073's bump made this false, not this entry and not objectui#8831. What the same bullet says about the spec at this position still holds on 17.5.0: `ComponentPropsMap['object-calendar'].calendar` declares the key but not its shape, and accepts `calendar: 42`.
+  - "and so do `calendar.dateField`", and the ⚠️ bullet's "The `dateField` / `endField` alias rungs in `getCalendarConfig` are **kept**": objectui#8355 retired both rungs in this same release. `getCalendarConfig` no longer reads either spelling, and the container refuses `calendar.dateField` and `calendar.endField` by name (see objectui#8355's own entry). objectui#8355 made these false, not objectui#11073 and not objectui#8831. An unexamined key and `calendar.defaultView` still parse inside the block, and the value validation this entry adds (`calendar: 42` and `calendar: { startDateField: 42 }` are refused) still holds.
+
+### Patch Changes
+
+- afb2284: `ObjectCalendar`'s user-visible copy now reaches the locale packs. The component
+  was already i18n-aware — it imports and calls both translation hooks — and a set
+  of English sentences sat beside those calls as literals, so a non-English session
+  read a half-translated calendar: the unscheduled label and the two write-failure
+  toasts in its own language, and the loading screen, the error screen, the refusal
+  screen, the pull-to-refresh affordance, the whole quick-create dialog and the
+  record overlay's fallback title in English (objectui#10031).
+  
+  Every one of those now reads a key. Two of them reuse keys the packs already
+  carried (`common.cancel`, `common.create`), one reuses `calendar.newEvent`, and
+  twelve are new under `calendar.`.
+  
+  **The hook is chosen per site by one criterion, which the file already stated for
+  its existing call:** `useSafeTranslate`'s `tt(key, fallback)` passes no options to
+  i18next and therefore cannot fill a hole, so the two sentences that carry one —
+  the error prefix and the quick-create date line — read their key through
+  `useObjectTranslation`'s `t()` with an inline default, and every hole-free string
+  uses `tt()`.
+  
+  **⚠️ A key added to `en` is not an `en`-only change in this repo**, and that is
+  worth stating because the cheap route looks available: the English fallback does
+  carry the English text at the call site, but the key-set invariant is a
+  pack-vs-pack one — every pack defines every `en` key — so it is answered by the
+  locale packs, not by the call site. All ten packs therefore carry the twelve new
+  keys, with real translations rather than the English value. The instrument that
+  says so is `all-locales-key-parity.test.ts`; `pnpm check:i18n-drift` prints which
+  of the two owns an addition.
+  
+  **One rendered English string moved**: the loading placeholder's three ASCII full
+  stops became the typographic ellipsis, because its sentence is now a pack value
+  and `ellipsis-glyph-3878.test.ts` holds every pack value to U+2026. The refusal
+  screen's copy is byte-identical to what it rendered before, which is what keeps
+  the five suites that pin it green.
+- 875ee61: fix(plugin-calendar, plugin-map, plugin-gantt): the registrations' `inputs` agree with the record-source rule
+  
+  All three blocks read their records from one of `data`, `staticData` and
+  `objectName` (in that order), and their `@object-ui/types` zod schemas enforce
+  "one of the three" through `requireRecordSource`. The designer-facing `inputs`
+  on the registrations disagreed with that rule in two ways:
+  
+  - `object-calendar` and `calendar` still declared `objectName` as required, so
+    the html tier's validator reported a `missing-required-prop` error on a
+    calendar authored on `staticData` or `data`, which the schema accepts and the
+    renderer draws. `objectName` is now declared without `required`, and its
+    description states the rule, as objectui#7470 did for map and gantt
+    (objectui#10392).
+  - `object-map`, `map` and `object-gantt` did not declare `data` or
+    `staticData`, so the validator reported a block authored on either as an
+    unknown prop. At this change both were declared on all three, on the schema's
+    own arms: `data` is a `{ provider, … }` data-source configuration (an object,
+    so a bare array there draws a type diagnostic, matching the schema), and
+    `staticData` is an array of records. Each description says what the renderer
+    does with the key, including that the map does not implement the `api`
+    provider (objectui#10394).
+  
+    ⚠️ **Dated note, 2026-09-25 — the bare `map` registration has since been
+    retired — objectui#10393.** Later in this same release `@object-ui/plugin-map`
+    stopped registering the bare `map` key (and its namespaced twin `view:map`),
+    so `map` declares nothing: a node authored `"type": "map"` resolves no
+    renderer, and the html tier reports it as `unknown-component`. The
+    `object-map` and `object-gantt` registrations keep both inputs exactly as
+    described above. The rest of this entry is kept as the reading of this
+    change; the objectui#10393 entry states what ships.
+  
+  The renderers' read order and the zod schemas are unchanged. The
+  `@object-ui/plugin-gantt` README sentence that listed the registration's inputs
+  is updated.
+  
+  **Correction, 2026-10-01 (objectui#11117).** "One of the three" now has an exception on all
+  three blocks: a block that declares none of them is accepted when its `dataSource.object` names
+  the object, because the registration's `ElementDataSourceGate` lands that name on `objectName`.
+  The `objectName` input description now says so.
+- e5f4343: Four more date faces now follow the display locale, not the UI language (objectui#10442).
+  
+  Each one takes its locale from `useDisplayLocale()` instead of the UI language. With an English UI and
+  a `de-CH` display locale, a date that used to read `3/4/2020` now reads `4.3.2020`. With no display
+  locale declared, the display locale falls back to the UI language, so these dates render as before.
+  
+  - `data-table` (`@object-ui/components`): the ISO date and datetime cells.
+  - The record page's History tab (`@object-ui/app-shell`): the `date` and `datetime` values in each
+    field diff.
+  - `ResourceWorkload` (`@object-ui/plugin-gantt`): the column labels and the cell tooltips. With no
+    language at all it used to fall through to the machine's locale; it now gets the display locale's
+    own last resort.
+  - `CalendarView` (`@object-ui/plugin-calendar`): the default locale for the header, the weekday
+    columns and the day cells. An explicit `locale` prop still wins over the display locale.
+- 4a3d500: `object-calendar` re-reads its events when the data-invalidation bus (`notifyDataChanged` from `@object-ui/react`) reports a change to the object it queries (objectui#10572). A write that bypasses the data source — a page action over raw HTTP, a flow, a server action — fires no `onMutation`, so a calendar on a page used to show it only when the whole page was remounted. Inline and external events are still the host's to refresh.
+- d435e96: fix(plugin-calendar): a failed load no longer keeps `ObjectCalendar` on its error screen after a later load succeeds (objectui#10663)
+  
+  `ObjectCalendar` set `error` when its fetch failed, and the render returns the
+  error screen early whenever `error` is set. Nothing ever cleared it. Every later
+  load that succeeded still wrote its events, but the calendar stayed on the error
+  screen until it remounted. Since objectui#10572 the calendar re-reads on every
+  data-invalidation event, so one failed background re-read was enough.
+  
+  The current run of the fetch now clears the error when it commits rows, on each
+  of its commit branches: those rows answer the current query, so the earlier
+  failure no longer describes the screen. This is the rule objectui#10578 set for
+  `ObjectGantt`. The clear sits inside the run's existing `isMounted` guard, so a
+  superseded run cannot clear the current run's error. The error is not cleared
+  when a run starts; it stays until rows land.
+  
+  Rows a parent hands over through `data` clear it too, beside the row-ceiling
+  reset that already sits there for the same reason: those rows are not the query
+  that failed.
+  
+  A failed background re-read is still reported: the calendar has no silent mode,
+  so it shows the error screen rather than keeping the last good events, and the
+  next re-read that succeeds takes the screen back.
+- f9c06ef: Every data node that sends its own authored `filter` into a query now resolves the spec's context tokens first (objectui#10666). With `filter: [['owner', '=', '{current_user_id}']]` these nodes used to send the literal token; they now send the signed-in user's id, and `{current_org_id}` resolves to the active organization:
+  
+  - `object-calendar`, `object-map` and `object-tree`, on both the object query and the inline (`provider: 'value'`) query;
+  - `object-gantt`, `object-kanban` and `object-timeline`;
+  - `record:related_list` and `record:line_items`, where the node's own filter is combined with the parent-record condition;
+  - the `element:repeater`, `element:number` (both the `aggregate` filter and the `find` fallback) and `element:record_picker` page elements.
+  
+  `list-view`, `object-grid` and `object-gallery` already did this, and are unchanged.
+  
+  **New in `@object-ui/react`: `useResolvedFilter(filter, scope)`.** Pass it a node's authored filter and `useFilterScope()`. It resolves the filter through `@object-ui/core`'s shared `resolveFilterPlaceholders` and holds the result: re-rendering with an equal filter (even one rebuilt inline on every render) hands back the same value, so a fetch effect keyed on it does not run again, while a structurally different filter or a change of signed-in user or organization resolves again. A filter with no token to resolve is handed back as the value you passed in. The hold is the one `list-view` and `object-gallery` used privately; `plugin-list` now imports it from here, and no second copy remains in that package.
+  
+  What changes for an app:
+  
+  - A filter with no placeholders reaches the query as before, unchanged.
+  - Nodes that re-queried whenever the host rebuilt an equal filter inline (`object-calendar`, `object-gantt`, `object-kanban`, `object-map`, `object-tree`) no longer issue those redundant queries.
+  - Date macros such as `{today}` in these nodes' own filters are now resolved in the browser's local time, as they already are for `list-view`, `object-grid` and `object-view`. Before, they reached the server as literals, and the server resolved them in the tenant's time zone.
+  
+  `@object-ui/types`: the `filter` docblocks on `ObjectMapSchema`, `ObjectTreeSchema`, `ObjectGanttSchema`, `ObjectCalendarSchema`, `ObjectKanbanSchema`, `ObjectChartSchema` and `ObjectGallerySchema` (and the matching zod descriptions) no longer say the filter is forwarded verbatim; they say its context tokens are resolved first. No type changes.
+- 1659f14: The calendar's quick-create dialog now formats its date with the same locale as the month grid (objectui#10668).
+  
+  `ObjectCalendar`'s quick-create dialog used its `locale` prop as is. When no host passed one, that was
+  `undefined`, so the dialog's date and time followed the machine's locale while the grid beside it
+  followed the display locale. The dialog now uses the grid's rule: an explicit `locale` prop still wins,
+  and otherwise the dialog reads `useDisplayLocale()`. With an English UI and a `de-CH` display locale,
+  clicking 18 March now opens a dialog reading `On 18. März 2020`.
+- 13220af: fix(plugin-calendar): `CalendarView`'s header date popover reads the same locale as its grids (objectui#10747)
+  
+  `CalendarView` formats its header and its month, week and day grids with one
+  locale: an explicit `locale` (an `object-calendar` node's authored `locale`
+  arrives this way), else the display locale. The header's date popover mounted
+  `Calendar` with no locale, so it read the display locale even when the grids
+  read another one. Under an `en-US` display locale with `locale: 'de-CH'`, the
+  header read `März 2020` and the popover under it read `March 2020` over
+  `Su Mo Tu …`.
+  
+  The popover now passes its grids' locale to `Calendar` as `localeTag`, so both
+  faces read `März 2020`, and the popover's week starts on Monday. With no
+  `locale`, both read the display locale, as before. This package takes no
+  date-fns dependency: the tag is resolved inside `@object-ui/components`.
+- c5ec15c: fix: every `Calendar` picker opens on its selected date's month, not today's (objectui#10799)
+  
+  react-day-picker opens on `month`, else `defaultMonth`, else today, and
+  `selected` does not move it. Five `Calendar` mounts passed `selected` only, so
+  a value outside the current month opened the picker on today's month: with
+  the calendar on 4 March 2020 and today in September 2026, the header of
+  `CalendarView` read `March 2020` while the popover under it opened on
+  `September 2026`, with no selected day in view.
+  
+  Each mount now passes its first selected day as `defaultMonth`:
+  
+  - `CalendarView`'s header date popover (`@object-ui/plugin-calendar`) opens on
+    the date the header names, and follows Previous / Next between opens;
+  - `ui:calendar` opens on its day in `single` mode, on the first valid listed
+    day in `multiple` mode (an entry that is not a date is skipped) and on `from`
+    in `range` mode. It reads that month once, when it mounts: a value that
+    changes afterwards does not move the month it shows;
+  - the form date picker (`date-picker`) and `DatePicker` open on their value;
+  - the dashboard date filter's custom-range calendar
+    (`@object-ui/plugin-dashboard`) opens on the range's `from`.
+  
+  With no value, each still opens on today. react-day-picker throws on an
+  invalid `defaultMonth`, so a day that names no instant is not passed as one: an
+  unparseable `ui:calendar` day, a range `from` that does not parse, and an
+  invalid `Date` a host hands `CalendarView` each open on today, as before. The
+  two date pickers are unchanged in this respect: an invalid value already fails
+  in their trigger's label, before any calendar mounts. The `Calendar` primitive
+  itself is unchanged.
+- 6650259: fix(plugin-calendar): a day event moved across a DST change writes the days it was dropped on (objectui#10866, slice 4)
+  
+  - **plugin-calendar.** At this change the month grid moved each date of an event by the milliseconds between two local midnights, the grabbed cell's and the drop cell's, and a date-only value is read at local midnight of its day. So when a DST change lay between one of an event's dates and where it landed, but not between the two cells (or the other way round), that date came back an hour off local midnight; at 23:00 of the day before, the write took the day before. Under `America/Los_Angeles` a span of `date` fields moved across November 1st or March 8th could be written a day short at its start or its end. A move of an event whose start, and end when it has one, are both stored calendar days now writes each `date` field as its stored day moved by the whole days the grid moved it. Every other write is unchanged: a `datetime` field still writes the instant the grid hands back, and at this change the grid's own arithmetic does not change.
+  
+    ⚠️ **Dated note, 2026-09-29 — the month grid now moves by calendar days — objectui#11005.** Later in this same release the month grid moves a value by the calendar days between the grabbed cell and the drop cell and keeps its time of day, for a move and for a drag of a span's end, so a 10:00 `datetime` stays at 10:00 across a DST change. A `date` value read at local midnight of its day then comes back at local midnight of the day it was dropped on, so the repair described above is removed and a moved `date` field is written as that local day, which is the same day the repair wrote. The rest of this entry is kept as the reading of this change; the objectui#11005 entry states what ships.
+  - **plugin-gantt, types.** The business `timeZone` prose (`GanttConfig.timeZone`, `GanttViewProps.timeZone` and `makeTzShift`) said persisted data stays real instants. A `date` field under a zoned chart has been written as a calendar day since this card's first slice; at this change the prose says so, and says that near a DST change of the chart's zone or the viewer's the shim can place a day's midnight an hour early, onto the day before. Documentation only.
+  
+    ⚠️ **Dated note, 2026-09-29 — a zoned chart reads and writes a day exactly on a DST change — objectui#10866, slice 5.** Later in this same release `ObjectGantt` inverts the shim exactly for a date-only day, so a stored day is drawn from its own midnight and a drop writes the day it was dropped on, on a DST change of the chart's zone or the viewer's too. The `GanttConfig.timeZone` and `GanttViewProps.timeZone` prose no longer says a day can land on the day before, and `makeTzShift`'s says a day does not take the shim's round trip. The rest of this entry is kept as the reading of this change; the slice-5 entry states what ships.
+  - **core.** The `DATEADD` / `DATEDIFF` / `DATEFORMAT` docblock names how a mixed `DATEDIFF`, one day and one instant, reads each argument when it counts months or years. Comment only.
+- 4f8b7f8: fix(plugin-calendar,plugin-gantt): a stored date-only day shows on that day in every viewer zone, and a `date` field is written back as a calendar day (objectui#10866, slice 1)
+  
+  The calendar and the gantt read a record's `YYYY-MM-DD` value with the engine's own `Date` parse, which reads it as UTC midnight. West of UTC a task due on the 5th therefore showed on the 4th, in both views. Moving it then wrote `toISOString()` into the field: a UTC instant stored in a `Field.date`.
+  
+  - **Reads.** Every date-only read in the two plugins now goes through `toDisplayDate` from `@object-ui/core`, which reads the value at local midnight of the day it names. In the calendar these are the object calendar's event start and end, and the `calendar-view` node's events and its authored `currentDate`. In the gantt they are the task start, end and baselines, a marker authored as a day, and the day typed into the inline editor. A value with a time keeps its instant.
+  - **Writes.** A calendar drop, a calendar quick-create and a gantt drag now write a field declared `date` as the local calendar day, `yyyy-MM-dd`. A `datetime` field keeps its instant. When no object schema is available to say which type a field is, the stored value's own shape decides, which is the same split the read makes; a calendar quick-create has no stored value, so there it still writes the instant.
+  - **Gantt `timeZone`.** A chart with a business `timeZone` re-bases every instant into that zone. A date-only day is not re-based: its bar and its marker stand on that day of the chart's calendar for every viewer, and a drop writes the day of the chart's calendar that the bar was dropped on.
+  - **Gantt working calendar.** `skipWeekends` / `holidays` now count the chart's own calendar days (local midnight, the same keys the day columns already folded by) rather than UTC days. The UTC floor put a rescheduled successor on the previous day in every zone except UTC once date-only values read as local days. `@object-ui/types` updates the `holidays` description to match.
+  
+  The timeline, charts, formula date functions and i18n helpers are later slices of objectui#10866.
+- f9b6dfe: fix(plugin-calendar): a month-grid move keeps the wall-clock time across a DST change (objectui#11005)
+  
+  The month grid moved an event by the milliseconds between the grabbed cell's local midnight and the drop cell's. Across a DST change that span is 23 or 25 hours. Under `America/Los_Angeles`, a 10:00 event moved onto or off November 1st or March 8th landed at 09:00 or 11:00. A span starting at local midnight, grabbed on a later day and moved, started at 23:00 of the day before the one it was dropped on. The calendar's own month-view quick-create writes such local-midnight instants.
+  
+  - **Move.** The grid now counts the calendar days between the grabbed cell and the drop cell and moves the start and the end by that many days on the local calendar. Each keeps its hours, minutes, seconds and milliseconds, so a 10:00 event stays at 10:00 on the day it is dropped on, whatever DST change lies between. This deliberately changes the instant a drag writes into a `datetime` field; what a `datetime` field stores and how it is read are unchanged. In a zone without DST every day is 24 hours, so a move writes what it wrote before.
+  - **Drag of a span's end.** The right-edge handle moves the end by calendar days the same way. It already kept the end's hours, minutes and seconds; it now keeps its milliseconds too.
+  - **`date` fields.** A `date` value is read at local midnight of its day, so it now comes back at local midnight of the day it was dropped on, and `ObjectCalendar` writes that local day. The `ObjectCalendar` repair from objectui#10866, which moved a day event's stored day by the whole days the grid moved it, is removed: every day move it pinned writes the same day without it.
+  - The week and day views are unchanged. Their time grid places a moved event at its snapped time on the drop day's own clock, not by a day delta.
+- 2a1779f: fix(plugin-calendar): a week or day view move keeps the event's own length and grab point (objectui#11037)
+  
+  The week and day views draw an event that crosses midnight as one piece per day, clipped at midnight, and a short event as a piece at least 15 minutes tall. A move took its length and its grab offset from the grabbed piece. So a 22:00 to 02:00 event dragged by its first piece to 10:00 was handed to `onEventDrop` as 10:00 to 12:00, and `ObjectCalendar`'s default drop handler writes what it is handed. Grabbed by its second piece, the event's start went where its midnight had been grabbed. A 5-minute event came back 15 minutes long.
+  
+  - **Length.** A move now keeps the event's own `end - start`, as elapsed time, so a `datetime` event keeps its real length. On the night a DST change falls in, the wall clock shows that length an hour longer or shorter: a 4-hour event placed at 22:00 on the night the clocks fall back reads 22:00 to 01:00.
+  - **Grab point.** The grabbed point's offset is measured from the event's own start, so the point under the pointer stays under the pointer. A 22:00 to 02:00 event grabbed at its own 00:00 and dropped at 10:00 is written 08:00 to 12:00.
+  - **Crossing midnight.** An event that crosses midnight is placed where it is dropped, so it can stay overnight; before, it was held to end by midnight of the drop day. An event drawn wholly inside one day is still held inside the drop day, as before.
+  - The drag preview is labelled with the whole event's times and drawn over the part of it that falls on the drop day.
+  - An event with no end is still handed an end one hour after its new start. All-day and date-only events sit in the all-day row, which has no drag, so nothing about them changes. The month grid and the resize handles are unchanged.
+- 3e71a98: fix(plugin-calendar): a week or day resize of an overnight event keeps its other edge (objectui#11060)
+  
+  The week and day views draw an event that crosses midnight as one piece per
+  day, clipped at midnight, and a short event as a piece at least 15 minutes
+  tall. The top resize handle sits on the event's first piece and the bottom
+  handle on its last. A resize rebuilt both edges on the grabbed piece's day,
+  the untouched one from that piece's clipped bound. So a 22:00 to 02:00 event
+  resized by its top handle to 21:00 was written 21:00 to 00:00, losing the two
+  hours past midnight, and resized by its bottom handle to 03:00 was written
+  00:00 to 03:00, its start moved to midnight. A press and release on the top
+  handle without moving cut the end to midnight too, and a 5-minute event resized
+  by its top handle came back ending 15 minutes after its old start.
+  
+  The top handle now changes only the start and the bottom handle only the end.
+  The other edge is the event's own instant, handed to `onEventDrop` unchanged.
+  The dragged edge is placed as before, at the pointer's row on the grabbed
+  piece's day, snapped, and held one slot away from the kept edge wherever that
+  edge falls. The preview while dragging is labelled with the whole event's
+  times. A same-day event resizes exactly as before.
+- 0e6e76b: fix(plugin-gantt, plugin-calendar): the `objectName` input description names the `dataSource.object` binding (objectui#11117)
+  
+  The designer-facing `objectName` input on `object-gantt` and `object-calendar` (and
+  `view:calendar`, which shares the calendar's list) said the block's schema refuses a block that
+  declares none of `data`, `staticData` and `objectName`. Since objectui#11117 the schema also
+  accepts a block whose `dataSource.object` names the object, because the registration's
+  `ElementDataSourceGate` lands that name on `objectName` before the renderer reads the node. The
+  sentence now says so. No input's name, type, `required` flag or shape changed. (`object-map`'s
+  input already names the binding: objectui#10859 batch 5 rewrote it.)
+  
+  The `plugin-gantt` and `plugin-kanban` READMEs carry the same correction.
+- 6cd5ae3: The `object-calendar` / `calendar` `navigation` input description said `openNewTab: true` "outranks the mode". That does not hold for `none`: `useNavigationOverlay` checks `mode === 'none'` before `openNewTab`, so `{ mode: 'none', openNewTab: true }` opens nothing. The description in `src/index.tsx` now says `openNewTab` outranks every mode except `none` (objectui#11168 slice 5, from objectui#8652).
+  
+  `src/__tests__/calendarNavigationMembers-8652.test.tsx` pins both halves: `openNewTab` beside each overlay mode opens a new tab and no overlay, and beside `none` it opens nothing. Behaviour is unchanged.
+- 39f4309: Published typings from every `vite-plugin-dts` package now carry an explicit extension on
+  every relative specifier, and a type error in the declaration build now fails the build
+  instead of being printed and ignored (objectui#5439, objectui#5483).
+  
+  **Consumers on `moduleResolution: nodenext` or `node16` may see NEW type errors, and that
+  is the fix working.** These packages re-export mostly through NAMED re-exports —
+  `export { useObjectChat } from './useObjectChat'`. TypeScript could not follow the
+  extensionless hop, but it still DECLARED the name, so the symbol resolved to a silent
+  `any`. Nothing errored; consumers simply got no types. With the extension emitted, the
+  symbol carries its real type, and any call site that was relying on the `any` now type
+  checks for the first time. This is the mode that produced the 21 residual `TS7006` on
+  `@object-ui/app-shell` reported against objectui#5365 — a type hole that opened quietly,
+  unlike objectui#5365's own `export * from './ui'` packages where the same defect surfaced
+  immediately as `TS2305: has no exported member`.
+  
+  410 extensionless relative specifiers across 19 packages were emitted before this change;
+  the count is now 0 in all 22 packages that build typings through `vite-plugin-dts`.
+  `@object-ui/fields` was already clean — its sources write explicit `.js` specifiers — and
+  is wired so it stays that way.
+  
+  The second half changes no emitted output today: 22/22 packages built green unmodified, so
+  making the declaration step's exit code honest turns nothing red. It changes what a FUTURE
+  regression does — print and exit 0, versus fail the build.
+- 3e853c9: Let a producer-marked refusal reach the drag-write surfaces (objectui#5902).
+  
+  The kanban card-move toast, the calendar drag-to-reschedule toast and the OCC
+  conflict dialog each substituted a generic string for a refusal the producer had
+  marked as user-facing (`userMessage`), so a user was told "Save failed" where the
+  application author had written a sentence addressed to them. All three now read
+  the marking through the shared `declaredUserMessage` reader, which covers both
+  places the adapter boundary parks it — the typed member on
+  `ConcurrentUpdateError` and the details bag on `DataApiValidationError`.
+  
+  Nothing unmarked changes: the reader answers `null` for it, so every existing
+  generic substitution — including the localized "not authorized" message that
+  keeps raw server diagnostics away from end users — still governs unmarked
+  refusals exactly as before.
+  
+  The two toasts substitute; the conflict dialog augments. Its description also
+  explains what the destructive "Overwrite" button does, which is affordance copy
+  that surface owns rather than a refusal message, so the marking leads and that
+  paragraph stays.
+- 7975f2d: A standalone `object-calendar` bound to an object now queries WITH its `$expand`, so
+  lookup / master_detail / user / tree fields render the related record instead of a raw
+  foreign-key id (objectui#6453).
+  
+  `ObjectCalendar`'s fetch effect built its expand set from a ref assigned in the render body
+  (`objectSchemaRef.current = objectSchema`) and left `objectSchema` out of its dependency
+  list. That bought the effect exactly one run per mount and paid for it with the expansion,
+  permanently: on that one run the ref was still `null`, `buildExpandFields` saw no fields,
+  the query went out with no `$expand` at all, and nothing re-ran the effect when the schema
+  landed. Only the standalone calendar reached this path — one hosted by `ObjectView` or
+  `ListView` receives its rows as `data`, which objectui#6419 already covers.
+  
+  The ref is replaced by a settled-and-keyed resolution (`{ key, def } | null`) that GATES the
+  record query, the third member of the family after objectui#6271 (`ObjectKanban`) and
+  objectui#6419 (`ObjectView`). Measured on this component rather than inherited: gated, the
+  calendar issues one query carrying `$expand` in every latency profile; the alternative of
+  adding `objectSchema` to the dependency list issued two, and when the schema read was the
+  slower of the two it painted raw ids, reverted to the "Loading calendar..." placeholder,
+  then swapped — a three-step paint the correct rows do not arrive any later than.
+  
+  The gate is on the schema read having SETTLED, never on a truthy schema: an adapter that
+  exposes no `getObjectSchema`, and a read that throws, both settle with nothing and the
+  calendar still queries (unexpanded) rather than waiting forever. An inline `value` data set
+  is deliberately not gated — it issues no metadata read, so there would be no resolution to
+  wait for.
+- f9653ae: Re-key the load-bearing fetch effects in `ObjectMap`, `ObjectCalendar` and
+  `ObjectGantt` onto the primitive fields they actually read off `dataConfig`
+  (`provider` / `object` / `items`) instead of the whole memoised `dataConfig`
+  object (objectui#6592, the deferred half of objectui#6270/PR #6591).
+  `ObjectTree` is a census member too but is deferred out of this change — see
+  the PR body — because its own fetch effects are the surface of PR #6696
+  (objectui#6481), open at the same time.
+  
+  `useMemo` carries no semantic guarantee — React is permitted to discard a
+  memo cache and recompute even when its dependency array compares equal to
+  the previous render, and the local `getDataConfig(schema)` helper each of
+  these renderers carries builds a fresh `{ provider, object }` /
+  `{ provider, items }` wrapper object on every call. So a fetch effect keyed
+  on `dataConfig` itself was correct only for as long as that identity
+  happened to survive a discard: a recompute alone (no author or caller
+  action) was enough to re-run the effect and issue an extra
+  `dataSource.find` / `dataSource.getObjectSchema` call. Keying the effects
+  on the primitives instead makes a cache discard a no-op, restoring
+  `useMemo` to a pure optimisation.
+  
+  `ObjectGantt`'s `effectiveDataSource` memo deliberately keeps `dataConfig`
+  as a dependency (`resolveDataSource` needs the whole provider-shaped
+  value — the `api` provider's `read`/`write` request config cannot be
+  flattened to a fixed primitive list the way `object`/`value` can), so its
+  `reload()` fetch is decoupled from the redundant direct `dataConfig`
+  dependency but not from `effectiveDataSource`'s own; for the `object`/`value`
+  providers `resolveDataSource` returns its `fallback`/a fresh
+  `ValueDataSource` respectively rather than reading further into the config,
+  which is enough for the two fetch effects to observe no extra call under a
+  recomputed-but-equivalent `dataConfig` in the common case.
+  
+  No behaviour change for a schema whose `useMemo` caches survive normally;
+  the effects are unaffected by React discarding one.
+- 3beef6d: The spec's `dataSource` element binding is now DECLARED by the blocks that read
+  it, so the html tier stops reporting the one working saved-view spelling as
+  `unknown-prop` (objectui#6678).
+  
+  `PageComponentSchema.dataSource` — `{ object, view, filter, sort, limit }` — is
+  the one spelling that resolves a saved view for an object-bound block. It works,
+  and it drew the identical `unknown-prop` warning as the two spellings that do
+  nothing (`viewName`, `view`), because `validateTree` looks a prop up in the
+  block's declared `inputs` and no registration declared this key. On the tier
+  built to accept AI-authored pages, where the diagnostic IS the contract, the
+  only signal pointed away from the key that works.
+  
+  Adopting the maintainer ruling of 2026-08-29 — option B **in the injection
+  form**:
+  
+  - `ELEMENT_DATA_SOURCE_INPUT` is the single declaration, in `@object-ui/core`
+    beside the binding's own semantics; `Registry.register` emits it for any
+    registration whose renderer passed through the new `elementDataSourceBlock()`
+    seam. One mechanism, one copy — not a hand-kept declaration per block, which is
+    the shape that drifts and that a new block forgets. The seam lives in
+    `@object-ui/core` and is re-exported by `@object-ui/react` beside
+    `ElementDataSourceGate` for discoverability; call sites take the core import,
+    because a registration runs at module scope and this repo's suites partially
+    mock `@object-ui/react`.
+  - Seventeen renderers, in thirteen files across twelve packages, reach the seam
+    and now publish the key to the save gate, the parser whitelist, the generated
+    JSX authoring types and the block list. The card named nine blocks; the tree
+    also has `plugin-grid`, `plugin-timeline`, two further `plugin-form` blocks and
+    `element:record_picker` — nothing was hand-listed, so the mechanism covered
+    them. `element:record_picker` consumes the gate's HOOK and status panels rather
+    than the wrapper tag (its object lives under `properties`), and was found by a
+    render probe rather than by reading sources.
+  - `dataSource` on a block that does NOT read it (`flex`, `card`) still reports
+    `unknown-prop`. Adding the key to `sdui-parser`'s `BASE_PROPS` was refused for
+    exactly this reason — that set mirrors `BaseSchema`, and silencing the key
+    everywhere would make the diagnostic lie in the other direction.
+  - New `check:element-data-source-declaration` fails any source that consumes the
+    gate without reaching the seam, so a block added tomorrow cannot forget.
+  
+  Behaviour of the binding itself is unchanged — this is a declaration, not a
+  resolution change. The saved view still resolves its columns, and an
+  unresolvable `view` still fails loudly rather than widening to the object's full
+  scope.
+  
+  The spec/registry parity gates (repo-wide and the `record:related_list` per-block
+  pin) now derive their accepted set from the WHOLE node contract rather than from
+  `ComponentPropsMap[type]` alone. `PageComponentSchema` accepts and keeps
+  `dataSource` on a page-component node — it is a node-level key, a sibling of
+  `type` and `className`, not a per-block prop — so the gates' previous complaint
+  was measurably wrong. Derived from the spec, not exempted, and both still
+  discriminate against an invented key.
+- 7c3df8f: The settled-schema convergence, and the gantt's duplicate query gated
+  (objectui#7225, maintainer ruling B, 2026-09-02).
+  
+  `useSettledSchema` was extracted and published in PR #6690 with exactly **one**
+  non-test adopter (`ObjectTree`, the component that had an actual defect —
+  objectui#6481's unkeyed latch). `ObjectKanban`, `plugin-view/ObjectView` and
+  `ObjectCalendar` kept their own hand copies of the same shape, so a published
+  export was owed compatibility forever **and** the duplication it was named for
+  stayed. All three now call the hook.
+  
+  The migration is a pure deduplication with no behaviour delta — the hook was
+  extracted *from* these three shapes, so each becomes a one-line call.
+  `ObjectCalendar`, which objectui#6482 named as the obstacle, fits via the
+  recipe the hook's own doc comment prescribes for it by name: pass the data
+  source as `undefined` for a render that must not read metadata
+  (`hasInlineData ? undefined : dataSource`), so "inline value data set" is
+  expressed as "there is no source to read from" rather than as a second enable
+  flag. GATE PLACEMENT stays local in all three, which is what #6482 ruled and
+  what made the calendar's obstacle a non-obstacle: it was about the gate half.
+  
+  **One observable change:** `ObjectKanban`'s rejected definition read now logs
+  on `console.error` with a `[useSettledSchema]` prefix instead of
+  `console.warn`. Its test spy moves with it, and now asserts on the channel
+  rather than merely silencing it.
+  
+  **The gantt's duplicate query is gated** (ask 2 of the card; #6482's
+  undischarged half). `ObjectGantt` listed `objectSchema` in `reload`'s
+  dependency list, so every load issued two unbounded queries — the first with no
+  `$expand` at all. Measured on this component across three latency profiles, the
+  cost is not the mild "round trip bought and thrown away": when the metadata
+  read is the slower of the two, which is the common case on a cold
+  `MetadataCache`, the user sees the full three-step paint — raw foreign-key ids,
+  back to the loading placeholder, then the expanded rows. It now issues one
+  query, already expanded.
+  
+  Gating the gantt required its schema resolution to settle on EVERY exit
+  (objectui#7232): the hand-rolled effect returned without settling on
+  `!effectiveDataSource`, on `!resource` and in its `catch` — harmless while
+  nothing waited on it, and a chart that never loads once something does.
+  `useSettledSchema` settles on all three by construction, which is what makes
+  the gate safe; both exits are pinned.
+  
+  ⛔ Gating is not capping. The row ceiling on these fetches is objectui#7210's
+  separate ruling, in its own commit on the same branch.
+- 6411def: FLS-gate the `$expand` projection at the five remaining build sites (objectui#7230).
+  
+  objectui#7215 / PR #7229 gated `$expand` at the two projection sites in its scope
+  (`ObjectGrid`, `ListView`). The helper is reached from more places than that. This
+  closes the five that were left: `ObjectCalendar`, `ObjectGantt`, `RecordDetailView`,
+  `DetailView`, and `ObjectDataTable` (which builds its own whitelist in
+  `computeLookupExpand` rather than calling `buildExpandFields`).
+  
+  **Three of them pass no column list at all**, which makes them the sharp ones:
+  `buildExpandFields` reads an absent column list as "no column restriction" and falls
+  back to **every declared relation on the object**, denied ones included. So a standalone
+  calendar, a gantt, and every record page in the console asked the server to resolve the
+  object's full relation set by default rather than by configuration.
+  
+  **`DetailView` was input-gated, and that is the defect rather than the fix.** Its column
+  list is already FLS-filtered field by field, which is exactly the route PR #7229 measured
+  as unsound: an emptied column list reads as "no column restriction", so a detail view
+  whose authored fields are all denied had its `$expand` **widened** from the relations it
+  asked for to every relation the object declares. The principal who may read least was
+  asking for the most.
+  
+  **Reproduced before it was fixed**, as a failing test per site.
+  
+  **Grading, measured rather than assumed.** Against ObjectStack's own server this is
+  defence-in-depth, exactly as objectui#6898 and #7215 are: `plugin-security`'s
+  `FieldMasker.maskRecord` deletes every unreadable key from each returned row and
+  objectql's expand path writes the resolved record back under that same key, so one
+  statement removes the expanded object and the bare id alike; the expansion sub-read is
+  itself gated (`__expandRead` takes the referenced object's full CRUD + RLS + FLS
+  treatment). It is load-bearing for any backend that does not strip, and the
+  client-request side is real regardless.
+  
+  **Nothing a permitted view did stops working.** The gate judges each helper's OUTPUT,
+  which contains only the object's declared reference-bearing fields, so the "`checkField`
+  answers false for an undeclared key" trap cannot be reached and derived / host-joined
+  columns are untouched. An unanswered permission policy filters nothing. Neither
+  `buildExpandFields` nor `computeLookupExpand` is changed.
+- e75f4c9: `colorField` now means the same thing in the gantt, the calendar and the timeline
+  (objectui#7243).
+  
+  **The inversion this fixes.** `gantt.colorField` is documented as "field that drives the
+  bar color", and the renderer passed the stored value straight into the bar's
+  `backgroundColor`. Pointing the key at a select field therefore emitted
+  `backgroundColor: "open"` — not a colour, so the browser dropped the declaration and
+  every bar rendered identically. OMITTING the key was strictly better: the absent-key
+  branch derived a real colour per status. Declaring the documented key was worse than not
+  declaring it, with no error, warning or console message either way.
+  
+  The same key also meant three different things across the three lenses: the timeline
+  resolved the field's authored option `color`, the calendar hashed the raw value onto a
+  fixed palette, and the gantt emitted the raw value. An author colouring three views by
+  one field got three unrelated results, one of which was no colour at all.
+  
+  **The ladder.** `@object-ui/core` gains `createFieldColorResolver` — the timeline's
+  resolver, lifted so all three call it:
+  
+  1. the field's own option `color` for the record's value;
+  2. else the value itself when it already IS a colour literal (`#rgb`, `#rrggbb`,
+     `#rrggbbaa`, `rgb(...)`, `hsl(...)`);
+  3. else each renderer's own last rung, which is deliberately NOT shared — the gantt
+     derives a semantic-token hex (a bar must be painted), the calendar keeps its
+     theme-aware 8-stop hash (a soft tint, not a solid fill), the timeline draws its
+     default marker.
+  
+  **What changes for authors.** A gantt or calendar whose `colorField` points at a select
+  field with authored option colours now paints those colours. A gantt value that is
+  neither an option colour nor a colour literal now derives a colour instead of emitting
+  an invalid CSS value — including a palette NAME (`red`), which now resolves to that
+  palette's hex, the behaviour the key's own contract has always promised ("hex or
+  semantic name") and the one `borderColorField` already had. `gantt.borderColorField`
+  takes rung 1 as well, so an authored option colour reaches the alert stroke; it keeps
+  today's behaviour otherwise and deliberately gains no derivation rung, since the stroke
+  is opt-in and deriving one for every record would draw an alert on records that have
+  none.
+  
+  Calendars whose `colorField` points at a plain categorical field are unchanged: that
+  value still reaches `CalendarView`'s deterministic hash exactly as before. The timeline
+  is unchanged apart from accepting the 8-digit `#rrggbbaa` hex spelling the calendar
+  already accepted.
+- b8fc1e2: fix(plugin-calendar): the all-day lane header reads the same string with or without an I18nProvider
+  
+  `CalendarView`'s `DEFAULT_TRANSLATIONS` table — the `defaults` map behind its
+  `createSafeTranslation` factory — spelled `calendar.allDay` as `all-day`, while
+  all ten locale packs carry the key and `en` spells it `All Day`. Since
+  `createSafeTranslation` serves that table only when no `I18nProvider` is
+  mounted, the same lane header rendered `all-day` in a standalone embed and
+  `All Day` inside the console. The table now matches the pack, so both paths
+  render one string.
+  
+  The table entry was the only one of the seven that disagreed with its `en`
+  value, and the packs predate it by three months — the drift was an oversight,
+  not a compact spelling chosen for the 56px gutter (both strings are seven
+  characters wide).
+  
+  Also removes the dead `t('calendar.allDay') === 'calendar.allDay'` ternary that
+  guarded the lane header: the factory's provider-less arm returns `defaults[key]`
+  before it could ever return the bare key, and with a provider the merged
+  resources always carry `calendar.allDay`, so its lowercase branch was
+  unreachable from either side.
+- c6198c2: **Breaking for authored metadata:** `ComponentInput.label`, `ComponentInput.defaultValue` and
+  `ComponentInput.advanced` are RETIRED on both faces (objectui#7493 item ① and objectui#7781;
+  maintainer ruling A of 2026-09-06, immediate, no deprecation window; ADR-0049 enforce-or-remove).
+  They are the three keys the manifest serializer does not forward, and nothing read them on any
+  publication or consumption path.
+  
+  No manifest ever published them, so no consumer could ever have read them. `sdui-parser`'s
+  serializer (`packages/sdui-parser/src/index.ts`) forwards exactly seven keys per input — `name`,
+  `type`, `of`, `required`, `enum`, `binding`, `description` — so a value authored under any of the three
+  never reached `sdui.manifest.json`, the generated JSX `.d.ts`, or a diagnostic; its boundary type
+  has no slot for them; the registry's data-source seam reads `name` only; and neither the designer
+  nor the app-shell inspectors consult registry `inputs` at all. A structural census over every
+  `inputs:` array in the repository (re-measured on this change's merge-base, `name` 951 and `type`
+  951 as the controls) counted the writes: `label` 908, `defaultValue` 245, `advanced` 9 — written on
+  nearly every registration, read by nothing.
+  
+  FROM → TO, per key — all three **TOMBSTONED, not removed**, because the route was measured on
+  the built face before it was chosen: `ComponentInputSchema` is a non-strict `z.object`, and an
+  undeclared key parses GREEN and is silently STRIPPED, so a deletion would have swallowed 1,162
+  authored values in silence. The tombstone is what makes the refusal loud and by name.
+  
+  - `label?: string` → `label?: never` on the interface, `retirementTombstone()` on the Zod mirror.
+    Migration: delete the key. An input is identified by its `name` on every path that reaches it;
+    nothing ever rendered a label for it.
+  - `defaultValue?: any` → `defaultValue?: never` / `retirementTombstone()`. Migration: delete the
+    key. The renderer's own fallback read IS the default; tell the author about it in `description`,
+    which IS published. (Tightening the type to `unknown` was ruled out: it closes no error class,
+    since nothing reads the value.)
+  - `advanced?: boolean` → `advanced?: never` / `retirementTombstone()`. Migration: delete the key.
+    No designer surface ever hid an "advanced" input; there is nothing to write instead.
+  
+  The retirement kit: `?: never` on `ComponentInput` (`packages/types/src/base.ts`), so authoring one
+  is a `tsc` error at the registration site; `retirementTombstone()` on `ComponentInputSchema`
+  (`packages/types/src/zod/base.zod.ts`), so an authored value is REFUSED at parse time with
+  `code: 'invalid_type'`, the key named in the issue `path`, and the migration note as the message
+  (one string, both channels). Pinned in
+  `packages/types/src/__tests__/component-input-retired-keys-7493.test.ts`, which also holds a
+  tree-scoped absence census over every `inputs:` array under `packages/**` and `apps/**`.
+  
+  Accept-set change, stated plainly for reviewers: a document that sets any of the three keys on a
+  `ComponentInput` used to parse GREEN (the value was then dropped by the serializer) and now parses
+  RED. Every in-repo authoring site — 1,199 keys across 110 registration files, the three standalone
+  `ComponentInput[]` arrays and the two named input arrays `tsc` found included — is deleted in the same change, as the ruling's split rule
+  requires; the `WidgetRegistry` seam no longer copies the widget-manifest values onto the synthesized
+  `ComponentInput` (they fed nothing), and the data-source declaration `ELEMENT_DATA_SOURCE_INPUT`
+  drops its `label`. The patch entries on the other packages record exactly that: their registrations
+  stop authoring inert keys, with no runtime or published-manifest change.
+  
+  The nine test files that read `defaultValue` off a registration were re-pinned against the
+  renderer's ACTUAL default (its own fallback read, or the `defaultProps` it ships) instead of the
+  declaration that went away; two assertions that only restated the shadow default were dropped with
+  the reason on the line.
+  
+  The in-repo zero is what was measured. Whether anything OUTSIDE this repository writes these keys
+  is not measurable from here (the objectui#5674 limit); converting such a write from a silent drop
+  into a named refusal is exactly what the tombstones buy. `WidgetInput`'s own `label` /
+  `defaultValue` / `advanced` (the widget-manifest face) stay declared and writable — nothing has
+  ruled on that face; that it now has no reader either is recorded as objectui#7911.
+- ce2aaef: One shared record-source ladder, five plugins delegate.
+  
+  `@object-ui/core` publishes `resolveRecordSourceConfig(schema)` — the ONE implementation
+  of the ruled three-rung record source ladder: `data` first, then `staticData` wrapped as
+  `{ provider: 'value', items }`, then `objectName` folded to `{ provider: 'object' }`, and
+  `null` when nothing is bound. It is the PRODUCER whose output the reader
+  `resolveRecordSourceObjectName` (`b041b9c0c`) consumes, and it now sits beside it in the same module.
+  
+  That ladder is published contract on both faces — `packages/types/src/objectql.ts` and its
+  zod mirror both ship `.describe()` strings naming `getDataConfig`'s order (`77cb489b4`,
+  maintainer ruling 2026-09-02), pinned by `objectql-record-source-refinement-6939.test.ts` —
+  and it was hand-copied into five plugin components with no gate holding them together. A
+  change to the ruled order had five edit sites and nothing that noticed a missed one; that
+  is the AGENTS.md #0.1 drift class.
+  
+  **No behaviour changes.** `ObjectCalendar`, `ObjectGantt` and `ObjectTree` now call the
+  shared reader directly. `ObjectGrid` and `ObjectMap` keep their own bare-array `data`
+  shorthand as a documented head above the shared call and are otherwise unchanged.
+  `record-source-config.behaviourNeutrality-7632.test.ts` transcribes all five pre-collapse
+  bodies verbatim and asserts the post-collapse spelling agrees with each across the whole
+  input matrix, so a later edit to the shared reader that moves any site turns red.
+  
+  **Two divergences were measured rather than assumed, and both are preserved.**
+  
+  `ObjectCalendar`'s `'data' in schema && schema.data` guards existed because its parameter was
+  at that time the union `ObjectGridSchema | CalendarSchema`, whose `CalendarSchema` arm declared
+  neither key. (objectui#8651 has since re-pointed that parameter at the published
+  `ObjectCalendarSchema`, so the union is gone; the CONCLUSION below — that the guard had no
+  runtime effect and removing it is behaviour-neutral — is unaffected.)
+  That is a TypeScript narrowing device with no runtime effect — an absent property reads
+  `undefined`, falsy either way — so the guard could never change which rung is taken. The
+  shared reader's optional-property parameter accepts the union directly, and the
+  equivalence is pinned on a fixture that really lacks both keys rather than argued.
+  
+  `ObjectGrid` and `ObjectMap` normalize a bare-array `data` to `{ provider: 'value', items }`;
+  `ObjectCalendar`, `ObjectGantt` and `ObjectTree` do not, and return the array verbatim. That
+  is a real divergence on off-contract input — `ViewData` is a discriminated union over object
+  variants, so an array under `data` cannot be published. It is NOT unified here: the shared
+  rung stays contract-strict and the two sites keep the head locally, the same way `b041b9c0c`
+  left the off-contract `{ provider: 'object' }` tails at their sites. Both sides of the fork are
+  pinned, so neither folding the head in nor deleting it as redundant can happen silently.
+  
+  `ObjectTree`'s copy took `schema: any`; it now goes through the shared reader's typed
+  parameter. Types are erased at runtime, so nothing it resolves moves.
+- 2ce2612: A record-page URL now names the object the clicked rows actually came from, in
+  `ObjectTree` and `ObjectCalendar`.
+  
+  `useNavigationOverlay` builds `/{objectName}/record/{id}` out of whatever it is handed,
+  and both components handed it the bare top-level `schema.objectName` while resolving
+  their own rows through the ruled record-source ladder (`data`, then
+  `staticData`, then `objectName`). `77cb489b4` published `objectName` as that ladder's
+  THIRD RUNG and not as a parallel "page object" concept, so a block has exactly one
+  record source — and a row fetched through `data.object` whose click built
+  `/{schema.objectName}/record/{id}` named a record that the URL's own object does not
+  contain.
+  
+  Two shapes change, both toward the object the rows came from:
+  
+  - a block carrying **both** bindings navigated to the top-level key and now navigates to
+    `data.object`;
+  - a **data-only** block had no name to build a URL from at all, so the hook took its
+    `/{id}` leg — an unrouted path that paints a blank page — and now builds the routed
+    record URL.
+  
+  `ObjectCalendar` is where the divergence was plainest: on one click it resolved the
+  detail drawer through the ladder and the navigation URL through the top-level key. The
+  URL now reuses the very `schemaObjectName` that already keys the calendar's record query
+  and its `$expand` derivation, so query, drawer and URL agree by construction.
+  
+  **Nothing else moves.** Both converted sites keep a site-local `?? schema.objectName`
+  tail for the off-contract `data: { provider: 'object' }` that carries no `object`
+  (`ViewDataSchema` declares it required) — the same tail `ObjectTree`'s `headerObjectName`
+  already carries, and the same conservatism `b041b9c0c` applied when it published the
+  shared reader. `useNavigationOverlay`'s own signature is unchanged: it still takes an
+  `objectName`, and only what callers hand it has changed.
+  
+  The hook's `@example` stops prescribing `objectName: schema.objectName`. That prose is
+  why there were copies to convert at all — component authors copied the divergence out of
+  the documentation, correctly, as written — so it now points at
+  `resolveRecordSourceObjectName` and says explicitly that a caller with no data config
+  has nothing above rung three and should keep passing `schema.objectName`.
+  
+  `ObjectKanban` is deliberately **not** converted: it has no data config, no
+  `getDataConfig`, and its `data` is a raw row array rather than a `ViewData` binding, so
+  `schema.objectName` already IS its record source and its board, drawer and URL already
+  agree.
+- 5e5d6b2: `ObjectCalendar`'s refusal screen now states a remedy an author can act on, on every
+  door it is reachable from (objectui#8170).
+  
+  It used to read "Calendar configuration required. Please specify startDateField and
+  titleField." The first clause was right and is unchanged. The second was wrong twice:
+  
+  **It demanded an optional key.** `@objectstack/spec`'s `CalendarConfigSchema` is a
+  strict object whose ONE required key is `startDateField`. Re-measured on the installed
+  17.4.0, three legs via `CalendarConfigSchema.safeParse` from `@objectstack/spec/ui`:
+  `{}` and `{ titleField: 't' }` both fail `invalid_type` at `startDateField`, and
+  `{ startDateField: 'd' }` parses clean. The spec's own note on that schema names this
+  renderer as the reason — `resolveTitle` takes an explicit `titleField` when present and
+  otherwise resolves through the ADR-0079 record display-name chain, so the screen was
+  asking for a key the component neither needs nor reads.
+  
+  **It named keys without saying where they go, which is unactionable on an interface
+  page.** That surface's `interfaceConfig` has no calendar slot at all — it reads
+  `columns`, `sort`, `filterBy`, `userFilters`, `appearance`, `addRecord`, `userActions`,
+  `showRecordCount`, `source`, `sourceView`, `buttons` and `recordAction`, and no calendar
+  key — so the only lever there is `sourceView`, which the screen never mentioned. The
+  refusal was honest about the binding and dishonest about the remedy.
+  
+  The new copy names the one required key, says the title resolves without `titleField`,
+  points at the view's `calendar` block as the place both doors read the binding from, and
+  states the interface page's indirection outright.
+  
+  **Why the wording is door-COMPLETE rather than door-AWARE.** Two producers emit an
+  `object-calendar` node — the calendar branches of `plugin-list`'s `ListView` and
+  `plugin-view`'s `ObjectView` — and app-shell reaches the first from both its `ObjectView`
+  (object-view door) and `InterfaceListPage` (interface-page door). Every one of them hands
+  the component the same shared `baseProps` bag plus whichever declared binding keys exist:
+  nothing on the node names the door. A door-aware screen therefore needs a newly declared
+  prop threaded through four packages, and inferring the door from whether the object
+  carries a date field only correlates with it — `InterfaceListPage`'s deriver runs solely
+  when `calendar` is whitelisted in `appearance.allowedVisualizations` — which is the
+  "the gate and the seam must answer one question" failure this repo has recorded on `map`,
+  `chart` and `kanban` already.
+  
+  The first clause is unchanged on purpose: five suites pin this screen with
+  `/Calendar configuration required/i`, and `@object-ui/types`' calendar alias tombstones
+  assert on the same phrase. Only the clause that was wrong moves. The new second clause is
+  pinned in `ObjectCalendar.refusalRemedy-8170.test.tsx`, together with the runtime control
+  that makes its claim checkable: a calendar with a date binding and no `titleField` renders
+  real record titles.
+- 2d80456: `object-kanban` / `view:kanban` and `object-calendar` / `view:calendar` now DECLARE seven
+  spec-carried keys their renderers already honoured, so the html tier stops reporting working
+  metadata as `unknown-prop` (objectui#8201, the backlog objectui#8176 exposed).
+  
+  Board: `groupBy`, `cardTitle`, `titleField`, `swimlaneField`, `coverImageField`.
+  Calendar: `defaultView` (the spec's three-member enum) and `locale`.
+  
+  No renderer behaviour changes — every one of these keys was already read and already acted on;
+  what changes is that authoring tools can now discover them and the save gate agrees with the
+  validator. Both tags of each block now spread ONE shared `inputs` list, so the two published
+  surfaces cannot drift apart by hand-copy.
+- 289d146: `object-calendar` / `view:calendar` now DECLARE the last three spec-carried keys the renderer
+  already honoured — `data`, `staticData` and `loading` — so the html tier stops reporting working
+  metadata as `unknown-prop`. Each declared description names the POSITION the key is honoured at:
+  `data` replaces the calendar's own query, `staticData` is read below `data` and above `objectName`,
+  and `loading` is honoured only alongside an array `data` (objectui#8314, slice 2b of
+  objectui#8201). Every `object-calendar` key the spec declares is now discoverable.
+- 5058336: `object-calendar` is taught with its `calendar` block, not with flat field-name keys (objectstack-ai/objectui#8831).
+  
+  `@objectstack/spec` refuses `startDateField`, `endDateField`, `titleField`, `colorField` and `allDayField` written flat on an `object-calendar` node, and its diagnostic prescribes `calendar: { startDateField, endDateField, titleField, colorField, allDayField }`. Since 17.5.0 the spec's `CalendarConfigSchema` declares all five, `allDayField` included. objectui's published faces still taught the flat spelling as something to write, so an author who followed them was refused at publish.
+  
+  - `@object-ui/plugin-calendar`: both `object-calendar` examples in the README write the five keys inside `calendar`, and the README says what the flat spelling is: the runtime handoff `ObjectView` and `ListView` emit, which `getCalendarConfig` reads only when the node has no `calendar` block. The five-key sentence for `calendar-view` stays and now says it is about that element: `CalendarViewSchema` has no `calendar` block, so the flat keys are its only spelling.
+  - `@object-ui/types`: the `.describe()` text and the TypeScript docblocks of `ObjectCalendarSchema`'s five flat members call them the read-only handoff and point at `calendar.KEY`. The `calendar` member's text calls the block the authored spelling. The `allDayField` member of the `calendar` block no longer calls the key objectui-local, because 17.5.0 declares it.
+  
+  Descriptions and documentation only. No accept set moves: the flat members stay declared on both faces, with the same types, because the renderer still reads them.
+- 708f271: fix(plugin-calendar): the month gridcell's accessible name follows the resolved locale
+  
+  `MonthView`'s day gridcell built its `aria-label` with
+  `toLocaleDateString("default", …)` — the literal `"default"` means the *machine's*
+  locale — while the weekday column headers one row above were already formatted with
+  the component's resolved `locale`. A screen-reader user on a non-`en` session
+  therefore heard the column headers in their own language and every date in whatever
+  locale the runtime happened to be set to.
+  
+  Both branches of that label (with events and without) now use the same resolved
+  `locale` the headers use. No locale pack, key or translation is involved — this is
+  which tag the `Intl` call is handed.
+- 76ae729: `README.md`'s "Schema API / CalendarView" block described a `CalendarViewSchema`
+  that does not exist. Measured against the interface itself
+  (`packages/types/src/complex.ts`) and its zod mirror: `events` — the schema's
+  only required key besides `type` — was published as `events?`, so a reader
+  following the README omits it and TypeScript rejects the node; `defaultDate` was
+  `string` where the schema says `string | Date`; and `onDateClick` was listed as a
+  schema key when it is a `CalendarViewProps` **component** prop, sending readers
+  to a different package's surface for a key `calendar-view` does not have (the
+  schema's key is `onDateChange`). The block also listed 6 of the schema's 13 keys
+  with nothing saying it was a summary (objectui#5045).
+  
+  The block now carries the requiredness the schema declares, names itself a
+  partial summary of `CalendarViewSchema`, and adds the author-facing
+  `defaultView` / `view` / `views` / `editable` / `date`. It also states plainly
+  what the registered `calendar-view` renderer actually reads — it builds events
+  from the node's `data` array and drops an authored `events` key (objectui#4433) —
+  so the corrected requiredness does not itself become a new wrong instruction.
+  
+  This is a documentation fix to a file `plugin-calendar` publishes to npm, which
+  is why it carries a version: the npm landing page only picks up the correction
+  on a release. No behaviour, export, type, or `dist` byte changes. The pin test
+  added alongside it publishes nothing.
+- bc5870c: fix(plugin-calendar): a record with no date is no longer placed on today
+  
+  `ObjectCalendar` mapped a record whose declared `startDateField` carried no
+  value to `new Date()` — the current moment — so it rendered on today's cell as
+  an ordinary event, indistinguishable from a real one. The `isNaN` guard six
+  lines below could not catch it by construction: a no-argument `new Date()` is
+  always valid, so the absent-value case became a well-formed lie *before* the
+  check that would have caught it.
+  
+  The fabricating arm is deleted. Such records now leave the grid entirely and
+  appear in a collapsed "Unscheduled (N)" area below the calendar — a visible
+  count and an expandable list, with no invented date and no scheduling UI. The
+  `isNaN` filter keeps its original job for values that are present but
+  unparseable: absent and malformed stay two distinguishable outcomes.
+  `allDay: !endDate` now applies only to records that have a start, so a record
+  with no dates at all is unscheduled rather than silently all-day; a record with
+  a start and no end still renders all-day exactly as before.
+  
+  Adds `calendar.unscheduled` to all ten locale packs.
+- f47d94c: `@object-ui/plugin-calendar` now exports the `CalendarView` component's runtime event
+  type as **`CalendarViewEvent`**, and keeps `CalendarEvent` as a **`@deprecated` alias**
+  of it. **Non-breaking:** the alias is a working re-export denoting the same type, so
+  code importing `CalendarEvent` from this package keeps compiling unchanged — nothing is
+  removed and no behaviour changes.
+  
+  Why: `@object-ui/types` exports its own `CalendarEvent`, the AUTHORING event
+  (`id: string`, `start` / `end` accept ISO strings with `end` required, plus
+  `description`), while this package's was the runtime event (`id: string | number`,
+  `start: Date`, `end?: Date`). Neither is assignable to the other, and IDE auto-import
+  chose between the two identical names essentially at random — the wrong pick surfaced as
+  a remote `TS2322` about `Date` rather than as a wrong import, which is how this package's
+  own README example stayed uncompilable through an earlier import-path fix. The authoring
+  type keeps the canonical `CalendarEvent` name; the runtime type gets the self-describing
+  one (objectui#5044, following the `ObjectCalendarProps` -> `ObjectCalendarComponentProps`
+  rename in objectui#4650).
+  
+  Write `CalendarViewEvent` in new code.
+- 065bba7: `CalendarViewSchema` (TS interface and zod mirror) converges on the registered
+  `calendar-view` renderer's measured read set (objectui#5667, maintainer ruling
+  option A — the renderer is authoritative).
+  
+  **Breaking for consumers of the published type** (deliberate; per-repo policy
+  breaking changes ship as `minor` — the fixed group's `major` tracks
+  `@objectstack`):
+  
+  - Nine inert keys are retired: `events` (the interface's only required key,
+    which the renderer deliberately drops — objectui#4433), `defaultView`,
+    `defaultDate`, `date`, `views`, `editable`, `onEventCreate`,
+    `onEventUpdate`, `onDateChange`. None had a read site on the authored-node
+    path and no measured app authors them (ADR-0049 enforce-or-remove).
+  - The type now declares what the renderer actually reads: `data`, `titleField`,
+    `startDateField`, `endDateField`, `allDayField`, `colorField`, `view`,
+    `currentDate`, `allowCreate`, `className`, plus the two host-only function
+    hatches it forwards (`onEventClick`, `onViewChange`).
+  - Practical radius, measured: `BaseSchema` carries an index signature and the
+    zod `BaseSchema` is `.passthrough()`, so nodes still authoring retired keys
+    neither fail to compile nor get rejected at validation — they are simply no
+    longer declared, documented, or type-checked. The material accept change is
+    that zod no longer **requires** `events`: a `{ "type": "calendar-view" }`
+    node without it now validates (previously the one key validation demanded
+    was the one key guaranteed to do nothing).
+  
+  Runtime renderer behaviour is unchanged. `@object-ui/plugin-calendar`'s README
+  and `content/docs/api/schema-reference.md` are repaired to the converged
+  surface in the same change, so no copy of the old contradiction survives.
+- f760064: Localize every accessible name `CalendarView` authors itself.
+  
+  The component hard-coded the accessible names of its own landmarks and controls
+  in English, so no locale pack could reach them. A screen-reader user on a
+  translated console heard "Calendar" and "Calendar grid" — the only names those
+  two landmarks have — plus the toolbar buttons and both resize grips, in English,
+  while every sighted string beside them was translated.
+  
+  All of them now resolve through the `createSafeTranslation` hook the component
+  already used for its visible copy, and the keys land in all ten locale packs
+  under `calendar.a11y`. Two of the repaired strings were English frames wrapped
+  around already-localized data (the current-date button and the day gridcell's
+  event count); those are now pack-owned sentences whose translations can put the
+  date and the count where each language's grammar wants them, and the gridcell's
+  count is a plural family with a base key so the categories a pack does not
+  enumerate resolve in its own language rather than falling through to English.
+- fb336df: Move `lucide-react` from `^1.31.0` to `^1.43.0` in every package that declares it, and
+  repair what the jump breaks, so icons resolved from a STRING keep drawing a glyph.
+  
+  Measured once against the installed 1.43.0 artifact when this change was made; nothing in
+  the repository re-derives these readings. Across the jump lucide removes no runtime export,
+  no public type name and no `lucide-react/dynamic.mjs` name, and every name this repository
+  imports from `lucide-react` resolves. Exactly one key leaves the runtime `icons` record:
+  `Trash2`, retired in favour of `trash`.
+  
+  What a user sees change:
+  
+  - Icons the lazy icon seam draws (`resolveIcon`, objectui#9251) get their path data again.
+    lucide 1.43.0 icon modules export their path data inside `__iconData` and no longer
+    export `__iconNode`; the seam now reads both. Reading only `__iconNode` against 1.43.0
+    leaves every such glyph an empty box, with nothing thrown or logged.
+  - `DetailView`'s delete action and three schema-catalog examples spell their icon
+    `trash`, not `trash-2`, so they keep resolving. The glyph is unchanged: 1.43.0's `trash`
+    path data is byte-identical to the `trash-2` path data of 1.31.0 and 1.35.0. Anything
+    that already authored `trash` now draws that same artwork, because lucide moved it under
+    the `trash` name; a few other glyphs were also redrawn upstream.
+  - Icons imported as COMPONENTS carry lucide 1.43.0's own classes: one class per declared
+    alias (a spinner renders `class="lucide lucide-loader-circle lucide-loader-2 ..."`), and
+    no longer the class lucide used to derive from the PascalCase key where that differs
+    (`ArrowDown01` no longer carries `lucide-arrow-down01`). The canonical
+    `lucide-<icon name>` class is still there, so a `.lucide-loader-circle` selector still
+    matches.
+  - Icons resolved from a STRING through the seam keep the classes they had: `lucide`, the
+    canonical `lucide-<icon name>` class and the key-derived class. They do not carry
+    lucide's per-alias classes. That is a maintainer ruling (objectui#8941, option C): the
+    alias list lives only inside each lazily loaded icon module, and it was not moved into
+    the eager name list. A selector that targets an alias class matches a component-imported
+    icon and not a string-resolved one. This also dates the example in the objectui#9251
+    entry: `trash-2` no longer resolves as a string, so no seam-drawn glyph carries
+    `lucide-trash2 lucide-trash-2`; a digit-bearing name that still resolves, such as
+    `arrow-down-0-1`, carries `lucide-arrow-down01 lucide-arrow-down-0-1`.
+- Updated dependencies [cd2cb41]
+- Updated dependencies [7b10bef]
+- Updated dependencies [97abedc]
+- Updated dependencies [b46c58f]
+- Updated dependencies [a507334]
+- Updated dependencies [ad694ac]
+- Updated dependencies [6f96fca]
+- Updated dependencies [afb2284]
+- Updated dependencies [3ac2de8]
+- Updated dependencies [0aacecc]
+- Updated dependencies [28b0658]
+- Updated dependencies [63f4f92]
+- Updated dependencies [777fca2]
+- Updated dependencies [c131d9e]
+- Updated dependencies [5f00ff4]
+- Updated dependencies [c9e073a]
+- Updated dependencies [7b395d8]
+- Updated dependencies [0879812]
+- Updated dependencies [588380d]
+- Updated dependencies [8cedb0d]
+- Updated dependencies [6ce001a]
+- Updated dependencies [162621b]
+- Updated dependencies [b06c3de]
+- Updated dependencies [0d379f5]
+- Updated dependencies [4c6f549]
+- Updated dependencies [6cc910b]
+- Updated dependencies [061f5e8]
+- Updated dependencies [879ecac]
+- Updated dependencies [c2dabf0]
+- Updated dependencies [2dd4d3f]
+- Updated dependencies [e686f4d]
+- Updated dependencies [4ab4f1b]
+- Updated dependencies [fa5fbd9]
+- Updated dependencies [5f44cc6]
+- Updated dependencies [b57107d]
+- Updated dependencies [e3ea4f9]
+- Updated dependencies [fd6f5da]
+- Updated dependencies [bb5d4ee]
+- Updated dependencies [dc666f7]
+- Updated dependencies [3335767]
+- Updated dependencies [8b1f066]
+- Updated dependencies [af243c1]
+- Updated dependencies [cff4b77]
+- Updated dependencies [961ceaa]
+- Updated dependencies [f3f4e4c]
+- Updated dependencies [a05c350]
+- Updated dependencies [1dbb993]
+- Updated dependencies [2b5f509]
+- Updated dependencies [808f339]
+- Updated dependencies [6cf5999]
+- Updated dependencies [274e14a]
+- 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 [cdefa2a]
+- Updated dependencies [cc4366d]
+- Updated dependencies [0961d5e]
+- Updated dependencies [6276478]
+- Updated dependencies [5e67837]
+- Updated dependencies [ff14e29]
+- Updated dependencies [9b28151]
+- Updated dependencies [64563a9]
+- Updated dependencies [1a5003f]
+- Updated dependencies [09ab32b]
+- Updated dependencies [8acc51b]
+- Updated dependencies [ea9d17f]
+- Updated dependencies [45362a3]
+- Updated dependencies [2a943bf]
+- Updated dependencies [d999617]
+- Updated dependencies [93a689d]
+- Updated dependencies [4357a27]
+- Updated dependencies [e5f4343]
+- Updated dependencies [3261e64]
+- Updated dependencies [f5178a2]
+- Updated dependencies [2ad3671]
+- Updated dependencies [8740e86]
+- Updated dependencies [d22b37b]
+- Updated dependencies [9cbe4db]
+- Updated dependencies [1daf477]
+- Updated dependencies [3d614ea]
+- Updated dependencies [6c2f3c5]
+- Updated dependencies [fb13e85]
+- Updated dependencies [c2d8659]
+- Updated dependencies [e0f8202]
+- Updated dependencies [ac2d6f1]
+- Updated dependencies [9fbbb17]
+- Updated dependencies [c3a26cc]
+- Updated dependencies [a66e58e]
+- Updated dependencies [d89492c]
+- Updated dependencies [9a5f998]
+- Updated dependencies [9327397]
+- Updated dependencies [17cc3a3]
+- Updated dependencies [02e6d36]
+- Updated dependencies [4758b33]
+- Updated dependencies [4758b33]
+- Updated dependencies [8848ce4]
+- Updated dependencies [f905090]
+- Updated dependencies [9c78ebe]
+- Updated dependencies [9c78ebe]
+- Updated dependencies [12809a5]
+- Updated dependencies [9c78ebe]
+- Updated dependencies [12809a5]
+- Updated dependencies [7afc81d]
+- Updated dependencies [f9c06ef]
+- Updated dependencies [93a5585]
+- Updated dependencies [5ad3b88]
+- Updated dependencies [21eb61a]
+- Updated dependencies [f9d772b]
+- Updated dependencies [97b6c21]
+- Updated dependencies [26ca2ad]
+- Updated dependencies [41ae65b]
+- Updated dependencies [184cfe1]
+- Updated dependencies [baac95a]
+- Updated dependencies [13220af]
+- Updated dependencies [29b45f6]
+- Updated dependencies [39b8d51]
+- Updated dependencies [17b323e]
+- Updated dependencies [b956e69]
+- Updated dependencies [33e58d8]
+- Updated dependencies [256b4c9]
+- Updated dependencies [c5ec15c]
+- Updated dependencies [fec3b1a]
+- Updated dependencies [b8e0941]
+- Updated dependencies [0c50f18]
+- Updated dependencies [285e36b]
+- Updated dependencies [1dae95a]
+- Updated dependencies [e32dae1]
+- Updated dependencies [30b11ad]
+- Updated dependencies [4aebea0]
+- Updated dependencies [f976774]
+- Updated dependencies [3d6badf]
+- Updated dependencies [25cb364]
+- Updated dependencies [a60539b]
+- Updated dependencies [de1b879]
+- Updated dependencies [c6678b1]
+- Updated dependencies [0638322]
+- Updated dependencies [e3782d2]
+- Updated dependencies [db0beb2]
+- Updated dependencies [997ce38]
+- Updated dependencies [ae0b9d3]
+- Updated dependencies [ad1785c]
+- Updated dependencies [3b469c8]
+- Updated dependencies [990a2d6]
+- Updated dependencies [37140f4]
+- Updated dependencies [1c84036]
+- Updated dependencies [1c84036]
+- Updated dependencies [6650259]
+- Updated dependencies [4f8b7f8]
+- Updated dependencies [9e6619f]
+- Updated dependencies [f6ae5e2]
+- Updated dependencies [eb97ce6]
+- 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 [244d516]
+- Updated dependencies [deca847]
+- Updated dependencies [ac15833]
+- Updated dependencies [ac15833]
+- Updated dependencies [e2dffc9]
+- Updated dependencies [328abeb]
+- Updated dependencies [dd0d78f]
+- Updated dependencies [24d3e65]
+- Updated dependencies [95a7c8d]
+- Updated dependencies [e227156]
+- Updated dependencies [cc4e476]
+- Updated dependencies [92970c4]
+- Updated dependencies [d570eaa]
+- Updated dependencies [4b742f4]
+- Updated dependencies [42687ba]
+- Updated dependencies [6cd8f66]
+- Updated dependencies [24a0f14]
+- Updated dependencies [797a30f]
+- Updated dependencies [27ae632]
+- Updated dependencies [b4075c0]
+- Updated dependencies [9b85600]
+- Updated dependencies [e327c89]
+- Updated dependencies [2eaf5be]
+- Updated dependencies [bf7ab35]
+- Updated dependencies [99878d8]
+- Updated dependencies [3c13675]
+- Updated dependencies [63ab761]
+- Updated dependencies [0eb9f36]
+- Updated dependencies [ae582b7]
+- Updated dependencies [62d6f56]
+- Updated dependencies [51c2949]
+- Updated dependencies [a4b017e]
+- Updated dependencies [8732846]
+- Updated dependencies [559a2e2]
+- 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 [c021b35]
+- Updated dependencies [f61dab1]
+- Updated dependencies [b0a05dd]
+- Updated dependencies [dd5ff19]
+- Updated dependencies [54997ff]
+- Updated dependencies [81f8498]
+- Updated dependencies [a782fa7]
+- Updated dependencies [1d6a23d]
+- Updated dependencies [0645133]
+- Updated dependencies [76e9df0]
+- Updated dependencies [0ecaa7d]
+- Updated dependencies [b24f93a]
+- Updated dependencies [6158e4c]
+- Updated dependencies [cff8641]
+- Updated dependencies [3f61eef]
+- Updated dependencies [c27b575]
+- Updated dependencies [84b275c]
+- Updated dependencies [0e6e76b]
+- Updated dependencies [bf43afa]
+- Updated dependencies [385ebc5]
+- Updated dependencies [858eafb]
+- Updated dependencies [a8c5509]
+- Updated dependencies [c2a8d23]
+- Updated dependencies [f4ed238]
+- Updated dependencies [0ffc423]
+- Updated dependencies [3cc4fe5]
+- Updated dependencies [cd5b19a]
+- Updated dependencies [cd5b19a]
+- Updated dependencies [17dc167]
+- Updated dependencies [20d23be]
+- Updated dependencies [20d23be]
+- Updated dependencies [2e3da72]
+- Updated dependencies [1263e40]
+- Updated dependencies [e6bc087]
+- Updated dependencies [9419df1]
+- Updated dependencies [8bab157]
+- Updated dependencies [a7557a7]
+- Updated dependencies [7d074ba]
+- Updated dependencies [6158e4c]
+- Updated dependencies [6158e4c]
+- Updated dependencies [52aad5c]
+- Updated dependencies [18d1a0a]
+- Updated dependencies [e420df3]
+- Updated dependencies [7fed09d]
+- Updated dependencies [58da8ae]
+- Updated dependencies [a8b9889]
+- Updated dependencies [138ad45]
+- Updated dependencies [138ad45]
+- Updated dependencies [5262f7d]
+- Updated dependencies [6aa029b]
+- Updated dependencies [2124d04]
+- Updated dependencies [be52115]
+- Updated dependencies [770cc5b]
+- Updated dependencies [1a88ce2]
+- Updated dependencies [a1a44d6]
+- Updated dependencies [e0a9c67]
+- Updated dependencies [5638529]
+- Updated dependencies [5638529]
+- Updated dependencies [d0fba91]
+- 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 [55d18c6]
+- Updated dependencies [c4ab6d0]
+- Updated dependencies [0e9058b]
+- Updated dependencies [c4ab6d0]
+- Updated dependencies [5988b6b]
+- Updated dependencies [6158e4c]
+- Updated dependencies [00ccdf7]
+- Updated dependencies [9d9ed54]
+- Updated dependencies [4a1adb7]
+- Updated dependencies [4a1adb7]
+- Updated dependencies [4a1adb7]
+- Updated dependencies [50c73fe]
+- Updated dependencies [ca3de72]
+- Updated dependencies [83e3f83]
+- Updated dependencies [401611b]
+- Updated dependencies [2c0ddf2]
+- Updated dependencies [4abc0aa]
+- Updated dependencies [f560ded]
+- Updated dependencies [f560ded]
+- Updated dependencies [2b188fa]
+- Updated dependencies [b654d4e]
+- 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 [fc7db05]
+- Updated dependencies [9ed8d0f]
+- Updated dependencies [c73cdb5]
+- Updated dependencies [6f5719e]
+- Updated dependencies [b34cc14]
+- Updated dependencies [ab18797]
+- Updated dependencies [d0097af]
+- Updated dependencies [432882b]
+- Updated dependencies [64dae8e]
+- Updated dependencies [b06e374]
+- Updated dependencies [06a8af5]
+- Updated dependencies [6a91586]
+- Updated dependencies [a04d7c6]
+- Updated dependencies [5ccc500]
+- Updated dependencies [f3c2bb0]
+- Updated dependencies [978507b]
+- Updated dependencies [778138e]
+- Updated dependencies [9801765]
+- Updated dependencies [9cebfca]
+- Updated dependencies [460575f]
+- Updated dependencies [d796c8d]
+- Updated dependencies [594704f]
+- Updated dependencies [d3995fe]
+- Updated dependencies [1b1d772]
+- Updated dependencies [d88e20f]
+- Updated dependencies [f66072d]
+- Updated dependencies [2d7304d]
+- Updated dependencies [636b236]
+- Updated dependencies [4172589]
+- Updated dependencies [d6d8fb9]
+- Updated dependencies [64d624d]
+- Updated dependencies [053fdc8]
+- Updated dependencies [41b7ce3]
+- Updated dependencies [ae476b8]
+- Updated dependencies [39f4309]
+- Updated dependencies [95bad12]
+- Updated dependencies [d2fb6ef]
+- Updated dependencies [7cd3987]
+- Updated dependencies [ee3b878]
+- Updated dependencies [e304a4e]
+- Updated dependencies [fda49e5]
+- Updated dependencies [490d9a9]
+- Updated dependencies [1117414]
+- Updated dependencies [6d63cd0]
+- Updated dependencies [fc62bb4]
+- Updated dependencies [41df893]
+- Updated dependencies [0cba1b7]
+- Updated dependencies [7c96c94]
+- Updated dependencies [4da5109]
+- Updated dependencies [00f3eb5]
+- Updated dependencies [1ec291c]
+- Updated dependencies [453dbaa]
+- Updated dependencies [95f8704]
+- Updated dependencies [f8cdbf2]
+- Updated dependencies [69a2163]
+- Updated dependencies [24e027e]
+- Updated dependencies [2c3cd1b]
+- Updated dependencies [e176053]
+- Updated dependencies [e30ed15]
+- Updated dependencies [90665e0]
+- Updated dependencies [8d3a529]
+- Updated dependencies [5ac2e2c]
+- Updated dependencies [194fae1]
+- Updated dependencies [63d54dd]
+- Updated dependencies [7e19d03]
+- Updated dependencies [b08b7eb]
+- Updated dependencies [1e946c9]
+- Updated dependencies [546ddf7]
+- Updated dependencies [864154e]
+- Updated dependencies [b023625]
+- Updated dependencies [75bd83d]
+- Updated dependencies [44d075b]
+- Updated dependencies [40c479a]
+- Updated dependencies [b4393e5]
+- 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 [6fd2cf7]
+- Updated dependencies [5fa06c4]
+- Updated dependencies [52a43de]
+- Updated dependencies [195052f]
+- Updated dependencies [e4559d1]
+- Updated dependencies [2c71482]
+- Updated dependencies [129bcc5]
+- Updated dependencies [d3005f7]
+- Updated dependencies [1e7fe0a]
+- Updated dependencies [a26b9e4]
+- Updated dependencies [5ef9c4f]
+- Updated dependencies [46f0bb4]
+- Updated dependencies [06b82b8]
+- Updated dependencies [8ec11e1]
+- Updated dependencies [6f81384]
+- Updated dependencies [22ba927]
+- Updated dependencies [f8c70f4]
+- Updated dependencies [5d3a2d1]
+- Updated dependencies [8f1d995]
+- Updated dependencies [b362c1b]
+- Updated dependencies [f9c34df]
+- Updated dependencies [dddb942]
+- Updated dependencies [00c665e]
+- Updated dependencies [29754cf]
+- Updated dependencies [d7de534]
+- Updated dependencies [3c2b6f7]
+- Updated dependencies [6e88630]
+- Updated dependencies [b84dc18]
+- Updated dependencies [ac8abb0]
+- Updated dependencies [9d86e1d]
+- Updated dependencies [3a5817f]
+- Updated dependencies [99a3c2d]
+- Updated dependencies [5961030]
+- Updated dependencies [f24de8b]
+- Updated dependencies [c8ea8af]
+- Updated dependencies [9602dc8]
+- Updated dependencies [3777538]
+- Updated dependencies [3190414]
+- Updated dependencies [4e480f5]
+- Updated dependencies [38a123c]
+- Updated dependencies [299102e]
+- Updated dependencies [30c73cd]
+- Updated dependencies [830ed58]
+- Updated dependencies [d7acad6]
+- Updated dependencies [45a9aeb]
+- Updated dependencies [713db46]
+- Updated dependencies [c71e14d]
+- Updated dependencies [bf3a03c]
+- Updated dependencies [cb55718]
+- Updated dependencies [748494b]
+- Updated dependencies [5967be0]
+- Updated dependencies [831be72]
+- Updated dependencies [29cb85b]
+- Updated dependencies [3e028c8]
+- Updated dependencies [d0889e2]
+- Updated dependencies [ce503e5]
+- Updated dependencies [f20dcf0]
+- Updated dependencies [12402a9]
+- Updated dependencies [aff3d7a]
+- Updated dependencies [4ca30d0]
+- Updated dependencies [7a5da14]
+- Updated dependencies [fff9645]
+- Updated dependencies [9c3b7ce]
+- Updated dependencies [2c1c967]
+- Updated dependencies [9486ac6]
+- Updated dependencies [9486ac6]
+- Updated dependencies [4d5f9b4]
+- Updated dependencies [d6ceb8d]
+- Updated dependencies [dc4365c]
+- Updated dependencies [e321d52]
+- Updated dependencies [969ba84]
+- Updated dependencies [4c68077]
+- Updated dependencies [7977ff9]
+- Updated dependencies [3beef6d]
+- Updated dependencies [06b8c42]
+- Updated dependencies [46b9bc9]
+- Updated dependencies [45ac2cb]
+- Updated dependencies [b97790a]
+- Updated dependencies [dbd5194]
+- Updated dependencies [7c9b044]
+- Updated dependencies [d47de51]
+- Updated dependencies [3fe6463]
+- Updated dependencies [b392674]
+- Updated dependencies [4f3a1e2]
+- Updated dependencies [31ab372]
+- Updated dependencies [846889b]
+- Updated dependencies [2acd8e1]
+- Updated dependencies [26896c6]
+- Updated dependencies [a439e16]
+- Updated dependencies [67fc3b0]
+- Updated dependencies [33a3b3c]
+- Updated dependencies [b87f15b]
+- Updated dependencies [9409eb9]
+- Updated dependencies [045d20b]
+- Updated dependencies [a2d2515]
+- Updated dependencies [c18d099]
+- Updated dependencies [adb2a86]
+- Updated dependencies [03380aa]
+- Updated dependencies [4562ea5]
+- Updated dependencies [3619792]
+- Updated dependencies [3561bd2]
+- Updated dependencies [bf97b98]
+- Updated dependencies [320374d]
+- Updated dependencies [b0d308d]
+- Updated dependencies [40f34b4]
+- Updated dependencies [bd0376d]
+- 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 [c4326fe]
+- Updated dependencies [4dfdcc3]
+- Updated dependencies [6a449fc]
+- Updated dependencies [446d93d]
+- Updated dependencies [ecd9cb2]
+- Updated dependencies [98d4108]
+- Updated dependencies [0e3b3be]
+- Updated dependencies [a29ae2d]
+- Updated dependencies [220c18d]
+- Updated dependencies [eeb6c2f]
+- Updated dependencies [00d3f09]
+- Updated dependencies [4388f71]
+- Updated dependencies [0b1ac58]
+- Updated dependencies [c93b4d5]
+- Updated dependencies [c1fe272]
+- Updated dependencies [3cab570]
+- Updated dependencies [8ad218d]
+- Updated dependencies [3e41187]
+- Updated dependencies [5f78953]
+- Updated dependencies [639114c]
+- Updated dependencies [639114c]
+- Updated dependencies [1490691]
+- Updated dependencies [1f31d3a]
+- Updated dependencies [d1842ab]
+- Updated dependencies [854cba3]
+- Updated dependencies [78ca238]
+- Updated dependencies [d8ec8d6]
+- Updated dependencies [351eb31]
+- Updated dependencies [866cd1d]
+- Updated dependencies [20c04b2]
+- Updated dependencies [01c9023]
+- Updated dependencies [48c19bd]
+- Updated dependencies [a6d8b8d]
+- Updated dependencies [4b5bb95]
+- Updated dependencies [b652514]
+- Updated dependencies [adbda1b]
+- Updated dependencies [adbda1b]
+- Updated dependencies [8952395]
+- Updated dependencies [e2b3826]
+- Updated dependencies [a338037]
+- Updated dependencies [0348bc9]
+- Updated dependencies [e8c553b]
+- Updated dependencies [2e32ed4]
+- Updated dependencies [3ed3eec]
+- Updated dependencies [7c3df8f]
+- Updated dependencies [a4514e8]
+- Updated dependencies [6411def]
+- Updated dependencies [db3896c]
+- Updated dependencies [b9f5ff1]
+- Updated dependencies [e75f4c9]
+- Updated dependencies [19f1639]
+- Updated dependencies [4704aa4]
+- Updated dependencies [47547d0]
+- Updated dependencies [1bee5d0]
+- Updated dependencies [63a8828]
+- Updated dependencies [b61d7d8]
+- Updated dependencies [858cd72]
+- Updated dependencies [cfc9b6d]
+- Updated dependencies [dc0a60b]
+- Updated dependencies [554f2b6]
+- Updated dependencies [72f55c9]
+- Updated dependencies [26e06d7]
+- Updated dependencies [669d71b]
+- Updated dependencies [ed27d7c]
+- Updated dependencies [52c8cf7]
+- Updated dependencies [2ceb43a]
+- Updated dependencies [7cdd2b9]
+- Updated dependencies [52c8cf7]
+- Updated dependencies [3399704]
+- Updated dependencies [02fe257]
+- Updated dependencies [71a4a53]
+- Updated dependencies [7bf244b]
+- Updated dependencies [f0bb9fa]
+- Updated dependencies [81a2eb1]
+- Updated dependencies [caa0cd3]
+- Updated dependencies [caa0cd3]
+- Updated dependencies [20cb8db]
+- Updated dependencies [25c7d58]
+- Updated dependencies [00d2fa6]
+- Updated dependencies [77b2a18]
+- Updated dependencies [c6198c2]
+- Updated dependencies [721d1e0]
+- Updated dependencies [c2f0f48]
+- Updated dependencies [1237ae4]
+- Updated dependencies [2f61238]
+- Updated dependencies [51eb515]
+- Updated dependencies [c354ce5]
+- Updated dependencies [8fe8e5c]
+- Updated dependencies [feac439]
+- Updated dependencies [9ae871d]
+- Updated dependencies [efbd566]
+- Updated dependencies [2a5bf45]
+- Updated dependencies [9587fc9]
+- Updated dependencies [e62c44e]
+- Updated dependencies [daf9d57]
+- Updated dependencies [fe8f451]
+- Updated dependencies [23b9958]
+- Updated dependencies [c15d7ec]
+- Updated dependencies [5d0876c]
+- Updated dependencies [f7ace0a]
+- Updated dependencies [b041b9c]
+- Updated dependencies [ce2aaef]
+- Updated dependencies [544ecba]
+- Updated dependencies [2ce2612]
+- 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 [c14d3a0]
+- Updated dependencies [a137d0c]
+- Updated dependencies [caf477f]
+- Updated dependencies [f6375da]
+- Updated dependencies [967e5d8]
+- Updated dependencies [c907a9c]
+- Updated dependencies [a4611b3]
+- Updated dependencies [20316ba]
+- Updated dependencies [d3499b3]
+- Updated dependencies [91f9276]
+- Updated dependencies [309c75e]
+- Updated dependencies [c9f9bae]
+- Updated dependencies [18897a4]
+- Updated dependencies [8b7ea39]
+- Updated dependencies [a915064]
+- 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 [d1bebb0]
+- Updated dependencies [95bf128]
+- Updated dependencies [335abea]
+- Updated dependencies [edea22a]
+- 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 [1cfdff8]
+- Updated dependencies [e1c27e4]
+- Updated dependencies [8c8da45]
+- Updated dependencies [8cd8eb5]
+- Updated dependencies [cf1d29e]
+- Updated dependencies [1bd79c8]
+- Updated dependencies [af9e957]
+- Updated dependencies [b1030c7]
+- Updated dependencies [c974edf]
+- Updated dependencies [592402e]
+- Updated dependencies [ad852b6]
+- Updated dependencies [6778809]
+- Updated dependencies [7fb22a1]
+- Updated dependencies [ad66d79]
+- Updated dependencies [0758bd8]
+- Updated dependencies [ee4d19f]
+- Updated dependencies [37149ec]
+- Updated dependencies [496d31d]
+- Updated dependencies [0ea7054]
+- Updated dependencies [9a853f2]
+- Updated dependencies [cb847fd]
+- Updated dependencies [ee70287]
+- Updated dependencies [3e98e13]
+- Updated dependencies [a695f50]
+- 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 [6e9a3d4]
+- Updated dependencies [4a292d2]
+- Updated dependencies [5323168]
+- Updated dependencies [841dd2b]
+- Updated dependencies [3014fc0]
+- Updated dependencies [dacb402]
+- Updated dependencies [846cec0]
+- Updated dependencies [91facae]
+- Updated dependencies [b38014e]
+- Updated dependencies [e2feb13]
+- Updated dependencies [474797d]
+- Updated dependencies [704e695]
+- Updated dependencies [9dcc545]
+- Updated dependencies [d7fecfb]
+- Updated dependencies [c13d39e]
+- Updated dependencies [a407bd6]
+- Updated dependencies [317dbce]
+- Updated dependencies [309728c]
+- Updated dependencies [e6ec217]
+- Updated dependencies [aa08d7e]
+- Updated dependencies [3a43a15]
+- Updated dependencies [868e825]
+- Updated dependencies [f76f436]
+- Updated dependencies [ce45a03]
+- Updated dependencies [7cf6f38]
+- Updated dependencies [fd9c50a]
+- Updated dependencies [421544b]
+- Updated dependencies [5cc8c28]
+- Updated dependencies [fb01022]
+- Updated dependencies [e9d9212]
+- Updated dependencies [ecfb693]
+- Updated dependencies [40a7c53]
+- Updated dependencies [abc1b18]
+- Updated dependencies [81a51db]
+- Updated dependencies [67749c7]
+- Updated dependencies [507b61b]
+- Updated dependencies [512c84b]
+- Updated dependencies [c300267]
+- Updated dependencies [fb3a101]
+- Updated dependencies [d4733f2]
+- Updated dependencies [7c9145f]
+- Updated dependencies [1570eac]
+- 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 [cc00c59]
+- Updated dependencies [676f677]
+- Updated dependencies [f95b140]
+- Updated dependencies [541ce4e]
+- Updated dependencies [6479086]
+- Updated dependencies [d79f525]
+- Updated dependencies [d1865d2]
+- Updated dependencies [ab77513]
+- Updated dependencies [55ba3ff]
+- Updated dependencies [0b138da]
+- Updated dependencies [f1190b0]
+- Updated dependencies [561abef]
+- Updated dependencies [ef52001]
+- Updated dependencies [6a4680b]
+- Updated dependencies [c3a4273]
+- Updated dependencies [abf710d]
+- Updated dependencies [093af32]
+- Updated dependencies [6df26f0]
+- Updated dependencies [1bd1be7]
+- Updated dependencies [d234fa9]
+- Updated dependencies [adf5812]
+- Updated dependencies [e36acd4]
+- Updated dependencies [5058336]
+- Updated dependencies [2f6b2bf]
+- Updated dependencies [2028b31]
+- Updated dependencies [16a1a51]
+- Updated dependencies [63601ab]
+- Updated dependencies [c372b29]
+- Updated dependencies [152f0a7]
+- Updated dependencies [8693b85]
+- Updated dependencies [e82dad1]
+- Updated dependencies [58b7b3d]
+- Updated dependencies [e77a003]
+- Updated dependencies [84defab]
+- Updated dependencies [681d3f1]
+- Updated dependencies [969d4f2]
+- Updated dependencies [88561fd]
+- Updated dependencies [f3bc481]
+- Updated dependencies [b79aac2]
+- Updated dependencies [93fc0e7]
+- Updated dependencies [0601af1]
+- Updated dependencies [a4b723f]
+- Updated dependencies [2b10ca0]
+- Updated dependencies [7db4a81]
+- Updated dependencies [19a0b0e]
+- Updated dependencies [526fc11]
+- Updated dependencies [f8e3e9a]
+- Updated dependencies [b9d47ec]
+- Updated dependencies [3b6bc69]
+- Updated dependencies [6214db6]
+- Updated dependencies [6732df4]
+- Updated dependencies [fe9e0d0]
+- Updated dependencies [63fb72c]
+- Updated dependencies [804831c]
+- Updated dependencies [9f5c017]
+- Updated dependencies [c271413]
+- Updated dependencies [279e48e]
+- Updated dependencies [4784bb3]
+- Updated dependencies [8700d6d]
+- Updated dependencies [8db2a0f]
+- Updated dependencies [689953a]
+- Updated dependencies [30443fb]
+- Updated dependencies [8d3dbb2]
+- Updated dependencies [efc1c9c]
+- Updated dependencies [7d6439c]
+- Updated dependencies [da45e6b]
+- Updated dependencies [7533465]
+- Updated dependencies [835f0f3]
+- Updated dependencies [6d5db7b]
+- Updated dependencies [a9d97be]
+- Updated dependencies [ed35b44]
+- Updated dependencies [e6040ef]
+- Updated dependencies [9ba7e9c]
+- Updated dependencies [729e851]
+- Updated dependencies [96919a4]
+- Updated dependencies [345e24a]
+- Updated dependencies [3bc1bb4]
+- Updated dependencies [20b507a]
+- Updated dependencies [2e471dc]
+- Updated dependencies [6748587]
+- Updated dependencies [be50942]
+- Updated dependencies [775e079]
+- Updated dependencies [7e8b3c0]
+- Updated dependencies [53374dc]
+- Updated dependencies [f6fb83f]
+- Updated dependencies [2049b03]
+- Updated dependencies [2bf34f7]
+- Updated dependencies [15b33ae]
+- Updated dependencies [7cbc724]
+- Updated dependencies [4a94c38]
+- Updated dependencies [7098eed]
+- Updated dependencies [3df7c5c]
+- Updated dependencies [fb91ac9]
+- Updated dependencies [fb91ac9]
+- Updated dependencies [641fb55]
+- Updated dependencies [8524372]
+- Updated dependencies [7cbefa5]
+- Updated dependencies [72d6587]
+- Updated dependencies [a272a4f]
+- Updated dependencies [55f39ee]
+- Updated dependencies [502eb58]
+- Updated dependencies [0ce32d5]
+- Updated dependencies [0970a0e]
+- Updated dependencies [e427e9c]
+- Updated dependencies [bbc9dc3]
+- Updated dependencies [02f1813]
+- Updated dependencies [1ef89c0]
+- Updated dependencies [ba0b61a]
+- Updated dependencies [ba0b61a]
+- Updated dependencies [ba0b61a]
+- Updated dependencies [ac716ff]
+- Updated dependencies [697aabc]
+- Updated dependencies [f0f3cd5]
+- Updated dependencies [ab856ed]
+- Updated dependencies [20f3e65]
+- Updated dependencies [bbba098]
+- Updated dependencies [87af769]
+- Updated dependencies [3be720e]
+- Updated dependencies [80a0ecd]
+- Updated dependencies [43c0d17]
+- Updated dependencies [c3df43a]
+- Updated dependencies [d16d0e9]
+- Updated dependencies [bbe57fd]
+- Updated dependencies [272a530]
+- Updated dependencies [462bafb]
+- Updated dependencies [1779e8d]
+- Updated dependencies [f7fcc2c]
+- Updated dependencies [f0f4d6c]
+- Updated dependencies [4128188]
+- Updated dependencies [b253c4e]
+- Updated dependencies [78a9c67]
+- Updated dependencies [4a7ef0d]
+- Updated dependencies [4598f6d]
+- Updated dependencies [dea17b4]
+- Updated dependencies [89bb77a]
+- Updated dependencies [06611e4]
+- Updated dependencies [44152c4]
+- Updated dependencies [3939545]
+- Updated dependencies [0ee6e31]
+- Updated dependencies [66abbde]
+- Updated dependencies [dc3893d]
+- Updated dependencies [1bbaa16]
+- Updated dependencies [6ee259a]
+- Updated dependencies [7649f43]
+- Updated dependencies [d0f52e4]
+- Updated dependencies [e708426]
+- Updated dependencies [33e1697]
+- Updated dependencies [3b6d53b]
+- Updated dependencies [a017617]
+- Updated dependencies [276d174]
+- Updated dependencies [2982ed9]
+- Updated dependencies [741864f]
+- Updated dependencies [a8198de]
+- Updated dependencies [0c789a4]
+- Updated dependencies [05a49f2]
+- Updated dependencies [b234a84]
+- Updated dependencies [a78cd37]
+- Updated dependencies [5ea623e]
+- Updated dependencies [dc49246]
+- Updated dependencies [5eabe86]
+- Updated dependencies [ca5d671]
+- Updated dependencies [32bf2d6]
+- Updated dependencies [ff0c384]
+- Updated dependencies [af4fb29]
+- Updated dependencies [c698a81]
+- Updated dependencies [ff5ef1c]
+- Updated dependencies [befd40c]
+- Updated dependencies [905913c]
+- Updated dependencies [9a97800]
+- Updated dependencies [6358a2d]
+- Updated dependencies [6bca0e4]
+- Updated dependencies [81c0bc4]
+- Updated dependencies [3c76801]
+- Updated dependencies [d06fba8]
+- Updated dependencies [60500cb]
+- Updated dependencies [2fcefb9]
+- Updated dependencies [77f846a]
+- Updated dependencies [bc5870c]
+- Updated dependencies [b55a346]
+- Updated dependencies [065bba7]
+- Updated dependencies [f760064]
+- Updated dependencies [dd19463]
+- Updated dependencies [6791717]
+- Updated dependencies [8ea3bee]
+- Updated dependencies [100547e]
+- Updated dependencies [3a58149]
+- Updated dependencies [6d1c155]
+- Updated dependencies [d7573b3]
+- Updated dependencies [bf3edfe]
+- Updated dependencies [2c8474c]
+- Updated dependencies [6ce89da]
+- Updated dependencies [0e05aac]
+- Updated dependencies [ae61ad4]
+- Updated dependencies [5aed9e4]
+- Updated dependencies [83c77dc]
+- Updated dependencies [3c9fca3]
+- 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 [fe76ece]
+- Updated dependencies [8b446f5]
+- Updated dependencies [8e74b27]
+- Updated dependencies [7102b20]
+- Updated dependencies [8ebd57f]
+- Updated dependencies [617707a]
+- Updated dependencies [c40f3b8]
+- Updated dependencies [58770f3]
+- Updated dependencies [aefe428]
+- Updated dependencies [485f096]
+- Updated dependencies [7357447]
+- Updated dependencies [199d31b]
+- Updated dependencies [b655a9d]
+- Updated dependencies [3e01cb5]
+- Updated dependencies [7138bc1]
+- Updated dependencies [cef27e2]
+- Updated dependencies [4e8622b]
+- Updated dependencies [dffd752]
+- Updated dependencies [06973aa]
+- Updated dependencies [50798f3]
+- Updated dependencies [6a576c9]
+- Updated dependencies [0b12a33]
+- Updated dependencies [105f3c5]
+- Updated dependencies [3ccd9e8]
+- Updated dependencies [689b979]
+- Updated dependencies [c70f865]
+- Updated dependencies [e546222]
+- Updated dependencies [fd13f52]
+- Updated dependencies [d7bd274]
+- Updated dependencies [98c3a74]
+- Updated dependencies [fffa30d]
+- Updated dependencies [ebce5a3]
+- Updated dependencies [fb336df]
+- Updated dependencies [6c1b105]
+- Updated dependencies [4dc80d0]
+- Updated dependencies [9d9040d]
+- Updated dependencies [20e317c]
+- Updated dependencies [0fce2ef]
+- Updated dependencies [42df928]
+- Updated dependencies [0e2ddd4]
+- Updated dependencies [b7479ab]
+- Updated dependencies [9850c6e]
+- Updated dependencies [de570cc]
+- Updated dependencies [b2ea297]
+- Updated dependencies [5b5a5c3]
+- Updated dependencies [14582b8]
+- Updated dependencies [51e144e]
+- Updated dependencies [19cbf10]
+- Updated dependencies [7e50e84]
+- Updated dependencies [ab92940]
+- Updated dependencies [a691c0b]
+- Updated dependencies [0b1326d]
+- Updated dependencies [1e66879]
+- Updated dependencies [c5200f0]
+- Updated dependencies [af3861f]
+- Updated dependencies [2a79e84]
+- Updated dependencies [2609812]
+- Updated dependencies [515f171]
+- Updated dependencies [1f4e029]
+- Updated dependencies [4f14ad7]
+- Updated dependencies [258d264]
+- Updated dependencies [cac64b3]
+- Updated dependencies [17fbbaf]
+- Updated dependencies [d8cf1cb]
+- Updated dependencies [0d1e702]
+- Updated dependencies [b03ba3a]
+- Updated dependencies [0068348]
+- Updated dependencies [641543f]
+- Updated dependencies [8a44390]
+- Updated dependencies [8033ad1]
+- Updated dependencies [fa140b8]
+- Updated dependencies [71cba28]
+- Updated dependencies [190fbd0]
+- Updated dependencies [c00bf28]
+- Updated dependencies [23705b7]
+- Updated dependencies [93127bd]
+- Updated dependencies [f2158ec]
+- Updated dependencies [759606e]
+- Updated dependencies [fd8dace]
+- Updated dependencies [72ffc34]
+- Updated dependencies [a51fa0c]
+- Updated dependencies [51f3d8d]
+- Updated dependencies [bf28341]
+- Updated dependencies [78cbdb5]
+- Updated dependencies [b7543a9]
+- Updated dependencies [6c6cee7]
+- Updated dependencies [42887e0]
+- Updated dependencies [83fe6e7]
+- Updated dependencies [d1ab06f]
+- Updated dependencies [38a9568]
+- Updated dependencies [f90b8fb]
+- Updated dependencies [91783c4]
+- Updated dependencies [982885d]
+- Updated dependencies [dba7d84]
+- Updated dependencies [ca39427]
+- Updated dependencies [bd09957]
+- Updated dependencies [5a07e67]
+- Updated dependencies [2d36552]
+- Updated dependencies [45d8288]
+- Updated dependencies [b2437a7]
+- Updated dependencies [f157423]
+- Updated dependencies [7a90afd]
+- Updated dependencies [eddc1dd]
+- Updated dependencies [490f482]
+- Updated dependencies [27308c5]
+- Updated dependencies [8689166]
+- Updated dependencies [c9327c9]
+- Updated dependencies [920165d]
+- Updated dependencies [9101be5]
+- Updated dependencies [f53a8d0]
+- Updated dependencies [30266cf]
+- Updated dependencies [968dc1e]
+- Updated dependencies [57f9b07]
+- Updated dependencies [3c73d99]
+- Updated dependencies [d91aed9]
+- Updated dependencies [ed71d9e]
+- Updated dependencies [7776fc2]
+- Updated dependencies [e76634c]
+- Updated dependencies [c86185e]
+- Updated dependencies [fb96ecb]
+- Updated dependencies [1170ed1]
+- Updated dependencies [92814db]
+- Updated dependencies [4d73b07]
+  - @object-ui/plugin-detail@17.7.0
+  - @object-ui/react@17.7.0
+  - @object-ui/core@17.7.0
+  - @object-ui/types@17.7.0
+  - @object-ui/i18n@17.7.0
+  - @object-ui/components@17.7.0
+  - @object-ui/mobile@17.7.0
+  - @object-ui/permissions@17.7.0
+
 ## 17.6.0
 
 ### Patch Changes