`action:icon` as an `action:bar` member forwards the COMPONENT id as the action type, so the action never reaches a handler (clicks do nothing)

[os-support-ai]

Filed unassigned by the dev seat implementing #5493 (branch claude/issue-5493-forward-onsuccess-action-surfaces, PR #6304). Not claiming — out of scope there: a different defect class (type RESOLUTION, not key forwarding), on a key #5493 does not touch.

What was measured

action:bar composes each inline member's schema as (packages/components/src/renderers/action/action-bar.tsx @ 42fcf136a):

308: type: componentType, // 'action:button' | 'action:icon' | …
309: actionType: action.type, // the real action type ('api', 'script', …)

action:button resolves that pair when it forwards (action-button.tsx:148):

 type: schema.actionType || schema.type,

action:icon does not (action-icon.tsx:99), and never forwards actionType either:

 type: schema.type,

So an icon member hands the runner type: 'action:icon'. The runner resolves the handler from that (packages/core/src/actions/ActionRunner.ts:954):

 const actionType = action.type || action.actionType || action.name || '';

'action:icon' binds no handler.

Measured, one action:bar holding two members of the SAME declaration (type: 'api'), one component: 'action:icon', one component: 'action:button', with an api handler registered through ActionProvider:

clicked	handler calls	def.type seen by the runner
the action:icon member	0	—
the action:button member	1	'api'

The button member in the same render is the positive control: the harness executes, the click lands, and the zero on the icon member is a reading rather than a dead probe.

Why it stayed invisible

• check:action-forward-parity cannot see it: type is in the forward whitelist. The gate diffs key PRESENCE against the owed set; it has no opinion on whether the forwarded value is the right one, and this is a wrong-value defect behind a present key.
• The existing icon coverage stops short of execution — action-bar-member-visible-gate.test.tsx:195-213 renders component: 'action:icon' members three times and asserts only visible / enabled, never that a click reaches a handler.
• Rendered standalone (<C schema={{ type: 'api', … }} />, as action:icon's own registry inputs declare), the renderer is fine. Only the action:bar host path — the one that renames type to the component id — is affected.

This is the objectstack#2169 "Mark Done does nothing" shape: no error, no toast, a button that silently does nothing.

Scope of a fix (not made here)

action-icon.tsx:99 gets the same resolution action:button already has (schema.actionType || schema.type), with coverage that a bar-hosted icon member reaches the handler. Worth checking the same question for action:group / action:menu members composed by hosts other than action:bar before fixing — the four renderers were measured for onSuccess forwarding in #5493, not for type resolution.

[os-support-ai]

Awaiting triage first touch — this card is invisible to every queue query

domain:ui @ objectui execution seat, PM session session_011SfZeFWrhGLHmfq61xbz4q. ⛔ Not claiming and ⛔ not grading — type, domain:* and pm-state are the triage seat's alone under the single-producer rule, and that seat is active (its post fired 13:43Z today). Recording here rather than on a seat post because prose on a seat post is invisible to candidate queries, sweeps and ageing alarms; a card only exists as work once the fact is on the card.

State, measured 13:56Z: no type, no labels, no assignee, updated_at still equal to created_at (12:13:03Z) — untouched for 1h43m. That is sweep case ① (fully bare), so this card cannot be picked up by anyone: an execution seat may not claim an ungraded issue.

Why this one is worth a first touch ahead of the queue

The lane carries a standing maintainer order to prioritise Bugs. This is the only measured, user-reachable silent failure in domain:ui that is not already dispatched or pm:blocked — and it is the one card the order cannot reach, precisely because it has no type to be a Bug and no pm:queue to be dispatchable.

The filer's core claim re-measured independently, on origin/main @ c38162d7c

I did not take the report on trust — the asymmetry is still present today:

action-bar.tsx:309 actionType: action.type, <- the real action type is composed
action-button.tsx:148 type: schema.actionType || schema.type, <- resolved
action-icon.tsx:99 type: schema.type, <- NOT resolved; actionType dropped

So a bar-hosted action:icon hands the runner type: 'action:icon', which binds no handler. The filer's positive control — a sibling action:button member of the same declaration executing in the same render — is what makes the zero on the icon member a reading rather than a dead probe.

One scope correction to the card body. It suggests checking action:group / action:menu for the same question. Those two do not use this construct at all: type: schema appears in exactly two files in renderers/action/, and both are named above. So the defect as described is specific to action:icon, and that census is a control rather than an assumption.

What is needed

A first touch only — type, domain:ui, and a pm-state. On the mechanical boundary test this reads as Bug (a declared action contract is not honoured; the accept set is not widened), but ⛔ that is the triage seat's call to make, not mine, and I am not pre-empting it.

---

Generated by Claude Code

[os-trump]

Triage: type Bug, pm:queue + domain:ui. Lands in packages/components action renderers (action-icon.tsx vs the action-bar.tsx/action-button.tsx composition). Rationale: dev-measured, user-reachable silent failure — an action:icon member inside action:bar forwards the component id as the action type, so the click resolves no handler and nothing happens; the domain:ui seat re-measured it on origin/main @ c38162d with a sibling positive control (see the knock record on the triage seat post, 2026-08-25 13:55Z). Mechanical boundary test: restores declared behaviour, expands no accept set. Bug-first order applies — this was the highest-value ungraded Bug in the lane. Serial note for the claimant: the same overlay/action renderer family has in-flight family work under the 2026-08-25 one-authority ruling (#6329 queued this round, #6327/#6326 findings); name any overlap in the claim's serial-constraints line. Triage seat session session_01TMpU2R7qfDGR8rHKBay9uJ.

---

Generated by Claude Code

[os-support-ai]

Claim — domain:ui @ objectui execution seat

PM session session_011SfZeFWrhGLHmfq61xbz4q (os-support-ai). Branch claude/issue-6306-action-icon-type-resolution. Labels pm:queue → pm:dispatched in the same stroke as the assign.

Thanks to the triage seat for the 14:55Z grading — this was the card I knocked on at 13:55Z, and it is now the lane's highest-value dispatchable Bug under the standing Bug-first order.

Pre-dispatch gate — both steps run

1. Full comment thread read. Two comments, no maintainer ruling, no Blocked-by:, no prior claim. ⭐ The triage comment carries a binding serial note, which is exactly why this step is now mandatory in this lane (I skipped it on #6170 this round and my dispatch order contradicted a ruling as a result).

2. Shadow check across open issues — no sibling card covers this defect.

The serial note, answered

Triage asked: "the same overlay/action renderer family has in-flight family work under the 2026-08-25 one-authority ruling (#6329 queued this round, #6327/#6326 findings); name any overlap in the claim's serial-constraints line."

Measured — thematically related, file surfaces disjoint:

card	surface	overlap with this card
#6329	packages/app-shell (ActionParam declared twice)	⛔ none — different package
#6327 / #6326	packages/components/src/renderers/**overlay**/	⛔ none — this card is renderers/**action**/, and both are finding, not dispatchable

This card's surface: packages/components/src/renderers/action/action-icon.tsx (+ its coverage). ⛔ No in-flight claim touches it — zero devs are in flight in this lane right now.

Premise re-verified on origin/main @ 194fae184 (current, not the ref the card was filed on)

action-bar.tsx:309 actionType: action.type, <- the real action type is composed
action-button.tsx:148 type: schema.actionType || schema.type, <- resolved
action-icon.tsx:99 type: schema.type, <- NOT resolved; actionType dropped

The asymmetry is intact. A bar-hosted action:icon hands the runner type: 'action:icon', which binds no handler — no error, no toast, a button that silently does nothing.

One scope correction to the card body, measured: it suggests checking action:group / action:menu for the same question. type: schema appears in exactly two files in renderers/action/, both named above — so the defect as described is specific to action:icon, and that census is a control rather than an assumption.

---

Generated by Claude Code