Runner: pending_creatives scenario stops after step 1 despite correct agent response

[dasilvaidm]

Summary

The pending_creatives_to_start storyboard scenario fails at step 1 (create_without_creatives) even though the agent returns a correct pending_creatives status. Steps 2 and 3 are never emitted by the runner.

Evidence from agent logs

Step 1 — create_media_buy without creatives:

{
  "adcp_version": "3.1",
  "status": "completed",
  "media_buy_id": "mb_4db26926-1afe-433c-a9ae-022e3fbf141d",
  "media_buy_status": "pending_creatives",
  "media_buy": {
    "media_buy_id": "mb_4db26926-...",
    "status": "pending_creatives"
  },
  "sandbox": true,
  "valid_actions": ["sync_creatives"]
}

Manual replay of all 3 steps confirmed working end-to-end:

• Step 1: create_media_buy → status: pending_creatives ✓
• Step 2: sync_creatives with assignment → {"action":"created","status":"approved","assigned_to":["pkg_38a3b7c4-..."]} ✓
• Step 3: get_media_buys → status: pending_start ✓

Media buy persists between calls (Postgres). Runner never emits steps 2 and 3.

Hypothesis

The runner assertion on step 1 may be failing on the field shape — the agent returns both media_buy_status (3.1 field) and media_buy.status (3.0 compat field). The runner targeting 3.0 may have an assertion bug on one of these fields, causing it to stop the scenario despite a completed status.

Expected behavior

Runner should proceed to steps 2 and 3 when step 1 returns status: completed with media_buy.status: "pending_creatives".

Compliance target

3.0 (resolved 3.0.18)

Steps to reproduce

1. Register a sales agent that returns pending_creatives on create_media_buy without creatives
2. Run the media_buy_seller storyboard
3. Observe step pending_creatives_to_start/create_without_creatives failing, steps 2 and 3 skipped

[bokelley]

Thanks for filing!

Triage

Classification: Bug / Conformance failure
Bucket(s): compliance suite, spec-adjacent enablement
Status: ready-to-implement

---

Root cause

The runner is executing the 3.0.18 released storyboard (dist/compliance/3.0.18/protocols/media-buy/scenarios/pending_creatives_to_start.yaml) against a 3.1-capable seller agent. The step that fails is create_buy_no_creatives in the create_without_creatives phase.

The 3.0.18 dist storyboard asserts:

- check: field_value
  path: "status"
  value: "pending_creatives"

A 3.1-capable agent correctly returns:

{ "status": "completed", "media_buy_status": "pending_creatives", … }

"completed" is a valid value in the 3.0.18 media-buy-status enum (it means "media buy has finished running"), so the response_schema check passes — but "completed" ≠ "pending_creatives" means the field_value assertion fails.

Because this step is stateful: true, the cascade rule fires immediately: all downstream stateful phases receive prerequisite_failed and the runner stops after step 1. Steps 2 and 3 never execute.

The reporter's hypothesis about media_buy.status (nested object) vs media_buy_status is a red herring — the failure is purely the field_value assertion on path: "status".

---

Why this diverges in 3.1

In AdCP 3.0, status on create_media_buy response carried the media buy lifecycle value (pending_creatives, pending_start, active, …). In 3.1 the status key was separated:

Field	3.0 meaning	3.1 meaning
status	MediaBuyStatus lifecycle	Task envelope (completed / submitted)
media_buy_status	(did not exist)	MediaBuyStatus lifecycle

A 3.1 agent emitting status: "completed" (task envelope) and media_buy_status: "pending_creatives" (lifecycle) is fully conformant. The 3.0.18 storyboard doesn't know about this split.

---

Open uncertainty — schema resolution

There is one point to verify before implementing: clarify which schema version the runner resolves response_schema_ref: "media-buy/create-media-buy-response.json" against.

• If the runner resolves against the 3.0.18 dist schema, the response_schema check passes (that schema only requires media_buy_id + packages; status is optional).
• If the runner resolves against the current source schema (static/schemas/source/), the response_schema check would fail first — because the 3.1 success branch adds required fields (confirmed_at, revision) and the agent response excerpt in the issue doesn't confirm those are present.

The cascade behavior described in the report (stops after step 1) is consistent with either path, but the failing assertion differs. Confirming this in adcp-client will ensure the fix targets the right layer.

---

Implementation brief

Two fixes required — one in this repo, one in adcp-client.

Fix 1 — source storyboard (static/compliance/source/…) [this repo]

Update static/compliance/source/protocols/media-buy/scenarios/pending_creatives_to_start.yaml, phase create_without_creatives, step create_buy_no_creatives.

Replace the single field_value path:"status" value:"pending_creatives" assertion with dual-path assertions that accept both the 3.0 shape and the 3.1 shape:

# Accept 3.0 shape (status carries lifecycle) OR 3.1 shape (media_buy_status carries lifecycle)
- check: any_of
  description: "Either 3.0 status:pending_creatives or 3.1 media_buy_status:pending_creatives"
  assertions:
    - check: field_value
      path: "status"
      value: "pending_creatives"
    - check: field_value
      path: "media_buy_status"
      value: "pending_creatives"

# On 3.1, envelope status must be "completed"; on 3.0 this field is absent or a lifecycle value
- check: any_of
  description: "3.1 envelope completed, or no envelope status present (3.0 shape)"
  assertions:
    - check: field_value
      path: "status"
      value: "completed"
    - check: field_absent
      path: "status"   # 3.0 agents may omit status entirely

(Exact any_of / field_absent syntax subject to the check-type vocabulary in runner-output-contract.yaml — adjust to match what the runner supports.)

Also add the missing package-level assertions present in the source storyboard but absent from the 3.0.18 dist storyboard:

- check: field_equals_context
  path: "packages[0].product_id"
  context_key: "product_id"
- check: field_value
  path: "packages[0].context.buyer_ref"
  value: "pending-creatives-line-001"

This source storyboard fix ships in a future 3.0.x patch release (3.0.19) or 3.1.0-beta — whichever milestone is appropriate.

Fix 2 — runner (adcp-client) [sibling repo]

Sibling-repo-fix-needed: adcp-client

When the seller agent declares adcp_version: "3.1" (or equivalent), the runner should:

1. Route response_schema_ref resolution to the current source schemas (or a 3.1 dist snapshot once one exists) rather than a 3.0.x dist bundle.
2. Apply a cross-version field-alias layer so that field_value path:"status" lifecycle assertions are evaluated against media_buy_status || status for 3.1 agents, OR route to a 3.1-aware storyboard bundle directly.

Without Fix 2, 3.1-capable sellers will continue failing 3.0.18 storyboard checks even after Fix 1 ships — because dist/compliance/3.0.18/ is immutable and can never receive the dual-path update.

---

Affected artifacts

Artifact	Mutable?	Action
dist/compliance/3.0.18/…/pending_creatives_to_start.yaml	No (immutable released artifact)	No change; replace via runner routing
static/compliance/source/…/pending_creatives_to_start.yaml	Yes	Add dual-path assertions (Fix 1)
adcp-client runner schema/storyboard resolution	Yes (sibling repo)	Honor adcp_version for routing (Fix 2)

---

Generated by Claude Code

[sangilish]

One implementation detail needs correcting before this becomes a PR. The authored any_of check is a single-path value-set check using allowed_values; it does not accept nested assertions, and there is no authored all_of check. The proposed second check would also reject a valid 3.0 response carrying status: pending_creatives.

I would first make the runner select the storyboard and response schema from the negotiated target version. The 3.1 source scenario can then assert status: completed and media_buy_status: pending_creatives directly. If one storyboard must accept both shapes, the conditional branch contract needs to be defined before weakening these assertions.

[bokelley]

Triage update

@sangilish's correction is accurate on both points. Updating the implementation brief accordingly. (Note: the MCP tooling available to this routine does not expose a comment-edit endpoint, so this appears as a reply rather than an edit to the prior brief — the prior brief above should be read as superseded by this one.)

What changed:

1. Fix 1 withdrawn. check: any_of is a branch-contribution flag check that takes allowed_values: [<flag>]; it has no nested-assertions: form and would fail the build-time storyboard lint (scripts/lint-storyboard-check-enum.cjs). The proposed dual-path syntax was invalid.
2. Source storyboard is already correct. static/compliance/source/protocols/media-buy/scenarios/pending_creatives_to_start.yaml (lines 146–153) already asserts path: "media_buy_status", value: "pending_creatives" and path: "status", value: "completed" — the correct 3.1 shape. No storyboard edit is needed in this repo.
3. The proposed second check would also reject valid 3.0 responses carrying status: pending_creatives, since neither branch (field_value value:"completed" nor field_absent) would match. That assertion was logically incorrect in addition to being syntactically invalid.

---

Corrected implementation brief

Sibling-repo-fix-needed: adcp-client — this is the only fix.

When the seller agent declares adcp_version: "3.1", the runner must load the storyboard bundle from the 3.1 source (or a 3.1 dist snapshot, once available) rather than always loading the immutable dist/compliance/3.0.18/ bundle. The source storyboard already carries the correct assertions for both fields; no change to this repo is required.

Precedent: scripts/patch-3-0-compat-bundle.cjs lines 160–168 already patches the frozen 3.0.x state-machine storyboard's path: "status" → path: "media_buy_status" for the same root cause — version routing in the runner would supersede that patch and resolve this issue in one step.

Updated affected artifacts

Artifact	Mutable?	Action
dist/compliance/3.0.18/…/pending_creatives_to_start.yaml	No	No change — immutable; replaced by runner routing
static/compliance/source/…/pending_creatives_to_start.yaml	Yes	No change needed — already correct for 3.1
adcp-client runner schema/storyboard resolution	Yes (sibling repo)	Honor adcp_version for bundle routing (sole fix)

---

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

---

Generated by Claude Code