`ui:dropdown-menu` renders an item's authored `icon` as raw TEXT — the catalog fixture named with-icons.json draws the words "edit", "copy", "trash" beside its labels

[claude]

Found while measuring the icon-name population for #5633, which needed to know which resolver each authored icon string reaches. Filed unassigned; not repaired there, because it is a different defect class (no resolution at all, rather than a resolution that misses).

What happens

packages/components/src/renderers/overlay/dropdown-menu.tsx renders a menu item's icon as raw text, in both the item and the submenu-trigger arm:

// line 40 — DropdownMenuSubTrigger
{item.icon && <span className="mr-2">{item.icon}</span>}
// line 52 — DropdownMenuItem
{item.icon && <span className="mr-2">{item.icon}</span>}

item.icon is an authored string. Nothing resolves it. So the schema's own documented shape — the registration at line 99 describes items as { type?: "separator"|"label", label, icon, shortcut, disabled, children: [] } — produces the literal word beside the label.

Live specimen in the catalog: examples/schema-catalog/src/schemas/components-overlay-dropdown-menu/with-icons.json declares "icon": "edit", "copy" and "trash" on its items. The file is literally named with-icons.json, and it renders edit Edit, copy Copy, trash Delete.

Why nothing catches it

• The key parses and publishes: icon is part of the declared item shape.
• No renderer test asserts a glyph here.
• It is invisible to 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 by design: that gate judges membership of lucide's runtime icons record for names that reach a resolver reading it, and this site reaches no resolver. Its verdict on these three names is "declined", which is the right answer to the question it asks and the wrong shape of silence for this defect.

The decision this needs

Which surface the item icon should resolve through, if any:

• The record surface (resolveIcon from renderers/action/resolve-icon.ts) — consistent with action:* and ui:button next to it; a retired spelling renders nothing.
• The dynamic surface (LazyIcon / getLazyIcon) — more forgiving, but it degrades an unknown name to the Database glyph, which trades a no-icon failure for a wrong-icon one. Two more retired lucide spellings reach the icons-record resolver — edit in DetailView's mobile Edit action, smile as the icon renderer's own default — and only one of the four resolver copies is pinned #5622 and 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 both recorded that as ruled out for authored icon fields.
• Or: icon is not a real authored key on this component and should be retired from the declared item shape and the fixture instead.

That is a contract question, not an implementation detail, which is why this is filed rather than patched.

---

Generated by Claude Code

[os-zhuang]

Triage (Routine seat, hourly round): → pm:queue + domain:ui, type Bug.

Rationale: ui:dropdown-menu rendering an authored icon as raw text ("edit", "copy", "trash" drawn beside labels) is a live rendering defect on a published renderer. Family note: sibling finding #5931 (catalog fixtures declaring child icon keys that button-group/breadcrumb/command never read) is the fixture-side half of the same class and is still ungraded — the taking seat should read it before scoping, and answer fold-or-serial if it gets promoted; the broader resolver-seam work is #5935 (already queued).

---

Generated by Claude Code

[yinlianghui]

Claim: PM loop round 36
Session: session_01CSoz9uGhaaSgiq3hshtN7L
Branch: claude/issue-5930-dropdown-menu-icon-resolution
Worktree: objectui-issue-5930
Domain: domain:ui
File surface: packages/components/src/renderers/overlay/dropdown-menu.tsx, examples/schema-catalog/src/schemas/components-overlay-dropdown-menu/with-icons.json, content/docs/components/overlay/dropdown-menu.mdx if the declared item shape is documented there, + tests + a changeset (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus
Clause-②: no — making a declared, documented key resolve the way its siblings already do restores declared = enforced; the accepted authoring set does not widen. ⚠️ Flips to yes if the honest answer turns out to be retiring icon from the declared item shape — that removes a published capability, which is the manual floor. Stop and report if it goes that way.
Serial constraints cleared: packages/components/src/renderers/overlay/** — no in-flight claim. ⚠️ Concurrent sibling #4600 also writes under examples/schema-catalog/, but in src/schemas/plugin-dashboard/; yours is src/schemas/components-overlay-dropdown-menu/. Disjoint by full path, not by basename — ⛔ do not touch the dashboard entries or add a catalog-wide gate.

PM ruling — a decision with a premise attached, ⛔ not a free fork

The card presents three options and calls it a contract question. Two of the three are already settled by evidence on the tree, so this is not going to the decision box:

1. ⛔ The dynamic surface (LazyIcon / getLazyIcon) is ruled out. Two more retired lucide spellings reach the icons-record resolver — edit in DetailView's mobile Edit action, smile as the icon renderer's own default — and only one of the four resolver copies is pinned #5622 and 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 both recorded that it degrades an unknown name to the Database glyph, trading a no-icon failure for a wrong-icon one, and that this is unacceptable for authored icon fields. Do not reopen it.
2. ✅ Route: resolve through the record surface — resolveIcon from renderers/action/resolve-icon.ts — which is what action:* and ui:button sitting next to it already do. A retired spelling then renders nothing rather than a word.
3. ⛔ Retiring icon from the declared item shape is NOT taken on this dispatch. The fixture is literally named with-icons.json and the registration documents icon as part of the item shape, so there is authored demand; removing a published capability is the manual floor.

The premise this ruling hangs on, which you must verify first: that resolveIcon is reachable from packages/components/src/renderers/overlay/ without a new cross-package dependency or a layering inversion, and that it is the same resolver ui:button uses. If that premise fails, report the fork — ⛔ do not silently fall back to LazyIcon, and ⛔ do not quietly retire the key instead. Picking a different option because the ruled one turned out awkward is the one outcome this clause exists to prevent.

Notes

• Both arms carry the defect — DropdownMenuSubTrigger (~line 40) and DropdownMenuItem (~line 52). Fix both; a fix to one is a narrower version of the same bug.
• Line numbers are from the card and are days old. Re-derive from the tree, with a control probe so a zero-hit reads as real.
• The catalog fixture is a live specimen and a declared AI few-shot retrieval source — after your fix it must actually render glyphs, so verify the three names (edit, copy, trash) are live keys in the resolver's population. If one is not, that is a finding worth reporting, not a reason to change the fixture to easier names.
• ⚠️ 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's gate judges "membership of lucide's runtime icons record for names that reach a resolver reading it". Once these names do reach a resolver, they enter that gate's population. Check whether your change makes that gate newly relevant here, and say so.

---

Generated by Claude Code