Combobox renderer never reads ComboboxSchema.defaultValue / .description / .name — the sibling select and input renderers read theirs

[os-justin]

Found by the os-dev seat while implementing objectui#7687 (honouring options[].disabled). Out of that card's scope: #7687 is about a member of ComboboxOption, this is about members of ComboboxSchema itself. Grading and domain:* are the triage seat's.

The fact

ComboboxSchema (packages/types/src/form.ts) declares eight authorable members. The combobox renderer (packages/components/src/renderers/form/combobox.tsx) forwards four of them:

reads:  options, placeholder, value, className

Three of the remaining ones have no read site anywhere on the combobox path, and each has a sibling renderer that does read the same key:

key	combobox	sibling that reads it
defaultValue	0 read sites	select.tsx:52 — defaultValue={value === undefined ? toControlValue(schema.defaultValue) : undefined}
name	0 read sites	select.tsx:57 — name={schema.name}
description	0 read sites	input.tsx:67 renders it as help text under the control

packages/components/src/custom/combobox.tsx does not accept defaultValue or description on ComboboxProps either, so there is nothing downstream to receive them.

⛔ What is NOT part of this — measured, so nobody re-derives it wrong

The other two undeclared-looking members, label and error, are deliberately handled and must not be swept into this card. toFormControlDomProps in packages/components/src/renderers/form/form.tsx strips both on purpose, with the rationale written out at the strip site: the enclosing FormLabel already renders the label, and error exists for REGISTERED widgets that need to place aria-invalid themselves, whereas the builtin branch renders inside FormControl, whose Slot injects it. Forwarding either would only land a stray label="…" / error="…" attribute on a DOM node.

⇒ A reviewer who greps for "which declared keys does the combobox renderer forward" and stops at the count gets five apparent misses and would file a card that is 40 percent wrong. The count is three.

Consequence

Same class as objectui#7687 but a different member set: an author who writes defaultValue on a combobox node passes safeValidateSchema, type-checks against the published ComboboxSchema, and gets an empty combobox — while the identical authoring on a select node works. description renders help text under an input and nothing under a combobox.

⚠️ Unverified by this seat, and it decides the remedy: whether a combobox used as a form FIELD (rather than as a standalone node) already receives its default through the form's own value plumbing rather than through schema.defaultValue. If it does, the gap is standalone-node-only and narrower than the table above suggests. Measure that before choosing between honouring the keys and retiring them. objectui#4047 (closed) is adjacent — a create dialog ignoring a field's defaultValue for a select — but it is about the dialog, not about this renderer.

Reproduce

grep -n 'schema\.' packages/components/src/renderers/form/combobox.tsx
grep -n 'schema.defaultValue\|schema.name' packages/components/src/renderers/form/select.tsx
grep -n 'schema.description' packages/components/src/renderers/form/input.tsx

Measured on origin/main at 5b09821ed.

Related

• objectui#7687 — the same defect class one level down, on ComboboxOption.disabled. Being fixed separately; ⛔ this card is not a blocker for it and must not be folded into it.
• objectui#7697 — ComboboxOption absent from the @object-ui/types root barrel; surface-only.

Filed by the os-dev seat while working objectui#7687, session session_01YBWFb5YgMU5dw8p2VKj16S, generated by Claude Code.