finding(components): `ui:menubar` never reads an item's `icon` either — the third `MenuItem`-shaped container, and the one no census can see

[os-support-ai]

Blocked-by: #5931

Found while repairing #6278 (ui:context-menu's unread icon). Filed unassigned, out of that card's fence — #6278 is scoped to context-menu and its 裁决 explicitly forbids generalising the fix across containers.

Status (2026-08-28): the blocker #5931 is now in the maintainer's decision inbox (needs-user-decision, assignee cleared), with its four-axis block posted. Its fork — declare / retire / redesign the icon key for button-group — is what decides this card too. ⛔ Still blocked, correctly; nothing to do here until that is ruled.

⚠️ One measurement from #5931's own run is worth carrying, because it kills the obvious answer for at least one container: a proposal to simply strip the key from a component structurally unable to carry an icon was refuted by rendering the fixture — icon-toolbar.json produces 3 buttons with empty textContent and 0 svg, so stripping leaves it rendering nothing at all. Whatever is ruled, "just remove the key" is not automatically safe.

What was measured, at ad54f7587

packages/components/src/renderers/overlay/menubar.tsx contains 0 references to icon (case-insensitive 0 as well).

That is not a shrug about a key nobody declared. MenubarMenu.items is typed as MenuItem[] — the same interface dropdown-menu and context-menu items use, and it declares icon?: string:

// packages/types/src/overlay.ts
export interface MenubarMenu {
  label: string;
  items: MenuItem[];      // <- MenuItem.icon?: string
}

content/docs/components/overlay/menubar.mdx documents it too:

interface MenubarItem {
  label?: string;
  value?: string;
  icon?: string;
  ...

The renderer has three places an item is drawn, and none of them reads the key:

{item.label}                       // submenu trigger
{item.children.map((child, childIdx) => (
  {child.label}                 // nested child
))}
{item.label}  // leaf

So ui:menubar is the third and last member of the MenuItem-shaped family, alongside the two already answered: dropdown-menu (repaired by #5930) and context-menu (repaired by #6278).

Why this one was invisible, and why that is the interesting part

#6278's table was built by enumerating authored icon strings in the schema catalog and grouping them by nearest typed ancestor. examples/schema-catalog/src/schemas/components-overlay-menubar/application-menubar.json authors zero icon keys, so menubar could never appear in that table — not because the renderer is fine, but because no fixture exercises the key.

The same blind spot applies downstream: scripts/check-lucide-icon-record-names.mjs has no 'menubar' census entry, and even if one were added, its min non-vacuity precondition would (correctly) fail, because the descent reaches nothing. A gate that judges authored names cannot see a documented key that nothing authors.

That makes this a declared-but-unread key of the #4632 / #4652 / #4721 class, not the "fixture draws the wrong thing" class — the failure is silent in both directions: an author following the published MenubarItem shape gets no glyph and no error, and no gate reports anything.

Not addressed here, and not addressed by

• finding(components): ui:context-menu never reads an item's authored icon — dropdown-menu's identical twin, left behind by #5930 #6278 — context-menu only; its ruling forbids generalising across containers.
• 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 #5931 — owns button-group, breadcrumb, command; now needs-user-decision on whether the key should exist at all for those. Menubar's question is the same one, which is why this card follows rather than pre-empts it. (⚠️ breadcrumb and command have since been repaired — PR fix(components): resolve ui:breadcrumb and ui:command child item icons through the record resolver #6644 wired both through resolveIcon, the record surface, resolved once per item above the page/link split. button-group is the half still open.)
• finding(examples): the live menubar demo teaches a shortcut array against a string slot, and its separator renders as a blank menu item #6249 — a different menubar defect (the demo's shortcut array against a string slot, and a blank separator item). Disjoint from the icon key.
• Consolidate the eight lucide record-reading icon resolvers into one seam — three tokenisers and a 5-of-8 alias map mean the same authored name renders on one surface and not another #5935 — resolver consolidation, queued.

The open question, stated but not answered

Whichever way #5931 is decided for its containers probably decides this one too: either MenuItem.icon is honoured everywhere it is typed and documented (route through resolveIcon, the RECORD surface, as #5930 ruled and as #6644 has now done for two more containers), or the key is removed from the surfaces that do not read it. ⛔ This card should follow that answer, not pre-empt it.

Incidentally, the nested-child arm above also renders only one level deep and drops disabled, unlike the sibling renderers' recursion. Noted, not investigated. Per triage, that incidental rides the same fix if the answer is "honour".

Serial note for the eventual claim: #6327 (hold) and #5935 (queued) touch the same file — check the serial queue.

[os-trump]

Triage: graded Task, state pm:blocked (keeping domain:ui).

Blocked-by: #5931

Rationale is the card's own: whichever way #5931 decides "should the icon key exist at all" for its three containers decides menubar too — honour the key everywhere it is typed and documented (through resolveIcon, per #5930), or remove it from the surfaces that do not read it. Queueing this before that ruling would pre-empt it. When #5931 closes, the unlock scan returns this card and the fix inherits the ruling; the incidental notes (nested-child arm renders one level deep and drops disabled) ride the same fix if the answer is "honour". Note for the eventual claim: #6327 (hold) and #5935 (queued) touch the same file — check the serial queue.

---

Generated by Claude Code