finding(components): an `autoTrigger` action that spills past action:bar's maxVisible lands in action:menu, which never runs it — deep link consumed, nothing triggered

[yinlianghui]

Measured while implementing #4123 (arming the ?runAction=create_environment deep link on the create action's presence). Filed separately: #4123's fix is correct and complete for the divergence it names, and this is a different layer with the same end signature, one step further down.

Fact

autoTrigger is consumed only by action:button (packages/components/src/renderers/action/action-button.tsx, the useEffect guarded by the autoTriggered ref). action:menu has no autoTrigger handling at all.

action:bar splits its post-filter list into inline and overflow (packages/components/src/renderers/action/action-bar.tsx):

inlineActions   = filteredActions.slice(0, maxVisible)
overflowActions = filteredActions.slice(maxVisible)

Overflow is rendered by action:menu. So an action carrying autoTrigger: true that sorts past maxVisible is rendered — it is present, reachable, clickable in the "More" menu — but its auto-trigger is silently dropped, while the caller that set the flag has already treated the signal as spent.

maxVisible defaults to 3 on desktop and mobileMaxVisible to 1 on mobile, so which actions lose their auto-trigger is partly a function of viewport width.

Measurement

Real SchemaRenderer + action:bar + action:button, EnvironmentListToolbar with four list_toolbar actions where the create action is 4th and declares neither order nor variant: 'primary' (so needsOrdering is false and the bar keeps registration order), with ?runAction=create_environment in the URL:

PROBE-OVERFLOW: urlParam=null execute=0 buttons=["a1","a2","a3",""]

The three inline buttons plus the overflow trigger (empty label). Same end state as the #4123 measurement — urlParam=null execute=0, param unrecoverably consumed, nothing triggered — reached by a different mechanism, and not closed by #4123's fix: the create action IS in the post-gate list there, so arming is correct by that predicate; the bar then moves it to a renderer that ignores the flag.

Why it may matter

Same user-visible outcome as #4123: the #844 welcome-page "Create your environment" CTA lands on the list with no dialog and no URL left to retry from. Reachability depends on the deployment's toolbar shape rather than on anything ObjectUI controls:

• on the environments toolbar specifically, the setup_production state gives the create action variant: 'primary', which makes needsOrdering true and floats it into the primary slot — so that state is safe today by accident of the label override, not by design;
• the add_development state applies no variant, so ordering falls to whatever the cloud registers, and a 4th-position create action (or 2nd on mobile) reaches this;
• any other host that composes autoTrigger onto an action it does not also pin to the front has the same exposure. The flag is a client-composed one (never persisted metadata), so hosts are the only producers.

Left as an observation rather than a fix because the right shape is a design question, not a patch — at least three candidates, and they differ in blast radius:

1. action:menu consumes autoTrigger for its items (widest, and "auto-open a menu item" has its own semantics to settle);
2. action:bar treats autoTrigger as an ordering key, so an auto-triggered action can never be the one that spills;
3. the flag is rejected loudly when it lands on a renderer that cannot honour it, making the silent drop impossible — closest to the repo's contract-first instinct, since today a dropped autoTrigger is indistinguishable from one that ran.

Filed as observation-class (finding, no pm:queue) per objectstack#4949 — severity self-assessed at filing time is unreliable, so triage should grade it. Searched open issues first (autoTrigger / maxVisible / action:menu overflow) — no duplicate. Unassigned.

Related

• Landing files: packages/components/src/renderers/action/action-bar.tsx (inline/overflow split), action-menu.tsx (no autoTrigger), action-button.tsx (the only consumer)
• Sibling defect, same signature, different layer: finding(app-shell): useAutoRunCreate strips ?runAction=create_environment even when the toolbar has no create action, destroying the deep link unrecoverably #4123
• Deep-link flow origin: feat: URL-driven debug/developer panel (à la amis devtools) #844

---

Generated by Claude Code

[yinlianghui]

Claim: PM loop round 6 (rolling slot refill)
Session: session_017Qqyix2QcnpUC9XeYVDzx3 · Branch: claude/issue-4162-autotrigger-menu · Worktree: objectui-issue-4162
File surface: packages/components/src/renderers/action/ (action-menu, and the shared autoTrigger contract point) + tests. Serial constraints: #3398 (in flight) is in components/form — different renderer area; disjoint from #4167/#4178/#4181.
Container & model: S, mode:subagent, model: opus

Delegated ruling on the three-way design fork (maintainer's 2026-08-10 delegation; veto window open): the flag's contract is "execute once on mount by whichever renderer receives the action" — so action:menu consumes autoTrigger the same way action:button does (execute, not render-then-hope), making a deep link work regardless of overflow state, which is the least-surprise completion of the transport contract #4123 just fixed the arming for. The other two options are rejected with reasons on the record: ordering-key (bar hoists the auto-triggered action into the visible set) changes VISUAL layout as a side effect of a transport flag — surprising and layout-unstable; reject-loudly turns a working deep link into an error for the crime of being fourth in a list. Guard rails: the menu's execution must reuse action:button's exact once-guard mechanics (no second implementation of once-ness — lift if needed), and if reading the menu's structure reveals a real safety reason execution-from-menu cannot work (confirmation flows? overlay context?), STOP and report — that would falsify the ruling's premise, not bend the implementation.

---

Generated by Claude Code