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