fix(runner): reset alias cache at phase boundaries (#1657)

[bokelley]

Summary

Closes #1657.

$generate:uuid_v4#alias placeholders were sharing their WeakMap cache entry across all phases within a single executeStoryboardPass call. When two independent setup phases both used the same alias name (e.g., #setup), the second phase received the same UUID as the first — hitting the seller's idempotency cache and returning stale state from the prior group.

Root cause: the alias cache (a WeakMap<StoryboardContext, Record<string, string>>) is keyed on object identity. Within a pass, context was the same object across phases because the runner only created a fresh identity at pass start (line 1292: let context = { ...options.context }). Step-to-step, forwardAliasCache explicitly propagates the cache — that's correct. But no equivalent reset happened at phase boundaries, so aliases bled across them.

Fix: at the entry of each non-skipped phase, replace context with a spread clone:

context = { ...context };

The new object identity drops the WeakMap alias cache entry — no alias carried forward — while all $context.* values (plain spread properties) survive intact. forwardAliasCache in executeStep still propagates aliases step-to-step within the new phase, so within-phase replay continuity is unaffected.

Placement is after the shouldSkipPhase + continue block — phases that skip execution have no steps, so there is no alias to reset.

Changed files

File	Change
src/lib/testing/storyboard/runner.ts	context = { ...context } at phase boundary entry
test/lib/storyboard-context-generate.test.js	Regression test: phase-boundary reset: alias does not bleed from phase 1 setup into phase 2 setup (#1657)
.changeset/fix-phase-boundary-alias-reset.md	Patch changeset

What was tested

• Existing tests: aliased placeholders resolve to the SAME UUID within a context, bare (no-alias) placeholders each resolve to a FRESH UUID, forwardAliasCache propagates aliases across a shallow-cloned context, shallow-cloned context WITHOUT forwardAliasCache gets a fresh cache — all remain green.
• New regression test: validates within-phase replay still shares UUID (step-roll with forwardAliasCache) and cross-phase alias gets a fresh UUID (no forwardAliasCache at phase boundary).
• Format check: npm run format:check passes.

Pre-PR review

Code reviewer (independent agent): no blockers. Confirmed:

• Placement is correct (after shouldSkipPhase skip, before any step runs).
• context = { ...context } correctly creates a new WeakMap key → fresh alias cache on next injectContext call.
• All three forwardAliasCache call sites in runner.ts are accounted for; none missed.
• Changeset is appropriate (patch bump, no API change).

Note for reviewers: the reviewer flagged one optional nit: the comment could note that the reset also precedes the seeding-cascade early-exit path (lines ~1636-1668). This doesn't affect correctness — those continue paths embed the freshly-reset context — but a one-line callout would aid future readers. Happy to add if you'd like.

Compatibility

• No existing compliance storyboard uses cross-phase aliases: the create_media_buy_async_submitted fixture alias #media_buy_seller_create_submitted_create_media_buy is scoped to a single phase; there are no multi-phase shared aliases in the fixture corpus.
• No API surface change — internal runner behavior only.
• If future storyboards want an alias to persist across phases, forwardAliasCache can be called explicitly at the phase boundary — the mechanism is already there; the default is now correctly opt-in.

---

Triage-managed PR — opened by claude-code triage agent for issue #1657.

https://claude.ai/code/session_01TQwo3hTJAPCeA2Qxa42wCK

---

Generated by Claude Code