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