finding(components): `ui:button` inlines its own copy of resolveIcon instead of importing it, so any future fix to the shared resolver silently misses it

[yinlianghui]

Found while implementing #5930, verifying the premise that resolveIcon is "the same resolver ui:button uses". It is the same algorithm, but not the same function.

What is on the tree

packages/components/src/renderers/form/button.tsx (the ui:button registration, namespace ui) does not import resolveIcon. It carries a byte-equivalent reimplementation at module scope — its own toPascalCase, its own iconNameMap containing the single entry Home -> House, and its own index into icons from lucide-react:

let Icon: LucideIcon | null = null;
if (schema.icon) {
 const iconName = toPascalCase(schema.icon);
 const mappedIconName = iconNameMap[iconName] || iconName;
 Icon = (icons as any)[mappedIconName] as LucideIcon;
}

packages/components/src/renderers/action/resolve-icon.ts is the shared version, and the action:* family (action-button, action-menu, action-group, action-icon) plus renderers/complex/data-table.tsx all import it.

Why it matters

Behaviour is identical today — same population, same casing rule, same Home -> House alias, same "unknown name renders nothing" outcome — so nothing is currently mis-rendering. The risk is divergence: an alias added to iconNameMap in resolve-icon.ts (which is exactly how lucide retirements have been absorbed — see #5586, #5622) does not reach ui:button. The copy would keep resolving the retired spelling to nothing while every action:* site started resolving it correctly, and no gate separates them because check:icon-record-names declares both modules as legitimate record readers.

That hand-copied-resolver class is what #5633 was opened about; it chose to build a gate over the population rather than dedupe. This is the dedupe half, still outstanding.

Shape of the repair

Import resolveIcon in form/button.tsx, delete the local toPascalCase and iconNameMap, and drop form/button.tsx from DECLARED_RECORD_READERS in scripts/check-lucide-icon-record-names.mjs — the census rediscovers readers from source on every run and fails on drift in both directions, so that edit is verified rather than asserted.

Not folded into #5930: different file, different renderer, and it widens that card's verification surface for no behavioural gain.

[claude]

Concentrated triage round: finding → pm:queue, Task, domain:ui stands. Mechanical convergence: ui:button carries a byte-equivalent inline copy of resolveIcon — import the shared resolver from renderers/action/resolve-icon.ts, delete the module-scope copy (toPascalCase, iconNameMap, the index), pin that ui:button renders through the shared function. Size: S.

---

Generated by Claude Code

[os-support-ai]

Claim — domain:ui @ objectui execution seat

PM session session_011SfZeFWrhGLHmfq61xbz4q (os-support-ai). Branch claude/issue-5993-button-inlined-icon-resolver. Labels pm:queue → pm:dispatched in the same stroke as the assign.

Premise confirmed on origin/main @ 79ebf30d1

The renderer is packages/components/src/renderers/form/button.tsx, and it duplicates the shared resolver's logic in full — not just the lookup:

shared — renderers/action/resolve-icon.ts	copy — renderers/form/button.tsx
toPascalCase (:15-20)	toPascalCase (:17-23)
iconNameMap = { Home: 'House' } (:22-24)	iconNameMap = { 'Home': 'House' } (:26-28)
resolveIcon (:30-35)	inline at :45-49

⚠️ The two corrections that matter for how this is dispatched

1. This is duplication, ⛔ NOT a live rendering defect. I first read a partial grep and concluded button.tsx skipped toPascalCase, which would have made kebab-case icons silently fail on this renderer alone — a user-facing bug. That was wrong. Line 46 does call toPascalCase(schema.icon); my grep pattern just didn't match that line. Reading the actual source refuted it. The two implementations are behaviourally equivalent today, which is exactly what the card claims: the hazard is that a future fix to the shared resolver silently misses this copy. The card's original framing is right and its Task grading is right.

2. The census is three, not two. toPascalCase also has a third production copy at renderers/basic/icon.tsx (the ui:icon renderer), which the card does not mention. ⛔ That one is NOT in scope, and converging it would be a mistake: it carries unresolvable-name placeholder-and-warn behaviour (pinned by basic/__tests__/icon-unresolvable-placeholder.test.tsx) that the shared resolveIcon does not have — it returns null. Folding it in would delete a deliberate behaviour. I will file it separately rather than widen this card.

Package is packages/components — disjoint from the three concurrent claims (#5034 → plugin-form, #6275 → core, #5977 → plugin-map).

Type Task; dispatched under the lane's Bug-first order with the reason logged: the graded pm:queue Bug tier is drained.

---

Generated by Claude Code

[os-support-ai]

⚠️ Overlap declared — this card is a strict SUBSET of #5935, and I should have caught it before dispatching

domain:ui @ objectui execution seat, PM session session_011SfZeFWrhGLHmfq61xbz4q. Recording an error of my own process, and what I am doing about it.

#5935 — "Consolidate the eight lucide record-reading icon resolvers into one seam" — is open, pm:queue, unassigned, and its body explicitly names packages/components/src/renderers/form/button.tsx among its eight call sites. Its stated end state is "One shared resolver, one iconNameMap, one tokeniser; the eight call sites re-pointed at it."

That is this card, for one of the eight.

My error: I ran the duplicate check for a finding I was about to file, and that search is what surfaced #5935 — after I had already dispatched this card. The shadow check belonged before the dispatch, not after. The rule I skipped is the one that says open, unclaimed siblings must first be converged into a single dispatch entry point.

Why the dev is NOT being stopped

This card is one file, one import, and behaviour-preserving by construction. Landing it does not conflict with #5935 — it discharges one of its eight call sites and shrinks its remaining scope to seven. Stopping a running, correctly-scoped agent to re-dispatch the same work under a bigger number would waste the run and buy nothing.

⛔ What must not happen is #5935 being dispatched later as if form/button.tsx were still unconverged. That is recorded on #5935.

The scope boundary on this card still stands, and #5935 is where its tension gets resolved

I told this card's dev ⛔ not to touch renderers/basic/icon.tsx, because its copy carries unresolvable-name placeholder-and-warn behaviour that the shared resolveIcon does not have. That boundary is still correct for this card. But #5935's goal of one tokeniser runs straight into it: converging icon.tsx means deciding what happens to that placeholder behaviour. ⭐ That decision belongs to #5935's scoping, not here.

The third-copy finding I said I would file is therefore NOT being filed — basic/icon.tsx is already inside #5935's census. Filing it would have been the duplicate this check exists to prevent.

---

Generated by Claude Code