Found while building the render pin for objectui#8310 (which is about the ARITY of
PageNodeSchema.body, not about this). Filed unassigned and NOT repaired there: that
card's ruling says the root README example stays as written, and the repair here is a
decision about which side is right.
What
The SDUI grid node renders its child list from children and from nothing else:
packages/components/src/renderers/layout/grid.tsx {schema.children && renderChildren(schema.children)}
packages/types/src/layout.ts GridSchema children?: SchemaNode | SchemaNode[];
GridSchema declares no items, and the renderer never reads one. Three teaching
surfaces author the child list as items anyway — including the project's flagship
example on the npm/GitHub landing page:
- root
README.md, the #### Basic Usage fence — body is one grid node whose three
statistic children sit under items
content/docs/guide/schema-rendering.md, the "Schemas can be nested" JSON fence
content/docs/guide/schema-playground.md, the "Project Dashboard" JSON fence
A reader who copies any of them gets a grid element with NO children.
Measured
Rendered through the real SchemaRenderer with the default renderers registered
(packages/components, happy-dom), the README's flagship page — verbatim, items and
all — produced this, with the grid element self-closing:
div class="min-h-full w-full bg-background p-3 md:p-4 lg:p-6" data-obj-type="page" data-page-type="record"
div class="mx-auto space-y-6 max-w-7xl"
div class="space-y-6"
div class="grid grid-cols-1 sm:grid-cols-2 md:grid-cols-3 gap-4" data-obj-type="grid" /
getByText('Total Users') — one of the three statistic labels the example authors —
finds nothing. Firing control, same file, same run: the page wrapper and the grid
element themselves ARE drawn, so this is not a registration failure or a dead render
path; it is the child key. Moving the same three nodes to children draws all three.
Nothing refuses the authored key either: BaseSchema is .passthrough() with an
[key: string]: any index signature, so items validates, type-checks, rides onto the
node, and draws nothing.
Why it is not caught today
pnpm check:doc-types asks of every doc type literal whether the repository registers
that component — grid does exist, so the fence passes. Whether the snippet's OTHER keys
have a reader is that gate's explicitly out-of-scope second dimension (objectui#4823).
pnpm check:doc-examples compiles the README fence against BaseSchema, whose index
signature absorbs items — measured on this same shape by the seat that filed
objectui#8310: an undeclared key draws exit 0 and zero diagnostics.
The decision, not made here
- Fix the three documentation surfaces to
children, the declared and read key. Cheapest,
and it is what coding standard #0.1 (contract-first — fix the metadata, not the renderer)
points at. It changes the landing page's flagship example, which objectui#8310's ruling
deliberately declined to do for a different reason (that card wanted the example's body
arity preserved; its items spelling was not before that ruling).
- Make
grid read items as an alias for children. ⛔ This is the lenient-fallback shape
#0.1 forbids, and it would mint a second child-key dialect on one node.
- Declare
items on GridSchema and read it. Same objection as 2, plus it publishes a
second spelling as supported.
Adjacent, not the same card: objectui#8310 is the arity of PageNodeSchema.body (one node
vs a list) and is being repaired now; objectui#8284 asks which of body / children a
renderer reads. This one asks whether a node's authored child key has any reader at all.
None of the three is a superset of the others, and this card is not addressed by either of
them.
Filed by the os-dev agent working objectui#8310, domain:ui @ objectui, 2026-09-09,
under PM session session_01611D6ZaRaMmwTNQmSbk8MH. Generated by Claude Code.
Generated by Claude Code
Found while building the render pin for objectui#8310 (which is about the ARITY of
PageNodeSchema.body, not about this). Filed unassigned and NOT repaired there: thatcard's ruling says the root README example stays as written, and the repair here is a
decision about which side is right.
What
The SDUI
gridnode renders its child list fromchildrenand from nothing else:GridSchemadeclares noitems, and the renderer never reads one. Three teachingsurfaces author the child list as
itemsanyway — including the project's flagshipexample on the npm/GitHub landing page:
README.md, the#### Basic Usagefence —bodyis onegridnode whose threestatisticchildren sit underitemscontent/docs/guide/schema-rendering.md, the "Schemas can be nested" JSON fencecontent/docs/guide/schema-playground.md, the "Project Dashboard" JSON fenceA reader who copies any of them gets a grid element with NO children.
Measured
Rendered through the real
SchemaRendererwith the default renderers registered(
packages/components, happy-dom), the README's flagship page — verbatim,itemsandall — produced this, with the grid element self-closing:
getByText('Total Users')— one of the threestatisticlabels the example authors —finds nothing. Firing control, same file, same run: the
pagewrapper and thegridelement themselves ARE drawn, so this is not a registration failure or a dead render
path; it is the child key. Moving the same three nodes to
childrendraws all three.Nothing refuses the authored key either:
BaseSchemais.passthrough()with an[key: string]: anyindex signature, soitemsvalidates, type-checks, rides onto thenode, and draws nothing.
Why it is not caught today
pnpm check:doc-typesasks of every doctypeliteral whether the repository registersthat component —
griddoes exist, so the fence passes. Whether the snippet's OTHER keyshave a reader is that gate's explicitly out-of-scope second dimension (objectui#4823).
pnpm check:doc-examplescompiles the README fence againstBaseSchema, whose indexsignature absorbs
items— measured on this same shape by the seat that filedobjectui#8310: an undeclared key draws exit 0 and zero diagnostics.
The decision, not made here
children, the declared and read key. Cheapest,and it is what coding standard #0.1 (contract-first — fix the metadata, not the renderer)
points at. It changes the landing page's flagship example, which objectui#8310's ruling
deliberately declined to do for a different reason (that card wanted the example's
bodyarity preserved; its
itemsspelling was not before that ruling).gridreaditemsas an alias forchildren. ⛔ This is the lenient-fallback shape#0.1 forbids, and it would mint a second child-key dialect on one node.
itemsonGridSchemaand read it. Same objection as 2, plus it publishes asecond spelling as supported.
Adjacent, not the same card: objectui#8310 is the arity of
PageNodeSchema.body(one nodevs a list) and is being repaired now; objectui#8284 asks which of
body/childrenarenderer reads. This one asks whether a node's authored child key has any reader at all.
None of the three is a superset of the others, and this card is not addressed by either of
them.
Filed by the
os-devagent working objectui#8310,domain:ui @ objectui, 2026-09-09,under PM session session_01611D6ZaRaMmwTNQmSbk8MH. Generated by Claude Code.
Generated by Claude Code