@object-ui/plugin-gantt 17.6.0 → 18.0.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/CHANGELOG.md CHANGED
@@ -1,5 +1,3529 @@
1
1
  # @object-ui/plugin-gantt
2
2
 
3
+ ## 18.0.0
4
+
5
+ ### Dependency floors
6
+
7
+ Computed from `.objectstack-sha` `06cab4849a8a`: the earliest published `@objectstack/spec` that contains it is `18.0.0`.
8
+
9
+ - `@objectstack/spec` (`dependencies`): `^18.0.0-next.1` → `^18.0.0`
10
+
11
+ ### Major Changes
12
+
13
+ - 6f3299f: objectui moves to major 18, following `@objectstack/*` from 17 to 18 (objectui#12334). objectui's major is not a count of its own breaking changes: it tracks the major of the `@objectstack/spec` its packages depend on, so that the same major means compatible across the two projects. These packages already declare `@objectstack/*` on the 18 line (objectui#12030), so every package in the fixed release group crosses to 18 together. It is the one `major` that rule admits: objectui's own breaking changes ship as `minor`, described in their entries.
14
+
15
+ The 18 line is released from Changesets pre mode on the `next` tag (`.changeset/pre.json`), as `@objectstack/*` 18 is: these releases are `18.0.0-next.N` on the npm `next` dist-tag, and they do not move `latest`. The first `18.0.0` on `latest` comes when `@objectstack` 18 is generally available and this repository leaves pre mode.
16
+
17
+ What a consumer must do to take it is in the `@objectstack/*` 18 entry of this release (objectui#12030): move its own `@objectstack/*` packages to the 18 line at the same time.
18
+
19
+ ### Minor Changes
20
+
21
+ - c5406c2: Depend on the `@objectstack/*` 18 prerelease line (objectui#12030).
22
+
23
+ Every `@objectstack/*` range these packages declare in `dependencies` or `peerDependencies` moves from `^17.x` to `^18.0.0-next.0`, the `next` prerelease of `@objectstack/*` 18 (raised to `^18.0.0-next.1` by objectui#12370 before release).
24
+
25
+ **Breaking for consumers:** an install that resolves `@objectstack/spec` (or `@objectstack/client`, `@objectstack/formula`, `@objectstack/lint`) 17.x no longer satisfies these ranges. A consumer must move its own `@objectstack/*` packages to the 18 line, starting with `18.0.0-next.1` (objectui#12370), at the same time as it takes this release.
26
+
27
+ **objectui's own surface moves with it:**
28
+
29
+ - `element:record_picker`'s registration stops publishing the `object`, `filter`, `sort` and `limit` inputs, which spec 18 retires; a JSX page that writes one now gets `unknown-prop`.
30
+ - The `CapabilityMultiSelectField` widget's curated capability set (`@object-ui/fields`) follows spec 18: `manage_mailboxes` in, `manage_org_presentation` out.
31
+ - `element:number` and `element:repeater` nodes that bind no object are accepted, as spec 18's row and `PageComponentSchema` accept them; the two `ELEMENT_*_OBJECT_REQUIRED` refusals are gone.
32
+
33
+ **Retired with the spec:** `@objectstack/spec` 18 tombstones `object-grid`'s `defaultFilters` and refuses it by name, and `ObjectGrid` and `ObjectView` stop reading it (`table.defaultFilters` on an `object-view` included). A view that still carries it renders unfiltered: rename the key to `filter`, whose value is the same rule array.
34
+ - 524136e: The view-level `provider: 'api'` data source is no longer read anywhere in objectui (objectui#12325). `@objectstack/spec` retires it (objectstack#23082, ADR-0049): a view binds its object (`provider: 'object'`) or static rows (`provider: 'value'`), and a metadata-declared API call is the page element's `dataSource` binding.
35
+
36
+ Breaking, declared as `minor` per the version-alignment rule:
37
+
38
+ - **`resolveDataSource`** (`@object-ui/core`) has no `api` arm. A block that still says `provider: 'api'` is an unknown provider and gets an unknown provider's answer (the fallback DataSource, else `null`); no `ApiDataSource` is built from its `read` / `write`. `ResolveDataSourceOptions` loses `fetch` and `defaultHeaders`, which only that arm read.
39
+ - **`ViewDataProvider`** (`@object-ui/core`) has no `api` arm: such a config resolves with `Unknown data provider: api`. `ViewDataConfig` and `ResolvedData.provider` drop `'api'`, and `DataFetcher.fetchUrl`, which only that arm called, is removed.
40
+ - **`useViewData`** (`@object-ui/react`) no longer keys on or threads anything for an `api` block.
41
+ - **`ObjectGantt`** reads no `api` block: its `read` URL is never requested, and the chart answers it like any unknown provider. `ObjectCalendar` and `ObjectMap` drop their `api` branches, which only warned "not yet implemented".
42
+ - **`ListView`** no longer stands down for a gantt view with an `api` block: it fetches the bound object like any other list.
43
+
44
+ Unchanged: `ApiDataSource` stays a class for code that constructs it from an `ApiDataSourceConfig`, so the console's approvals inbox reads exactly as before.
45
+ - ff9df88: Depend on `@objectstack/*` `18.0.0-next.1` (objectui#12370).
46
+
47
+ Every `@objectstack/*` range these packages declare moves from `^18.0.0-next.0` to `^18.0.0-next.1`; the console and the runner bundle `18.0.0-next.1`. A consumer moves its own `@objectstack/*` packages to `18.0.0-next.1` with this release.
48
+
49
+ **Accept sets that narrow with it.** `@object-ui/types` validates page action rows and view data bindings through the spec's own rows, so its faces (`safeValidateSchema` and `StrictAnyComponentSchema`) now refuse what `18.0.0-next.1` refuses. Each was accepted on `18.0.0-next.0`:
50
+
51
+ - `onSuccess` on an `action:button` / `action:icon` row, or an `action:group` / `action:menu` member, whose executor is the `url`, `navigation`, `modal`, `flow` or `form` built-in, or that has no executor at all. Write the hop on an `api` or `script` action (or a host handler name), or drop it.
52
+ - `onSuccess` beside `operation: 'update'`, and an `onSuccess` block carrying a key outside `{ navigate, openIn }`.
53
+ - `actionType: 'navigation'` on a row (and `type: 'navigation'` on a container member): write `'url'`.
54
+ - A `url` executor's `target` that is not openable, judged on the executor the runner runs, including a row whose `name` selects it.
55
+ - A view `data` binding with `provider: 'api'`: bind the object or static rows; an API call is the page element's binding.
56
+
57
+ ### Patch Changes
58
+
59
+ - c0862c1: The `object-gantt` `markers` input and the `object-timeline` `items` and `mapping` inputs open their descriptions with the `@objectstack/spec` 17.7.0 row's own describe text, which is true of these renderers (objectui#11168's rule, followed at objectui#11717). The renderer-specific sentences after it are unchanged.
60
+ - 7525045: More write affordances read the affordance-to-grant map, so a caller without the
61
+ grant is no longer offered a write the server then refuses (objectui#12082, leg A
62
+ of the write-census backlog). No row is added: each reuses the row of the same
63
+ verb on the same object.
64
+
65
+ - **The record overlay's inline edit** — the overlay the calendar, the kanban and
66
+ the gantt open on a record (`RecordDetailPanel`) — reads the `recordEdit` row,
67
+ the row the record page reads for the same in-place edit: the object's policy,
68
+ the effective API operation set and the caller's update grant. A closed row
69
+ opens no inline-edit session, as an absent `onFieldSave` already did. Each
70
+ field still asks its own field question, as since objectui#12103.
71
+ - **The gantt's in-chart writes** read `rowEdit` (a bar's drag, resize and
72
+ progress, its title edited in place, and its dependency links) and `rowDelete`
73
+ (a row's Delete). A closed row withholds the handler the chart draws the
74
+ affordance from, the way `readOnly` and `lockField` already do.
75
+ - **A grid's bulk field update** (a `bulkActionDefs` entry with `operation:
76
+ 'update'`) reads `rowEdit`, as its bulk delete reads `rowDelete`: a closed row
77
+ removes the button from the selection bar, and with it the dialog, its undo
78
+ and its retry. `custom` operations are unchanged.
79
+ - **A master-detail form's line grids** read `relatedNew` (Add, the entry row
80
+ and Duplicate) and `relatedRowDelete` (Remove) on the CHILD object, as a
81
+ line-items panel does. Remove asks the delete grant on an edit form only: a
82
+ create form's lines are drafts, and a removed one is never a server delete.
83
+ - **A line-items panel** now hands its child object's schema to those two rows,
84
+ so the child's own policy (`managedBy`, `userActions`) is read too.
85
+ - **The AI build panel's spreadsheet import** (`ExcelImportBar`) reads the
86
+ `listImport` row of the object it imports into, as the list page's Import
87
+ does: without it, Import is disabled for that object.
88
+
89
+ With no permission provider mounted every one of these reads open, as before.
90
+ - 5330038: Console rendering fixes from the HotCRM browser pass (objectui#12110):
91
+
92
+ - **Grid:** a view column's authored `label` is the header. It used to lose to the field's translated label whenever the app bundle translated the field.
93
+ - **Form:** a field `widget` that names no registered component falls back to the field type's renderer, as the spec's `widget` description says. A `rating` field declaring `widget: 'star_rating'` now draws the star widget instead of a text box. A built-in control name (`input`, `textarea`, …) and the native password and email inputs still render as before.
94
+ - **Cells:** a `rating` value draws stars out of the field's `max` (5 by default) in list, detail and related-list cells, instead of a bare number.
95
+ - **Reference rail:** a related row is named by its object's declared `nameField`, and the rail refetches in place when the record, a related object or everything is invalidated. A record action with `refreshAfter: true` therefore refreshes the rail too.
96
+ - **Gantt:** the task list, the tooltip and the drag previews show a date's year when it is not the current year.
97
+ - **Approvals drawer:** a `position:` approver shows the position's label, from the console's position registry, instead of a truncated id. The headline figure prefers the object's declared `currency` field and never shows a zero from a field matched only by its name.
98
+ - **Public form:** a form with no title of its own is headed by its object's label, not the object's API name.
99
+ - d75f212: Published text no longer teaches the retired view-level `provider: 'api'` data source (objectui#12364). A view binds `provider: 'object'` or `provider: 'value'`; a metadata-declared API call is the page element's `dataSource` binding. Text only: no schema accepts or refuses anything new, and no renderer behaves differently.
100
+
101
+ - **`@object-ui/types`:** the `object-tree` `data` description drops the `api` provider from the providers it names.
102
+ - **`@object-ui/plugin-grid` / `@object-ui/plugin-map`:** the `data` input descriptions drop the `api` provider.
103
+ - **`@object-ui/plugin-calendar` / `@object-ui/plugin-gantt` / `@object-ui/plugin-map`:** the error thrown when no `DataSource` is available now reads `DataSource required for the object provider` (was `DataSource required for object/api providers`). It fires in exactly the same conditions as before.
104
+ - **`@object-ui/react` / `@object-ui/auth`:** the README and docblocks describe `SchemaRendererProvider`'s `apiFetch` as what it is now: the host's authenticated fetch the renderers use for their own reads of the host's API (chart metadata, dataset dimension labels, record-permission probes). It is not a channel for a view's data source.
105
+ - **`@object-ui/app-shell`:** comment wording only in `ConsoleShell`, `useConsoleActionRuntime` and `ObjectView` (these comments ship in the built JS): no behaviour change.
106
+ - **`@object-ui/core`:** docblock wording only on `normalizeListViewSchema` and `resolveRecordSourceObjectName` (these ship in `dist/*.d.ts` and the built JS): no behaviour change.
107
+ - 1e6d83b: Data-bound blocks title their "data source could not be resolved" panel in the page's language (objectui#12920, the family of objectui#12910). The panel shows when a block's `dataSource.view` names a view its object does not have. Each block's title now reads `@object-ui/i18n` through `useObjectTranslation`, with the `en` pack's value as the inline default, so a page with no `I18nProvider` draws the same English it drew before.
108
+
109
+ - **Plugin blocks.** `object-calendar`, `object-chart`, `object-metric`, `object-pivot`, `detail-view`, `record:related_list`, `object-form`, `embeddable-form`, `object-master-detail-form`, `record:line_items`, `object-gantt`, `object-grid`, `object-kanban`, `list-view`, `object-map` and `object-timeline` read one `element.KIND.sourceUnresolved` key per block kind. `object-metric` reads `element.number.sourceUnresolved`, the key `element:number` already reads for the same sentence. The three forms share `element.form.sourceUnresolved`. `record:related_list`'s panel for a failed `parentDataSource` read reads `element.relatedList.parentUnreadable` ("This related list’s parent record could not be read").
110
+ - **`@object-ui/react` panel defaults.** `ElementDataSourceErrorPanel` with no `title` reads `element.component.sourceUnresolved`, and `NoDataSourcePanel` with no `title` reads `element.component.noDataSource`. A passed `title` still wins, an empty string included. Props and markup do not change.
111
+
112
+ Clause-②: yes
113
+
114
+ The new keys in `@object-ui/i18n` widen its exported `TranslationKeys`. No prop, input or export of these packages changes.
115
+ - Updated dependencies [18d7b48]
116
+ - Updated dependencies [172acc3]
117
+ - Updated dependencies [f0496bd]
118
+ - Updated dependencies [c4c506b]
119
+ - Updated dependencies [9db9ff3]
120
+ - Updated dependencies [c096f03]
121
+ - Updated dependencies [d92b2a1]
122
+ - Updated dependencies [92f4e2b]
123
+ - Updated dependencies [b10c68e]
124
+ - Updated dependencies [bdc9049]
125
+ - Updated dependencies [b61c116]
126
+ - Updated dependencies [e8c0b96]
127
+ - Updated dependencies [b92329c]
128
+ - Updated dependencies [2e818d0]
129
+ - Updated dependencies [fd060f0]
130
+ - Updated dependencies [fd060f0]
131
+ - Updated dependencies [8b14aec]
132
+ - Updated dependencies [2abec3a]
133
+ - Updated dependencies [4c127cd]
134
+ - Updated dependencies [9dfaca6]
135
+ - Updated dependencies [76993f8]
136
+ - Updated dependencies [c000398]
137
+ - Updated dependencies [73b5d77]
138
+ - Updated dependencies [7b17705]
139
+ - Updated dependencies [fc3c2cc]
140
+ - Updated dependencies [f9f4a62]
141
+ - Updated dependencies [848ba0e]
142
+ - Updated dependencies [57d82cb]
143
+ - Updated dependencies [de96f3d]
144
+ - Updated dependencies [9ca3cac]
145
+ - Updated dependencies [c910630]
146
+ - Updated dependencies [ce464d9]
147
+ - Updated dependencies [e6dcd85]
148
+ - Updated dependencies [96fcf30]
149
+ - Updated dependencies [7a2c60b]
150
+ - Updated dependencies [055d350]
151
+ - Updated dependencies [7300fca]
152
+ - Updated dependencies [834c559]
153
+ - Updated dependencies [22b503c]
154
+ - Updated dependencies [9fc68aa]
155
+ - Updated dependencies [d50f724]
156
+ - Updated dependencies [17acfbb]
157
+ - Updated dependencies [6be0f7a]
158
+ - Updated dependencies [db4cb6b]
159
+ - Updated dependencies [4590363]
160
+ - Updated dependencies [89cc738]
161
+ - Updated dependencies [c0862c1]
162
+ - Updated dependencies [c0862c1]
163
+ - Updated dependencies [c0862c1]
164
+ - Updated dependencies [c0862c1]
165
+ - Updated dependencies [c0862c1]
166
+ - Updated dependencies [c0862c1]
167
+ - Updated dependencies [ded4494]
168
+ - Updated dependencies [d172f63]
169
+ - Updated dependencies [885a96f]
170
+ - Updated dependencies [4c0de52]
171
+ - Updated dependencies [a80fef7]
172
+ - Updated dependencies [3bf8894]
173
+ - Updated dependencies [72167a9]
174
+ - Updated dependencies [e06365c]
175
+ - Updated dependencies [3035948]
176
+ - Updated dependencies [1e1f09e]
177
+ - Updated dependencies [455c646]
178
+ - Updated dependencies [f34e877]
179
+ - Updated dependencies [f34e877]
180
+ - Updated dependencies [f34e877]
181
+ - Updated dependencies [f34e877]
182
+ - Updated dependencies [9844bbf]
183
+ - Updated dependencies [cef0eee]
184
+ - Updated dependencies [7ebff39]
185
+ - Updated dependencies [054fd84]
186
+ - Updated dependencies [5275d1f]
187
+ - Updated dependencies [7241a81]
188
+ - Updated dependencies [74add0c]
189
+ - Updated dependencies [aaba865]
190
+ - Updated dependencies [f1781be]
191
+ - Updated dependencies [5ab2f19]
192
+ - Updated dependencies [fbad078]
193
+ - Updated dependencies [45d5853]
194
+ - Updated dependencies [4f4fc03]
195
+ - Updated dependencies [2312bd9]
196
+ - Updated dependencies [6d5eb34]
197
+ - Updated dependencies [c5406c2]
198
+ - Updated dependencies [c5406c2]
199
+ - Updated dependencies [d99b731]
200
+ - Updated dependencies [2571a3e]
201
+ - Updated dependencies [a368ccb]
202
+ - Updated dependencies [2a48bd4]
203
+ - Updated dependencies [8a55f0c]
204
+ - Updated dependencies [c7b30bd]
205
+ - Updated dependencies [e391f87]
206
+ - Updated dependencies [20c6d35]
207
+ - Updated dependencies [417e245]
208
+ - Updated dependencies [69bca0a]
209
+ - Updated dependencies [023f00d]
210
+ - Updated dependencies [158c75d]
211
+ - Updated dependencies [7525045]
212
+ - Updated dependencies [5af42db]
213
+ - Updated dependencies [ce991bd]
214
+ - Updated dependencies [3c0f806]
215
+ - Updated dependencies [1071393]
216
+ - Updated dependencies [5f75cfa]
217
+ - Updated dependencies [29b9949]
218
+ - Updated dependencies [1d1cfe0]
219
+ - Updated dependencies [6757a93]
220
+ - Updated dependencies [b7cd5c8]
221
+ - Updated dependencies [5330038]
222
+ - Updated dependencies [2498a07]
223
+ - Updated dependencies [898bd2c]
224
+ - Updated dependencies [c9fc10b]
225
+ - Updated dependencies [dc6d28e]
226
+ - Updated dependencies [c0c2f79]
227
+ - Updated dependencies [0665c3b]
228
+ - Updated dependencies [d2500d8]
229
+ - Updated dependencies [a7d4920]
230
+ - Updated dependencies [e723f58]
231
+ - Updated dependencies [82bb1d5]
232
+ - Updated dependencies [f3d5408]
233
+ - Updated dependencies [b231607]
234
+ - Updated dependencies [b231607]
235
+ - Updated dependencies [466a219]
236
+ - Updated dependencies [466a219]
237
+ - Updated dependencies [466a219]
238
+ - Updated dependencies [6fb281d]
239
+ - Updated dependencies [54159d3]
240
+ - Updated dependencies [fa778e6]
241
+ - Updated dependencies [334f0cf]
242
+ - Updated dependencies [c08c933]
243
+ - Updated dependencies [92f979d]
244
+ - Updated dependencies [c4dd707]
245
+ - Updated dependencies [c4dd707]
246
+ - Updated dependencies [7578323]
247
+ - Updated dependencies [a491b64]
248
+ - Updated dependencies [38bb373]
249
+ - Updated dependencies [803f678]
250
+ - Updated dependencies [923504f]
251
+ - Updated dependencies [5b45c0d]
252
+ - Updated dependencies [923504f]
253
+ - Updated dependencies [5c2982a]
254
+ - Updated dependencies [0cd322d]
255
+ - Updated dependencies [97e7d4e]
256
+ - Updated dependencies [5d3f437]
257
+ - Updated dependencies [10aba37]
258
+ - Updated dependencies [10aba37]
259
+ - Updated dependencies [5d3f437]
260
+ - Updated dependencies [51c661e]
261
+ - Updated dependencies [7af0ab3]
262
+ - Updated dependencies [b434f5f]
263
+ - Updated dependencies [9f282ef]
264
+ - Updated dependencies [fd4872f]
265
+ - Updated dependencies [f0532d8]
266
+ - Updated dependencies [cea429b]
267
+ - Updated dependencies [3092aca]
268
+ - Updated dependencies [82e5f53]
269
+ - Updated dependencies [d81e460]
270
+ - Updated dependencies [8106db1]
271
+ - Updated dependencies [068a540]
272
+ - Updated dependencies [ca45c6d]
273
+ - Updated dependencies [093d55b]
274
+ - Updated dependencies [b64fda3]
275
+ - Updated dependencies [28ebfb5]
276
+ - Updated dependencies [a8051d6]
277
+ - Updated dependencies [72594f2]
278
+ - Updated dependencies [524136e]
279
+ - Updated dependencies [2b06a91]
280
+ - Updated dependencies [6f3299f]
281
+ - Updated dependencies [065a1cf]
282
+ - Updated dependencies [f2b17c6]
283
+ - Updated dependencies [52d6194]
284
+ - Updated dependencies [23bf859]
285
+ - Updated dependencies [1c72d77]
286
+ - Updated dependencies [789cb16]
287
+ - Updated dependencies [2b4d3f1]
288
+ - Updated dependencies [d75f212]
289
+ - Updated dependencies [37db09f]
290
+ - Updated dependencies [ff9df88]
291
+ - Updated dependencies [70e843f]
292
+ - Updated dependencies [caac3b2]
293
+ - Updated dependencies [a2225f9]
294
+ - Updated dependencies [5c4deb5]
295
+ - Updated dependencies [a8e5b73]
296
+ - Updated dependencies [9782cb2]
297
+ - Updated dependencies [3e2394d]
298
+ - Updated dependencies [d9d9d98]
299
+ - Updated dependencies [c950345]
300
+ - Updated dependencies [21f9577]
301
+ - Updated dependencies [044f231]
302
+ - Updated dependencies [f8267df]
303
+ - Updated dependencies [023087f]
304
+ - Updated dependencies [023087f]
305
+ - Updated dependencies [9b82ced]
306
+ - Updated dependencies [3821a3a]
307
+ - Updated dependencies [3eb3ec1]
308
+ - Updated dependencies [92c2a69]
309
+ - Updated dependencies [518a8e3]
310
+ - Updated dependencies [165f8ff]
311
+ - Updated dependencies [646caea]
312
+ - Updated dependencies [1ffd6a2]
313
+ - Updated dependencies [5f8ecf6]
314
+ - Updated dependencies [6f5dc6b]
315
+ - Updated dependencies [7d0c174]
316
+ - Updated dependencies [8ed7e5a]
317
+ - Updated dependencies [6c4d00d]
318
+ - Updated dependencies [db8ce2f]
319
+ - Updated dependencies [726d8c9]
320
+ - Updated dependencies [f0e760a]
321
+ - Updated dependencies [a5bb7ac]
322
+ - Updated dependencies [f78efdd]
323
+ - Updated dependencies [8a8bcf3]
324
+ - Updated dependencies [f74638c]
325
+ - Updated dependencies [278bc29]
326
+ - Updated dependencies [ef71a09]
327
+ - Updated dependencies [8614705]
328
+ - Updated dependencies [619e3f7]
329
+ - Updated dependencies [ca7a4c3]
330
+ - Updated dependencies [c9e6742]
331
+ - Updated dependencies [4be76e0]
332
+ - Updated dependencies [f62b6ff]
333
+ - Updated dependencies [608033b]
334
+ - Updated dependencies [c6b7d82]
335
+ - Updated dependencies [611566b]
336
+ - Updated dependencies [efa9cb4]
337
+ - Updated dependencies [d66d7e8]
338
+ - Updated dependencies [15d8ca6]
339
+ - Updated dependencies [378896d]
340
+ - Updated dependencies [9d857c9]
341
+ - Updated dependencies [670ea10]
342
+ - Updated dependencies [ff215d9]
343
+ - Updated dependencies [71243db]
344
+ - Updated dependencies [e219a3d]
345
+ - Updated dependencies [a8add5c]
346
+ - Updated dependencies [33ee9de]
347
+ - Updated dependencies [4839f5c]
348
+ - Updated dependencies [a23e804]
349
+ - Updated dependencies [c7462e7]
350
+ - Updated dependencies [36e2f7b]
351
+ - Updated dependencies [263e9dd]
352
+ - Updated dependencies [360e27a]
353
+ - Updated dependencies [ac59073]
354
+ - Updated dependencies [44cb469]
355
+ - Updated dependencies [e058d76]
356
+ - Updated dependencies [464ae62]
357
+ - Updated dependencies [c999d4c]
358
+ - Updated dependencies [8df2608]
359
+ - Updated dependencies [8df2608]
360
+ - Updated dependencies [5483297]
361
+ - Updated dependencies [ed43c79]
362
+ - Updated dependencies [6367bfe]
363
+ - Updated dependencies [260ef71]
364
+ - Updated dependencies [655e897]
365
+ - Updated dependencies [655e897]
366
+ - Updated dependencies [020d178]
367
+ - Updated dependencies [8d80845]
368
+ - Updated dependencies [69a408f]
369
+ - Updated dependencies [1aa622a]
370
+ - Updated dependencies [d2b21a1]
371
+ - Updated dependencies [6e4f144]
372
+ - Updated dependencies [5ff64ef]
373
+ - Updated dependencies [64acb7e]
374
+ - Updated dependencies [4ff5b6b]
375
+ - Updated dependencies [473e5a0]
376
+ - Updated dependencies [b279016]
377
+ - Updated dependencies [bb6c38c]
378
+ - Updated dependencies [15b1065]
379
+ - Updated dependencies [26323c4]
380
+ - Updated dependencies [9753811]
381
+ - Updated dependencies [2727527]
382
+ - Updated dependencies [3da39ae]
383
+ - Updated dependencies [bc281f4]
384
+ - Updated dependencies [d637be3]
385
+ - Updated dependencies [8392f74]
386
+ - Updated dependencies [2cfdc99]
387
+ - Updated dependencies [2cfdc99]
388
+ - Updated dependencies [8523e81]
389
+ - Updated dependencies [1e6d83b]
390
+ - Updated dependencies [1e6d83b]
391
+ - Updated dependencies [32b492b]
392
+ - Updated dependencies [6058bf8]
393
+ - Updated dependencies [c219165]
394
+ - Updated dependencies [79cb8c0]
395
+ - Updated dependencies [a7ae252]
396
+ - Updated dependencies [fb501bc]
397
+ - Updated dependencies [03f1d65]
398
+ - Updated dependencies [30083da]
399
+ - Updated dependencies [7f9cc37]
400
+ - Updated dependencies [b7fe09e]
401
+ - Updated dependencies [025130c]
402
+ - Updated dependencies [76f91f8]
403
+ - Updated dependencies [ea34d9b]
404
+ - Updated dependencies [8aa8e3e]
405
+ - Updated dependencies [024b7b6]
406
+ - Updated dependencies [cb80001]
407
+ - Updated dependencies [bcd9717]
408
+ - Updated dependencies [909c64e]
409
+ - Updated dependencies [9e7e1a5]
410
+ - Updated dependencies [1d3da6c]
411
+ - Updated dependencies [0d97642]
412
+ - Updated dependencies [2493e85]
413
+ - Updated dependencies [d0b9648]
414
+ - Updated dependencies [46dbf32]
415
+ - Updated dependencies [a928aaa]
416
+ - Updated dependencies [47508f3]
417
+ - Updated dependencies [61ed5ad]
418
+ - Updated dependencies [1b94d50]
419
+ - Updated dependencies [6f877f1]
420
+ - Updated dependencies [988aa9f]
421
+ - Updated dependencies [50ba1bb]
422
+ - Updated dependencies [1ce0711]
423
+ - Updated dependencies [fb85637]
424
+ - Updated dependencies [9f1dd79]
425
+ - Updated dependencies [df71568]
426
+ - Updated dependencies [d11174a]
427
+ - Updated dependencies [4c68855]
428
+ - Updated dependencies [2d8a8b7]
429
+ - Updated dependencies [cbac9d7]
430
+ - Updated dependencies [5129caa]
431
+ - Updated dependencies [9eb1479]
432
+ - Updated dependencies [74e37aa]
433
+ - Updated dependencies [961b69f]
434
+ - Updated dependencies [52907d7]
435
+ - Updated dependencies [f466b0a]
436
+ - Updated dependencies [673a71c]
437
+ - Updated dependencies [616df65]
438
+ - Updated dependencies [f48a4d5]
439
+ - Updated dependencies [58798ec]
440
+ - Updated dependencies [8803ca5]
441
+ - Updated dependencies [e70c21d]
442
+ - Updated dependencies [4b92c5a]
443
+ - Updated dependencies [06be396]
444
+ - Updated dependencies [3650d94]
445
+ - Updated dependencies [7c05f21]
446
+ - Updated dependencies [8cd4db4]
447
+ - Updated dependencies [daeb77f]
448
+ - Updated dependencies [eb4552e]
449
+ - Updated dependencies [3c3115e]
450
+ - Updated dependencies [55e90fd]
451
+ - Updated dependencies [9b75509]
452
+ - Updated dependencies [b13ea3c]
453
+ - Updated dependencies [d7e9e9a]
454
+ - Updated dependencies [cf62edf]
455
+ - Updated dependencies [0253416]
456
+ - Updated dependencies [5d77c09]
457
+ - Updated dependencies [3fd8625]
458
+ - Updated dependencies [1473757]
459
+ - Updated dependencies [d73d987]
460
+ - Updated dependencies [12ff256]
461
+ - Updated dependencies [35a2b59]
462
+ - Updated dependencies [26b0bd2]
463
+ - Updated dependencies [26b0bd2]
464
+ - Updated dependencies [d328698]
465
+ - Updated dependencies [d328698]
466
+ - Updated dependencies [d328698]
467
+ - Updated dependencies [b4e0787]
468
+ - Updated dependencies [53ee2f8]
469
+ - Updated dependencies [088e0f7]
470
+ - Updated dependencies [78b07f4]
471
+ - Updated dependencies [0df67f2]
472
+ - Updated dependencies [f962cdc]
473
+ - Updated dependencies [b403bb3]
474
+ - Updated dependencies [8a25fee]
475
+ - Updated dependencies [4016370]
476
+ - Updated dependencies [12dc7b4]
477
+ - @object-ui/types@18.0.0
478
+ - @object-ui/components@18.0.0
479
+ - @object-ui/core@18.0.0
480
+ - @object-ui/i18n@18.0.0
481
+ - @object-ui/react@18.0.0
482
+ - @object-ui/plugin-detail@18.0.0
483
+ - @object-ui/fields@18.0.0
484
+ - @object-ui/permissions@18.0.0
485
+
486
+ ## 17.7.0
487
+
488
+ ### Minor Changes
489
+
490
+ - af243c1: On `tree` and `chart` list views, the toolbar's Filter control and the `UserFilters`
491
+ chips now narrow the view, and on a `gantt` list view the toolbar's Search box now
492
+ narrows the chart (objectui#10250).
493
+
494
+ These three views run their own query instead of drawing the rows `ListView` fetched.
495
+ The tree and chart nodes carried only the authored `filter`, and the gantt node carried
496
+ no search term, so each control changed `ListView`'s own fetch and nothing on screen.
497
+
498
+ - The `tree` node and the object-bound `chart` node now carry the same effective filter
499
+ `ListView`'s own fetch sends, as the `gantt` node has since objectui#10037. The value
500
+ keeps its identity while its content is unchanged, so re-rendering the list does not
501
+ re-query the view.
502
+ - `ObjectGanttSchema` declares two optional keys, `search` and `searchableFields`.
503
+ `ObjectGantt` sends `search` as `$search` and, only alongside a term,
504
+ `searchableFields` as `$searchFields` — the pair a list's own query sends. A `gantt`
505
+ list view writes both from its toolbar Search box and the view's `searchableFields`.
506
+
507
+ Unchanged: the toolbar state still does not reach the query of a `chart` view bound to a
508
+ semantic `dataset`, and the toolbar Search box still does not reach the `tree` or `chart`
509
+ query. objectui#10326 stops offering that Search box on `tree` and `chart` views.
510
+ - 8673402: feat(plugin-gantt): `object-gantt` publishes the eleven `@objectstack/spec` row keys its renderer honours (objectui#11168 slice 4)
511
+
512
+ The `object-gantt` registration now declares `navigation`, `label`, `skipWeekends`, `holidays`, `persistLayout`, `viewName`, `markers`, `criticalPath`, `showBaselines`, `readOnly` and `mobileReadOnly`. Each is a member of the spec's `ComponentPropsMap['object-gantt']` row, and each was measured through the real `SchemaRenderer`, `ObjectGantt` and `GanttView` before it was declared (objectui#11111 decision 3 = B). All eleven are honoured, so the page validator no longer reports any of them as an unknown prop. Where the row's own describe is true of this renderer, the input's description starts with it word for word, followed by what the measurement added:
513
+
514
+ - `navigation`: absent opens the task's record in a drawer; `drawer`, `modal` and `popover` open that overlay; `split` opens the record beside the chart; `page` and a block without `mode` open the record page in the same tab, and `new_window` in a new tab; `none` and `preventNavigation` open nothing; `openNewTab` outranks every mode except `none`; `size` sets the overlay width. The gantt derives the record-page address from the page it is on and does not use a record navigator the host publishes, so a host that publishes one changes nothing. On the object's own list or view route that address is the record page; on any other page, such as a custom page, `/OBJECT/record/ID` is appended to the current address. On inline rows that name no object, no mode opens anything.
515
+ - `label`: a string, or an inline locale map resolved to the display locale, naming the exported PNG/PDF file after `gantt.exportFileName` and before the object's own label.
516
+ - `skipWeekends` and `holidays` (members: `yyyy-mm-dd` strings): working-day auto-schedule math, and the day view folds those days out of its axis. A non-empty `holidays` turns the working calendar on by itself.
517
+ - `persistLayout` and `viewName`: the `objectName:viewName` storage key; `persistLayout: false` removes the save-layout button and stores nothing.
518
+ - `markers`, `criticalPath`, `showBaselines` and `readOnly`.
519
+ - `mobileReadOnly`: on a chart narrower than 640px the chart's write paths are read-only unless `false`; the record drawer locks under `readOnly` alone, so a task's record still opens writable on a narrow chart.
520
+
521
+ The `gantt` input's description no longer names `percentageField`, which nothing reads and the spec refuses by name. It now starts with the row's own describe and states the three required members.
522
+
523
+ Nothing changes at render time: every key was already read. The README and the docs page say what each key does, including the record-page address above. The README no longer lists `{ provider: 'schema', schemaId }` as a source this chart reads: measured, a gantt carrying it queries `objectName` instead.
524
+ - 00f3eb5: `ObjectGanttSchema` declares the ten gantt keys `ObjectGantt` actually reads
525
+ (objectui#5903, triage 2026-08-24). Every one is a real, working, documented
526
+ feature — `readOnly`, `mobileReadOnly`, `markers`, `navigation`, `skipWeekends`,
527
+ `holidays`, `criticalPath`, `showBaselines`, `persistLayout`, `viewName` — and
528
+ none of them was discoverable from the published type, because all ten were read
529
+ as `(schema as any).K`. The cast was the load-bearing part: it kept the read
530
+ invisible to `tsc`, to the zod mirror and to the designer's registry `inputs`.
531
+
532
+ Both halves move together. The TS declaration (`packages/types/src/objectql.ts`)
533
+ and its zod mirror (`src/zod/objectql.zod.ts`) gain the same ten keys at the same
534
+ requiredness — all optional — and no `KnownDrift` entry is added. `navigation` is
535
+ taken from `@objectstack/spec`'s `NavigationConfigSchema` by reference rather than
536
+ restated, matching `ObjectGridSchema.navigation`.
537
+
538
+ ⚠️ **The JUSTIFICATION for that parity clause was retired (objectui#9743); the
539
+ clause itself stands and did not move.** As first written it credited the
540
+ `zod-mirror-parity` ratchet with a zero-drift reading for this pair — but at that
541
+ time the ratchet measured three directions and was structurally blind to the
542
+ MIRRORED-but-undeclared one (objectui#9711), so a zero from it recorded that it
543
+ had not looked in that direction, not that nothing was there. objectui#9725
544
+ landed the fourth direction, and it covers this pair BY NAME:
545
+ `packages/types/src/__tests__/zod-mirror-parity.test.ts` registers
546
+ `objectql.zod.ts#ObjectGanttSchema` in both its mirror map and its declaration
547
+ map; `assertionMirroredUndeclaredMatchesLedger` requires every registered pair's
548
+ mirrored-but-undeclared key set to equal that pair's `MirroredUndeclared` ledger
549
+ entry — `never` for a pair the ledger does not name — and
550
+ `assertionNoVacuousMirroredUndeclaredMeasurement` refuses a measurement that has
551
+ degenerated to `any`. ⛔ Read this pair's verdict off that reconciliation, which
552
+ re-derives it on every run, rather than off any figure written here; when this
553
+ paragraph was authored, on 2026-09-18, it required no `MirroredUndeclared` entry
554
+ for the pair.
555
+
556
+ `ObjectGanttProps.schema` is retyped from `ObjectGridSchema` to
557
+ `ObjectGanttSchema`. That is what makes the declaration load-bearing: the ten
558
+ keys are not grid keys, so with the old prop type, dropping the casts would have
559
+ left the reads landing on `BaseSchema`'s index signature — the same invisibility
560
+ in different syntax. The grid-style `{ gantt: { … } }` block is unaffected;
561
+ `getGanttConfig` reads it through that index signature exactly as before, and the
562
+ registered renderer passes `schema: any`, so no runtime shape is turned away.
563
+
564
+ Accept-set change, stated plainly: a **declared** key is now type-validated, so
565
+ `readOnly: 'yes'` is refused where it used to parse green — the same narrowing
566
+ objectui#5074 landed for `viewMode`. An **undeclared** key is still accepted:
567
+ `BaseSchema` is `.passthrough()` and carries an index signature (objectui#5155's
568
+ structural ceiling), so declaring these ten did not buy rejection of a
569
+ misspelling. `packages/types/src/__tests__/gantt-declared-keys.test.ts` pins both
570
+ halves so neither can be misread.
571
+
572
+ The eleventh reported key, `label`, needed no declaration — `BaseSchema` already
573
+ carries it — so only its cast was dropped.
574
+ - 75bd83d: `ObjectGanttSchema` declares the flattened `GanttConfig` face `ObjectGantt`
575
+ actually reads (objectui#6051). `getGanttConfig` has two branches: when
576
+ `startDateField` and `endDateField` are both present at the TOP level it builds
577
+ its config from top-level keys and returns early; otherwise it reads the `gantt`
578
+ block. Everything the first branch reads was undeclared — and unlike
579
+ objectui#5903's ten, none of it was hidden behind a cast. `BaseSchema` carries
580
+ `[key: string]: any` (objectui#5155's structural ceiling) and the helper's
581
+ parameter was `ObjectGridSchema | any`, so `schema.colorField` type-checked as
582
+ `any` with no syntax anywhere to grep for. That is also why the census here is an
583
+ AST enumeration and not a compile-and-observe: an index signature absorbs every
584
+ literal name, so annotating the parameter compiles clean while enforcing nothing.
585
+
586
+ **27 keys join the declared surface, each additive and each with a live read
587
+ site.** 24 flattened `GanttConfig` members — `colorField`, `borderColorField`,
588
+ `dependenciesField`, `parentField`, `typeField`, `lockField`, `objectField`,
589
+ `summaryExtent`, `defaultCollapsedDepth`, `tooltipFields`, `baselineStartField`,
590
+ `baselineEndField`, `groupByField`, `resourceView`, `assigneeField`,
591
+ `effortField`, `capacity`, `quickFilters`, `autoZoomToFilter`, `timeSegments`,
592
+ `interactions`, `exportFileName`, `timeZone`, `dependencyTypes` — plus the three
593
+ query keys the fetch path reads, `staticData`, `filter` and `sort`. Nothing is
594
+ declared that the renderer does not consume.
595
+
596
+ **`GanttConfig` itself gains nine members and is a published type**, exported by
597
+ name from `packages/types/src/index.ts`: `lockField`, `objectField`,
598
+ `summaryExtent`, `defaultCollapsedDepth`, `borderColorField`, `dependencyTypes`,
599
+ `timeZone`, `exportFileName`, `interactions`. The entry file's diff is empty only
600
+ because the export list already named the type — the widening happened at the
601
+ declaration.
602
+
603
+ **The 28th measured key, `gantt` (the block face), is deliberately NOT declared**
604
+ — see the closing section.
605
+
606
+ The 24 are DERIVED from `GanttConfig` rather than restated, so the flat spelling
607
+ cannot fork from the block spelling, and the invariant is pinned in the type
608
+ system: every key of `GanttConfig` must be declared at the node's top level.
609
+ Making that derivation possible moved nine members — `lockField`, `objectField`,
610
+ `summaryExtent`, `defaultCollapsedDepth`, `borderColorField`, `dependencyTypes`,
611
+ `timeZone`, `exportFileName`, `interactions` — out of `plugin-gantt`'s
612
+ package-private `GanttConfigEx` and into `@object-ui/types`' `GanttConfig`. They
613
+ are a MOVE, not new vocabulary: the `gantt` block already honoured all nine, and
614
+ a type private to the plugin could be referenced by neither authoring face.
615
+
616
+ Both halves move together, as in objectui#5903: the TS declaration and its zod
617
+ mirror gain the same 27 keys at the same requiredness (all optional), the
618
+ spec-modelled ones taken from `GanttConfigSchema.shape` by reference, and no
619
+ `KnownDrift` or `UnmirroredDeclared` entry is added. The mirror builds the flat
620
+ face and the `gantt` block from one field map, so they are one schema expressed
621
+ twice.
622
+
623
+ ⚠️ **The JUSTIFICATION for that parity clause was retired (objectui#9743) — the
624
+ same retirement objectui#5903's entry carries, for the same clause and the same
625
+ reason; the clause itself stands and did not move.** As first written it credited
626
+ the `zod-mirror-parity` ratchet with a zero-drift reading for this pair, at a time
627
+ when that ratchet measured three directions and was structurally blind to the
628
+ MIRRORED-but-undeclared one (objectui#9711), so a zero from it recorded that it
629
+ had not looked in that direction. objectui#9725 landed the fourth direction, and
630
+ it covers this pair BY NAME:
631
+ `packages/types/src/__tests__/zod-mirror-parity.test.ts` registers
632
+ `objectql.zod.ts#ObjectGanttSchema` in both its mirror map and its declaration
633
+ map; `assertionMirroredUndeclaredMatchesLedger` reconciles every registered pair's
634
+ mirrored-but-undeclared key set against that pair's `MirroredUndeclared` ledger
635
+ entry — `never` for a pair the ledger does not name — and
636
+ `assertionNoVacuousMirroredUndeclaredMeasurement` refuses a measurement that has
637
+ degenerated to `any`. ⛔ Read this pair's verdict off that reconciliation, which
638
+ re-derives it on every run, rather than off any figure written here; when this
639
+ paragraph was authored, on 2026-09-18, it required no `MirroredUndeclared` entry
640
+ for the pair.
641
+
642
+ Accept-set change, stated plainly. All 27 keys are additive — every one is
643
+ optional, and nothing previously legal loses its slot. What changes is that a
644
+ **declared** key is now type-validated, so `capacity: 'one'` and
645
+ `summaryExtent: 'parent'` are refused where they used to parse green. An
646
+ **undeclared** key is still accepted — `BaseSchema` is `.passthrough()`, so this
647
+ bought no rejection of misspellings. There is no narrowing anywhere in this
648
+ change.
649
+
650
+ **`gantt` is severed on purpose (objectui#6475), not overlooked.** It is the 28th
651
+ key of the measured residue and a genuine read — `getGanttConfig`'s second branch
652
+ honours it in full — but it is the one key whose declaration would NOT have been
653
+ additive. It has no mirror entry today, so a block rides through `.passthrough()`
654
+ unvalidated; declaring it as `GanttConfig` means it gets parsed against the spec's
655
+ `GanttConfigSchema`, which REQUIRES `startDateField`, `endDateField` and
656
+ `titleField`, and `ObjectGanttSchema` reaches the CLI's `validate` / `check`
657
+ through `AnyComponentSchema`. A published CLI's refusal behaviour is decided on
658
+ its own card, where reviewers can see what they are approving; objectui#6475
659
+ carries the full measurement, including the case FOR enforcing it (the renderer
660
+ already feeds that block to `GanttConfigSchema.safeParse` and warns, so enforcing
661
+ restores declared = enforced rather than inventing a contract). Today's behaviour
662
+ is pinned in the test file so the omission is a measured state, not a silent gap.
663
+ `packages/types/src/__tests__/gantt-flat-config-declared-keys.test.ts` pins both
664
+ halves so neither can be misread.
665
+
666
+ Which face WINS is unchanged and was not decided here: the flat branch is checked
667
+ first and returns early, so a node carrying both spellings still renders the flat
668
+ one. (`plugin-map` had the opposite precedence ruled on in objectui#5018; no
669
+ equivalent ruling exists for gantt.)
670
+ - d7acad6: **plugin-gantt: the `gantt` block now outranks the flat top-level spelling, and
671
+ the losing face's keys are named instead of dropped.**
672
+
673
+ `getGanttConfig` checked the flattened top-level spelling first and returned
674
+ early, so a node carrying both spellings rendered the flat one and every key
675
+ inside an authored `gantt` block was discarded with **no diagnostic** — not even
676
+ the `GanttConfigSchema.safeParse` warning, which sat behind that early return.
677
+
678
+ `plugin-map` had the identical two-faces shape ruled the other way (maintainer
679
+ ruling on objectui#5018, 2026-08-17, landed in PR #5156): the block wins, with a
680
+ dev-mode warning naming the ignored top-level keys. objectui#6469 inherits that
681
+ ruling, so the two sibling view plugins now answer the same question the same
682
+ way.
683
+
684
+ What changes:
685
+
686
+ - A node carrying **both** spellings now renders the **`gantt` block's** values.
687
+ The block is taken **whole** — the flat keys are not merged into it.
688
+ - In dev, `[ObjectGantt] … these top-level keys are IGNORED: …` names every
689
+ shadowed flat key, once per distinct shadowing.
690
+ - Nothing else moves. A node with only the flat spelling, or only a block, is
691
+ read exactly as before.
692
+
693
+ **Producer-safe:** `ObjectView` (`case 'gantt'`) and `ListView` (`case 'gantt'`)
694
+ both flatten `options.gantt` onto top-level keys and emit **no** `gantt` key, so
695
+ every gantt reached through either view layer still takes the flat branch, and
696
+ the new warning cannot fire on that path. This is the same producer check the
697
+ `plugin-map` flip pinned, re-run on today's `main`.
698
+
699
+ This **supersedes** the precedence sentence in the objectui#6051 changeset
700
+ (`.changeset/6051-gantt-flat-config-declared-keys.md`), which recorded the flat
701
+ branch winning — accurate for that change, which deliberately did not touch
702
+ precedence, and reversed by this one.
703
+ - e3d117a: `ObjectGantt` and `ObjectTree` resolve a relationship target only from the two
704
+ spellings a contract carries, dropping the third one no contract declares
705
+ (objectui#6837, second slice).
706
+
707
+ - `ObjectGantt`'s quick-filter option fetch was
708
+ `fd?.reference_to ?? fd?.reference ?? fd?.referenceTo`; it is now
709
+ `fd?.reference_to ?? fd?.reference`.
710
+ - `ObjectTree`'s `detectParentField` was
711
+ `def?.reference || def?.reference_to || def?.referenceTo`; it is now
712
+ `def?.reference || def?.reference_to`.
713
+
714
+ **Accept-set move — a def carrying ONLY `referenceTo` stops resolving a target
715
+ at these two seams.** Concretely: the gantt quick filter for that field falls
716
+ back to the distinct values present in the loaded rows instead of fetching the
717
+ referenced object's full domain, and the tree stops auto-detecting that field as
718
+ its parent pointer, so records render as a flat forest unless `parentField` is
719
+ configured explicitly. Nothing else changes; the two surviving arms are
720
+ untouched.
721
+
722
+ Two things bound that move:
723
+
724
+ - Any def that entered through the ingestion choke point is unaffected.
725
+ `normalizeSchemaReferenceKeys` reads `reference_to ?? reference ??
726
+ referenceTo` and stamps both snake_case keys, so a `referenceTo`-only def
727
+ arriving via `MetadataProvider` or `ObjectStackAdapter.getObjectSchema`
728
+ already carries `reference_to` before either component sees it. Only a def
729
+ that bypassed that door entirely is affected — and that door is not total:
730
+ `getObjectSchema` is a required member of the published `DataSource`
731
+ interface, and both components call it on the generic `dataSource`.
732
+ - No contract declares the deleted spelling. `@objectstack/spec` 17.2.0's
733
+ `FieldSchema` refuses `referenceTo` by name with `unrecognized_keys`, carrying
734
+ its own "Did you mean `referenceTo` -> `reference`?" rename, and `referenceTo`
735
+ is additionally a tombstone in `RETIRED_FIELD_KEY_TOMBSTONES` (objectui#6041)
736
+ at all three strip sites, so the designer read door removes it before a draft
737
+ round-trips.
738
+
739
+ A repo-wide structure-walk producer census found **0** emitters of `referenceTo`
740
+ reaching either seam, measured in the cell these components read (a value inside
741
+ an object schema's `fields` container) against controls `reference` (92 hits / 36
742
+ files) and `reference_to` (52 / 36) hot in the same pass over the same cells;
743
+ the only two in-cell hits are negative fixtures of the retirement machinery,
744
+ asserting the read door strips the key. Neither `plugin-gantt` nor `plugin-tree`
745
+ emits `referenceTo` anywhere, while both packages' own fixtures are hot on the
746
+ surviving spellings.
747
+
748
+ Pinned by `ObjectGantt.referenceArms-6837.test.tsx` and
749
+ `ObjectTree.referenceArms-6837.test.tsx`, which keep the live arms green beside a
750
+ named refusal for the deleted key.
751
+
752
+ ⚠️ **Dated note, 2026-09-30 — the choke point folds, it no longer stamps both keys — objectui#11070.** "`normalizeSchemaReferenceKeys` ... stamps both snake_case keys" above held when this change landed. Later in this same release objectui#11070 (round 4) made that pass fold a legacy spelling onto `reference` without stamping `reference_to`; a def that entered through it still carries `reference`, the one arm both components keep. `.changeset/11070-reference-to-round4.md` states what ships; the text above is kept as the reading of this change.
753
+ - 045d20b: Relationship-target readers resolve a lookup's target from `reference` alone,
754
+ dropping the `reference_to` fallback arm (objectui#6837, half 2).
755
+
756
+ Maintainer ruling, 2026-08-31, 原文照录: 「objectui不是前端的项目吗?后端的元数据只要
757
+ 对,前端按协议执行就行了呀」. Protocol normalization belongs on the SERVER; the front
758
+ end just executes the protocol. objectstack#13847 landed the server half — a
759
+ `field-reference-to-alias` conversion rewrites stored `reference_to` to
760
+ `reference` on the serve path and in `os migrate meta`.
761
+
762
+ `reference` is the only target spelling `@objectstack/spec`'s `FieldSchema`
763
+ declares. Measured on the installed 17.2.0: it refuses `reference_to`,
764
+ `referenceTo` and `target` with `unrecognized_keys`, each carrying its own
765
+ "Did you mean -> `reference`?" rename, while a nonsense key gets the same
766
+ refusal with NO rename hint and `reference` parses clean.
767
+
768
+ ## ⚠️ BREAKING for a hand-written schema that spells `reference_to` — read this
769
+
770
+ **This is a behaviour change for BYO consumers, and it is being stated rather
771
+ than shipped silently.** ObjectUI is usable without an ObjectStack backend
772
+ (`examples/byo-backend-console`), and a hand-written TypeScript schema passes
773
+ through no zod door, so nothing rejects the legacy spelling at authoring time.
774
+
775
+ **The break surface is narrower than "all BYO consumers", and this is the
776
+ measurement rather than a blanket claim.** Two ingestion choke points stamp both
777
+ snake_case keys from whichever spelling arrived — `MetadataProvider`'s type
778
+ cache for metadata type `object`, and `ObjectStackAdapter.getObjectSchema`. Any
779
+ def that passed either one already carries `reference` and is **completely
780
+ unaffected**. What is affected is exactly:
781
+
782
+ - **A `DataSource` implementation other than `ObjectStackAdapter`.**
783
+ `getObjectSchema` is a required member of the published `DataSource`
784
+ interface, and the readers call it on the generic `dataSource` (through
785
+ `useSettledSchema` and directly), so a host adapter's object schema reaches
786
+ them raw. Every in-repo example of one is on this path:
787
+ `ApiDataSource`, `ValueDataSource`, `packages/types/examples/rest-data-source.ts`,
788
+ `examples/byo-backend-console/src/mockDataSource.ts`,
789
+ `packages/runner/src/lib/mockDataSource.ts`,
790
+ `apps/site/app/components/galleryDataSource.ts`,
791
+ `apps/console/src/sdui-workbench-preview.tsx`,
792
+ `packages/plugin-grid/demo/bulk-actions.tsx`.
793
+
794
+ **Measured on this tree, none of those eight emits a relationship target at all** —
795
+ `reference_to` and `reference` are both zero in each, and
796
+ `examples/byo-backend-console` carries no lookup or master_detail field
797
+ anywhere (its only `reference` hits are a vite triple-slash directive and a
798
+ tsconfig `references` array). The single in-repo producer that WAS on this
799
+ surface, `packages/plugin-gantt/demo/main.tsx`, is fixed here at the producer.
800
+
801
+ ⇒ **If you author object metadata by hand and spell a lookup's target
802
+ `reference_to`, rename that key to `reference`.** Symptom if you do not: the
803
+ target silently fails to resolve, and the affected surface degrades rather than
804
+ erroring — a related list is not derived, a gantt quick filter falls back to the
805
+ distinct values in the loaded rows instead of the referenced object's full
806
+ domain, a tree stops auto-detecting its parent pointer, a lookup cell shows a
807
+ raw id, a chart's group-by labels stay unresolved.
808
+
809
+ The ingestion choke point now emits a **dev-mode warning** when a def arrives
810
+ carrying only `reference_to` or `referenceTo` and no `reference`. It names the
811
+ object, the field and the offending key, and points at this ruling. Stamping is
812
+ deliberately unchanged, so nothing that worked stops working. It is memoised
813
+ once per **(object name, field name, spelling, target value)** — every segment
814
+ of that key is pinned, in both directions, in
815
+ `reference-keys.legacyWarning-6837.test.ts`.
816
+
817
+ ⛔ **This warning does NOT cover the break described above, and it is worth being
818
+ exact about that rather than letting it read as mitigation.** It lives in
819
+ `normalizeFieldReferenceKeys`, reachable only through
820
+ `normalizeSchemaReferenceKeys`, which has exactly two production call sites —
821
+ `MetadataProvider` (metadata type `object`) and
822
+ `ObjectStackAdapter.getObjectSchema`. Both of those also STAMP the def, so the
823
+ warning fires precisely where the def still resolves and nothing is broken. A
824
+ hand-written schema served through any OTHER `DataSource` — the break surface —
825
+ reaches a reader raw: it never passes through this code and produces **no
826
+ warning at all**. On that path the failure is exactly as silent as before.
827
+ A reader-side or shared-resolver diagnostic, which would cover it, remains open
828
+ on objectui#6837.
829
+
830
+ ⚠️ **Dated note, 2026-09-29 — the call-site count above has since moved —
831
+ objectui#7650.** "exactly two production call sites" above held when this change landed
832
+ (`045d20ba8`). Later in this same release objectui#7650 (PR objectui#8868) added a call
833
+ on `MetadataProvider`'s by-name object-schema serve path. Re-measured for objectui#10979
834
+ on `main` at `2eaf5be27`, `normalizeSchemaReferenceKeys` had three production call sites:
835
+ two in `MetadataProvider`, on its list path and on its by-name path, and one in
836
+ `ObjectStackAdapter.getObjectSchema`.
837
+ `.changeset/7650-metadata-item-reference-canonicalisation.md` (PR objectui#8868) states
838
+ what ships; the text above is kept as the reading of this change.
839
+
840
+ ## What did NOT change
841
+
842
+ **Every key these readers EMIT is byte-identical**, and that was verified
843
+ mechanically over the whole diff rather than asserted. Eleven of the sixteen
844
+ sites write a target onto a bag whose own contract spells it `reference_to` (or
845
+ camelCase `referenceTo`): the six whose read and write share a line —
846
+ `RecordDetailDrawer`, `RelatedList`, `buildDefaultPageSchema`, `ListView`,
847
+ `FilterConditionField`, `resolveActionParams` — plus five more that read on one
848
+ line and emit on another, and so are just as much emitters: `RecordDetailView`,
849
+ `RecordMetaFooter`, `ObjectGallery`, `fieldEnrichment` (all `reference_to`) and
850
+ `UserFilters` (`referenceTo`). Only the right-hand read narrowed anywhere; the
851
+ emitted key is what its target contract declares, and renaming it would be a
852
+ separate change.
853
+
854
+ **Three readers were deliberately left alone.** `LookupCellRenderer`
855
+ (`fields/src/index.tsx`), `LookupField` and `UserField` read `FieldMetadata` —
856
+ ObjectUI's OWN contract, whose `LookupFieldMetadata` declares `reference_to` and
857
+ never declares `reference`. They are fed by the emitters above and by published
858
+ example schemas (`examples/schema-catalog/src/schemas/fields-lookup/*.json`), so
859
+ narrowing them would break in-repo producers, and `plugin-grid`'s
860
+ `relationalMetaCopySet.derivation.test.ts` re-derives its read set from exactly
861
+ those three sources — where `reference_to` is recorded with verdict
862
+ `adapter-stamped`. `DetailViewFieldSchema` is likewise untouched.
863
+
864
+ ⚠️ **Dated note, 2026-09-30 — the stamp, the three readers and the emitted key have since moved — objectui#11070.** Later in this same release objectui#11070 (round 4) retired `reference_to` inside ObjectUI as well. `normalizeFieldReferenceKeys` now FOLDS a legacy `reference_to` / `referenceTo` onto `reference` and no longer stamps `reference_to`, so "Stamping is deliberately unchanged" and "stamp both snake_case keys" above no longer describe what ships. `LookupCellRenderer`, `LookupField` and `UserField` read `reference` only; `LookupFieldMetadata`, `MasterDetailFieldMetadata` and `DetailViewField` (with `DetailViewFieldSchema`) declare `reference`; and the emitters listed under "What did NOT change" write `reference`. A hand-written schema served through a `DataSource` other than `ObjectStackAdapter` that spells only `reference_to` therefore also loses the lookup picker's target and the read cell's name. `.changeset/11070-reference-to-round4.md` states what ships; the text above is kept as the reading of this change.
865
+ - bf244f4: Size the gantt task list from its container, and give a row's dates ONE predicate
866
+ (objectui#7204, objectui#7224; maintainer ruling 2026-09-02, option Y).
867
+
868
+ **A row could show no dates at all.** Two gates decided whether a row's dates were
869
+ painted, and they read two different widths. The Start/End columns were gated on the
870
+ container-derived task-list width; the `8/26 → 9/2` sublabel under the title was gated
871
+ by the component's own `@media (min-width: 640px) { .gantt-sm-hidden { display: none } }`
872
+ rule, which reads the viewport. Between a 640px and a 1023px container both were shut,
873
+ so the row's dates existed in the DOM twice and were painted zero times. The same hole
874
+ opened at any width once the splitter was dragged under the threshold.
875
+
876
+ The sublabel now renders on exactly the complement of the Start/End columns, both from
877
+ the same container-derived width, and the media rule is gone. A row always carries its
878
+ dates one way or the other.
879
+
880
+ **And the task list no longer caps at 320px.** From a 1024px container up, the pane
881
+ takes 3/8 of the container clamped to `[320, 560]` instead of a flat 320. At 1440 that
882
+ is 540px, which leaves the title 287px with the Start/End columns still painted — a
883
+ 40-character title measures 262px in the row's font, so real-world task names stop
884
+ truncating to about seven characters while several hundred pixels of chart sit empty.
885
+ Measured in Chromium at a 1440px container: title 53px before, 287px after.
886
+
887
+ The Start/End threshold moves from an estimated 280 to a derived **412** — 32 row
888
+ padding + 160 for the two columns + 28 for the open-details slot + 32 of title
889
+ furniture + 160 minimum title, each term traced to the markup that spends it. Below it
890
+ the sublabel carries the dates. One consequence worth stating: between a 1024px and a
891
+ 1097px container the columns are now off and the dates ride the sublabel, which trades
892
+ two 80px date cells for a title that grows from 67px to 291px.
893
+
894
+ Not fixed here, and unchanged: a row's `depth * 14` indent is unbounded, so no single
895
+ default keeps a deeply nested row legible.
896
+ - 7c3df8f: A non-grid view's fetch now carries a platform row ceiling, and crossing it is
897
+ never silent (objectui#7210, maintainer ruling a′, 2026-09-02).
898
+
899
+ Before this, `ObjectGantt`, `ObjectCalendar`, `ObjectMap` and `ObjectTree` each
900
+ issued a `find` with **no `$top` at all**, so the request returned the entire
901
+ filtered result set. At the 186 rows the card was filed from that is invisible;
902
+ on an object with 100k scheduled rows it is the whole table into the browser,
903
+ and nothing an author could write — `pagination.pageSize` included — could
904
+ bound a request that never carried a cap to begin with.
905
+
906
+ **What changed.** Those four fetches now ask for `NON_GRID_ROW_CEILING_TOP`
907
+ rows, draw at most `NON_GRID_ROW_CEILING` of them, and when the result set was
908
+ larger they render a footnote naming both numbers, verbatim as it renders:
909
+ *"Showing the first 2000 of 41234 records. Narrow the filter."* Below the
910
+ ceiling nothing changes: the full set draws and no footnote appears.
911
+
912
+ The four view packages take a **minor**, not a patch: a result set above the
913
+ ceiling is no longer drawn in full, which is a behaviour break whatever the
914
+ fixed group does to the released version number.
915
+
916
+ **The ceiling is a platform constant, not an authorable key** — `2000`, exported
917
+ from `@object-ui/react` as `NON_GRID_ROW_CEILING`. An authored `limit` or
918
+ `dataSource: { limit }` still does not reach these queries, by the same ruling;
919
+ three alternatives were rejected with it (a documentation note only — still the
920
+ whole table; truncating at `pageSize` — silent, and a complete schedule capped
921
+ at one page; an authorable `maxRows` — a new permanent key every author sets).
922
+
923
+ **Why 2,000.** One constant for all four, so the binding view sets it. Measured
924
+ in this repo's jsdom lane: gantt, calendar and map hold their DOM flat as rows
925
+ grow (virtualised task list; four events per day cell; auto-clustering above
926
+ 100 markers), while `ObjectTree` flattens every expanded node into the document
927
+ at a linear **5.2 DOM elements per record** with no virtualisation. 2,000 rows
928
+ is where the worst of the four lands at ~10,400 elements — an order of
929
+ magnitude above Lighthouse's "excessive DOM size" warning, and still ~10x the
930
+ real application result set this card came from.
931
+
932
+ New exports on `@object-ui/react`: `NON_GRID_ROW_CEILING`,
933
+ `NON_GRID_ROW_CEILING_TOP`, `applyNonGridRowCeiling`, `NonGridRowCeilingNote`
934
+ and the type `NonGridCeilingResult`. Two new `common.*` i18n keys carry the
935
+ footnote copy in all ten packs.
936
+ - db3896c: `ObjectGantt` refreshes in place when its query really changes, instead of tearing the chart down to the loading placeholder (objectui#7237).
937
+
938
+ Once the chart has painted, a change to its sort, filter, permissions, search or bound source re-runs the query with the chart still mounted, so it keeps its scroll position, its collapsed groups and any inline edit in progress. While the query runs, a thin indeterminate bar over the chart marks the rows on screen as the previous answer, and the rows are replaced when the new answer lands. It is the same `RefreshIndicator` that `ObjectGrid`, `ListView` and `ObjectChart` draw over their rows. The initial load still shows the loading placeholder.
939
+
940
+ The bar also shows during the chart's other in-place re-reads: the toolbar refresh, the re-read after a drag, a dependency link, a delete or a field edit, and a re-read triggered by the data-invalidation bus. Those already kept the chart mounted, but the only sign of them was a disabled refresh button.
941
+
942
+ A changed query that fails is still reported as an error, as it was before. Only a re-read of the same query keeps its last good rows when it fails.
943
+
944
+ `@object-ui/i18n`: new key `gantt.aria.refreshing`, the bar's accessible name, in all ten locale packs.
945
+ - b041b9c: `@object-ui/core` publishes `resolveRecordSourceObjectName`, the ONE reader for "which
946
+ object is this block bound to".
947
+
948
+ Six view plugins each spelled that resolution locally — `ObjectCalendar` twice,
949
+ `ObjectGantt`, `ObjectTree` twice, `ObjectMap`, `ObjectGrid` — and had drifted: three
950
+ wrote `?? schema.objectName`, one `|| ''`, one `: undefined`, one an `'object' in
951
+ dataConfig` test. They now delegate to one function that states the published
952
+ record-source ladder `77cb489b4` declared (`data`, then `staticData`, then `objectName`) once.
953
+
954
+ **No behaviour changes.** Each site's pre-collapse expression is transcribed verbatim
955
+ into `record-source.behaviourNeutrality-7627.test.ts` and asserted equal to its
956
+ post-collapse spelling across the whole contract-valid input matrix — both bindings
957
+ present, data only, `objectName` only, empty `objectName`, empty `data.object`, the
958
+ `api` / `value` / `staticData` / array-shorthand providers, and nothing bound.
959
+
960
+ **Two questions stay two questions.** `normalizeListViewSchema`'s gap-fill (#7477,
961
+ ruling B, landed as `00d2fa682`) is untouched and is NOT re-pointed at the new reader: it answers
962
+ how `objectName` gets POPULATED when absent, where an already-present `objectName` wins.
963
+ The new reader answers which object a block RESOLVES, where the `data` block wins — the
964
+ order declared on both published faces in `@object-ui/types` and pinned by
965
+ `objectql-record-source-refinement-6939.test.ts`. Merging them would silently override
966
+ one standing ruling or the other.
967
+
968
+ **`ObjectGantt`'s `persistLayoutKey` is deliberately excluded** and keeps its inverted
969
+ order, with an in-place comment saying why: its receiver is a localStorage key
970
+ (`gantt-layout:KEY:filters`), not a record source, so re-pointing it would orphan every
971
+ saved layout and filter-chip set of a view carrying both bindings. Two more sites the
972
+ finding listed are not object-name readers at all and were struck: `ObjectGantt`'s
973
+ refresh-handler predicate (`object` OR `api`) and `plugin-dashboard`'s `isObjectProvider`
974
+ type-guard over a widget's `data`.
975
+
976
+ `useSettledSchema`'s doc comment stops prescribing the hand-written ladder at all four
977
+ lines that taught it, so the copies cannot re-seed from the hook that replaced them.
978
+ - edea22a: **BREAKING** — `SchemaRendererProvider`'s `dataSource` prop, and the context
979
+ type every `useSchemaContext()` consumer reads back, are the published
980
+ `DataSource` contract instead of `any`.
981
+
982
+ **FROM** `dataSource={anything}` **TO** `dataSource={adapter}` — a `DataSource`
983
+ from `@object-ui/types`, or `null` / `undefined` when the host has no adapter
984
+ bound.
985
+
986
+ ```ts
987
+ // before — compiled, and failed at runtime on the first find()
988
+ <SchemaRendererProvider dataSource={'not-an-adapter'}>
989
+ // before — compiled, and no reader can do anything with it
990
+ <SchemaRendererProvider dataSource={{}}>
991
+ // after
992
+ <SchemaRendererProvider dataSource={adapter}> // a DataSource
993
+ <SchemaRendererProvider dataSource={undefined}> // "I have no adapter"
994
+ ```
995
+
996
+ Both sites are typed `DataSource | null | undefined` — the spelling
997
+ `useSettledSchema` in this same package already used. The two absences are part
998
+ of the contract, not a weakening of it: a Studio preview, a `kind:'react'` page
999
+ rendered before the host's adapter connects, and a widget probe driving
1000
+ `apiFetch` alone all render with nothing bound, and every reader in the tree
1001
+ already guards for it. What the union refuses is everything that is not an
1002
+ adapter: a string, an empty object, a plain data bag, a partial adapter missing
1003
+ a required member.
1004
+
1005
+ The measured cost, both halves, because the two `any`s have different blast
1006
+ radii (measured separately on `origin/main`, whole-repo type-check over the 33
1007
+ packages that depend on `@object-ui/react`):
1008
+
1009
+ - the **context type** — the `any` that reaches every `useSchemaContext()`
1010
+ reader — reds **7 diagnostics at 7 sites in 4 packages**, all of them
1011
+ production code or a mocked module factory.
1012
+ - the **provider prop** — the injection points — reds **52 diagnostics at 27
1013
+ sites in 11 packages**, all but one of them test doubles.
1014
+
1015
+ That ordering is the reverse of the prediction on the card: the context `any`
1016
+ was expected to be the expensive one because it infects the whole tree, and it
1017
+ is the cheap one, because every reader in the tree already guarded and none of
1018
+ them ever reached past `find` / `getObjectSchema`. The prop is the expensive
1019
+ one, because the injection points are overwhelmingly test doubles that were
1020
+ never complete adapters. The full accounting is on objectui#7912.
1021
+
1022
+ Two runtime behaviours change, both in the "no adapter" direction and both
1023
+ strictly closer to what the surrounding code already intended:
1024
+
1025
+ - `@object-ui/components`' `kind:'react'` page passed an empty object as its
1026
+ "no adapter yet" stand-in. An empty object is TRUTHY, so it walked past every
1027
+ `if (!dataSource)` guard written to catch exactly that state and failed later,
1028
+ at the call. It now passes the absent adapter itself, so the guard fires where
1029
+ it was meant to. The module-constant identity that stand-in existed for is
1030
+ preserved: `null` is a primitive, so the provider's memo is unaffected.
1031
+ - `@object-ui/plugin-calendar`, `@object-ui/plugin-gantt` and
1032
+ `@object-ui/plugin-kanban` collapse a `null` adapter from the context to
1033
+ `undefined` before handing it to their widget, whose prop declares the single
1034
+ spelling `dataSource?: DataSource`.
1035
+
1036
+ Nothing else moves at runtime: no value flowing through this key changes, and
1037
+ no data path is touched. A TypeScript consumer outside this repo that handed
1038
+ this prop something other than an adapter now gets a compile error naming the
1039
+ key (TS2322 / TS2739 / TS2740), which is why the FROM/TO is spelled out above.
1040
+
1041
+ Five `as any` reads of this context in `@object-ui/fields` are gone — they were
1042
+ redundant the moment the seam became honest — and `LookupField`'s local
1043
+ re-declaration of the imported context as a `Context` of `any`, which laundered
1044
+ its `dataSource` read while looking typed, is gone with them. Both directions of
1045
+ the contract are pinned against the real compiler in
1046
+ `SchemaRendererContext.dataSourceType.pin.test.ts`, and the card's planted
1047
+ documentation probe (a bare string in `packages/react/README.md`'s provider
1048
+ example) now fails `pnpm check:doc-snippets`, where it used to exit 0 with zero
1049
+ diagnostics.
1050
+
1051
+ objectui#7912.
1052
+ - 233a1b3: Declare the `filter` and `sort` inputs on the `object-map`, `object-gantt`,
1053
+ `object-timeline` and `view:timeline` registrations (objectui#8220) — the html
1054
+ tier stops reporting `unknown-prop` on two keys the spec declares and all three
1055
+ renderers read.
1056
+
1057
+ objectui#7712's and objectui#8171's defect, three blocks over. `ObjectMap`,
1058
+ `ObjectGantt` and `ObjectTimeline` each lower the authored keys onto their own
1059
+ query — `$filter` (the authored `filter`, its context tokens resolved first) and
1060
+ `$orderby: convertSortToQueryParams(schema.sort)` — but none of the four
1061
+ registrations publishing those renderers listed either key in `inputs`, and
1062
+ `sdui-parser`'s `validateTree` reports `unknown-prop` for every key no `inputs`
1063
+ entry claims. An author writing the spelling that works was told it was unknown.
1064
+
1065
+ Unlike the kanban and calendar cases, these three blocks had no spec row when the
1066
+ defect was filed, so declaring the keys then would have published an authoring
1067
+ surface no contract backed. That order is now met on the installed package:
1068
+ `@objectstack/spec` 17.5.0 maps `object-map`, `object-gantt` and `object-timeline`
1069
+ in `ComponentPropsMap`, each row declaring `filter` as the `ViewFilterRule` array
1070
+ and `sort` as the `SortItem` array. ADR-0049 enforce-or-remove therefore resolves
1071
+ toward **declare**: both keys have live readers on both ends.
1072
+
1073
+ Both keys are declared `type: 'array'`. For `filter` that is the rule-array arm
1074
+ `[{ field, operator, value }, ...]` and nothing else: the spec refuses the
1075
+ MongoDB-style record form at all three doors, and with the key declared as an
1076
+ array the html tier now refuses it too, as a `type-mismatch`, instead of passing
1077
+ it as an unknown key. `sort` takes `[{ field, order }]`.
1078
+
1079
+ `view:timeline` declares the same pair as `object-timeline`: it is the same
1080
+ renderer under a second tag, the `view:calendar` precedent. The map's and the
1081
+ gantt's bare `view:` twins are already retired (objectui#10393, objectui#8008),
1082
+ so four registrations carry the declaration, not six.
1083
+
1084
+ Pinned per plugin in `__tests__/queryKeysDeclared-8220.test.tsx`: the real
1085
+ validator over a manifest built from the live registry, with an undeclared-key
1086
+ control; the installed spec row's verdict on the same values; and a mount through
1087
+ `SchemaRenderer` showing the rule array reach `$filter` and the sort items reach
1088
+ `$orderby` on every tag.
1089
+
1090
+ Not changed here: the console's `registry-inputs-spec-parity` ledger. It does not
1091
+ load these three plugins yet and books the blocks as unjudged, owed to
1092
+ objectui#11168, so this change moves none of its rows.
1093
+
1094
+ **Note, 2026-10-02 (objectui#11168 slice 5, shipping in this same release).**
1095
+ The last paragraph above says the console's `registry-inputs-spec-parity` gate
1096
+ does not load these three plugins yet and books the blocks as unjudged. That no
1097
+ longer holds for the release: objectui#11168 loaded all three in this same
1098
+ release (`object-map` in slice 3, `object-gantt` in slice 4, `object-timeline`
1099
+ in slice 5), so the gate judges each registration in both directions, and its
1100
+ unjudged-block ledger books none of them. This change itself still moved none
1101
+ of those rows.
1102
+ - 91facae: **Breaking behaviour change — a view block now honours only the `data` spelling its published row declares.**
1103
+
1104
+ 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.
1105
+
1106
+ ⚠️ **`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).
1107
+
1108
+ **Per block — what the published row says, and what actually moves:**
1109
+
1110
+ - **`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`.
1111
+ - **`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.
1112
+ - **`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.
1113
+ - **`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.
1114
+ - **`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.
1115
+
1116
+ 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.
1117
+ - a1c00e3: Honour `filter`, `sort` and the platform row ceiling on a gantt's inline
1118
+ (`provider: 'value'`) data (objectui#8769).
1119
+
1120
+ **The defect was fail-open.** `ObjectGantt`'s `reload` short-circuited the
1121
+ inline provider — it set the authored rows and returned BEFORE the adapter
1122
+ query, which is the one site that lowers `schema.filter` to `$filter`,
1123
+ `schema.sort` to `$orderby` and the objectui#7210 ceiling to `$top`. So an
1124
+ inline gantt that declared a `filter` drew **every** authored row, with no
1125
+ diagnostic. The key that was dropped is the key that NARROWS, which is why this
1126
+ matters: the chart answered a wider question than the author asked. ⛔ Nothing
1127
+ was exposed that was not already in the authored schema — this is a
1128
+ correctness defect, not a data-access one.
1129
+
1130
+ Measured two-sided before the repair: the same five rows and the same
1131
+ `status = open` filter drew 3 rows through a fetching data source and 5 rows
1132
+ inline, with the same matcher on both sides.
1133
+
1134
+ **What changed.** The inline branch is gone; `provider: 'value'` now goes
1135
+ through `resolveDataSource`'s `ValueDataSource` like every other provider,
1136
+ which already implements `$filter` / `$orderby` / `$skip` / `$top` / `$select`
1137
+ over its own array. No filter combinator was written for this change.
1138
+
1139
+ **Behaviour you may notice.**
1140
+
1141
+ - An authored `filter` / `sort` now narrows and orders inline rows. Both
1142
+ spellings reach it: `data: { provider: 'value', items }` and `staticData`.
1143
+ - The row ceiling now applies to inline rows: past 2,000 drawn rows the chart
1144
+ draws 2,000 and shows the footnote naming both numbers, as it already did for
1145
+ fetched rows. It is applied to the **filtered** set, so a large inline array
1146
+ that a `filter` cuts below the ceiling draws every matching row and stays
1147
+ quiet. Rows a host passes down through the `data` React prop are still never
1148
+ capped — those are not ours to cap.
1149
+ - Inline rows now reach the chart as the adapter's own deep copy rather than as
1150
+ the authored array's object identities. `ViewData.items` is serializable
1151
+ metadata, so every value the contract admits survives that copy unchanged;
1152
+ code comparing a row handed to `onTaskClick` against the authored array with
1153
+ `===` would need `id` equality instead.
1154
+ - An inline gantt's own write-backs (drag, dependency edit, inline edit,
1155
+ delete) now survive the reload that follows them, because the reload reads
1156
+ the adapter that took the write instead of re-reading the authored array over
1157
+ the top of it.
1158
+ - A filter comparand that `@object-ui/core`'s `convertFiltersToAST` refuses does
1159
+ **not** throw at render on this path: the inline matcher is local and never
1160
+ reaches that converter. The row is excluded and the reason is logged once.
1161
+ - 093af32: Take the `@objectstack/*` line to 17.4.0 and follow every contract it moved
1162
+ (objectui#8772, with #7783 · #7663 · #8172 · #7845 · #8785).
1163
+
1164
+ **Breaking on one authored key, deliberately.** A dashboard node's
1165
+ `refreshInterval` is now `refreshIntervalSeconds` — the value is unchanged
1166
+ (seconds), and the spec refuses the old spelling by name with a message naming
1167
+ the new one, so an existing document fails loudly at parse rather than silently
1168
+ losing its auto-refresh. `os migrate meta --from 17` lists the mechanical edits.
1169
+ The report component's own `refreshInterval` is a different key and is NOT
1170
+ affected. (Scored `minor`, not `major`: this repo's fixed group tracks the
1171
+ `@objectstack` major — AGENTS.md §版本号策略.)
1172
+
1173
+ Also authored-surface changes, all following a published spec move rather than a
1174
+ local decision:
1175
+
1176
+ - `element:record_picker`'s `filter` input is now the `ViewFilterRule` array
1177
+ form `[{ field, operator, value }, …]`. The MongoDB-style record form is
1178
+ refused by the contract (objectstack#14406 converged the last record-form
1179
+ `filter` in the map), so a JSX page writing the array form no longer draws a
1180
+ false `type-mismatch` and one writing the record form is told.
1181
+ - `object-kanban` now publishes `limit`, the row cap its renderer has always
1182
+ lowered to `$top`. The spec declares it as of objectstack#16503, so the key
1183
+ the docs teach is finally one the save gate stores.
1184
+ - `object-gantt`'s ten extension keys (`timeSegments`, `interactions`,
1185
+ `lockField`, …) are derived from the spec's `GanttConfigSchema` instead of
1186
+ being re-declared locally. Same accept set on the flat face; the nested
1187
+ `gantt` block narrows to the spec's, which now refuses an undeclared sub-key
1188
+ by name where its `.passthrough()` window used to admit one.
1189
+ - The console's preview-gallery samples — the worked examples an author copies —
1190
+ move with two spec changes of their own: a job's `timeout` is now `timeoutMs`
1191
+ (same unit-in-the-key-name ruling as the dashboard key above), and a flow's
1192
+ end node writes `outcome: 'completed'`, the enum having narrowed to
1193
+ `completed | refused`.
1194
+ - adf5812: Four node type keys retire, and the kanban and gantt families converge on their
1195
+ `object-*` spellings: `kanban` (objectui#8802), `kanban-ui` and `kanban-enhanced`
1196
+ (objectui#8257), and `gantt` (objectui#8008). All four were ruled by the
1197
+ maintainer in one batch on 2026-09-09.
1198
+
1199
+ **⛔ No stored document moves.** The strings `kanban` and `gantt` name two
1200
+ different things at two different layers, and only one of them is retiring:
1201
+
1202
+ | layer | value | who writes it | retired? |
1203
+ | --- | --- | --- | --- |
1204
+ | stored `NamedListView.type` | `"kanban"`, `"gantt"` | `CreateViewDialog`, persisted per tenant | **no — untouched** |
1205
+ | node type key | `kanban`, `gantt` | hand-authored JSON | **yes** |
1206
+
1207
+ `ObjectView`'s `switch (viewType)` maps a stored view type onto the node type it
1208
+ renders, and it already emitted `object-kanban` and `object-gantt` — as it does
1209
+ for all twelve stored view types. So every kanban and gantt view any user ever
1210
+ created through the console already renders through the surviving spelling.
1211
+ Nothing in a tenant database changes, and ⛔ nothing should be migrated there.
1212
+
1213
+ **What each retirement was, measured.** Three of the four were
1214
+ registration-only: no schema face in `@object-ui/types` ever declared
1215
+ `kanban-ui`, `kanban-enhanced` or `gantt` as a component node type, so
1216
+ unregistering is the whole retirement. The bare `kanban` key was the exception —
1217
+ it had a declared arm on both faces (`KanbanSchema` in `complex.ts` and its Zod
1218
+ mirror), and a plain deletion there would have been the objectui#7664 failure:
1219
+ `BaseSchema` is `.passthrough()`, so a document naming a dropped key validates
1220
+ green and renders nothing. It therefore retires as a **named refusal**: the Zod
1221
+ union keeps an arm claiming the literal and answers a `{ "type": "kanban" }`
1222
+ document with a message naming `object-kanban` as the remedy, while the
1223
+ TypeScript half is the absence of the arm from `ComplexSchema` and of the key
1224
+ from `SchemaRegistry`, so `tsc` refuses it at the authoring site.
1225
+
1226
+ **⭐ This closes objectui#8818's `objectFields` hole — for that ENTRY, not for
1227
+ the class.** `SchemaRenderer` strips a fixed enumerated metadata list and
1228
+ spreads the rest as React props; `objectFields` is not on that list, and
1229
+ `KanbanRenderer` — the component the `kanban-ui` key resolved to — declares
1230
+ `objectFields` as a real prop, so an authored value reached the predicate layer
1231
+ with no schema face judging it. With the registration gone, no authored node
1232
+ reaches that component through the registry. ⚠️ The **class** is still open: the
1233
+ hole returns the moment another registered renderer declares an `objectFields`
1234
+ prop. objectui#8818's option (a) — stripping at the `SchemaRenderer` boundary —
1235
+ is what would close the class.
1236
+
1237
+ Superseded in this release by objectui#8818: option (a) landed, so the class
1238
+ is closed as well. `objectFields` is now on `SchemaRenderer`'s stripped-metadata
1239
+ list, and the legacy `props` alias bag drops it too, so an authored
1240
+ `objectFields` reaches no component prop on any type key. The paragraph above
1241
+ describes the tree this entry was written against.
1242
+
1243
+ **⚠️ What the `kanban` arm took with it, stated because it is the cost of this
1244
+ change.** That arm was the only schema face that ever declared `columns`,
1245
+ `cardTitle`, `swimlaneField`, `grouping` and `navigation`, the only one that
1246
+ refused `allowCollapse` / `cardTemplates` / `columnWidths` / `titleField` /
1247
+ `draggable` / `onColumnAdd` / `onCardAdd` by name, and — through
1248
+ `columns: KanbanColumn[]` — the only one that judged a lane's `cards`
1249
+ (`240b80f31`).
1250
+
1251
+ ⭐ **The sentence that stood here — «The surviving `ObjectKanbanSchema` face
1252
+ declares none of them» — is retired, and the two reasons it failed are DIFFERENT
1253
+ defects (objectui#9713).** It is replaced by a dated reading rather than silently
1254
+ overwritten, because half of it was true when written and erasing that would be a
1255
+ false record of its own:
1256
+
1257
+ | key named just above | on `ObjectKanbanSchema` when this entry was written (`adf581278`, 2026-09-10) | on `main`, 2026-09-17 | what moved |
1258
+ | --- | --- | --- | --- |
1259
+ | `columns` | not declared | **declared** | objectui#8913 (PR objectui#8989), six hours after this entry was written |
1260
+ | `cardTitle` | not declared | **declared** | objectui#9606 (PR objectui#9709) |
1261
+ | `titleField` | **declared** | **declared** | nothing — the sentence was never true of this key |
1262
+ | `allowCollapse` | **declared**, a live `z.boolean().optional()` | **declared**, as a `retirementTombstone()` | objectui#8801 retired it; it was declared on this face throughout |
1263
+ | `swimlaneField`, `grouping`, `navigation`, `cardTemplates`, `columnWidths`, `draggable`, `onColumnAdd`, `onCardAdd`, and a lane's `cards` | not declared | not declared | nothing |
1264
+
1265
+ ⇒ For `columns` and `cardTitle` the claim **ROTTED**: it was true on 2026-09-10 and
1266
+ was falsified afterwards by cards that had no reason to read this file. For
1267
+ `titleField` and `allowCollapse` it was **BORN FALSE**: those two are named above as
1268
+ keys the `kanban` arm refused BY NAME — which the surviving face indeed does not do
1269
+ — but the surviving face declared both of them the whole time, and «declares none of
1270
+ them» said otherwise. ⛔ Do not restate any of this in the present tense: a pending
1271
+ entry publishes verbatim into the CHANGELOG, and an undated present-tense claim
1272
+ about another file is the construction that failed here.
1273
+
1274
+ ⛔ Nothing about an `object-kanban` document changes: it was never judged by the
1275
+ `kanban` arm, so all of those keys have always ridden `BaseSchema`'s index
1276
+ signature there. What is gone is the `kanban` document that had them. Declaring
1277
+ them on `ObjectKanbanSchema` would WIDEN a published accept set, which is a
1278
+ maintainer ruling and not part of this one; every one of these readings is
1279
+ pinned where it can be seen rather than left to be rediscovered.
1280
+
1281
+ **Migrating.** Replace `"type": "kanban"` with `"type": "object-kanban"` and
1282
+ `"type": "gantt"` with `"type": "object-gantt"` in hand-authored documents. The
1283
+ `object-kanban` face requires `groupBy` and one of `bind` / `data` /
1284
+ `objectName`; a purely static board (lanes carrying their own cards, no record
1285
+ source) adds `"groupBy"` and `"data": []`. `kanban-ui` and `kanban-enhanced`
1286
+ have no authored documents anywhere in this repository to migrate.
1287
+
1288
+ **⚠️ The namespaced spellings retire with the registrations — `view:kanban` and
1289
+ `view:gantt` are the same two keys.** `ComponentRegistry.register(type, C,
1290
+ { namespace })` stores BOTH `namespace:type` and a bare-`type` fallback, so
1291
+ every one of these keys had a namespaced twin that goes with it:
1292
+
1293
+ | retired spelling | namespaced twin | author instead |
1294
+ | --- | --- | --- |
1295
+ | `kanban` | `view:kanban` | `object-kanban` |
1296
+ | `gantt` | `view:gantt` | `object-gantt` |
1297
+ | `kanban-ui` | `plugin-kanban:kanban-ui` | `object-kanban` |
1298
+ | `kanban-enhanced` | `plugin-kanban:kanban-enhanced` | `object-kanban` |
1299
+
1300
+ Both spellings are pinned as gone, each against a firing control on the
1301
+ surviving key, in `plugin-kanban/src/__tests__/kanban-family-registry-keys-retired-8257.test.ts`
1302
+ and `plugin-gantt/src/__tests__/bare-gantt-node-key-retired-8008.test.ts`.
1303
+
1304
+ **What an unmigrated `view:kanban` / `view:gantt` node now renders depends on
1305
+ the host.** In `apps/console` it renders the protocol **placeholder** panel, not
1306
+ the OBJUI-001 "Unknown component type" error: the console calls the opt-in
1307
+ `registerPlaceholders()` (`@object-ui/components`, `renderers/placeholders.tsx`)
1308
+ *after* its plugin registrations, `view:kanban` and `view:gantt` are both in
1309
+ that file's `PROTOCOL_COMPONENTS` list, and the placeholder only claims a key
1310
+ nothing else has taken — which, until this change, `@object-ui/plugin-kanban`
1311
+ and `@object-ui/plugin-gantt` had. In every other host, which does not call that
1312
+ bootstrap, the same node renders OBJUI-001.
1313
+
1314
+ **⚠️ `objectui check` will NOT flag either namespaced spelling.** The CLI's
1315
+ `known-schema-types.ts` is generated from the repository's real registration
1316
+ calls, and the placeholder registration is a real one — so `view:kanban` and
1317
+ `view:gantt` are still on that list and still validate green, while the node
1318
+ renders a placeholder rather than a board. The bare `kanban` / `gantt` entries
1319
+ DID leave the generated list; only the namespaced pair survives, and only
1320
+ because of the placeholder. Grep your documents for the namespaced spellings
1321
+ directly; do not rely on `objectui check` to find them.
1322
+
1323
+ `KanbanRenderer` is still exported from this package's entry point
1324
+ (`@object-ui/plugin-kanban`); only its registry key is gone. ⚠️ `KanbanEnhanced`
1325
+ is a different case, and the earlier draft of this note stated it wrongly: this
1326
+ package's `exports` map has exactly two entries — `.` and `./style.css` — and
1327
+ the barrel never re-exported the component, so
1328
+ `@object-ui/plugin-kanban/KanbanEnhanced` has never been a resolvable specifier
1329
+ for a consumer. At this change, with `kanban-enhanced` unregistered,
1330
+ `KanbanEnhanced.tsx` had zero non-test importers, and the file was deliberately
1331
+ left in place: deleting published-but-unreachable source is a further narrowing
1332
+ and needed its own maintainer ruling, which this change did not have.
1333
+
1334
+ ⚠️ **Dated note, 2026-09-25 — that ruling came, and the file has since been
1335
+ deleted — objectui#8932.** Later in this same release
1336
+ `packages/plugin-kanban/src/KanbanEnhanced.tsx` was deleted, and with it the
1337
+ `dist/KanbanEnhanced.d.ts` typings this package shipped for it. The rest of this
1338
+ entry is kept as the reading of this change; the objectui#8932 entry states what
1339
+ ships.
1340
+
1341
+ **⚠️ `@object-ui/sdui-parser`: `QUICK_ADD_HOST_TYPES` loses `kanban` with the
1342
+ registration.** The `inert-quick-add` diagnostic (objectui#8285) named the two
1343
+ tags `ObjectKanbanRenderer` answered to; one of them retires here, so the set is
1344
+ now `{ 'object-kanban' }`. ⛔ Nothing is silently dropped by that narrowing, and
1345
+ this is measured rather than argued: `checkKanbanQuickAdd` has exactly one call
1346
+ site — `validate.ts`'s per-prop walk — and that walk runs only in the branch
1347
+ where the manifest RESOLVED the tag. A tag no registration produces is answered
1348
+ one level up by `unknown-component`, an **error**, and its props are never
1349
+ walked, so on a manifest built from the live registry a `<kanban quickAdd>` node
1350
+ draws `error/unknown-component` and nothing else, against a firing control on
1351
+ `<object-kanban quickAdd>` that still draws `warning/inert-quick-add`. Keeping
1352
+ `kanban` in the set would have been reachable only through a hand-built manifest
1353
+ declaring a component of that name — which, after this retirement, is somebody
1354
+ else's component, and the message asserts things about `ObjectKanban` that would
1355
+ be false of it. This supersedes the `kanban` half of the objectui#8285 entry.
1356
+
1357
+ **The diagnostic's remedy text moves from a tag to a component.** It used to end
1358
+ "render `<kanban-ui>` from a React host that passes `onQuickAdd`". That sentence
1359
+ is falsified by this change: `kanban-ui` is no longer a node type key, so a page
1360
+ written to the old advice draws `unknown-component`. It now names
1361
+ `KanbanRenderer` from `@object-ui/plugin-kanban` — still exported, still
1362
+ forwarding both halves by identity — which is the surviving way to get the pair.
1363
+ `content/docs/plugins/plugin-kanban.mdx` says the same thing the same way.
1364
+ - 7098eed: One record-overlay shell: all five list-type renderers honour all four overlay
1365
+ `navigation.mode` values (objectui#9299, director seat decision batch #128 item
1366
+ 1, 2026-09-13).
1367
+
1368
+ `ObjectGantt`, `ObjectKanban` and `ObjectCalendar` rendered one drawer for every
1369
+ authored mode — `modal`, `split` and `popover` silently WERE the drawer, with no
1370
+ diagnostic. `RecordDetailDrawer`'s payload is extracted into the new
1371
+ `RecordDetailPanel` (shell-free by construction) and mounted through the shared
1372
+ `NavigationOverlay`, which is what `ObjectGrid` and `ObjectTree` already used.
1373
+
1374
+ User-visible on published surfaces:
1375
+
1376
+ - **`modal` / `split` / `popover` now do what they say** on the gantt, the
1377
+ kanban and the calendar.
1378
+ - **`split` renders.** Each renderer passes its own view as `mainContent`, so
1379
+ the board / calendar / chart / tree / grid sits beside the record panel.
1380
+ Authored `split` used to render NOTHING on `ObjectTree` — and, measured while
1381
+ fixing this, on `ObjectGrid` too.
1382
+ - **`popover` is anchored to the element the user clicked** — row, node, bar,
1383
+ card, event — instead of degrading to a centred dialog. It was honoured on no
1384
+ surface before.
1385
+ - **Drawer chrome converges** on the shared shell's header (breadcrumb title,
1386
+ close, optional expand) for the three renderers that brought their own.
1387
+ - **Drawer widths carry over, they are not reset.** The two drag-resize
1388
+ implementations become one: a width persisted under the retired
1389
+ `objectui.drawerWidth.OBJECT` is read once, written forward to
1390
+ `ov:drawer-width:OBJECT` and removed. One key per object across every view
1391
+ type. The default width is unchanged at every viewport (objectui#6584); an
1392
+ authored width below `min(60vw, 880px)` now widens to it, which is the shell's
1393
+ long-standing policy on grid and tree.
1394
+ - **Richer record body on grid and tree** — typed widgets, declared labels,
1395
+ honoured `hidden` — wherever the object declares its fields. With nothing
1396
+ declared those two renderers keep their own value-inference reading, which is
1397
+ what preserves the locale-aware date fallback (objectui#4541), the localized
1398
+ empty placeholder (objectui#8491) and the `format` hint (objectui#8920); the
1399
+ overlay shell is the shared one on that path too.
1400
+
1401
+ New published API: `RecordDetailPanel`, `buildRecordDetailFields`,
1402
+ `RECORD_OVERLAY_DEFAULT_WIDTH` (`@object-ui/plugin-detail`);
1403
+ `useOverlayAnchor`, `recordOverlayWidthStorageKey`,
1404
+ `legacyRecordDrawerWidthKey` and the `popoverAnchorRef` / `legacyStorageKey`
1405
+ props on `NavigationOverlay` (`@object-ui/components`). `RecordDetailDrawer`
1406
+ keeps its props and is now a thin wrapper over the shared shell. ⛔ No spec
1407
+ change.
1408
+ - 502eb58: The row/card click props on the view components now declare the modifier
1409
+ payload they have always been invoked with (objectui#9357).
1410
+
1411
+ `useNavigationOverlay`'s `handleClick` invokes the handler it is given with two
1412
+ arguments — the record, and an optional modifier payload (`metaKey` / `ctrlKey`
1413
+ / `button`) a host needs to implement Cmd/Ctrl/middle-click. objectui#9360 made
1414
+ the hook's own option say so. These components pass a host-supplied prop
1415
+ straight into that option, so the value a host writes against them is invoked
1416
+ with two arguments too — and every one of these props declared only the record.
1417
+ The payload was therefore invisible on the one line a host reads, exactly as it
1418
+ had been on the hook.
1419
+
1420
+ Thirteen declarations across nine packages now name both parameters:
1421
+
1422
+ - `ObjectGridComponentProps.onRowClick`
1423
+ - `ObjectKanbanComponentProps.onRowClick` (its sibling `onCardClick`, the other
1424
+ arm of the same fallback, already declared both)
1425
+ - `KanbanRendererProps.schema.onCardClick`
1426
+ - `ObjectCalendar`, `ObjectGantt`, `ObjectMap`, `ObjectTree`: `onRowClick`
1427
+ - `ObjectTimeline`: `onRowClick` and `onItemClick`, the two arms of one fallback
1428
+ - `ListView.onRowClick`
1429
+ - `ObjectGallery`: `onRowClick` and `onCardClick`, likewise two arms of one
1430
+ - `RelatedList.onRowClick`
1431
+
1432
+ **Source-compatible, and with no refused class.** A one-parameter handler is
1433
+ still assignable to the widened signature, and a handler written against the
1434
+ widened signature was already assignable to the narrow one — its minimum
1435
+ argument count is still one. The second parameter is spelled `any` rather than
1436
+ `HandleClickModifiers`, which is the difference that matters for callers: the
1437
+ hook's own option names that interface and therefore refuses a handler whose
1438
+ second parameter is annotated narrower (objectui#9360 documents that class and
1439
+ the one-line remedy). These faces refuse nothing. A host that discovered the
1440
+ payload from the implementation and annotated it `React.MouseEvent` — which is
1441
+ what actually arrives — keeps compiling. `any` is also the spelling
1442
+ `ObjectKanbanSchema.onCardClick` already carries for this same payload
1443
+ (objectui#9341) and the one `BaseSchema`'s own `onClick` / `onChange` /
1444
+ `onSubmit` use, and it is forced on the published twins in `@object-ui/types`,
1445
+ which may not name a type that lives in a package depending on them.
1446
+
1447
+ **Runtime behaviour is unchanged.** Nothing is newly called and nothing newly
1448
+ passes an argument; only the declarations move.
1449
+
1450
+ Three declarations that share the name and the shape are deliberately NOT
1451
+ widened, because the value flowing through them is not invoked with the
1452
+ payload: `VirtualGrid.onRowClick`, whose second parameter is a row index;
1453
+ `ManageViewsDialog.onRowClick`, which receives a view id; and the `data-table`
1454
+ family (`DataTableSchema.onRowClick`, `ObjectDataTableSchema.onRowClick`),
1455
+ whose renderer invokes with one argument. Widening those would have declared a
1456
+ payload that never arrives.
1457
+ - 199d31b: **`viewMode` is now declared authoring surface on `ObjectGanttSchema`, and both
1458
+ gantt renderer branches honour it** (objectui#5074, maintainer ruling
1459
+ 2026-08-19: declare-and-wire; the spec half landed first upstream).
1460
+
1461
+ - `ObjectGanttSchema` (TS interface and zod mirror) declares `viewMode`,
1462
+ DERIVED from the pinned `@objectstack/spec` `GanttConfigSchema.viewMode`
1463
+ enum by reference, so the member list cannot drift. Deliberately no
1464
+ default: an omitted `viewMode` keeps letting a persisted layout
1465
+ (`persistLayoutKey`) seed the timeline granularity before the renderer's
1466
+ `'day'` fallback.
1467
+ - The timeline branch (`GanttView`) now receives an authored `viewMode`.
1468
+ Previously only the resource-workload branch (`resourceView` +
1469
+ `assigneeField`) honoured it, so `viewMode: 'month'` on an ordinary gantt
1470
+ view was silently ignored.
1471
+ - The `(schema as any).viewMode` cast in `ObjectGantt` is retired; both
1472
+ branches read the declared `ganttConfig.viewMode`, which also honours the
1473
+ key when authored inside the spec's `gantt` config block.
1474
+ - Accept-set note: `viewMode` is now a DECLARED key, so an off-enum value
1475
+ (e.g. `viewMode: 'hour'`) becomes a zod validation error where it
1476
+ previously passed through unvalidated. Values on the published spec enum
1477
+ are unaffected.
1478
+
1479
+ ### Patch Changes
1480
+
1481
+ - 3759c56: Gantt, chart and grid views refresh in place after a write instead of being rebuilt (objectui#10035).
1482
+
1483
+ `ObjectGrid`, `ObjectGantt` and `ObjectChart` query for themselves and read no refresh input, so both object-view layers could show them a write only by remounting them — which lost a gantt's scroll, collapsed groups and zoom, a chart's open drill-down, and a grid's selection, column state and in-progress edit. Each now refetches when the data-invalidation bus (`notifyDataChanged` / `useDataInvalidation` from `@object-ui/react`) reports a change to the object it reads:
1484
+
1485
+ - `@object-ui/plugin-grid`: `ObjectGrid` re-reads its rows into the same table.
1486
+ - `@object-ui/plugin-gantt`: `ObjectGantt` re-reads silently and keeps the chart mounted, as its toolbar refresh does.
1487
+ - `@object-ui/plugin-charts`: `ObjectChart` re-runs its query on both binding shapes — an object-bound aggregate follows its `objectName`, a dataset-bound chart follows the dataset's base object as the `queryDataset` answer names it.
1488
+ - `@object-ui/plugin-view`: the object view keys every view on its identity alone, and declares on the bus its own saves and deletes and each `onMutation` write it hears.
1489
+ - `@object-ui/app-shell`: the object page keys its list and its chart view on identity alone, and declares on the bus the changes it learns of without a data-source write — server actions, flows, imports, realtime events and an explicit refresh.
1490
+
1491
+ Rows a host hands these components (`data`, `bind`, inline values) are still the host's to refresh; only the components' own queries follow the bus.
1492
+ - 75b0d0b: `ObjectGantt` no longer re-issues its record query because React threw a memo cache
1493
+ away (objectui#10036).
1494
+
1495
+ The fetch seam carried two dependencies that AGENTS.md §5 commandment #10 bans — the
1496
+ ninth and tenth instances of the class ruled on objectui#8640. `reload`'s dependency
1497
+ list named `effectiveDataSource`, a `useMemo` result, and the mount effect named
1498
+ `reload`, a `useCallback` result. Both hooks are documented performance hints: React
1499
+ may discard the cache and recompute even when the dependency list compares equal, and
1500
+ the object that comes back is then a new one.
1501
+
1502
+ That is not harmless here. `resolveDataSource` returns the context adapter UNCHANGED
1503
+ for `provider: 'object'`, but CONSTRUCTS a fresh `ApiDataSource` / `ValueDataSource`
1504
+ for `provider: 'api'` and `provider: 'value'` — so on those two providers a discard
1505
+ alone handed `reload` a brand-new adapter for a byte-identical authored config, rebuilt
1506
+ `reload`, and re-fired the mount effect: one redundant round trip per discard, on a
1507
+ view nobody had touched. A discarded `useCallback` moves `reload`'s identity whatever
1508
+ its own dependency list says, so the second half had to move with the first.
1509
+
1510
+ The record fetch now READS the adapter through a ref and KEYS on the values that
1511
+ determine it: the authored config slice `resolveDataSource` actually reads, per
1512
+ provider arm, plus the host's `dataSource` and `apiFetch`. Every authored or host
1513
+ change that used to refetch still refetches — a changed `api` endpoint, changed
1514
+ `read`/`write` config, changed inline `items`, a swapped adapter, a swapped
1515
+ authenticated fetch, a changed object, filter or sort. What no longer refetches is a
1516
+ discard, and an inert key inside `data` that the resolved adapter never reads.
1517
+
1518
+ The file already recorded half of this in the first person: `dataItems` came off that
1519
+ same dependency list because a discard «was enough to give `reload` a fresh identity
1520
+ and re-fire the mount effect below (objectui#6592)». One banned identity came off the
1521
+ line then; the other stayed on it until now.
1522
+ - 875ee61: fix(plugin-calendar, plugin-map, plugin-gantt): the registrations' `inputs` agree with the record-source rule
1523
+
1524
+ All three blocks read their records from one of `data`, `staticData` and
1525
+ `objectName` (in that order), and their `@object-ui/types` zod schemas enforce
1526
+ "one of the three" through `requireRecordSource`. The designer-facing `inputs`
1527
+ on the registrations disagreed with that rule in two ways:
1528
+
1529
+ - `object-calendar` and `calendar` still declared `objectName` as required, so
1530
+ the html tier's validator reported a `missing-required-prop` error on a
1531
+ calendar authored on `staticData` or `data`, which the schema accepts and the
1532
+ renderer draws. `objectName` is now declared without `required`, and its
1533
+ description states the rule, as objectui#7470 did for map and gantt
1534
+ (objectui#10392).
1535
+ - `object-map`, `map` and `object-gantt` did not declare `data` or
1536
+ `staticData`, so the validator reported a block authored on either as an
1537
+ unknown prop. At this change both were declared on all three, on the schema's
1538
+ own arms: `data` is a `{ provider, … }` data-source configuration (an object,
1539
+ so a bare array there draws a type diagnostic, matching the schema), and
1540
+ `staticData` is an array of records. Each description says what the renderer
1541
+ does with the key, including that the map does not implement the `api`
1542
+ provider (objectui#10394).
1543
+
1544
+ ⚠️ **Dated note, 2026-09-25 — the bare `map` registration has since been
1545
+ retired — objectui#10393.** Later in this same release `@object-ui/plugin-map`
1546
+ stopped registering the bare `map` key (and its namespaced twin `view:map`),
1547
+ so `map` declares nothing: a node authored `"type": "map"` resolves no
1548
+ renderer, and the html tier reports it as `unknown-component`. The
1549
+ `object-map` and `object-gantt` registrations keep both inputs exactly as
1550
+ described above. The rest of this entry is kept as the reading of this
1551
+ change; the objectui#10393 entry states what ships.
1552
+
1553
+ The renderers' read order and the zod schemas are unchanged. The
1554
+ `@object-ui/plugin-gantt` README sentence that listed the registration's inputs
1555
+ is updated.
1556
+
1557
+ **Correction, 2026-10-01 (objectui#11117).** "One of the three" now has an exception on all
1558
+ three blocks: a block that declares none of them is accepted when its `dataSource.object` names
1559
+ the object, because the registration's `ElementDataSourceGate` lands that name on `objectName`.
1560
+ The `objectName` input description now says so.
1561
+ - e5f4343: Four more date faces now follow the display locale, not the UI language (objectui#10442).
1562
+
1563
+ Each one takes its locale from `useDisplayLocale()` instead of the UI language. With an English UI and
1564
+ a `de-CH` display locale, a date that used to read `3/4/2020` now reads `4.3.2020`. With no display
1565
+ locale declared, the display locale falls back to the UI language, so these dates render as before.
1566
+
1567
+ - `data-table` (`@object-ui/components`): the ISO date and datetime cells.
1568
+ - The record page's History tab (`@object-ui/app-shell`): the `date` and `datetime` values in each
1569
+ field diff.
1570
+ - `ResourceWorkload` (`@object-ui/plugin-gantt`): the column labels and the cell tooltips. With no
1571
+ language at all it used to fall through to the machine's locale; it now gets the display locale's
1572
+ own last resort.
1573
+ - `CalendarView` (`@object-ui/plugin-calendar`): the default locale for the header, the weekday
1574
+ columns and the day cells. An explicit `locale` prop still wins over the display locale.
1575
+ - 2803fac: fix(plugin-gantt): a failed load no longer keeps `ObjectGantt` on its error screen after a later load succeeds
1576
+
1577
+ `ObjectGantt` sets `error` when the current reload fails, and the render returns
1578
+ the error screen early whenever `error` is set. Nothing ever cleared it. After one
1579
+ failed load (a filter or sort change against a flaky backend, say), every later
1580
+ load that succeeded still wrote its rows, but the chart stayed on the error screen
1581
+ until the component remounted.
1582
+
1583
+ The current reload now clears the error when it commits rows, whether it is a
1584
+ changed query or a silent re-read of the same one (a data-invalidation, say). Those
1585
+ rows answer the current query, so the earlier failure no longer describes the
1586
+ screen. A superseded reload's answer is discarded under the existing `isCurrent()`
1587
+ guard, and its clear is discarded with it, so it cannot remove an error the current
1588
+ reload reported.
1589
+
1590
+ The error is deliberately not cleared when a reload starts, although `ObjectGrid`'s
1591
+ load clears there. A silent re-read can overtake a changed query and then fail
1592
+ without reporting it. Had the changed query cleared the error when it started, the
1593
+ chart would go back to an older query's rows with nothing to say they are stale.
1594
+ Until rows that answer the current query land, the error stays on screen. Before the
1595
+ first paint the loading placeholder still shows while a query is in flight.
1596
+ - 9d89c6f: fix(plugin-gantt): a silent re-read that overtakes a changed query now reports that query's failure
1597
+
1598
+ `ObjectGantt` re-reads in two modes. A changed query (a sort, filter or search
1599
+ change) reports a failure on the error screen. A silent re-read of the same query
1600
+ (a data-invalidation, the toolbar refresh, or the read-back after a drag, resize or
1601
+ inline edit) only logs a failure and keeps the last good rows, because those rows
1602
+ still answer that query.
1603
+
1604
+ Only the newest re-read may commit, so a silent re-read that starts while a
1605
+ changed query is still in flight makes that query's run stale. The re-read reads
1606
+ the changed query too. When it failed, the chart kept the rows of the query before
1607
+ the change, with no error and no refreshing state. Those rows answer neither query
1608
+ the user asked for.
1609
+
1610
+ A silent re-read that overtakes a changed query in flight now takes over that
1611
+ query's report: its failure shows the error screen, as the changed query's own
1612
+ failure would. The report passes on if another silent re-read overtakes it, and it
1613
+ is released when the current re-read settles. The same holds for a silent re-read
1614
+ that overtakes the initial load, which used to leave an empty chart with no error.
1615
+ A silent re-read with nothing pending still only logs a failure and keeps its rows.
1616
+ No prop or export changes.
1617
+ - 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:
1618
+
1619
+ - `object-calendar`, `object-map` and `object-tree`, on both the object query and the inline (`provider: 'value'`) query;
1620
+ - `object-gantt`, `object-kanban` and `object-timeline`;
1621
+ - `record:related_list` and `record:line_items`, where the node's own filter is combined with the parent-record condition;
1622
+ - the `element:repeater`, `element:number` (both the `aggregate` filter and the `find` fallback) and `element:record_picker` page elements.
1623
+
1624
+ `list-view`, `object-grid` and `object-gallery` already did this, and are unchanged.
1625
+
1626
+ **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.
1627
+
1628
+ What changes for an app:
1629
+
1630
+ - A filter with no placeholders reaches the query as before, unchanged.
1631
+ - 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.
1632
+ - 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.
1633
+
1634
+ `@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.
1635
+ - 1659f14: The gantt timeline now follows the display locale, not the UI language (objectui#10668).
1636
+
1637
+ `GanttView` takes its date locale from `useDisplayLocale()` instead of the UI language. This covers the
1638
+ timeline's column and band headers, the toolbar's period label, the task list's start and end dates,
1639
+ a bar's hover card, and the dates shown while a bar is dragged. With an English UI and a `de-CH` display locale, a week column that used to read
1640
+ `3/2` now reads `2.3.`, the same locale `ObjectGantt`'s tooltips and `ResourceWorkload` already use in
1641
+ the same chart. With no display locale declared, the display locale falls back to the UI language, so
1642
+ the timeline renders as before. With no language at all, it used to fall through to the machine's
1643
+ locale; it now gets the display locale's own last resort.
1644
+ - db0beb2: docs(plugin-gantt): authored `object-gantt` examples write their props in the `properties` bag (objectui#10859, batch 6)
1645
+
1646
+ The README's authored `object-gantt` examples now write `{ "type": "object-gantt", "properties": { …, "gantt": { … } } }`, the spelling `@objectstack/spec`'s `ComponentPropsMap['object-gantt']` row declares and `objectui validate` now requires, with the field mapping in the bag's `gantt` block. The flat field-mapping keys are described as what they are, the handoff `ObjectView` and `ListView` write onto the node they compose. The examples that mount `ObjectGantt` directly keep the flat `schema` prop: a component mounted without `SchemaRenderer` receives the node as it reads it, and nothing hoists a bag there. Under `src/`, a new render pin holds that the bag draws what the flat spelling drew, and the catalog-plans pin reads the catalog entries' bag. No runtime change.
1647
+ - 6650259: fix(plugin-calendar): a day event moved across a DST change writes the days it was dropped on (objectui#10866, slice 4)
1648
+
1649
+ - **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.
1650
+
1651
+ ⚠️ **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.
1652
+ - **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.
1653
+
1654
+ ⚠️ **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.
1655
+ - **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.
1656
+ - 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)
1657
+
1658
+ 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`.
1659
+
1660
+ - **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.
1661
+ - **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.
1662
+ - **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.
1663
+ - **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.
1664
+
1665
+ The timeline, charts, formula date functions and i18n helpers are later slices of objectui#10866.
1666
+ - e119f12: fix(plugin-gantt): a gantt move shifts a task's end by the calendar days it shifts the start, keeping each value's time of day across a DST change (objectui#10866, slice 6)
1667
+
1668
+ On the day, week, month, quarter and year scales a drag snaps to whole days. The start moved by calendar days, but the end followed it by the elapsed milliseconds of the start's move, and a summary's group move carried every task beneath it by that same span. Across a DST change of the viewer's zone that span is a whole number of days plus or minus an hour. Under `America/Los_Angeles`, a `date` task from October 29th to October 31st moved three days wrote `end_date` `2026-11-02` where the drop reads November 3rd; a `datetime` end that crossed the change when its start did not moved its wall-clock time by an hour; a task under a moved summary could start on the day before the one it was dropped on. An edge drag past the other edge stopped 24 hours from it, which on a DST day is 23:00 of the day before, or 01:00.
1669
+
1670
+ - **Move.** A drag now counts the calendar days its snapped start moved and moves the start and the end by that many days on the local calendar. Each keeps its hours, minutes, seconds and milliseconds, as objectui#11005 ruled for the calendar's month grid, so a `date` task keeps its length in days and a 10:00 start stays at 10:00. This deliberately changes the instant a drag writes into a `datetime` end across a DST change; what a `datetime` field stores and how it is read are unchanged.
1671
+ - **Edge drags.** The end handle already moved the end by calendar days, keeping its time of day. An edge dragged past the other edge now stops one calendar day from it.
1672
+ - **Group move.** Dragging a summary moves the summary and every unlocked task beneath it by the same calendar days, and the live preview draws what the drop writes.
1673
+ - **Unchanged.** In a zone without DST every day is 24 hours, so a drag writes what it wrote before. The shift-band scale (`timeSegments` in day view) moves by bands on an elapsed-time axis and is unchanged.
1674
+ - f6ae5e2: fix(plugin-gantt): a zoned chart reads and writes a stored day as that day on a DST change (objectui#10866, slice 5)
1675
+
1676
+ A gantt with a business `timeZone` draws every date through a shim that re-bases it into that zone, and hands every dropped date back through the shim's inverse. Since this card's first slice, earlier in this same release, `ObjectGantt` has handed a date-only day in as the shim's inverse of the day's local midnight, and read a dropped `date` field back through the shim. Each direction reads the two zones' offsets at the instant it is handed, so on a DST day of one zone and not the other the round trip missed by an hour. An `America/Los_Angeles` viewer of an `America/New_York` chart saw a stored `2026-03-08` drawn from 23:00 on March 7th, and a drop onto March 8th wrote `2026-03-07`; `2026-11-01` was drawn from 01:00. A `Europe/Berlin` viewer of the same chart saw `2026-03-29` drawn from 23:00 on March 28th, and a drop onto it wrote `2026-03-28`.
1677
+
1678
+ - **plugin-gantt.** `ObjectGantt` now inverts the shim exactly for a day: it hands the view the instant the shim maps onto the day's local midnight, and writes the day of the display date the dropped instant was translated from. 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. Where the shim draws no instant at that midnight, as when the chart's zone changes its clocks at 00:00, the day is drawn from the first instant after it, on that day. A `datetime` value goes through the shim unchanged, and a chart with no `timeZone` is unchanged.
1679
+ - **types.** The `GanttConfig.timeZone` description said that near a DST change a day could be drawn, and a drop written, as the day before. It now says the day holds on a DST change too.
1680
+ - 0e6e76b: fix(plugin-gantt, plugin-calendar): the `objectName` input description names the `dataSource.object` binding (objectui#11117)
1681
+
1682
+ The designer-facing `objectName` input on `object-gantt` and `object-calendar` (and
1683
+ `view:calendar`, which shares the calendar's list) said the block's schema refuses a block that
1684
+ declares none of `data`, `staticData` and `objectName`. Since objectui#11117 the schema also
1685
+ accepts a block whose `dataSource.object` names the object, because the registration's
1686
+ `ElementDataSourceGate` lands that name on `objectName` before the renderer reads the node. The
1687
+ sentence now says so. No input's name, type, `required` flag or shape changed. (`object-map`'s
1688
+ input already names the binding: objectui#10859 batch 5 rewrote it.)
1689
+
1690
+ The `plugin-gantt` and `plugin-kanban` READMEs carry the same correction.
1691
+ - 858eafb: fix(plugin-gantt,core,plugin-timeline): both gantt surfaces read a date-only end inclusively through one core rule, and a drag writes the same day back (objectui#11141)
1692
+
1693
+ **A widening: `@object-ui/core` gains two exports**, `toDisplayEndDate(value)` and `toInclusiveEndDay(end)`, on its published entry beside `toDisplayDate` (the same file, `utils/date-display.ts`, re-exported by `export *`). Nothing else in `@object-ui/core` is added, removed, renamed or retyped.
1694
+
1695
+ - **A date-only end is inclusive on the object gantt too.** `ObjectGantt` read a stored end like a start, as the named day's local midnight, so every bar was drawn one day short and a successor starting the next day stood one day after its predecessor. The schema catalog's own plans drew that way. A task from `2024-01-01` to `2024-01-15` now runs through January 15th, and a successor starting `2024-01-16` begins exactly where it ends, as the timeline's gantt already drew it (objectui#11112). A task whose date-only start and end name the same day is now one day long, where it was a zero-length milestone. An end with a time part is still an instant, and the bar ends exactly there. Baseline ends read the same way.
1696
+ - **One rule, in `@object-ui/core`.** `toDisplayEndDate` reads an end: a date-only value becomes the start of the next day (a calendar day, so 23 or 25 hours across a DST change), and anything else is read as `toDisplayDate` reads it. `toInclusiveEndDay` is its exact inverse: it names the last day a span ending at an instant runs through. The timeline's gantt and `ObjectGantt` both read their ends through the first, so they cannot drift apart again. A day whose OWN midnight does not exist in the viewer's zone (`America/Santiago` on 2026-09-06, which starts at 01:00) now ends at the next day's midnight; the timeline used to end it at 01:00 of that next day. A day whose NEXT midnight does not exist (2026-09-05 there) still ends at the next day's first hour, as it did.
1697
+ - **A drag writes the day the bar runs through.** A dragged or resized bar whose end lands on a day's midnight writes the day before it into a date-only end field, so reading, dragging and writing a stored `2024-01-15` leaves `2024-01-15`. This also holds under a business `timeZone` whose clock skips a midnight. A `datetime` end still writes its instant.
1698
+ - **The view names that day.** `GanttView`'s End column, row date line, tooltip, drag preview and inline editor now name the last day a bar runs through, and the tooltip's day count includes it. Pressing Enter on an untouched row in the inline editor commits the end it started with. An end inside a day still names that day, and a zero-length task still names its own day. An embedder that passes `GanttView` a `Date` end directly now sees that end named as the last day the bar covers. A local-midnight end is named as the day before, which is where its bar already stopped.
1699
+ - With `autoZoomToFilter: false`, the pinned range ends on the last day any task runs through, and no longer adds an empty day column after it.
1700
+ - c1763e5: fix(plugin-gantt): a number row in the gantt tooltip shows the field's declared decimals, and none when it declares none
1701
+
1702
+ A tooltip row over a `number` field (and the `integer`, `float` and `decimal`
1703
+ spellings the tooltip groups with it) always read two decimals, whatever the field
1704
+ declared. A field declaring `scale: 3` read `1.50`, a field declaring `scale: 0` read
1705
+ `1.50`, and a `number` with no `scale` read `1.50` while the list cell for the same
1706
+ value read `1.5`. The row now reads the field's width through `resolveFieldScale`
1707
+ from `@objectstack/spec/data`, as the list cell does. A declared `scale` is that
1708
+ width. A field with no `scale` shows the value as stored (`1.5`, `12`, `7`), because
1709
+ the protocol gives these types no default width.
1710
+
1711
+ Only the decimals change. The row still uses the display locale, and it still groups
1712
+ thousands as before.
1713
+ - b149617: fix(plugin-gantt): a percent row in the gantt tooltip shows the field's declared decimals
1714
+
1715
+ A tooltip row over a `percent` field declaring `scale: 2` read whole percents
1716
+ (`12%`) while the list cell for the same value read `12.34%`. The row now reads
1717
+ the field's width through `resolveFieldScale` from `@objectstack/spec/data`, as
1718
+ the list cell does. A percent that declares no `scale` is unchanged.
1719
+
1720
+ `@object-ui/plugin-gantt` raises its `@objectstack/spec` floor to `^17.5.0`,
1721
+ the first release exporting `resolveFieldScale`.
1722
+ - 31987bd: Three more reader sites stop riding `BaseSchema`'s index signature (objectui#11355 round 2, part of the preparation for objectui#8347's removal of that signature). None changes runtime behaviour.
1723
+
1724
+ **`ActionBarSchema`, the `action:bar` node, is now exported by `@object-ui/types`.** It used to be declared in `@object-ui/components`' `renderers/action/action-bar.tsx`, which is not on that package's entry, so a host could not import it. It now lives in `@object-ui/types`' `ui-action.ts`, beside `UIActionSchema`: `actions` and `systemActions` are `UIActionSchema[]`, and `location` is `@objectstack/spec`'s `ActionLocation`. It declares no `[key: string]: any`, so a literal typed `ActionBarSchema` may write only its declared members, which are the keys the renderer reads. The renderer imports it from `@object-ui/types`, and its parameter annotation keeps its own index signature for the DOM pass-through (objectui#4422). `@object-ui/components` adds no export.
1725
+
1726
+ **`ObjectChartSchema.isAnimationActive?: boolean` is declared on the TypeScript face.** Code sets it `false` for a render with no entrance animation: `DashboardRenderer` and `DashboardGridLayout` on the `object-chart` nodes they build, and `DatasetWidget` and `DatasetReportRenderer` on the nodes they hand the `chart` registration. `ChartRenderer` honours it. The zod mirror declares no member for it, so it is not an authoring key; `zod-mirror-parity.test.ts` files it as runtime-only.
1727
+
1728
+ **Typed where they stand.**
1729
+
1730
+ - `@object-ui/app-shell`: the list-toolbar `action:bar` nodes in `EnvironmentListToolbar`, `InterfaceListPage` and `ObjectView` are built as `ActionBarSchema` values before they reach `SchemaRenderer`.
1731
+ - `@object-ui/plugin-gantt`: `ObjectGantt`'s dev warning about flat gantt keys that a `gantt` block shadows reads those keys off `ObjectGanttSchema`, which declares every one, instead of through a `Record` conversion.
1732
+
1733
+ **minor, not patch, for `@object-ui/types`.** `ActionBarSchema` is a new export, and `isAnimationActive` is a new member in the shipped `.d.ts`.
1734
+ - 4a1adb7: The schedule-conflict and auto-schedule dialogs' task counts read the right noun form in every language at every count (objectui#11445): `gantt.conflict.body`, `gantt.autoScheduleDlg.body` and `gantt.autoScheduleDlg.skipped` are i18next count families, so German no longer reads `1 betroffene Vorgänge` and Russian reads `3 задачи`. The provider-less fallback reads a family's `_one` / `_other` row for a numeric `count`.
1735
+ - f560ded: The gantt tooltip's `percent` row scales at the storage the field declares
1736
+ (`percentCellScale`, the spec's `percentScaleOf`), the answer the list cell
1737
+ reads. A fraction-stored `1` now reads `100%`, where the old magnitude guess
1738
+ read `1%` (objectui#11475).
1739
+ - 39f4309: Published typings from every `vite-plugin-dts` package now carry an explicit extension on
1740
+ every relative specifier, and a type error in the declaration build now fails the build
1741
+ instead of being printed and ignored (objectui#5439, objectui#5483).
1742
+
1743
+ **Consumers on `moduleResolution: nodenext` or `node16` may see NEW type errors, and that
1744
+ is the fix working.** These packages re-export mostly through NAMED re-exports —
1745
+ `export { useObjectChat } from './useObjectChat'`. TypeScript could not follow the
1746
+ extensionless hop, but it still DECLARED the name, so the symbol resolved to a silent
1747
+ `any`. Nothing errored; consumers simply got no types. With the extension emitted, the
1748
+ symbol carries its real type, and any call site that was relying on the `any` now type
1749
+ checks for the first time. This is the mode that produced the 21 residual `TS7006` on
1750
+ `@object-ui/app-shell` reported against objectui#5365 — a type hole that opened quietly,
1751
+ unlike objectui#5365's own `export * from './ui'` packages where the same defect surfaced
1752
+ immediately as `TS2305: has no exported member`.
1753
+
1754
+ 410 extensionless relative specifiers across 19 packages were emitted before this change;
1755
+ the count is now 0 in all 22 packages that build typings through `vite-plugin-dts`.
1756
+ `@object-ui/fields` was already clean — its sources write explicit `.js` specifiers — and
1757
+ is wired so it stays that way.
1758
+
1759
+ The second half changes no emitted output today: 22/22 packages built green unmodified, so
1760
+ making the declaration step's exit code honest turns nothing red. It changes what a FUTURE
1761
+ regression does — print and exit 0, versus fail the build.
1762
+ - 9b61cf1: The package README stops documenting a `navigation` key the spec refuses, and the corrected example is now parsed by the schema that validates it.
1763
+
1764
+ `README.md`'s record-navigation override read
1765
+ `{ mode: 'page', basePath: '/console/apps/.../campaign' }`. `basePath` is not a
1766
+ member of the spec's `NavigationConfig`, and nothing consumes it:
1767
+ `useNavigationOverlay` — where a gantt's `navigation` lands — builds no URL out
1768
+ of the config, and `ObjectGantt` calls the hook with no `onNavigate`, so a
1769
+ page-mode click falls through to the host's `onRowClick`. The destination route
1770
+ is owned by the host and was never authorable through this key, under any
1771
+ spelling.
1772
+
1773
+ That made the snippet worse than inert. `NavigationConfigSchema` is a strict
1774
+ object with no passthrough, so the undeclared key did not fall away quietly — it
1775
+ rejected the **whole** config with `unrecognized_keys`, taking down the
1776
+ `mode: 'page'` the sentence was actually teaching. An author who copied the
1777
+ documented snippet got a rejected navigation config and no page navigation, which
1778
+ is the copy-the-snippet-get-rejected shape objectui#5057 / #5012 named on other
1779
+ keys.
1780
+
1781
+ The example is corrected to `{ "navigation": { "mode": "page" } }` — the shape
1782
+ the sentence demonstrates — and the prose now says who owns the destination route
1783
+ and points at `@objectstack/spec`'s `NavigationConfigSchema` for the member list
1784
+ instead of restating it, matching the derivation `ObjectGanttSchema.navigation`'s
1785
+ doc comment (objectui#5903) adopted for the same concept.
1786
+
1787
+ `view` is **not** substituted for `basePath`. It is a declared member, but it
1788
+ names a form view (the spec: *"Name of the form view to use for details"*) and is
1789
+ forwarded to `onNavigate` as the action argument — it is not a route, so putting
1790
+ it where `basePath` stood would have replaced an invented key with a wrong one.
1791
+ It is documented for what it does.
1792
+
1793
+ No gate in this repo could have caught the original defect, and that is why the
1794
+ fix ships with a measurement rather than a re-reading: `check-doc-snippet-types`
1795
+ compiles `ts`/`tsx` fences and `check-doc-component-types` reads `type` literals,
1796
+ and both are structurally blind to a metadata key in a README — the former's own
1797
+ header records schema-key validity as "a different question … left unruled on
1798
+ purpose". `src/readme-navigation-example.test.ts` closes that hole for this
1799
+ example by EXTRACTING the fence from the README on every run and parsing it
1800
+ against `NavigationConfigSchema`, with a control asserting the same parse still
1801
+ rejects an undeclared key by name, so the green cannot come from a schema that
1802
+ accepts everything.
1803
+
1804
+ `tsconfig.test.json` names `node` in `types` for that test to compile, and its
1805
+ comment — which had recorded that no test in this package touches a Node global
1806
+ — is corrected rather than left standing.
1807
+
1808
+ **Dated note, 2026-10-01 (objectui#11168 slice 4).** Two sentences above describe a README that has since moved. objectui#7334 (same release) gave `ObjectGantt` its own `onNavigate`, so a `page` click no longer falls through to a host handler: the gantt navigates to the record-page address it derives from the page it is on, and no `navigation` member authors that address, `basePath` included. The README example is now the authored node, with `{ "mode": "page" }` inside its `properties` bag, and the prose says where that address leads. The rest of this entry is kept as the reading of this change.
1809
+ - cbc8839: `ObjectGantt`'s export filename resolves a locale-map `label` instead of stringifying it
1810
+ (objectui#6052). A gantt authored as
1811
+ `{ "type": "object-gantt", "objectName": "task", "label": { "en": "Shift Plan", "zh-CN": "排班计划" } }`
1812
+ exported its PNG/PDF as `[object Object]-20260825-1030.png`.
1813
+
1814
+ `BaseSchema.label` is `string | I18nLabel` since #4580's revised Q1-A ruling — `I18nLabel`
1815
+ being the spec's INLINE locale MAP — and the `exportFileName` chain handed that value
1816
+ straight to `String(...)`. It now goes through `resolveI18nLabel` from `@objectstack/spec/ui`,
1817
+ the producer's own resolver for that vocabulary, against the display locale the file already
1818
+ reads via `useDisplayLocale()`. A zh-CN audience gets `排班计划-<stamp>.png`, an en audience
1819
+ `Shift Plan-<stamp>.png`, and a plain-string label is unchanged.
1820
+
1821
+ The next link in the same chain, `objectSchema?.label`, is deliberately left alone: that is
1822
+ the DATA object's label, declared `z.string().optional()` on the spec's `ObjectSchemaBase`,
1823
+ which is a `strictObject` — a locale map there is rejected by the producer rather than
1824
+ resolved by the consumer, and wrapping it would be accepting a second vocabulary at a read
1825
+ site. No filename sanitisation is added either; `GanttView` already strips
1826
+ filesystem-hostile characters downstream, and a resolved map entry goes through the same
1827
+ strip a plain string does.
1828
+ - 45a9aeb: `ObjectGanttSchema.dependencyField` is now marked `@deprecated` on both published
1829
+ declaration faces, naming `dependenciesField` as the canonical spelling
1830
+ (objectui#6470). Nothing is removed and nothing is rejected that was accepted
1831
+ before.
1832
+
1833
+ **What the two spellings were.** `ObjectGanttSchema` declares both, and
1834
+ `getGanttConfig`'s flat branch reads them with a `||`:
1835
+ `dependenciesField: schema.dependenciesField || schema.dependencyField`.
1836
+ `dependenciesField` is the spec's key (`@objectstack/spec`
1837
+ `GanttConfigSchema.dependenciesField`); the singular `dependencyField` has NO
1838
+ spec counterpart — zero occurrences across `packages/spec/src`, measured against
1839
+ a live positive control on the plural. Until objectui#6051 declared the plural,
1840
+ the singular was the ONLY dependencies spelling this interface carried, so for
1841
+ the whole time the alias existed the published type taught the non-spec key and
1842
+ hid the canonical one.
1843
+
1844
+ **What was missing was the ranking, not the behaviour.** The two were declared as
1845
+ equals: nothing on either face said which one to author, so a reader — including
1846
+ an AI writing metadata, which is the reader this project optimises for — had a
1847
+ coin flip between a spec key and pre-spec vocabulary. The marker turns that coin
1848
+ flip into a fact the type itself carries, and the zod mirror's description makes
1849
+ it readable at runtime as well as in an editor.
1850
+
1851
+ This adopts the idiom already ruled for this exact shape rather than inventing a
1852
+ second one: `KanbanConfig`'s pre-#2231 aliases (`groupField`, `cardFields`) carry
1853
+ `/** @deprecated legacy alias for the spec's X */` plus
1854
+ `.describe('Deprecated alias for X')`, and `dependencyField` now reads the same
1855
+ way.
1856
+
1857
+ **⛔ Not a removal, deliberately.** Deleting the alias — or narrowing the
1858
+ renderer's `||` — would break every author who wrote the singular and narrow the
1859
+ accept set of a published surface. That is a maintainer decision on a future
1860
+ enforce-or-remove card once the deprecation has sat a release, and it is
1861
+ explicitly excluded here. Two pins hold the line in both directions:
1862
+ `packages/types/src/__tests__/gantt-dependency-field-deprecated-alias.test.ts`
1863
+ fails if the marker goes missing AND if the alias stops being declared or
1864
+ accepted, and `packages/plugin-gantt/src/ObjectGantt.dependencyAlias.test.tsx`
1865
+ fails if the `||` limb is dropped — the two spellings must keep resolving to the
1866
+ same config, with the canonical one winning when both carry a value.
1867
+
1868
+ `packages/plugin-gantt/README.md`'s `ObjectGanttSchema` example authored the
1869
+ singular; it was the only in-repo site that did, and it now authors the plural
1870
+ with the alias named as legacy. No runtime code, fixture, example app or catalog
1871
+ schema authored it.
1872
+ - f9653ae: Re-key the load-bearing fetch effects in `ObjectMap`, `ObjectCalendar` and
1873
+ `ObjectGantt` onto the primitive fields they actually read off `dataConfig`
1874
+ (`provider` / `object` / `items`) instead of the whole memoised `dataConfig`
1875
+ object (objectui#6592, the deferred half of objectui#6270/PR #6591).
1876
+ `ObjectTree` is a census member too but is deferred out of this change — see
1877
+ the PR body — because its own fetch effects are the surface of PR #6696
1878
+ (objectui#6481), open at the same time.
1879
+
1880
+ `useMemo` carries no semantic guarantee — React is permitted to discard a
1881
+ memo cache and recompute even when its dependency array compares equal to
1882
+ the previous render, and the local `getDataConfig(schema)` helper each of
1883
+ these renderers carries builds a fresh `{ provider, object }` /
1884
+ `{ provider, items }` wrapper object on every call. So a fetch effect keyed
1885
+ on `dataConfig` itself was correct only for as long as that identity
1886
+ happened to survive a discard: a recompute alone (no author or caller
1887
+ action) was enough to re-run the effect and issue an extra
1888
+ `dataSource.find` / `dataSource.getObjectSchema` call. Keying the effects
1889
+ on the primitives instead makes a cache discard a no-op, restoring
1890
+ `useMemo` to a pure optimisation.
1891
+
1892
+ `ObjectGantt`'s `effectiveDataSource` memo deliberately keeps `dataConfig`
1893
+ as a dependency (`resolveDataSource` needs the whole provider-shaped
1894
+ value — the `api` provider's `read`/`write` request config cannot be
1895
+ flattened to a fixed primitive list the way `object`/`value` can), so its
1896
+ `reload()` fetch is decoupled from the redundant direct `dataConfig`
1897
+ dependency but not from `effectiveDataSource`'s own; for the `object`/`value`
1898
+ providers `resolveDataSource` returns its `fallback`/a fresh
1899
+ `ValueDataSource` respectively rather than reading further into the config,
1900
+ which is enough for the two fetch effects to observe no extra call under a
1901
+ recomputed-but-equivalent `dataConfig` in the common case.
1902
+
1903
+ No behaviour change for a schema whose `useMemo` caches survive normally;
1904
+ the effects are unaffected by React discarding one.
1905
+ - 3beef6d: The spec's `dataSource` element binding is now DECLARED by the blocks that read
1906
+ it, so the html tier stops reporting the one working saved-view spelling as
1907
+ `unknown-prop` (objectui#6678).
1908
+
1909
+ `PageComponentSchema.dataSource` — `{ object, view, filter, sort, limit }` — is
1910
+ the one spelling that resolves a saved view for an object-bound block. It works,
1911
+ and it drew the identical `unknown-prop` warning as the two spellings that do
1912
+ nothing (`viewName`, `view`), because `validateTree` looks a prop up in the
1913
+ block's declared `inputs` and no registration declared this key. On the tier
1914
+ built to accept AI-authored pages, where the diagnostic IS the contract, the
1915
+ only signal pointed away from the key that works.
1916
+
1917
+ Adopting the maintainer ruling of 2026-08-29 — option B **in the injection
1918
+ form**:
1919
+
1920
+ - `ELEMENT_DATA_SOURCE_INPUT` is the single declaration, in `@object-ui/core`
1921
+ beside the binding's own semantics; `Registry.register` emits it for any
1922
+ registration whose renderer passed through the new `elementDataSourceBlock()`
1923
+ seam. One mechanism, one copy — not a hand-kept declaration per block, which is
1924
+ the shape that drifts and that a new block forgets. The seam lives in
1925
+ `@object-ui/core` and is re-exported by `@object-ui/react` beside
1926
+ `ElementDataSourceGate` for discoverability; call sites take the core import,
1927
+ because a registration runs at module scope and this repo's suites partially
1928
+ mock `@object-ui/react`.
1929
+ - Seventeen renderers, in thirteen files across twelve packages, reach the seam
1930
+ and now publish the key to the save gate, the parser whitelist, the generated
1931
+ JSX authoring types and the block list. The card named nine blocks; the tree
1932
+ also has `plugin-grid`, `plugin-timeline`, two further `plugin-form` blocks and
1933
+ `element:record_picker` — nothing was hand-listed, so the mechanism covered
1934
+ them. `element:record_picker` consumes the gate's HOOK and status panels rather
1935
+ than the wrapper tag (its object lives under `properties`), and was found by a
1936
+ render probe rather than by reading sources.
1937
+ - `dataSource` on a block that does NOT read it (`flex`, `card`) still reports
1938
+ `unknown-prop`. Adding the key to `sdui-parser`'s `BASE_PROPS` was refused for
1939
+ exactly this reason — that set mirrors `BaseSchema`, and silencing the key
1940
+ everywhere would make the diagnostic lie in the other direction.
1941
+ - New `check:element-data-source-declaration` fails any source that consumes the
1942
+ gate without reaching the seam, so a block added tomorrow cannot forget.
1943
+
1944
+ Behaviour of the binding itself is unchanged — this is a declaration, not a
1945
+ resolution change. The saved view still resolves its columns, and an
1946
+ unresolvable `view` still fails loudly rather than widening to the object's full
1947
+ scope.
1948
+
1949
+ The spec/registry parity gates (repo-wide and the `record:related_list` per-block
1950
+ pin) now derive their accepted set from the WHOLE node contract rather than from
1951
+ `ComponentPropsMap[type]` alone. `PageComponentSchema` accepts and keeps
1952
+ `dataSource` on a page-component node — it is a node-level key, a sibling of
1953
+ `type` and `className`, not a per-block prop — so the gates' previous complaint
1954
+ was measurably wrong. Derived from the spec, not exempted, and both still
1955
+ discriminate against an invented key.
1956
+ - 231d1b9: Gantt toolbar: the period label names the visible window, and the prev/next
1957
+ buttons step it (objectui#7203).
1958
+
1959
+ The label formatted `timelineRange.start` — the memo spanning the whole dataset
1960
+ — so it named the first unit of the entire result set and could not change while
1961
+ the chart was scrolled, because it was not derived from scroll position at all.
1962
+ On a dataset running January to December it therefore read "January 2026" at
1963
+ every scroll position, four pixels above a band header correctly reading
1964
+ "Aug 2026". Measured on the demo fixture in Chromium at 1440x900: on first paint,
1965
+ after the chart auto-scrolls to Today, the label read `December 2025` over
1966
+ columns `28F 29S 30S 31M 1T 2W 3T` with the band beneath them reading `Aug 2026`.
1967
+ Two month labels four pixels apart, disagreeing — and the wrong one is the
1968
+ prominent one, so the chart reads as if the columns were mislabelled.
1969
+
1970
+ The label now names the period at the left edge of the viewport, snapped to the
1971
+ same tier `headerGroups` bands the timeline by: a month under day and week view,
1972
+ a year under month and quarter view, a decade under year view, the shift-day
1973
+ under shift-segmented day view. The toolbar and the band header therefore agree
1974
+ by construction rather than by two derivations that can drift. Wording is
1975
+ unchanged for the month tier — the toolbar still spells the month out
1976
+ ("August 2026" beside the header's "Aug 2026").
1977
+
1978
+ The `‹` / `›` buttons rendered an `aria-label` and an icon and carried no
1979
+ `onClick`. They now scroll the visible window one period backwards/forwards at
1980
+ that same tier, clamped to the ends of the timeline (ADR-0049 enforce-or-remove:
1981
+ wiring is the branch the label change makes available). They step the label's
1982
+ tier rather than one column, so a click always changes what the label says.
1983
+
1984
+ The band header is untouched. It was already correct; it is the reference here.
1985
+ - 7c3df8f: The settled-schema convergence, and the gantt's duplicate query gated
1986
+ (objectui#7225, maintainer ruling B, 2026-09-02).
1987
+
1988
+ `useSettledSchema` was extracted and published in PR #6690 with exactly **one**
1989
+ non-test adopter (`ObjectTree`, the component that had an actual defect —
1990
+ objectui#6481's unkeyed latch). `ObjectKanban`, `plugin-view/ObjectView` and
1991
+ `ObjectCalendar` kept their own hand copies of the same shape, so a published
1992
+ export was owed compatibility forever **and** the duplication it was named for
1993
+ stayed. All three now call the hook.
1994
+
1995
+ The migration is a pure deduplication with no behaviour delta — the hook was
1996
+ extracted *from* these three shapes, so each becomes a one-line call.
1997
+ `ObjectCalendar`, which objectui#6482 named as the obstacle, fits via the
1998
+ recipe the hook's own doc comment prescribes for it by name: pass the data
1999
+ source as `undefined` for a render that must not read metadata
2000
+ (`hasInlineData ? undefined : dataSource`), so "inline value data set" is
2001
+ expressed as "there is no source to read from" rather than as a second enable
2002
+ flag. GATE PLACEMENT stays local in all three, which is what #6482 ruled and
2003
+ what made the calendar's obstacle a non-obstacle: it was about the gate half.
2004
+
2005
+ **One observable change:** `ObjectKanban`'s rejected definition read now logs
2006
+ on `console.error` with a `[useSettledSchema]` prefix instead of
2007
+ `console.warn`. Its test spy moves with it, and now asserts on the channel
2008
+ rather than merely silencing it.
2009
+
2010
+ **The gantt's duplicate query is gated** (ask 2 of the card; #6482's
2011
+ undischarged half). `ObjectGantt` listed `objectSchema` in `reload`'s
2012
+ dependency list, so every load issued two unbounded queries — the first with no
2013
+ `$expand` at all. Measured on this component across three latency profiles, the
2014
+ cost is not the mild "round trip bought and thrown away": when the metadata
2015
+ read is the slower of the two, which is the common case on a cold
2016
+ `MetadataCache`, the user sees the full three-step paint — raw foreign-key ids,
2017
+ back to the loading placeholder, then the expanded rows. It now issues one
2018
+ query, already expanded.
2019
+
2020
+ Gating the gantt required its schema resolution to settle on EVERY exit
2021
+ (objectui#7232): the hand-rolled effect returned without settling on
2022
+ `!effectiveDataSource`, on `!resource` and in its `catch` — harmless while
2023
+ nothing waited on it, and a chart that never loads once something does.
2024
+ `useSettledSchema` settles on all three by construction, which is what makes
2025
+ the gate safe; both exits are pinned.
2026
+
2027
+ ⛔ Gating is not capping. The row ceiling on these fetches is objectui#7210's
2028
+ separate ruling, in its own commit on the same branch.
2029
+ - 6411def: FLS-gate the `$expand` projection at the five remaining build sites (objectui#7230).
2030
+
2031
+ objectui#7215 / PR #7229 gated `$expand` at the two projection sites in its scope
2032
+ (`ObjectGrid`, `ListView`). The helper is reached from more places than that. This
2033
+ closes the five that were left: `ObjectCalendar`, `ObjectGantt`, `RecordDetailView`,
2034
+ `DetailView`, and `ObjectDataTable` (which builds its own whitelist in
2035
+ `computeLookupExpand` rather than calling `buildExpandFields`).
2036
+
2037
+ **Three of them pass no column list at all**, which makes them the sharp ones:
2038
+ `buildExpandFields` reads an absent column list as "no column restriction" and falls
2039
+ back to **every declared relation on the object**, denied ones included. So a standalone
2040
+ calendar, a gantt, and every record page in the console asked the server to resolve the
2041
+ object's full relation set by default rather than by configuration.
2042
+
2043
+ **`DetailView` was input-gated, and that is the defect rather than the fix.** Its column
2044
+ list is already FLS-filtered field by field, which is exactly the route PR #7229 measured
2045
+ as unsound: an emptied column list reads as "no column restriction", so a detail view
2046
+ whose authored fields are all denied had its `$expand` **widened** from the relations it
2047
+ asked for to every relation the object declares. The principal who may read least was
2048
+ asking for the most.
2049
+
2050
+ **Reproduced before it was fixed**, as a failing test per site.
2051
+
2052
+ **Grading, measured rather than assumed.** Against ObjectStack's own server this is
2053
+ defence-in-depth, exactly as objectui#6898 and #7215 are: `plugin-security`'s
2054
+ `FieldMasker.maskRecord` deletes every unreadable key from each returned row and
2055
+ objectql's expand path writes the resolved record back under that same key, so one
2056
+ statement removes the expanded object and the bare id alike; the expansion sub-read is
2057
+ itself gated (`__expandRead` takes the referenced object's full CRUD + RLS + FLS
2058
+ treatment). It is load-bearing for any backend that does not strip, and the
2059
+ client-request side is real regardless.
2060
+
2061
+ **Nothing a permitted view did stops working.** The gate judges each helper's OUTPUT,
2062
+ which contains only the object's declared reference-bearing fields, so the "`checkField`
2063
+ answers false for an undeclared key" trap cannot be reached and derived / host-joined
2064
+ columns are untouched. An unanswered permission policy filters nothing. Neither
2065
+ `buildExpandFields` nor `computeLookupExpand` is changed.
2066
+ - 92c65aa: `ObjectGantt` no longer blanks the chart when one reload supersedes another
2067
+
2068
+ `reload()` already sequenced concurrent runs with `reloadSeqRef` and guarded every
2069
+ result write with `isCurrent()`, but its `finally` was unguarded — so a **superseded**
2070
+ reload still flipped `loading` / `refreshing` off. The stale run only had to finish
2071
+ first, which is the ordinary case whenever a second reload is issued while the first
2072
+ is still in flight: the placeholder was released, no rows had arrived, and the user
2073
+ saw an empty chart until the fresh response landed.
2074
+
2075
+ The `finally` now clears the flags only when the run reaching it is still the current
2076
+ one. It clears **both** flags rather than only the one its own `silent` mode set:
2077
+ being current at that point means nothing is in flight any more, so clearing only its
2078
+ own mode would strand the other flag whenever the superseded run used the other mode
2079
+ — a silent toolbar refresh overtaken by a filter-change reload would have left the
2080
+ refresh button busy for the life of the component.
2081
+
2082
+ This is the reload guard alone. Nothing about which queries are issued, how they are
2083
+ projected or how they page changes.
2084
+ - e75f4c9: `colorField` now means the same thing in the gantt, the calendar and the timeline
2085
+ (objectui#7243).
2086
+
2087
+ **The inversion this fixes.** `gantt.colorField` is documented as "field that drives the
2088
+ bar color", and the renderer passed the stored value straight into the bar's
2089
+ `backgroundColor`. Pointing the key at a select field therefore emitted
2090
+ `backgroundColor: "open"` — not a colour, so the browser dropped the declaration and
2091
+ every bar rendered identically. OMITTING the key was strictly better: the absent-key
2092
+ branch derived a real colour per status. Declaring the documented key was worse than not
2093
+ declaring it, with no error, warning or console message either way.
2094
+
2095
+ The same key also meant three different things across the three lenses: the timeline
2096
+ resolved the field's authored option `color`, the calendar hashed the raw value onto a
2097
+ fixed palette, and the gantt emitted the raw value. An author colouring three views by
2098
+ one field got three unrelated results, one of which was no colour at all.
2099
+
2100
+ **The ladder.** `@object-ui/core` gains `createFieldColorResolver` — the timeline's
2101
+ resolver, lifted so all three call it:
2102
+
2103
+ 1. the field's own option `color` for the record's value;
2104
+ 2. else the value itself when it already IS a colour literal (`#rgb`, `#rrggbb`,
2105
+ `#rrggbbaa`, `rgb(...)`, `hsl(...)`);
2106
+ 3. else each renderer's own last rung, which is deliberately NOT shared — the gantt
2107
+ derives a semantic-token hex (a bar must be painted), the calendar keeps its
2108
+ theme-aware 8-stop hash (a soft tint, not a solid fill), the timeline draws its
2109
+ default marker.
2110
+
2111
+ **What changes for authors.** A gantt or calendar whose `colorField` points at a select
2112
+ field with authored option colours now paints those colours. A gantt value that is
2113
+ neither an option colour nor a colour literal now derives a colour instead of emitting
2114
+ an invalid CSS value — including a palette NAME (`red`), which now resolves to that
2115
+ palette's hex, the behaviour the key's own contract has always promised ("hex or
2116
+ semantic name") and the one `borderColorField` already had. `gantt.borderColorField`
2117
+ takes rung 1 as well, so an authored option colour reaches the alert stroke; it keeps
2118
+ today's behaviour otherwise and deliberately gains no derivation rung, since the stroke
2119
+ is opt-in and deriving one for every record would draw an alert on records that have
2120
+ none.
2121
+
2122
+ Calendars whose `colorField` points at a plain categorical field are unchanged: that
2123
+ value still reaches `CalendarView`'s deterministic hash exactly as before. The timeline
2124
+ is unchanged apart from accepting the 8-digit `#rrggbbaa` hex spelling the calendar
2125
+ already accepted.
2126
+ - 67d4ed9: `ObjectGantt` no longer treats an EMPTY host `data` array as the rows it was handed (objectui#7333).
2127
+
2128
+ `ObjectGantt` read a host `data` prop at two places, and both accepted `[]`. The
2129
+ reload's short-circuit tested `data && Array.isArray(data)`, and an empty array
2130
+ is truthy, so the chart adopted it and returned before its own query. The gating
2131
+ flag tested `Array.isArray(data)` alone, so the same array also switched off the
2132
+ object-schema gate and the data-invalidation subscription of that query. A gantt
2133
+ whose `data` names its own source, for example `{ provider: 'api', read }`,
2134
+ therefore painted an EMPTY chart whenever a host handed it an array it had not
2135
+ filled yet.
2136
+
2137
+ Both places now read one predicate. A host `data` array is adopted only when it
2138
+ has rows. An empty one reads as "no host rows yet": the chart queries its own
2139
+ source, exactly as it does with no host array at all, and adopts the host's rows
2140
+ when they arrive.
2141
+
2142
+ Who can reach this: the registered `object-gantt` renderer still forwards no
2143
+ host prop, and `ObjectGanttProps` does not declare `data`, so only a caller that
2144
+ renders `ObjectGantt` directly and spreads `data` in was affected.
2145
+ - 2c878be: Honour a gantt view's authored `navigation` — forward it down the gantt
2146
+ view-schema path, and give the component a destination for the non-overlay
2147
+ modes (objectui#7334).
2148
+
2149
+ **Leg 1, `@object-ui/plugin-list`.** `ObjectGantt` resolves
2150
+ `schema.navigation ?? { mode: 'drawer' }` and classifies four overlay modes
2151
+ (`drawer` / `modal` / `split` / `popover`). Nothing ever put `navigation` on the
2152
+ node it receives — `ListView`'s shared `baseProps` declares no such key and the
2153
+ `case 'gantt'` branch added only the data keys — so that fallback was the only
2154
+ branch ever taken. A gantt view authoring `navigation: { mode: 'page' }` (or
2155
+ `modal`, or `split`) opened a drawer instead, with no diagnostic. The key was
2156
+ already authorable and already read; this restores declared = enforced. No new
2157
+ authorable key is added.
2158
+
2159
+ The key is forwarded on the `case 'gantt'` branch and deliberately **not** on
2160
+ the shared `baseProps`, because every other child view resolves this same
2161
+ question through the `onRowClick` that `baseProps` already carries:
2162
+ `ObjectGrid`, `ObjectGallery`, `ObjectKanban`, `ObjectMap`, `ObjectTimeline` and
2163
+ `ObjectTree` hand that callback to `useNavigationOverlay` unconditionally, and
2164
+ the hook gives an external `onRowClick` full priority over any `navigation` — so
2165
+ on `baseProps` the authored config would arrive there only to be outranked.
2166
+ `ObjectCalendar` is the one that would genuinely change behaviour: it mirrors
2167
+ gantt's `navIsOverlay ? undefined : onRowClick`, so an authored non-overlay mode
2168
+ would stop it suppressing the host handler. Gantt is the only branch where
2169
+ forwarding settles the question rather than splitting it, because its wrapper
2170
+ drops host props entirely (objectui#7210 / objectui#7222) and there is no
2171
+ `onRowClick` there to outrank anything.
2172
+
2173
+ **Leg 2, `@object-ui/plugin-gantt`.** `ObjectGantt` now supplies its own
2174
+ `onNavigate`, so a click under an authored `page` or `new_window` actually
2175
+ reaches the record page. Leg 1 alone would have made `page` reachable and inert:
2176
+ `useNavigationOverlay`'s `page` branch calls `onNavigate` and returns with no
2177
+ fallback, this component supplied none, and its registration hands it no host
2178
+ `onRowClick` either — both carriers empty at once, turning an authored `page`
2179
+ from "a drawer opens, which is wrong" into "the click does nothing". The
2180
+ destination is the record-page href the component already computes for the
2181
+ drawer's full-page link, so the two cannot diverge; same-tab navigation uses the
2182
+ history plus `popstate` pair (matching `DashboardRenderer` and `PageHeader`),
2183
+ and `new_window` now opens the app-prefixed href rather than the hook's
2184
+ unprefixed fallback. No host prop is forwarded to the chart.
2185
+
2186
+ A view that authors no `navigation` still gets **no** key and still opens its
2187
+ drawer, so the component's default is unchanged for every gantt in the product
2188
+ today; an authored `none` stays inert.
2189
+ - 3ef0b51: fix(plugin-map, plugin-gantt): the registrations no longer declare `objectName` a required input
2190
+
2191
+ Both renderers read their records from one of three keys (`data`, then
2192
+ `staticData`, then `objectName`), and the `object-map` / `object-gantt` zod schemas
2193
+ enforce "one of the three" through `requireRecordSource` (`77cb489b4`). The
2194
+ registrations' designer-facing `inputs` still said `objectName` was required, on
2195
+ `object-map`, `map` and `object-gantt`, so the html tier's validator reported a
2196
+ `missing-required-prop` error on a block authored on `staticData` or `data` that
2197
+ the schema accepts and the renderer draws.
2198
+
2199
+ `objectName` is now declared without `required`, and its description states the
2200
+ rule: the record source is one of `data`, `staticData` and `objectName`, and the
2201
+ schema refuses a block that declares none of them. No one-of form was added to the
2202
+ input declaration; the zod refinement stays the place that enforces it. The
2203
+ renderers' read order is unchanged. The `@object-ui/plugin-gantt` README sentence
2204
+ that called `objectName` required is corrected (objectui#7470).
2205
+
2206
+ **Correction, 2026-10-01 (objectui#11117).** The rule this entry describes gained an exception:
2207
+ the `object-map` and `object-gantt` schemas also accept a block that declares none of the three
2208
+ when its `dataSource.object` names the object, because the registration's `ElementDataSourceGate`
2209
+ lands that name on `objectName`. The `objectName` input description now says so.
2210
+ - c6198c2: **Breaking for authored metadata:** `ComponentInput.label`, `ComponentInput.defaultValue` and
2211
+ `ComponentInput.advanced` are RETIRED on both faces (objectui#7493 item ① and objectui#7781;
2212
+ maintainer ruling A of 2026-09-06, immediate, no deprecation window; ADR-0049 enforce-or-remove).
2213
+ They are the three keys the manifest serializer does not forward, and nothing read them on any
2214
+ publication or consumption path.
2215
+
2216
+ No manifest ever published them, so no consumer could ever have read them. `sdui-parser`'s
2217
+ serializer (`packages/sdui-parser/src/index.ts`) forwards exactly seven keys per input — `name`,
2218
+ `type`, `of`, `required`, `enum`, `binding`, `description` — so a value authored under any of the three
2219
+ never reached `sdui.manifest.json`, the generated JSX `.d.ts`, or a diagnostic; its boundary type
2220
+ has no slot for them; the registry's data-source seam reads `name` only; and neither the designer
2221
+ nor the app-shell inspectors consult registry `inputs` at all. A structural census over every
2222
+ `inputs:` array in the repository (re-measured on this change's merge-base, `name` 951 and `type`
2223
+ 951 as the controls) counted the writes: `label` 908, `defaultValue` 245, `advanced` 9 — written on
2224
+ nearly every registration, read by nothing.
2225
+
2226
+ FROM → TO, per key — all three **TOMBSTONED, not removed**, because the route was measured on
2227
+ the built face before it was chosen: `ComponentInputSchema` is a non-strict `z.object`, and an
2228
+ undeclared key parses GREEN and is silently STRIPPED, so a deletion would have swallowed 1,162
2229
+ authored values in silence. The tombstone is what makes the refusal loud and by name.
2230
+
2231
+ - `label?: string` → `label?: never` on the interface, `retirementTombstone()` on the Zod mirror.
2232
+ Migration: delete the key. An input is identified by its `name` on every path that reaches it;
2233
+ nothing ever rendered a label for it.
2234
+ - `defaultValue?: any` → `defaultValue?: never` / `retirementTombstone()`. Migration: delete the
2235
+ key. The renderer's own fallback read IS the default; tell the author about it in `description`,
2236
+ which IS published. (Tightening the type to `unknown` was ruled out: it closes no error class,
2237
+ since nothing reads the value.)
2238
+ - `advanced?: boolean` → `advanced?: never` / `retirementTombstone()`. Migration: delete the key.
2239
+ No designer surface ever hid an "advanced" input; there is nothing to write instead.
2240
+
2241
+ The retirement kit: `?: never` on `ComponentInput` (`packages/types/src/base.ts`), so authoring one
2242
+ is a `tsc` error at the registration site; `retirementTombstone()` on `ComponentInputSchema`
2243
+ (`packages/types/src/zod/base.zod.ts`), so an authored value is REFUSED at parse time with
2244
+ `code: 'invalid_type'`, the key named in the issue `path`, and the migration note as the message
2245
+ (one string, both channels). Pinned in
2246
+ `packages/types/src/__tests__/component-input-retired-keys-7493.test.ts`, which also holds a
2247
+ tree-scoped absence census over every `inputs:` array under `packages/**` and `apps/**`.
2248
+
2249
+ Accept-set change, stated plainly for reviewers: a document that sets any of the three keys on a
2250
+ `ComponentInput` used to parse GREEN (the value was then dropped by the serializer) and now parses
2251
+ RED. Every in-repo authoring site — 1,199 keys across 110 registration files, the three standalone
2252
+ `ComponentInput[]` arrays and the two named input arrays `tsc` found included — is deleted in the same change, as the ruling's split rule
2253
+ requires; the `WidgetRegistry` seam no longer copies the widget-manifest values onto the synthesized
2254
+ `ComponentInput` (they fed nothing), and the data-source declaration `ELEMENT_DATA_SOURCE_INPUT`
2255
+ drops its `label`. The patch entries on the other packages record exactly that: their registrations
2256
+ stop authoring inert keys, with no runtime or published-manifest change.
2257
+
2258
+ The nine test files that read `defaultValue` off a registration were re-pinned against the
2259
+ renderer's ACTUAL default (its own fallback read, or the `defaultProps` it ships) instead of the
2260
+ declaration that went away; two assertions that only restated the shadow default were dropped with
2261
+ the reason on the line.
2262
+
2263
+ The in-repo zero is what was measured. Whether anything OUTSIDE this repository writes these keys
2264
+ is not measurable from here (the objectui#5674 limit); converting such a write from a silent drop
2265
+ into a named refusal is exactly what the tombstones buy. `WidgetInput`'s own `label` /
2266
+ `defaultValue` / `advanced` (the widget-manifest face) stay declared and writable — nothing has
2267
+ ruled on that face; that it now has no reader either is recorded as objectui#7911.
2268
+ - ce2aaef: One shared record-source ladder, five plugins delegate.
2269
+
2270
+ `@object-ui/core` publishes `resolveRecordSourceConfig(schema)` — the ONE implementation
2271
+ of the ruled three-rung record source ladder: `data` first, then `staticData` wrapped as
2272
+ `{ provider: 'value', items }`, then `objectName` folded to `{ provider: 'object' }`, and
2273
+ `null` when nothing is bound. It is the PRODUCER whose output the reader
2274
+ `resolveRecordSourceObjectName` (`b041b9c0c`) consumes, and it now sits beside it in the same module.
2275
+
2276
+ That ladder is published contract on both faces — `packages/types/src/objectql.ts` and its
2277
+ zod mirror both ship `.describe()` strings naming `getDataConfig`'s order (`77cb489b4`,
2278
+ maintainer ruling 2026-09-02), pinned by `objectql-record-source-refinement-6939.test.ts` —
2279
+ and it was hand-copied into five plugin components with no gate holding them together. A
2280
+ change to the ruled order had five edit sites and nothing that noticed a missed one; that
2281
+ is the AGENTS.md #0.1 drift class.
2282
+
2283
+ **No behaviour changes.** `ObjectCalendar`, `ObjectGantt` and `ObjectTree` now call the
2284
+ shared reader directly. `ObjectGrid` and `ObjectMap` keep their own bare-array `data`
2285
+ shorthand as a documented head above the shared call and are otherwise unchanged.
2286
+ `record-source-config.behaviourNeutrality-7632.test.ts` transcribes all five pre-collapse
2287
+ bodies verbatim and asserts the post-collapse spelling agrees with each across the whole
2288
+ input matrix, so a later edit to the shared reader that moves any site turns red.
2289
+
2290
+ **Two divergences were measured rather than assumed, and both are preserved.**
2291
+
2292
+ `ObjectCalendar`'s `'data' in schema && schema.data` guards existed because its parameter was
2293
+ at that time the union `ObjectGridSchema | CalendarSchema`, whose `CalendarSchema` arm declared
2294
+ neither key. (objectui#8651 has since re-pointed that parameter at the published
2295
+ `ObjectCalendarSchema`, so the union is gone; the CONCLUSION below — that the guard had no
2296
+ runtime effect and removing it is behaviour-neutral — is unaffected.)
2297
+ That is a TypeScript narrowing device with no runtime effect — an absent property reads
2298
+ `undefined`, falsy either way — so the guard could never change which rung is taken. The
2299
+ shared reader's optional-property parameter accepts the union directly, and the
2300
+ equivalence is pinned on a fixture that really lacks both keys rather than argued.
2301
+
2302
+ `ObjectGrid` and `ObjectMap` normalize a bare-array `data` to `{ provider: 'value', items }`;
2303
+ `ObjectCalendar`, `ObjectGantt` and `ObjectTree` do not, and return the array verbatim. That
2304
+ is a real divergence on off-contract input — `ViewData` is a discriminated union over object
2305
+ variants, so an array under `data` cannot be published. It is NOT unified here: the shared
2306
+ rung stays contract-strict and the two sites keep the head locally, the same way `b041b9c0c`
2307
+ left the off-contract `{ provider: 'object' }` tails at their sites. Both sides of the fork are
2308
+ pinned, so neither folding the head in nor deleting it as redundant can happen silently.
2309
+
2310
+ `ObjectTree`'s copy took `schema: any`; it now goes through the shared reader's typed
2311
+ parameter. Types are erased at runtime, so nothing it resolves moves.
2312
+ - fb336df: Move `lucide-react` from `^1.31.0` to `^1.43.0` in every package that declares it, and
2313
+ repair what the jump breaks, so icons resolved from a STRING keep drawing a glyph.
2314
+
2315
+ Measured once against the installed 1.43.0 artifact when this change was made; nothing in
2316
+ the repository re-derives these readings. Across the jump lucide removes no runtime export,
2317
+ no public type name and no `lucide-react/dynamic.mjs` name, and every name this repository
2318
+ imports from `lucide-react` resolves. Exactly one key leaves the runtime `icons` record:
2319
+ `Trash2`, retired in favour of `trash`.
2320
+
2321
+ What a user sees change:
2322
+
2323
+ - Icons the lazy icon seam draws (`resolveIcon`, objectui#9251) get their path data again.
2324
+ lucide 1.43.0 icon modules export their path data inside `__iconData` and no longer
2325
+ export `__iconNode`; the seam now reads both. Reading only `__iconNode` against 1.43.0
2326
+ leaves every such glyph an empty box, with nothing thrown or logged.
2327
+ - `DetailView`'s delete action and three schema-catalog examples spell their icon
2328
+ `trash`, not `trash-2`, so they keep resolving. The glyph is unchanged: 1.43.0's `trash`
2329
+ path data is byte-identical to the `trash-2` path data of 1.31.0 and 1.35.0. Anything
2330
+ that already authored `trash` now draws that same artwork, because lucide moved it under
2331
+ the `trash` name; a few other glyphs were also redrawn upstream.
2332
+ - Icons imported as COMPONENTS carry lucide 1.43.0's own classes: one class per declared
2333
+ alias (a spinner renders `class="lucide lucide-loader-circle lucide-loader-2 ..."`), and
2334
+ no longer the class lucide used to derive from the PascalCase key where that differs
2335
+ (`ArrowDown01` no longer carries `lucide-arrow-down01`). The canonical
2336
+ `lucide-<icon name>` class is still there, so a `.lucide-loader-circle` selector still
2337
+ matches.
2338
+ - Icons resolved from a STRING through the seam keep the classes they had: `lucide`, the
2339
+ canonical `lucide-<icon name>` class and the key-derived class. They do not carry
2340
+ lucide's per-alias classes. That is a maintainer ruling (objectui#8941, option C): the
2341
+ alias list lives only inside each lazily loaded icon module, and it was not moved into
2342
+ the eager name list. A selector that targets an alias class matches a component-imported
2343
+ icon and not a string-resolved one. This also dates the example in the objectui#9251
2344
+ entry: `trash-2` no longer resolves as a string, so no seam-drawn glyph carries
2345
+ `lucide-trash2 lucide-trash-2`; a digit-bearing name that still resolves, such as
2346
+ `arrow-down-0-1`, carries `lucide-arrow-down01 lucide-arrow-down-0-1`.
2347
+ - Updated dependencies [cd2cb41]
2348
+ - Updated dependencies [7b10bef]
2349
+ - Updated dependencies [97abedc]
2350
+ - Updated dependencies [b46c58f]
2351
+ - Updated dependencies [a507334]
2352
+ - Updated dependencies [ad694ac]
2353
+ - Updated dependencies [6f96fca]
2354
+ - Updated dependencies [afb2284]
2355
+ - Updated dependencies [3ac2de8]
2356
+ - Updated dependencies [0aacecc]
2357
+ - Updated dependencies [28b0658]
2358
+ - Updated dependencies [63f4f92]
2359
+ - Updated dependencies [777fca2]
2360
+ - Updated dependencies [c131d9e]
2361
+ - Updated dependencies [5f00ff4]
2362
+ - Updated dependencies [c9e073a]
2363
+ - Updated dependencies [0361d6b]
2364
+ - Updated dependencies [7b395d8]
2365
+ - Updated dependencies [0879812]
2366
+ - Updated dependencies [588380d]
2367
+ - Updated dependencies [8cedb0d]
2368
+ - Updated dependencies [162621b]
2369
+ - Updated dependencies [b06c3de]
2370
+ - Updated dependencies [0d379f5]
2371
+ - Updated dependencies [4c6f549]
2372
+ - Updated dependencies [80c5412]
2373
+ - Updated dependencies [6cc910b]
2374
+ - Updated dependencies [061f5e8]
2375
+ - Updated dependencies [879ecac]
2376
+ - Updated dependencies [c2dabf0]
2377
+ - Updated dependencies [2dd4d3f]
2378
+ - Updated dependencies [e686f4d]
2379
+ - Updated dependencies [212c451]
2380
+ - Updated dependencies [a04b06d]
2381
+ - Updated dependencies [4ab4f1b]
2382
+ - Updated dependencies [fa5fbd9]
2383
+ - Updated dependencies [5f44cc6]
2384
+ - Updated dependencies [b57107d]
2385
+ - Updated dependencies [e3ea4f9]
2386
+ - Updated dependencies [65f1e8d]
2387
+ - Updated dependencies [fd6f5da]
2388
+ - Updated dependencies [1f8ef0a]
2389
+ - Updated dependencies [bb5d4ee]
2390
+ - Updated dependencies [dc666f7]
2391
+ - Updated dependencies [3335767]
2392
+ - Updated dependencies [8b1f066]
2393
+ - Updated dependencies [af243c1]
2394
+ - Updated dependencies [cff4b77]
2395
+ - Updated dependencies [31938f0]
2396
+ - Updated dependencies [961ceaa]
2397
+ - Updated dependencies [f3f4e4c]
2398
+ - Updated dependencies [a05c350]
2399
+ - Updated dependencies [1dbb993]
2400
+ - Updated dependencies [2b5f509]
2401
+ - Updated dependencies [808f339]
2402
+ - Updated dependencies [6cf5999]
2403
+ - Updated dependencies [274e14a]
2404
+ - Updated dependencies [8c10f4f]
2405
+ - Updated dependencies [90dac98]
2406
+ - Updated dependencies [6096f20]
2407
+ - Updated dependencies [544aca2]
2408
+ - Updated dependencies [ea02938]
2409
+ - Updated dependencies [a14fb23]
2410
+ - Updated dependencies [ae98f1d]
2411
+ - Updated dependencies [f98eddf]
2412
+ - Updated dependencies [ce6bd99]
2413
+ - Updated dependencies [a5b08c9]
2414
+ - Updated dependencies [86982ac]
2415
+ - Updated dependencies [8c929e6]
2416
+ - Updated dependencies [cdefa2a]
2417
+ - Updated dependencies [2fc2a24]
2418
+ - Updated dependencies [cc4366d]
2419
+ - Updated dependencies [0961d5e]
2420
+ - Updated dependencies [9d25b9b]
2421
+ - Updated dependencies [6276478]
2422
+ - Updated dependencies [5e67837]
2423
+ - Updated dependencies [ff14e29]
2424
+ - Updated dependencies [9b28151]
2425
+ - Updated dependencies [64563a9]
2426
+ - Updated dependencies [1a5003f]
2427
+ - Updated dependencies [09ab32b]
2428
+ - Updated dependencies [8acc51b]
2429
+ - Updated dependencies [ea9d17f]
2430
+ - Updated dependencies [45362a3]
2431
+ - Updated dependencies [2a943bf]
2432
+ - Updated dependencies [111fa4c]
2433
+ - Updated dependencies [d999617]
2434
+ - Updated dependencies [93a689d]
2435
+ - Updated dependencies [4357a27]
2436
+ - Updated dependencies [e5f4343]
2437
+ - Updated dependencies [3261e64]
2438
+ - Updated dependencies [f5178a2]
2439
+ - Updated dependencies [2ad3671]
2440
+ - Updated dependencies [39bf246]
2441
+ - Updated dependencies [8740e86]
2442
+ - Updated dependencies [d22b37b]
2443
+ - Updated dependencies [9cbe4db]
2444
+ - Updated dependencies [8c0e550]
2445
+ - Updated dependencies [fde4caf]
2446
+ - Updated dependencies [caf0ed0]
2447
+ - Updated dependencies [1daf477]
2448
+ - Updated dependencies [3d614ea]
2449
+ - Updated dependencies [a7df45f]
2450
+ - Updated dependencies [6c2f3c5]
2451
+ - Updated dependencies [fb13e85]
2452
+ - Updated dependencies [c2d8659]
2453
+ - Updated dependencies [6516320]
2454
+ - Updated dependencies [98b1a7c]
2455
+ - Updated dependencies [e0f8202]
2456
+ - Updated dependencies [ac2d6f1]
2457
+ - Updated dependencies [9fbbb17]
2458
+ - Updated dependencies [c3a26cc]
2459
+ - Updated dependencies [a66e58e]
2460
+ - Updated dependencies [d89492c]
2461
+ - Updated dependencies [9a5f998]
2462
+ - Updated dependencies [1c5ee33]
2463
+ - Updated dependencies [9327397]
2464
+ - Updated dependencies [17cc3a3]
2465
+ - Updated dependencies [a9c5ea0]
2466
+ - Updated dependencies [02e6d36]
2467
+ - Updated dependencies [4758b33]
2468
+ - Updated dependencies [4758b33]
2469
+ - Updated dependencies [4758b33]
2470
+ - Updated dependencies [8848ce4]
2471
+ - Updated dependencies [f905090]
2472
+ - Updated dependencies [3cd6c5e]
2473
+ - Updated dependencies [5bb855d]
2474
+ - Updated dependencies [9c78ebe]
2475
+ - Updated dependencies [12809a5]
2476
+ - Updated dependencies [9c78ebe]
2477
+ - Updated dependencies [12809a5]
2478
+ - Updated dependencies [9c78ebe]
2479
+ - Updated dependencies [12809a5]
2480
+ - Updated dependencies [7afc81d]
2481
+ - Updated dependencies [f9c06ef]
2482
+ - Updated dependencies [93a5585]
2483
+ - Updated dependencies [5ad3b88]
2484
+ - Updated dependencies [21eb61a]
2485
+ - Updated dependencies [f9d772b]
2486
+ - Updated dependencies [bf14b64]
2487
+ - Updated dependencies [4345558]
2488
+ - Updated dependencies [97b6c21]
2489
+ - Updated dependencies [26ca2ad]
2490
+ - Updated dependencies [41ae65b]
2491
+ - Updated dependencies [184cfe1]
2492
+ - Updated dependencies [baac95a]
2493
+ - Updated dependencies [13220af]
2494
+ - Updated dependencies [29b45f6]
2495
+ - Updated dependencies [39b8d51]
2496
+ - Updated dependencies [17b323e]
2497
+ - Updated dependencies [b956e69]
2498
+ - Updated dependencies [b32e7de]
2499
+ - Updated dependencies [ff94a12]
2500
+ - Updated dependencies [33e58d8]
2501
+ - Updated dependencies [256b4c9]
2502
+ - Updated dependencies [97672ba]
2503
+ - Updated dependencies [c5ec15c]
2504
+ - Updated dependencies [fec3b1a]
2505
+ - Updated dependencies [b8e0941]
2506
+ - Updated dependencies [0c50f18]
2507
+ - Updated dependencies [285e36b]
2508
+ - Updated dependencies [1dae95a]
2509
+ - Updated dependencies [e32dae1]
2510
+ - Updated dependencies [d0c0c7f]
2511
+ - Updated dependencies [30b11ad]
2512
+ - Updated dependencies [4aebea0]
2513
+ - Updated dependencies [f976774]
2514
+ - Updated dependencies [3d6badf]
2515
+ - Updated dependencies [25cb364]
2516
+ - Updated dependencies [a60539b]
2517
+ - Updated dependencies [de1b879]
2518
+ - Updated dependencies [c6678b1]
2519
+ - Updated dependencies [0638322]
2520
+ - Updated dependencies [e3782d2]
2521
+ - Updated dependencies [db0beb2]
2522
+ - Updated dependencies [997ce38]
2523
+ - Updated dependencies [ae0b9d3]
2524
+ - Updated dependencies [ad1785c]
2525
+ - Updated dependencies [3b469c8]
2526
+ - Updated dependencies [990a2d6]
2527
+ - Updated dependencies [990a2d6]
2528
+ - Updated dependencies [37140f4]
2529
+ - Updated dependencies [1c84036]
2530
+ - Updated dependencies [1c84036]
2531
+ - Updated dependencies [6650259]
2532
+ - Updated dependencies [4f8b7f8]
2533
+ - Updated dependencies [9e6619f]
2534
+ - Updated dependencies [f6ae5e2]
2535
+ - Updated dependencies [eb97ce6]
2536
+ - Updated dependencies [7343376]
2537
+ - Updated dependencies [b2683a2]
2538
+ - Updated dependencies [dded788]
2539
+ - Updated dependencies [b45d463]
2540
+ - Updated dependencies [54a7830]
2541
+ - Updated dependencies [f3135a4]
2542
+ - Updated dependencies [b5696d3]
2543
+ - Updated dependencies [3f9d926]
2544
+ - Updated dependencies [e978ed5]
2545
+ - Updated dependencies [6a7f24e]
2546
+ - Updated dependencies [b3c96d6]
2547
+ - Updated dependencies [8d0ca91]
2548
+ - Updated dependencies [c30c8dd]
2549
+ - Updated dependencies [244d516]
2550
+ - Updated dependencies [deca847]
2551
+ - Updated dependencies [ac15833]
2552
+ - Updated dependencies [ac15833]
2553
+ - Updated dependencies [e2dffc9]
2554
+ - Updated dependencies [328abeb]
2555
+ - Updated dependencies [dd0d78f]
2556
+ - Updated dependencies [24d3e65]
2557
+ - Updated dependencies [95a7c8d]
2558
+ - Updated dependencies [e227156]
2559
+ - Updated dependencies [cc4e476]
2560
+ - Updated dependencies [92970c4]
2561
+ - Updated dependencies [d570eaa]
2562
+ - Updated dependencies [4b742f4]
2563
+ - Updated dependencies [42687ba]
2564
+ - Updated dependencies [6cd8f66]
2565
+ - Updated dependencies [24a0f14]
2566
+ - Updated dependencies [797a30f]
2567
+ - Updated dependencies [27ae632]
2568
+ - Updated dependencies [b4075c0]
2569
+ - Updated dependencies [9b85600]
2570
+ - Updated dependencies [e327c89]
2571
+ - Updated dependencies [2eaf5be]
2572
+ - Updated dependencies [bf7ab35]
2573
+ - Updated dependencies [99878d8]
2574
+ - Updated dependencies [3c13675]
2575
+ - Updated dependencies [63ab761]
2576
+ - Updated dependencies [0eb9f36]
2577
+ - Updated dependencies [ae582b7]
2578
+ - Updated dependencies [62d6f56]
2579
+ - Updated dependencies [51c2949]
2580
+ - Updated dependencies [a4b017e]
2581
+ - Updated dependencies [8732846]
2582
+ - Updated dependencies [559a2e2]
2583
+ - Updated dependencies [db11afd]
2584
+ - Updated dependencies [154075a]
2585
+ - Updated dependencies [582edef]
2586
+ - Updated dependencies [19f484f]
2587
+ - Updated dependencies [0a78a20]
2588
+ - Updated dependencies [615346d]
2589
+ - Updated dependencies [75dcc81]
2590
+ - Updated dependencies [55a12a8]
2591
+ - Updated dependencies [edfcf5a]
2592
+ - Updated dependencies [0a3e540]
2593
+ - Updated dependencies [c021b35]
2594
+ - Updated dependencies [f61dab1]
2595
+ - Updated dependencies [b0a05dd]
2596
+ - Updated dependencies [dd5ff19]
2597
+ - Updated dependencies [54997ff]
2598
+ - Updated dependencies [81f8498]
2599
+ - Updated dependencies [a782fa7]
2600
+ - Updated dependencies [1d6a23d]
2601
+ - Updated dependencies [0645133]
2602
+ - Updated dependencies [76e9df0]
2603
+ - Updated dependencies [0ecaa7d]
2604
+ - Updated dependencies [b24f93a]
2605
+ - Updated dependencies [6158e4c]
2606
+ - Updated dependencies [cff8641]
2607
+ - Updated dependencies [3f61eef]
2608
+ - Updated dependencies [c27b575]
2609
+ - Updated dependencies [84b275c]
2610
+ - Updated dependencies [0e6e76b]
2611
+ - Updated dependencies [bf43afa]
2612
+ - Updated dependencies [385ebc5]
2613
+ - Updated dependencies [3a0e7ab]
2614
+ - Updated dependencies [858eafb]
2615
+ - Updated dependencies [a8c5509]
2616
+ - Updated dependencies [c2a8d23]
2617
+ - Updated dependencies [f4ed238]
2618
+ - Updated dependencies [0ffc423]
2619
+ - Updated dependencies [3cc4fe5]
2620
+ - Updated dependencies [cd5b19a]
2621
+ - Updated dependencies [cd5b19a]
2622
+ - Updated dependencies [17dc167]
2623
+ - Updated dependencies [20d23be]
2624
+ - Updated dependencies [20d23be]
2625
+ - Updated dependencies [2e3da72]
2626
+ - Updated dependencies [1263e40]
2627
+ - Updated dependencies [e6bc087]
2628
+ - Updated dependencies [9419df1]
2629
+ - Updated dependencies [8bab157]
2630
+ - Updated dependencies [a7557a7]
2631
+ - Updated dependencies [7d074ba]
2632
+ - Updated dependencies [6158e4c]
2633
+ - Updated dependencies [6158e4c]
2634
+ - Updated dependencies [52aad5c]
2635
+ - Updated dependencies [18d1a0a]
2636
+ - Updated dependencies [e420df3]
2637
+ - Updated dependencies [7fed09d]
2638
+ - Updated dependencies [c1763e5]
2639
+ - Updated dependencies [58da8ae]
2640
+ - Updated dependencies [a8b9889]
2641
+ - Updated dependencies [138ad45]
2642
+ - Updated dependencies [138ad45]
2643
+ - Updated dependencies [5262f7d]
2644
+ - Updated dependencies [6aa029b]
2645
+ - Updated dependencies [2124d04]
2646
+ - Updated dependencies [be52115]
2647
+ - Updated dependencies [770cc5b]
2648
+ - Updated dependencies [1a88ce2]
2649
+ - Updated dependencies [a1a44d6]
2650
+ - Updated dependencies [e0a9c67]
2651
+ - Updated dependencies [5638529]
2652
+ - Updated dependencies [5638529]
2653
+ - Updated dependencies [d0fba91]
2654
+ - Updated dependencies [c476be0]
2655
+ - Updated dependencies [c82ff39]
2656
+ - Updated dependencies [6c3da53]
2657
+ - Updated dependencies [31987bd]
2658
+ - Updated dependencies [3c3ce15]
2659
+ - Updated dependencies [063119f]
2660
+ - Updated dependencies [e100589]
2661
+ - Updated dependencies [304f611]
2662
+ - Updated dependencies [e46ee77]
2663
+ - Updated dependencies [f9c8c4e]
2664
+ - Updated dependencies [6e9c8d2]
2665
+ - Updated dependencies [9547063]
2666
+ - Updated dependencies [3f6efd6]
2667
+ - Updated dependencies [52c95a1]
2668
+ - Updated dependencies [55d18c6]
2669
+ - Updated dependencies [c4ab6d0]
2670
+ - Updated dependencies [0e9058b]
2671
+ - Updated dependencies [c4ab6d0]
2672
+ - Updated dependencies [5988b6b]
2673
+ - Updated dependencies [6158e4c]
2674
+ - Updated dependencies [00ccdf7]
2675
+ - Updated dependencies [9d9ed54]
2676
+ - Updated dependencies [6007dd4]
2677
+ - Updated dependencies [4a1adb7]
2678
+ - Updated dependencies [4a1adb7]
2679
+ - Updated dependencies [4a1adb7]
2680
+ - Updated dependencies [4a1adb7]
2681
+ - Updated dependencies [185b7a0]
2682
+ - Updated dependencies [50c73fe]
2683
+ - Updated dependencies [ca3de72]
2684
+ - Updated dependencies [83e3f83]
2685
+ - Updated dependencies [401611b]
2686
+ - Updated dependencies [2c0ddf2]
2687
+ - Updated dependencies [4abc0aa]
2688
+ - Updated dependencies [f560ded]
2689
+ - Updated dependencies [f560ded]
2690
+ - Updated dependencies [2b188fa]
2691
+ - Updated dependencies [b654d4e]
2692
+ - Updated dependencies [f68e0a0]
2693
+ - Updated dependencies [aea682a]
2694
+ - Updated dependencies [fcdc8ec]
2695
+ - Updated dependencies [2d576e4]
2696
+ - Updated dependencies [8366acc]
2697
+ - Updated dependencies [95e58a3]
2698
+ - Updated dependencies [9d7419b]
2699
+ - Updated dependencies [fc7db05]
2700
+ - Updated dependencies [fc7db05]
2701
+ - Updated dependencies [9ed8d0f]
2702
+ - Updated dependencies [c73cdb5]
2703
+ - Updated dependencies [6f5719e]
2704
+ - Updated dependencies [b34cc14]
2705
+ - Updated dependencies [ab18797]
2706
+ - Updated dependencies [d0097af]
2707
+ - Updated dependencies [432882b]
2708
+ - Updated dependencies [64dae8e]
2709
+ - Updated dependencies [b06e374]
2710
+ - Updated dependencies [06a8af5]
2711
+ - Updated dependencies [6a91586]
2712
+ - Updated dependencies [a04d7c6]
2713
+ - Updated dependencies [5ccc500]
2714
+ - Updated dependencies [f3c2bb0]
2715
+ - Updated dependencies [978507b]
2716
+ - Updated dependencies [778138e]
2717
+ - Updated dependencies [9801765]
2718
+ - Updated dependencies [9cebfca]
2719
+ - Updated dependencies [460575f]
2720
+ - Updated dependencies [d796c8d]
2721
+ - Updated dependencies [594704f]
2722
+ - Updated dependencies [d3995fe]
2723
+ - Updated dependencies [1b1d772]
2724
+ - Updated dependencies [d88e20f]
2725
+ - Updated dependencies [f66072d]
2726
+ - Updated dependencies [2d7304d]
2727
+ - Updated dependencies [636b236]
2728
+ - Updated dependencies [4172589]
2729
+ - Updated dependencies [d6d8fb9]
2730
+ - Updated dependencies [64d624d]
2731
+ - Updated dependencies [053fdc8]
2732
+ - Updated dependencies [41b7ce3]
2733
+ - Updated dependencies [ae476b8]
2734
+ - Updated dependencies [39f4309]
2735
+ - Updated dependencies [95bad12]
2736
+ - Updated dependencies [d2fb6ef]
2737
+ - Updated dependencies [7cd3987]
2738
+ - Updated dependencies [ee3b878]
2739
+ - Updated dependencies [e304a4e]
2740
+ - Updated dependencies [fda49e5]
2741
+ - Updated dependencies [490d9a9]
2742
+ - Updated dependencies [1117414]
2743
+ - Updated dependencies [6d63cd0]
2744
+ - Updated dependencies [fc62bb4]
2745
+ - Updated dependencies [41df893]
2746
+ - Updated dependencies [0cba1b7]
2747
+ - Updated dependencies [7c96c94]
2748
+ - Updated dependencies [4da5109]
2749
+ - Updated dependencies [00f3eb5]
2750
+ - Updated dependencies [1ec291c]
2751
+ - Updated dependencies [453dbaa]
2752
+ - Updated dependencies [95f8704]
2753
+ - Updated dependencies [f8cdbf2]
2754
+ - Updated dependencies [69a2163]
2755
+ - Updated dependencies [24e027e]
2756
+ - Updated dependencies [2c3cd1b]
2757
+ - Updated dependencies [e176053]
2758
+ - Updated dependencies [e30ed15]
2759
+ - Updated dependencies [90665e0]
2760
+ - Updated dependencies [8d3a529]
2761
+ - Updated dependencies [5ac2e2c]
2762
+ - Updated dependencies [194fae1]
2763
+ - Updated dependencies [63d54dd]
2764
+ - Updated dependencies [7e19d03]
2765
+ - Updated dependencies [b08b7eb]
2766
+ - Updated dependencies [1e946c9]
2767
+ - Updated dependencies [546ddf7]
2768
+ - Updated dependencies [864154e]
2769
+ - Updated dependencies [b023625]
2770
+ - Updated dependencies [75bd83d]
2771
+ - Updated dependencies [44d075b]
2772
+ - Updated dependencies [40c479a]
2773
+ - Updated dependencies [b4393e5]
2774
+ - Updated dependencies [971d387]
2775
+ - Updated dependencies [ee851c3]
2776
+ - Updated dependencies [6414dfd]
2777
+ - Updated dependencies [a8d5c71]
2778
+ - Updated dependencies [905b21f]
2779
+ - Updated dependencies [88e9109]
2780
+ - Updated dependencies [2c45966]
2781
+ - Updated dependencies [db3a600]
2782
+ - Updated dependencies [3a3db76]
2783
+ - Updated dependencies [0d723a3]
2784
+ - Updated dependencies [0c95d3d]
2785
+ - Updated dependencies [3e4fa2c]
2786
+ - Updated dependencies [b5b928a]
2787
+ - Updated dependencies [6fd2cf7]
2788
+ - Updated dependencies [5fa06c4]
2789
+ - Updated dependencies [52a43de]
2790
+ - Updated dependencies [195052f]
2791
+ - Updated dependencies [e4559d1]
2792
+ - Updated dependencies [2c71482]
2793
+ - Updated dependencies [129bcc5]
2794
+ - Updated dependencies [d3005f7]
2795
+ - Updated dependencies [1e7fe0a]
2796
+ - Updated dependencies [a26b9e4]
2797
+ - Updated dependencies [5ef9c4f]
2798
+ - Updated dependencies [46f0bb4]
2799
+ - Updated dependencies [06b82b8]
2800
+ - Updated dependencies [8ec11e1]
2801
+ - Updated dependencies [6f81384]
2802
+ - Updated dependencies [22ba927]
2803
+ - Updated dependencies [8631c32]
2804
+ - Updated dependencies [f8c70f4]
2805
+ - Updated dependencies [5d3a2d1]
2806
+ - Updated dependencies [8f1d995]
2807
+ - Updated dependencies [b362c1b]
2808
+ - Updated dependencies [f9c34df]
2809
+ - Updated dependencies [dddb942]
2810
+ - Updated dependencies [00c665e]
2811
+ - Updated dependencies [29754cf]
2812
+ - Updated dependencies [d7de534]
2813
+ - Updated dependencies [3c2b6f7]
2814
+ - Updated dependencies [6e88630]
2815
+ - Updated dependencies [b84dc18]
2816
+ - Updated dependencies [ac8abb0]
2817
+ - Updated dependencies [9d86e1d]
2818
+ - Updated dependencies [3a5817f]
2819
+ - Updated dependencies [99a3c2d]
2820
+ - Updated dependencies [5961030]
2821
+ - Updated dependencies [f24de8b]
2822
+ - Updated dependencies [c8ea8af]
2823
+ - Updated dependencies [9602dc8]
2824
+ - Updated dependencies [3777538]
2825
+ - Updated dependencies [3190414]
2826
+ - Updated dependencies [4e480f5]
2827
+ - Updated dependencies [38a123c]
2828
+ - Updated dependencies [299102e]
2829
+ - Updated dependencies [30c73cd]
2830
+ - Updated dependencies [830ed58]
2831
+ - Updated dependencies [d7acad6]
2832
+ - Updated dependencies [45a9aeb]
2833
+ - Updated dependencies [713db46]
2834
+ - Updated dependencies [c71e14d]
2835
+ - Updated dependencies [bf3a03c]
2836
+ - Updated dependencies [cb55718]
2837
+ - Updated dependencies [748494b]
2838
+ - Updated dependencies [5967be0]
2839
+ - Updated dependencies [831be72]
2840
+ - Updated dependencies [29cb85b]
2841
+ - Updated dependencies [3e028c8]
2842
+ - Updated dependencies [d0889e2]
2843
+ - Updated dependencies [ce503e5]
2844
+ - Updated dependencies [f20dcf0]
2845
+ - Updated dependencies [12402a9]
2846
+ - Updated dependencies [aff3d7a]
2847
+ - Updated dependencies [4ca30d0]
2848
+ - Updated dependencies [7a5da14]
2849
+ - Updated dependencies [fff9645]
2850
+ - Updated dependencies [9c3b7ce]
2851
+ - Updated dependencies [2c1c967]
2852
+ - Updated dependencies [9486ac6]
2853
+ - Updated dependencies [9486ac6]
2854
+ - Updated dependencies [4d5f9b4]
2855
+ - Updated dependencies [d6ceb8d]
2856
+ - Updated dependencies [dc4365c]
2857
+ - Updated dependencies [e321d52]
2858
+ - Updated dependencies [969ba84]
2859
+ - Updated dependencies [98188c2]
2860
+ - Updated dependencies [4c68077]
2861
+ - Updated dependencies [7977ff9]
2862
+ - Updated dependencies [3beef6d]
2863
+ - Updated dependencies [06b8c42]
2864
+ - Updated dependencies [46b9bc9]
2865
+ - Updated dependencies [f46bd39]
2866
+ - Updated dependencies [b98352a]
2867
+ - Updated dependencies [b76ca67]
2868
+ - Updated dependencies [45ac2cb]
2869
+ - Updated dependencies [b97790a]
2870
+ - Updated dependencies [dbd5194]
2871
+ - Updated dependencies [7c9b044]
2872
+ - Updated dependencies [e552c31]
2873
+ - Updated dependencies [d47de51]
2874
+ - Updated dependencies [3fe6463]
2875
+ - Updated dependencies [b392674]
2876
+ - Updated dependencies [4f3a1e2]
2877
+ - Updated dependencies [31ab372]
2878
+ - Updated dependencies [846889b]
2879
+ - Updated dependencies [2acd8e1]
2880
+ - Updated dependencies [7b90231]
2881
+ - Updated dependencies [26896c6]
2882
+ - Updated dependencies [a439e16]
2883
+ - Updated dependencies [67fc3b0]
2884
+ - Updated dependencies [8579e34]
2885
+ - Updated dependencies [d57db5d]
2886
+ - Updated dependencies [33a3b3c]
2887
+ - Updated dependencies [b87f15b]
2888
+ - Updated dependencies [9409eb9]
2889
+ - Updated dependencies [045d20b]
2890
+ - Updated dependencies [a2d2515]
2891
+ - Updated dependencies [c18d099]
2892
+ - Updated dependencies [0caacca]
2893
+ - Updated dependencies [adb2a86]
2894
+ - Updated dependencies [03380aa]
2895
+ - Updated dependencies [4562ea5]
2896
+ - Updated dependencies [3619792]
2897
+ - Updated dependencies [3561bd2]
2898
+ - Updated dependencies [bf97b98]
2899
+ - Updated dependencies [320374d]
2900
+ - Updated dependencies [b0d308d]
2901
+ - Updated dependencies [b458300]
2902
+ - Updated dependencies [40f34b4]
2903
+ - Updated dependencies [bd0376d]
2904
+ - Updated dependencies [8063bcb]
2905
+ - Updated dependencies [b74a859]
2906
+ - Updated dependencies [d4493fd]
2907
+ - Updated dependencies [240b80f]
2908
+ - Updated dependencies [77cb489]
2909
+ - Updated dependencies [bfaa158]
2910
+ - Updated dependencies [777e5c6]
2911
+ - Updated dependencies [0c386dd]
2912
+ - Updated dependencies [39d69ad]
2913
+ - Updated dependencies [9e37d9b]
2914
+ - Updated dependencies [5ad86dd]
2915
+ - Updated dependencies [16a725f]
2916
+ - Updated dependencies [c4326fe]
2917
+ - Updated dependencies [4dfdcc3]
2918
+ - Updated dependencies [6a449fc]
2919
+ - Updated dependencies [446d93d]
2920
+ - Updated dependencies [ecd9cb2]
2921
+ - Updated dependencies [f08bcd9]
2922
+ - Updated dependencies [98d4108]
2923
+ - Updated dependencies [0e3b3be]
2924
+ - Updated dependencies [a29ae2d]
2925
+ - Updated dependencies [220c18d]
2926
+ - Updated dependencies [eeb6c2f]
2927
+ - Updated dependencies [00d3f09]
2928
+ - Updated dependencies [4388f71]
2929
+ - Updated dependencies [0b1ac58]
2930
+ - Updated dependencies [c93b4d5]
2931
+ - Updated dependencies [c1fe272]
2932
+ - Updated dependencies [3cab570]
2933
+ - Updated dependencies [8ad218d]
2934
+ - Updated dependencies [3e41187]
2935
+ - Updated dependencies [5f78953]
2936
+ - Updated dependencies [639114c]
2937
+ - Updated dependencies [639114c]
2938
+ - Updated dependencies [1490691]
2939
+ - Updated dependencies [e8e4c4d]
2940
+ - Updated dependencies [1f31d3a]
2941
+ - Updated dependencies [d1842ab]
2942
+ - Updated dependencies [854cba3]
2943
+ - Updated dependencies [78ca238]
2944
+ - Updated dependencies [d8ec8d6]
2945
+ - Updated dependencies [351eb31]
2946
+ - Updated dependencies [866cd1d]
2947
+ - Updated dependencies [20c04b2]
2948
+ - Updated dependencies [01c9023]
2949
+ - Updated dependencies [48c19bd]
2950
+ - Updated dependencies [a6d8b8d]
2951
+ - Updated dependencies [4b5bb95]
2952
+ - Updated dependencies [b652514]
2953
+ - Updated dependencies [adbda1b]
2954
+ - Updated dependencies [adbda1b]
2955
+ - Updated dependencies [8952395]
2956
+ - Updated dependencies [e2b3826]
2957
+ - Updated dependencies [a338037]
2958
+ - Updated dependencies [0348bc9]
2959
+ - Updated dependencies [e8c553b]
2960
+ - Updated dependencies [2e32ed4]
2961
+ - Updated dependencies [554e647]
2962
+ - Updated dependencies [3ed3eec]
2963
+ - Updated dependencies [7c3df8f]
2964
+ - Updated dependencies [a4514e8]
2965
+ - Updated dependencies [6411def]
2966
+ - Updated dependencies [db3896c]
2967
+ - Updated dependencies [b9f5ff1]
2968
+ - Updated dependencies [e75f4c9]
2969
+ - Updated dependencies [19f1639]
2970
+ - Updated dependencies [4704aa4]
2971
+ - Updated dependencies [47547d0]
2972
+ - Updated dependencies [1bee5d0]
2973
+ - Updated dependencies [63a8828]
2974
+ - Updated dependencies [b61d7d8]
2975
+ - Updated dependencies [858cd72]
2976
+ - Updated dependencies [cfc9b6d]
2977
+ - Updated dependencies [dc0a60b]
2978
+ - Updated dependencies [554f2b6]
2979
+ - Updated dependencies [72f55c9]
2980
+ - Updated dependencies [26e06d7]
2981
+ - Updated dependencies [669d71b]
2982
+ - Updated dependencies [ed27d7c]
2983
+ - Updated dependencies [52c8cf7]
2984
+ - Updated dependencies [2ceb43a]
2985
+ - Updated dependencies [7cdd2b9]
2986
+ - Updated dependencies [52c8cf7]
2987
+ - Updated dependencies [3399704]
2988
+ - Updated dependencies [02fe257]
2989
+ - Updated dependencies [71a4a53]
2990
+ - Updated dependencies [7bf244b]
2991
+ - Updated dependencies [f0bb9fa]
2992
+ - Updated dependencies [81a2eb1]
2993
+ - Updated dependencies [caa0cd3]
2994
+ - Updated dependencies [caa0cd3]
2995
+ - Updated dependencies [20cb8db]
2996
+ - Updated dependencies [25c7d58]
2997
+ - Updated dependencies [00d2fa6]
2998
+ - Updated dependencies [77b2a18]
2999
+ - Updated dependencies [c6198c2]
3000
+ - Updated dependencies [721d1e0]
3001
+ - Updated dependencies [c2f0f48]
3002
+ - Updated dependencies [1237ae4]
3003
+ - Updated dependencies [2f61238]
3004
+ - Updated dependencies [51eb515]
3005
+ - Updated dependencies [c354ce5]
3006
+ - Updated dependencies [8fe8e5c]
3007
+ - Updated dependencies [feac439]
3008
+ - Updated dependencies [9ae871d]
3009
+ - Updated dependencies [efbd566]
3010
+ - Updated dependencies [2a5bf45]
3011
+ - Updated dependencies [9587fc9]
3012
+ - Updated dependencies [e62c44e]
3013
+ - Updated dependencies [daf9d57]
3014
+ - Updated dependencies [fe8f451]
3015
+ - Updated dependencies [23b9958]
3016
+ - Updated dependencies [c15d7ec]
3017
+ - Updated dependencies [5d0876c]
3018
+ - Updated dependencies [f7ace0a]
3019
+ - Updated dependencies [b041b9c]
3020
+ - Updated dependencies [ce2aaef]
3021
+ - Updated dependencies [544ecba]
3022
+ - Updated dependencies [2ce2612]
3023
+ - Updated dependencies [bc640ec]
3024
+ - Updated dependencies [1e215c4]
3025
+ - Updated dependencies [da6e191]
3026
+ - Updated dependencies [3e377c9]
3027
+ - Updated dependencies [a3eb5d0]
3028
+ - Updated dependencies [4ce14f1]
3029
+ - Updated dependencies [aef97e5]
3030
+ - Updated dependencies [2af1fa7]
3031
+ - Updated dependencies [c14d3a0]
3032
+ - Updated dependencies [a137d0c]
3033
+ - Updated dependencies [caf477f]
3034
+ - Updated dependencies [f6375da]
3035
+ - Updated dependencies [967e5d8]
3036
+ - Updated dependencies [c907a9c]
3037
+ - Updated dependencies [a4611b3]
3038
+ - Updated dependencies [20316ba]
3039
+ - Updated dependencies [d3499b3]
3040
+ - Updated dependencies [91f9276]
3041
+ - Updated dependencies [309c75e]
3042
+ - Updated dependencies [c9f9bae]
3043
+ - Updated dependencies [18897a4]
3044
+ - Updated dependencies [8b7ea39]
3045
+ - Updated dependencies [a915064]
3046
+ - Updated dependencies [dcbf0b2]
3047
+ - Updated dependencies [52cac38]
3048
+ - Updated dependencies [93fea2e]
3049
+ - Updated dependencies [1422a92]
3050
+ - Updated dependencies [d05fe17]
3051
+ - Updated dependencies [a480f79]
3052
+ - Updated dependencies [f08d1a8]
3053
+ - Updated dependencies [64a252d]
3054
+ - Updated dependencies [786bc91]
3055
+ - Updated dependencies [75fca96]
3056
+ - Updated dependencies [7ca6ddd]
3057
+ - Updated dependencies [f1cd290]
3058
+ - Updated dependencies [5a41ce7]
3059
+ - Updated dependencies [8d50bc2]
3060
+ - Updated dependencies [604476d]
3061
+ - Updated dependencies [d1bebb0]
3062
+ - Updated dependencies [95bf128]
3063
+ - Updated dependencies [335abea]
3064
+ - Updated dependencies [edea22a]
3065
+ - Updated dependencies [0f5cadf]
3066
+ - Updated dependencies [4f9f1ee]
3067
+ - Updated dependencies [66e8b2a]
3068
+ - Updated dependencies [aa083cd]
3069
+ - Updated dependencies [12b5992]
3070
+ - Updated dependencies [b93e245]
3071
+ - Updated dependencies [c842594]
3072
+ - Updated dependencies [290de37]
3073
+ - Updated dependencies [e1c27e4]
3074
+ - Updated dependencies [8c8da45]
3075
+ - Updated dependencies [8cd8eb5]
3076
+ - Updated dependencies [f52a9d7]
3077
+ - Updated dependencies [cf1d29e]
3078
+ - Updated dependencies [1bd79c8]
3079
+ - Updated dependencies [af9e957]
3080
+ - Updated dependencies [b1030c7]
3081
+ - Updated dependencies [c974edf]
3082
+ - Updated dependencies [592402e]
3083
+ - Updated dependencies [ad852b6]
3084
+ - Updated dependencies [6778809]
3085
+ - Updated dependencies [3a3dd28]
3086
+ - Updated dependencies [7fb22a1]
3087
+ - Updated dependencies [ad66d79]
3088
+ - Updated dependencies [0758bd8]
3089
+ - Updated dependencies [ee4d19f]
3090
+ - Updated dependencies [37149ec]
3091
+ - Updated dependencies [496d31d]
3092
+ - Updated dependencies [7ed9808]
3093
+ - Updated dependencies [0ea7054]
3094
+ - Updated dependencies [ac0e39a]
3095
+ - Updated dependencies [9a853f2]
3096
+ - Updated dependencies [cb847fd]
3097
+ - Updated dependencies [ee70287]
3098
+ - Updated dependencies [3e98e13]
3099
+ - Updated dependencies [a695f50]
3100
+ - Updated dependencies [fc32921]
3101
+ - Updated dependencies [4eaa835]
3102
+ - Updated dependencies [8f9d87a]
3103
+ - Updated dependencies [b1777ae]
3104
+ - Updated dependencies [24845c4]
3105
+ - Updated dependencies [6f864cf]
3106
+ - Updated dependencies [24d1edd]
3107
+ - Updated dependencies [645087c]
3108
+ - Updated dependencies [33f4a19]
3109
+ - Updated dependencies [6e9a3d4]
3110
+ - Updated dependencies [4a292d2]
3111
+ - Updated dependencies [5323168]
3112
+ - Updated dependencies [841dd2b]
3113
+ - Updated dependencies [3014fc0]
3114
+ - Updated dependencies [dacb402]
3115
+ - Updated dependencies [846cec0]
3116
+ - Updated dependencies [91facae]
3117
+ - Updated dependencies [b38014e]
3118
+ - Updated dependencies [e2feb13]
3119
+ - Updated dependencies [474797d]
3120
+ - Updated dependencies [704e695]
3121
+ - Updated dependencies [9dcc545]
3122
+ - Updated dependencies [d7fecfb]
3123
+ - Updated dependencies [c13d39e]
3124
+ - Updated dependencies [a407bd6]
3125
+ - Updated dependencies [317dbce]
3126
+ - Updated dependencies [309728c]
3127
+ - Updated dependencies [c03d03b]
3128
+ - Updated dependencies [e6ec217]
3129
+ - Updated dependencies [aa08d7e]
3130
+ - Updated dependencies [3a43a15]
3131
+ - Updated dependencies [868e825]
3132
+ - Updated dependencies [f76f436]
3133
+ - Updated dependencies [ce45a03]
3134
+ - Updated dependencies [7cf6f38]
3135
+ - Updated dependencies [fd9c50a]
3136
+ - Updated dependencies [421544b]
3137
+ - Updated dependencies [5cc8c28]
3138
+ - Updated dependencies [fb01022]
3139
+ - Updated dependencies [e9d9212]
3140
+ - Updated dependencies [ecfb693]
3141
+ - Updated dependencies [639ca9d]
3142
+ - Updated dependencies [2152962]
3143
+ - Updated dependencies [40a7c53]
3144
+ - Updated dependencies [abc1b18]
3145
+ - Updated dependencies [81a51db]
3146
+ - Updated dependencies [67749c7]
3147
+ - Updated dependencies [507b61b]
3148
+ - Updated dependencies [512c84b]
3149
+ - Updated dependencies [c300267]
3150
+ - Updated dependencies [fb3a101]
3151
+ - Updated dependencies [d4733f2]
3152
+ - Updated dependencies [7c9145f]
3153
+ - Updated dependencies [1570eac]
3154
+ - Updated dependencies [f391ede]
3155
+ - Updated dependencies [f5cfbbd]
3156
+ - Updated dependencies [f5cfbbd]
3157
+ - Updated dependencies [8b532cb]
3158
+ - Updated dependencies [64c3cdd]
3159
+ - Updated dependencies [4d65991]
3160
+ - Updated dependencies [c42554e]
3161
+ - Updated dependencies [3e71b26]
3162
+ - Updated dependencies [b89583b]
3163
+ - Updated dependencies [70c4523]
3164
+ - Updated dependencies [555b4ec]
3165
+ - Updated dependencies [64f1cf1]
3166
+ - Updated dependencies [da5e4f6]
3167
+ - Updated dependencies [1ccfc23]
3168
+ - Updated dependencies [542718f]
3169
+ - Updated dependencies [7f27bc5]
3170
+ - Updated dependencies [0a174f3]
3171
+ - Updated dependencies [cc00c59]
3172
+ - Updated dependencies [676f677]
3173
+ - Updated dependencies [f95b140]
3174
+ - Updated dependencies [541ce4e]
3175
+ - Updated dependencies [6479086]
3176
+ - Updated dependencies [d79f525]
3177
+ - Updated dependencies [d1865d2]
3178
+ - Updated dependencies [88a629d]
3179
+ - Updated dependencies [cdd2542]
3180
+ - Updated dependencies [ab77513]
3181
+ - Updated dependencies [55ba3ff]
3182
+ - Updated dependencies [0b138da]
3183
+ - Updated dependencies [3ecc369]
3184
+ - Updated dependencies [f1190b0]
3185
+ - Updated dependencies [561abef]
3186
+ - Updated dependencies [ef52001]
3187
+ - Updated dependencies [6a4680b]
3188
+ - Updated dependencies [c3a4273]
3189
+ - Updated dependencies [abf710d]
3190
+ - Updated dependencies [093af32]
3191
+ - Updated dependencies [6df26f0]
3192
+ - Updated dependencies [1bd1be7]
3193
+ - Updated dependencies [d234fa9]
3194
+ - Updated dependencies [adf5812]
3195
+ - Updated dependencies [0eaed83]
3196
+ - Updated dependencies [e36acd4]
3197
+ - Updated dependencies [5058336]
3198
+ - Updated dependencies [2f6b2bf]
3199
+ - Updated dependencies [2028b31]
3200
+ - Updated dependencies [16a1a51]
3201
+ - Updated dependencies [63601ab]
3202
+ - Updated dependencies [c372b29]
3203
+ - Updated dependencies [152f0a7]
3204
+ - Updated dependencies [8693b85]
3205
+ - Updated dependencies [e82dad1]
3206
+ - Updated dependencies [58b7b3d]
3207
+ - Updated dependencies [e77a003]
3208
+ - Updated dependencies [84defab]
3209
+ - Updated dependencies [681d3f1]
3210
+ - Updated dependencies [969d4f2]
3211
+ - Updated dependencies [88561fd]
3212
+ - Updated dependencies [f3bc481]
3213
+ - Updated dependencies [b79aac2]
3214
+ - Updated dependencies [93fc0e7]
3215
+ - Updated dependencies [0601af1]
3216
+ - Updated dependencies [a4b723f]
3217
+ - Updated dependencies [2b10ca0]
3218
+ - Updated dependencies [7db4a81]
3219
+ - Updated dependencies [19a0b0e]
3220
+ - Updated dependencies [526fc11]
3221
+ - Updated dependencies [f8e3e9a]
3222
+ - Updated dependencies [b9d47ec]
3223
+ - Updated dependencies [3b6bc69]
3224
+ - Updated dependencies [6214db6]
3225
+ - Updated dependencies [6732df4]
3226
+ - Updated dependencies [fe9e0d0]
3227
+ - Updated dependencies [63fb72c]
3228
+ - Updated dependencies [804831c]
3229
+ - Updated dependencies [9f5c017]
3230
+ - Updated dependencies [c271413]
3231
+ - Updated dependencies [279e48e]
3232
+ - Updated dependencies [4784bb3]
3233
+ - Updated dependencies [8700d6d]
3234
+ - Updated dependencies [8db2a0f]
3235
+ - Updated dependencies [689953a]
3236
+ - Updated dependencies [30443fb]
3237
+ - Updated dependencies [8d3dbb2]
3238
+ - Updated dependencies [efc1c9c]
3239
+ - Updated dependencies [7d6439c]
3240
+ - Updated dependencies [da45e6b]
3241
+ - Updated dependencies [7533465]
3242
+ - Updated dependencies [835f0f3]
3243
+ - Updated dependencies [6d5db7b]
3244
+ - Updated dependencies [a9d97be]
3245
+ - Updated dependencies [ed35b44]
3246
+ - Updated dependencies [e6040ef]
3247
+ - Updated dependencies [9ba7e9c]
3248
+ - Updated dependencies [729e851]
3249
+ - Updated dependencies [96919a4]
3250
+ - Updated dependencies [345e24a]
3251
+ - Updated dependencies [3bc1bb4]
3252
+ - Updated dependencies [20b507a]
3253
+ - Updated dependencies [2e471dc]
3254
+ - Updated dependencies [6748587]
3255
+ - Updated dependencies [be50942]
3256
+ - Updated dependencies [775e079]
3257
+ - Updated dependencies [7e8b3c0]
3258
+ - Updated dependencies [53374dc]
3259
+ - Updated dependencies [f6fb83f]
3260
+ - Updated dependencies [2049b03]
3261
+ - Updated dependencies [2bf34f7]
3262
+ - Updated dependencies [15b33ae]
3263
+ - Updated dependencies [7cbc724]
3264
+ - Updated dependencies [4a94c38]
3265
+ - Updated dependencies [7098eed]
3266
+ - Updated dependencies [3df7c5c]
3267
+ - Updated dependencies [fb91ac9]
3268
+ - Updated dependencies [fb91ac9]
3269
+ - Updated dependencies [641fb55]
3270
+ - Updated dependencies [8524372]
3271
+ - Updated dependencies [7cbefa5]
3272
+ - Updated dependencies [72d6587]
3273
+ - Updated dependencies [a272a4f]
3274
+ - Updated dependencies [55f39ee]
3275
+ - Updated dependencies [502eb58]
3276
+ - Updated dependencies [0ce32d5]
3277
+ - Updated dependencies [0970a0e]
3278
+ - Updated dependencies [e427e9c]
3279
+ - Updated dependencies [bbc9dc3]
3280
+ - Updated dependencies [02f1813]
3281
+ - Updated dependencies [1ef89c0]
3282
+ - Updated dependencies [ba0b61a]
3283
+ - Updated dependencies [ba0b61a]
3284
+ - Updated dependencies [ba0b61a]
3285
+ - Updated dependencies [ac716ff]
3286
+ - Updated dependencies [e05553c]
3287
+ - Updated dependencies [697aabc]
3288
+ - Updated dependencies [f0f3cd5]
3289
+ - Updated dependencies [ab856ed]
3290
+ - Updated dependencies [f0f2046]
3291
+ - Updated dependencies [20f3e65]
3292
+ - Updated dependencies [bbba098]
3293
+ - Updated dependencies [87af769]
3294
+ - Updated dependencies [3be720e]
3295
+ - Updated dependencies [80a0ecd]
3296
+ - Updated dependencies [43c0d17]
3297
+ - Updated dependencies [c3df43a]
3298
+ - Updated dependencies [d16d0e9]
3299
+ - Updated dependencies [bbe57fd]
3300
+ - Updated dependencies [272a530]
3301
+ - Updated dependencies [462bafb]
3302
+ - Updated dependencies [1779e8d]
3303
+ - Updated dependencies [9aa2a57]
3304
+ - Updated dependencies [f7fcc2c]
3305
+ - Updated dependencies [f0f4d6c]
3306
+ - Updated dependencies [4128188]
3307
+ - Updated dependencies [b253c4e]
3308
+ - Updated dependencies [78a9c67]
3309
+ - Updated dependencies [2e97c8c]
3310
+ - Updated dependencies [4a7ef0d]
3311
+ - Updated dependencies [4598f6d]
3312
+ - Updated dependencies [dea17b4]
3313
+ - Updated dependencies [89bb77a]
3314
+ - Updated dependencies [06611e4]
3315
+ - Updated dependencies [44152c4]
3316
+ - Updated dependencies [3939545]
3317
+ - Updated dependencies [66abbde]
3318
+ - Updated dependencies [dc3893d]
3319
+ - Updated dependencies [1bbaa16]
3320
+ - Updated dependencies [6ee259a]
3321
+ - Updated dependencies [7649f43]
3322
+ - Updated dependencies [d0f52e4]
3323
+ - Updated dependencies [e708426]
3324
+ - Updated dependencies [33e1697]
3325
+ - Updated dependencies [3b6d53b]
3326
+ - Updated dependencies [e22fa12]
3327
+ - Updated dependencies [1560d46]
3328
+ - Updated dependencies [a017617]
3329
+ - Updated dependencies [276d174]
3330
+ - Updated dependencies [2982ed9]
3331
+ - Updated dependencies [741864f]
3332
+ - Updated dependencies [a8198de]
3333
+ - Updated dependencies [0c789a4]
3334
+ - Updated dependencies [05a49f2]
3335
+ - Updated dependencies [b234a84]
3336
+ - Updated dependencies [a78cd37]
3337
+ - Updated dependencies [5ea623e]
3338
+ - Updated dependencies [4d7d322]
3339
+ - Updated dependencies [dc49246]
3340
+ - Updated dependencies [5eabe86]
3341
+ - Updated dependencies [ca5d671]
3342
+ - Updated dependencies [32bf2d6]
3343
+ - Updated dependencies [ff0c384]
3344
+ - Updated dependencies [af4fb29]
3345
+ - Updated dependencies [c698a81]
3346
+ - Updated dependencies [ff5ef1c]
3347
+ - Updated dependencies [befd40c]
3348
+ - Updated dependencies [905913c]
3349
+ - Updated dependencies [9a97800]
3350
+ - Updated dependencies [6358a2d]
3351
+ - Updated dependencies [6bca0e4]
3352
+ - Updated dependencies [81c0bc4]
3353
+ - Updated dependencies [3c76801]
3354
+ - Updated dependencies [d06fba8]
3355
+ - Updated dependencies [60500cb]
3356
+ - Updated dependencies [2fcefb9]
3357
+ - Updated dependencies [77f846a]
3358
+ - Updated dependencies [bc5870c]
3359
+ - Updated dependencies [b55a346]
3360
+ - Updated dependencies [065bba7]
3361
+ - Updated dependencies [f760064]
3362
+ - Updated dependencies [dd19463]
3363
+ - Updated dependencies [6791717]
3364
+ - Updated dependencies [8ea3bee]
3365
+ - Updated dependencies [100547e]
3366
+ - Updated dependencies [3a58149]
3367
+ - Updated dependencies [6d1c155]
3368
+ - Updated dependencies [d7573b3]
3369
+ - Updated dependencies [bf3edfe]
3370
+ - Updated dependencies [2c8474c]
3371
+ - Updated dependencies [6ce89da]
3372
+ - Updated dependencies [0e05aac]
3373
+ - Updated dependencies [ae61ad4]
3374
+ - Updated dependencies [5aed9e4]
3375
+ - Updated dependencies [83c77dc]
3376
+ - Updated dependencies [3c9fca3]
3377
+ - Updated dependencies [18a8e7d]
3378
+ - Updated dependencies [e7957ab]
3379
+ - Updated dependencies [f7e34ca]
3380
+ - Updated dependencies [e719ebd]
3381
+ - Updated dependencies [516583b]
3382
+ - Updated dependencies [f9e4f91]
3383
+ - Updated dependencies [6ef48b1]
3384
+ - Updated dependencies [58be55e]
3385
+ - Updated dependencies [fa429cf]
3386
+ - Updated dependencies [ed8df3e]
3387
+ - Updated dependencies [fe76ece]
3388
+ - Updated dependencies [8b446f5]
3389
+ - Updated dependencies [8e74b27]
3390
+ - Updated dependencies [7102b20]
3391
+ - Updated dependencies [8ebd57f]
3392
+ - Updated dependencies [968dc1e]
3393
+ - Updated dependencies [9a1fb41]
3394
+ - Updated dependencies [617707a]
3395
+ - Updated dependencies [c40f3b8]
3396
+ - Updated dependencies [58770f3]
3397
+ - Updated dependencies [aefe428]
3398
+ - Updated dependencies [485f096]
3399
+ - Updated dependencies [7357447]
3400
+ - Updated dependencies [199d31b]
3401
+ - Updated dependencies [b655a9d]
3402
+ - Updated dependencies [a865c73]
3403
+ - Updated dependencies [3e01cb5]
3404
+ - Updated dependencies [7138bc1]
3405
+ - Updated dependencies [cef27e2]
3406
+ - Updated dependencies [4e8622b]
3407
+ - Updated dependencies [dffd752]
3408
+ - Updated dependencies [06973aa]
3409
+ - Updated dependencies [50798f3]
3410
+ - Updated dependencies [6a576c9]
3411
+ - Updated dependencies [0b12a33]
3412
+ - Updated dependencies [105f3c5]
3413
+ - Updated dependencies [3ccd9e8]
3414
+ - Updated dependencies [689b979]
3415
+ - Updated dependencies [c70f865]
3416
+ - Updated dependencies [e546222]
3417
+ - Updated dependencies [fd13f52]
3418
+ - Updated dependencies [d7bd274]
3419
+ - Updated dependencies [98c3a74]
3420
+ - Updated dependencies [fffa30d]
3421
+ - Updated dependencies [e4e9557]
3422
+ - Updated dependencies [7a28e1e]
3423
+ - Updated dependencies [ebce5a3]
3424
+ - Updated dependencies [fb336df]
3425
+ - Updated dependencies [6c1b105]
3426
+ - Updated dependencies [4dc80d0]
3427
+ - Updated dependencies [9d9040d]
3428
+ - Updated dependencies [20e317c]
3429
+ - Updated dependencies [0fce2ef]
3430
+ - Updated dependencies [42df928]
3431
+ - Updated dependencies [0e2ddd4]
3432
+ - Updated dependencies [b7479ab]
3433
+ - Updated dependencies [9850c6e]
3434
+ - Updated dependencies [de570cc]
3435
+ - Updated dependencies [b2ea297]
3436
+ - Updated dependencies [5b5a5c3]
3437
+ - Updated dependencies [14582b8]
3438
+ - Updated dependencies [51e144e]
3439
+ - Updated dependencies [19cbf10]
3440
+ - Updated dependencies [b6e83be]
3441
+ - Updated dependencies [7e50e84]
3442
+ - Updated dependencies [ab92940]
3443
+ - Updated dependencies [a691c0b]
3444
+ - Updated dependencies [0b1326d]
3445
+ - Updated dependencies [1e66879]
3446
+ - Updated dependencies [c5200f0]
3447
+ - Updated dependencies [af3861f]
3448
+ - Updated dependencies [2a79e84]
3449
+ - Updated dependencies [2609812]
3450
+ - Updated dependencies [515f171]
3451
+ - Updated dependencies [1f4e029]
3452
+ - Updated dependencies [4f14ad7]
3453
+ - Updated dependencies [258d264]
3454
+ - Updated dependencies [cac64b3]
3455
+ - Updated dependencies [4bb940b]
3456
+ - Updated dependencies [17fbbaf]
3457
+ - Updated dependencies [d8cf1cb]
3458
+ - Updated dependencies [0d1e702]
3459
+ - Updated dependencies [b03ba3a]
3460
+ - Updated dependencies [0068348]
3461
+ - Updated dependencies [641543f]
3462
+ - Updated dependencies [8a44390]
3463
+ - Updated dependencies [8033ad1]
3464
+ - Updated dependencies [fa140b8]
3465
+ - Updated dependencies [71cba28]
3466
+ - Updated dependencies [190fbd0]
3467
+ - Updated dependencies [c00bf28]
3468
+ - Updated dependencies [23705b7]
3469
+ - Updated dependencies [93127bd]
3470
+ - Updated dependencies [f2158ec]
3471
+ - Updated dependencies [759606e]
3472
+ - Updated dependencies [fd8dace]
3473
+ - Updated dependencies [72ffc34]
3474
+ - Updated dependencies [a51fa0c]
3475
+ - Updated dependencies [51f3d8d]
3476
+ - Updated dependencies [bf28341]
3477
+ - Updated dependencies [78cbdb5]
3478
+ - Updated dependencies [b7543a9]
3479
+ - Updated dependencies [6c6cee7]
3480
+ - Updated dependencies [42887e0]
3481
+ - Updated dependencies [f1690d4]
3482
+ - Updated dependencies [83fe6e7]
3483
+ - Updated dependencies [d1ab06f]
3484
+ - Updated dependencies [38a9568]
3485
+ - Updated dependencies [f90b8fb]
3486
+ - Updated dependencies [91783c4]
3487
+ - Updated dependencies [982885d]
3488
+ - Updated dependencies [dba7d84]
3489
+ - Updated dependencies [ca39427]
3490
+ - Updated dependencies [bd09957]
3491
+ - Updated dependencies [5a07e67]
3492
+ - Updated dependencies [2d36552]
3493
+ - Updated dependencies [45d8288]
3494
+ - Updated dependencies [b2437a7]
3495
+ - Updated dependencies [f157423]
3496
+ - Updated dependencies [7a90afd]
3497
+ - Updated dependencies [eddc1dd]
3498
+ - Updated dependencies [490f482]
3499
+ - Updated dependencies [27308c5]
3500
+ - Updated dependencies [8689166]
3501
+ - Updated dependencies [c9327c9]
3502
+ - Updated dependencies [920165d]
3503
+ - Updated dependencies [9101be5]
3504
+ - Updated dependencies [f53a8d0]
3505
+ - Updated dependencies [30266cf]
3506
+ - Updated dependencies [968dc1e]
3507
+ - Updated dependencies [57f9b07]
3508
+ - Updated dependencies [3c73d99]
3509
+ - Updated dependencies [d91aed9]
3510
+ - Updated dependencies [ed71d9e]
3511
+ - Updated dependencies [7776fc2]
3512
+ - Updated dependencies [e76634c]
3513
+ - Updated dependencies [c86185e]
3514
+ - Updated dependencies [fb96ecb]
3515
+ - Updated dependencies [1170ed1]
3516
+ - Updated dependencies [92814db]
3517
+ - Updated dependencies [4d73b07]
3518
+ - @object-ui/plugin-detail@17.7.0
3519
+ - @object-ui/react@17.7.0
3520
+ - @object-ui/core@17.7.0
3521
+ - @object-ui/types@17.7.0
3522
+ - @object-ui/i18n@17.7.0
3523
+ - @object-ui/components@17.7.0
3524
+ - @object-ui/fields@17.7.0
3525
+ - @object-ui/permissions@17.7.0
3526
+
3
3527
  ## 17.6.0
4
3528
 
5
3529
  ### Patch Changes