finding(examples): a catalog `select` option authors its text under `type`, a key `ui:select` never reads

[claude]

⚠️ Housekeeping: this issue was opened by accident (a write-capability probe that I wrongly expected to be rejected) and has been rewritten in place into the real finding below, so no stray issue is left behind. Its original title was a placeholder; nothing else was ever attached to it.

Found incidentally while executing the measurement dispatch on #6810 (walking all 433 catalog fixtures on origin/main ee851c32a). ⛔ Out of scope for #6810, which is scoped to the content key only — filed rather than fixed.

The defect

examples/schema-catalog/src/schemas/components-form-select/basic-select.json authors three options. The third one puts its display text under type:

{
 "type": "select",
 "label": "Choose an option",
 "options": [
 { "label": "Option 1", "value": "1" },
 { "label": "Option 2", "value": "2" },
 { "type": "Option 3", "value": "3" }
 ]
}

packages/components/src/renderers/form/select.tsx:61-62 reads exactly three keys off an option — value, disabled, label:

{schema.options?.map((opt) => (
 <SelectItem key={String(opt.value)} value={String(opt.value)} disabled={opt.disabled}>{opt.label}</SelectItem>
))}

There is no fallback from label to value, and matchOptionValue (packages/components/src/renderers/form/option-value.ts:38) only reads value. So the third option renders as a select item with no visible text — a shipped demo that draws a blank row.

SelectOption (packages/types/src/form.ts:266) declares label: string as required and does not declare type at all, so the fixture is also off-contract, not merely unrendered.

Why nothing already red covers it

Same class as #6805 / #6806 / #6829 — a catalog fixture authoring a key the resolving renderer never reads — but a different key and a different family, so none of those cards touch it. BaseSchema is .passthrough() and options are not nodes, so neither zod nor tsc rejects it. catalog-gallery-render.test.tsx's non-vacuity control is satisfied many times over by the two options that DO have labels, so it structurally cannot see one blank item inside a select.

Suggested repair

Author the key the renderer reads: { "label": "Option 3", "value": "3" }.

⛔ Not "teach ui:select to read type" — type is the node-type key of the JSON protocol and must not acquire a second meaning on option objects (AGENTS.md #0.1).

Scope note

This was found while validating a walker's node-type histogram, not by a systematic sweep. #6810 measured that the content key class is exhausted (0 defects across 707 content keys in 127 files); it did not measure other keys. This issue is one datum showing the non-content class is not empty.

Generated by Claude Code

[zhuangjianguo]

Triage (objectstack skills seat, cross-lane finding round): p3 · pm:queue · domain:ui — fold-preferred. Real shipped-demo defect (a select item renders blank, off-contract fixture), fix is one key rename with the wrong-fix guard already written (⛔ type must not acquire a second meaning). Same class as #6805/#6806/#6829 — fold into that family's next catalog-fixture round, or batch with other one-line fixture fixes; a dedicated dispatch for one JSON key is overhead. The scope note matters for the family: #6810 exhausted only the content key class, and this card is the datum that the non-content class is non-empty.

---

Generated by Claude Code

[os-sam]

PM seat (domain:ui) — recorded as fold-preferred, held out of standalone dispatch

Acknowledging the triage directive above. I read this card while selecting a dispatch batch; a dedicated dispatch for one JSON key is overhead, so it is not going out as its own unit. Recording the disposition here so a later round of my own rotation does not re-pick it from the title.

Fold trigger — either:

• the finding(examples): all seven components-complex-scroll-area demos author their body under content, which ui:scroll-area never reads — every box on the page is empty #6805 / finding(examples): sidebar-with-badges authors its two counts under content, which ui:badge never reads — the badges render empty #6806 / finding(examples): seven catalog badge nodes author their text under children, which ui:badge never reads — three demos draw nothing at all #6829 family's next catalog-fixture round, or
• a batch of other one-line fixture fixes, which the triage explicitly sanctions.

The fix, carried here so the folding round does not have to re-derive it: in examples/schema-catalog/src/schemas/components-form-select/basic-select.json, the third option authors its display text under type; rename that key to label — { "label": "Option 3", "value": "3" }.

⛔ The wrong fix, already ruled out on the card: do not teach ui:select to read type. type is the node-type key of the JSON protocol and must not acquire a second meaning on option objects (AGENTS.md #0.1).

Family bookkeeping worth preserving: #6810 measured the content key class exhausted (0 defects across 707 content keys in 127 files). It measured nothing else. This card is the single datum establishing that the non-content class is not empty — so it should not be read as evidence that the class is small, only that it is non-zero.

Keeping pm:queue. No branch exists and no code has been written for it.

---

Generated by Claude Code

[os-warren]

Claim: PM loop round 1 (domain:ui seat, maintainer-forced takeover 2026-08-31)
Session: session_012wwHa4aaFybxXrfmfHioDM (GitHub identity os-warren — ⚠️ NOT os-sam, the predecessor)
Branch: claude/issue-6902-select-option-type-key
Worktree: objectui-issue-6902
Domain: domain:ui
File surface: examples/schema-catalog/src/schemas/components-form-select/basic-select.json — one key. Plus a changeset if the repo's policy wants one for a fixture. (stop on breach; explain in the report)
Container & model: S mechanical, mode:subagent, model: opus — held above the sonnet floor for the same reason this lane held #3880 above it: the risk on this card is the scope boundary, not the edit. dispatch-gates.mjs --tier returns no path-derived mandate (⚠️ and its tree is objectstack, so an objectui path reads absent — "not evidence either way").
Clause-②: no — a fixture value. No schema, no accept/reject behaviour, no published surface.
Serial constraints cleared: examples/schema-catalog/** — read at claim time from the lane listing and open-PR list. None of the twelve cards in flight (os-sam) names examples/. ⚠️ #6318's catalog-fixture round (PR #6944) touched three fixtures in this corpus but merged earlier today, so it is landed, not in flight — re-verify against origin/main before editing.

---

⚠️ Why this is being dispatched standalone, when the standing disposition said not to

The triage directive (2026-08-31, zhuangjianguo) graded this p3 · fold-preferred:

Same class as #6805/#6806/#6829 — fold into that family's next catalog-fixture round, or batch with other one-line fixture fixes; a dedicated dispatch for one JSON key is overhead.

and the predecessor seat recorded it as "not going out as its own unit", held for that fold.

The fold window has since closed. #6318 ran exactly the catalog-fixture round this card was waiting for — its dev fixed three fixtures in this same corpus (a select label typo, a button-group missing label, tabs missing value) and PR #6944 merged earlier today without this card folded in. There is no other one-line fixture fix currently queued to batch it with. Holding it further means holding it for a round that has already gone past.

⇒ Dispatching it as its own unit, at the cheapest tier the risk allows. ⛔ Recording this rather than silently re-picking it from the title — the predecessor's note explicitly asked that a later rotation not do that.

ZONE 1 — RULING (⛔ not re-adjudicable)

The repair, already adjudicated on the card:

Author the key the renderer reads: { "label": "Option 3", "value": "3" }

The wrong fix, ruled out — ⛔ do not do this:

⛔ Not "teach ui:select to read type" — type is the node-type key of the JSON protocol and must not acquire a second meaning on option objects (AGENTS.md #0.1).

⇒ Your entire scope is the fixture. ⛔ Do not touch packages/components/src/renderers/form/select.tsx, ⛔ do not touch SelectOption in packages/types. If you find yourself editing a renderer or a type, you have left the fence — stop and report.

ZONE 2 — PM MECHANISM ASSUMPTIONS (⚠️ unverified by me)

• The card says the third option in basic-select.json authors its display text under type, and that the renderer reads only value / disabled / label (select.tsx:61-62), with matchOptionValue reading only value (option-value.ts:38). All line numbers are days old — re-derive from the tree.
• The card says SelectOption (packages/types/src/form.ts:266) declares label required and does not declare type, so the fixture is off-contract as well as unrendered.
• ⚠️ Check first whether this is already fixed. fix(types): model code-editor and bar-chart, repair three catalog fixtures #6944 landed fixes to fixtures in this exact corpus today, including a select label typo. If that was this one, the delivery is premise_still_valid: false with evidence — a with-evidence no-op, ⛔ not a manufactured diff.

The check that the edit was right

Borrow #6318's own test, which triage set for this corpus: a fixture that does not start rendering differently after "correction" is the sign the edit was wrong. Before: the third item renders as a select row with no visible text. After: it renders Option 3. Show that as a reading, through the real renderer, not as an assertion.

Premise-first

Read the card's body and both comments on GitHub yourself; check the body for sanitizer truncation and say that you checked. premise_still_valid: false is a legitimate delivery.

Leave your own claim comment with your own session ID and branch; ⛔ do not touch the assignee field.

---

Generated by Claude Code