@adcp/sdk 14.0.0-rc.49 → 14.0.0-rc.50

package/README.md

@@ -31,10 +31,10 @@ AdCP operations are **distributed and asynchronous by default**. An agent might:
 ```bash
 npm install @adcp/sdk@adcp-3.0   # 7.x, AdCP 3.0
 npm install @adcp/sdk             # 13.x, maintained AdCP 3.1 stable line
-npm install '@adcp/sdk@^14.0.0-0' # newest 14.x prerelease, AdCP 3.2 beta
+npm install @adcp/sdk@rc          # 14.x release candidate, AdCP 3.2 RC
 ```
 
-Trying the v14 prerelease? Read the [release-bound upgrade worksheet](./docs/migration-14.x-rc-worksheet.md) and [14.0.0 prerelease notes](./docs/releases/14.0.0-beta.0.md), then use the [13-to-14](./docs/migration-13-to-14.md) or [12-to-14](./docs/migration-12-to-14.md) migration guide. The npm `latest` tag remains on v13 for the maintained AdCP 3.1 stable line. SDK 14 requires Node.js `^20.19.0 || >=22.12.0`. Older paths: [12-to-13](./docs/migration-12-to-13.md), **[MIGRATION-v8.md](./MIGRATION-v8.md)**, and [8.0-to-8.1](./docs/migration-8.0-to-8.1.md).
+Trying the v14 release candidate? Read the [release-bound upgrade worksheet](./docs/migration-14.x-rc-worksheet.md), then use the [13-to-14](./docs/migration-13-to-14.md) or [12-to-14](./docs/migration-12-to-14.md) migration guide. The [prerelease history](./docs/releases/14.0.0-beta.0.md) covers earlier beta changes. The npm `latest` tag remains on v13 for the maintained AdCP 3.1 stable line. SDK 14 requires Node.js `^20.19.0 || >=22.12.0`. Older paths: [12-to-13](./docs/migration-12-to-13.md), **[MIGRATION-v8.md](./MIGRATION-v8.md)**, and [8.0-to-8.1](./docs/migration-8.0-to-8.1.md).
 
 ### Narrow type imports (`@adcp/sdk/types/<tool>`)
 

package/bin/adcp-grade.js

@@ -37,6 +37,7 @@ Options:
                              neg/007 and neg/018 against an 'either' agent)
                              will FAIL instead of SKIP.
   --only <id[,id...]>        Run only the named vector ids
+  --signing-profile 3.2      Grade only authored 3.2 profile vectors
   --allow-live-side-effects  Opt in to vectors 016/020 against non-sandbox
                              endpoints (USE WITH CARE — creates real orders)
   --allow-http               Allow http:// URLs + private-IP targets (dev loops)
@@ -192,6 +193,15 @@ async function runRequestSigningGrader(args) {
       case '--only':
         options.onlyVectors = parseVectorList(args[++i], '--only');
         break;
+      case '--signing-profile': {
+        const profile = args[++i];
+        if (profile !== '3.2') {
+          console.error(`ERROR: --signing-profile must be "3.2", got "${profile}"\n`);
+          process.exit(2);
+        }
+        options.signingProfileVersion = profile;
+        break;
+      }
       case '--allow-live-side-effects':
         options.allowLiveSideEffects = true;
         break;

package/compliance/cache/{3.1.18/protocols → 3.1.24/domains}/creative/scenarios/billing_out_of_band.yaml

@@ -6,7 +6,6 @@ summary: "Verifies that a creative agent declaring bills_through_adcp: false rej
 track: creative
 introduced_in: "3.1"
 required_tools:
-  - get_adcp_capabilities
   - report_usage
 
 narrative: |

package/compliance/cache/{3.1.18/protocols → 3.1.24/domains}/creative/scenarios/canonical_supported_formats.yaml

@@ -6,7 +6,6 @@ summary: "Verifies the 3.1 creative-agent canonical path: targetable supported_f
 track: creative
 introduced_in: "3.1"
 required_tools:
-  - get_adcp_capabilities
   - build_creative
 
 narrative: |

package/compliance/cache/{3.1.18 → 3.1.24}/domains/creative/scenarios/evaluator_auth.yaml

@@ -6,7 +6,6 @@ summary: "Verifies that build_creative evaluator pointers use the verifier allow
 track: creative
 introduced_in: "3.1"
 required_tools:
-  - get_adcp_capabilities
   - build_creative
 
 narrative: |

package/compliance/cache/{3.1.18/protocols → 3.1.24/domains}/media-buy/index.yaml

@@ -1,5 +1,5 @@
 id: media_buy_seller
-version: "1.0.0"
+version: "1.0.1"
 title: "Media buy seller agent"
 category: media_buy_seller
 summary: "Seller agent that receives briefs, returns products, accepts media buys, and reports delivery."
@@ -37,9 +37,6 @@ narrative: |
   required scenarios that run alongside this storyboard. See requires_scenarios for the
   full set of seller behaviors validated.
 
-context:
-  governance_agent_url: "https://test-agent.adcontextprotocol.org"
-
 agent:
   interaction_model: media_buy_seller
   capabilities:
@@ -178,7 +175,8 @@ phases:
           accounts:
             - brand:
                 domain: "acmeoutdoor.example"
-              operator: "pinnacle-agency.example"
+              operator: "media-buy-lifecycle.pinnacle-agency.example"
+              sandbox: true
               billing: "operator"
               payment_terms: "net_30"
           idempotency_key: "$generate:uuid_v4#media_buy_seller_account_setup_sync_accounts"
@@ -202,57 +200,6 @@ phases:
             value: "media_buy_seller--sync_accounts"
             description: "Context correlation_id returned unchanged"
 
-  - id: governance_setup
-    title: "Governance agent registration"
-    narrative: |
-      The buyer registers their governance agent with your platform. This tells your
-      platform where to call check_governance before confirming media buys.
-
-    steps:
-      - id: sync_governance
-        title: "Register governance agents"
-        narrative: |
-          The buyer tells your platform: "Before you confirm any media buy for this
-          account, call this governance agent to validate it."
-        task: sync_governance
-        schema_ref: "account/sync-governance-request.json"
-        response_schema_ref: "account/sync-governance-response.json"
-        doc_ref: "/accounts/tasks/sync_governance"
-        requires_tool: sync_governance
-        stateful: true
-        expected: |
-          Acknowledge the governance agents. Your platform should:
-          - Store the governance agent URLs for the specified accounts
-          - Return confirmation that agents were registered
-
-        sample_request:
-          accounts:
-            - account:
-                brand:
-                  domain: "acmeoutdoor.example"
-                operator: "pinnacle-agency.example"
-              governance_agents:
-                - url: "$context.governance_agent_url"
-                  authentication:
-                    schemes: ["Bearer"]
-                    credentials: "gov-token-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
-          idempotency_key: "$generate:uuid_v4#media_buy_seller_governance_setup_sync_governance"
-          context:
-            correlation_id: "media_buy_seller--sync_governance"
-          ext:
-            test_platform:
-              governance_tier: "standard"
-
-        validations:
-          - check: response_schema
-            description: "Response matches sync-governance-response.json schema"
-          - check: field_present
-            path: "context"
-            description: "Response echoes back the context object"
-          - check: field_value
-            path: "context.correlation_id"
-            value: "media_buy_seller--sync_governance"
-            description: "Context correlation_id returned unchanged"
 
   - id: product_discovery
     title: "Product discovery"
@@ -307,7 +254,8 @@ phases:
           account:
             brand:
               domain: "acmeoutdoor.example"
-            operator: "pinnacle-agency.example"
+            operator: "media-buy-lifecycle.pinnacle-agency.example"
+            sandbox: true
           context:
             correlation_id: "media_buy_seller--get_products_brief"
 
@@ -427,10 +375,10 @@ phases:
       is no "pending_approval" media buy status — IO review is modelled at the task
       layer, not as a MediaBuy.status value.
 
-      If the buyer registered governance agents in Phase 2, your platform calls
-      check_governance before confirming the buy. The governance agent validates budget
-      authority, brand safety, and compliance. If governance denies the buy, return the
-      denial — don't override it.
+      Governance-aware creation is covered by the dedicated, capability-gated
+      governance scenarios. The base lifecycle leaves the test account ungoverned so
+      every media-buy seller can exercise this universal flow without an undeclared
+      governance_context commitment.
 
     steps:
       - id: create_media_buy
@@ -487,7 +435,7 @@ phases:
           account:
             brand:
               domain: "acmeoutdoor.example"
-            operator: "pinnacle-agency.example"
+            operator: "media-buy-lifecycle.pinnacle-agency.example"
             sandbox: true
           start_time: "asap"
           end_time: "2099-06-30T23:59:59Z"
@@ -557,7 +505,8 @@ phases:
           account:
             brand:
               domain: "acmeoutdoor.example"
-            operator: "pinnacle-agency.example"
+            operator: "media-buy-lifecycle.pinnacle-agency.example"
+            sandbox: true
           media_buy_ids:
             - "$context.media_buy_id"
           context:
@@ -587,6 +536,9 @@ phases:
 
   - id: creative_sync
     title: "Creative sync"
+    requires_capability:
+      path: creative.has_creative_library
+      equals: true
     narrative: |
       With the media buy confirmed, the buyer syncs creative assets to your platform.
       Each package in the buy has creative format requirements — the buyer discovered
@@ -700,7 +652,8 @@ phases:
           account:
             brand:
               domain: "acmeoutdoor.example"
-            operator: "pinnacle-agency.example"
+            operator: "media-buy-lifecycle.pinnacle-agency.example"
+            sandbox: true
           creatives:
             - creative_id: "video_30s_trail_pro"
               name: "Trail Pro 3000 - 30s CTV Spot"
@@ -745,6 +698,7 @@ phases:
 
   - id: delivery_monitoring
     title: "Delivery and reporting"
+    depends_on: [create_buy]
     narrative: |
       The campaign is live. The buyer monitors delivery through two tasks:
       get_media_buys for status and get_media_buy_delivery for performance metrics.
@@ -780,7 +734,8 @@ phases:
           account:
             brand:
               domain: "acmeoutdoor.example"
-            operator: "pinnacle-agency.example"
+            operator: "media-buy-lifecycle.pinnacle-agency.example"
+            sandbox: true
           media_buy_ids:
             - "$context.media_buy_id"
           include_package_daily_breakdown: true

package/compliance/cache/{3.1.18 → 3.1.24}/domains/media-buy/scenarios/creative_fate_after_cancellation.yaml

@@ -1,5 +1,5 @@
 id: media_buy_seller/creative_fate_after_cancellation
-version: "1.0.0"
+version: "1.0.1"
 title: "Creative lifecycle is decoupled from media buy lifecycle"
 category: media_buy_seller
 summary: "Validates that canceling a media buy releases package-creative assignments but leaves the underlying creatives in the library with their review state intact, and that buyers can reuse released creatives on a new buy."
@@ -12,6 +12,10 @@ required_tools:
   - sync_creatives
   - list_creatives
 
+requires_capability:
+  path: creative.has_creative_library
+  equals: true
+
 narrative: |
   Per the creative library model (docs/creative/creative-libraries#creative-state-and-assignment-state-are-separate)
   and the Media Buy State Transitions rule, canceling or rejecting a media buy

package/compliance/cache/{3.1.18/protocols → 3.1.24/domains}/media-buy/scenarios/dependency_impairment.yaml

@@ -1,5 +1,5 @@
 id: media_buy_seller/dependency_impairment
-version: "2.0.0"
+version: "2.0.1"
 title: "Dependency impairment end-to-end — resource transition propagates to media buy health"
 category: media_buy_seller
 summary: "Forces a creative from approved → rejected on a non-terminal media buy, verifies the buy reflects health: impaired with a matching impairments[] entry, and recovers via assignment swap to a different creative (canonical recovery vector — re-approval of the same creative_id is uncommon in production)."
@@ -13,19 +13,13 @@ required_tools:
   - update_media_buy
   - comply_test_controller
 
-# Capability gate: this scenario grades the snapshot-coherence surface, so it
-# runs only for sellers that declare media_buy.propagation_surfaces including
-# "snapshot". Webhook-only or out_of_band sellers grade not_applicable instead
-# of false-failing on a contract that does not apply to them — the opt-out the
-# propagation_surfaces schema already documents (get-adcp-capabilities-response.json)
-# but that was never wired into this scenario. Requires the `contains:` matcher
-# (@adcp/sdk >= 7.70). Sellers that OMIT propagation_surfaces inherit the
-# ["snapshot"] default and are graded here only on @adcp/sdk >= 9.2.0, which
-# materializes capability-gate schema defaults; earlier runners skip them as
-# not_applicable (adcp-client#2278).
+# The 3.1 runner supports one storyboard-level capability predicate. Gate the
+# whole creative workflow on the library declaration, then repeat the snapshot
+# predicate on every phase so webhook-only and out_of_band sellers remain out
+# of scope as well.
 requires_capability:
-  path: media_buy.propagation_surfaces
-  contains: "snapshot"
+  path: creative.has_creative_library
+  equals: true
 
 narrative: |
   Per the dependency-impairment surface ([adcp#2855](https://github.com/adcontextprotocol/adcp/issues/2855)
@@ -118,6 +112,9 @@ prerequisites:
 
 phases:
   - id: setup
+    requires_capability: &snapshot_gate
+      path: media_buy.propagation_surfaces
+      contains: "snapshot"
     title: "Create an active buy with a creative assignment"
     narrative: |
       Discover a product, create a media buy, sync one creative into the library
@@ -339,6 +336,7 @@ phases:
             description: "Controller acknowledged the directive"
 
   - id: baseline_healthy
+    requires_capability: *snapshot_gate
     title: "Baseline: buy reads as healthy, no impairments"
     narrative: |
       With the creative at approved and assigned, the buy MUST report
@@ -383,6 +381,7 @@ phases:
             description: "impairments[] is empty (or absent) in the baseline — no resources are offline yet"
 
   - id: transition_offline
+    requires_capability: *snapshot_gate
     title: "Force the creative to rejected"
     narrative: |
       The seller transitions the creative from approved → rejected via
@@ -422,6 +421,7 @@ phases:
             description: "Controller acknowledged the rejection directive"
 
   - id: verify_impaired
+    requires_capability: *snapshot_gate
     title: "Buy reads as impaired with a matching impairments[] entry"
     narrative: |
       After the rejection, the buy MUST report `health: impaired` and
@@ -520,6 +520,7 @@ phases:
             description: "At least one impairment entry matches the rejected creative, affected package, and rejected transition (forward rule)"
 
   - id: swap_recovery
+    requires_capability: *snapshot_gate
     title: "Recover via assignment swap — different creative replaces the rejected one"
     narrative: |
       Sync a second creative (B) into the library as approved, then use

package/compliance/cache/{3.1.18 → 3.1.24}/domains/media-buy/scenarios/dependency_impairment_cardinality.yaml

@@ -1,5 +1,5 @@
 id: media_buy_seller/dependency_impairment_cardinality
-version: "1.0.0"
+version: "1.0.1"
 title: "Dependency impairment cardinality — impairments[] tracks each offline resource independently"
 category: media_buy_seller
 summary: "Two creatives on two packages of the same buy. Rejects them sequentially and verifies impairments[] grows 0 → 1 → 2; recovers them sequentially via swap-assignment and verifies impairments[] shrinks 2 → 1 → 0. Pressure-tests the inverse rule under cardinality — a seller emitting any impairment entry rather than the right one fails."
@@ -13,19 +13,13 @@ required_tools:
   - update_media_buy
   - comply_test_controller
 
-# Capability gate: this scenario grades the snapshot-coherence surface, so it
-# runs only for sellers that declare media_buy.propagation_surfaces including
-# "snapshot". Webhook-only or out_of_band sellers grade not_applicable instead
-# of false-failing on a contract that does not apply to them — the opt-out the
-# propagation_surfaces schema already documents (get-adcp-capabilities-response.json)
-# but that was never wired into this scenario. Requires the `contains:` matcher
-# (@adcp/sdk >= 7.70). Sellers that OMIT propagation_surfaces inherit the
-# ["snapshot"] default and are graded here only on @adcp/sdk >= 9.2.0, which
-# materializes capability-gate schema defaults; earlier runners skip them as
-# not_applicable (adcp-client#2278).
+# The 3.1 runner supports one storyboard-level capability predicate. Gate the
+# whole creative workflow on the library declaration, then repeat the snapshot
+# predicate on every phase so webhook-only and out_of_band sellers remain out
+# of scope as well.
 requires_capability:
-  path: media_buy.propagation_surfaces
-  contains: "snapshot"
+  path: creative.has_creative_library
+  equals: true
 
 narrative: |
   The base dependency_impairment scenario tests forward + inverse + health-iff
@@ -98,6 +92,9 @@ prerequisites:
 
 phases:
   - id: setup
+    requires_capability: &snapshot_gate
+      path: media_buy.propagation_surfaces
+      contains: "snapshot"
     title: "Create a buy with two packages, two creatives, two assignments"
     narrative: |
       Discover a product, create a buy with two packages (same product is
@@ -396,6 +393,7 @@ phases:
             description: "impairments[] is empty (cardinality zero baseline)"
 
   - id: reject_first_cardinality_one
+    requires_capability: *snapshot_gate
     title: "Reject creative A — impairments[] cardinality 1, scoped to package_a"
     narrative: |
       Force creative A to rejected. The buy MUST report exactly ONE
@@ -525,6 +523,7 @@ phases:
           # an `array_length` check kind — tracked in a follow-up.
 
   - id: reject_second_cardinality_two
+    requires_capability: *snapshot_gate
     title: "Reject creative B — impairments[] grows to cardinality 2"
     narrative: |
       Force creative B to rejected. The buy MUST report exactly TWO
@@ -643,6 +642,7 @@ phases:
           # a creative that isn't offline, failing the invariant.
 
   - id: recover_first_via_swap
+    requires_capability: *snapshot_gate
     title: "Swap package_a's binding to a fresh creative C — cardinality back to 1"
     narrative: |
       Sync creative C (approved), then update_media_buy to swap
@@ -800,6 +800,7 @@ phases:
             description: "impairments[1] MUST NOT exist — the swap recovered A's dependency; only B remains rejected. Cardinality decrement check."
 
   - id: recover_second_via_swap
+    requires_capability: *snapshot_gate
     title: "Swap package_b's binding to a fresh creative D — cardinality back to 0"
     narrative: |
       Sync creative D (approved), swap package_b's binding from B → D, read

package/compliance/cache/{3.1.18/protocols → 3.1.24/domains}/media-buy/scenarios/governance_approved.yaml

@@ -4,11 +4,18 @@ title: "Seller creates buy when governance approves"
 category: media_buy_seller
 summary: "Verifies that the seller creates a media buy when governance approves the transaction."
 track: media_buy
+requires:
+  - multi_agent
+default_agent: sales
 required_tools:
   - sync_governance
   - get_products
   - create_media_buy
 
+requires_capability:
+  path: media_buy.governance_aware
+  equals: true
+
 narrative: |
   This is a multi-agent test. The test harness sets up a permissive governance plan on
   a governance agent with a $100K budget, then registers that agent with the seller.
@@ -76,6 +83,7 @@ phases:
     steps:
       - id: sync_plans
         title: "Create permissive governance plan"
+        agent: governance
         task: sync_plans
         schema_ref: "governance/sync-plans-request.json"
         response_schema_ref: "governance/sync-plans-response.json"
@@ -98,6 +106,9 @@ phases:
                 start: "2020-01-01T00:00:00Z"
                 end: "2099-06-30T23:59:59Z"
               countries: ["US", "CA"]
+        context_outputs:
+          - name: plan_id
+            path: "plans[0].plan_id"
         validations:
           - check: response_schema
             description: "Response matches sync-plans-response.json schema"
@@ -107,6 +118,7 @@ phases:
     steps:
       - id: sync_accounts
         title: "Establish account with seller"
+        agent: sales
         task: sync_accounts
         schema_ref: "account/sync-accounts-request.json"
         response_schema_ref: "account/sync-accounts-response.json"
@@ -131,6 +143,7 @@ phases:
 
       - id: sync_governance
         title: "Register governance agent with seller"
+        agent: sales
         task: sync_governance
         schema_ref: "account/sync-governance-request.json"
         response_schema_ref: "account/sync-governance-response.json"
@@ -159,6 +172,7 @@ phases:
     steps:
       - id: get_products_brief
         title: "Discover products"
+        agent: sales
         task: get_products
         schema_ref: "media-buy/get-products-request.json"
         response_schema_ref: "media-buy/get-products-response.json"
@@ -192,6 +206,7 @@ phases:
 
       - id: create_media_buy
         title: "Create buy (governance approves)"
+        agent: sales
         task: create_media_buy
         schema_ref: "media-buy/create-media-buy-request.json"
         response_schema_ref: "media-buy/create-media-buy-response.json"
@@ -208,6 +223,7 @@ phases:
             brand:
               domain: "acmeoutdoor.example"
             operator: "pinnacle-agency.example"
+          plan_id: "$context.plan_id"
           start_time: "asap"
           end_time: "2099-06-30T23:59:59Z"
           packages:

package/compliance/cache/{3.1.18/protocols → 3.1.24/domains}/media-buy/scenarios/governance_conditions.yaml

@@ -4,11 +4,18 @@ title: "Seller attaches conditions when governance approves with conditions"
 category: media_buy_seller
 summary: "Verifies that the seller attaches governance conditions to the buy when governance approves with conditions."
 track: media_buy
+requires:
+  - multi_agent
+default_agent: sales
 required_tools:
   - sync_governance
   - get_products
   - create_media_buy
 
+requires_capability:
+  path: media_buy.governance_aware
+  equals: true
+
 narrative: |
   This is a multi-agent test. The test harness sets up a governance plan on a governance
   agent with custom policies that trigger conditions (e.g., "CTV buys require weekly
@@ -53,6 +60,7 @@ phases:
     steps:
       - id: sync_plans
         title: "Create conditional governance plan"
+        agent: governance
         task: sync_plans
         schema_ref: "governance/sync-plans-request.json"
         response_schema_ref: "governance/sync-plans-response.json"
@@ -82,6 +90,9 @@ phases:
                 - policy_id: "ugc_brand_safety"
                   enforcement: "must"
                   policy: "UGC placements require brand safety review before activation."
+        context_outputs:
+          - name: plan_id
+            path: "plans[0].plan_id"
         validations:
           - check: response_schema
             description: "Response matches sync-plans-response.json schema"
@@ -91,6 +102,7 @@ phases:
     steps:
       - id: sync_accounts
         title: "Establish account with seller"
+        agent: sales
         task: sync_accounts
         schema_ref: "account/sync-accounts-request.json"
         response_schema_ref: "account/sync-accounts-response.json"
@@ -115,6 +127,7 @@ phases:
 
       - id: sync_governance
         title: "Register governance agent with seller"
+        agent: sales
         task: sync_governance
         schema_ref: "account/sync-governance-request.json"
         response_schema_ref: "account/sync-governance-response.json"
@@ -143,6 +156,7 @@ phases:
     steps:
       - id: get_products_brief
         title: "Discover CTV products"
+        agent: sales
         task: get_products
         schema_ref: "media-buy/get-products-request.json"
         response_schema_ref: "media-buy/get-products-response.json"
@@ -172,6 +186,7 @@ phases:
 
       - id: create_media_buy_conditions
         title: "Create CTV buy (governance approves with conditions)"
+        agent: sales
         task: create_media_buy
         schema_ref: "media-buy/create-media-buy-request.json"
         response_schema_ref: "media-buy/create-media-buy-response.json"
@@ -192,6 +207,7 @@ phases:
               domain: "acmeoutdoor.example"
             operator: "pinnacle-agency.example"
             sandbox: true
+          plan_id: "$context.plan_id"
           start_time: "asap"
           end_time: "2099-06-30T23:59:59Z"
           packages:

package/compliance/cache/{3.1.18 → 3.1.24}/domains/media-buy/scenarios/measurement_terms_rejected.yaml

@@ -1,25 +1,20 @@
 id: media_buy_seller/measurement_terms_rejected
-version: "1.0.0"
+version: "1.0.1"
 title: "Seller rejects unworkable measurement_terms"
 category: media_buy_seller
-summary: "Buyer proposes measurement_terms the seller will not accept; seller returns TERMS_REJECTED; buyer retries with seller-compatible terms."
+summary: "Buyer proposes unworkable measurement_terms and the seller returns TERMS_REJECTED."
 track: media_buy
 required_tools:
   - get_products
   - create_media_buy
 
 narrative: |
-  measurement_terms negotiation is a round-trip. The buyer proposes a measurement vendor,
-  window, and variance tolerance on each package; the seller either accepts (returning
-  measurement_terms echoed in the response) or rejects with TERMS_REJECTED and a message
-  explaining what is unacceptable. The buyer mints a fresh idempotency_key and retries
-  create_media_buy with the adjusted payload — reusing the prior key against a different
-  body MUST be rejected with IDEMPOTENCY_CONFLICT per spec.
+  The buyer proposes a measurement vendor, window, and variance tolerance on each
+  package. This universal scenario sends intentionally unworkable terms and verifies
+  that the seller rejects them with TERMS_REJECTED and an explanatory message.
 
-  This scenario sends an intentionally aggressive first proposal (max_variance_percent: 0
-  with a window the seller does not guarantee), verifies the seller rejects with
-  TERMS_REJECTED, then retries with a relaxed proposal that falls inside the seller's
-  stated tolerance and expects a successful create_media_buy.
+  AdCP 3.1 has no capability bit for measurement-term acceptance, so the optional
+  relaxed-terms success arm is deliberately not graded on this maintenance line.
 
 agent:
   interaction_model: media_buy_seller
@@ -140,64 +135,3 @@ phases:
             path: "context.correlation_id"
             value: "measurement_terms_rejected--aggressive"
             description: "Context correlation_id returned unchanged"
-
-  - id: accept_terms
-    title: "Buyer retries with acceptable terms"
-    narrative: |
-      The buyer relaxes measurement_terms to match the seller's stated capability
-      (c7 window, 10% variance, makegood remedies) and retries. The seller accepts and
-      returns the confirmed terms echoed in the response.
-
-    steps:
-      - id: create_media_buy_relaxed_terms
-        title: "Propose seller-compatible measurement_terms"
-        task: create_media_buy
-        schema_ref: "media-buy/create-media-buy-request.json"
-        response_schema_ref: "media-buy/create-media-buy-response.json"
-        doc_ref: "/media-buy/task-reference/create_media_buy"
-        comply_scenario: create_media_buy
-        stateful: true
-        expected: |
-          The buy succeeds. The response echoes the accepted measurement_terms (possibly
-          normalized by the seller).
-
-        sample_request:
-          brand:
-            domain: "acmeoutdoor.example"
-          account:
-            brand:
-              domain: "acmeoutdoor.example"
-            operator: "pinnacle-agency.example"
-          idempotency_key: "$generate:uuid_v4#media_buy_seller_measurement_terms_rejected_accept_terms_create_media_buy_relaxed_terms"
-          start_time: "asap"
-          end_time: "2099-09-30T23:59:59Z"
-          packages:
-            - product_id: "$context.product_id"
-              budget: 25000
-              pricing_option_id: "$context.pricing_option_id"
-              measurement_terms:
-                billing_measurement:
-                  vendor:
-                    domain: "videoamp.example"
-                  measurement_window: "c7"
-                  max_variance_percent: 10
-                makegood_policy:
-                  available_remedies: ["additional_delivery", "credit"]
-
-          context:
-            correlation_id: "measurement_terms_rejected--relaxed"
-        validations:
-          - check: response_schema
-            description: "Response matches create-media-buy-response.json schema"
-          - check: field_present
-            path: "media_buy_id"
-            description: "Seller returns a media_buy_id after accepting terms"
-          - check: field_present
-            path: "context"
-            description: "Response echoes back the context object"
-          - check: field_value
-            path: "context.correlation_id"
-            value: "measurement_terms_rejected--relaxed"
-            description: "Context correlation_id returned unchanged"
-        reviewer_checks:
-          - "Reviewer MUST confirm the seller releases the idempotency claim after a TERMS_REJECTED response. Probe: send the aggressive-terms request (same key, step 1), then retry with the same key and corrected terms (this step) — the seller MUST return a fresh media_buy_id, not IDEMPOTENCY_CONFLICT. A seller that caches rejected requests would make this two-step retry pattern impossible. See security.mdx#idempotency rule 3 ('Only successful responses are cached')."