Runner: inventory_list_no_match fails despite agent returning products:[] correctly

[dasilvaidm]

Summary

The inventory_list_no_match storyboard scenario fails even though the agent returns a correct empty product list.

Evidence from agent logs

• Brief sent by runner: "Video inventory on outdoor lifestyle programming. Q3 flight."
• Agent response: {"status":"completed","products":[]}
• Agent log: returnedProductIds: [] at correlation_id inventory_list_no_match--get_products_brief

The agent correctly returns an empty list with no error. The runner marks the step as failed.

Hypothesis

The runner assertion on this step may be checking for a specific error code or non-empty response instead of accepting products: [] as a valid "no match" result.

Expected behavior

When get_products returns {"status":"completed","products":[]}, the inventory_list_no_match scenario should pass.

Compliance target

3.0 (resolved 3.0.18)

Steps to reproduce

1. Register a sales agent with a defined product catalog
2. Run the media_buy_seller storyboard
3. Observe inventory_list_no_match/discover failing despite agent returning empty products array

[bokelley]

Triage

Classification: Conformance failure (agent-side); storyboard clarity gap (secondary)
Bucket(s): compliance suite (label missing from repo — noted in triage run)
Status: ready-to-implement
Milestone: Spec Backlog

What the experts said:

• ad-tech-protocol-expert: Runner is correct — the discover step must yield real catalog products so Phase 2 can substitute $context.product_id into create_media_buy; "no match" in this scenario's name refers to the targeting_overlay (property_list + collection_list) in Phase 2, not to get_products returning empty. key: → name: diverges from the schema spec.
• code-reviewer: Agrees runner is correct. key: is empirically accepted by the runner (25 production storyboards use it; passing e2e test confirms). Separately flags stale dist/compliance/3.0.0/ — it diverges from source, missing the field_present validation; a 3.0.x patch release is needed to deliver the fix to adopters running against dist artifacts.

Experts split on key: vs name:: protocol-expert reads the schema comment as normative; code-reviewer found the runner accepts both at runtime. Neither position changes the primary failure diagnosis.

My take: The agent under test is wrong — plain catalog discovery must return real products; the "no match" happens in Phase 2's targeting_overlay. Two storyboard improvements are worth shipping: (1) add an explicit field_present on products[0] before the nested assertion with a description making Phase 1's role clear; (2) resolve key:/name: ambiguity in storyboard-schema.yaml.

Implementation scope:

• static/compliance/source/protocols/media-buy/scenarios/inventory_list_no_match.yaml — add check: field_present, path: "products[0]" as first validation with description: "Discover phase must return ≥1 product; the no-match targeting is exercised via targeting_overlay in Phase 2"
• static/compliance/source/universal/storyboard-schema.yaml — document whether key: is a supported alias or require name: exclusively
• patch changeset for adcontextprotocol; non-breaking (additive validation only)
• Include dist/compliance/3.0.0/ update in the same patch release (stale vs source)

---

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

---

Generated by Claude Code

[bokelley]

Closing because the reported result is non-conformant for this scenario, not a runner defect. The discover phase must return at least one real catalog product so Phase 2 can substitute product_id; no_match refers to the targeting_overlay exercised afterward. The incidental video-only wording is being removed under #5896, but products: [] will correctly remain a failure here. Released dist artifacts are immutable and will not be hand-edited.