Catalog fixtures declare child `icon` keys that button-group, breadcrumb and command never read — two of them are named with-icons.json and render none

[claude]

Observation, filed unassigned while measuring the icon-name population for #5633. Not a user-visible failure by itself — it is authored surface that nothing reads.

Measured

Three catalog fixtures declare an icon on child items whose renderer never reads icon at all. Verified by reading each renderer, not by inference:

fixture	key	renderer	reads icon?
examples/schema-catalog/.../components-basic-button-group/with-icons.json	buttons[].icon ("grid", "list")	packages/components/src/renderers/basic/button-group.tsx	no — the only icon in the file is the 'icon' member of the size enum
examples/schema-catalog/.../components-data-display-breadcrumb/with-icons.json	items[].icon ("home", "book", "layout")	packages/components/src/renderers/data-display/breadcrumb.tsx	no — no icon anywhere in the file
examples/schema-catalog/.../components-form-command/command-menu.json	groups[].items[].icon ("smile", …)	packages/components/src/renderers/form/command.tsx	no — no icon anywhere in the file

Two of the fixtures are named with-icons.json and render none.

The command one was already recorded in #5633's own comment thread as inert; the other two are new here, and the shape is the same in all three.

Why it stayed invisible

• Nothing type-checks a catalog document against the renderer's actual reads.
• The Nothing checks that an icon: literal reaching a record-reading lucide resolver is a live icons key — four hand-copied resolvers, four local pins, no gate over the population #5633 gate sees all six names and declines them: the child items carry no type of their own, so the gate cannot say which vocabulary (if any) they reach — and the honest answer here is "none". Its silence is correct; it is just not a report.

Worth deciding

The declared-but-unenforced pattern is the one ADR-0049's enforce-or-remove reasoning exists for. Either these components should render an authored icon (which is #5930's question, one component over), or the key should leave the fixtures so the catalog stops advertising an affordance the renderer does not have. A fixture named with-icons.json that renders no icons is the worst of the two states, because it reads as coverage.

---

Generated by Claude Code

[os-zhuang]

Triage (finding first-touch): graded domain:ui, type Task, pm:blocked.

Blocked-by: #5930

Rationale: the render-vs-strip fork this card names is being decided one component over — #5930 is in flight making ui:dropdown-menu actually render an authored child icon through the shared resolver. Its landed shape is the pattern answer for these three components (button-group / breadcrumb / command): either extend the same resolver wiring to them, or — if the maintainer's acceptance there narrows the pattern — strip the fixture keys so the catalog stops advertising an affordance the renderers lack. Unlock action: on #5930's close, re-measure the three renderers on the merged ref and re-price; a fixture named with-icons.json rendering no icons must not survive either way. Adjacent gate context: the #5633 icon-record gate declines untyped child nodes (its own recorded blind spot, finding #5992) — do not "fix" this card by teaching that gate to guess.

---

Generated by Claude Code