feat(types): the widget slot's component arm declares the spec's widget layout (objectui#11070 round 11)

[objectstack-fleet]

Refs #11070
Clause-②: yes (widening). The strict face is expected to accept layout on a metric-card slot, and options.description if the spec carries it. It is priced in the changeset.

Round 11 of objectui#11070, the two dashboard keys the domain:spec pointers routed here (5928509607, 5930223710), claim 5933040700. Base 2e060ba6 (carries PR #11377); merged with origin/main at 3ae91930; head cbc637c2.

• (i) The widget layout: done. The widget slot's component arm declares layout by reference to the spec's widget layout, on both faces.
• (ii) options.description: stopped at needs_decision, nothing declared. @objectstack/spec 17.5.0 does not declare it, so under the order's rule it is the spec lane's call. This PR only makes the read-site comments true. The question, with the four-axis analysis, is in the report on objectui#11070.

(i) layout — producer / reader / declaration

	Where	What it does with layout
Producer	DashboardGridLayout's Save Layout, mergeLayoutIntoSchema	Writes layout: { x, y, w, h } onto every widgets[] entry it can match by id, a metric-card component node included. The README's documented persistence route hands that document to client.meta.saveItem.
Readers	DashboardGridLayout (buildDefaultLayouts, widgetsSignature), DashboardRenderer (inferredColumns, renderWidget), DashboardWithConfig	Place each entry by its x / y / w / h, defaulting a missing one.
Spec	@objectstack/spec 17.5.0 DashboardWidgetSchema.shape.layout	An optional strict object of four numbers, no other key. This is the shape the producer writes, so the order's STOP condition does not apply.
Widget arm (before and after)	zod/complex.zod.ts DashboardWidgetSchema	Takes the spec's member by reference (specFieldsExcept). It accepted layout on both faces at base.
Component arm, base	DashboardWidgetSlotComponentSchema	Declared no layout. The tolerant face kept any value through BaseSchema's passthrough. The strict face refused it: unrecognized_keys: ['layout'] on that arm, and the union refused the widget.
Component arm, head	same	Declares layout: stripImportedDefaults(SpecDashboardWidgetSchema).shape.layout (zod) and layout?: SpecDashboardWidget['layout'] (TypeScript).

Measured on the built @object-ui/types dist with a scratch probe, at base and at head, a dashboard holding { type: 'metric-card', title: 'Revenue', value: '1', layout: { x: 0, y: 0, w: 3, h: 2 } }:

Case	Strict, base	Strict, head	Tolerant, base	Tolerant, head
layout as Save Layout writes it	REFUSE (layout unrecognized)	ACCEPT	ACCEPT	ACCEPT
x: 'a'	REFUSE	REFUSE (at layout.x)	ACCEPT	REFUSE
h missing	REFUSE	REFUSE (at layout.h)	ACCEPT	REFUSE
extra key z	REFUSE	REFUSE (at layout)	ACCEPT	REFUSE
no layout (control)	ACCEPT	ACCEPT	ACCEPT	ACCEPT
spec metric widget with layout (control)	ACCEPT	ACCEPT	ACCEPT	ACCEPT

The bold cells are the one narrowing: a malformed layout on a component node is now refused on the tolerant face, as it already was on the widget arm. The changeset states it, and prices the change as minor (§9: never major).

The pin. plugin-dashboard/src/__tests__/metricCardRegisteredInputsStrictFace-11022.test.ts, extended:

• It runs the producer itself (mergeLayoutIntoSchema) and parses its output on the strict face, so it measures what Save Layout writes rather than a copy of it.
• Its malformed-layout controls read the component arm's own verdict, not the widget arm's.
• It checks that both arms judge layout exactly as the spec's member does.
• It adds a TypeScript-face @ts-expect-error on a malformed literal.

The types-side pin strict-widget-slot-registered-inputs-11022.test.ts now reads the arm's key set as the base's plus layout.

(ii) options.description — producer / reader / declaration (no change)

	Where	Reading
Spec	@objectstack/spec 17.5.0 DashboardWidgetOptionsSchema	Declares no description member. Its open catchall (unknown) admits the key unjudged. The spec's own docblock at objectstack main says it "stays undeclared", and objectstack's check:widget-option-census keeps it in a ledger as an undeclared resolver output.
Served-path writer	objectstack translateDashboard (packages/spec/src/system/i18n-resolver.ts, objectstack main b9087d77e)	if (subCaption) next.options = { ...w.options, description: subCaption };, live.
Authored writers	objectui catalog, docs, designers; objectstack examples	None found. No bundle in either repository's apps, examples or platform objects carries a subCaption entry.
Readers	DatasetWidget (metric caption row), widgetSubCaption.ts (limb 1), DashboardRenderer inline arms (via tWidgetSubCaption)	Read it as a string or an inline per-locale map.
Strict face	StrictAnyComponentSchema	REFUSES it as unrecognized_keys, exactly like the undeclared control key notAKey11070. Ruling C on objectui#11228 keeps that refusal. The tolerant face and the spec accept it.

What changed here is comments only: DatasetWidget.tsx said the slot was "declared end to end", and widgetSubCaption.ts said the spec "admits" it as a typed value. Both now say it is wired but not declared, and that its status is an open decision on objectui#11070.

M3 (scripts/measure-strict-authoring-face.mjs --json), base vs head

• totals are identical at base (2e060ba6) and at head (9efb7a34): 2230 nodes, 77 strict-refused, 46 strict-only, 31 red today, 602 documents, 72 whole-tree refusals and 24 whole-document red.
• The dashboard row is identical: 15 documents, 6 strict-refused.
• The one moved figure is rendererMentionsOfUndeclaredKeys.key, 9110 to 9113. It is a text count of the word in renderer source, moved by this PR's comment prose.
• No corpus document writes layout on a component node, so hypothesis H3 holds.

Ablations (predictions were written before each run)

• Leg A, zod face. The mutation deletes the slot arm's layout member through ablation-replace.mjs (anchor 1 to 0, blob 239db046 to 55d40c71). The subject is source: the root vitest config aliases @object-ui/types/zod to src.
  • Predicted: 6 failed / 25 passed over the two pins, naming five plugin-dashboard tests (strict-face parse, three malformed controls, both-arms equivalence) and one types test (the arm key set).
  • Observed: exactly those 6 failed, 25 passed.
  • Restore proven: the blob equals HEAD and git diff HEAD is empty.
• Leg B, TypeScript face. The mutation deletes layout?: SpecDashboardWidget['layout']; from complex.ts, then rebuilds @object-ui/types. The dist/complex.d.ts marker count was 0, and the tree was otherwise clean.
  • Predicted: @object-ui/plugin-dashboard type-check fails with exactly one TS2578 (unused @ts-expect-error) in the pin.
  • Observed: exit 2, exactly that one error.
  • Restore: rebuilt, marker count back to 1, type-check exit 0 with 0 errors.
• (ii) declares nothing, so it has no ablation.

Gates, at head cbc637c2 unless noted

• type-check (exit 0): @object-ui/types, @object-ui/plugin-dashboard, @object-ui/app-shell, @object-ui/plugin-designer, @object-ui/plugin-list, @object-ui/sdui-parser, @object-ui/core, examples/schema-catalog.
  • Census: every workspace package whose source or tests name DashboardComponentSchema, DashboardWidgetSlotComponentSchema or DashboardWidgetSchema (the types whose shape moved), found by git grep, plus the order's named set.
  • Built first: their ^... closures, with turbo --concurrency=2.
  • @object-ui/i18n is not touched.
• vitest --maxWorkers=2: packages/types/, packages/plugin-dashboard/, examples/schema-catalog/ and the sdui-parser widget-options census. 508 files, 11690 passed, 6 skipped, 0 failed.
• Docs and bytes: check:doc-snippets (its own --build-filter closure built), check:doc-fences, docs:check-links, check:control-bytes, check-doc-component-types, check-doc-example-ids, check:readme-exports and check:new-line-citations all exit 0.
• Changesets: check:changeset-claims (report-only; the 31 bodies it names were read and none is falsified by this change), check:pending-changeset-literals, check-changeset-presence (9 source files of 2 released packages, 1 changeset) and changeset:check all exit 0.
• Dated notes on .changeset/11348-dashboard-widget-reads.md and .changeset/11022-strict-widget-slot-registered-inputs.md, whose component-arm statements this round makes false.
• Lint, narrowed to the 9 changed .ts / .tsx files with the root eslint.config.js:
  • Population: its files: ['**/*.{ts,tsx}'] block. Count: 9 files in --format json.
  • Result: 0 errors at head; warnings per file identical to the merge base (41 = 41).
  • Invariance: no rule is type-aware (no parserOptions.project or projectService in the config), and no custom rule in eslint-rules/ reads another file, so this diff cannot move a verdict in an untouched file.
• NOT MEASURED, declared to CI: check:docs-route-closure (needs the site build), check:published-dist, the Spec Main Shape Gate, and the repo-wide pnpm lint.

Acceptance notes

• Partial layout writers (out of scope; filed through the report for the seat). DashboardWidgetInspector (app-shell metadata admin), DashboardWithConfig and the designer's DashboardEditor write { ...(widget.layout ?? {}), w }, cast to DashboardWidgetSchema['layout']. On a widget with no layout that is { w }, which the spec's layout refuses (x, y and h missing). Before this round the tolerant face kept such a value on a component node; it now refuses it there too, as it always did on the widget arm.
• Legacy envelope. The legacy { id, component, layout } envelope's component is still judged as a bare BaseSchema node on the strict face (the objectui#11022 changeset says so). Its layout was never refused.
• The 7293 changeset. .changeset/7293-dataset-metric-subcaption.md speaks of a sub-caption "its author declared in options.description". This round does not make that false, but whichever way (ii) is decided, that round should re-read it.

---

Generated by Claude Code

[github-actions]

changeset-claim-re-read

⚠️ 31 pending changeset(s) describe a file this change touches

Their bodies publish verbatim into the CHANGELOG at the next release, so this is a request to re-read them against your diff — addressed here because you are the one seat that can answer it without re-deriving anything.

⛔ Nothing here blocks, and nothing here is a verdict on your change. This gate exits 0, is not a required context, and judges name resolution, never meaning: it asked whether a pending body names a file you touched. "Is this sentence still true?" is the one question it will not answer, and the one you are being asked to answer.

.changeset/11068-grid-declared-keys.md

• names schema-reference.md → content/docs/api/schema-reference.md — edited by this change

  What was wrong. ObjectGridSchema declared eight keys the grid never read. An author who wrote description, emptyState, name, placeholder, rowSpecActions or bulkSpecActions on an object-grid got no type error, no validator refusal and no effect. The reference example in schema-reference.md taught description and showFilters as if they worked. It now authors only keys the grid reads.

.changeset/3917-retire-action-condition-branch.md

• names content/docs/api/schema-reference.md → content/docs/api/schema-reference.md — edited by this change

  • ActionCondition is removed from @object-ui/types (and from the barrel export). - ActionSchema.condition is retyped to the predicate the runtime actually honours: boolean | string | { dialect?: string; source: string } — the same three arms ActionRunner's own ActionDef.condition carries, and the same vocabulary visible and disabled use. - ActionConditionSchema is removed from @object-ui/types/zod (and from the zod barrel); the condition key now validates against that predicate union. - The two teaching sites (content/docs/core/enhanced-actions.mdx Conditional Execution, content/docs/api/schema-reference.md ActionSchema table) are rewritten to the live vocabulary: condition is a gate; a branch is expressed as separate actions with mutually exclusive conditions.

.changeset/6170-retire-timeline-dead-keys.md

• names content/docs/api/schema-reference.md → content/docs/api/schema-reference.md — edited by this change

  Also in this change: the in-repo example packages/types/examples/data-display-examples.json (its timeline node authored all three) is migrated to items / variant; the two content/docs/api/schema-reference.md snippets that authored events: [] now author items: []; and the plugin-timeline docs callout says retired rather than deprecated.

.changeset/6687-chatbot-surface-authorable.md

• names packages/types/src/complex.ts → packages/types/src/complex.ts — edited by this change

  Measured on both declaration faces before the fix, each with a control that had to hit: schema.surface appeared 0 times in renderer.tsx against schema.placeholder at 3 (one per registration) and schema.processVisibility at 1; and ChatbotSchema (packages/types/src/complex.ts) declared 34 keys, not this one. Two faces agreeing is what made the zero a reading rather than a bad query.

.changeset/6896-retire-chart-inline-data.md

• names content/docs/api/schema-reference.md → content/docs/api/schema-reference.md — edited by this change

  ⚠️ One correction to the record the ruling rests on. The ruling states zero authorship of a populated series[].data outside tests across packages/ / apps/ / examples/. The re-measurement finds one such site inside those roots — packages/types/examples/data-display-examples.json (2 series) — plus four outside them, in documentation: content/docs/api/schema-reference.md (3) and content/docs/core/report-schema.mdx (1).

.changeset/6939-kanban-column-cards.md

• names complex.ts → packages/types/src/complex.ts — edited by this change

  Breaking, deliberately. KanbanColumn declared its card list as items in complex.ts and in the zod mirror complex.zod.ts. Every board reads cards. Measured on origin/main 78a3cc238: KanbanImpl.tsx reads .cards on 12 lines, KanbanEnhanced.tsx on 8, and bucketCardsIntoColumns twice more as col.cards || []; .items had zero read sites in either board (a same-shaped .title control on the same two files returns 8 and 3, so those zeros are readings and not a mis-shaped probe). Both catalog entries, the plugin docs and content/docs/api/schema-reference.md all author cards.

• names complex.zod.ts → packages/types/src/zod/complex.zod.ts — edited by this change

  Breaking, deliberately. KanbanColumn declared its card list as items in complex.ts and in the zod mirror complex.zod.ts. Every board reads cards. Measured on origin/main 78a3cc238: KanbanImpl.tsx reads .cards on 12 lines, KanbanEnhanced.tsx on 8, and bucketCardsIntoColumns twice more as col.cards || []; .items had zero read sites in either board (a same-shaped .title control on the same two files returns 8 and 3, so those zeros are readings and not a mis-shaped probe). Both catalog entries, the plugin docs and content/docs/api/schema-reference.md all author cards.

• names content/docs/api/schema-reference.md → content/docs/api/schema-reference.md — edited by this change

  Breaking, deliberately. KanbanColumn declared its card list as items in complex.ts and in the zod mirror complex.zod.ts. Every board reads cards. Measured on origin/main 78a3cc238: KanbanImpl.tsx reads .cards on 12 lines, KanbanEnhanced.tsx on 8, and bucketCardsIntoColumns twice more as col.cards || []; .items had zero read sites in either board (a same-shaped .title control on the same two files returns 8 and 3, so those zeros are readings and not a mis-shaped probe). Both catalog entries, the plugin docs and content/docs/api/schema-reference.md all author cards.

.changeset/6951-tree-view-data-retired.md

• names content/docs/api/schema-reference.md → content/docs/api/schema-reference.md — edited by this change

  What was measured, on this branch's base. TreeViewSchema declared two spellings for its one inline-nodes slot — nodes (read second) and data (read third: boundData || schema.nodes || schema.data || [] at renderers/data-display/tree-view.tsx:105), both declared by objectui#6150. data had been REQUIRED until 777e5c6f4 (PR fix(types): tree-view mirror stops requiring the limb it reads third (group 2 of objectui#6939) #7533) made it optional, so this retirement starts from a declared-and-optional member on both faces. The in-repo corpus at the retirement: seven tree-view nodes under examples/schema-catalog and packages/types/examples plus one content/docs fence — six on nodes, two on data (packages/types/examples/data-display-examples.json and content/docs/api/schema-reference.md), both rewritten; no package source authored either spelling.

.changeset/7113-chart-data-model.md

• names complex.zod.ts → packages/types/src/zod/complex.zod.ts — edited by this change

  .extend() with a NEW key still works and preserves the fold and the refinement; .optional(), z.discriminatedUnion, z.toJSONSchema and safeValidateSchema are all unaffected. Nothing in this repository calls the throwing combinators on either const, and the published surface already ships refined mirrors (objectql.zod.ts, complex.zod.ts, form.zod.ts, app.zod.ts), so the class is not new — but it is a real behaviour change on a published export and it belongs in the release note rather than in a reviewer's file.

.changeset/7125-dashboard-empty-state-keys-retired.md

• names DatasetWidget.tsx → packages/plugin-dashboard/src/DatasetWidget.tsx — edited by this change

  Not touched: table.noRows ('No rows to display') and engine.form.noRows (packages/app-shell/src/views/metadata-admin/i18n.ts, read at widgets.tsx) — two different, same-named keys in different namespaces. Nor the comments in WidgetEmptyState.tsx, DatasetWidget.tsx, ObjectDataTable.tsx and PivotTable.tsx that record WHY three widgets with three strings became one shared empty state; the packs' own comment keeps that rationale and now names the retirement instead of a row that is gone.

.changeset/7295-chat-message-avatar-keys.md

• names packages/types/src/complex.ts → packages/types/src/complex.ts — edited by this change

  packages/plugin-chatbot/src/index.tsx:173–178 reads message.avatar || userAvatarUrl and message.avatarFallback || userAvatarFallback (and the assistant twins), the authoring-to-runtime seam spreads every unlisted key through (chatMessageAdapter.ts, ...passthrough), and the SDUI renderer feeds the authored messages[] straight in — a per-message avatar override renders, is documented, and no authoring-facing type declared it. ChatMessage in packages/types/src/complex.ts has no index signature (objectui#5155, deliberately — none is added here), so an author annotating ChatbotSchema.messages was told a value that renders is an error (TS2353); the zod mirror ChatMessageSchema is a plain strip-mode z.object, so the value parsed green and was silently DROPPED from the parsed output.

.changeset/7655-chatbot-registration-authoring-faces.md

• names complex.ts → packages/types/src/complex.ts — edited by this change

  New published symbol: ChatbotSharedKey, the string-literal union of the twenty keys all three registrations read. It is exported from complex.ts because an exported interface may not extend a Pick over a private name (TS4022), so it is emitted into dist/complex.d.ts and is reachable through the published @object-ui/types/complex subpath (it is not re-exported from the package entry). It is a census, not an authoring face.

.changeset/7664-kanban-arm-plugin-dialect.md

• names content/docs/api/schema-reference.md → content/docs/api/schema-reference.md — edited by this change

  Migration. Author boards in the plugin dialect — objectName + groupBy for an object-bound board, or columns[].cards[] with badges for a static one. Replace DeclarativeKanbanSchema imports with KanbanSchema (from @object-ui/types, or the Zod KanbanSchema from @object-ui/types/zod; @object-ui/plugin-kanban re-exports the same KanbanSchema type). Delete draggable (drag-and-drop is always on) and column color (style a lane through className). content/docs/api/schema-reference.md's kanban section now documents this dialect.

.changeset/7703-chatbot-dark-keys-retired.md

• names packages/types/src/complex.ts → packages/types/src/complex.ts — edited by this change

  Each member goes to ?: never on packages/types/src/complex.ts and to retirementTombstone(...) on packages/types/src/zod/complex.zod.ts — both halves, in lockstep, the convention MarkdownSchema.sanitize (objectui#6972), TimelineSchema.timeScale (objectui#6355) and ObjectViewSchema.viewTabBar (objectui#7779) already carry. Each refusal names the key, says why it is retired, and points at what to write instead; one string feeds both the parse-time message and the .describe() metadata, so the two cannot drift.

• names packages/types/src/zod/complex.zod.ts → packages/types/src/zod/complex.zod.ts — edited by this change

  Each member goes to ?: never on packages/types/src/complex.ts and to retirementTombstone(...) on packages/types/src/zod/complex.zod.ts — both halves, in lockstep, the convention MarkdownSchema.sanitize (objectui#6972), TimelineSchema.timeScale (objectui#6355) and ObjectViewSchema.viewTabBar (objectui#7779) already carry. Each refusal names the key, says why it is retired, and points at what to write instead; one string feeds both the parse-time message and the .describe() metadata, so the two cannot drift.

.changeset/7997-detail-view-related-retired.md

• names content/docs/api/schema-reference.md → content/docs/api/schema-reference.md — edited by this change

  Documentation. packages/plugin-detail/README.md and content/docs/api/schema-reference.md stop teaching the retired array and gain a migration block each.

.changeset/8114-detail-tab-activity-timeline.md

• names plugin-dashboard/README.md → packages/plugin-dashboard/README.md — edited by this change

  README.md ships in this package's files, so the example went out in every tarball. DetailTabs renders a tab's content through ANGLE-BRACKETS(SchemaRenderer schema={toRenderableSchema(tab.content)} /), which makes content.type an SDUI node position judged by the component registry — so a reader copying the tab got the registry's Unknown component type panel (OBJUI-001) where the timeline should be. Same shape as the line-chart widget in plugin-dashboard/README.md (objectui#7896's census; fixed by objectui#7951) and the fourth known instance.

.changeset/8268-testid-emitted-as-data-testid.md

• names content/docs/api/schema-reference.md → content/docs/api/schema-reference.md — edited by this change

  The other direction — retiring the promise — was considered and declined. It is what c1fe272ad did for BaseSchema.hidden, but that key had a working behaviour to describe and zero named consumers, and the ruling's decline turned on exactly that. This promise already has carriers outside the type declaration: content/docs/api/schema-reference.md states it as a table row and authors testId in that page's own base-schema example, @object-ui/cli's OBJECTUI_STRUCTURAL_KEYS identifies a file as an ObjectUI schema node by this key, at this change ObjectGridSlotKey / ObjectFormSlotKey pin it, SchemaBuilder.testId() writes it, and ADR-0054 C4 — shipped — reads "the renderer emits data-testid … derived from metadata".

.changeset/8415-filter-builder-condition-id.md

• names complex.ts → packages/types/src/complex.ts — edited by this change

  Breaking for authored metadata: a filter-builder CONDITION must now declare id (objectui#8415). It is declared on both published faces — the TypeScript interface FilterBuilderCondition in complex.ts and the Zod mirror FilterBuilderConditionSchema in zod/complex.zod.ts — so a key the renderer has always required is finally validated instead of silently discarded.

• names zod/complex.zod.ts → packages/types/src/zod/complex.zod.ts — edited by this change

  Breaking for authored metadata: a filter-builder CONDITION must now declare id (objectui#8415). It is declared on both published faces — the TypeScript interface FilterBuilderCondition in complex.ts and the Zod mirror FilterBuilderConditionSchema in zod/complex.zod.ts — so a key the renderer has always required is finally validated instead of silently discarded.

.changeset/8478-describe-line-addresses.md

• names complex.zod.ts → packages/types/src/zod/complex.zod.ts — edited by this change

  The remaining 15 addresses (form.zod.ts, layout.zod.ts, complex.zod.ts) were out of scope for this PR — form.zod.ts / layout.zod.ts were held while PR fix(types): arm AnyComponentSchema for seven registered node-slot renderers (objectui#8499) #8763 was open; complex.zod.ts's hold (PR feat(types): FilterFieldSchema.type — the published doc's fourteen members, optional #8766) cleared when that PR merged during this round, so its 6 addresses returned to the queue rather than riding this PR's scope.

.changeset/8478-zod-pins-complex.md

• names packages/types/src/zod/complex.zod.ts → packages/types/src/zod/complex.zod.ts — edited by this change

  Remove stale source-line citations (NAME.ext:NNN) from all 6 published .describe() schema descriptions in packages/types/src/zod/complex.zod.ts (finding(types): 27 published .describe() schema descriptions in packages/types/src/zod/** cite source line addresses — the authorable surface carries a citation nothing reads #8478) — the last file of this card's remainder, which the card now closes.

.changeset/8478-zod-pins-form-layout.md

• names zod/complex.zod.ts → packages/types/src/zod/complex.zod.ts — edited by this change

  The remaining 6 addresses (zod/complex.zod.ts) stayed out of scope for this PR and returned to the queue rather than riding this PR's scope — the card did not close here.

.changeset/8653-listview-title-retired-rowactiondefs-pinned.md

• names content/docs/api/schema-reference.md → content/docs/api/schema-reference.md — edited by this change

  title — retired. ListView resolved its export filename through schema.label || (schema as any).title. @objectstack/spec/ui's ListViewSchema refuses title by name (unrecognized_keys: ['title']) while ObjectGridPropsSchema accepts it; packages/types mirrors the platform contract rather than ruling over it, so declaring title on ListViewSchema would have made this repo accept what the platform save gate rejects. That asymmetry is also why objectui#6639 could take the declare branch for ObjectGridSchema.title one package over and this site could not. A parse-based census of apps/ examples/ content/ and packages/ found zero list-view nodes authoring title, so the retirement costs no author a filename. Over that same corpus the instrument reports three object-grid nodes carrying the key: two authored ones, both in content/docs/api/schema-reference.md, plus one that is not authored at all — packages/plugin-view/src/ObjectView.tsx composes title: schema.table?.title onto a grid node it builds, so it is a producer writing the key rather than an author declaring it. ObjectGrid's own title reads are untouched — they remain declared, ruled and read.

.changeset/8760-unfulfilled-chart-stubs.md

• names content/docs/plugins/plugin-dashboard.mdx → content/docs/plugins/plugin-dashboard.mdx — edited by this change

  • At render. SchemaRenderer's lazy branch re-checks hasLazy(type) on every pass and returns the Loading ANGLE-BRACKETS(type)… placeholder. Registry.register() deletes a lazy entry only for keys the loaded module actually registers, so for an unfulfilled key the entry SURVIVES the load and every later pass takes the same branch. Measured on b775500af through the real chain: { "type": "line-chart" } painted role="status" / data-lazy-loading="line-chart" / Loading line-chart…, permanently. Not the OBJUI-001 panel the card expected — no alert, no error, no console warning. A skeleton that never resolves reads to a user as a slow network. - At authoring. A stub is enough to put a key into getKnownTypes(), so check:doc-types and the CLI's generated KNOWN_SCHEMA_TYPES snapshot both blessed all three. content/docs/plugins/plugin-dashboard.mdx taught "type": "line-chart" inside a card body, and every gate was green on it.

.changeset/8801-object-kanban-allow-collapse-retired.md

• names packages/types/src/zod/complex.zod.ts → packages/types/src/zod/complex.zod.ts — edited by this change

  • the declarations retired here — packages/types/src/objectql.ts and its mirror packages/types/src/zod/objectql.zod.ts; - the pins that assert the retirement — object-kanban-allow-collapse-retired-8801.test.ts and bare-kanban-node-key-retired-8802.test.ts; - a comment in packages/types/src/zod/complex.zod.ts, recording that the deleted retiredZeroReadKanbanKey helper once carried this spelling on the SIBLING arm; - one row of content/docs/api/schema-reference.md; - the .changeset/ release notes that discuss it — this one, the two historical entries covering the sibling arm's own spelling, and objectui#9629's note recording the correction to this paragraph.

• names content/docs/api/schema-reference.md → content/docs/api/schema-reference.md — edited by this change

  • the declarations retired here — packages/types/src/objectql.ts and its mirror packages/types/src/zod/objectql.zod.ts; - the pins that assert the retirement — object-kanban-allow-collapse-retired-8801.test.ts and bare-kanban-node-key-retired-8802.test.ts; - a comment in packages/types/src/zod/complex.zod.ts, recording that the deleted retiredZeroReadKanbanKey helper once carried this spelling on the SIBLING arm; - one row of content/docs/api/schema-reference.md; - the .changeset/ release notes that discuss it — this one, the two historical entries covering the sibling arm's own spelling, and objectui#9629's note recording the correction to this paragraph.

.changeset/8802-8257-8008-kanban-gantt-family-retirement.md

• names complex.ts → packages/types/src/complex.ts — edited by this change

  What each retirement was, measured. Three of the four were registration-only: no schema face in @object-ui/types ever declared kanban-ui, kanban-enhanced or gantt as a component node type, so unregistering is the whole retirement. The bare kanban key was the exception — it had a declared arm on both faces (KanbanSchema in complex.ts and its Zod mirror), and a plain deletion there would have been the objectui#7664 failure: BaseSchema is .passthrough(), so a document naming a dropped key validates green and renders nothing. It therefore retires as a named refusal: the Zod union keeps an arm claiming the literal and answers a { "type": "kanban" } document with a message naming object-kanban as the remedy, while the TypeScript half is the absence of the arm from ComplexSchema and of the key from SchemaRegistry, so tsc refuses it at the authoring site.

.changeset/9187-record-highlights-layout-two-values.md

• names content/docs/api/schema-reference.md → content/docs/api/schema-reference.md — edited by this change

  ⚠️ The census behind this narrowing covers this repository only, and it found no in-repo authoring to migrate: every in-tree layout: 'grid' belongs to a different component (detail-view in content/docs/api/schema-reference.md and phase2-schemas.test.ts, ai-recommendations in packages/plugin-ai/README.md), and the one in-repo consumer of this interface that writes a layout (p1-spec-alignment.test.ts) writes 'horizontal'. So no document in this repository stops type-checking. A TypeScript consumer outside this repo that wrote grid is not observable from here and gets a compile error (TS2322) naming the key — which is why the FROM/TO is spelled out above.

.changeset/9628-kanban-column-collapsed-honoured.md

• names complex.ts → packages/types/src/complex.ts — edited by this change

  The key was declared on both published faces of the object-kanban arm — the lane element of ObjectKanbanSchema (objectql.ts and its Zod mirror) and the runtime lane KanbanColumn (complex.ts and its mirror) — and read by KanbanEnhanced alone, a module no production source imports. An authored { "id": "todo", "title": "To Do", "collapsed": true } therefore parsed green on both faces and reached a board that did nothing with it: KanbanImpl's only collapse is the SWIMLANE row's, held in viewer state under objectui:kanban-collapsed:ANGLE-BRACKETS(swimlaneField) and never keyed to a lane's declared value. That is the ADR-0049 declared-but-unhonoured shape.

.changeset/calendar-readme-schema-keys-5045.md

• names packages/types/src/complex.ts → packages/types/src/complex.ts — edited by this change

  README.md's "Schema API / CalendarView" block described a CalendarViewSchema that does not exist. Measured against the interface itself (packages/types/src/complex.ts) and its zod mirror: events — the schema's only required key besides type — was published as events?, so a reader following the README omits it and TypeScript rejects the node; defaultDate was string where the schema says string | Date; and onDateClick was listed as a schema key when it is a CalendarViewProps component prop, sending readers to a different package's surface for a key calendar-view does not have (the schema's key is onDateChange). The block also listed 6 of the schema's 13 keys with nothing saying it was a summary (objectui#5045).

.changeset/calendar-view-schema-converge.md

• names content/docs/api/schema-reference.md → content/docs/api/schema-reference.md — edited by this change

  Runtime renderer behaviour is unchanged. @object-ui/plugin-calendar's README and content/docs/api/schema-reference.md are repaired to the converged surface in the same change, so no copy of the old contradiction survives.

.changeset/issue-5373-retire-crud-schema.md

• names content/docs/api/schema-reference.md → content/docs/api/schema-reference.md — edited by this change

  crud had four declaration faces and no registered renderer, for the whole life of the key: the TS interface (packages/types/src/crud.ts), the zod mirror (packages/types/src/zod/crud.zod.ts), a dedicated branch in validateSchema that affirmatively PASSED it, and CRUDBuilder in @object-ui/core. A node spelling it painted the OBJUI-001 "Unknown component type" panel, and content/docs/api/schema-reference.md published it as reference material — so a reader (or an AI author) who copied the page got a red panel.

• names api/schema-reference.md → content/docs/api/schema-reference.md — edited by this change

  Authoring crud is now REFUSED BY NAME rather than passed or silently ignored. validateSchema returns an error with code: 'RETIRED_TYPE' on schema.type — at any depth, since it is what validateChildren recurses with — so assertValidSchema throws and isValidSchema answers false. The message names the migration: object-grid for the record table with its toolbar, filters, pagination and row/batch actions, object-form for the create/edit form, and detail for the record view. api/schema-reference.md is rewritten around those shapes.

.changeset/object-view-unmirrored-keys-7779.md

• names content/docs/api/schema-reference.md → content/docs/api/schema-reference.md — edited by this change

  listViews stays unmirrored, on the ruling's own fallback clause. The declaration's value is the local NamedListView — 64 declared top-level members (⚠️ re-taken at objectui#8980, which added the seventeen the protocol declares on this surface to the 47 this entry first measured), of which the renderer reads 21 off a named view. data is one of the 21 now: it used to reach the renderer through an as any cast on the named-view config in packages/plugin-view/src/ObjectView.tsx and be declared nowhere, and the objectui#8980 ruling declared it by name — objectui#7928's open half, answered. The spec's ViewSchema.listViews is a record of the STRICT ObjectListViewSchema, which requires columns and refuses options, ObjectQL tuple filters and default — that is, it refused the named views this package's own README and content/docs/api/schema-reference.md taught when this entry was written ({ label: 'All Users' } fails at columns; filter: [["owner", "=", "..."]] fails at filter.0), and objectui#8255 has since rewritten them in the spec shape. Mirroring the spec value would have lost documented behaviour; mirroring the local value would enforce 43 unread members (64 declared, minus the 21 that are both declared and read) into the contract — the very thing ruling B refused for the six local keys. The key therefore stays in the parity ledger with that measurement, pinned, until the maintainer decides its value type. It is not papered over with z.any().

.changeset/table-renderer-declared-column-contract-5350.md

• names content/docs/api/schema-reference.md → content/docs/api/schema-reference.md — edited by this change

  What makes this site different from its three siblings is that the alias was not merely tolerated, it was published. content/docs/api/schema-reference.md §TableSchema shipped a copyable { "name": "id", "label": "#" } example and a property row reading "Column definitions with name, label, …", while packages/types declared the opposite pair. Docs and type disagreed about one type they both call TableColumn, each internally consistent. Retiring the alias without correcting the page would have turned a documented, working example into a silently broken one, so both halves land together: the page now authors accessorKey/header. The same row also advertised a render property that TableColumn has never declared — the renderer's hook is cell — and that claim is dropped rather than re-spelled.

Read the paragraph, not the line: both false halves of the objectui#8617 claim sat in one paragraph, and correcting either alone would have left it asserting the same wrong thing.

If a claim did go false, correct the body. That is precedented and prose-only, frontmatter untouched; check-changeset-overwrite.mjs will report the correction as its own case 2 ("correcting a declaration on purpose … legitimate"), which is the intended shape — one gate asks for the read, the other records the write.

Not covered, stated so nobody reads this as more: a born-false claim that spells no line address at all (objectui#9495 coordinated one by ORDINAL — "a grep finds that member first" — and deciding that means reading what the sentence means), a claim spelled as a symbol or a package rather than a backticked file name, and a file named ambiguously.

Angle-bracketed names in the quoted prose above are rewritten as ANGLE-BRACKETS(name): GitHub deletes tag-shaped fragments from a stored body, and a quote that silently loses the identifier it is about is worse than a visible repair.

Compared the checked-out tree with 3c3ce15a7 (merge-base with origin/main): 13 file(s) changed outside .changeset/, read against 1939 pending declaration(s) that publish a body (2559 pending in total). · run

[github-actions]

✅ Console Performance Budget

Metric	Value	Budget
Eager closure (gzip, 330 chunks)	3552.4 KB	3574.6 KB
Main entry chunk (gzip)	150.3 KB	350 KB
Entry file	index-kJ-LgZ0G.js	—
Status	PASS	—

The eager closure is every chunk the entry reaches through static imports — what the browser fetches and parses before the app renders. The entry chunk on its own is a small fraction of it.

---

📦 Bundle Size Report

Package	Size	Gzipped
app-shell (consoleActionDispatch.js)	0.20KB	0.19KB
app-shell (index.js)	16.88KB	6.25KB
app-shell (runtime-config.js)	20.68KB	7.36KB
app-shell (types.js)	0.01KB	0.04KB
app-shell (urlParams.js)	10.11KB	3.87KB
auth (ActiveOrganizationStorage.js)	27.95KB	10.04KB
auth (AuthContext.js)	0.31KB	0.24KB
auth (AuthGuard.js)	2.07KB	1.00KB
auth (AuthProvider.js)	40.22KB	10.61KB
auth (AuthShell.js)	3.49KB	1.40KB
auth (ForgotPasswordForm.js)	12.21KB	3.45KB
auth (LoginForm.js)	18.17KB	5.40KB
auth (PreviewBanner.js)	0.90KB	0.50KB
auth (RegisterForm.js)	6.72KB	2.24KB
auth (SocialSignInButtons.js)	9.70KB	3.93KB
auth (UserMenu.js)	3.39KB	1.21KB
auth (auth-gate-events.js)	1.29KB	0.66KB
auth (authStyles.js)	5.04KB	1.72KB
auth (createAuthClient.js)	40.70KB	10.94KB
auth (createAuthenticatedFetch.js)	8.54KB	3.46KB
auth (index.js)	3.63KB	1.64KB
auth (invitation-status.js)	1.22KB	0.70KB
auth (org-roles.js)	6.66KB	2.78KB
auth (phone-identifier.js)	1.11KB	0.66KB
auth (types.js)	0.59KB	0.35KB
auth (useAuth.js)	5.30KB	1.02KB
auth (useWorkspaceAdminStatus.js)	11.08KB	4.58KB
collaboration (CommentThread.js)	27.13KB	7.95KB
collaboration (LiveCursors.js)	3.17KB	1.27KB
collaboration (PresenceAvatars.js)	6.49KB	2.64KB
collaboration (PresenceProvider.js)	2.79KB	1.13KB
collaboration (index.js)	1.68KB	0.73KB
collaboration (useCollaborationTranslation.js)	6.05KB	2.52KB
collaboration (useCommentSearch.js)	1.98KB	0.88KB
collaboration (useConflictResolution.js)	7.75KB	1.86KB
collaboration (useMentionNotifications.js)	1.81KB	0.68KB
collaboration (usePresence.js)	6.33KB	1.84KB
collaboration (useRealtimeSubscription.js)	7.91KB	2.01KB
components (index.js)	570.62KB	136.73KB
core (index.js)	10.00KB	3.96KB
create-plugin (index.js)	27.94KB	9.51KB
data-objectstack (index.js)	230.46KB	63.94KB
fields (index.js)	260.89KB	66.19KB
i18n (LocalizationContext.js)	1.76KB	0.96KB
i18n (builtinAggregateLabels.js)	0.86KB	0.49KB
i18n (currency.js)	2.59KB	1.22KB
i18n (fallbackInterpolation.js)	6.25KB	2.77KB
i18n (i18n.js)	8.87KB	3.64KB
i18n (index.js)	5.24KB	2.27KB
i18n (pickLocalized.js)	9.86KB	3.95KB
i18n (provider.js)	39.35KB	12.88KB
i18n (translateFn.js)	0.20KB	0.18KB
i18n (useDisplayLocale.js)	3.52KB	1.76KB
i18n (useObjectLabel.js)	34.49KB	9.23KB
i18n (useSafeTranslation.js)	5.60KB	2.33KB
layout (index.js)	39.93KB	11.29KB
mobile (MobileProvider.js)	0.92KB	0.49KB
mobile (ResponsiveContainer.js)	0.94KB	0.38KB
mobile (breakpoints.js)	1.51KB	0.70KB
mobile (createOfflineDataSource.js)	5.61KB	1.75KB
mobile (index.js)	1.99KB	0.87KB
mobile (offlineQueue.js)	3.91KB	1.35KB
mobile (pwa.js)	0.97KB	0.49KB
mobile (serviceWorker.js)	1.48KB	0.62KB
mobile (serviceWorkerSource.js)	3.41KB	1.48KB
mobile (useBreakpoint.js)	1.54KB	0.65KB
mobile (useGesture.js)	6.96KB	1.98KB
mobile (useOfflineSync.js)	1.99KB	0.72KB
mobile (usePullToRefresh.js)	6.62KB	2.45KB
mobile (useResponsive.js)	0.72KB	0.42KB
mobile (useSpecGesture.js)	5.52KB	2.10KB
mobile (useTouchTarget.js)	1.01KB	0.54KB
permissions (MePermissionsProvider.js)	13.86KB	5.00KB
permissions (PermissionContext.js)	0.31KB	0.25KB
permissions (PermissionGuard.js)	0.89KB	0.45KB
permissions (PermissionProvider.js)	6.52KB	2.26KB
permissions (discardProofCache.js)	1.04KB	0.55KB
permissions (evaluator.js)	8.33KB	3.07KB
permissions (index.js)	0.93KB	0.41KB
permissions (store.js)	0.91KB	0.42KB
permissions (useFieldPermissions.js)	1.28KB	0.53KB
permissions (usePermissions.js)	4.83KB	2.27KB
plugin-ai (index.js)	16.01KB	3.93KB
plugin-calendar (index.js)	53.15KB	15.45KB
plugin-charts (index.js)	84.07KB	22.93KB
plugin-chatbot (index.js)	198.22KB	46.97KB
plugin-dashboard (index.js)	139.74KB	37.42KB
plugin-designer (index.js)	216.49KB	44.65KB
plugin-detail (index.js)	245.45KB	64.47KB
plugin-editor (index.js)	2.23KB	1.05KB
plugin-form (index.js)	173.14KB	44.58KB
plugin-gantt (index.js)	173.23KB	43.13KB
plugin-grid (index.js)	231.72KB	63.65KB
plugin-kanban (index.js)	49.49KB	15.54KB
plugin-list (index.js)	116.63KB	28.97KB
plugin-map (index.js)	25.60KB	8.62KB
plugin-markdown (index.js)	13.88KB	4.80KB
plugin-report (index.js)	44.04KB	12.21KB
plugin-timeline (index.js)	34.29KB	10.13KB
plugin-tree (index.js)	14.58KB	5.17KB
plugin-view (index.js)	90.32KB	22.76KB
providers (DataSourceProvider.js)	0.75KB	0.39KB
providers (MetadataProvider.js)	1.37KB	0.59KB
providers (ThemeProvider.js)	1.90KB	0.85KB
providers (UploadProvider.js)	11.81KB	3.58KB
providers (index.js)	0.45KB	0.23KB
providers (types.js)	0.01KB	0.04KB
react-runtime (index.js)	5.62KB	2.34KB
react (LazyPluginLoader.js)	4.47KB	1.63KB
react (SchemaRenderer.js)	120.63KB	39.56KB
react (data-invalidation.js)	5.05KB	2.08KB
react (index.js)	4.50KB	2.06KB
react (schema-input.js)	4.25KB	2.04KB
react (spec-input.js)	0.20KB	0.18KB
sdui-parser (body-dialect.js)	4.50KB	1.99KB
sdui-parser (codegen.js)	9.45KB	3.76KB
sdui-parser (dashboard-widget-options.js)	3.08KB	1.30KB
sdui-parser (index.js)	6.06KB	2.68KB
sdui-parser (input-type.js)	2.84KB	1.40KB
sdui-parser (parse.js)	25.28KB	7.80KB
sdui-parser (provenance.js)	3.84KB	1.90KB
sdui-parser (types.js)	0.28KB	0.23KB
sdui-parser (validate.js)	21.42KB	7.05KB
types (ai.js)	4.39KB	2.17KB
types (api-types.js)	0.20KB	0.18KB
types (app.js)	4.12KB	1.61KB
types (base.js)	0.20KB	0.18KB
types (blocks.js)	0.20KB	0.18KB
types (complex.js)	3.19KB	1.62KB
types (crud.js)	0.20KB	0.18KB
types (dashboard-filter-alias.js)	6.23KB	2.74KB
types (data-display.js)	3.75KB	1.85KB
types (data-protocol.js)	0.20KB	0.19KB
types (data.js)	0.20KB	0.18KB
types (designer.js)	1.85KB	0.85KB
types (disclosure.js)	0.20KB	0.18KB
types (error-code.js)	1.54KB	0.88KB
types (expression.js)	0.20KB	0.18KB
types (feedback.js)	0.20KB	0.18KB
types (field-types.js)	0.20KB	0.18KB
types (form.js)	0.20KB	0.18KB
types (http-inflight.js)	8.87KB	3.73KB
types (http-retry.js)	4.32KB	2.02KB
types (icon-key-migration.js)	4.26KB	1.63KB
types (index.js)	4.74KB	2.26KB
types (layout.js)	0.20KB	0.18KB
types (managed-by.js)	0.19KB	0.18KB
types (mobile.js)	5.00KB	2.39KB
types (navigation.js)	0.20KB	0.18KB
types (objectql.js)	0.20KB	0.18KB
types (overlay.js)	0.20KB	0.18KB
types (permissions.js)	2.52KB	1.31KB
types (plugin-scope.js)	0.20KB	0.18KB
types (record-components.js)	0.20KB	0.19KB
types (record-semantics.js)	1.28KB	0.67KB
types (registry.js)	0.20KB	0.18KB
types (reports.js)	0.20KB	0.18KB
types (select-option.js)	0.20KB	0.19KB
types (spec-report.js)	4.99KB	1.96KB
types (spec-ui-namespace.js)	0.20KB	0.19KB
types (strict-authoring-face.js)	21.59KB	7.71KB
types (system-fields.js)	3.33KB	1.54KB
types (theme.js)	6.28KB	2.87KB
types (ui-action.js)	8.11KB	3.32KB
types (views.js)	0.20KB	0.18KB
types (widget.js)	0.20KB	0.18KB

Size Limits

• ✅ Core packages should be < 50KB gzipped
• ✅ Component packages should be < 100KB gzipped
• ⚠️ Plugin packages should be < 150KB gzipped