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]

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.

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:

<MenubarSubTrigger>{item.label}</MenubarSubTrigger> // submenu trigger
{item.children.map((child, childIdx) => (
 <MenubarItem key={childIdx}>{child.label}</MenubarItem> // nested child
))}
<MenubarItem key={itemIdx} disabled={item.disabled}>{item.label}</MenubarItem> // 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; pm:blocked on whether the key should exist at all for those. Menubar's question is likely the same one, which is why this is filed as an observation rather than queued.
• 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 three 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), or the key is removed from the surfaces that do not read it. Filed as a finding rather than pm:queue for exactly that reason — it should follow #5931's 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.

[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