@adcp/sdk 13.0.1 → 13.0.3

package/compliance/cache/{3.1.15.previous/protocols → 3.1.20/domains}/media-buy/scenarios/inventory_list_targeting.yaml

@@ -1,38 +1,40 @@
 id: media_buy_seller/inventory_list_targeting
-version: "1.0.0"
-title: "Seller honors property_list and collection_list targeting on create and update"
+version: "1.0.1"
+title: "Seller honors property_list targeting on create and update"
 category: media_buy_seller
-summary: "Verifies that a seller accepts PropertyListReference and CollectionListReference in package targeting on create_media_buy AND update_media_buy, with parity between both paths."
+summary: "Verifies that a seller accepts PropertyListReference in package targeting on create_media_buy AND update_media_buy, with parity between both paths."
 track: media_buy
 required_tools:
   - get_products
   - create_media_buy
   - update_media_buy
+  - get_media_buys
+
+requires_capability:
+  path: "media_buy.features.property_list_filtering"
+  equals: true
 
 narrative: |
   AdCP 3.0 targets inventory through agent-hosted reference lists rather than inline
-  property arrays. Buyers point a package's targeting at a `PropertyListReference`
-  and/or `CollectionListReference`; the seller resolves the list against its own
-  inventory at serve time.
+  property arrays. Buyers point a package's targeting at a `PropertyListReference`;
+  the seller resolves the list against its own inventory at serve time.
 
   A common integration regression is create/update parity: a seller accepts list
   references on create_media_buy but silently drops them on update_media_buy, so a
-  buyer who edits a live buy loses their list targeting. This scenario writes both
-  list types on create, then swaps both on update, and finally reads the buy back
-  to confirm the updated references are what the seller persisted.
+  buyer who edits a live buy loses their list targeting. This scenario writes the
+  property list on create, swaps it on update, and finally reads the buy back to
+  confirm the updated reference is what the seller persisted.
 
-  The buyer references pre-populated inventory lists from the test kit — one for
-  matching properties and one for matching collections — so the seller's test
-  engine can resolve them without needing a live governance/inventory agent.
+  The buyer references a pre-populated property list from the test kit so the
+  seller's test engine can resolve it without needing a live governance agent.
 
 agent:
   interaction_model: media_buy_seller
   capabilities:
     - sells_media
     - supports_property_list_targeting
-    - supports_collection_list_targeting
   examples:
-    - "Sellers that accept PropertyListReference / CollectionListReference in package targeting"
+    - "Sellers that accept PropertyListReference in package targeting"
 
 caller:
   role: buyer_agent
@@ -40,14 +42,14 @@ caller:
 
 prerequisites:
   description: |
-    The seller must accept PropertyListReference and CollectionListReference in
-    package targeting on both create_media_buy and update_media_buy. List contents
-    come from test-kits/acme-outdoor.yaml → inventory_targets.
+    The seller must accept PropertyListReference in package targeting on both
+    create_media_buy and update_media_buy. List contents come from
+    test-kits/acme-outdoor.yaml → inventory_targets.
   test_kit: "test-kits/acme-outdoor.yaml"
 
 phases:
   - id: discover_product
-    title: "Discover a product that supports list targeting"
+    title: "Discover a product that supports property-list targeting"
     steps:
       - id: get_products_brief
         title: "Discover product"
@@ -58,8 +60,8 @@ phases:
         comply_scenario: full_sales_flow
         stateful: false
         expected: |
-          Return at least one product whose targeting supports property_list and
-          collection_list references.
+          Return at least one product whose targeting supports a property_list
+          reference.
 
         sample_request:
           buying_mode: "brief"
@@ -89,16 +91,16 @@ phases:
             path: "products[0].pricing_options[0].fixed_price"
             description: "The captured pricing option is fixed-price; fixed-price storyboards do not send bid_price"
 
-  - id: create_with_both_lists
-    title: "Create media buy with property_list AND collection_list targeting"
+  - id: create_with_property_list
+    title: "Create media buy with property_list targeting"
     narrative: |
-      The buyer references the matching-property list and the matching-collection
-      list from the test kit. The seller accepts both references, creates the buy,
-      and echoes the resolved targeting back on the package.
+      The buyer references the matching-property list from the test kit. The
+      seller accepts the reference, creates the buy, and echoes the resolved
+      targeting back on the package.
 
     steps:
       - id: create_buy_with_lists
-        title: "create_media_buy with both list references"
+        title: "create_media_buy with a property-list reference"
         task: create_media_buy
         schema_ref: "media-buy/create-media-buy-request.json"
         response_schema_ref: "media-buy/create-media-buy-response.json"
@@ -106,10 +108,9 @@ phases:
         comply_scenario: create_media_buy
         stateful: true
         expected: |
-          The seller accepts the list references without error. The response
-          includes a media_buy_id and the package retains both the property_list
-          and collection_list targeting fields so subsequent get / update calls
-          can read them back.
+          The seller accepts the list reference without error. The response
+          includes a media_buy_id and the package retains the property_list
+          targeting field so subsequent get / update calls can read it back.
 
         sample_request:
           brand:
@@ -130,10 +131,6 @@ phases:
                 property_list:
                   agent_url: "https://governance.pinnacle-agency.example"
                   list_id: "acme_outdoor_allowlist_v1"
-                collection_list:
-                  agent_url: "https://governance.pinnacle-agency.example"
-                  list_id: "acme_outdoor_collections_v1"
-
           context:
             correlation_id: "inventory_list_targeting--create_buy_with_lists"
         context_outputs:
@@ -154,9 +151,9 @@ phases:
   - id: verify_create_persisted
     title: "Verify list targeting persisted after create"
     narrative: |
-      Read the buy back to confirm the seller stored both list references — not just
-      echoed them back in the create response. This catches sellers that parse list
-      references on create but never persist them to their internal package model.
+      Read the buy back to confirm the seller stored the list reference — not just
+      echoed it back in the create response. This catches sellers that parse the
+      list reference on create but never persist it to their internal package model.
 
     steps:
       - id: get_after_create
@@ -169,7 +166,7 @@ phases:
         stateful: true
         expected: |
           Return the media buy with packages[0].targeting_overlay.property_list
-          and .collection_list populated with the list_id values sent on create.
+          populated with the list_id value sent on create.
 
         sample_request:
           account:
@@ -189,22 +186,18 @@ phases:
             path: "media_buys[0].packages[0].targeting_overlay.property_list.list_id"
             value: "acme_outdoor_allowlist_v1"
             description: "property_list.list_id persisted after create"
-          - check: field_value
-            path: "media_buys[0].packages[0].targeting_overlay.collection_list.list_id"
-            value: "acme_outdoor_collections_v1"
-            description: "collection_list.list_id persisted after create"
 
   - id: update_swap_lists
-    title: "Swap property_list and collection_list via update_media_buy"
+    title: "Swap property_list via update_media_buy"
     narrative: |
-      The buyer swaps both list references. This is the create/update parity check:
-      a seller that accepts list references on create but silently drops them on
+      The buyer swaps the list reference. This is the create/update parity check:
+      a seller that accepts the reference on create but silently drops it on
       update would fail to update the persisted targeting. We exercise update
       explicitly to catch that class of regression.
 
     steps:
       - id: update_buy_swap_lists
-        title: "update_media_buy replaces both list references"
+        title: "update_media_buy replaces the property-list reference"
         task: update_media_buy
         schema_ref: "media-buy/update-media-buy-request.json"
         response_schema_ref: "media-buy/update-media-buy-response.json"
@@ -212,8 +205,8 @@ phases:
         comply_scenario: media_buy_lifecycle
         stateful: true
         expected: |
-          The seller acknowledges the updated targeting. Both property_list and
-          collection_list are replaced (not merged) with the new list_id values.
+          The seller acknowledges the updated targeting. property_list is
+          replaced (not merged) with the new list_id value.
 
         sample_request:
           account:
@@ -227,10 +220,7 @@ phases:
               targeting_overlay:
                 property_list:
                   agent_url: "https://governance.pinnacle-agency.example"
-                  list_id: "acme_outdoor_no_match_v1"
-                collection_list:
-                  agent_url: "https://governance.pinnacle-agency.example"
-                  list_id: "acme_outdoor_no_match_collections_v1"
+                  list_id: "acme_outdoor_allowlist_v2"
 
           idempotency_key: "$generate:uuid_v4#media_buy_seller_inventory_list_targeting_update_swap_lists_update_buy_swap_lists"
           context:
@@ -250,10 +240,7 @@ phases:
               targeting_overlay:
                 property_list:
                   agent_url: "https://governance.pinnacle-agency.example"
-                  list_id: "acme_outdoor_no_match_v1"
-                collection_list:
-                  agent_url: "https://governance.pinnacle-agency.example"
-                  list_id: "acme_outdoor_no_match_collections_v1"
+                  list_id: "acme_outdoor_allowlist_v2"
             description: "Update response returns the affected package with complete post-update targeting state"
 
       - id: get_after_update
@@ -285,9 +272,5 @@ phases:
             description: "Response matches get-media-buys-response.json schema"
           - check: field_value
             path: "media_buys[0].packages[0].targeting_overlay.property_list.list_id"
-            value: "acme_outdoor_no_match_v1"
+            value: "acme_outdoor_allowlist_v2"
             description: "property_list.list_id updated after update_media_buy"
-          - check: field_value
-            path: "media_buys[0].packages[0].targeting_overlay.collection_list.list_id"
-            value: "acme_outdoor_no_match_collections_v1"
-            description: "collection_list.list_id updated after update_media_buy"

package/compliance/cache/{3.1.15/protocols → 3.1.20/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')."

package/compliance/cache/{3.1.15.previous → 3.1.20}/domains/media-buy/scenarios/pending_creatives_to_start.yaml

@@ -1,17 +1,16 @@
 id: media_buy_seller/pending_creatives_to_start
-version: "1.0.0"
+version: "1.0.1"
 title: "Creative sync unblocks pending_creatives → pending_start"
 category: media_buy_seller
 summary: "Verifies that a media buy created without creatives sits in pending_creatives until sync_creatives completes, then transitions to pending_start."
 track: media_buy
 
-# This scenario requires an explicit auto-approval declaration. Sellers that
-# declare `require_human`, or omit the field because approval behavior is
-# legacy-unspecified, grade not_applicable rather than false-failing on a
-# manual-review workflow.
+# This scenario requires a creative library. The 3.1 runner supports one
+# storyboard-level capability predicate, so the auto-approval predicate is
+# repeated on each phase below to preserve both applicability conditions.
 requires_capability:
-  path: media_buy.creative_approval_mode
-  equals: auto_approve
+  path: creative.has_creative_library
+  equals: true
 
 required_tools:
   - get_products
@@ -52,6 +51,9 @@ prerequisites:
 
 phases:
   - id: setup
+    requires_capability: &auto_approval_gate
+      path: media_buy.creative_approval_mode
+      equals: auto_approve
     title: "Discover products and formats"
     steps:
       - id: get_products_brief
@@ -91,6 +93,7 @@ phases:
             description: "The captured pricing option is fixed-price; fixed-price storyboards do not send bid_price"
 
   - id: create_without_creatives
+    requires_capability: *auto_approval_gate
     title: "Create media buy without creative_assignments"
     narrative: |
       The buyer intentionally omits creative_assignments. The seller must accept the
@@ -168,6 +171,7 @@ phases:
             description: "Created package echoes package-level context for legacy package correlation"
 
   - id: supply_creatives
+    requires_capability: *auto_approval_gate
     title: "Supply creatives and assign to the package"
     narrative: |
       The buyer syncs a creative with the format the product requires, then updates the
@@ -260,6 +264,7 @@ phases:
             description: "Envelope task-status is completed on synchronous update success (protocol-envelope.json required: [status])"
 
   - id: verify_transition
+    requires_capability: *auto_approval_gate
     title: "Verify the status transition"
     narrative: |
       Independently of the update_media_buy response, call get_media_buys to confirm the

package/compliance/cache/{3.1.15.previous → 3.1.20}/domains/media-buy/scenarios/refine_products.yaml

@@ -1,5 +1,5 @@
 id: media_buy_seller/refine_products
-version: "1.0.0"
+version: "1.0.1"
 title: "Seller handles product refinement"
 category: media_buy_seller
 summary: "Verifies that a media buy seller supports buying_mode: refine with product-level and request-level changes."
@@ -7,6 +7,10 @@ track: media_buy
 required_tools:
   - get_products
 
+requires_capability:
+  path: media_buy.buying_modes
+  contains: refine
+
 narrative: |
   After a buyer receives products from a brief, they refine the results without starting
   over. The buyer calls get_products with buying_mode: refine and a refine array describing

package/compliance/cache/{3.1.15 → 3.1.20}/index.json

@@ -1,7 +1,7 @@
 {
-  "published_version": "3.1.15",
-  "adcp_version": "3.1.15",
-  "generated_at": "2026-08-16T19:12:23.779Z",
+  "published_version": "3.1.20",
+  "adcp_version": "3.1.20",
+  "generated_at": "2026-09-02T12:43:46.586Z",
   "universal": [
     "billing-gate-dispatch",
     "canonical-format-validate-input",

package/compliance/cache/{3.1.15.previous/domains → 3.1.20/protocols}/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."
@@ -587,6 +587,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
@@ -745,6 +748,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.

package/compliance/cache/{3.1.15 → 3.1.20}/protocols/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.15.previous/domains → 3.1.20/protocols}/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.15.previous → 3.1.20}/protocols/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