valid_actions warning persists despite field present in get_media_buys response

[danoykin]

Summary

The missing-valid-actions advisory fires on media_buy_seller/pending_creatives_to_start/verify_transition even when valid_actions is present in every get_media_buys response, including the pending_start status.

SDK version

@adcp/sdk 7.11.1 (AdCP 3.0.12)

Steps to reproduce

1. Implement a sales agent that returns valid_actions inside each buy object in get_media_buys
2. Run npx adcp storyboard run <agent> sales_guaranteed --allow-http --auth <token>
3. Both capability tracks pass (28/28 Media Buy Lifecycle, 3/3 Reporting & Delivery)
4. Advisory still fires: Agent does not return valid_actions in get_media_buys response

Evidence

Server logs confirm valid_actions is present for all statuses including pending_start:

{
  "media_buy_id": "...",
  "status": "pending_start",
  "valid_actions": ["cancel", "update_budget", "update_dates", "update_packages", "add_packages", "sync_creatives"],
  "available_actions": [{"action": "cancel", "mode": "self_serve"}]
}

Expected behavior

Warning should not fire when valid_actions is present in all buy objects.

Hypothesis

The compliance checker's observation data extraction may occur before the valid_actions field reaches the final wire format in the pending_creatives_to_start scenario specifically.

Labels

bug, sdk, storyboard

[bokelley]

Thanks for filing!

Triage

Classification: Bug (false positive advisory)
Bucket(s): compliance-suite, media-buy
Status: ready-for-human

What the experts said:

• ad-tech-protocol-expert: storyboard is correct as-is — the advisory fires from runner logic in adcp-client, not from a storyboard validation; no spec change needed here.
• code-reviewer: shared comply_scenario: media_buy_lifecycle on both assign_creative_to_package (update_media_buy) and get_media_buy_after_sync (get_media_buys) is the likely dispatch-key source of the step confusion in comply.ts:160-181.

My take: Root cause is in the adcp-client runner's advisory dispatch, not in this storyboard. Both conformance tracks pass and the advisory is best-practice severity — certification is not blocked. @bokelley: please file the upstream issue in adcp-client targeting comply.ts:160-181 and convert this issue to Blocked-on once the adcp-client issue number is known.

Sibling-repo-fix-needed: adcp-client src/lib/testing/compliance/comply.ts:160-181. The missing-valid-actions check likely dispatches by comply_scenario rather than storyboard step identity; both assign_creative_to_package and get_media_buy_after_sync share comply_scenario: media_buy_lifecycle, which is the likely source of the false positive in the pending_creatives_to_start flow specifically.

Related: #4751 (same advisory text at the AAO scoring engine layer, closed 2026-05-30) — that issue confirmed the CLI runner reads live wire data, so #5319 is a distinct root cause path.

Workaround: Both tracks pass (28/28 and 3/3); advisory does not affect conformance scoring. Safe to proceed with certification.

---

Triaged by Claude Code. Session: https://claude.ai/code/${CLAUDE_CODE_REMOTE_SESSION_ID}

---

Generated by Claude Code

[sangilish]

Quick update: I opened adcontextprotocol/adcp-client#2172 with a narrow runner fix that scans all get_media_buys observations before emitting missing-valid-actions. CI is green; I’d leave this issue open until the SDK PR is reviewed and merged.

[bokelley]

Blocked-on: adcp-client#2172 — resurfaces on merge

---

Generated by Claude Code