compliance(media-buy): available_actions should be runnable by sales-non-guaranteed-only sellers

[fgranata]

Problem

Follows the same root cause as the base media_buy_seller flow fix (recently merged): available_actions.yaml seeds a guaranteed-only product fixture (available_actions_display, delivery_type: guaranteed). A seller declaring only specialisms: ["sales-non-guaranteed"] correctly rejects a guaranteed buy with a terminal DELIVERY_MODE_NOT_SUPPORTED, so create_buy_from_product fails and the whole enforcement flow (read_persisted_buy_actions, enforce_available_actions) cascades as prerequisite_failed.

Change

Switch the fixture to non_guaranteed (fixed_price → floor_price). The allowed_actions behavior this scenario actually grades (self-serve vs requires-approval action enforcement) is delivery-type-agnostic, so nothing about the test's intent changes. The create steps reference the product/pricing by id, unchanged.

Reproduction

Against a live sales-non-guaranteed seller, media_buy_seller/available_actions → create_buy_from_product returns DELIVERY_MODE_NOT_SUPPORTED (terminal) → downstream steps prerequisite_failed.

Scope note for maintainers

This is the second incidental guaranteed-only fixture (after the base flow). I found 8 other media-buy scenarios that also seed delivery_type: guaranteed (billing_finality_delivery, create_media_buy_async, measurement_accountability, vendor_metric_accountability, delivery_reporting, canonical_formats, get_products_async, governance_approved). I deliberately did not touch those — some likely test guaranteed-specific behavior on purpose (e.g. governance_approved's IO-approval, the async arms) and should stay guaranteed + be capability-gated rather than flipped. Happy to follow up per your guidance on which are incidental vs intentional.

Source-only change; the packaged dist/compliance/ cache is generated by the build.

🤖 Generated with Claude Code

[aao-release-bot]

⚠️ Argus review could not complete

The automated review encountered an issue (possibly reached max turns, timed out, or failed to post the final gh pr review). A human reviewer should take this PR.

View workflow run

_{This is an automated message from the Argus AI review workflow.}

[fgranata]

Gentle nudge on this one. The sibling fix for the base media_buy_seller flow (#5703, same root cause and rationale — an incidental delivery_type: guaranteed fixture) merged on 2026-06-26, but this available_actions counterpart is still open.

On the current graded cache (3.1.1, @adcp/sdk@latest = 9.6.2), media_buy_seller/available_actions stays red for sales-non-guaranteed-only sellers for exactly the reason in the description: the guaranteed-only product fixture makes create_buy_from_product reject with a terminal DELIVERY_MODE_NOT_SUPPORTED, cascading read_persisted_buy_actions + enforce_available_actions as prerequisite_failed. The allowed_actions behavior the scenario actually grades is delivery-type-agnostic, so the non_guaranteed switch doesn't change the test's intent.

Happy to rebase if it's drifted from main, or to fold in the other 8 guaranteed-only scenarios from the scope note as a single sweep if you'd rather review one PR than several — whichever is easier on your side.

[fgranata]

@bokelley checking in on this one — the sibling base-flow fix (#5703) merged on 2026-06-26, but this available_actions counterpart is still open, and on the current graded cache (3.1.1) it remains the last blocker for the guaranteed-fixture cluster (available_actions plus the same-class scenarios flagged in the scope note): sales-non-guaranteed-only sellers still fail create_buy_from_product with a terminal DELIVERY_MODE_NOT_SUPPORTED cascade. The allowed_actions enforcement this scenario grades is delivery-type-agnostic, so the non_guaranteed fixture switch doesn't change the test's intent. Anything you need from my side — rebase, or folding the other 8 guaranteed-only scenarios into this PR as a single sweep?

[fgranata]

@bokelley — one more check-in on this one. On the current graded 3.1.x cache it remains the last blocker for the guaranteed-fixture cluster on sales-non-guaranteed-only sellers (available_actions + the same-class scenarios): our latest full run still shows exactly these three reds and nothing else. It's the same one-line fixture class as #5703, which you merged on 2026-06-26.

cc @EmmaLouise2018 @nastassiafulconis — in case Brian's queue is deep: this is a two-line compliance-fixture change (guaranteed → non_guaranteed seed, sibling of merged #5703), CI is green, and it needs no seller-side coordination — any maintainer can land it.

While I have you: #5783 is in the same boat — it's the contract-documentation PR Brian green-lit in #5337 ("Go ahead with the contract PR"), scoped exactly to his implementation notes there, all checks green since 2026-07-01. Landing both closes out the whole runner-contract thread (#5337 can then close too).

[bokelley]

Approved. The scenario grades allowed_actions rather than guaranteed delivery, so changing the incidental fixture to non_guaranteed removes a false failure for sales-non-guaranteed-only sellers without weakening the behavior under test. The source-only compliance fix and changeset are correctly scoped; all checks are green, with no CodeQL findings or unresolved threads.

[bokelley]

Correction after checking the changeset frontmatter against the repository playbook: this PR changes a published compliance asset, but .changeset/available-actions-non-guaranteed.md is an empty changeset. Empty changeset padding is explicitly disallowed. Please declare adcontextprotocol as a patch in that changeset; the scenario change itself remains approved.

[bokelley]

The required adcontextprotocol patch changeset is now present. The compliance fixture change remains correctly scoped and CI can rerun on the updated head.

[fgranata]

Thanks for merging this! One follow-up on propagation: a fresh graded run against our agent (today, after the merge) still seeds a guaranteed delivery buy in the available_actions scenario — same terminal DELIVERY_MODE_NOT_SUPPORTED as before. The merged source yaml is correct on main (delivery_type: "non_guaranteed", line 71), so it looks like the packaged compliance cache the grading engine consumes hasn't been regenerated yet — the changeset notes dist/compliance/ is generated from this source, and the latest published @adcp/sdk (12.0.3) predates the merge with no storyboard changes.

Could you say when the regenerated cache ships (next npm publish?) or whether the AAO engine can refresh from source sooner? Happy to re-verify the moment it does — the identical fixture fix in the base media_buy flow (#5703) went green against us with no seller change, so we expect the same here.

[bokelley]

The regenerated cache is already published. The v3.1.4 Version Packages run (PR #5909, merged 2026-07-19 00:26 UTC — ~4.5 h after this PR's merge) rebuilt dist/compliance/ from source and shipped dist/compliance/3.1.4/domains/media-buy/scenarios/available_actions.yaml with the non_guaranteed fixture. That artifact is live in adcontextprotocol@3.1.4.

The remaining lag is on the @adcp/sdk side: 12.0.3 was published before the merge, so it doesn't yet pin to adcontextprotocol@3.1.4. A new @adcp/sdk release that bumps the adcontextprotocol dep to >=3.1.4 is what will make the grading engine pick up the fix automatically. @bokelley — is an @adcp/sdk release planned, or should the AAO engine be pointed at the adcontextprotocol@3.1.4 tarball directly in the interim?

---

Generated by Claude Code

[fgranata]

Quick data point while the cache regen is pending: we ran the merged scenario source (packaged cache locally patched with this PR's non_guaranteed fixture, @adcp/sdk 12.0.3 runner, no other changes) against our production agent — 11/11 steps pass, track green, overall_status: passing, including the full available-actions enforcement flow beyond the previously-blocked create_buy_from_product step. So once the packaged compliance cache regenerates from this source, the scenario should grade clean with no seller-side changes.

[fgranata]

(Our comments crossed — thanks for the fast turnaround on the 3.1.4 regen.) That matches what we see: the lag is the @adcp/sdk dep pin, and per the data point above, grading against the 3.1.4 fixture should be clean on our side either way. Whichever path is faster works for us — a new @adcp/sdk release or pointing the AAO engine at adcontextprotocol@3.1.4 directly. We'll re-verify on the next graded run.

[fgranata]

We pulled the v3.1.4 release asset to verify before re-running, and it looks like the regen didn't capture this fix: 3.1.4.tgz (sha256 3e502fed2bae500ca120afe9e7cbacbd4f9307e9c7c3b271346acc7c71acea51) still contains the old fixture —

adcp-3.1.4/compliance/protocols/media-buy/scenarios/available_actions.yaml
65:      delivery_type: "guaranteed"

— while static/compliance/source/.../available_actions.yaml on main correctly has non_guaranteed (line 71). Timeline checks out oddly: this PR merged 2026-07-18 19:50 UTC and the v3.1.4 tag was cut 2026-07-19 00:26 UTC, so the release postdates the merge but its packaged compliance snapshot doesn't include it — possibly the Version Packages branch built its compliance dir before this merge and wasn't regenerated at cut time. Could you regenerate/release (3.1.5?) with the current source? Happy to verify the new asset the moment it's up — we've already confirmed the fixed scenario passes end-to-end against our agent (11/11 above).

[bokelley]

Your tarball check is correct, and I can confirm it from the repository directly: both dist/compliance/3.1.4/protocols/media-buy/scenarios/available_actions.yaml and dist/compliance/3.1.4/domains/media-buy/scenarios/available_actions.yaml have delivery_type: "guaranteed" (line 65). The earlier comment claiming the fix was in 3.1.4 was wrong — I apologize for the confusion.

What happened: Version Packages PR #5909 was created and built its compliance snapshot before this PR merged at 19:50 UTC. Merging #5909 afterward applied its pre-built dist/compliance/3.1.4/ artifacts without regenerating them, and the changeset from this PR (available-actions-non-guaranteed.md) wasn't consumed in that run.

What's queued: The changeset is now in the open Version Packages PR #5785, listed under the adcontextprotocol@3.2.0 patch changes section. When #5785 merges, the compliance cache will regenerate from the corrected source and the fix ships.

@bokelley — two things for your call: (1) if adopters need this on the 3.1.x line before 3.2.0 ships, a 3.1.5 patch would need to be cut separately (cherry-pick of the compliance fixture change); (2) otherwise, merging #5785 is the path. What's the priority here?

---

Generated by Claude Code

[fgranata]

Thanks for confirming and for the clear explanation — that mechanism makes sense. From our side as an affected adopter: no urgency preference if #5785 / 3.2.0 is close; if it's likely to sit open for a while, a 3.1.5 cherry-pick would let graded runs pick up the fixture sooner. Either way we'll verify the shipped asset as soon as it's out — we've already confirmed the corrected scenario passes end-to-end against our agent, so we expect it to grade clean immediately.