@object-ui/cli 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,2510 @@
1
1
  # @object-ui/cli
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
+ - c4c506b: **Clause-②: yes (narrowing)**
22
+
23
+ One declaration of the per-type NODE SLOTS — the keys other than `children` through which a renderer hands authored nodes back to `SchemaRenderer` — and three readers that walk it instead of stopping at `children` (objectui#11170, the follow-up PR #11126's Acceptance notes filed).
24
+
25
+ New on `@object-ui/types`, beside `BaseSchema.children`: `NODE_SLOT_DECLARATIONS` (one row per renderer, under every registry spelling that resolves to it), `nodeSlotsFor(type)`, `nodeSlotPathSegments(path)` and `nodeSlotValues(node, path)`, with the types `NodeSlotDeclaration`, `NodeSlotRow`, `NodeSlotSegment` and `NodeSlotValue`. A position is spelled as a key path — `trigger`, `items[].content`, `regions[].components`, `items[]`, `report.sections[].content` — and the value at its end is one node or a list of nodes. The `page:*` rows are `@objectstack/spec`'s `pageComponentSlotPositions()` placed on the type whose renderer reads each position, pinned against that export in both directions; every other row is objectui's own, pinned against the live renderer. `body` stays retired as the generic child-list key (objectui#6771): it appears only on the four `page:*` types whose renderer still paints it for stored documents, marked `retired`.
26
+
27
+ Accept sets that narrow, each reader FROM → TO:
28
+
29
+ - `@object-ui/cli` — `objectui check`'s unevaluated-expression refusal (`findUnbindableTextExpressions`). FROM: the document root and every node its `children` hold. TO: those, and every node under a slot its type declares — so a `${…}` on `title` / `label` / `value` / `description` of a node under a dialog's `content`, a tab item's `content`, a page's `regions[].components`, a carousel item, a detail view's `tabs[].content` is now refused with the slot path (`items → 0 → content → value`). The false-refusal rows of PR #11126's ablation 2 stay green: a form's `fields[]`, a grid's `columns[]` and `{ "type": "multiple" }` are not slots. Measured over this repository's own JSON corpus and docs fences: no new finding.
30
+ - `@object-ui/core` — `validateSchema`. FROM: `validateChildren` recursed through `children` only. TO: it also recurses through the declared slots, so an invalid node under one (a retired `crud` spelling under `dialog.content`, an `INVALID_SCHEMA` member) is reported with its own path, spelled as `schema.items[0].content`. Measured over the same corpus: no new finding.
31
+ - `@object-ui/sdui-parser` — `validateTree`. FROM: the walk descended `children` alone, and a manifest entry carried no slot. TO: `ManifestComponent` gains `slots?: readonly string[]`, `manifestFromConfigs` gains `opts.slotsFor` (hand it `nodeSlotsFor`) and projects each entry's non-retired positions, and `validateTree` descends them — an unknown component, an unknown or mis-typed prop or an illegal enum under a slot now draws its diagnostic. A manifest built without the option serialises byte-identically and keeps the `children`-only reach. The `RETIRED_CHILD_LIST_KEY` refusals are unchanged.
32
+ - `@object-ui/components` — the `kind:'html'` page's compile manifest (`getJsxManifest`) is built with `slotsFor`, so an html-tier page whose slot-held node fails validation now fails to compile the way one under `children` does. Narrowing: a page that compiled with an unknown tag under a `dialog`'s `content` no longer does.
33
+
34
+ Docs: `content/docs/utilities/cli.mdx`'s "Component nodes only" rule, the gate's own docblock, `validateChildren`'s comment and the parser's header now say the walk follows `children` and the declared slots; the declaration's header is where the slot list is explained.
35
+ - 45d5853: New SDUI widget `cloud:workspace-timezone-notice`: one line on the Cloud welcome page naming the timezone a workspace was seeded with at creation (objectui#11930, the objectui half of objectstack-ai/cloud#2676).
36
+
37
+ **Clause-②: yes** — four published surfaces widen, and nothing that parsed or rendered before changes:
38
+
39
+ - the accept set of `AnyComponentSchema`, and so of `safeValidateSchema` and `objectui validate`, widens by one `type` literal, `cloud:workspace-timezone-notice`. `@object-ui/types/zod` exports one new schema, `CloudWorkspaceTimezoneNoticeSchema`, and `@object-ui/types` exports its TypeScript twin of the same name, a member of `AnySchema`;
40
+ - `@object-ui/i18n` adds one key, `cloudWorkspaceTimezoneNotice.seeded`, to all ten locale packs;
41
+ - `@object-ui/cli`: `objectui check` knows `cloud:workspace-timezone-notice` as a registered type;
42
+ - `@object-ui/app-shell` registers the widget, and its `sideEffects` array names the new module in its source and published spellings.
43
+
44
+ **Why.** The welcome page is static metadata, and nothing in a page's expression scope carries a per-organization value, so the page could not say which timezone the workspace was created with. The seed is available only from the org-scoped `GET /cloud/environment-entitlements` summary, as the additive `workspaceTimezoneSeed` string.
45
+
46
+ **What changed, in observable terms.**
47
+
48
+ - A page places the node with no props: `{ "type": "cloud:workspace-timezone-notice" }`. The widget reads the summary through the hook the environment list already uses, and when the summary carries `workspaceTimezoneSeed` it renders one muted line naming that zone, verbatim. In English: "The environment timezone was set to Asia/Shanghai from your browser when the environment was created. You can change it in Settings → Localization."
49
+ - It renders nothing when the summary carries no seed (workspaces created before the seed existed, and control planes that do not send it yet), while the summary loads, when the request fails or rejects, and when the body is not the `{ success, data }` envelope. A failed request does not throw.
50
+ - The line is text only: no link and no dismissal state.
51
+ - The node's `className` and `responsiveStyles` reach the line.
52
+ - The widget is registered under one key, `cloud:workspace-timezone-notice`. There is no bare `workspace-timezone-notice` fallback and no `app-shell:`-prefixed twin.
53
+ - `CloudWorkspaceTimezoneNoticeSchema` takes no prop: `properties` is optional and may only be `{}`, so any key in the bag, the zone included, is refused at `properties`. `body` and `children` are refused by name, because the widget reads neither.
54
+ - c5406c2: Depend on the `@objectstack/*` 18 prerelease line (objectui#12030).
55
+
56
+ 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).
57
+
58
+ **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.
59
+
60
+ **objectui's own surface moves with it:**
61
+
62
+ - `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`.
63
+ - The `CapabilityMultiSelectField` widget's curated capability set (`@object-ui/fields`) follows spec 18: `manage_mailboxes` in, `manage_org_presentation` out.
64
+ - `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.
65
+
66
+ **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.
67
+ - 82e5f53: `record:details`, `record:highlights` and `record:quick_actions` honour the per-element `dataSource` binding the spec already declares on every page component (objectui#12294). A product `app` page can now compose a record's surfaces from these blocks, with no record page around them:
68
+
69
+ ```json
70
+ {
71
+ "type": "record:highlights",
72
+ "properties": { "fields": ["name", "environment_type"] },
73
+ "dataSource": {
74
+ "object": "sys_environment",
75
+ "filter": [{ "field": "environment_type", "operator": "equals", "value": "production" }],
76
+ "limit": 1
77
+ }
78
+ }
79
+ ```
80
+
81
+ - **One record per block.** A record block shows the FIRST row of the bound set by the binding's `sort`, read as one row and under the caller's own identity; the server decides what the caller may read, exactly as on any other read. When no row matches, each block draws what it draws for a record that is not there: `record:details` its "record not found" state, `record:highlights` nothing, `record:quick_actions` its empty bar. A read the server refuses draws the same, so a record the caller may not read looks absent. A read that fails for any other reason is reported in the block's place, with the family's data-source error panel.
82
+ - **`record:quick_actions` runs against the bound row.** The object's declared actions (`actionNames`) run with the bound row's id.
83
+ - **The binding resolves as on every bound block.** A named `view`, the binding's `filter` (with `{current_user_id}`-style tokens), and its `sort` mean what they mean on a list block, and an unresolvable view or a refused filter draws the same configuration panel. Reference fields come back expanded, limited to the fields the caller may read, as on the record page.
84
+ - **The bound record stays fresh.** It re-reads in place whenever a write to its object is announced — by the data source's mutation events or on the data-invalidation bus — so a save or an action elsewhere on the page refreshes it.
85
+ - **The record page is unchanged.** A block with no `dataSource` reads the record page's record exactly as before. A bound block placed on a record page shows its bound record instead, as the spec says the binding does, and is kept out of that page's inline-edit session and highlight-field registry: it is read-only there, and it does not hide fields from the page record's details.
86
+ - **The registrations declare the key.** The three blocks publish the injected `dataSource` input, so the page authoring diagnostics no longer report it as an unknown prop.
87
+ - **`@object-ui/types`: the strict authoring face accepts the binding on the three blocks.** Each arm declares `dataSource` as the spec's `ElementDataSourceSchema`, by reference, as `record:line_items` does; the TypeScript authoring face follows. `objectui validate` refused it as an undeclared key before.
88
+ - **`@object-ui/cli`: `objectui validate` warns on a record block whose binding has no `limit: 1`.** The document still validates; the warning names the block's path and asks the author to say which record the block shows. `record:related_list` is not warned about: its binding is the binding of its child rows.
89
+
90
+ `record:related_list` is unchanged: its `dataSource` still binds the rows it lists.
91
+ - d81e460: `record:related_list` reads its parent record from `parentDataSource` (objectui#12294, ruling B on objectui#12296). The key is a member of the spec's `record:related_list` row and takes the object binding `dataSource` takes, so a product `app` page can list a record's children with no record page around the block:
92
+
93
+ ```json
94
+ {
95
+ "type": "record:related_list",
96
+ "properties": {
97
+ "objectName": "sys_member",
98
+ "relationshipField": "environment_id",
99
+ "parentDataSource": {
100
+ "object": "sys_environment",
101
+ "filter": [{ "field": "environment_type", "operator": "equals", "value": "production" }],
102
+ "limit": 1
103
+ }
104
+ }
105
+ }
106
+ ```
107
+
108
+ - **The parent is read the way the other record blocks read their record.** The FIRST row of the binding by its `sort` is the parent, read as one row under the caller's own identity and re-read when a write to its object is announced. The list draws that record's children through `relationshipField`, and `relationshipValueField` is read on that row.
109
+ - **No row is said out loud.** When no row matches, or the server refuses the read, the block draws a notice naming the object in its place, and no list: an empty list would read as "this record has no related records". A read that fails any other way draws the data-source error panel.
110
+ - **Without the key, the parent is the record page's record, as before**, and a related list rendered on a record page draws the same markup it drew. With the key, the binding wins over the page record.
111
+ - **`dataSource` keeps its meaning.** On this block it binds the CHILD rows the list draws, and it is never read as the parent.
112
+ - **Authoring.** `RecordRelatedListComponentProps` declares `parentDataSource` as the spec's `ElementDataSource`, by reference, and the registration publishes it as an input, so the html tier no longer reports it as an unknown prop. `objectui validate` already accepted it in `properties`, where the spec row puts it, and refuses it written on the node; it now also warns on a parent binding without `limit: 1`, as it warns on the one-record blocks' bindings.
113
+ - ff9df88: Depend on `@objectstack/*` `18.0.0-next.1` (objectui#12370).
114
+
115
+ 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.
116
+
117
+ **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`:
118
+
119
+ - `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.
120
+ - `onSuccess` beside `operation: 'update'`, and an `onSuccess` block carrying a key outside `{ navigate, openIn }`.
121
+ - `actionType: 'navigation'` on a row (and `type: 'navigation'` on a container member): write `'url'`.
122
+ - A `url` executor's `target` that is not openable, judged on the executor the runner runs, including a row whose `name` selects it.
123
+ - A view `data` binding with `provider: 'api'`: bind the object or static rows; an API call is the page element's binding.
124
+ - 35244b6: The separate Installed Apps view is retired (objectui#12733, ruling B on objectstack#23892). Setup → Packages filtered to Marketplace is the one list of what is installed (objectui#12675), and objectstack#23933 points the install-local plugin's Installed Apps entry straight at it. This is breaking for a host that used one of the retired names; it is marked `minor` under this repository's version policy.
125
+
126
+ - **Export `MarketplaceInstalledPage`.** FROM: `@object-ui/app-shell` exported it, and it redirected to Packages filtered to Marketplace. TO: there is no such export, and importing it fails to compile.
127
+ - **SDUI widget `marketplace:installed-list`** (also registered as `app-shell:marketplace:installed-list`). FROM: registered, and it redirected to the same URL. TO: not registered. A page that still names it draws the unknown-component panel, and `objectui check` no longer counts it among the known component types.
128
+ - **Routes `system/marketplace/installed`**, in the no-active-app branch and the app branch. FROM: both redirected to the same URL. TO: neither exists. The path now matches `system/marketplace/:packageId`, so an old bookmark opens the package page for a package id `installed`, which the catalog does not have.
129
+ - **The Marketplace page's "Installed (N)" button** opens `/apps/APP/component/developer/packages?source=marketplace` directly, with no redirect hop. APP is the app the page was opened under, and `setup` when there is none.
130
+
131
+ The widget's module also leaves the `sideEffects` array of `@object-ui/app-shell`.
132
+
133
+ Fix for each retired name: link to `/apps/APP/component/developer/packages?source=marketplace` (Setup → Packages, Source = Marketplace) instead.
134
+
135
+ Clause-②: no (narrowing)
136
+ - 30083da: Two Cloud SDUI widgets are retired: `cloud:onboarding-next`, the Welcome page's next-step block, and `cloud:plan-status`, the pricing page's current-plan marker (objectui#12954). The Cloud control plane was their one consumer, and objectstack-ai/cloud#3010 replaced both: the home's next step is declared `element:button` nodes over `GET /api/v1/cloud/home`, and the pricing page marks the current plan with a `visibleWhen` on the same summary. At retirement, hotcrm `main` (`3b05ae7`) and objectstack `main` (`0b44840dfd`) registered and authored neither type. They are retired at once, with no deprecation alias. This is breaking for a page or host that still names one of them; it is marked `minor` under this repository's version policy.
137
+
138
+ - **SDUI widget `cloud:onboarding-next`**, also registered as `app-shell:cloud:onboarding-next`. FROM: `@object-ui/app-shell` registered both keys. TO: neither is registered. A page that still names one draws the unknown-component panel, and `objectui check` no longer counts either key among the known component types.
139
+ - **SDUI widget `cloud:plan-status`**. FROM: `@object-ui/app-shell` registered it. TO: not registered, with the same two consequences.
140
+ - **Schema `CloudPlanStatusSchema`** in `@object-ui/types`: the TypeScript interface from the package entry, and the zod arm from `@object-ui/types/zod`, which was also a member of `AnyComponentSchema`. FROM: exported, and a `cloud:plan-status` node validated against the arm. TO: there is no such export, so importing it fails to compile. `AnyComponentSchema` keeps a refusal arm for the literal, which is not exported, so `objectui validate` refuses a `cloud:plan-status` node BY NAME at `type`, and the message names the remedy: a `visibleWhen` on the page's summary. `CloudWorkspaceTimezoneNoticeSchema` stays.
141
+ - **Locale keys `cloudOnboarding.*`** (`hintCreate`, `hintReady`, `createEnvironment`, `openWorkspace`, `manageEnvironments`) **and `cloudPlanStatus.current`** leave all ten built-in packs of `@object-ui/i18n`.
142
+
143
+ The two widget modules also leave the `sideEffects` array of `@object-ui/app-shell`. `useEnvironmentEntitlements` stays: the environment list and `cloud:workspace-timezone-notice` still read it.
144
+
145
+ Fix for a page that still names either widget: compose it from generic blocks, as objectstack-ai/cloud#3010 did — declared `element:button` nodes over the home summary in place of `cloud:onboarding-next`, and a `visibleWhen` on the same summary in place of `cloud:plan-status`.
146
+
147
+ Clause-②: no (narrowing)
148
+ - e4c0b54: `objectui validate` and `objectui check` judge a document through the strict authoring face (objectui#5250)
149
+
150
+ Both commands parsed an authored document with `safeValidateSchema`, whose node schemas are
151
+ `.passthrough()`: a key no schema declares was kept and never judged, so a misspelled or invented
152
+ key read `✓ Schema is valid!`. They now parse through `StrictAnyComponentSchema`, the strict twin
153
+ of the same declarations (objectui#8345), under the objectui#5250 ruling: the authoring verdict is
154
+ strict, while the rendering face keeps its passthrough.
155
+
156
+ **Breaking for documents that carry an undeclared key.** `objectui validate` now exits 1 on such a
157
+ document, on the root node and on every nested node, and names each key, the path of the object
158
+ carrying it, and the fix:
159
+
160
+ Undeclared key "validation" at (root) (type "input"): no schema declares it there. Remove it, or check its spelling against the keys declared at that position.
161
+
162
+ A nested child's key is named at the child's path, and so is one inside a union the node fits
163
+ more than one arm of (a dashboard widget), where the issue list reports only an `Invalid input`
164
+ that names no key. For an undeclared key `objectui check` stays advisory — it does not change the
165
+ exit code, which is non-zero on unreadable JSON and on a `${…}` refused on a text key its node never
166
+ evaluates (objectui#4795) — but such a file is no longer counted as validated: it is listed by name
167
+ among the files that did not validate, with the same line under it. Its `${…}` expressions are still
168
+ judged, so a listed file can fail the run for an expression. There is no flag to opt out.
169
+
170
+ Where another entry in this release says `objectui validate` or `objectui check` runs
171
+ `safeValidateSchema`, the tolerant face, this entry supersedes it: both commands run the strict face.
172
+
173
+ Declared `minor` rather than `major` because this release group follows the `@objectstack` major;
174
+ the breaking semantics are stated here instead.
175
+ - 78b07f4: The object-page special cases for the retired permission-set catalog object are removed (objectui#7611, after objectstack's ADR-0131 stage 8 retired `sys_position`, `sys_permission_set`, `sys_position_permission_set` and `sys_capability`). A permission set is edited on its Setup metadata page, which reads the registry; none of the removed code ran anywhere else.
176
+
177
+ **Breaking (narrowing; scored `minor` per the fixed group's version policy).** Each removal below shrinks a published face:
178
+
179
+ - **`@object-ui/core`: `recordDelete.confirmText`.** FROM `recordDelete.confirmText({ objectName, t }, record)` TO `recordDelete.confirmText({ t })`. A package-owned `sys_permission_set` row no longer gets the reset question or the "reset" toast: every record gets the delete question and the delete toast. Fix: drop `objectName` and the second argument.
180
+ - **`@object-ui/i18n`: pack keys.** FROM `perm.facet.*` (`none`, `more`, `objects`, `fields`, `rls`, `tabs` with their plural slots, `adminScope`, `designInStudio`, `designInStudioHint`) and `objectActions.resetPackageSetConfirm` / `objectActions.resetPackageSetSuccess` in all ten packs TO absent. Fix: a consumer that still asks for one keeps its own copy (inline `defaultValue` or its own bundle).
181
+ - **`@object-ui/plugin-detail`: the `field:permission-facet-link` registry key.** FROM a registered field widget (the read-only facet summary with a "Design in Studio" link, also special-cased in the detail section and inline edit) TO unregistered. A field still carrying `widget: 'permission-facet-link'` renders with its declared type, like any unregistered widget. Fix: drop the `widget` hint, or register an own widget under that key.
182
+ - **`@object-ui/cli`: `objectui check`'s known schema types.** FROM `field:permission-facet-link` known TO unknown, so `objectui check` reports a node of that type. Fix: as above.
183
+
184
+ **Behaviour changes, not narrowings:**
185
+
186
+ - **`@object-ui/data-objectstack`:** `getObjectSchema` no longer stamps `widget: 'permission-facet-link'` onto the six `sys_permission_set` facet fields (that object is no longer served).
187
+ - **`@object-ui/app-shell`:** the `sys_permission_set` record page no longer appends the assigned-users panel. The panel itself, `AssignedUsersSection`, stays on the permission-set metadata page.
188
+ - **`@object-ui/app-shell`: a permission set created from the Setup catalog is created live.** "New" on the permission-set page used to save a draft, while the set's editor edits the live set and reads no draft: the editor opened an empty set without the label, its Save wrote the grants live, and the draft stayed pending, so publishing it from Home replaced the grants with the empty create body. Outside a package binding the create now writes live (with the same first-write pin); under `?package=` it stays a package draft.
189
+
190
+ **Widenings:**
191
+
192
+ - **`@object-ui/core`:** the data source `recordDelete.run` is injected with needs only `delete` (it no longer calls `findOne`).
193
+ - **`@object-ui/app-shell`:** the metadata-resource registry entry gains an optional `createLive`, which a type sets when its edit page writes the live item.
194
+
195
+ Internal, not reachable from a published entry: the `PermissionFacetLink` component (never exported from `@object-ui/plugin-detail`), `RecordPermissionAssignmentsRenderer` (never exported from `@object-ui/app-shell`), and `ObjectStackAdapter`'s private `applyFieldWidgetOverrides`.
196
+
197
+ ### Patch Changes
198
+
199
+ - c4dd707: feat(app-shell): five generic product-page blocks — `hero`, `stat`, `usage-bar`, `checklist`, `tile-grid` (objectui#12197)
200
+
201
+ Clause-②: yes
202
+
203
+ `@object-ui/app-shell` registers five product-neutral SDUI blocks for pages a product composes as metadata, each with declared `inputs` that state their defaults, and each accepting the spec's API binding as `dataSource`:
204
+
205
+ - `hero` — `title`, `subtitle?`, `meta?` (drawn with a copy-to-clipboard button), `status?`, `statusTone?` (`neutral` when omitted), `primary?` / `secondary?` (`element:button` or `action:button` nodes).
206
+ - `stat` — `label`, `value` (a number is formatted in the viewer's locale), `hint?`.
207
+ - `usage-bar` — `label`, `used`, `limit?`, `unit?`; the bar's width is `used / limit` clamped to 0–100, and an absent or `0` limit is unlimited: the amount used and no bar.
208
+ - `checklist` — `items: [{ label, done, action? }]`, `collapsedWhenDone?` (`false` when omitted; when set, the block draws nothing once every step is done).
209
+ - `tile-grid` — `items: [{ label, href, icon?, caption? }]` or a `${…}` hole naming such a list, `addTile?: { label, href }`; the console home's launcher tile, now shared with the home's apps strip, which draws as before.
210
+
211
+ `@object-ui/types` gains each block's strict arm in `AnyComponentSchema` (`HeroBlockSchema`, `StatBlockSchema`, `UsageBarBlockSchema`, `ChecklistBlockSchema`, `ChecklistBlockItemSchema`, `TileGridBlockSchema`, `TileGridBlockItemSchema`, `TileGridBlockAddTileSchema`, the union `ProductBlockComponentSchema`) and their TypeScript twins, so `objectui validate` accepts the five types. A value the bound answer may supply also accepts one whole-string `${…}` hole. The `dataSource` descriptions on the object-bound arms now name the object binding as one of `PageComponentSchema.dataSource`'s two shapes. `@object-ui/cli`'s known component types gain the five names. The console's preview gallery draws every block at `?only=product_blocks`.
212
+ - 52d6194: The page block `record:approval_decision` renders (objectui#12342). `@objectstack/spec` 18 declares it, and until now a page naming it passed the spec and drew nothing, because no registration mounted the decision panel.
213
+
214
+ - **Registered (`@object-ui/app-shell`).** The package entry registers `ApprovalDecisionRenderer` as `record:approval_decision` (no bare twin), from the new side-effect leaf `views/record-approval-decision-renderer.tsx`, which joins the package's `sideEffects` array. On an approval request's record page the node draws the request's decision progress above its declared decision actions; off a request page it draws the localized notice it already drew. The renderer is still not exported from the package entry: a page reaches it by type.
215
+ - **Armed (`@object-ui/types`).** `RecordApprovalDecisionBlockSchema` (zod, from `@object-ui/types/zod`) and its TypeScript twin of the same name (from `@object-ui/types`) are new, and `AnyComponentSchema` gains the arm, so `safeValidateSchema` and the strict face accept a `record:approval_decision` node. Its `properties` bag is the spec's empty strict row, restated because the spec exports the row under no name: the only bag it accepts is `{}`, and a node-level `children` or `body` is refused by name.
216
+ - **`objectui check` and `objectui validate` (`@object-ui/cli`).** The generated list of registered types gains `record:approval_decision`, and `objectui validate` no longer refuses the type at `type`.
217
+
218
+ Studio's block palette still does not offer the block; its exclusion reason now says it renders.
219
+ - 1f1c4b5: The `objectui doctor` check-result types are declared as `DoctorDiagnostic` and `DoctorDiagnosticLevel` instead of `Diagnostic` and `DiagnosticLevel` (objectui#6349, batch 6), because `@object-ui/sdui-parser` publishes `Diagnostic` for a parser finding, a different shape. Both types are internal to the command: this package's entry exports `serve` and `init` only, so no import changes.
220
+
221
+ No runtime behaviour changes; `objectui doctor` prints the same output.
222
+ - 088e0f7: A record-form field can name one item of a metadata registry by its machine name: a `text` field that declares `widget: 'position-ref'` lists the position registry, and one that declares `widget: 'permission-ref'` lists the permission-set registry. It stores the name only (objectui#7611, ruling B2 on objectstack#22865). This is the mechanism the metadata forms' `ref-multi:permission` picker brought in (objectui#12126), now reachable from an ObjectQL object field. A grant table's name field (`sys_user_position`'s position, `sys_user_permission_set.permission_set`) can now offer the declared items instead of a box for a typed name.
223
+
224
+ - **The widget (`@object-ui/fields`).** `field:position-ref` and `field:permission-ref`, one key per registry type, with the type in the key, as `object-ref` carries `object`. Like every `widget` value, the name is looked up as `field:<widget>`. Each item reads as its label beside its name, and a pick writes the name: no label, no id. A stored name the loaded registry does not list stays on screen as its own option, flagged *not found*. The four catalog arms follow the metadata forms' `ref:dataset` / `ref-multi:<type>` pickers. With no data source that can list a registry, the field is a text box for the typed name. While the list loads, the stored name sits in a disabled box. When the load fails, a notice names the failure and its cause, and the text box stays enabled. A loaded but empty registry gives the same text box. Neither key is a declarable field type: both are widget hints, like `object-ref`.
225
+ - **The catalog (`@object-ui/types`, `@object-ui/data-objectstack`).** `DataSource` gains an optional `listMetadataItems(type)`, answering `{ name, label }` headers for one registry type. An empty array is authoritative ("this registry has no item of this type"), so a failed load must reject, never resolve `[]`. `ObjectStackAdapter` implements it over `GET /api/v1/meta/:type` (the client's `meta.getItems`). It rejects with the transport's error, and refuses an answer that carries no `items` list. It is uncached, so an item authored in Studio shows on the next form.
226
+ - **Locale keys (`@object-ui/i18n`).** `fields.registryRef.loadFailed` and `fields.registryRef.notFound`, in all ten packs.
227
+ - **Wiring.** The form renderer threads `dataSource` to both keys, as it does for the other widget-hint pickers (`@object-ui/components`). The inline-grid exclusion set and the action-param value-shape table list both keys as widget-hint-only (`@object-ui/fields`, `@object-ui/app-shell`). The CLI's generated `KNOWN_SCHEMA_TYPES` gains `field:position-ref` and `field:permission-ref` (`@object-ui/cli`). A comment in `@object-ui/core` stops counting the picker names.
228
+
229
+ **Clause-②: yes (widening)**: one optional `DataSource` member, two registered `field:` keys (the `RegisteredFieldWidgetType` union and `FORM_FIELD_TYPES` gain two members), and two locale keys. Nothing narrows: a field without the hint renders exactly as before.
230
+ - Updated dependencies [18d7b48]
231
+ - Updated dependencies [172acc3]
232
+ - Updated dependencies [f0496bd]
233
+ - Updated dependencies [c4c506b]
234
+ - Updated dependencies [9db9ff3]
235
+ - Updated dependencies [c096f03]
236
+ - Updated dependencies [92f4e2b]
237
+ - Updated dependencies [b10c68e]
238
+ - Updated dependencies [bdc9049]
239
+ - Updated dependencies [2e818d0]
240
+ - Updated dependencies [fd060f0]
241
+ - Updated dependencies [8b14aec]
242
+ - Updated dependencies [2abec3a]
243
+ - Updated dependencies [9dfaca6]
244
+ - Updated dependencies [c000398]
245
+ - Updated dependencies [73b5d77]
246
+ - Updated dependencies [e6dcd85]
247
+ - Updated dependencies [96fcf30]
248
+ - Updated dependencies [7a2c60b]
249
+ - Updated dependencies [9fc68aa]
250
+ - Updated dependencies [89cc738]
251
+ - Updated dependencies [c0862c1]
252
+ - Updated dependencies [c0862c1]
253
+ - Updated dependencies [c0862c1]
254
+ - Updated dependencies [c0862c1]
255
+ - Updated dependencies [4c0de52]
256
+ - Updated dependencies [a80fef7]
257
+ - Updated dependencies [e06365c]
258
+ - Updated dependencies [1e1f09e]
259
+ - Updated dependencies [455c646]
260
+ - Updated dependencies [f34e877]
261
+ - Updated dependencies [9844bbf]
262
+ - Updated dependencies [cef0eee]
263
+ - Updated dependencies [7241a81]
264
+ - Updated dependencies [74add0c]
265
+ - Updated dependencies [aaba865]
266
+ - Updated dependencies [45d5853]
267
+ - Updated dependencies [4f4fc03]
268
+ - Updated dependencies [2312bd9]
269
+ - Updated dependencies [c5406c2]
270
+ - Updated dependencies [2a48bd4]
271
+ - Updated dependencies [c7b30bd]
272
+ - Updated dependencies [69bca0a]
273
+ - Updated dependencies [ce991bd]
274
+ - Updated dependencies [b7cd5c8]
275
+ - Updated dependencies [5330038]
276
+ - Updated dependencies [c9fc10b]
277
+ - Updated dependencies [dc6d28e]
278
+ - Updated dependencies [c0c2f79]
279
+ - Updated dependencies [0665c3b]
280
+ - Updated dependencies [d2500d8]
281
+ - Updated dependencies [e723f58]
282
+ - Updated dependencies [f3d5408]
283
+ - Updated dependencies [b231607]
284
+ - Updated dependencies [466a219]
285
+ - Updated dependencies [6fb281d]
286
+ - Updated dependencies [c08c933]
287
+ - Updated dependencies [92f979d]
288
+ - Updated dependencies [c4dd707]
289
+ - Updated dependencies [c4dd707]
290
+ - Updated dependencies [923504f]
291
+ - Updated dependencies [5c2982a]
292
+ - Updated dependencies [97e7d4e]
293
+ - Updated dependencies [10aba37]
294
+ - Updated dependencies [5d3f437]
295
+ - Updated dependencies [7af0ab3]
296
+ - Updated dependencies [b434f5f]
297
+ - Updated dependencies [fd4872f]
298
+ - Updated dependencies [f0532d8]
299
+ - Updated dependencies [3092aca]
300
+ - Updated dependencies [82e5f53]
301
+ - Updated dependencies [d81e460]
302
+ - Updated dependencies [8106db1]
303
+ - Updated dependencies [093d55b]
304
+ - Updated dependencies [a8051d6]
305
+ - Updated dependencies [72594f2]
306
+ - Updated dependencies [524136e]
307
+ - Updated dependencies [6f3299f]
308
+ - Updated dependencies [f2b17c6]
309
+ - Updated dependencies [52d6194]
310
+ - Updated dependencies [23bf859]
311
+ - Updated dependencies [1c72d77]
312
+ - Updated dependencies [2b4d3f1]
313
+ - Updated dependencies [d75f212]
314
+ - Updated dependencies [ff9df88]
315
+ - Updated dependencies [70e843f]
316
+ - Updated dependencies [a2225f9]
317
+ - Updated dependencies [5c4deb5]
318
+ - Updated dependencies [c950345]
319
+ - Updated dependencies [21f9577]
320
+ - Updated dependencies [044f231]
321
+ - Updated dependencies [f8267df]
322
+ - Updated dependencies [3eb3ec1]
323
+ - Updated dependencies [1ffd6a2]
324
+ - Updated dependencies [5f8ecf6]
325
+ - Updated dependencies [726d8c9]
326
+ - Updated dependencies [ef71a09]
327
+ - Updated dependencies [619e3f7]
328
+ - Updated dependencies [c9e6742]
329
+ - Updated dependencies [f62b6ff]
330
+ - Updated dependencies [608033b]
331
+ - Updated dependencies [611566b]
332
+ - Updated dependencies [d66d7e8]
333
+ - Updated dependencies [15d8ca6]
334
+ - Updated dependencies [378896d]
335
+ - Updated dependencies [71243db]
336
+ - Updated dependencies [a8add5c]
337
+ - Updated dependencies [33ee9de]
338
+ - Updated dependencies [4839f5c]
339
+ - Updated dependencies [c7462e7]
340
+ - Updated dependencies [e058d76]
341
+ - Updated dependencies [c999d4c]
342
+ - Updated dependencies [8df2608]
343
+ - Updated dependencies [5483297]
344
+ - Updated dependencies [ed43c79]
345
+ - Updated dependencies [655e897]
346
+ - Updated dependencies [655e897]
347
+ - Updated dependencies [69a408f]
348
+ - Updated dependencies [d2b21a1]
349
+ - Updated dependencies [5ff64ef]
350
+ - Updated dependencies [26323c4]
351
+ - Updated dependencies [9753811]
352
+ - Updated dependencies [bc281f4]
353
+ - Updated dependencies [d637be3]
354
+ - Updated dependencies [2cfdc99]
355
+ - Updated dependencies [1e6d83b]
356
+ - Updated dependencies [c219165]
357
+ - Updated dependencies [a7ae252]
358
+ - Updated dependencies [30083da]
359
+ - Updated dependencies [8aa8e3e]
360
+ - Updated dependencies [024b7b6]
361
+ - Updated dependencies [909c64e]
362
+ - Updated dependencies [9e7e1a5]
363
+ - Updated dependencies [d0b9648]
364
+ - Updated dependencies [46dbf32]
365
+ - Updated dependencies [a928aaa]
366
+ - Updated dependencies [61ed5ad]
367
+ - Updated dependencies [1b94d50]
368
+ - Updated dependencies [988aa9f]
369
+ - Updated dependencies [fb85637]
370
+ - Updated dependencies [df71568]
371
+ - Updated dependencies [d11174a]
372
+ - Updated dependencies [2d8a8b7]
373
+ - Updated dependencies [cbac9d7]
374
+ - Updated dependencies [4b92c5a]
375
+ - Updated dependencies [3650d94]
376
+ - Updated dependencies [8cd4db4]
377
+ - Updated dependencies [daeb77f]
378
+ - Updated dependencies [eb4552e]
379
+ - Updated dependencies [55e90fd]
380
+ - Updated dependencies [9b75509]
381
+ - Updated dependencies [b13ea3c]
382
+ - Updated dependencies [d7e9e9a]
383
+ - Updated dependencies [cf62edf]
384
+ - Updated dependencies [0253416]
385
+ - Updated dependencies [5d77c09]
386
+ - Updated dependencies [3fd8625]
387
+ - Updated dependencies [1473757]
388
+ - Updated dependencies [d73d987]
389
+ - Updated dependencies [12ff256]
390
+ - Updated dependencies [26b0bd2]
391
+ - Updated dependencies [26b0bd2]
392
+ - Updated dependencies [d328698]
393
+ - Updated dependencies [b4e0787]
394
+ - Updated dependencies [088e0f7]
395
+ - Updated dependencies [b403bb3]
396
+ - Updated dependencies [4016370]
397
+ - @object-ui/types@18.0.0
398
+ - @object-ui/components@18.0.0
399
+ - @object-ui/react@18.0.0
400
+
401
+ ## 17.7.0
402
+
403
+ ### Minor Changes
404
+
405
+ - 29b45f6: feat(core,components): the html tier registers and declares `code` — `<code>inline</code>` on a `kind:'html'` page renders its text instead of the `field:code` editor
406
+
407
+ `renderers/basic/html-elements.tsx` called `code` "registered elsewhere", but the
408
+ only bare `code` registration was the `field:code` widget's namespace fallback: a
409
+ code editor reading `value`, with no declared inputs and no child slot. The
410
+ console's html-tier compile whitelists `ComponentRegistry.getKnownTypes()`, so
411
+ `<code>inline</code>` on an html page compiled, resolved to the editor, and the
412
+ authored text was dropped — while `pre`, `strong` and `em` rendered their
413
+ children through the passthrough, and `span` through its own renderer. The
414
+ published manifest (objectui#10735) left `code` undeclared for the same reason,
415
+ so the objectstack gate refused the tag the renderer mis-drew.
416
+
417
+ **What moves for a consumer.**
418
+
419
+ - `@object-ui/components` — `code` joins the `TAGS` loop of `html-elements.tsx`:
420
+ registered `ui:code`, sanitised like its siblings, declaring `className` and the
421
+ `children` slot. An html author's `<code>` now renders a real `code` element with
422
+ its text.
423
+ - `@object-ui/fields` — **BREAKING (authoring): the bare `code` key no longer
424
+ resolves to the code-editor widget.** `code` joins `FIELD_TYPES_SKIP_FALLBACK`,
425
+ so the widget is registered `field:code` only. A node authored as bare
426
+ `{ "type": "code", "value": … }` now renders the html tier's `code` element (it
427
+ draws `children`, not `value`); in a registry without `@object-ui/components`
428
+ the bare key resolves to nothing. Migration: `{ "type": "code" }` becomes
429
+ `{ "type": "field:code" }`. Form fields of type `code` resolve through the
430
+ `field:` namespace and render the same editor as before. Released as `minor`
431
+ under objectui's version policy; a breaking change never declares `major`.
432
+ - `@object-ui/core` — `code` joins `HTML_TIER_INTRINSICS`, so `getPublicConfigs()`
433
+ projects it stamped `tier: 'html'` and the regenerated `sdui.manifest.json`
434
+ grows by one entry (the html tier declares 48 tags where objectui#10735
435
+ declared 47); `div` and `kbd` stay undeclared.
436
+ - `@object-ui/types` — `HtmlElementSchema` (zod and TS) names `code`, keeping the
437
+ JSON-surface declaration equal to the registration, as the objectui#8499 pin
438
+ requires — so `AnyComponentSchema` (and `objectui validate`) now accepts
439
+ `{ "type": "code" }`, which it refused before.
440
+ - `@object-ui/cli` — `packages/cli/src/utils/known-schema-types.ts` regenerates
441
+ from the registrations and gains `ui:code`, so `objectui validate` and
442
+ `objectui check` recognise it as a known schema type (the objectui#9533 and
443
+ objectui#6416 precedent).
444
+
445
+ The `kind:'react'` scope skips stamped entries, so no `Code` wrapper is injected
446
+ on react pages. The framework's tracked manifest regenerates at its next
447
+ `.objectui-sha` bump (objectstack#20112's port list); nothing there changes here.
448
+ - 37140f4: chore(cli)!: the generated known-types list drops the twelve node type keys objectui#10859 batch 8 phase 2b retired
449
+
450
+ **BREAKING (authoring):** `KNOWN_SCHEMA_TYPES` (regenerated from the registration calls) no longer lists `scatter-chart`, `dashboard-grid`, `form-analytics`, `import-wizard`, `shared-view-link`, `app-creation-wizard`, `branding-editor`, `dashboard-editor`, `navigation-designer` or `related-list`, nor their namespaced twins, and no longer lists the bare `metric` / `metric-card` (their `plugin-dashboard:` keys stay). `objectui check` now reports a root document of one of those types as an unknown type, and `objectui validate` keeps refusing it at `type`, as it already did.
451
+
452
+ Migration:
453
+
454
+ - `scatter-chart` → `chart` with `chartType: "scatter"`;
455
+ - `dashboard-grid` → `dashboard`;
456
+ - `related-list` → `record:related_list`;
457
+ - `metric` / `metric-card` as a standalone node → `plugin-dashboard:metric` / `plugin-dashboard:metric-card` (inside a dashboard, keep the widget spelling);
458
+ - `form-analytics`, `import-wizard`, `shared-view-link`, `app-creation-wizard`, `branding-editor`, `dashboard-editor`, `navigation-designer` → mount the exported React component directly.
459
+
460
+ The registered-types ratchet (`REFUSED_AT_TYPE`) falls from 36 to 24, and its namespaced twin from 389 to 379.
461
+
462
+ **Clause-②: yes**, released as `minor` with this banner.
463
+ - ad1785c: chore(cli)!: the generated known-types list drops the four node type keys objectui#10859 batch 8 phase 2c retired
464
+
465
+ **BREAKING (authoring):** `KNOWN_SCHEMA_TYPES` (regenerated from the registration calls) no longer lists `pie-chart`, `donut-chart`, `radar-chart` or `page-header`, nor their namespaced twins (`plugin-charts:pie-chart`, `plugin-charts:donut-chart`, `plugin-charts:radar-chart`, `layout:page-header`, `protocol-placeholder:page-header`). `objectui check` now reports a root document of one of those types as an unknown type, and `objectui validate` keeps refusing it at `type`, as it already did.
466
+
467
+ Migration:
468
+
469
+ - `pie-chart` / `donut-chart` / `radar-chart` → `chart` with `chartType: "pie"` / `"donut"` / `"radar"`;
470
+ - `page-header` → `page:header`, with `title` / `subtitle` / `actions` in `properties`.
471
+
472
+ The registered-types ratchet (`REFUSED_AT_TYPE`) falls from 24 to 20, and its namespaced twin from 379 to 374.
473
+
474
+ **Clause-②: yes**, released as `minor` with this banner.
475
+ - 1c84036: chore(cli)!: the generated known-types list drops the ten `sidebar-*` node type keys objectui#10859 batch 8 phase 2d retired
476
+
477
+ **BREAKING (authoring):** `KNOWN_SCHEMA_TYPES` (regenerated from the registration calls) no longer lists `sidebar-provider`, `sidebar-header`, `sidebar-content`, `sidebar-group`, `sidebar-menu`, `sidebar-menu-item`, `sidebar-menu-button`, `sidebar-footer`, `sidebar-inset` or `sidebar-trigger`, nor their `ui:` twins. `objectui check` now reports a root document of one of those types as an unknown type, and `objectui validate` keeps refusing it at `type`, as it already did.
478
+
479
+ Migration: author the `sidebar` node, which now mounts its own provider when its host has none, and put the parts' content in its `children`. `@object-ui/components`' changeset for this phase lists the move per spelling.
480
+
481
+ objectui#11441 retired its two layout keys first, so on that base this change takes the registered-types ratchet (`REFUSED_AT_TYPE`) from 18 to 8, and its namespaced twin from 372 to 362.
482
+
483
+ **Clause-②: yes**, released as `minor` with this banner.
484
+ - 990a2d6: chore(cli)!: the generated known-types list drops the thirty node type keys objectui#10859 batch 8 retired
485
+
486
+ **BREAKING (authoring):** `KNOWN_SCHEMA_TYPES` (`packages/cli/src/utils/known-schema-types.ts`, regenerated from the registration calls) no longer lists the 28 bare field-widget fallbacks retired in `@object-ui/fields`, nor `tree` / `view:tree` (`@object-ui/plugin-tree`) or `view` / `plugin-view:view` (`@object-ui/plugin-view`). `objectui check` now reports a root document of one of those types as an unknown type, and `objectui validate` keeps refusing it at `type`, as it already did.
487
+
488
+ Migration:
489
+
490
+ - a root `type` naming one of the 28 field types → write the field inside a form's `fields[]`; the widget is `field:<type>`;
491
+ - `tree` → `object-tree`;
492
+ - `view` → `object-view`.
493
+
494
+ The registered-types ratchet (`REFUSED_AT_TYPE`) falls from 66 to 36, and its namespaced twin from 391 to 389.
495
+
496
+ **Clause-②: yes**, released as `minor` with this banner.
497
+ - 9d9ed54: chore(cli)!: the generated known-types list drops `spec-report`, which objectui#11440 retired
498
+
499
+ **BREAKING (authoring):** `KNOWN_SCHEMA_TYPES` (regenerated from the registration calls) no longer lists `spec-report` or its twin `plugin-report:spec-report`. `objectui check` now reports a root document of either type as an unknown type, and `objectui validate` keeps refusing it at `type`, as it already did.
500
+
501
+ Migration: `{ "type": "spec-report", "report": { … } }` → `{ "type": "report", "report": { … } }`, with the same `report` member. `@object-ui/plugin-report`'s changeset for this change states what each face accepts.
502
+
503
+ This change takes the registered-types ratchet (`REFUSED_AT_TYPE`) from 1 to 0, and its namespaced twin from 362 to 361.
504
+
505
+ **Clause-②: yes**, released as `minor` with this banner.
506
+ - 9d1c0bf: chore(cli)!: the generated known-types list drops the two node type keys objectui#11441 retired
507
+
508
+ **BREAKING (authoring):** `KNOWN_SCHEMA_TYPES` (regenerated from the registration calls) no longer lists `navigation-renderer` or `responsive-grid`, nor their namespaced twins `layout:navigation-renderer` and `layout:responsive-grid`. `objectui check` now reports a root document of one of those types as an unknown type, and `objectui validate` keeps refusing it at `type`, as it already did.
509
+
510
+ Migration:
511
+
512
+ - `responsive-grid` → `grid`, with the same breakpoint `columns` object and `gap`;
513
+ - `navigation-renderer` → the app document's `navigation` items (`{ "type": "app", "name": N, "navigation": [...] }`), drawn by the shell.
514
+
515
+ The registered-types ratchet (`REFUSED_AT_TYPE`) falls from 20 to 18, and its namespaced twin from 374 to 372.
516
+
517
+ **Clause-②: yes**, released as `minor` with this banner.
518
+
519
+ ⚠️ **Dated note, 2026-10-02 — `grid` takes column counts 1 to 12, not any number — objectui#11491.** At this change "the same breakpoint `columns` object" carried any count; now each count in a `grid`'s `columns` is one of 1 to 12, the counts the `grid` renderer maps, and `objectui validate` refuses any other with that set named. Every count `ResponsiveGrid` drew (1, 2, 3, 4, 6 and 12) is one of them, so the migration above holds for every `responsive-grid` that drew its columns. `.changeset/11491-grid-columns-set.md` states what ships. The rest of this entry is kept as the reading of this change.
520
+
521
+ ⚠️ **Dated note, 2026-10-02 — `grid` takes one of ten `gap` steps, not any number — objectui#11474.** At this change "the same breakpoint `columns` object and `gap`" carried any `gap` number; now `grid`'s `gap` is one of 0, 1, 2, 3, 4, 5, 6, 8, 10 and 12, the steps the `grid` renderer maps, and `objectui validate` refuses any other with that set named. Every step `ResponsiveGrid`'s own class map drew (0 to 6 and 8) is one of them, so the migration above holds for every `responsive-grid` whose `gap` drew a class. `.changeset/11474-layout-spacing-sets.md` states what ships. The rest of this entry is kept as the reading of this change.
522
+ - 9de0b34: **BREAKING (`@object-ui/cli`):** `objectui generate` no longer accepts `--output`. The flag is retired, with no alias window, and the CLI now refuses it as an unknown option (objectui#11476).
523
+
524
+ (The bump is `minor` by this repo's release model: objectui's major follows the `@objectstack` family major, and its own breaking changes ship as `minor` with the breaking semantics stated here.)
525
+
526
+ - FROM `objectui generate TYPE NAME --output DIR` TO `objectui generate TYPE NAME`: drop the flag. Files are written in the generator's per-type layout under the current directory, e.g. `pages/NAME.json`.
527
+
528
+ **Why.** The flag was declared (documented default `schemas/`) and documented, but nothing read it. The action called `generate(type, name)` without it, so a run with `--output custom/` exited 0, wrote `pages/NAME.json`, and created no `custom/` directory. Its documented default was not even where the generator writes. Honouring it would have meant inventing and testing an output layout for every resource type, with no measured user, so the flag goes instead.
529
+
530
+ **What changes at the command line.** `objectui generate page NAME --output DIR` now exits non-zero with commander's unknown-option error and writes nothing. Without the flag, `generate` writes exactly where it wrote before. `objectui generate --help` no longer lists `--output`, and the `generate` flag table in the CLI docs drops its row.
531
+
532
+ **Clause-②: yes.** The published CLI's accept set narrows: an option `generate` used to accept (and ignore) is now refused. No exported symbol moves.
533
+ - 1fe05ff: **BREAKING (`@object-ui/cli`):** `objectui generate` no longer accepts `--from`. The flag is retired, with no alias window and no placeholder, and the CLI now refuses it as an unknown option (objectui#11488).
534
+
535
+ (The bump is `minor` by this repo's release model: objectui's major follows the `@objectstack` family major, and its own breaking changes ship as `minor` with the breaking semantics stated here.)
536
+
537
+ - FROM `objectui generate TYPE NAME --from SOURCE` TO `objectui generate TYPE NAME`: drop the flag. No import from an external source (OpenAPI, Prisma) exists, so there is nothing to replace it with; `generate` scaffolds the resource in the generator's per-type layout under the current directory, e.g. `pages/NAME.json`.
538
+
539
+ **Why.** The flag was declared ("Generate schema from external source (openapi.yaml, prisma.schema)") and documented as *experimental*, but no importer was ever built. A run with `--from openapi.yaml` printed "not yet implemented", exited 0 and wrote nothing, so a script or CI step read the no-op as success. No producer of the flag was measured, and building an OpenAPI or Prisma importer would be a new capability with no pull, so the flag goes instead.
540
+
541
+ **What changes at the command line.** `objectui generate page NAME --from SOURCE` now exits non-zero with commander's unknown-option error and writes nothing. Without the flag, `generate` behaves exactly as before. `objectui generate --help` no longer lists `--from`, and the `generate` section of the CLI docs drops its flag table, which `--from` was the last row of.
542
+
543
+ **Clause-②: yes.** The published CLI's accept set narrows: an option `generate` used to accept (and answer with a no-op that exited 0) is now refused. No exported symbol moves.
544
+ - ea39141: **BREAKING (`@object-ui/cli`):** the `objectui add` command is retired, and so are `objectui analyze`'s two flags, `--render-performance` and `--bundle-size`. There is no alias window and no placeholder: the CLI now refuses `add` as an unknown command and each flag as an unknown option (objectui#11496).
545
+
546
+ (The bump is `minor` by this repo's release model: objectui's major follows the `@objectstack` family major, and its own breaking changes ship as `minor` with the breaking semantics stated here.)
547
+
548
+ - FROM `objectui add COMPONENT` TO nothing: drop the call. No renderer download or scaffold exists, so there is nothing to replace it with.
549
+ - FROM `objectui analyze --render-performance` TO nothing: drop the call. It analysed nothing; it printed the same fixed list of tips in every directory.
550
+ - FROM `objectui analyze --bundle-size` TO `objectui analyze`: drop the flag. The bundle-size report is now all `analyze` does.
551
+
552
+ **Why.** `add` was declared ("Add a new component renderer to your project") and documented with an example, but its action printed "Feature not implemented yet.", wrote nothing and exited 0, so a script or CI step read the no-op as success. No producer of the command was measured, and downloading renderer source into a project would be a new capability with no pull, so the command goes instead. Checking every other command and flag the CLI declares turned up one more no-op: `analyze --render-performance` printed fixed text, byte for byte the same in an empty directory and in a built project, and exited 0. It goes the same way. `--bundle-size` only chose between that section and the bundle report; with one analysis left it would be read by nothing, which is why `generate --output` was retired, so it goes too.
553
+
554
+ **What changes at the command line.** `objectui add Input` now exits non-zero with commander's unknown-command error and writes nothing. `objectui analyze --render-performance` and `objectui analyze --bundle-size` exit non-zero with the unknown-option error. `objectui analyze` with no flag prints the bundle-size report of `dist/` exactly as before, without the fixed render-performance section. `objectui --help` no longer lists `add`, `objectui analyze --help` lists no flags, and the CLI docs and the package README drop the `add` section and the `analyze` flag table.
555
+
556
+ **Clause-②: yes.** The published CLI's accept set narrows: a command and two options it used to accept are now refused. No exported symbol moves; `analyze` is not part of the package's exports.
557
+ - 37268aa: **BREAKING (`@object-ui/cli`):** four commands are retired: `objectui create`, `objectui lint`, `objectui test` and `objectui studio`. There is no alias window and no placeholder: the CLI now refuses each as an unknown command (objectui#11500).
558
+
559
+ (The bump is `minor` by this repo's release model: objectui's major follows the `@objectstack` family major, and its own breaking changes ship as `minor` with the breaking semantics stated here.)
560
+
561
+ - FROM `objectui create plugin NAME` TO `npm create @object-ui/plugin NAME`, the package's own initializer (`@object-ui/create-plugin`). `plugin` was the only type `create` accepted, so `create` itself goes.
562
+ - FROM `objectui lint` and `objectui test` TO your project's own ESLint and Vitest (or whichever linter and test runner it declares), run directly.
563
+ - FROM `objectui studio` TO nothing published. Contributors to the objectui monorepo run `pnpm --filter console dev`.
564
+
565
+ **Why.** Each of the four could only fail. `create plugin` looked for its generator one directory too high, so it exited 1 with a "Cannot find module" error in a checkout and in an installed copy alike, and wrote nothing. `lint` and `test` ran ESLint and Vitest inside the temp app `objectui dev` generates, which declares neither tool and has no lint config and no tests, so they failed on every run, and they reported the setup error as lint findings or failed tests. `studio` started this monorepo's console app rather than the local project its documentation promised, and outside the monorepo it exited 1 with "Console app not found in workspace".
566
+
567
+ **Corrected alongside, each to what the command does:**
568
+
569
+ - `objectui analyze` with no `dist/` directory now exits non-zero with an error naming the missing `dist/`. It used to print a warning, then "Analysis complete", and exit 0.
570
+ - `objectui init NAME --template UNKNOWN` now refuses the template before it creates the `NAME` directory. It used to exit 1 and leave an empty `NAME` directory behind, which the next `init NAME` then refused as already existing.
571
+ - `objectui doctor`'s help no longer says it fixes issues. It reports and changes no file. The CLI docs no longer promise a Node version check it never ran.
572
+ - The CLI docs no longer say `objectui serve` lacks `--no-open`. It has always accepted it, as `dev` does.
573
+
574
+ **What changes at the command line.** `objectui create plugin my-widget`, `objectui lint`, `objectui test` and `objectui studio` now exit non-zero with commander's unknown-command error and write nothing. `objectui --help` no longer lists them. The CLI docs and the package README drop their sections, and the docs name the plugin initializer.
575
+
576
+ **Clause-②: yes.** The published CLI's accept set narrows: four commands it used to accept are now refused, and `analyze` without `dist/` now exits non-zero. No exported symbol moves; none of these commands is part of the package's exports.
577
+ - 33da643: feat(cli): `objectui check` refuses a `${…}` on a text key its node never evaluates
578
+
579
+ `SchemaRenderer` evaluates an expression on the closed text keys `title`,
580
+ `label`, `value` and `description` only where `@objectstack/spec`'s
581
+ `expressionBindableTextKeysFor(type)` lists that key for the node's type.
582
+ Anywhere else the expression is never resolved, so the user sees
583
+ `${data.total}` as literal text, or nothing at all — and no step before the
584
+ browser said so.
585
+
586
+ `objectui check` now refuses such an expression in every file it recognises as
587
+ an ObjectUI schema, and the run exits non-zero. The refusal names the key, the
588
+ path to it (spelled as `objectui validate` spells paths), the keys that type
589
+ does evaluate, and the channels `SchemaRenderer` evaluates. Types with no row in
590
+ the carriage map are refused too: `text.value` and `action:button.label` are
591
+ never evaluated.
592
+
593
+ - **Component nodes only**: the file's root node and every node its `children`
594
+ hold. Objects under other keys, such as a form's `fields` entries, are
595
+ definitions rather than nodes and are not judged. A root of type `page` keeps
596
+ its own `title`, which is a page key; its `children` are still judged.
597
+ - **The type is matched as written**, as the runtime matches it: `ui:card` has
598
+ no row, and is not read as `card`.
599
+ - **A type no registered component answers to** gets a warning instead of a
600
+ refusal, because a custom renderer may evaluate its own keys.
601
+ - **There is no escape spelling**: a `${…}` meant as literal text on one of
602
+ these keys, such as a code sample in a `code-editor`'s `value`, is refused
603
+ too. Write it without `${`.
604
+
605
+ The key vocabulary and the per-type carriage map are read from
606
+ `@objectstack/spec`, now a declared dependency of `@object-ui/cli`, so a row
607
+ added upstream moves this check and the runtime together.
608
+ - 7dc08a3: `objectui check` recognises a schema by validating it, and reports broken ObjectUI files instead of filing them as foreign ones.
609
+
610
+ A file with a root `type` was judged only when its root carried an ObjectUI
611
+ structural key (`children`, `body`, `className`, …). Leaf schemas carry only
612
+ their own vocabulary, so nothing checked them: measured on this repository, 475
613
+ files were eligible, 166 were judged and 309 were skipped.
614
+
615
+ The command now has a second recogniser arm — the document validates as an
616
+ ObjectUI component schema under `@object-ui/types`' own Zod union — which the
617
+ maintainer's 2026-08-25 ruling selected over shipping a JSON Schema artifact to
618
+ point a `$schema` URL at. It admits 209 of those 309 files. The structural arm
619
+ still runs first, so recognition costs nothing for files that already had a
620
+ marker, and `package.json` is still never judged: `"type": "module"` names no
621
+ component the protocol models.
622
+
623
+ Validity alone would have answered two different questions with one word.
624
+ A broken ObjectUI schema fails validation exactly as a foreign file does, so a
625
+ two-bucket report would have filed it as "not ObjectUI" — and the symptom of
626
+ that is an absence: the file simply stops being mentioned. Measured, that bucket
627
+ is not empty: 54 files land in it and 53 of them are real corpus content.
628
+
629
+ So files the recogniser refuses are split. When the root `type` names a
630
+ component this build registers, the file is **listed by name** as ObjectUI
631
+ content that did not validate, pointing at `objectui validate <file>` for the
632
+ reason — either the document is off-spec or its component type is not modelled
633
+ by `@object-ui/types`. Everything else is counted as skipped, as before. The
634
+ printed explanation now describes both arms, and only unreadable JSON still
635
+ makes the command exit non-zero.
636
+ - 2acd8e1: **BREAKING (authoring surface): `body` is no longer a child-list key. Author `children`.**
637
+
638
+ `BaseSchema` declared two spellings of one concept — `body` and `children` — and left the
639
+ choice per component. **Thirteen** registrations read `body` and nothing else, so it was
640
+ their ONLY door — the twelve the ruling enumerated plus `tooltip`, which it did not, and
641
+ which is the count the committed instrument carries (`BODY_ONLY` plus
642
+ `BODY_ONLY_UNRULED` in `scripts/body-dialect-census.mjs`). `div`, `card`, `page`,
643
+ `button`, `aspect-ratio`, the seven sectioning tags and the safe-HTML tag factory read
644
+ `children || body` and took either. The authoring tier only ever knew `children`, so
645
+ an author writing the one spelling that resolved got `unknown-prop` — the same warning a
646
+ typo draws, on the tier built to accept AI-authored pages, where the diagnostic **is** the
647
+ contract (objectui#6771).
648
+
649
+ Ruled 2026-09-01: one concept, one spelling, and the spelling is `children`.
650
+
651
+ ## What changed
652
+
653
+ - **Renderers.** `alert`, `badge`, `tooltip` and the `sidebar-*` family read `children`.
654
+ Every `children || body` fallback drops its `body` arm **except the four `page:*`
655
+ reads named below** — `div`, `card`, `button`, `aspect-ratio`, the sectioning tags,
656
+ the safe-HTML tag factory behind ~36 tags, `page`'s flat content list, and
657
+ `@object-ui/core`'s recursive `validateSchema`.
658
+ - **Item-level `body` is a DIFFERENT key and is untouched.** At this change, `list`
659
+ draws each entry as `item.content || renderChildren(item.body)` and `tabs` as
660
+ `item.content || item.body`, both filed under the ITEM type rather than the node,
661
+ and `tabs` still ships `body` inside its own `defaultProps`. ⛔ Neither is this
662
+ spelling and neither is refused here: the node-level retirement does not reach a
663
+ member of a declared `items` array. Retiring the item-level dialect is
664
+ objectui#9590's card, and the two named above are recorded on it.
665
+ ⚠️ **Dated note, 2026-09-25 — neither half of this bullet holds any longer — objectui#9590.**
666
+ objectui#9941 respelled the `tabs` `defaultProps` items to `content`, and
667
+ objectui#9590 retired both item-level reads: a `list` item and a `tabs` item draw
668
+ `content` and nothing else, and both item faces now refuse `body` by name,
669
+ pointing at `content`. The rest of this bullet is kept as the reading of this change.
670
+ - **What still reads `body` at NODE level, and why.** Four renderer reads, all `page:*`: `page:card`
671
+ (renderer and Studio canvas) and the three thin `page:section` / `page:footer` /
672
+ `page:sidebar` containers. ⛔ Authoring the key is refused on them as it is
673
+ everywhere else; only the READ survives, for documents already STORED under it.
674
+ `@objectstack/spec` states the ground on `PageContainerProps` itself: «The renderers
675
+ keep reading `body` as a back-compat fallback for stored documents; that fallback is
676
+ objectui's to retire on its own schedule, and it is not a second authorable
677
+ spelling.» ⚠️ What separates the two halves is a CONVERSION, not a ground: the spec's
678
+ registry carries `page-card-body-to-children` (`toMajor: 17`, surface
679
+ `page.component.page:card.body`, shipped `retiredFromLoadPath: true` in spec 17.0.0)
680
+ and carries none for the other three — so a stored row under their key has no
681
+ migration path at all. Nothing in this repository authors any of them, and the
682
+ committed census over those keys is how to see that rather than take it on trust:
683
+ `node scripts/body-dialect-census.mjs --keys page:section,page:footer,page:sidebar,page:card,card`.
684
+ ⚠️ This sentence used to restate that table's answer instead of pointing at it, and
685
+ the very commit that edited the sentence moved the figure — a count copied into prose
686
+ is what AGENTS.md #9 forbids, so the instrument replaces the number. Read the table
687
+ for three things: `card` + `body` is a control that FIRES on the head that ships (so
688
+ a zero elsewhere is a reading, not a blind spot), every node still carrying `body`
689
+ under these keys falls in the `test` bucket, and `page:section` is a LIT zero — 6
690
+ nodes resolved, 0 `body`, 4 `children` — rather than a key nobody asked about.
691
+ Retiring the THREE THIN reads is objectui#9916,
692
+ which asks for the stored-corpus reading they turn on; `page:card`'s read is not
693
+ that card's either — it is objectui's own, grounded by objectstack#5775 /
694
+ ADR-0087 D2 rather than owned by it, and it ends when the stored rows have been
695
+ replayed through the conversion that already shipped for it.
696
+ - **The published type.** `BaseSchema.body` is `never` on the TypeScript face and an
697
+ alias refusal naming `children` on the Zod mirror, as are the four per-component
698
+ redeclarations (`CardSchema`, `AspectRatioSchema`, `PageNodeSchema`, `TooltipSchema`).
699
+ ⚠️ Refused **by name**, not deleted: `BaseSchema` carries an index signature and the
700
+ mirror ends `.passthrough()`, so a deleted member would be accepted silently and
701
+ rendered by nothing — the exact silence this retirement ends.
702
+ - **The VS Code extension (`object-ui`) changes behaviour, not just teaching.** Its
703
+ preview no longer draws a `body`-spelled document — the node renders empty, the way
704
+ the runtime renders it — and its validator now emits a warning naming `children` at
705
+ the key's own position. That warning is skipped for node types that declare their
706
+ own `body` input (`record:alert`), so a declared translation-map `body` is not
707
+ reported as the retired spelling.
708
+ - **Two new `@object-ui/sdui-parser` exports.** `RETIRED_CHILD_LIST_KEY` (the retired
709
+ spelling, so a consumer names it once) and `checkRetiredBodyDialect` (the diagnostic
710
+ the tier substitutes for `unknown-prop` on that key).
711
+ - **The authoring tier.** `sdui-parser` answers an authored `body` with the replacement
712
+ named, instead of the bare "has no prop" every typo gets — and a `body` child list
713
+ under a non-container draws the same containment code the `children` spelling draws.
714
+ - **Corpus and teaching, in the same change.** 114 authored nodes across the docs site,
715
+ the schema catalog, five package READMEs and the VS Code extension's snippets, JSON
716
+ schema, syntax map, hovers and completions. The platform does not refuse a spelling it
717
+ still ships.
718
+
719
+ ## Migrating
720
+
721
+ Rename the key. `{ "type": "card", "body": [...] }` becomes
722
+ `{ "type": "card", "children": [...] }`; both faces now name `children` in the refusal,
723
+ and `pnpm census:body-dialect` reports where the dialect still lives in a tree.
724
+
725
+ ⚠️ **Four renderer reads are deliberately untouched, all in the `page:*` namespace** —
726
+ `page:card` and the three thin `page:section` / `page:footer` / `page:sidebar`
727
+ containers. They are read-only back-compat paths for STORED documents, not a second
728
+ authoring face: `@objectstack/spec`'s `PageContainerProps` says so itself — `children`
729
+ is canonical, `body` is deliberately not declared, and «the renderers keep reading
730
+ `body` as a back-compat fallback for stored documents; that fallback is objectui's to
731
+ retire on its own schedule».
732
+
733
+ ⛔ **Authoring `body` on them is still refused**, on both published faces and at the
734
+ authoring tier, exactly as everywhere else. What survives is the READ.
735
+
736
+ ⚠️ The two halves are not in the same state. `page:card` has a migration path — the
737
+ spec's conversions registry carries `page-card-body-to-children` (`toMajor: 17`,
738
+ surface `page.component.page:card.body`), which shipped with `retiredFromLoadPath: true`
739
+ in spec 17.0.0. The other three have **no conversion at all**, so a stored row under
740
+ their key has nowhere to be migrated to. ⇒ the two halves are tracked separately, and
741
+ the pointer is not one card: retiring the three thin reads is objectui#9916, whose
742
+ question is the stored corpus; retiring `page:card`'s read was **grounded by**
743
+ objectstack#5775 / ADR-0087 D2, whose conversion has already shipped and whose
744
+ remaining condition is replayed rows. ⚠️ Grounded by, not owned by — the distinction
745
+ is the point. objectstack#5775 is CLOSED and its body is a props-declaration audit
746
+ that carries no such step, so a reader sent there for the action finds none. The
747
+ action is objectui's, on the spec's own terms quoted above: «that fallback is
748
+ objectui's to retire on its own schedule.»
749
+
750
+ **Non-rendering readers keep their arm on the same rule**, and none of them renders
751
+ anything: while a renderer still reaches stored `body` content, a reader that must see
752
+ the SAME content keeps its arm, or the renderer draws what the reader cannot find.
753
+ Those are the two tab-subtree walkers in `renderers/layout/containers.tsx`,
754
+ `app-shell`'s `pageSchemaIntrospect` (`CONTAINER_KEYS`) and `PageBlockInspector`
755
+ (`STRUCTURAL_PROP_KEYS`, the inspector half of a stored `properties.body`), and the
756
+ CLI's `OBJECTUI_STRUCTURAL_KEYS` — a file-IDENTIFICATION marker, where keeping `body` is
757
+ what lets an old file still be recognised as an ObjectUI node and therefore refused,
758
+ instead of silently not judged.
759
+
760
+ ⚠️ **Dated note, 2026-10-02 — the `sidebar-*` parts are retired — objectui#10859.**
761
+ Later in this same release objectui#10859 batch 8 (phase 2d) unregistered the ten `sidebar-*` part keys. Of the
762
+ family the **Renderers** line names, only `sidebar` remains, and it reads `children`. The rest of this entry is
763
+ kept as the reading of this change.
764
+ - a5d5547: `objectui validate` now prints the failing union arm the document selected, instead of a
765
+ bare "Invalid input" (maintainer ruling 2026-09-02 — option B).
766
+
767
+ `safeValidateSchema` checks a document against `AnyComponentSchema`, a `z.union`. When a
768
+ document matches no arm, Zod reports ONE top-level issue — `invalid_union` · `Invalid
769
+ input` · path `(root)` — and hangs every arm's real diagnosis off that issue's `errors`
770
+ array, which nothing read. So a menu whose item used the divider spelling retired in
771
+ objectui#6523 printed a bare verdict on the whole document, while the remediation text
772
+ `8063bcbdc` wrote into that arm sat one level down, unreachable.
773
+
774
+ **What is printed now.** When the top-level issue is a failing union:
775
+
776
+ - the document's `type` selects exactly one arm ⇒ that arm's issues are printed beneath
777
+ the entry as `1.1`, `1.2` … with their real paths (`Path: items → 0 → type`) and codes,
778
+ and **nothing** from the other arms;
779
+ - no arm accepts the `type` ⇒ `No arm accepts type "dropdwn-menu".` plus the nearest few
780
+ of the accepted values, ranked by edit distance and **capped** at five
781
+ (`MAX_UNION_ARMS_REPORTED`);
782
+ - the document declares no `type` at all ⇒ the note says so and offers no candidates —
783
+ "nearest" needs something to be near, and an alphabetical slice of 108 arm names
784
+ presented as guidance would be a bogus suggestion;
785
+ - a union with no `type` discriminator to select on — `MenuItemSchema`, whose two arms
786
+ both declare `type` as an ADR-0049 retirement tombstone — reports every arm, labelled
787
+ and capped by the same constant. This is the path that finally delivers the
788
+ objectui#6523 text to the author.
789
+
790
+ Printing EVERY arm was rejected in the ruling: `AnyComponentSchema` resolves to 108 leaf
791
+ arms, so one mistyped `type` would have produced hundreds of lines.
792
+
793
+ `objectui check` is unchanged and deliberately so: it has no zod-issue printer, using
794
+ `safeValidateSchema(...).success` as a boolean recogniser. Printing issues behind a
795
+ *negative* recognition would flood its report with diagnoses of non-ObjectUI files, the
796
+ failure objectui#5127 and objectui#6075 exist to prevent.
797
+
798
+ ⚠️ **Dated note, 2026-09-29 — objectui#11007.** `check` now prints one line under each file in
799
+ its "did not validate" list: the first issue's path, spelled by the formatter behind `validate`'s
800
+ `Path:` line, and its message, with no arm selection. That list is the only place it prints
801
+ one. Files counted as skipped, the foreign files the paragraph above guards against, still get
802
+ no diagnosis.
803
+
804
+ Nothing about which documents are ACCEPTED changes — this is diagnostic output only.
805
+ - 4b5bb95: The VS Code extension no longer ignores a child list spelled `children`, and everything
806
+ the platform scaffolds now emits that spelling (objectui#7181).
807
+
808
+ ## The defect, and who it hit
809
+
810
+ `children` is the spelling ObjectUI declares on four faces: the `BaseSchema` TypeScript
811
+ declaration and its zod mirror in `@object-ui/types`, `validateSchema` in
812
+ `@object-ui/core`, and the authoring tier's `BASE_PROPS` in `@object-ui/sdui-parser`
813
+ (which accepts `children` and does **not** list `body`).
814
+
815
+ Both readers in the VS Code extension honoured only `body`. So an author who wrote the
816
+ spelling the platform blesses got, from the tool meant to be teaching them the format:
817
+
818
+ - **a blank preview** — `Object UI: Open Preview` rendered the node as an empty card or
819
+ container, with no error and no diagnostic; and
820
+ - **children that were never validated** — the validator's recursion never reached them,
821
+ so a child missing its required `type` drew no warning at all.
822
+
823
+ Both failures were silent in both directions: nothing told the author their file was
824
+ being skipped, and nothing told them it was fine. Metadata written to a file by one
825
+ party and re-authored by another was simply dropped by the reader.
826
+
827
+ Both readers now read `children` first and **keep** `body`, so every existing
828
+ `body`-spelled document behaves exactly as it did. Nothing is removed and no accepted
829
+ spelling is narrowed. The extension's validator also reports diagnostics at the key the
830
+ document actually used, instead of addressing them to `.body[...]` in a file that
831
+ contains no such key.
832
+
833
+ ## Scaffolders and shipped defaults now emit `children`
834
+
835
+ The same dialect was being *produced* into files users own, and into components' own
836
+ declared defaults:
837
+
838
+ - `objectui init` — the `app.json` written for every template
839
+ - `Object UI: Create New Schema` — every template the VS Code extension writes
840
+ - `carousel`, `resizable` and `scroll-area` — the child lists inside their shipped
841
+ `defaultProps`
842
+ - the runner's "no index page found" fallback page
843
+
844
+ Every node type involved already read `children`, so rendering is unchanged; what moves
845
+ is the spelling users are handed as their starting point.
846
+
847
+ ⚠️ This is a change to what those tools *emit*, not to what ObjectUI accepts: `body`
848
+ remains readable everywhere it was readable before, and a project scaffolded by an
849
+ earlier version needs no edit. Retiring the `body` arm is a separate, already-ruled
850
+ step and is not part of this release. `pnpm census:body-dialect` is the instrument that
851
+ reports where the dialect still lives.
852
+
853
+ Scaffolded output and shipped defaults are now pinned by tests that discover the
854
+ template population from the code, so a template added later is covered without anyone
855
+ remembering to extend them.
856
+ - 67749c7: Discriminate `AnyComponentSchema` on `type` (objectui#8498).
857
+
858
+ The union was flat, so a refusal carried EVERY arm's issue list, and Zod's
859
+ `$ZodError` initializer stringifies that whole tree into `.message` eagerly — in the
860
+ constructor, not behind a getter. The cost was paid whether or not anyone read the
861
+ message, and it compounded per level of nesting: measured on zod 4.4.3, a root
862
+ refusal cost 14,624 chars, growing until `RangeError: Invalid string length`, thrown
863
+ out of `safeValidateSchema` — documented as validating "without throwing errors".
864
+ Discriminated, the same document costs 164. `ObjectQLComponentSchema` and
865
+ `CRUDComponentSchema` follow for the same reason: zod refuses a plain `z.union` as a
866
+ discriminated member.
867
+
868
+ **No document changes verdict.** The 13 arms declare 107 `type` literals with zero
869
+ collisions, so the arm a literal selects was already the only arm that could accept
870
+ it; across 440 example documents, flat and discriminated agree on every one.
871
+
872
+ **What moves is diagnostics.** A refused document whose `type` selects an arm now
873
+ reports that arm's issues as top-level issues at absolute paths, rather than one
874
+ `invalid_union` at the root with them nested inside; a `type` no arm claims is
875
+ reported at `type` rather than at the root. `objectui validate` prints the same
876
+ 2026-09-02 ruling output — the selected arm alone, or a note plus a capped candidate
877
+ list — read off the new issue shape.
878
+
879
+ ⚠️ **Dated note, 2026-09-28 — a fourteenth arm — objectui#10859.** Later in this same release
880
+ `AnyComponentSchema` gains a fourteenth top-level arm, `AIComponentSchema` (the three AI node types),
881
+ and still no `type` literal is claimed by two arms — the property this entry's "no document changes
882
+ verdict" rests on. The counts above are this change's reading; the objectui#10859 entry states what
883
+ that arm accepts.
884
+ - 6a4680b: Retire `line-chart`, `area-chart` and `advanced-chart` — three chart component keys the
885
+ console registered as lazy stubs that `@object-ui/plugin-charts` never fulfilled
886
+ (objectui#8760).
887
+
888
+ **The defect, and why it outlived the checks.** `apps/console` registered ten chart
889
+ variants as `registerLazy` stubs pointing at `@object-ui/plugin-charts`. That package
890
+ registers eight keys; three of the ten were not among them. An unfulfilled stub does not
891
+ fail — it succeeds at being useless, in both of the places that decide whether a defect
892
+ is ever seen:
893
+
894
+ - **At render.** `SchemaRenderer`'s lazy branch re-checks `hasLazy(type)` on every pass
895
+ and returns the `Loading <type>…` placeholder. `Registry.register()` deletes a lazy
896
+ entry only for keys the loaded module actually registers, so for an unfulfilled key the
897
+ entry SURVIVES the load and every later pass takes the same branch. Measured on
898
+ `b775500af` through the real chain: `{ "type": "line-chart" }` painted
899
+ `role="status"` / `data-lazy-loading="line-chart"` / `Loading line-chart…`,
900
+ permanently. **Not** the `OBJUI-001` panel the card expected — no alert, no error, no
901
+ console warning. A skeleton that never resolves reads to a user as a slow network.
902
+ - **At authoring.** A stub is enough to put a key into `getKnownTypes()`, so
903
+ `check:doc-types` and the CLI's generated `KNOWN_SCHEMA_TYPES` snapshot both blessed
904
+ all three. `content/docs/plugins/plugin-dashboard.mdx` taught `"type": "line-chart"`
905
+ inside a `card` body, and every gate was green on it.
906
+
907
+ So the failure was strictly worse than an unknown key: an unknown key is refused loudly at
908
+ authoring time, while these passed every check, were taught by the documentation, and
909
+ failed only at render in front of a user.
910
+
911
+ **Why removal rather than implementation.** Both repairs were available and they are not
912
+ equivalent. Fulfilment would mint three new pieces of authorable surface: `line-chart` and
913
+ `area-chart` duplicate, under a second spelling, families the plugin already draws as
914
+ `{ "type": "chart", "chartType": "line" | "area" }`, and `advanced-chart` was never a
915
+ family at all — it named `AdvancedChartImpl`, an internal module. Measured demand for all
916
+ three is zero: a sweep of both repositories for authored nodes of these types returns
917
+ exactly one hit, the doc snippet corrected here, against lit controls in the same
918
+ commands (`"type": "bar-chart"` 5, `"type": "chart"` 12, `object-chart` 1 in the sibling
919
+ repo). No example app, fixture, seed document or deployment authors any of them. Under
920
+ 声明即强制, a declaration with no delivery and no demand comes off rather than growing an
921
+ implementation to match it.
922
+
923
+ **Breaking, for anyone who authored a retired key.** A document with
924
+ `{ "type": "line-chart" }` used to resolve in the registry and then draw nothing; it is
925
+ now refused by name — `SchemaRenderer` paints the `OBJUI-001` panel instead of an endless
926
+ skeleton. `objectui validate` refuses the document at `type` (`invalid_union`). That is a
927
+ louder failure for the same broken document, not a new one: no document that previously
928
+ DREW is affected. Migrate to `{ "type": "chart", "chartType": "line" | "area" }`, which
929
+ `CHART_TYPE_KEYWORD_FAMILIES` resolves. Scored `minor`, not `major`, per
930
+ AGENTS.md §版本号策略.
931
+
932
+ ⚠️ **Dated note, 2026-09-25 — `objectui check` warns only in a file it recognises —
933
+ objectui#10606.** This entry first said `objectui check` reports `Unknown schema type
934
+ "line-chart"` for that document. `check` checks the `type` of each file it recognises, and a
935
+ file whose root carries an ObjectUI structural key (`children`, `className`, `body`, …) is
936
+ recognised by that key alone. A file with none of those keys is parsed against the schema
937
+ and recognised only if it validates; one that does not validate is listed by name when its
938
+ root `type` is on the known-type list `check` reads, and is otherwise counted as skipped.
939
+ `line-chart` is no longer on that list, so `{ "type": "line-chart" }` is counted as skipped
940
+ ("no ObjectUI recogniser admitted") and gets no unknown-type line, while
941
+ `{ "type": "line-chart", "className": "h-64" }` gets one. `check` exits non-zero on
942
+ unreadable JSON only; the verdict is `objectui validate`'s.
943
+
944
+ **What moved.** The stub lists in `apps/console/src/register-plugins.ts` and
945
+ `apps/console/src/preview-gallery.tsx` (both loops, because the doc gate's key universe is
946
+ their union — retiring one alone would have changed nothing observable); the dashboard doc
947
+ snippet plus a note on how chart families are actually spelled; the regenerated
948
+ `KNOWN_SCHEMA_TYPES` snapshot (six entries, three bare and three namespaced); and the
949
+ `line-chart` leg of `node-slot-registered-arms-8499.test.ts`, whose premise this
950
+ retirement changed and which reads the stub list rather than the file so the ⛔ comment
951
+ left behind cannot satisfy it.
952
+ - e356c39: Converge the bare `dashboard` key on `plugin-dashboard`, and retire
953
+ `view:dashboard` with a by-name tombstone (objectui#9533).
954
+
955
+ **Breaking for authored metadata.** `{ "type": "view:dashboard" }` no longer
956
+ renders a dashboard. It now resolves to a refusal that names the spelling and
957
+ names its replacement. `objectui validate` refuses the document at `type`
958
+ (`invalid_union`). `{ "type": "dashboard" }` and
959
+ `{ "type": "plugin-dashboard:dashboard" }` both render `DashboardRenderer`,
960
+ unchanged and newly-working respectively.
961
+
962
+ ⚠️ **Dated note, 2026-09-25 — `objectui check` names the spelling only in a
963
+ file it recognises — objectui#10606.** This entry first said `objectui check`
964
+ reports `{ "type": "view:dashboard" }` as an unknown schema type, and **What
965
+ changed** below said, unscoped, that `check` names the spelling. `check` checks
966
+ the `type` of each file it recognises, and a file whose root carries an ObjectUI
967
+ structural key (`children`, `className`, `body`, …) is recognised by that key
968
+ alone. A file with none of those keys is parsed against the schema and
969
+ recognised only if it validates; one that does not validate is listed by name
970
+ when its root `type` is on the known-type list `check` reads, and is otherwise
971
+ counted as skipped. `view:dashboard` is withheld from that list, so the document
972
+ above is counted as skipped ("no ObjectUI recogniser admitted") and gets no
973
+ unknown-type line, while `{ "type": "view:dashboard", "className": "h-64" }` gets one.
974
+ `check` exits non-zero on unreadable JSON only; the verdict is
975
+ `objectui validate`'s.
976
+
977
+ **What was wrong.** `apps/console` declares the lazy stub for bare `dashboard`
978
+ under `plugin-dashboard` — twice, in `preview-gallery.tsx` and
979
+ `register-plugins.ts` — while this package registered the renderer as
980
+ `view:dashboard`. Neither site passed `skipFallback`, so both also claimed the
981
+ bare key (`Registry.register` and `Registry.registerLazy` share the
982
+ `meta?.namespace && !meta?.skipFallback` branch, and `registerLazy` has no
983
+ collision check at all, so nothing warned). Two consequences followed, and both
984
+ were reproduced against a real `Registry` before anything here was written:
985
+
986
+ 1. **The bare key was double-claimed, phase-dependently.** After the stub step
987
+ bare `dashboard` declared namespace `plugin-dashboard`; after the chunk
988
+ loaded the same key declared `view`. Which answer a host got depended on when
989
+ it asked — the objectui#6416 shape, which converged `plugin-report` off it.
990
+ 2. **The namespaced stub was never cleared.** `register()` clears the lazy stub
991
+ of the type IT registers, and that type was `view:dashboard`. So
992
+ `hasLazy('dashboard', 'plugin-dashboard')` read `true` after the package had
993
+ fully loaded and `get('dashboard', 'plugin-dashboard')` read `undefined`,
994
+ while the generated CLI whitelist listed that spelling as renderable. A node
995
+ authored with it could only ever paint `Loading plugin-dashboard:dashboard…`
996
+ forever: `Registry.loadLazy` resolves whether or not the loaded module
997
+ registered the expected type, and `SchemaRenderer` re-checks `hasLazy` on
998
+ every pass. That is the objectui#8760 shape — a key that passes every
999
+ authoring check and fails only in front of a user.
1000
+
1001
+ **What changed.** The renderer registers as `plugin-dashboard:dashboard`, the
1002
+ namespace every sibling plugin, both console stubs and the CLI whitelist already
1003
+ use, so the console stubs are cleared on load and all three claimants of the bare
1004
+ key name ONE full type. The retired `view:dashboard` key answers
1005
+ `RetiredDashboardNodeTombstone` — an inline refusal, plus a `console.error`
1006
+ carrying the same text — registered with `skipFallback: true` so it claims no
1007
+ bare key. Its spelling is withheld from the derived key universe by declaration
1008
+ in `scripts/check-doc-component-types.mjs`, the same disposition the
1009
+ `RETIRED_FIELD_TYPES` tombstones take, so `objectui check` names it in a file it
1010
+ recognises rather than blessing it; `packages/cli/src/utils/known-schema-types.ts`
1011
+ regenerates and loses that one entry.
1012
+
1013
+ **Also published: four new symbols on the package entry.** `src/index.tsx`
1014
+ re-exports `RETIRED_DASHBOARD_NODE_TYPES`, `RetiredDashboardNodeTombstone`,
1015
+ `reportRetiredDashboardNodeType` and `resetRetiredDashboardNodeTypeReports` from
1016
+ `./retired-node-types`, and `exports["."]` is what publishes them — so these are
1017
+ **published** surface, not an internal one, and removing or renaming one later is
1018
+ a breaking change like any other export. They exist for the same reason
1019
+ `@object-ui/fields` publishes its tombstone: the pin has to import the refusal
1020
+ text it asserts rather than restate it.
1021
+
1022
+ **Also visible in the DOM: the `data-obj-type` value on a dashboard grid.** That
1023
+ attribute carries the type the node was AUTHORED with, so the spelling that puts
1024
+ a dashboard grid on the page moves with the registration.
1025
+ `[data-obj-type="view:dashboard"]` no longer selects one — that node now renders
1026
+ the tombstone, which publishes `data-retired-node-type` and no `data-obj-type` at
1027
+ all — while `[data-obj-type="plugin-dashboard:dashboard"]` now does.
1028
+ `{ "type": "dashboard" }` is unchanged and still reads `dashboard`. A stylesheet,
1029
+ a selector or a DOM assertion keyed on the retired value stops matching, and
1030
+ stops matching silently, so it is declared here rather than left to be found.
1031
+
1032
+ **Ruled, not chosen.** Director seat summon #24, batch #152 item 5 letter 1,
1033
+ maintainer 「其他同意」 2026-09-18. The two rejected routes are on the record:
1034
+ converging on `view` would leave the whitelist advertising a dead
1035
+ `plugin-dashboard:dashboard`, and standing one side down resolves the naming
1036
+ contest but not the unsatisfiable stub.
1037
+
1038
+ **`Clause-②: yes`**, declared by that ruling: the published full name moves. Note
1039
+ the shape, because it is unusual — the accept set **narrows** (an authored
1040
+ `view:dashboard` stops resolving) and the clause is `yes` anyway, on the
1041
+ published-name move rather than on a widened surface. `minor` per AGENTS.md's
1042
+ 版本号策略: objectui's own breaking changes take `minor`, with the breaking
1043
+ semantics written out here.
1044
+
1045
+ `packages/plugin-dashboard/src/__tests__/dashboardBareKeyOwnership.test.tsx` is
1046
+ the half that outlives the fix. It reads the package's real declared metadata
1047
+ back out of the registry and replays it into a fresh `Registry` in **both**
1048
+ orders — eager-then-lazy and lazy-then-eager — checking the bare key's declared
1049
+ namespace after every step, so order- and phase-independence are properties under
1050
+ test rather than properties of the file it imports. It also asserts `hasLazy` is
1051
+ false after the load, and asserts the `view:dashboard` refusal **together with**
1052
+ the tombstone's own migration text, because a pin that asserts only "no dashboard
1053
+ rendered" passes identically against a registration that was simply deleted —
1054
+ the one outcome the ruling refuses. `objectui#9264`'s shrink-only bare-name
1055
+ collision ledger loses its row: it is now empty.
1056
+ - d2f723f: `objectui generate page` scaffolds its child list as `children` (objectui#9847).
1057
+
1058
+ ## What changed
1059
+
1060
+ `objectui generate page NAME` writes a `pages/NAME.json` into a project directory the
1061
+ user then owns and re-authors. Its child list was spelled `body` — the dialect
1062
+ objectui#6771 retires.
1063
+
1064
+ The asymmetry that makes the spelling matter is in the authoring tier: `BASE_PROPS` in
1065
+ `@object-ui/sdui-parser` accepts `children` and does **not** list `body`. `BaseSchema`
1066
+ and its zod mirror in `@object-ui/types` declare *both* keys today, and `validateSchema`
1067
+ in `@object-ui/core` reads `children` first and falls back to `body`; retiring that
1068
+ fallback is objectui#6771's own later step and no part of this release.
1069
+
1070
+ The scaffolded page now spells it `children`. Nothing else about the file moves.
1071
+
1072
+ ⚠️ This changes what the tool *emits*, not what ObjectUI accepts. `body` remains
1073
+ readable everywhere it was readable before, and a page scaffolded by an earlier version
1074
+ needs no edit. Retiring the `body` arm is a separate, already-ruled step and is not part
1075
+ of this release.
1076
+
1077
+ ## Why it was missed
1078
+
1079
+ objectui#7181 moved the `body` dialect off the platform's producers, working from a
1080
+ table of six files. `generatePage` is a seventh producer of exactly the same shape —
1081
+ code that emits `body`-spelled metadata into a file a user then owns — and that table
1082
+ never named it, so a migration round aimed at its own family passed it over.
1083
+
1084
+ The ordering constraint it sits under is the family's own: once the authoring tier
1085
+ teaches `children` only, a scaffolder still emitting `body` hands a new user a project
1086
+ that their very next `objectui validate` rejects.
1087
+
1088
+ ## What now re-derives this instead of remembering it
1089
+
1090
+ - A new pin runs `objectui generate` into a throwaway directory and reads the bytes back
1091
+ out, rather than reading this repo's source text — a source-text assertion over a file
1092
+ that documents the construct it asserts on passes off the comment, measured elsewhere
1093
+ in this family. Its type population is discovered from the line `generate` prints for
1094
+ an unknown type, so a type added later is covered without anyone extending the pin.
1095
+ - `pnpm census:body-dialect` remains the instrument that reports where the dialect still
1096
+ lives. The census pins keep their named-producer list — it is the drift guard — and now
1097
+ assert over the instrument's *population* beside it, so a producer arriving in a file
1098
+ nobody listed fails the suite without anyone remembering to extend that list.
1099
+
1100
+ ⛔ This does not clear objectui#6771's step 4. The census's own stated limits keep two
1101
+ producer-shaped sites out of its reach, and both are still live; the census pins name
1102
+ them, and objectui#9847's delivery reports them.
1103
+ - 94021dd: `objectui check` judges a file's `type` only when the file is recognisable as an ObjectUI schema, and reports how many it declined to judge.
1104
+
1105
+ A root `type` was treated as a component key wherever it appeared. `type` heads at
1106
+ least seven unrelated JSON vocabularies, and the most common of them is
1107
+ `package.json`'s `"type": "module"` — so the first line a user saw running
1108
+ `objectui check` in their own project was a warning about their own package
1109
+ manifest. Measured at this repository's root: 46 warnings, 45 of them
1110
+ `package.json` (objectui#5127).
1111
+
1112
+ A file now enters type judgement only when its root carries a structural key
1113
+ declared on `BaseSchema` — `children`, `body`, `className`, `placeholder`,
1114
+ `style`, the `visible`/`hidden`/`disabled` predicate family, `testId`,
1115
+ `ariaLabel`. Every other root-`type` vocabulary — JSON Schema's `"array"`, an
1116
+ `.eslintrc.json`'s `"commonjs"`, a package manifest's `"module"` — is simply
1117
+ never judged. The key set is read out of the node contract rather than invented,
1118
+ and it is closed: it grows only when `BaseSchema` grows.
1119
+
1120
+ A list of filenames to exclude was the alternative and was rejected: it is a
1121
+ second hand-maintained list of the shape objectui#5115 had just finished
1122
+ deleting, and it can only ever enumerate the foreign vocabularies someone already
1123
+ thought of. This is a positive marker instead.
1124
+
1125
+ Because the marker narrows what is checked, the command now also reports the
1126
+ count of files that had a root `type` and no marker, together with the marker
1127
+ keys that opt one back in. That number is the coverage this gate gives up until
1128
+ schema files are recognisable, and printing it is what keeps the loss visible
1129
+ rather than silent. The `.yaml`/`.yml` half of the scan is unchanged — it was
1130
+ never type-judged, before this change or after it. Exit codes are untouched: a
1131
+ JSON parse failure remains the only thing that fails the run.
1132
+
1133
+ No public `$schema` URL is introduced. An earlier revision also admitted a file
1134
+ whose root `$schema` had an `objectui.org` host; the maintainer ruled against
1135
+ minting that identifier (2026-08-20, objectui#5127), so the structural key is the
1136
+ only marker. Because the matching was host-based rather than literal, that arm
1137
+ can be added later without invalidating a single file.
1138
+
1139
+ ### Patch Changes
1140
+
1141
+ - 64563a9: **BREAKING (node type key):** `@object-ui/plugin-map` no longer registers the bare
1142
+ `map` node type key, and its namespaced twin `view:map` goes with it. A node
1143
+ authored `"type": "map"` no longer resolves a renderer. Write
1144
+ `"type": "object-map"` — the one spelling the plugin serves (objectui#10393,
1145
+ executing the objectui#8008 family ruling of 2026-09-09 that retired the bare
1146
+ `gantt` and `kanban` keys).
1147
+
1148
+ **Why.** The registry mounted a `map` node while the published declaration refused
1149
+ it: `ObjectMapSchema.type` is the literal `'object-map'` and `AnyComponentSchema`
1150
+ has no `map` arm, so `safeValidateSchema` answered a `map` node with
1151
+ `invalid_union` while the html tier accepted it. Two faces, opposite verdicts.
1152
+ No schema face ever declared `map` as a component node type, so there is no arm
1153
+ to turn into a named refusal: unregistering is the whole retirement, exactly as
1154
+ it was for `gantt`. After it, the html tier (`validateTree` over the live
1155
+ registry) reports a `map` node as `unknown-component`, matching the Zod face.
1156
+
1157
+ **⛔ No stored document moves.** The string `map` names two different things at
1158
+ two different layers, and only one of them is retiring:
1159
+
1160
+ | layer | value | who writes it | retired? |
1161
+ | --- | --- | --- | --- |
1162
+ | stored `NamedListView.type` / `defaultViewType` | `"map"` | `CreateViewDialog`, persisted per tenant | **no — untouched** |
1163
+ | node type key | `map`, `view:map` | hand-authored JSON | **yes** |
1164
+
1165
+ `ObjectView` and `ListView` map a stored `map` view onto the node type they
1166
+ render, and both already emit `object-map`, so every map view created through
1167
+ the console keeps rendering. Nothing in a tenant database changes, and ⛔ nothing
1168
+ should be migrated there.
1169
+
1170
+ **What moved with it.**
1171
+
1172
+ - `@object-ui/console` drops its lazy `map` / `view:map` registration stub; the
1173
+ lazy `object-map` stub is unchanged.
1174
+ - `@object-ui/core`: `recordSourceDataArmForType` no longer lists the `map` and
1175
+ `view:map` rows, since no block is registered under either key.
1176
+ - `@object-ui/cli`: the generated known-type list that `objectui check` reads no
1177
+ longer contains bare `map`, so the check now reports `map` as an unknown
1178
+ schema type in a file it recognises. ⚠️ `view:map` stays on
1179
+ that list, because the opt-in protocol placeholder (`registerPlaceholders()`
1180
+ in `@object-ui/components`) registers it — in the console a `view:map` node
1181
+ renders that placeholder panel, not a map, and `objectui check` does not report
1182
+ it as an unknown schema type in a file it recognises. A bare
1183
+ `{ "type": "view:map" }` with no structural key is listed in `check`'s advisory
1184
+ did-not-validate list instead, because `view:map` is on the known-type list and
1185
+ `AnyComponentSchema` has no arm for it; that line does not say the node renders
1186
+ a placeholder. Search documents for `view:map` directly.
1187
+
1188
+ ⚠️ **Dated note, 2026-09-25 — `objectui check` flags `map` only in a file it
1189
+ recognises — objectui#10606.** This entry first said, unscoped, that the check now
1190
+ flags bare `map`. `check` checks the `type` of each file it recognises, and a file
1191
+ whose root carries an ObjectUI structural key (`children`, `className`, `body`, …)
1192
+ is recognised by that key alone. A file with none of those keys is parsed against
1193
+ the schema and recognised only if it validates; one that does not validate is
1194
+ listed by name when its root `type` is on that known-type list, and is otherwise
1195
+ counted as skipped. `map` is no longer on it, so `{ "type": "map" }` is
1196
+ counted as skipped ("no ObjectUI recogniser admitted") and gets no unknown-type
1197
+ line, while `{ "type": "map", "className": "h-64" }` gets one. `check` exits
1198
+ non-zero on unreadable JSON only; the verdict is `objectui validate`'s: it refuses
1199
+ `{ "type": "map" }` at `type` (`invalid_union`) and exits non-zero.
1200
+
1201
+ The `@object-ui/plugin-map` README now describes one registered type, and its
1202
+ sentence claiming a bare array under `data` reaches the in-memory adapter is
1203
+ corrected: a bare array under `data` is not a record source on the map
1204
+ (objectui#8348), so inline rows belong under `staticData`. The same false claim
1205
+ is corrected on the two docs pages that carried it, `plugins/plugin-map.mdx`
1206
+ and `fields/location.mdx`.
1207
+
1208
+ **One pending entry in this same release is superseded in part.** The
1209
+ objectui#10392 / #10394 entry (`10392-registration-record-source-inputs.md`)
1210
+ says `object-map`, `map` and `object-gantt` gained `data` / `staticData`
1211
+ inputs. It now reads as of its own change and carries a dated note naming this
1212
+ card: `map` declares nothing after this retirement, while `object-map` and
1213
+ `object-gantt` keep both inputs.
1214
+ - c2d8659: `objectui check`'s help line and six `@object-ui/types` comments no longer present `check` as a
1215
+ validator (objectui#10524).
1216
+
1217
+ - `@object-ui/cli`: `objectui --help` and `objectui check --help` described `check` as
1218
+ "Validate schema files". It now reads "Advisory JSON file sweep; run objectui validate for a
1219
+ verdict". `check` itself is unchanged. It sweeps the project's JSON files and recognises a
1220
+ file whose root carries a structural key (`children`, `className`, `body`, …) by that key
1221
+ alone, without parsing it against the schema. It parses against the schema only a file with
1222
+ none of those keys, and lists it by name when its root `type` names a registered component but
1223
+ the document does not validate. That list is advisory: `check` exits non-zero on unreadable
1224
+ JSON only. The verdict is `objectui validate`'s: it parses one document against the published
1225
+ schema, prints the schema's own errors and exits non-zero.
1226
+ - `@object-ui/types`: the `ChatbotSchema.body` docblock said the retired key's refusal comes from
1227
+ "a root parse (`objectui validate` / `objectui check`, …)". `body` is itself one of the
1228
+ structural keys, so `check` never parses a `chatbot` document that authors it against the
1229
+ schema. The docblock now names `objectui validate` alone and says why `check` does not deliver
1230
+ the refusal. The two
1231
+ `SemanticElementSchema` docblocks (the interface and its zod mirror) said a document was
1232
+ refused by `objectui check`; they now name `objectui validate`, whose refusal it was. The
1233
+ `ObjectGanttSchema.gantt` comments (the interface and its zod mirror) and the
1234
+ `ObjectCalendarSchema` `sort` comment in the zod mirror said the refusal reaches the CLI's
1235
+ `validate` / `check`; they now name `validate` alone.
1236
+
1237
+ A help string and comments only: no command's behaviour, export, type or schema moves.
1238
+ - 24d3e65: New SDUI widget `cloud:plan-status`: a "Current plan" badge for one plan card on the Cloud pricing page, shown when that card's plan is the organization's plan (objectui#10919).
1239
+
1240
+ **Clause-②: yes** — the accept set of `AnyComponentSchema`, and so of `safeValidateSchema` and `objectui validate`, widens by one `type` literal, `cloud:plan-status`, and `@object-ui/types/zod` exports one new schema, `CloudPlanStatusSchema`. Nothing that parsed before is refused now.
1241
+
1242
+ **Why.** The pricing page is static metadata, and nothing in a page's expression scope carries the organization's plan, so the page could not tell which of its cards the organization is already on. The plan is available only from the org-scoped `GET /cloud/environment-entitlements` summary.
1243
+
1244
+ **What changed, in observable terms.**
1245
+
1246
+ - `@object-ui/app-shell` registers `cloud:plan-status`. A page places one node on each plan card and names that card's plan code in `properties.plan`: `{ "type": "cloud:plan-status", "properties": { "plan": "free" } }`. The widget reads the summary through the hook the environment list already uses, and renders the badge when the summary's `plan` equals `properties.plan`. The comparison is exact, so `Free` does not match `free`.
1247
+ - The widget renders nothing on every other card, while the summary loads, when the request fails, and when the body is not the `{ success, data }` envelope. It never guesses a plan.
1248
+ - The node's `className` and `responsiveStyles` reach the badge. Each node reads the summary itself, so a page with three cards makes three requests.
1249
+ - The widget is registered under one key, `cloud:plan-status`. There is no bare `plan-status` fallback and no `app-shell:`-prefixed twin.
1250
+ - `@object-ui/types/zod` exports `CloudPlanStatusSchema`, a member of `AnyComponentSchema`. `properties` is required and must be exactly `{ plan }`, with `plan` a non-empty string. A missing bag, a missing or empty `plan`, and any other key in the bag are each refused at that path.
1251
+ - `body` and `children` are refused by name on this node, because the widget reads neither.
1252
+ - `plan` is not an enum: the plan catalog belongs to the control plane, and ObjectUI does not list its codes.
1253
+ - `@object-ui/i18n` adds `cloudPlanStatus.current` ("Current plan") to all ten locale packs.
1254
+ - `@object-ui/cli`: `objectui check` knows `cloud:plan-status` as a registered type.
1255
+ - 37a19d4: `objectui check` prints the key and path a file was refused for, and no longer ends with 「✓ All checks passed」 over files it never validated (objectui#11007).
1256
+
1257
+ `check` recognises a JSON file in one of two ways: by a structural root key (`children`,
1258
+ `className`, …), which admits the file without parsing it, or by the whole document
1259
+ validating.
1260
+
1261
+ - **A file that did not validate now carries its reason.** Each entry in the "did not validate"
1262
+ list gets one indented line: the validator's first issue, its path spelled the way
1263
+ `objectui validate` prints it, and its message, with the issue count when there is more than
1264
+ one. A root `object-map` whose `map` block carries the typo `latitudeFieId` was listed by file
1265
+ and type only. It now reads `Issue at map: Unrecognized key: "latitudeFieId"`. The issue comes
1266
+ from the parse `check` already ran to recognise the file. Skipped files, which are foreign,
1267
+ still get no diagnosis.
1268
+ - **The closing line is a tally, not a pass.** A run with no parse errors used to end on
1269
+ 「✓ All checks passed」, including over a page whose nested node carries a refused key: that
1270
+ page is admitted on `children` and never parsed. The line now counts the recognised files
1271
+ that validated, those recognised by a structural key and not validated, and those that did
1272
+ not validate, and points to `objectui validate <file>` for a verdict.
1273
+
1274
+ `check` still does not parse a file its structural key admits. The verdict on a document stays
1275
+ `objectui validate`'s, and `check` still exits non-zero on unreadable JSON only, so no exit code
1276
+ changes. `objectui validate`'s output is unchanged: its path spelling moved into a helper both
1277
+ commands share.
1278
+ - 3c3ce15: Small reader sites stop riding `BaseSchema`'s index signature (objectui#11355, part of the preparation for objectui#8347's removal of that signature). Each key was measured on its own.
1279
+
1280
+ **Two keys are now declared, each with a spec row's type, by reference.**
1281
+
1282
+ - `ObjectKanbanSchema.swimlaneField`. The installed `@objectstack/spec` declares it on the `object-kanban` row as an optional string, `ObjectKanban` reads it, and the registration publishes it as an input. The TypeScript member takes the row's type, and the zod mirror now refuses a non-string `swimlaneField` where `.passthrough()` used to keep it unjudged. `grouping`, the read's fallback, is still undeclared; aligning it with the spec's typed row is objectui#11216.
1283
+ - `DetailViewSchema.showHeader`. `detail-view` has no spec row. `DetailView` reads the key, and its producer is `record:details`, which writes its own spec-declared `showHeader` onto the `detail-view` node it builds. So the member takes the `record:details` row's type, and the two cannot drift apart. The zod mirror declares it too. The defaults are unchanged: a bare `detail-view` draws its heading unless `showHeader` is `false`, and `record:details` keeps its own default of off.
1284
+
1285
+ **Two reads are typed where they stand, with no behaviour change.**
1286
+
1287
+ - `@object-ui/cli`: `objectui validate` reads a parsed node's `title` only where the node carries one. The read used to span every arm of the parsed union. The printed output is unchanged.
1288
+ - `@object-ui/plugin-map`: the dev warning about flat map keys that a `map` block shadows reads those keys through their own type, not through a `Record` conversion.
1289
+
1290
+ **minor, not patch, for `@object-ui/types`.** Both members are new in the shipped `.d.ts` and in the zod mirror's `.shape`, and the mirror now refuses a wrongly typed value for each, where it used to keep one unjudged.
1291
+
1292
+ ⚠️ **Dated note, 2026-10-03 — `ObjectKanbanSchema.grouping` is now declared — objectui#11216.**
1293
+ At this change `grouping`, the fallback `ObjectKanban` reads for `swimlaneField`,
1294
+ was undeclared on both faces, as the first bullet above says. objectui#11216
1295
+ declares it on both faces in this release, by reference: the TypeScript member is
1296
+ the spec's `GroupingConfig`, and the zod mirror takes the spec's
1297
+ `GroupingConfigSchema`, the type the `object-kanban` row gives the key. So the
1298
+ sentence above that calls `grouping` "still undeclared" does not hold in this
1299
+ release. The rest of this entry is kept as the reading of this change.
1300
+ - 5429e6c: `objectui generate page NAME` writes a page that draws its title (objectui#11450).
1301
+
1302
+ The generated `pages/NAME.json` had a `title` and no `pageType`. A page with no `pageType` is a `record` page, and a record page draws neither `title` nor `description`: it leaves its `h1` to a `page:header` block. So the generated title never showed. The generator now writes `"pageType": "app"`, which draws `title` as the page's `h1`.
1303
+
1304
+ The markdown child under it now reads `Welcome to NAME` instead of `# Welcome to NAME`. With the title drawn, a `#` heading in the markdown would draw a second `h1` beneath it. A page you generated before this release keeps its old shape; add `"pageType": "app"` to it, and drop the `# ` from its markdown, to get the same result.
1305
+ - 05474af: Fix `objectui check` scanning build output because its ignore list only excluded a
1306
+ root-level `dist/` / `node_modules/` (objectui#6320).
1307
+
1308
+ `packages/cli/src/commands/check.ts` passed `ignore: ['node_modules/**', 'dist/**',
1309
+ '.git/**']` to `globSync`. `glob` matches `ignore` patterns against the path relative to
1310
+ `cwd`, so an unanchored `dist/**` / `node_modules/**` excludes only a directory of that
1311
+ name at the scan root — every nested `packages/<name>/dist/`, `examples/<name>/dist/`,
1312
+ `apps/<name>/dist/` (and their `node_modules/`) was still scanned. In a built workspace
1313
+ this means `objectui check` re-reads the author's own schemas a second time from build
1314
+ output, roughly doubling every count it reports (measured on this repository: 617 → 1047
1315
+ files globbed after a full build) with nothing in the output explaining why.
1316
+
1317
+ The ignore patterns are now anchored at every depth (`'**/dist/**'`, `'**/node_modules/**'`),
1318
+ matching the fix's stated intent: exclude build output and installed dependencies wherever
1319
+ they live, not only at the project root. A root-level `dist/` / `node_modules/` remains
1320
+ excluded, unchanged.
1321
+
1322
+ Confirmed before widening: no example, template, or docs fixture in this repository
1323
+ authors a schema under a directory literally named `dist` — the widened pattern excludes
1324
+ only generated content.
1325
+ - 854222c: `@object-ui/plugin-report` now registers its three components under namespace
1326
+ **`plugin-report`**, the spelling its consumers already declare (objectui#6416).
1327
+
1328
+ It used to register `report`, `spec-report` and `report-viewer` under namespace
1329
+ `report`, while `apps/console` declared the lazy stubs for the same three short
1330
+ names under `plugin-report` and the CLI's known-type whitelist shipped the
1331
+ `plugin-report:*` spellings as renderable. Two things followed from the
1332
+ disagreement:
1333
+
1334
+ - **`plugin-report:report`, `plugin-report:report-viewer` and
1335
+ `plugin-report:spec-report` could never be satisfied.** `Registry.register`
1336
+ clears the lazy stub for the type IT registers, and that type was
1337
+ `report:report`, so those three stubs were never cleared and no component was
1338
+ ever stored under them: `get('report', 'plugin-report')` returned `undefined`
1339
+ and `hasLazy('report', 'plugin-report')` stayed `true` forever. A schema
1340
+ authored with any of the three whitelisted keys resolved to nothing — the
1341
+ gate handed authors a green light for a key the runtime could not satisfy.
1342
+ - **The bare `report` key was claimed twice under two different namespaces.**
1343
+ `Registry.register` and `Registry.registerLazy` share the
1344
+ `meta?.namespace && !meta?.skipFallback` branch, so what bare `report`
1345
+ *declared* depended on whether the plugin chunk had loaded yet — the
1346
+ objectui#6353 shape.
1347
+
1348
+ **No authored metadata changes.** The direction was chosen by measurement:
1349
+ nothing in this repository, and nothing in the sibling `objectstack` checkout,
1350
+ authors a `report:*` spelling (0 hits), while the bare spellings are authored in
1351
+ 48 places. `type: 'report'`, `type: 'spec-report'` and `type: 'report-viewer'`
1352
+ resolve exactly as before; the three unreachable `report:*` keys are retired and
1353
+ the three `plugin-report:*` keys now name real components for the first time.
1354
+
1355
+ `packages/cli/src/utils/known-schema-types.ts` is regenerated from the
1356
+ registrations, dropping `report:report`, `report:report-viewer` and
1357
+ `report:spec-report`.
1358
+
1359
+ Two pins are the half that outlives the fix:
1360
+ `packages/plugin-report/src/__tests__/report-bare-key-ownership.test.ts` replays
1361
+ this package's real declared metadata and a console-shaped lazy stub into a
1362
+ fresh `Registry` in **both** registration orders, checking the bare key's
1363
+ declared namespace after every step, so order- and phase-independence are
1364
+ properties under test rather than properties of the file the test imports.
1365
+ `scripts/__tests__/report-namespace-agreement-6416.test.ts` re-derives both
1366
+ sites from source and fails if the plugin, the console stubs and the generated
1367
+ whitelist ever disagree again.
1368
+
1369
+ ⚠️ **Dated note, 2026-10-02 — `spec-report` is retired — objectui#11440.**
1370
+ Later in this same release `@object-ui/plugin-report` stopped registering `spec-report`, and with it
1371
+ `plugin-report:spec-report`; the console dropped its lazy stub, and `known-schema-types.ts` no longer
1372
+ lists either key. So the package registers two components under `plugin-report`, not three, and
1373
+ "`type: 'spec-report'` … resolve exactly as before" and "the three `plugin-report:*` keys now name
1374
+ real components" above no longer hold for `spec-report`: a node of that type resolves to nothing.
1375
+ `report` and `report-viewer` resolve as this entry says. `.changeset/11440-retire-spec-report.md`
1376
+ states what ships. The rest of this entry is kept as the reading of this change.
1377
+ - 85b4957: `objectui validate` now says when a validation issue sits at the document root.
1378
+
1379
+ The printer guarded its Path line with `issue.path.length > 0`, so an issue at
1380
+ `path: []` printed no Path line at all — silent in exactly the case a reader
1381
+ most needs oriented. That case is the common one, not an edge: the CLI validates
1382
+ against `AnyComponentSchema`, a union over every component arm, so any document
1383
+ matching no arm reports a single top-level issue (`invalid_union` · `Invalid
1384
+ input` · root path). Authors saw a bare verdict on a whole document with nothing
1385
+ saying which node had been judged:
1386
+
1387
+ ```
1388
+ 1. Invalid input
1389
+ Code: invalid_union
1390
+ ```
1391
+
1392
+ Every reported issue now carries a Path line; a root-level one reads
1393
+ `Path: (root)`, parenthesised so it cannot be mistaken for a real key named
1394
+ `root`. Non-root issues print their authored path exactly as before.
1395
+
1396
+ Scope: the printer still reads only top-level issues. Whether a failing union
1397
+ should also surface its per-arm diagnoses — and if so which arm's — is an
1398
+ author-facing diagnostic contract left open for a maintainer
1399
+ ruling, and is deliberately not decided here.
1400
+ - 639114c: Reconcile the declared surface with `@objectstack/spec` 17.3.0 (objectui#7122).
1401
+
1402
+ ⚠️ **`@object-ui/types` is graded `minor` for a breaking surface change.**
1403
+ The exported `ObjectSchemaClientExtensions` narrows from
1404
+
1405
+ ```ts
1406
+ export interface ObjectSchemaClientExtensions { editMode?: 'modal' | 'page' }
1407
+ ```
1408
+
1409
+ to
1410
+
1411
+ ```ts
1412
+ export type ObjectSchemaClientExtensions = Record<never, never>;
1413
+ ```
1414
+
1415
+ Two breaking consequences for a consumer that names the type directly. **(1)** It
1416
+ no longer declares `editMode`; the key is now carried by the spec's
1417
+ `ServiceObject`, so `ObjectSchemaMetadata` still has it, but code written against
1418
+ the extension type ALONE loses it. **(2)** `interface` → type alias also ends
1419
+ **declaration merging**: a consumer that reopened
1420
+ `declare module '@object-ui/types' { interface ObjectSchemaClientExtensions { … } }`
1421
+ to add its own client-side member no longer compiles, because an alias cannot be
1422
+ reopened. `minor` rather than `major` per `AGENTS.md`'s version-alignment rule —
1423
+ objectui's own breaking changes are graded `minor` with the semantics stated in
1424
+ the body, since any `major` in the fixed group would push all 39 packages off
1425
+ `@objectstack`'s major.
1426
+
1427
+ **`ObjectSchema.editMode` is now the spec's.** 17.3.0 adopted the key (measured:
1428
+ the accept set went 42 → 43, gained set exactly `['editMode']`, lost set empty,
1429
+ declared as the same `'page' | 'modal'` union objectui carried). Its local copy
1430
+ is retired from `ObjectSchemaClientExtensions`, which is what that type's own pin
1431
+ prescribed for this event, leaving the client delta empty. Nothing is removed
1432
+ from the product: `editMode` stays authorable and stays typed on
1433
+ `ObjectSchemaMetadata`, carried by the spec's `ServiceObject` instead of by a
1434
+ local member — and a published, spec-validated object document may now carry it,
1435
+ which at 17.2.0 was refused by name.
1436
+
1437
+ **`user:profile` is retired across all three sites.** 17.3.0 dropped it from
1438
+ `PageComponentType` (measured: the enum went 34 → 32 options, lost set exactly
1439
+ `['user:profile', 'element:form']`, gained set empty). objectui went on knowing
1440
+ it in three places, so all three moved together: the Studio palette exclusion
1441
+ ledger, `PROTOCOL_COMPONENTS` in `renderers/placeholders.tsx`, and the
1442
+ regenerated `known-schema-types.ts` the CLI checks schemas against. Nothing
1443
+ user-reachable went with it — neither type had a renderer, `user:profile` had
1444
+ only the dashed "Component Placeholder" scaffold, and the app shell's own
1445
+ profile affordance is a React slot, never this block type. A page schema still
1446
+ naming it now draws the loud "Unknown component type" panel rather than a silent
1447
+ grey box, which is this repo's standing treatment for a type outside the
1448
+ supported surface.
1449
+
1450
+ **`record:details` sections document the eight keys 17.3.0 added.**
1451
+ `group`, `hideEmpty`, `collapsible`, `showBorder`, `defaultCollapsed`, `icon`,
1452
+ `description` and `headerColor` are now declared on a section entry (4 → 12
1453
+ members). Six of the eight are already honoured by `DetailSection`, so the
1454
+ `sections` input description now teaches all of them, and says plainly which two
1455
+ are not read here. Designer controls for them are a separate feature and are
1456
+ deliberately not added.
1457
+
1458
+ **`@object-ui/types` raises its declared `@objectstack/spec` floor `^17.0.0` →
1459
+ `^17.3.0`, and this is the second half of its `minor`.** The package's emitted
1460
+ `dist/spec-report.d.ts` names `FilterCondition` from `@objectstack/spec`, which
1461
+ `17.0.0` does not export, so the old range was a claim the artifact did not
1462
+ support — `scripts/check-spec-range-floors.mjs` reports it as `[floor-too-low]`
1463
+ and names `^17.3.0` as the lowest version carrying every symbol the package
1464
+ references. Breaking for a consumer pinned below 17.3.0: it can no longer
1465
+ resolve this package. That is the range stating the truth rather than a new
1466
+ restriction — the artifact already required those symbols — and it is the
1467
+ remedy the gate itself prescribes ("Raise that package's range to the lowest
1468
+ version that exports the symbol… Do not add a tolerant re-declaration on this
1469
+ side: the range is the claim, and the claim is what is wrong", `111741454`).
1470
+ `@object-ui/core` and `@object-ui/data-objectstack` already declare `^17.2.0`
1471
+ and `@object-ui/plugin-detail` `^17.1.0`, so a floor above the family minimum is
1472
+ this repo's normal state, not an exception.
1473
+
1474
+ ⚠️ **Measured on both sides, because it is bump-caused rather than pre-existing
1475
+ and the card that filed the `[floor-too-low]` finding recorded the opposite.** The gate is a scheduled / push-to-main
1476
+ workflow that cannot red a pull request, and `main` is green on it — the last
1477
+ eight runs, most recently at `c2e3cee2c`. On this branch's built tree it exits 1
1478
+ with CI's own `--cross-check` invocation, and exits 0 with this raise, judging
1479
+ 278 (subpath, symbol) pairs across 19 published packages either way. Its blocking
1480
+ copy runs on the publish path, so leaving it would have surfaced as a cancelled
1481
+ release rather than as a red check. The correction is recorded in `639114c4d`, the commit that landed this entry.
1482
+ - fb4ec65: Route the generated app layout's icon lookup through the platform seam (objectui#7472).
1483
+
1484
+ `objectui dev`/`init` emit a `src/Layout.tsx` into the user's application, and that
1485
+ template carried its own lucide resolver: `import * as LucideIcons from 'lucide-react'`
1486
+ feeding `lucideIcons[name]`, with **zero** normalisation. It was the last container in
1487
+ the platform still resolving icon names for itself, which objectui#5935's ruling
1488
+ forbids — and because the file is generated, the vocabulary it accepted became an
1489
+ authoring contract that held inside a generated app and nowhere else.
1490
+
1491
+ The layout now imports `LazyIcon` and `isLucideIconName` from `@object-ui/components`
1492
+ (already one of its declared dependencies, so nothing new is installed) and asks the
1493
+ predicate first, preserving the old "render no glyph for an unresolvable name"
1494
+ behaviour rather than falling back to the seam's stray database icon. The four
1495
+ statically-referenced icons move from the namespace object to named imports, so the
1496
+ wildcard import — the pattern that used to pull ~1500 icons into a bundle — is gone
1497
+ from generated apps entirely.
1498
+
1499
+ **Migration, measured rather than assumed.** Icon names are now normalised, so the
1500
+ accepted vocabulary changes in both directions:
1501
+
1502
+ - Canonical `PascalCase` names (`Flame`, `House`, `ChevronsUpDown`) keep working —
1503
+ converting exactly those is what the seam's tokeniser is for. 1,882 of them.
1504
+ - `kebab-case` names now work too. Every other container in the platform already
1505
+ accepted them; a generated app silently rendered nothing. 2,039 names gained.
1506
+ - lucide's **alias** spellings no longer resolve: the `HouseIcon` suffix form (2,037),
1507
+ the `LucideHouse` prefix form (2,036), and digit-suffixed spellings such as
1508
+ `Building2` (147). These were never `icons` keys, so they resolved only inside a
1509
+ generated app. An `app.json` using one should switch to the canonical spelling —
1510
+ `House`, or `building-2`.
1511
+ - adf5812: Four node type keys retire, and the kanban and gantt families converge on their
1512
+ `object-*` spellings: `kanban` (objectui#8802), `kanban-ui` and `kanban-enhanced`
1513
+ (objectui#8257), and `gantt` (objectui#8008). All four were ruled by the
1514
+ maintainer in one batch on 2026-09-09.
1515
+
1516
+ **⛔ No stored document moves.** The strings `kanban` and `gantt` name two
1517
+ different things at two different layers, and only one of them is retiring:
1518
+
1519
+ | layer | value | who writes it | retired? |
1520
+ | --- | --- | --- | --- |
1521
+ | stored `NamedListView.type` | `"kanban"`, `"gantt"` | `CreateViewDialog`, persisted per tenant | **no — untouched** |
1522
+ | node type key | `kanban`, `gantt` | hand-authored JSON | **yes** |
1523
+
1524
+ `ObjectView`'s `switch (viewType)` maps a stored view type onto the node type it
1525
+ renders, and it already emitted `object-kanban` and `object-gantt` — as it does
1526
+ for all twelve stored view types. So every kanban and gantt view any user ever
1527
+ created through the console already renders through the surviving spelling.
1528
+ Nothing in a tenant database changes, and ⛔ nothing should be migrated there.
1529
+
1530
+ **What each retirement was, measured.** Three of the four were
1531
+ registration-only: no schema face in `@object-ui/types` ever declared
1532
+ `kanban-ui`, `kanban-enhanced` or `gantt` as a component node type, so
1533
+ unregistering is the whole retirement. The bare `kanban` key was the exception —
1534
+ it had a declared arm on both faces (`KanbanSchema` in `complex.ts` and its Zod
1535
+ mirror), and a plain deletion there would have been the objectui#7664 failure:
1536
+ `BaseSchema` is `.passthrough()`, so a document naming a dropped key validates
1537
+ green and renders nothing. It therefore retires as a **named refusal**: the Zod
1538
+ union keeps an arm claiming the literal and answers a `{ "type": "kanban" }`
1539
+ document with a message naming `object-kanban` as the remedy, while the
1540
+ TypeScript half is the absence of the arm from `ComplexSchema` and of the key
1541
+ from `SchemaRegistry`, so `tsc` refuses it at the authoring site.
1542
+
1543
+ **⭐ This closes objectui#8818's `objectFields` hole — for that ENTRY, not for
1544
+ the class.** `SchemaRenderer` strips a fixed enumerated metadata list and
1545
+ spreads the rest as React props; `objectFields` is not on that list, and
1546
+ `KanbanRenderer` — the component the `kanban-ui` key resolved to — declares
1547
+ `objectFields` as a real prop, so an authored value reached the predicate layer
1548
+ with no schema face judging it. With the registration gone, no authored node
1549
+ reaches that component through the registry. ⚠️ The **class** is still open: the
1550
+ hole returns the moment another registered renderer declares an `objectFields`
1551
+ prop. objectui#8818's option (a) — stripping at the `SchemaRenderer` boundary —
1552
+ is what would close the class.
1553
+
1554
+ Superseded in this release by objectui#8818: option (a) landed, so the class
1555
+ is closed as well. `objectFields` is now on `SchemaRenderer`'s stripped-metadata
1556
+ list, and the legacy `props` alias bag drops it too, so an authored
1557
+ `objectFields` reaches no component prop on any type key. The paragraph above
1558
+ describes the tree this entry was written against.
1559
+
1560
+ **⚠️ What the `kanban` arm took with it, stated because it is the cost of this
1561
+ change.** That arm was the only schema face that ever declared `columns`,
1562
+ `cardTitle`, `swimlaneField`, `grouping` and `navigation`, the only one that
1563
+ refused `allowCollapse` / `cardTemplates` / `columnWidths` / `titleField` /
1564
+ `draggable` / `onColumnAdd` / `onCardAdd` by name, and — through
1565
+ `columns: KanbanColumn[]` — the only one that judged a lane's `cards`
1566
+ (`240b80f31`).
1567
+
1568
+ ⭐ **The sentence that stood here — «The surviving `ObjectKanbanSchema` face
1569
+ declares none of them» — is retired, and the two reasons it failed are DIFFERENT
1570
+ defects (objectui#9713).** It is replaced by a dated reading rather than silently
1571
+ overwritten, because half of it was true when written and erasing that would be a
1572
+ false record of its own:
1573
+
1574
+ | key named just above | on `ObjectKanbanSchema` when this entry was written (`adf581278`, 2026-09-10) | on `main`, 2026-09-17 | what moved |
1575
+ | --- | --- | --- | --- |
1576
+ | `columns` | not declared | **declared** | objectui#8913 (PR objectui#8989), six hours after this entry was written |
1577
+ | `cardTitle` | not declared | **declared** | objectui#9606 (PR objectui#9709) |
1578
+ | `titleField` | **declared** | **declared** | nothing — the sentence was never true of this key |
1579
+ | `allowCollapse` | **declared**, a live `z.boolean().optional()` | **declared**, as a `retirementTombstone()` | objectui#8801 retired it; it was declared on this face throughout |
1580
+ | `swimlaneField`, `grouping`, `navigation`, `cardTemplates`, `columnWidths`, `draggable`, `onColumnAdd`, `onCardAdd`, and a lane's `cards` | not declared | not declared | nothing |
1581
+
1582
+ ⇒ For `columns` and `cardTitle` the claim **ROTTED**: it was true on 2026-09-10 and
1583
+ was falsified afterwards by cards that had no reason to read this file. For
1584
+ `titleField` and `allowCollapse` it was **BORN FALSE**: those two are named above as
1585
+ keys the `kanban` arm refused BY NAME — which the surviving face indeed does not do
1586
+ — but the surviving face declared both of them the whole time, and «declares none of
1587
+ them» said otherwise. ⛔ Do not restate any of this in the present tense: a pending
1588
+ entry publishes verbatim into the CHANGELOG, and an undated present-tense claim
1589
+ about another file is the construction that failed here.
1590
+
1591
+ ⛔ Nothing about an `object-kanban` document changes: it was never judged by the
1592
+ `kanban` arm, so all of those keys have always ridden `BaseSchema`'s index
1593
+ signature there. What is gone is the `kanban` document that had them. Declaring
1594
+ them on `ObjectKanbanSchema` would WIDEN a published accept set, which is a
1595
+ maintainer ruling and not part of this one; every one of these readings is
1596
+ pinned where it can be seen rather than left to be rediscovered.
1597
+
1598
+ **Migrating.** Replace `"type": "kanban"` with `"type": "object-kanban"` and
1599
+ `"type": "gantt"` with `"type": "object-gantt"` in hand-authored documents. The
1600
+ `object-kanban` face requires `groupBy` and one of `bind` / `data` /
1601
+ `objectName`; a purely static board (lanes carrying their own cards, no record
1602
+ source) adds `"groupBy"` and `"data": []`. `kanban-ui` and `kanban-enhanced`
1603
+ have no authored documents anywhere in this repository to migrate.
1604
+
1605
+ **⚠️ The namespaced spellings retire with the registrations — `view:kanban` and
1606
+ `view:gantt` are the same two keys.** `ComponentRegistry.register(type, C,
1607
+ { namespace })` stores BOTH `namespace:type` and a bare-`type` fallback, so
1608
+ every one of these keys had a namespaced twin that goes with it:
1609
+
1610
+ | retired spelling | namespaced twin | author instead |
1611
+ | --- | --- | --- |
1612
+ | `kanban` | `view:kanban` | `object-kanban` |
1613
+ | `gantt` | `view:gantt` | `object-gantt` |
1614
+ | `kanban-ui` | `plugin-kanban:kanban-ui` | `object-kanban` |
1615
+ | `kanban-enhanced` | `plugin-kanban:kanban-enhanced` | `object-kanban` |
1616
+
1617
+ Both spellings are pinned as gone, each against a firing control on the
1618
+ surviving key, in `plugin-kanban/src/__tests__/kanban-family-registry-keys-retired-8257.test.ts`
1619
+ and `plugin-gantt/src/__tests__/bare-gantt-node-key-retired-8008.test.ts`.
1620
+
1621
+ **What an unmigrated `view:kanban` / `view:gantt` node now renders depends on
1622
+ the host.** In `apps/console` it renders the protocol **placeholder** panel, not
1623
+ the OBJUI-001 "Unknown component type" error: the console calls the opt-in
1624
+ `registerPlaceholders()` (`@object-ui/components`, `renderers/placeholders.tsx`)
1625
+ *after* its plugin registrations, `view:kanban` and `view:gantt` are both in
1626
+ that file's `PROTOCOL_COMPONENTS` list, and the placeholder only claims a key
1627
+ nothing else has taken — which, until this change, `@object-ui/plugin-kanban`
1628
+ and `@object-ui/plugin-gantt` had. In every other host, which does not call that
1629
+ bootstrap, the same node renders OBJUI-001.
1630
+
1631
+ **⚠️ `objectui check` will NOT flag either namespaced spelling.** The CLI's
1632
+ `known-schema-types.ts` is generated from the repository's real registration
1633
+ calls, and the placeholder registration is a real one — so `view:kanban` and
1634
+ `view:gantt` are still on that list and still validate green, while the node
1635
+ renders a placeholder rather than a board. The bare `kanban` / `gantt` entries
1636
+ DID leave the generated list; only the namespaced pair survives, and only
1637
+ because of the placeholder. Grep your documents for the namespaced spellings
1638
+ directly; do not rely on `objectui check` to find them.
1639
+
1640
+ `KanbanRenderer` is still exported from this package's entry point
1641
+ (`@object-ui/plugin-kanban`); only its registry key is gone. ⚠️ `KanbanEnhanced`
1642
+ is a different case, and the earlier draft of this note stated it wrongly: this
1643
+ package's `exports` map has exactly two entries — `.` and `./style.css` — and
1644
+ the barrel never re-exported the component, so
1645
+ `@object-ui/plugin-kanban/KanbanEnhanced` has never been a resolvable specifier
1646
+ for a consumer. At this change, with `kanban-enhanced` unregistered,
1647
+ `KanbanEnhanced.tsx` had zero non-test importers, and the file was deliberately
1648
+ left in place: deleting published-but-unreachable source is a further narrowing
1649
+ and needed its own maintainer ruling, which this change did not have.
1650
+
1651
+ ⚠️ **Dated note, 2026-09-25 — that ruling came, and the file has since been
1652
+ deleted — objectui#8932.** Later in this same release
1653
+ `packages/plugin-kanban/src/KanbanEnhanced.tsx` was deleted, and with it the
1654
+ `dist/KanbanEnhanced.d.ts` typings this package shipped for it. The rest of this
1655
+ entry is kept as the reading of this change; the objectui#8932 entry states what
1656
+ ships.
1657
+
1658
+ **⚠️ `@object-ui/sdui-parser`: `QUICK_ADD_HOST_TYPES` loses `kanban` with the
1659
+ registration.** The `inert-quick-add` diagnostic (objectui#8285) named the two
1660
+ tags `ObjectKanbanRenderer` answered to; one of them retires here, so the set is
1661
+ now `{ 'object-kanban' }`. ⛔ Nothing is silently dropped by that narrowing, and
1662
+ this is measured rather than argued: `checkKanbanQuickAdd` has exactly one call
1663
+ site — `validate.ts`'s per-prop walk — and that walk runs only in the branch
1664
+ where the manifest RESOLVED the tag. A tag no registration produces is answered
1665
+ one level up by `unknown-component`, an **error**, and its props are never
1666
+ walked, so on a manifest built from the live registry a `<kanban quickAdd>` node
1667
+ draws `error/unknown-component` and nothing else, against a firing control on
1668
+ `<object-kanban quickAdd>` that still draws `warning/inert-quick-add`. Keeping
1669
+ `kanban` in the set would have been reachable only through a hand-built manifest
1670
+ declaring a component of that name — which, after this retirement, is somebody
1671
+ else's component, and the message asserts things about `ObjectKanban` that would
1672
+ be false of it. This supersedes the `kanban` half of the objectui#8285 entry.
1673
+
1674
+ **The diagnostic's remedy text moves from a tag to a component.** It used to end
1675
+ "render `<kanban-ui>` from a React host that passes `onQuickAdd`". That sentence
1676
+ is falsified by this change: `kanban-ui` is no longer a node type key, so a page
1677
+ written to the old advice draws `unknown-component`. It now names
1678
+ `KanbanRenderer` from `@object-ui/plugin-kanban` — still exported, still
1679
+ forwarding both halves by identity — which is the surviving way to get the pair.
1680
+ `content/docs/plugins/plugin-kanban.mdx` says the same thing the same way.
1681
+ - 2923cea: Stop `objectui check` reporting five real page types as unknown.
1682
+
1683
+ `ui:page`, `ui:app`, `ui:utility`, `ui:home` and `ui:record` are registry keys the platform stores and the renderer paints, and `objectui check` called every document that spelled one of them an unknown schema type. The list the check judges against is generated from this repository's registration calls, and the generator could not see a `namespace` that arrives through a reference: the page kinds declare their options once and register from that object — one call passing it whole, four spreading it to vary a label — so there is no `namespace:` inside any of those call spans. The derivation read the bare half of each registration, produced no finding, and shipped a list short by exactly the namespaced half.
1684
+
1685
+ The derivation now reads an options object passed by identifier or by top-level spread. It does so from an allowlist of ARGUMENT shapes: an object literal whose top-level entries are all key-value pairs or plain-identifier spreads, or an identifier resolving to one such literal. Every other options ARGUMENT — a cast, a member expression, a call, a spread of any of those, a conditional spread, a computed `namespace` or `skipFallback` — is now reported instead of read as namespace-free, and so is an identifier the derivation declines to follow: one it counts as bound more than once or with `let`, an imported name, or one whose `namespace` or `skipFallback` the file assigns, deletes or `Object.assign`-es in a spelling the guard matches. A validator that refuses what the platform renders is the expensive direction — it teaches authors to stop reading the validator, which costs the opposite direction (a type the check blesses and the runtime rejects) its only reader.
1686
+
1687
+ Within a literal the derivation reads, entries are applied in source order and an entry that sets `namespace` or `skipFallback` replaces what an earlier one set — including a base spread twice around an intervening entry, and including an explicit `skipFallback: false` arriving by spread after an explicit `true`. Both of those were read wrongly, in silence, by the first draft of this change.
1688
+
1689
+ Refusing a name whose options this file is SEEN to write is the sharper half of that, because its failure direction is a phantom rather than a miss. A `let` may hold a different object by the time the call runs, and a `const` cannot be rebound but its `namespace` can be deleted after declaration — either way the derivation would publish a key the runtime never stores, and the check would bless a spelling that renders nothing. A miss refuses something that renders; a phantom green-lights a spelling that renders nothing.
1690
+
1691
+ ⚠️ What the instrument does NOT see is stated rather than implied, because a comment claiming more than the code does is the defect this card was filed about. Two rules bound it, and both are narrower than "the object is not rebound or written":
1692
+
1693
+ - A name counts as a binding only where it IMMEDIATELY follows `const` / `let` / `var`, or sits in an import clause. A function parameter, a destructuring pattern, a later declarator of the same statement and a `catch` binding are invisible to the count, so a module-level object answers while the call passes a different one.
1694
+ - A write counts only in three spellings: an assignment or a `delete` whose target is the name spelled exactly followed by `namespace` / `skipFallback` written out, dotted or in a quoted bracket; or an `Object.assign` whose first argument is that name. A write through an alias, inside a callee, with a computed key, as a destructuring-assignment target, or through `Reflect.set` / `Reflect.deleteProperty` / `Object.defineProperty` / `Object.setPrototypeOf` is invisible.
1695
+
1696
+ Closing either needs scope and aliasing analysis this regex-level derivation does not do, and a regex approximation of those semantics has no finishing line — so the end state chosen for this card is an accurate declaration instead. Every shape above is pinned as a KNOWN GAP reading that asserts today's silent answer, so closing one later fails a test instead of passing unnoticed.
1697
+
1698
+ ⛔ Nothing in this repository is KNOWN to hit one of them, and that is a weaker statement than "none is hit" — the whole point of a silent reading is that a clean run does not rule it out. What is re-derived every run is the size of the population a gap could reach: `counters.metaViaReference`, the number of call sites whose options arrive by reference at all. Today that is five sites in one file, all reading the same declaration, the derivation reports zero findings, and the generated list moved by exactly the five namespaced halves and nothing else.
1699
+
1700
+ The registration calls themselves are unchanged; so is every key that was already derived. Five keys are added to the generated list and none is removed or renamed.
1701
+
1702
+ ⚠️ Read against a census, not a guess: every `ComponentRegistry.register` / `registerLazy` call in the tree was classified by how its options argument arrives, because "are these five all of them?" was explicitly unmeasured when this was filed. ⚠️ That census is about CALL SITES and their arguments; it says nothing about the 132 keys whose namespace comes from a hand-kept indirect table rather than from a call, which is a different population with its own failure mode. The five page kinds were the only registrations losing a namespace this way; the one other site reaching its options by reference registers a third-party plugin's own key and is already declared unresolvable-by-design. `deriveRegistryKeys`' `metaViaReference` counter re-derives that population on every run — the number is not written down anywhere, here included.
1703
+ - 100547e: `objectui validate` now refuses a form field whose widget id names a namespace
1704
+ other than `field:`, matching the verdict `@object-ui/core`'s `validateSchema`
1705
+ has given since objectui#5375 (objectui#5449).
1706
+
1707
+ The CLI reaches `FormFieldSchema` through `safeValidateSchema`, and that schema
1708
+ declared `type` and `widget` as bare optional strings — so a field typed
1709
+ `ui:password` validated clean while the runtime validator rejected the same
1710
+ document with `UNRESOLVABLE_FIELD_WIDGET_NAMESPACE`. The CLI is the surface an
1711
+ author actually runs before shipping, so it was the one handing out the false
1712
+ green: an author did exactly the diligence objectui#5375 asks for and still
1713
+ shipped metadata that renders a secret into a plain text box.
1714
+
1715
+ A `superRefine` on `FormFieldSchema` now states the rule, mirroring core's
1716
+ precedence (`widget` before `type`), the key it blames, its error code and its
1717
+ message verbatim, so the two entry points cannot describe one defect two ways.
1718
+
1719
+ **This rejects documents that previously validated.** Only colon-qualified
1720
+ field widget ids outside the `field:` namespace are affected — `field:`-prefixed
1721
+ ids and bare names such as `password` still pass, registered or not. A field
1722
+ carrying, say, `type: 'ui:password'` must be rewritten as `password` or
1723
+ `field:password`; it never rendered as a password box in any case.
1724
+
1725
+ Which of the repo's authoring-time validators is canonical remains open
1726
+ (objectui#4631) — this states the rule on the zod side rather than unifying
1727
+ them.
1728
+ - fb336df: Move `lucide-react` from `^1.31.0` to `^1.43.0` in every package that declares it, and
1729
+ repair what the jump breaks, so icons resolved from a STRING keep drawing a glyph.
1730
+
1731
+ Measured once against the installed 1.43.0 artifact when this change was made; nothing in
1732
+ the repository re-derives these readings. Across the jump lucide removes no runtime export,
1733
+ no public type name and no `lucide-react/dynamic.mjs` name, and every name this repository
1734
+ imports from `lucide-react` resolves. Exactly one key leaves the runtime `icons` record:
1735
+ `Trash2`, retired in favour of `trash`.
1736
+
1737
+ What a user sees change:
1738
+
1739
+ - Icons the lazy icon seam draws (`resolveIcon`, objectui#9251) get their path data again.
1740
+ lucide 1.43.0 icon modules export their path data inside `__iconData` and no longer
1741
+ export `__iconNode`; the seam now reads both. Reading only `__iconNode` against 1.43.0
1742
+ leaves every such glyph an empty box, with nothing thrown or logged.
1743
+ - `DetailView`'s delete action and three schema-catalog examples spell their icon
1744
+ `trash`, not `trash-2`, so they keep resolving. The glyph is unchanged: 1.43.0's `trash`
1745
+ path data is byte-identical to the `trash-2` path data of 1.31.0 and 1.35.0. Anything
1746
+ that already authored `trash` now draws that same artwork, because lucide moved it under
1747
+ the `trash` name; a few other glyphs were also redrawn upstream.
1748
+ - Icons imported as COMPONENTS carry lucide 1.43.0's own classes: one class per declared
1749
+ alias (a spinner renders `class="lucide lucide-loader-circle lucide-loader-2 ..."`), and
1750
+ no longer the class lucide used to derive from the PascalCase key where that differs
1751
+ (`ArrowDown01` no longer carries `lucide-arrow-down01`). The canonical
1752
+ `lucide-<icon name>` class is still there, so a `.lucide-loader-circle` selector still
1753
+ matches.
1754
+ - Icons resolved from a STRING through the seam keep the classes they had: `lucide`, the
1755
+ canonical `lucide-<icon name>` class and the key-derived class. They do not carry
1756
+ lucide's per-alias classes. That is a maintainer ruling (objectui#8941, option C): the
1757
+ alias list lives only inside each lazily loaded icon module, and it was not moved into
1758
+ the eager name list. A selector that targets an alias class matches a component-imported
1759
+ icon and not a string-resolved one. This also dates the example in the objectui#9251
1760
+ entry: `trash-2` no longer resolves as a string, so no seam-drawn glyph carries
1761
+ `lucide-trash2 lucide-trash-2`; a digit-bearing name that still resolves, such as
1762
+ `arrow-down-0-1`, carries `lucide-arrow-down01 lucide-arrow-down-0-1`.
1763
+ - d91aed9: Name the case-only spelling when a component type misses the registry.
1764
+
1765
+ Registry lookup is exactly case-sensitive, so a node typed `Page` misses a registered `page` and falls through to the OBJUI-001 "Unknown component type" panel. Because the mistake is usually uniform across a document, the symptom is not one broken widget — it is the whole page rendering as error panels, with nothing in the message pointing at the cause.
1766
+
1767
+ Both surfaces that report the miss now name the spelling that would have resolved. `SchemaRenderer`'s panel reads `Unknown component type: Page — did you mean 'page'?`, and `objectui check` reports `Unknown schema type "Page" in <file> — did you mean "page"?`. When no known type differs by case alone, neither says anything extra — `zzz` gains no bogus suggestion, and this is case matching, not an edit distance, so `pge` suggests nothing either.
1768
+
1769
+ **Lookup itself does not change.** `Page` still misses, still fails, and still renders the panel; only the message teaches. Normalising the lookup was considered and rejected (objectui#5247, maintainer ruling 2026-08-19): it would make two spellings valid everywhere, permanently, and legalise the typo class (`PAGE`, `pAge`) along with the PascalCase convention.
1770
+
1771
+ Each surface reads its candidates from the set it can actually trust — the renderer from the live `ComponentRegistry` (including pending lazy stubs), the CLI from the registration-derived `KNOWN_SCHEMA_TYPES` snapshot — so neither can suggest a type nothing registers.
1772
+ - Updated dependencies [7b10bef]
1773
+ - Updated dependencies [97abedc]
1774
+ - Updated dependencies [b46c58f]
1775
+ - Updated dependencies [ad694ac]
1776
+ - Updated dependencies [6f96fca]
1777
+ - Updated dependencies [0aacecc]
1778
+ - Updated dependencies [777fca2]
1779
+ - Updated dependencies [5f00ff4]
1780
+ - Updated dependencies [c9e073a]
1781
+ - Updated dependencies [7b395d8]
1782
+ - Updated dependencies [0879812]
1783
+ - Updated dependencies [162621b]
1784
+ - Updated dependencies [4c6f549]
1785
+ - Updated dependencies [2dd4d3f]
1786
+ - Updated dependencies [4ab4f1b]
1787
+ - Updated dependencies [e3ea4f9]
1788
+ - Updated dependencies [8b1f066]
1789
+ - Updated dependencies [af243c1]
1790
+ - Updated dependencies [cff4b77]
1791
+ - Updated dependencies [f3f4e4c]
1792
+ - Updated dependencies [a05c350]
1793
+ - Updated dependencies [2b5f509]
1794
+ - Updated dependencies [808f339]
1795
+ - Updated dependencies [6cf5999]
1796
+ - Updated dependencies [274e14a]
1797
+ - Updated dependencies [8c10f4f]
1798
+ - Updated dependencies [90dac98]
1799
+ - Updated dependencies [6096f20]
1800
+ - Updated dependencies [ea02938]
1801
+ - Updated dependencies [a14fb23]
1802
+ - Updated dependencies [ae98f1d]
1803
+ - Updated dependencies [f98eddf]
1804
+ - Updated dependencies [ce6bd99]
1805
+ - Updated dependencies [a5b08c9]
1806
+ - Updated dependencies [cdefa2a]
1807
+ - Updated dependencies [0961d5e]
1808
+ - Updated dependencies [6276478]
1809
+ - Updated dependencies [9b28151]
1810
+ - Updated dependencies [1a5003f]
1811
+ - Updated dependencies [09ab32b]
1812
+ - Updated dependencies [93a689d]
1813
+ - Updated dependencies [e5f4343]
1814
+ - Updated dependencies [3261e64]
1815
+ - Updated dependencies [f5178a2]
1816
+ - Updated dependencies [2ad3671]
1817
+ - Updated dependencies [d22b37b]
1818
+ - Updated dependencies [1daf477]
1819
+ - Updated dependencies [3d614ea]
1820
+ - Updated dependencies [fb13e85]
1821
+ - Updated dependencies [c2d8659]
1822
+ - Updated dependencies [e0f8202]
1823
+ - Updated dependencies [9fbbb17]
1824
+ - Updated dependencies [c3a26cc]
1825
+ - Updated dependencies [a66e58e]
1826
+ - Updated dependencies [d89492c]
1827
+ - Updated dependencies [9a5f998]
1828
+ - Updated dependencies [9327397]
1829
+ - Updated dependencies [17cc3a3]
1830
+ - Updated dependencies [02e6d36]
1831
+ - Updated dependencies [4758b33]
1832
+ - Updated dependencies [9c78ebe]
1833
+ - Updated dependencies [9c78ebe]
1834
+ - Updated dependencies [12809a5]
1835
+ - Updated dependencies [7afc81d]
1836
+ - Updated dependencies [f9c06ef]
1837
+ - Updated dependencies [5ad3b88]
1838
+ - Updated dependencies [f9d772b]
1839
+ - Updated dependencies [97b6c21]
1840
+ - Updated dependencies [26ca2ad]
1841
+ - Updated dependencies [41ae65b]
1842
+ - Updated dependencies [baac95a]
1843
+ - Updated dependencies [13220af]
1844
+ - Updated dependencies [29b45f6]
1845
+ - Updated dependencies [39b8d51]
1846
+ - Updated dependencies [b956e69]
1847
+ - Updated dependencies [256b4c9]
1848
+ - Updated dependencies [c5ec15c]
1849
+ - Updated dependencies [fec3b1a]
1850
+ - Updated dependencies [b8e0941]
1851
+ - Updated dependencies [0c50f18]
1852
+ - Updated dependencies [1dae95a]
1853
+ - Updated dependencies [e32dae1]
1854
+ - Updated dependencies [4aebea0]
1855
+ - Updated dependencies [f976774]
1856
+ - Updated dependencies [25cb364]
1857
+ - Updated dependencies [a60539b]
1858
+ - Updated dependencies [de1b879]
1859
+ - Updated dependencies [c6678b1]
1860
+ - Updated dependencies [0638322]
1861
+ - Updated dependencies [e3782d2]
1862
+ - Updated dependencies [db0beb2]
1863
+ - Updated dependencies [997ce38]
1864
+ - Updated dependencies [ae0b9d3]
1865
+ - Updated dependencies [ad1785c]
1866
+ - Updated dependencies [3b469c8]
1867
+ - Updated dependencies [1c84036]
1868
+ - Updated dependencies [1c84036]
1869
+ - Updated dependencies [6650259]
1870
+ - Updated dependencies [4f8b7f8]
1871
+ - Updated dependencies [f6ae5e2]
1872
+ - Updated dependencies [7343376]
1873
+ - Updated dependencies [b2683a2]
1874
+ - Updated dependencies [dded788]
1875
+ - Updated dependencies [b45d463]
1876
+ - Updated dependencies [54a7830]
1877
+ - Updated dependencies [f3135a4]
1878
+ - Updated dependencies [b5696d3]
1879
+ - Updated dependencies [3f9d926]
1880
+ - Updated dependencies [e978ed5]
1881
+ - Updated dependencies [6a7f24e]
1882
+ - Updated dependencies [b3c96d6]
1883
+ - Updated dependencies [8d0ca91]
1884
+ - Updated dependencies [c30c8dd]
1885
+ - Updated dependencies [deca847]
1886
+ - Updated dependencies [328abeb]
1887
+ - Updated dependencies [dd0d78f]
1888
+ - Updated dependencies [24d3e65]
1889
+ - Updated dependencies [95a7c8d]
1890
+ - Updated dependencies [cc4e476]
1891
+ - Updated dependencies [92970c4]
1892
+ - Updated dependencies [d570eaa]
1893
+ - Updated dependencies [4b742f4]
1894
+ - Updated dependencies [42687ba]
1895
+ - Updated dependencies [24a0f14]
1896
+ - Updated dependencies [797a30f]
1897
+ - Updated dependencies [b4075c0]
1898
+ - Updated dependencies [9b85600]
1899
+ - Updated dependencies [99878d8]
1900
+ - Updated dependencies [3c13675]
1901
+ - Updated dependencies [0eb9f36]
1902
+ - Updated dependencies [ae582b7]
1903
+ - Updated dependencies [a4b017e]
1904
+ - Updated dependencies [559a2e2]
1905
+ - Updated dependencies [db11afd]
1906
+ - Updated dependencies [154075a]
1907
+ - Updated dependencies [582edef]
1908
+ - Updated dependencies [19f484f]
1909
+ - Updated dependencies [0a78a20]
1910
+ - Updated dependencies [615346d]
1911
+ - Updated dependencies [75dcc81]
1912
+ - Updated dependencies [55a12a8]
1913
+ - Updated dependencies [edfcf5a]
1914
+ - Updated dependencies [0a3e540]
1915
+ - Updated dependencies [c021b35]
1916
+ - Updated dependencies [f61dab1]
1917
+ - Updated dependencies [b0a05dd]
1918
+ - Updated dependencies [dd5ff19]
1919
+ - Updated dependencies [81f8498]
1920
+ - Updated dependencies [0645133]
1921
+ - Updated dependencies [0ecaa7d]
1922
+ - Updated dependencies [b24f93a]
1923
+ - Updated dependencies [c27b575]
1924
+ - Updated dependencies [84b275c]
1925
+ - Updated dependencies [0e6e76b]
1926
+ - Updated dependencies [0ffc423]
1927
+ - Updated dependencies [3cc4fe5]
1928
+ - Updated dependencies [cd5b19a]
1929
+ - Updated dependencies [cd5b19a]
1930
+ - Updated dependencies [17dc167]
1931
+ - Updated dependencies [20d23be]
1932
+ - Updated dependencies [20d23be]
1933
+ - Updated dependencies [2e3da72]
1934
+ - Updated dependencies [1263e40]
1935
+ - Updated dependencies [e6bc087]
1936
+ - Updated dependencies [8bab157]
1937
+ - Updated dependencies [a7557a7]
1938
+ - Updated dependencies [7d074ba]
1939
+ - Updated dependencies [6158e4c]
1940
+ - Updated dependencies [6158e4c]
1941
+ - Updated dependencies [52aad5c]
1942
+ - Updated dependencies [18d1a0a]
1943
+ - Updated dependencies [7fed09d]
1944
+ - Updated dependencies [58da8ae]
1945
+ - Updated dependencies [a8b9889]
1946
+ - Updated dependencies [138ad45]
1947
+ - Updated dependencies [5262f7d]
1948
+ - Updated dependencies [6aa029b]
1949
+ - Updated dependencies [2124d04]
1950
+ - Updated dependencies [be52115]
1951
+ - Updated dependencies [770cc5b]
1952
+ - Updated dependencies [1a88ce2]
1953
+ - Updated dependencies [a1a44d6]
1954
+ - Updated dependencies [e0a9c67]
1955
+ - Updated dependencies [5638529]
1956
+ - Updated dependencies [c476be0]
1957
+ - Updated dependencies [c82ff39]
1958
+ - Updated dependencies [6c3da53]
1959
+ - Updated dependencies [31987bd]
1960
+ - Updated dependencies [3c3ce15]
1961
+ - Updated dependencies [e100589]
1962
+ - Updated dependencies [304f611]
1963
+ - Updated dependencies [e46ee77]
1964
+ - Updated dependencies [6e9c8d2]
1965
+ - Updated dependencies [9547063]
1966
+ - Updated dependencies [3f6efd6]
1967
+ - Updated dependencies [c4ab6d0]
1968
+ - Updated dependencies [0e9058b]
1969
+ - Updated dependencies [5988b6b]
1970
+ - Updated dependencies [6158e4c]
1971
+ - Updated dependencies [00ccdf7]
1972
+ - Updated dependencies [9d9ed54]
1973
+ - Updated dependencies [4a1adb7]
1974
+ - Updated dependencies [50c73fe]
1975
+ - Updated dependencies [ca3de72]
1976
+ - Updated dependencies [83e3f83]
1977
+ - Updated dependencies [401611b]
1978
+ - Updated dependencies [2c0ddf2]
1979
+ - Updated dependencies [4abc0aa]
1980
+ - Updated dependencies [2b188fa]
1981
+ - Updated dependencies [b654d4e]
1982
+ - Updated dependencies [f68e0a0]
1983
+ - Updated dependencies [aea682a]
1984
+ - Updated dependencies [fcdc8ec]
1985
+ - Updated dependencies [2d576e4]
1986
+ - Updated dependencies [8366acc]
1987
+ - Updated dependencies [95e58a3]
1988
+ - Updated dependencies [9d7419b]
1989
+ - Updated dependencies [fc7db05]
1990
+ - Updated dependencies [9ed8d0f]
1991
+ - Updated dependencies [c73cdb5]
1992
+ - Updated dependencies [6f5719e]
1993
+ - Updated dependencies [06a8af5]
1994
+ - Updated dependencies [6a91586]
1995
+ - Updated dependencies [a04d7c6]
1996
+ - Updated dependencies [5ccc500]
1997
+ - Updated dependencies [f3c2bb0]
1998
+ - Updated dependencies [978507b]
1999
+ - Updated dependencies [778138e]
2000
+ - Updated dependencies [460575f]
2001
+ - Updated dependencies [d796c8d]
2002
+ - Updated dependencies [1b1d772]
2003
+ - Updated dependencies [d88e20f]
2004
+ - Updated dependencies [2d7304d]
2005
+ - Updated dependencies [636b236]
2006
+ - Updated dependencies [4172589]
2007
+ - Updated dependencies [d6d8fb9]
2008
+ - Updated dependencies [64d624d]
2009
+ - Updated dependencies [39f4309]
2010
+ - Updated dependencies [95bad12]
2011
+ - Updated dependencies [d2fb6ef]
2012
+ - Updated dependencies [7cd3987]
2013
+ - Updated dependencies [ee3b878]
2014
+ - Updated dependencies [e304a4e]
2015
+ - Updated dependencies [fda49e5]
2016
+ - Updated dependencies [fc62bb4]
2017
+ - Updated dependencies [41df893]
2018
+ - Updated dependencies [0cba1b7]
2019
+ - Updated dependencies [00f3eb5]
2020
+ - Updated dependencies [1ec291c]
2021
+ - Updated dependencies [453dbaa]
2022
+ - Updated dependencies [f8cdbf2]
2023
+ - Updated dependencies [69a2163]
2024
+ - Updated dependencies [24e027e]
2025
+ - Updated dependencies [2c3cd1b]
2026
+ - Updated dependencies [e176053]
2027
+ - Updated dependencies [e30ed15]
2028
+ - Updated dependencies [90665e0]
2029
+ - Updated dependencies [194fae1]
2030
+ - Updated dependencies [7e19d03]
2031
+ - Updated dependencies [1e946c9]
2032
+ - Updated dependencies [546ddf7]
2033
+ - Updated dependencies [864154e]
2034
+ - Updated dependencies [b023625]
2035
+ - Updated dependencies [75bd83d]
2036
+ - Updated dependencies [40c479a]
2037
+ - Updated dependencies [971d387]
2038
+ - Updated dependencies [ee851c3]
2039
+ - Updated dependencies [6414dfd]
2040
+ - Updated dependencies [a8d5c71]
2041
+ - Updated dependencies [905b21f]
2042
+ - Updated dependencies [88e9109]
2043
+ - Updated dependencies [2c45966]
2044
+ - Updated dependencies [db3a600]
2045
+ - Updated dependencies [3a3db76]
2046
+ - Updated dependencies [0d723a3]
2047
+ - Updated dependencies [0c95d3d]
2048
+ - Updated dependencies [3e4fa2c]
2049
+ - Updated dependencies [b5b928a]
2050
+ - Updated dependencies [6fd2cf7]
2051
+ - Updated dependencies [52a43de]
2052
+ - Updated dependencies [195052f]
2053
+ - Updated dependencies [e4559d1]
2054
+ - Updated dependencies [2c71482]
2055
+ - Updated dependencies [129bcc5]
2056
+ - Updated dependencies [5ef9c4f]
2057
+ - Updated dependencies [46f0bb4]
2058
+ - Updated dependencies [8ec11e1]
2059
+ - Updated dependencies [6f81384]
2060
+ - Updated dependencies [22ba927]
2061
+ - Updated dependencies [f8c70f4]
2062
+ - Updated dependencies [8f1d995]
2063
+ - Updated dependencies [f9c34df]
2064
+ - Updated dependencies [dddb942]
2065
+ - Updated dependencies [29754cf]
2066
+ - Updated dependencies [d7de534]
2067
+ - Updated dependencies [6e88630]
2068
+ - Updated dependencies [b84dc18]
2069
+ - Updated dependencies [ac8abb0]
2070
+ - Updated dependencies [9d86e1d]
2071
+ - Updated dependencies [3a5817f]
2072
+ - Updated dependencies [99a3c2d]
2073
+ - Updated dependencies [f24de8b]
2074
+ - Updated dependencies [c8ea8af]
2075
+ - Updated dependencies [3190414]
2076
+ - Updated dependencies [4e480f5]
2077
+ - Updated dependencies [38a123c]
2078
+ - Updated dependencies [30c73cd]
2079
+ - Updated dependencies [830ed58]
2080
+ - Updated dependencies [d7acad6]
2081
+ - Updated dependencies [45a9aeb]
2082
+ - Updated dependencies [713db46]
2083
+ - Updated dependencies [c71e14d]
2084
+ - Updated dependencies [bf3a03c]
2085
+ - Updated dependencies [cb55718]
2086
+ - Updated dependencies [748494b]
2087
+ - Updated dependencies [5967be0]
2088
+ - Updated dependencies [29cb85b]
2089
+ - Updated dependencies [3e028c8]
2090
+ - Updated dependencies [ce503e5]
2091
+ - Updated dependencies [f20dcf0]
2092
+ - Updated dependencies [12402a9]
2093
+ - Updated dependencies [aff3d7a]
2094
+ - Updated dependencies [4ca30d0]
2095
+ - Updated dependencies [7a5da14]
2096
+ - Updated dependencies [2c1c967]
2097
+ - Updated dependencies [9486ac6]
2098
+ - Updated dependencies [9486ac6]
2099
+ - Updated dependencies [d6ceb8d]
2100
+ - Updated dependencies [dc4365c]
2101
+ - Updated dependencies [e321d52]
2102
+ - Updated dependencies [4c68077]
2103
+ - Updated dependencies [7977ff9]
2104
+ - Updated dependencies [3beef6d]
2105
+ - Updated dependencies [06b8c42]
2106
+ - Updated dependencies [46b9bc9]
2107
+ - Updated dependencies [b97790a]
2108
+ - Updated dependencies [7c9b044]
2109
+ - Updated dependencies [d47de51]
2110
+ - Updated dependencies [3fe6463]
2111
+ - Updated dependencies [31ab372]
2112
+ - Updated dependencies [846889b]
2113
+ - Updated dependencies [2acd8e1]
2114
+ - Updated dependencies [26896c6]
2115
+ - Updated dependencies [67fc3b0]
2116
+ - Updated dependencies [33a3b3c]
2117
+ - Updated dependencies [b87f15b]
2118
+ - Updated dependencies [c18d099]
2119
+ - Updated dependencies [adb2a86]
2120
+ - Updated dependencies [03380aa]
2121
+ - Updated dependencies [4562ea5]
2122
+ - Updated dependencies [3561bd2]
2123
+ - Updated dependencies [bf97b98]
2124
+ - Updated dependencies [b0d308d]
2125
+ - Updated dependencies [40f34b4]
2126
+ - Updated dependencies [8063bcb]
2127
+ - Updated dependencies [b74a859]
2128
+ - Updated dependencies [d4493fd]
2129
+ - Updated dependencies [240b80f]
2130
+ - Updated dependencies [77cb489]
2131
+ - Updated dependencies [bfaa158]
2132
+ - Updated dependencies [777e5c6]
2133
+ - Updated dependencies [0c386dd]
2134
+ - Updated dependencies [9e37d9b]
2135
+ - Updated dependencies [5ad86dd]
2136
+ - Updated dependencies [16a725f]
2137
+ - Updated dependencies [4dfdcc3]
2138
+ - Updated dependencies [6a449fc]
2139
+ - Updated dependencies [446d93d]
2140
+ - Updated dependencies [ecd9cb2]
2141
+ - Updated dependencies [98d4108]
2142
+ - Updated dependencies [0e3b3be]
2143
+ - Updated dependencies [a29ae2d]
2144
+ - Updated dependencies [00d3f09]
2145
+ - Updated dependencies [4388f71]
2146
+ - Updated dependencies [0b1ac58]
2147
+ - Updated dependencies [c93b4d5]
2148
+ - Updated dependencies [c1fe272]
2149
+ - Updated dependencies [3cab570]
2150
+ - Updated dependencies [8ad218d]
2151
+ - Updated dependencies [3e41187]
2152
+ - Updated dependencies [5f78953]
2153
+ - Updated dependencies [639114c]
2154
+ - Updated dependencies [1f31d3a]
2155
+ - Updated dependencies [d1842ab]
2156
+ - Updated dependencies [78ca238]
2157
+ - Updated dependencies [351eb31]
2158
+ - Updated dependencies [20c04b2]
2159
+ - Updated dependencies [4b5bb95]
2160
+ - Updated dependencies [b652514]
2161
+ - Updated dependencies [adbda1b]
2162
+ - Updated dependencies [adbda1b]
2163
+ - Updated dependencies [e2b3826]
2164
+ - Updated dependencies [2e32ed4]
2165
+ - Updated dependencies [3ed3eec]
2166
+ - Updated dependencies [7c3df8f]
2167
+ - Updated dependencies [b9f5ff1]
2168
+ - Updated dependencies [4704aa4]
2169
+ - Updated dependencies [1bee5d0]
2170
+ - Updated dependencies [858cd72]
2171
+ - Updated dependencies [cfc9b6d]
2172
+ - Updated dependencies [554f2b6]
2173
+ - Updated dependencies [72f55c9]
2174
+ - Updated dependencies [26e06d7]
2175
+ - Updated dependencies [669d71b]
2176
+ - Updated dependencies [ed27d7c]
2177
+ - Updated dependencies [52c8cf7]
2178
+ - Updated dependencies [2ceb43a]
2179
+ - Updated dependencies [7cdd2b9]
2180
+ - Updated dependencies [52c8cf7]
2181
+ - Updated dependencies [71a4a53]
2182
+ - Updated dependencies [7bf244b]
2183
+ - Updated dependencies [f0bb9fa]
2184
+ - Updated dependencies [81a2eb1]
2185
+ - Updated dependencies [caa0cd3]
2186
+ - Updated dependencies [caa0cd3]
2187
+ - Updated dependencies [25c7d58]
2188
+ - Updated dependencies [c6198c2]
2189
+ - Updated dependencies [1237ae4]
2190
+ - Updated dependencies [2f61238]
2191
+ - Updated dependencies [51eb515]
2192
+ - Updated dependencies [c354ce5]
2193
+ - Updated dependencies [8fe8e5c]
2194
+ - Updated dependencies [feac439]
2195
+ - Updated dependencies [9ae871d]
2196
+ - Updated dependencies [efbd566]
2197
+ - Updated dependencies [9587fc9]
2198
+ - Updated dependencies [e62c44e]
2199
+ - Updated dependencies [daf9d57]
2200
+ - Updated dependencies [c15d7ec]
2201
+ - Updated dependencies [5d0876c]
2202
+ - Updated dependencies [f7ace0a]
2203
+ - Updated dependencies [b041b9c]
2204
+ - Updated dependencies [544ecba]
2205
+ - Updated dependencies [2ce2612]
2206
+ - Updated dependencies [bc640ec]
2207
+ - Updated dependencies [3e377c9]
2208
+ - Updated dependencies [a3eb5d0]
2209
+ - Updated dependencies [4ce14f1]
2210
+ - Updated dependencies [2af1fa7]
2211
+ - Updated dependencies [c14d3a0]
2212
+ - Updated dependencies [a137d0c]
2213
+ - Updated dependencies [caf477f]
2214
+ - Updated dependencies [f6375da]
2215
+ - Updated dependencies [967e5d8]
2216
+ - Updated dependencies [a4611b3]
2217
+ - Updated dependencies [20316ba]
2218
+ - Updated dependencies [d3499b3]
2219
+ - Updated dependencies [309c75e]
2220
+ - Updated dependencies [c9f9bae]
2221
+ - Updated dependencies [18897a4]
2222
+ - Updated dependencies [8b7ea39]
2223
+ - Updated dependencies [dcbf0b2]
2224
+ - Updated dependencies [1422a92]
2225
+ - Updated dependencies [d05fe17]
2226
+ - Updated dependencies [a480f79]
2227
+ - Updated dependencies [f08d1a8]
2228
+ - Updated dependencies [64a252d]
2229
+ - Updated dependencies [786bc91]
2230
+ - Updated dependencies [75fca96]
2231
+ - Updated dependencies [7ca6ddd]
2232
+ - Updated dependencies [f1cd290]
2233
+ - Updated dependencies [5a41ce7]
2234
+ - Updated dependencies [8d50bc2]
2235
+ - Updated dependencies [604476d]
2236
+ - Updated dependencies [d1bebb0]
2237
+ - Updated dependencies [95bf128]
2238
+ - Updated dependencies [335abea]
2239
+ - Updated dependencies [edea22a]
2240
+ - Updated dependencies [0f5cadf]
2241
+ - Updated dependencies [4f9f1ee]
2242
+ - Updated dependencies [66e8b2a]
2243
+ - Updated dependencies [aa083cd]
2244
+ - Updated dependencies [12b5992]
2245
+ - Updated dependencies [b93e245]
2246
+ - Updated dependencies [c842594]
2247
+ - Updated dependencies [290de37]
2248
+ - Updated dependencies [8c8da45]
2249
+ - Updated dependencies [8cd8eb5]
2250
+ - Updated dependencies [cf1d29e]
2251
+ - Updated dependencies [af9e957]
2252
+ - Updated dependencies [b1030c7]
2253
+ - Updated dependencies [c974edf]
2254
+ - Updated dependencies [ad852b6]
2255
+ - Updated dependencies [7fb22a1]
2256
+ - Updated dependencies [ad66d79]
2257
+ - Updated dependencies [ee4d19f]
2258
+ - Updated dependencies [496d31d]
2259
+ - Updated dependencies [0ea7054]
2260
+ - Updated dependencies [9a853f2]
2261
+ - Updated dependencies [cb847fd]
2262
+ - Updated dependencies [ee70287]
2263
+ - Updated dependencies [3e98e13]
2264
+ - Updated dependencies [4eaa835]
2265
+ - Updated dependencies [b1777ae]
2266
+ - Updated dependencies [24845c4]
2267
+ - Updated dependencies [6f864cf]
2268
+ - Updated dependencies [24d1edd]
2269
+ - Updated dependencies [645087c]
2270
+ - Updated dependencies [33f4a19]
2271
+ - Updated dependencies [4a292d2]
2272
+ - Updated dependencies [5323168]
2273
+ - Updated dependencies [841dd2b]
2274
+ - Updated dependencies [3014fc0]
2275
+ - Updated dependencies [dacb402]
2276
+ - Updated dependencies [474797d]
2277
+ - Updated dependencies [704e695]
2278
+ - Updated dependencies [a407bd6]
2279
+ - Updated dependencies [3a43a15]
2280
+ - Updated dependencies [868e825]
2281
+ - Updated dependencies [421544b]
2282
+ - Updated dependencies [fb01022]
2283
+ - Updated dependencies [e9d9212]
2284
+ - Updated dependencies [ecfb693]
2285
+ - Updated dependencies [81a51db]
2286
+ - Updated dependencies [67749c7]
2287
+ - Updated dependencies [507b61b]
2288
+ - Updated dependencies [512c84b]
2289
+ - Updated dependencies [c300267]
2290
+ - Updated dependencies [d4733f2]
2291
+ - Updated dependencies [1570eac]
2292
+ - Updated dependencies [8b532cb]
2293
+ - Updated dependencies [c42554e]
2294
+ - Updated dependencies [555b4ec]
2295
+ - Updated dependencies [1ccfc23]
2296
+ - Updated dependencies [542718f]
2297
+ - Updated dependencies [7f27bc5]
2298
+ - Updated dependencies [f95b140]
2299
+ - Updated dependencies [541ce4e]
2300
+ - Updated dependencies [6479086]
2301
+ - Updated dependencies [d79f525]
2302
+ - Updated dependencies [f1190b0]
2303
+ - Updated dependencies [6a4680b]
2304
+ - Updated dependencies [c3a4273]
2305
+ - Updated dependencies [093af32]
2306
+ - Updated dependencies [1bd1be7]
2307
+ - Updated dependencies [d234fa9]
2308
+ - Updated dependencies [adf5812]
2309
+ - Updated dependencies [e36acd4]
2310
+ - Updated dependencies [5058336]
2311
+ - Updated dependencies [2f6b2bf]
2312
+ - Updated dependencies [2028b31]
2313
+ - Updated dependencies [63601ab]
2314
+ - Updated dependencies [152f0a7]
2315
+ - Updated dependencies [8693b85]
2316
+ - Updated dependencies [e82dad1]
2317
+ - Updated dependencies [58b7b3d]
2318
+ - Updated dependencies [681d3f1]
2319
+ - Updated dependencies [f3bc481]
2320
+ - Updated dependencies [93fc0e7]
2321
+ - Updated dependencies [a4b723f]
2322
+ - Updated dependencies [2b10ca0]
2323
+ - Updated dependencies [7db4a81]
2324
+ - Updated dependencies [526fc11]
2325
+ - Updated dependencies [b9d47ec]
2326
+ - Updated dependencies [6214db6]
2327
+ - Updated dependencies [6732df4]
2328
+ - Updated dependencies [fe9e0d0]
2329
+ - Updated dependencies [63fb72c]
2330
+ - Updated dependencies [279e48e]
2331
+ - Updated dependencies [8700d6d]
2332
+ - Updated dependencies [8db2a0f]
2333
+ - Updated dependencies [689953a]
2334
+ - Updated dependencies [30443fb]
2335
+ - Updated dependencies [8d3dbb2]
2336
+ - Updated dependencies [efc1c9c]
2337
+ - Updated dependencies [7533465]
2338
+ - Updated dependencies [a9d97be]
2339
+ - Updated dependencies [9ba7e9c]
2340
+ - Updated dependencies [96919a4]
2341
+ - Updated dependencies [345e24a]
2342
+ - Updated dependencies [2e471dc]
2343
+ - Updated dependencies [6748587]
2344
+ - Updated dependencies [be50942]
2345
+ - Updated dependencies [775e079]
2346
+ - Updated dependencies [7e8b3c0]
2347
+ - Updated dependencies [53374dc]
2348
+ - Updated dependencies [f6fb83f]
2349
+ - Updated dependencies [2049b03]
2350
+ - Updated dependencies [7cbc724]
2351
+ - Updated dependencies [7098eed]
2352
+ - Updated dependencies [3df7c5c]
2353
+ - Updated dependencies [fb91ac9]
2354
+ - Updated dependencies [fb91ac9]
2355
+ - Updated dependencies [641fb55]
2356
+ - Updated dependencies [8524372]
2357
+ - Updated dependencies [7cbefa5]
2358
+ - Updated dependencies [72d6587]
2359
+ - Updated dependencies [a272a4f]
2360
+ - Updated dependencies [55f39ee]
2361
+ - Updated dependencies [0ce32d5]
2362
+ - Updated dependencies [0970a0e]
2363
+ - Updated dependencies [e427e9c]
2364
+ - Updated dependencies [bbc9dc3]
2365
+ - Updated dependencies [02f1813]
2366
+ - Updated dependencies [1ef89c0]
2367
+ - Updated dependencies [ba0b61a]
2368
+ - Updated dependencies [ac716ff]
2369
+ - Updated dependencies [f0f3cd5]
2370
+ - Updated dependencies [20f3e65]
2371
+ - Updated dependencies [bbba098]
2372
+ - Updated dependencies [87af769]
2373
+ - Updated dependencies [3be720e]
2374
+ - Updated dependencies [43c0d17]
2375
+ - Updated dependencies [c3df43a]
2376
+ - Updated dependencies [d16d0e9]
2377
+ - Updated dependencies [bbe57fd]
2378
+ - Updated dependencies [272a530]
2379
+ - Updated dependencies [1779e8d]
2380
+ - Updated dependencies [f7fcc2c]
2381
+ - Updated dependencies [f0f4d6c]
2382
+ - Updated dependencies [4128188]
2383
+ - Updated dependencies [b253c4e]
2384
+ - Updated dependencies [78a9c67]
2385
+ - Updated dependencies [4a7ef0d]
2386
+ - Updated dependencies [4598f6d]
2387
+ - Updated dependencies [dea17b4]
2388
+ - Updated dependencies [89bb77a]
2389
+ - Updated dependencies [06611e4]
2390
+ - Updated dependencies [3939545]
2391
+ - Updated dependencies [66abbde]
2392
+ - Updated dependencies [dc3893d]
2393
+ - Updated dependencies [1bbaa16]
2394
+ - Updated dependencies [6ee259a]
2395
+ - Updated dependencies [7649f43]
2396
+ - Updated dependencies [e708426]
2397
+ - Updated dependencies [3b6d53b]
2398
+ - Updated dependencies [a8198de]
2399
+ - Updated dependencies [0c789a4]
2400
+ - Updated dependencies [b234a84]
2401
+ - Updated dependencies [a78cd37]
2402
+ - Updated dependencies [5ea623e]
2403
+ - Updated dependencies [ca5d671]
2404
+ - Updated dependencies [32bf2d6]
2405
+ - Updated dependencies [ff0c384]
2406
+ - Updated dependencies [af4fb29]
2407
+ - Updated dependencies [befd40c]
2408
+ - Updated dependencies [9a97800]
2409
+ - Updated dependencies [6bca0e4]
2410
+ - Updated dependencies [3c76801]
2411
+ - Updated dependencies [2fcefb9]
2412
+ - Updated dependencies [b55a346]
2413
+ - Updated dependencies [065bba7]
2414
+ - Updated dependencies [dd19463]
2415
+ - Updated dependencies [100547e]
2416
+ - Updated dependencies [6d1c155]
2417
+ - Updated dependencies [d7573b3]
2418
+ - Updated dependencies [2c8474c]
2419
+ - Updated dependencies [0e05aac]
2420
+ - Updated dependencies [ae61ad4]
2421
+ - Updated dependencies [18a8e7d]
2422
+ - Updated dependencies [e7957ab]
2423
+ - Updated dependencies [f7e34ca]
2424
+ - Updated dependencies [e719ebd]
2425
+ - Updated dependencies [f9e4f91]
2426
+ - Updated dependencies [6ef48b1]
2427
+ - Updated dependencies [fa429cf]
2428
+ - Updated dependencies [ed8df3e]
2429
+ - Updated dependencies [fe76ece]
2430
+ - Updated dependencies [8b446f5]
2431
+ - Updated dependencies [7102b20]
2432
+ - Updated dependencies [58770f3]
2433
+ - Updated dependencies [aefe428]
2434
+ - Updated dependencies [485f096]
2435
+ - Updated dependencies [7357447]
2436
+ - Updated dependencies [199d31b]
2437
+ - Updated dependencies [b655a9d]
2438
+ - Updated dependencies [3e01cb5]
2439
+ - Updated dependencies [4e8622b]
2440
+ - Updated dependencies [dffd752]
2441
+ - Updated dependencies [105f3c5]
2442
+ - Updated dependencies [3ccd9e8]
2443
+ - Updated dependencies [689b979]
2444
+ - Updated dependencies [c70f865]
2445
+ - Updated dependencies [e546222]
2446
+ - Updated dependencies [fd13f52]
2447
+ - Updated dependencies [d7bd274]
2448
+ - Updated dependencies [98c3a74]
2449
+ - Updated dependencies [ebce5a3]
2450
+ - Updated dependencies [fb336df]
2451
+ - Updated dependencies [9d9040d]
2452
+ - Updated dependencies [0fce2ef]
2453
+ - Updated dependencies [0e2ddd4]
2454
+ - Updated dependencies [b7479ab]
2455
+ - Updated dependencies [9850c6e]
2456
+ - Updated dependencies [b2ea297]
2457
+ - Updated dependencies [5b5a5c3]
2458
+ - Updated dependencies [14582b8]
2459
+ - Updated dependencies [51e144e]
2460
+ - Updated dependencies [ab92940]
2461
+ - Updated dependencies [a691c0b]
2462
+ - Updated dependencies [0b1326d]
2463
+ - Updated dependencies [515f171]
2464
+ - Updated dependencies [4f14ad7]
2465
+ - Updated dependencies [258d264]
2466
+ - Updated dependencies [cac64b3]
2467
+ - Updated dependencies [8033ad1]
2468
+ - Updated dependencies [fa140b8]
2469
+ - Updated dependencies [71cba28]
2470
+ - Updated dependencies [190fbd0]
2471
+ - Updated dependencies [93127bd]
2472
+ - Updated dependencies [759606e]
2473
+ - Updated dependencies [72ffc34]
2474
+ - Updated dependencies [51f3d8d]
2475
+ - Updated dependencies [bf28341]
2476
+ - Updated dependencies [78cbdb5]
2477
+ - Updated dependencies [b7543a9]
2478
+ - Updated dependencies [6c6cee7]
2479
+ - Updated dependencies [42887e0]
2480
+ - Updated dependencies [83fe6e7]
2481
+ - Updated dependencies [d1ab06f]
2482
+ - Updated dependencies [f90b8fb]
2483
+ - Updated dependencies [91783c4]
2484
+ - Updated dependencies [982885d]
2485
+ - Updated dependencies [dba7d84]
2486
+ - Updated dependencies [ca39427]
2487
+ - Updated dependencies [bd09957]
2488
+ - Updated dependencies [5a07e67]
2489
+ - Updated dependencies [45d8288]
2490
+ - Updated dependencies [490f482]
2491
+ - Updated dependencies [27308c5]
2492
+ - Updated dependencies [8689166]
2493
+ - Updated dependencies [c9327c9]
2494
+ - Updated dependencies [920165d]
2495
+ - Updated dependencies [9101be5]
2496
+ - Updated dependencies [f53a8d0]
2497
+ - Updated dependencies [968dc1e]
2498
+ - Updated dependencies [57f9b07]
2499
+ - Updated dependencies [3c73d99]
2500
+ - Updated dependencies [d91aed9]
2501
+ - Updated dependencies [c86185e]
2502
+ - Updated dependencies [1170ed1]
2503
+ - Updated dependencies [4d73b07]
2504
+ - @object-ui/react@17.7.0
2505
+ - @object-ui/types@17.7.0
2506
+ - @object-ui/components@17.7.0
2507
+
3
2508
  ## 17.6.0
4
2509
 
5
2510
  ### Patch Changes