extend $generate:uuid_v4 to all storyboard scenarios with hardcoded idempotency_keys (follow-up to #4218)

[bokelley]

Background

#4218 (closes #4219) switched the two create_media_buy steps in media_buy_seller/measurement_terms_rejected from hardcoded literal idempotency_key values to $generate:uuid_v4#… aliases. The motivation: hardcoded literals collide cross-run because the runner shifts dynamic start_time substitutions forward to keep the buy future-dated, so against a long-running seller each run produces same key + different canonical body → seller correctly arms IDEMPOTENCY_CONFLICT.

That fix solved the symptom in measurement_terms_rejected, but the same pattern exists in 15 other storyboard steps across 9 scenarios that still use hardcoded literals.

Concrete impact (production seller)

A live media_buy_seller storyboard run against a salesagent deployment that recently rolled out a fix to its CreateMediaBuyResponse shape (variant-1 vs variant-3 split for sync-create-with-pending-creatives) had ALL 5 of its create_buy* storyboard scenarios fail with stale-cache replay errors:

mcp_error: Output validation error: 'submitted' is not one of [...]

The pre-fix runs had populated the seller's IdempotencyStore with the OLD (now-spec-non-compliant) variant-3 responses under those static keys. Post-fix runs replay the stale cached payloads instead of writing fresh ones, blocking 5 stateful chains and cascading into ~43 dependent skipped steps.

Affected scenarios + keys (from compliance/cache/3.0.7/domains/media-buy/scenarios/*.yaml)

Scenario	Hardcoded idempotency_key
creative_fate_after_cancellation	creative-fate-setup-create-buy-v1
creative_fate_after_cancellation	creative-fate-setup-sync-v1
creative_fate_after_cancellation	creative-fate-cancel-v1
creative_fate_after_cancellation	creative-fate-second-buy-v1
creative_fate_after_cancellation	creative-fate-reassign-v1
governance_approved	comply-gov-approved-sync-plans-v1
governance_conditions	comply-gov-conditions-sync-plans-v1
governance_denied	comply-gov-denied-sync-plans-v1
governance_denied_recovery	comply-gov-recovery-sync-plans-v1
governance_denied_recovery	gov-recovery-initial-denied-v1
governance_denied_recovery	gov-recovery-retry-approved-v1
invalid_transitions	invalid-transitions-setup-v1
inventory_list_no_match	inventory-list-no-match-v1
inventory_list_targeting	inventory-list-targeting-create-v1
pending_creatives_to_start	pending-creatives-transition-v1

15 hardcoded keys total, all on create_media_buy / sync_creatives / update_media_buy steps that mutate state.

Proposed fix

Same pattern as #4218: replace each hardcoded literal with $generate:uuid_v4#<scenario>--<step> so each storyboard run mints fresh keys and never collides cross-run with stale cached state.

Why this matters beyond the symptom

The runner's stale-cache replay is correct seller behavior — the spec mandates that an idempotency_key replay returns the cached response. But in practice, any time the spec or seller's emit shape changes (which happens whenever AdCP versions roll forward), every storyboard scenario with a static key becomes a one-shot landmine: works on first run, breaks on every run after the seller updates. The $generate:uuid_v4 pattern is the systemic prevention.

Same reasoning #4218 used. Asking to extend the fix.

Related

• fix(compliance): measurement_terms_rejected — UUID-aliased idempotency_keys + spec-aligned narrative #4218 (the precedent fix for measurement_terms_rejected)
• storyboard: media_buy_seller/measurement_terms_rejected/create_media_buy_relaxed_terms reuses idempotency_key, hits spec-required IDEMPOTENCY_CONFLICT adcp-client#1586 (filed against the runner; closed as not-actionable, deferred to spec)

[bokelley]

Triage

Classification: Bug (compliance harness regression pattern)
Bucket(s): compliance-suite
Status: drafting-pr

What the experts said:

• ad-tech-protocol-expert: Sound — fresh per-run UUIDs are the correct default for feature storyboards; replay coverage lives in universal/idempotency.yaml and is unaffected. sync_plans dynamic key is safe because the governance agent upserts idempotently on plan_id regardless of the idempotency key value.
• code-reviewer: Approved — all 15 keys covered, all 18 new/renamed aliases follow media_buy_seller_<scenario>_<phase>_<step> convention and are globally unique (53/53). Also caught 3 pre-existing non-conventional aliases in governance_denied and invalid_transitions that are cleaned up in the same PR.

My take: Straight extension of the already-merged #4218 pattern. Non-breaking harness-only change; drafting as PR. Compliance build passes with all 12 lints green.

Drafting PR: replaces all 15 hardcoded keys across 9 scenarios + renames 3 pre-existing out-of-convention aliases caught during review.

---

Triaged by Claude Code. Session: https://claude.ai/code/session_016efYC8QLXVZZSPiisZ83oM

---

Generated by Claude Code

[bokelley]

Triage routine stalled (claude-triaging label sat for ~10min with no PR/branch output). Took it over manually — PR #4232 implements the fix following the #4218 precedent: all 15 hardcoded idempotency_keys across the 9 scenarios listed in the issue body are now \$generate:uuid_v4#<scenario>_<step> aliases. Verified no hardcoded literals remain in static/compliance/source/protocols/media-buy/scenarios/.

Will land on main and cherry-pick to 3.0.x for 3.0.8.