Found while implementing #6150 (declare the 13 renderer-read keys). Filed unassigned, not folded into that PR — #6150's dispatch order rules a 14th key out of its scope explicitly:
⛔ The 13 only. … If your re-derivation finds a 14th genuinely-read key, ⛔ report it, do not fold it in.
This is that report.
Why #6150's census could not see these
#6150 measured documented keys: it walked the ## Schema blocks of all 76 content/docs/components pages and tested each documented key for membership against the shipped type. A key that the renderer reads and the docs never mention is invisible to that instrument in both directions — it is not in the docs, so it never becomes a candidate.
The re-derivation on #6150's branch ran the opposite way round: for each of the 8 renderers in that batch, enumerate every schema.KEYNAME read in the file and subtract the shipped type's declared members (read through the same built packages/types/dist/index.d.ts path, cross-checked against src). That direction finds keys the docs never recorded. It found the 13, and it found these 5.
The 4 genuinely-read undeclared keys
Measured on 40c479af2. Line numbers drift; the READ is the fact.
| type |
key |
read at |
what it does |
CheckboxSchema |
wrapperClass |
renderers/form/checkbox.tsx:33 — cn("flex items-center space-x-2", schema.wrapperClass) |
classes on the checkbox+label wrapper |
ContextMenuSchema |
triggerClassName |
renderers/overlay/context-menu.tsx:87 — first limb of schema.triggerClassName || className || schema.className || "h-[120px] …" |
classes on the right-click area |
ContextMenuSchema |
contentClassName |
overlay/context-menu.tsx:88, applied at :97 — className={contentClass} on ContextMenuContent |
classes on the popup panel |
ContextMenuSchema |
modal |
overlay/context-menu.tsx:91 — modal={schema.modal} on the Radix root |
modal vs non-modal menu behaviour |
CheckboxSchema.wrapperClass is the one worth noting on its own: wrapperClass is among #6150's 13 — but only on FilterBuilderSchema and FileUploadSchema, because only those two pages document it. The same key, on the same class of read, on a third type, is left undeclared purely because the checkbox page's schema block is a six-line summary. The asymmetry is an artefact of the docs, not of the renderers.
The mirror-image defect on the same type
ContextMenuSchema.children is declared on both faces — children: SchemaNode | SchemaNode[] in packages/types/src/overlay.ts and children: z.union([...]) in zod/overlay.zod.ts, both required — and no read site consumes it. The full set of schema. reads in context-menu.tsx is className, contentClassName, items, modal, trigger, triggerClassName. The renderer renders schema.trigger inside ContextMenuTrigger, never schema.children.
So the shipped contract for context-menu currently requires an authored key that does nothing, and is silent about the four that do. That is ADR-0049 enforce-or-remove territory, and it is a different remedy from the four above — hence one card with both halves rather than two that have to be read together.
Why this is not a docs card
The same argument #6150 makes. The docs are not wrong about what they describe; they are simply the only place these capabilities are recorded, and for these five they do not record them either. The defect is that the shipped types under-declare a working surface and over-declare a dead one.
Not claimed here
Which of the four are intended public API. triggerClassName / contentClassName overlap className on the same node and may want consolidating rather than declaring — that is a judgement this card does not make, exactly as #6150 declined to make it for CarouselSchema.opts.
Scope note
The re-derivation covered only the 8 types in #6150's batch. The other renderers were not swept in this direction, so this list is a floor, not a census. A full read-driven sweep across all renderers is a separate, larger card.
Refs: #6150 (where measured; the 13 land there) · #6151 (sibling finding, same sweep, different mechanism) · #6143 (the docs-driven sweep that started the family) · #5155 (why all of these compile)
Found while implementing #6150 (declare the 13 renderer-read keys). Filed unassigned, not folded into that PR — #6150's dispatch order rules a 14th key out of its scope explicitly:
This is that report.
Why #6150's census could not see these
#6150 measured documented keys: it walked the
## Schemablocks of all 76content/docs/componentspages and tested each documented key for membership against the shipped type. A key that the renderer reads and the docs never mention is invisible to that instrument in both directions — it is not in the docs, so it never becomes a candidate.The re-derivation on #6150's branch ran the opposite way round: for each of the 8 renderers in that batch, enumerate every
schema.KEYNAMEread in the file and subtract the shipped type's declared members (read through the same builtpackages/types/dist/index.d.tspath, cross-checked againstsrc). That direction finds keys the docs never recorded. It found the 13, and it found these 5.The 4 genuinely-read undeclared keys
Measured on
40c479af2. Line numbers drift; the READ is the fact.CheckboxSchemawrapperClassrenderers/form/checkbox.tsx:33—cn("flex items-center space-x-2", schema.wrapperClass)ContextMenuSchematriggerClassNamerenderers/overlay/context-menu.tsx:87— first limb ofschema.triggerClassName || className || schema.className || "h-[120px] …"ContextMenuSchemacontentClassNameoverlay/context-menu.tsx:88, applied at:97—className={contentClass}onContextMenuContentContextMenuSchemamodaloverlay/context-menu.tsx:91—modal={schema.modal}on the Radix rootCheckboxSchema.wrapperClassis the one worth noting on its own:wrapperClassis among #6150's 13 — but only onFilterBuilderSchemaandFileUploadSchema, because only those two pages document it. The same key, on the same class of read, on a third type, is left undeclared purely because the checkbox page's schema block is a six-line summary. The asymmetry is an artefact of the docs, not of the renderers.The mirror-image defect on the same type
ContextMenuSchema.childrenis declared on both faces —children: SchemaNode | SchemaNode[]inpackages/types/src/overlay.tsandchildren: z.union([...])inzod/overlay.zod.ts, both required — and no read site consumes it. The full set ofschema.reads incontext-menu.tsxisclassName,contentClassName,items,modal,trigger,triggerClassName. The renderer rendersschema.triggerinsideContextMenuTrigger, neverschema.children.So the shipped contract for
context-menucurrently requires an authored key that does nothing, and is silent about the four that do. That is ADR-0049 enforce-or-remove territory, and it is a different remedy from the four above — hence one card with both halves rather than two that have to be read together.Why this is not a docs card
The same argument #6150 makes. The docs are not wrong about what they describe; they are simply the only place these capabilities are recorded, and for these five they do not record them either. The defect is that the shipped types under-declare a working surface and over-declare a dead one.
Not claimed here
Which of the four are intended public API.
triggerClassName/contentClassNameoverlapclassNameon the same node and may want consolidating rather than declaring — that is a judgement this card does not make, exactly as #6150 declined to make it forCarouselSchema.opts.Scope note
The re-derivation covered only the 8 types in #6150's batch. The other renderers were not swept in this direction, so this list is a floor, not a census. A full read-driven sweep across all renderers is a separate, larger card.
Refs: #6150 (where measured; the 13 land there) · #6151 (sibling finding, same sweep, different mechanism) · #6143 (the docs-driven sweep that started the family) · #5155 (why all of these compile)