From f00c241e74e7749231ba3427b7ec2430f1edcde5 Mon Sep 17 00:00:00 2001 From: Claude Date: Mon, 28 Sep 2026 08:30:28 +0000 Subject: [PATCH 1/3] docs(types): correct two docblocks the series and listViews mirrors made false The `ObjectChartSchema.series` docblock said a `type` on the `{ dataKey }` arm is an excess property on a literal typed by the interface. Since the series union took the spec's `ChartSeries` as its `{ name }` arm, which declares `type`, that literal compiles; only the zod mirror still strips it. The zod route-overview docblock ("WHERE THIS ARM IS INSTALLED") said a named view's `listViews` is unmirrored and named a `custom` issue under `options.kanban` on that route. `listViews` is now the protocol's strict record by reference: it refuses a named view's `options` bag whole, and the named-view check reports at `listViews.KEY.kanban.groupBy` only. The heading and closing sentence are corrected to match. Comment text only; no behaviour, type or accept-set change. Claude-Session: https://claude.ai/code/session_012UwY3ahMixEFkfTUxMVkYm Co-authored-by: Claude --- packages/types/src/objectql.ts | 13 ++++++++----- packages/types/src/zod/objectql.zod.ts | 18 ++++++++++-------- 2 files changed, 18 insertions(+), 13 deletions(-) diff --git a/packages/types/src/objectql.ts b/packages/types/src/objectql.ts index 3e634b5c96..4e20532e67 100644 --- a/packages/types/src/objectql.ts +++ b/packages/types/src/objectql.ts @@ -4821,11 +4821,14 @@ export interface ObjectChartSchema extends BaseSchema { * that writes `type` on a `{ dataKey }` entry of an `object-chart` node; * none was named. Until one is, the per-series family override on this arm * is `chartType`, the renderer-internal spelling of `type`, which wins when - * an entry writes both. A `type` written on this arm anyway is an excess - * property on a literal typed by this interface, and the zod mirror's - * element is a plain `z.object`, which strips it: it parses clean and is - * dropped. The mirror's `.describe()` says the same, because that string is - * what an author-facing tool renders. + * an entry writes both. A `type` written on this arm anyway is NOT refused + * on a literal typed by this interface: the `{ name }` arm declares `type`, + * and excess-property checking on this union accepts a key that either arm + * declares when its value fits that declaration, so + * `{ dataKey: 'amount', type: 'line' }` compiles. The zod mirror's element + * for this arm is a plain `z.object`, which strips it: it parses clean and + * is dropped. The mirror's `.describe()` names the same omission, because + * that string is what an author-facing tool renders. * * An entry with neither `name` nor `dataKey` matches no arm and is refused; * `normalizeChartSchema` would drop it from the chart. diff --git a/packages/types/src/zod/objectql.zod.ts b/packages/types/src/zod/objectql.zod.ts index a371682d6f..0f8508d8f5 100644 --- a/packages/types/src/zod/objectql.zod.ts +++ b/packages/types/src/zod/objectql.zod.ts @@ -919,7 +919,7 @@ const KanbanStrayGroupByRefusal = aliasKeyRefusal( ); /** - * WHERE THIS ARM IS INSTALLED — TWO ROUTES, TWO NESTINGS EACH, ONE STRING. + * WHERE THIS ARM IS INSTALLED — TWO ROUTES, THREE NESTINGS, ONE STRING. * * `ListView` merges `{ ...schema.options?.kanban, ...schema.kanban }` before it * reads anything, so a stored view can carry the stray key under EITHER. The @@ -930,11 +930,13 @@ const KanbanStrayGroupByRefusal = aliasKeyRefusal( * `options.kanban.groupBy`) — see `ListViewSchema.options` below. * * The second route is a named view on an `object-view` document, whose - * `listViews` is unmirrored: nothing `ListViewSchema` declares reaches it, and - * `generateViewSchema` merges the same two nestings. It takes the SAME guidance - * through the named-view door (`custom` at `listViews.KEY.kanban.groupBy` and - * `listViews.KEY.options.kanban.groupBy`, objectui#10321) — see - * `checkNamedViewKanbanStrayGroupBy` below. + * `listViews` is the protocol's strict record by reference (objectui#7928), so + * nothing `ListViewSchema` declares reaches it, and it has ONE nesting: the + * record refuses a named view's `options` bag whole (`unrecognized_keys` naming + * `options`), and `generateViewSchema` no longer reads that bag. The `kanban` + * block takes the SAME guidance through the named-view door (`custom` at + * `listViews.KEY.kanban.groupBy`, objectui#10321, beside the protocol's own + * `unrecognized_keys`) — see `checkNamedViewKanbanStrayGroupBy` below. * * ⚠️ Covering the legacy nesting is not optional politeness: the retired * producer (`app-shell`'s `kanbanViewOptions`, objectui#8213) wrote into @@ -943,8 +945,8 @@ const KanbanStrayGroupByRefusal = aliasKeyRefusal( * population re-grouped in silence — option A, which the ruling did not take. * * ⛔ Every channel takes ONE string, read off this arm's own `.description`, - * so the message an author meets cannot depend on which route or nesting they - * wrote. + * so the message an author meets at the key cannot depend on which of those + * three nestings they wrote it in. */ const KanbanConfig = stripImportedDefaults(SpecKanbanConfigSchema).partial().extend({ From 7449bc6a945edc61e86d51d4a014fc5e3292cd09 Mon Sep 17 00:00:00 2001 From: Claude Date: Mon, 28 Sep 2026 08:32:12 +0000 Subject: [PATCH 2/3] chore(changeset): declare the objectui#10905 docblock correction as releasing nothing Claude-Session: https://claude.ai/code/session_012UwY3ahMixEFkfTUxMVkYm Co-authored-by: Claude --- .changeset/10905-types-stale-docblocks.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 .changeset/10905-types-stale-docblocks.md diff --git a/.changeset/10905-types-stale-docblocks.md b/.changeset/10905-types-stale-docblocks.md new file mode 100644 index 0000000000..3db066a3df --- /dev/null +++ b/.changeset/10905-types-stale-docblocks.md @@ -0,0 +1,19 @@ +--- +--- + +Comment-only correction in `@object-ui/types`; releases nothing (objectui#10905). + +Two source docblocks still described shapes that objectui#10770 and objectui#7928 +changed earlier in this same unreleased batch. The `ObjectChartSchema.series` +docblock said a `type` written on the `{ dataKey }` arm is an excess property on +a literal typed by the interface; since the `{ name }` arm is the spec's +`ChartSeries`, which declares `type`, that literal compiles, and only the zod +mirror still strips the key. The zod route overview headed "WHERE THIS ARM IS +INSTALLED" said a named view's `listViews` is unmirrored and named a `custom` +issue under `options.kanban` there; `listViews` is the protocol's strict record +by reference, which refuses a named view's `options` bag whole, and the named-view +check reports at `listViews.KEY.kanban.groupBy` only. + +No behaviour, type, accept set or `.describe()` string moves. The `series` +sentence is emitted into the published `.d.ts`, but it and the change that made it +false are both unreleased, so no release ever carried the false text. From 950bf6406e79a5a39aa73ccb34834aa221aa69b8 Mon Sep 17 00:00:00 2001 From: Claude Date: Mon, 28 Sep 2026 08:35:51 +0000 Subject: [PATCH 3/3] chore(changeset): say both objectui#10905 docblocks ship only as comment text Claude-Session: https://claude.ai/code/session_012UwY3ahMixEFkfTUxMVkYm Co-authored-by: Claude --- .changeset/10905-types-stale-docblocks.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/.changeset/10905-types-stale-docblocks.md b/.changeset/10905-types-stale-docblocks.md index 3db066a3df..78d41c8e27 100644 --- a/.changeset/10905-types-stale-docblocks.md +++ b/.changeset/10905-types-stale-docblocks.md @@ -14,6 +14,7 @@ issue under `options.kanban` there; `listViews` is the protocol's strict record by reference, which refuses a named view's `options` bag whole, and the named-view check reports at `listViews.KEY.kanban.groupBy` only. -No behaviour, type, accept set or `.describe()` string moves. The `series` -sentence is emitted into the published `.d.ts`, but it and the change that made it -false are both unreleased, so no release ever carried the false text. +No behaviour, type, accept set or `.describe()` string moves. Both docblocks reach +the build output only as comment text (the `series` one in the emitted `.d.ts`, +the route overview in the zod module's JavaScript), so there is nothing for a +consumer to act on.