finding(components): `autoTrigger` executes an action whose own declared `visible` gate hides it — in both renderers

[yinlianghui]

Measured while implementing #4162 (making action:menu consume autoTrigger). Filed separately: it is a property of the FLAG's relationship to the visibility gate, not of the overflow split #4162 fixes, and it predates that card in action:button.

Fact

action:button declares its auto-trigger effect before its visible early return:

useAutoTriggerOnce(hasAutoTrigger(schema), handleClick);   // effect
...
if (hasDeclaredVisibilityGate(schema.visible) && !isVisible) return null;

React commits effects for a component that returns null, so an action carrying both autoTrigger: true and a declared-false visible renders nothing and executes anyway. Measured on origin/main at e16fd9597, real action:button plus the real runner:

PROBE-VISIBLE-FALSE: rendered="" execute=1

Empty DOM, one execution. #4162 extends the same semantics to action:menu deliberately — its whole point is that inline and overflow must not disagree about a flag, and disagreeing here would have re-created the divergence one predicate over. So the two renderers now agree, and this card is about whether what they agree ON is right. The parity itself is pinned in packages/components/src/renderers/action/__tests__/action-overflow-autotrigger.test.tsx ("the ACTION's own declared visible gate does not suppress it"), which points here.

Note the neighbouring rule is different and is not in question: a container that renders nothing mounts no children, so a hidden action:bar or action:menu auto-triggers nothing. That one is pinned too.

Why it may matter

autoTrigger is never persisted metadata — hosts compose it client-side onto an action they already hold, so today's producers set it on an action they have just decided to run. Reaching this needs a host that composes the flag onto an action whose metadata ALSO declares a false visible, which no host in this repo does; that is why this is filed as observation-class rather than as a defect with a user behind it.

The reason it is worth a decision rather than a shrug is that the two gates answer different questions and only one of them is about the user's intent:

• visible is the metadata author's verdict on whether this action may be OFFERED here (fails closed on a throwing predicate, per ActionEngine.getActionsForLocation);
• autoTrigger is the host's statement that the user has already asked for it.

Reading the second as outranking the first means a deep link can invoke an action the author declared unofferable in this context — the runner's own confirm / param / entitlement gates still apply, so this is not an authorization hole, but it is a gate being bypassed by a transport flag. Reading it the other way costs the host a silent no-op, which is the failure mode #4123 and #4162 were both about, so "just gate it" is not obviously right either — a third answer (refuse loudly when both are declared) may fit the repo's contract-first instinct better.

Not fixed here: changing it means changing action:button's behaviour for every existing consumer of #844's flag, which is a design call, not a patch.

Related

• Files: packages/components/src/renderers/action/action-button.tsx, action-menu.tsx, and the shared guard auto-trigger.ts
• The overflow defect this was measured under: 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 #4162
• The arming defect one layer up: finding(app-shell): useAutoRunCreate strips ?runAction=create_environment even when the toolbar has no create action, destroying the deep link unrecoverably #4123 / PR fix(app-shell): arm the create deep link on the create action, not on any toolbar action (#4123) #4166
• Deep-link flow origin: feat: URL-driven debug/developer panel (à la amis devtools) #844
• Searched open issues first (autoTrigger / visible gate / action:menu) — no duplicate. Unassigned.

---

Generated by Claude Code

[claude]

Findings triage (first grade; premise check @ origin/main e1ade8f): HOLD — finding stands.

Anchors verified live in packages/components/src/renderers/action/action-button.tsx: the auto-trigger effect at :157 (useAutoTriggerOnce(hasAutoTrigger(schema), handleClick)) sits above the visibility early return at :164 (if (hasDeclaredVisibilityGate(schema.visible) && !isVisible) return null;) — so the ordering the card's probe measured is exactly what the source says. The parity pin it points at exists: packages/components/src/renderers/action/__tests__/action-overflow-autotrigger.test.tsx.

Held rather than queued: no host in this repo composes autoTrigger onto an action whose metadata also declares a false visible, so there is no live subject — and the card is explicit that the fix is a semantics choice, not a patch. That choice is genuinely three-way (gate it / keep today's precedence / refuse loudly when both are declared), and two of the three change action:button behaviour for every existing consumer of #844's flag.

Worth stating plainly for whoever grades this next: this is not an authorization finding. The runner's confirm / param / entitlement gates still apply; what is bypassed is the author's offer-ability verdict. That distinction is what keeps it observation-class rather than a security card, and it should survive re-grading intact.

Exit path: a decision card once the repo wants the semantics settled — the three options are already written out on this card, so escalation is cheap when someone wants it. Nothing blocks it today.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code

[os-zhuang]

Findings cadence re-check @ origin/main 6314e87: HOLD — finding stands.

Premise live: packages/components/src/renderers/action/action-button.tsx registers useAutoTriggerOnce(hasAutoTrigger(schema), handleClick) at :157 before the declared-visibility gate returns null at :165 — hooks having already run, the auto-trigger effect fires even when the render is suppressed; action-menu.tsx's consumption point (:142/:264-273) shares the contract. Held: real but requires an authored action carrying both autoTrigger: true and a falsy visible gate — no in-repo example does; the fix (gate the trigger on the same visibility verdict) is small and should ride the auto-trigger family (#4162's shared ./auto-trigger module) rather than dispatch alone.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code

[os-zhuang]

Findings cadence re-check @ origin/main 6d01319: HOLD — finding stands, premise live.

Verified on main: the effect still precedes the visibility early-return (action-button.tsx:157 useAutoTriggerOnce(...)), and the parity pin naming this card is live at action-overflow-autotrigger.test.tsx:296 ("the ACTION's own declared visible gate does not suppress it — and inline agrees with overflow"). Recent lane activity on the renderer family (#4207's forward-whitelist gate, #4169's retirement) did not touch this seam. Still unreachable in-repo — no host composes autoTrigger onto a visible:false action — and the runner's confirm/param/entitlement gates keep it short of an authorization hole.

Held rather than escalated: the eventual disposition is a design ruling (host intent vs author verdict vs refuse-loudly), but a decision card with zero reachable producers would sit in the maintainer's inbox ahead of decisions users are actually waiting on. Restart condition: escalate to needs-user-decision the moment any host (or the deep-link flow of #844's lineage) can compose the flag onto an action carrying a declared-false visible — at that point the third option (refuse loudly when both are declared) should be in the fork presented.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code