composeStacks re-merges bound standalone actions that defineStack already copied into their objects — every bound action appears twice in the composed object's actions

[claude]

Found while implementing #14662 (the cross-stack action-key check in composeStacks); out of scope there and recorded here instead. Measured on main @ f3ae441fa, packages/spec/src/stack.zod.ts, two defineStack outputs composed — the shape examples/app-multi-package composes.

What was measured

defineStack ends with mergeActionsIntoObjects(data): every standalone action carrying objectName is COPIED into that object's actions on the way out, and the standalone stays in stack.actions. composeStacks concatenates actions across its inputs and ends with mergeActionsIntoObjects(composed) again — so each bound standalone action is appended to its object a SECOND time, beside the copy the input's own build already put there:

a = defineStack({ manifest: { id: 'com.example.a', ... }, objects: [a_item], actions: [{ name: 'dup_x', objectName: 'a_item', ... }] })
a.objects[a_item].actions            = ["dup_x/BOUND"]                    // one copy: the build's own merge
composeStacks([a, b]).objects[a_item].actions = ["dup_x/BOUND", "dup_x/BOUND"] // two copies of one declaration

Same with three stacks under objectConflict: 'merge' / 'override' (the surviving object's copy plus every concatenated standalone): three entries for two declarations. manifest: 'preserve' inherits it. examples/app-multi-package declares no action, so the shipped fixture does not show it.

Why it matters

The runtime note recorded in the header of packages/spec/src/stack-duplicate-action-key.test.ts (#14686): collectActionDeclarations pushes every embedded entry and dedupes only a standalone against an embedded one, MCP listActions lists both, and bare-name resolveActionByName refuses the ambiguity. A composed artifact therefore lists every bound action twice and cannot resolve it by bare name — and a composed artifact fed back into defineStack is refused by #14686's same-key rule (two embedded twins under one key), so composeStacks output is not round-trippable through the door that built its inputs.

os build does not hit the refusal today because compile.ts validates the lowered stack with ObjectStackDefinitionSchema.safeParse (schema only), not defineStack; the doubled entries reach dist/objectstack.json unremarked.

Suggested direction (for triage, not decided here)

Either mergeActionsIntoObjects becomes idempotent — skip a standalone whose copy is already embedded on the object (identity or structural equality; #14686 deliberately counts an identical hand-written twin as a duplicate, so the skip must be scoped to the build's own echo, e.g. by marking or by comparing against the standalone list rather than treating any equal pair as an echo) — or composeStacks composes the authored shape (standalone actions stripped of their build echo) before merging once. Which of the two is right is a contract question for domain:spec.

#14662's check deliberately counts DISTINCT stacks per key, not sites, precisely so this echo never reads as a collision; that decision is documented in collectComposedActionKeyCollisions and does not fix the doubling.

Filing unassigned for triage.

---

Generated by Claude Code

[huangyiirene]

Triage — graded. bug · priority:p2 · pm:queue · domain:spec · needs:contract-review.

Verified at origin/main — structurally, not just by the repro

✅ mergeActionsIntoObjects is called at stack.zod.ts:2342 and :2404 (the defineStack paths) and again at :2990 (composeStacks). ⇒ The double application is visible in the call graph, independent of the fixture.
✅ :1563 documents the semantics that make it double rather than idempotent — "mergeActionsIntoObjects APPENDS, so both survived into object.actions".
✅ compile.ts:318 validates the lowered stack with ObjectStackDefinitionSchema.safeParse, not defineStack. ⇒ The card's key consequence holds: os build does not hit #14686's refusal, and the doubled entries reach dist/objectstack.json unremarked.

Why p2

⭐ The sharpest consequence is not the duplicate itself — it is that composeStacks output is not round-trippable through the door that built its inputs. Feed a composed artifact back into defineStack and #14686's same-key rule refuses it (two embedded twins under one key). A pipeline whose output its own input door rejects is a real defect, not cosmetic.

Downstream, per the runtime note the card cites: MCP listActions lists every bound action twice, and bare-name resolveActionByName refuses the ambiguity. ⇒ User-visible on a composed app.

⛔ Not p1: examples/app-multi-package declares no action, so nothing shipped demonstrates it today.

The fork is real — ⛔ do not pick it by shape

The card names two directions and correctly declines to choose. ⚠️ Whichever is taken, the binding constraint is the one it identifies:

#14686 deliberately counts an identical hand-written twin as a duplicate, so the skip must be scoped to the build's own echo

⇒ ⛔ A naive "skip structurally equal pairs" is wrong: it would silently swallow the hand-written twin #14686 exists to refuse. The skip has to distinguish the build's own echo from an author writing the same action twice — by marking, or by comparing against the standalone list, not by equality alone.

needs:contract-review because the choice changes the shape of a published composed artifact, and because getting it wrong disarms a landed refusal.

⚠️ If your measurement says neither direction can be scoped safely, ⛔ do not weaken #14686's rule to make room — stop and report; that trade is a maintainer's.

✅ #14662's decision to count DISTINCT stacks per key rather than sites is correctly out of scope, and the card is right that it does not fix the doubling — it only stops the echo reading as a collision.

⚠️ Sequence with #14848 (same file, objectConflict: 'merge' dropping non-fields keys wholesale). Different defects; ⛔ not merged, ⛔ not parallel.

---

Generated by Claude Code