@adcp/sdk 9.6.0 → 9.6.2

package/compliance/cache/{3.1.0 → 3.1.1.previous}/domains/media-buy/scenarios/governance_denied_recovery.yaml

@@ -4,11 +4,23 @@ title: "Seller accepts corrected buy after governance denial"
 category: media_buy_seller
 summary: "Verifies that a buyer can recover from GOVERNANCE_DENIED by shrinking the buy to within plan limits and retrying."
 track: media_buy
+requires:
+  - multi_agent
+default_agent: sales
 required_tools:
   - sync_governance
   - get_products
   - create_media_buy
 
+# Capability gate: this scenario asserts the seller produces GOVERNANCE_DENIED
+# after consulting a registered governance agent, so it runs only for sellers
+# that declare media_buy.governance_aware: true. Sellers without outbound
+# governance consultation grade not_applicable rather than false-failing on a
+# denial they have no mechanism to produce.
+requires_capability:
+  path: media_buy.governance_aware
+  equals: true
+
 narrative: |
   GOVERNANCE_DENIED is a correctable error, not a dead end. The buyer must be able to
   read the denial findings, adjust the media buy, and retry. This scenario exercises the
@@ -19,6 +31,13 @@ narrative: |
   exactly which constraint was violated (budget authority, brand policy, etc.) and
   correct it.
 
+  This scenario requires a runner that can route calls to at least two logical
+  agents: `sales` for the seller under test and `governance` for the governance
+  plan setup. Single-agent runners should only include this storyboard when the
+  endpoint under test deliberately combines seller and governance behavior in
+  one tenant; otherwise it belongs in the governance-aware-seller multi-agent
+  suite.
+
   By default, the governance agent is the training agent at test-agent.adcontextprotocol.org.
   Override by supplying a different `governance_agent_url` in the run's initial context
   (e.g., via `--context` on `adcp storyboard run` once the CLI supports it).
@@ -40,7 +59,9 @@ caller:
 
 prerequisites:
   description: |
-    A governance agent that supports sync_plans and check_governance.
+    A multi-agent runner with `sales` and `governance` agents. The governance
+    agent supports sync_plans and check_governance; the sales agent supports
+    sync_governance and create_media_buy.
   test_kit: "test-kits/acme-outdoor.yaml"
 
 phases:
@@ -53,6 +74,7 @@ phases:
     steps:
       - id: sync_plans
         title: "Create strict governance plan"
+        agent: governance
         task: sync_plans
         schema_ref: "governance/sync-plans-request.json"
         response_schema_ref: "governance/sync-plans-response.json"
@@ -84,6 +106,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"
@@ -108,6 +131,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"
@@ -136,6 +160,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"
@@ -170,6 +195,7 @@ phases:
 
       - id: create_media_buy_denied
         title: "Attempt $50K buy — denied"
+        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"
@@ -217,6 +243,7 @@ phases:
     steps:
       - id: create_media_buy_retry
         title: "Retry with $8K — approved"
+        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"

package/compliance/cache/{3.1.0 → 3.1.1.previous}/domains/sponsored-intelligence/sponsored-context-accountability.yaml

@@ -60,10 +60,12 @@ prerequisites:
     not echoes of the agent's own prior emission. The assertions test receipt acceptance and
     rejection semantics, not principal-matching against the agent's own declaration.
 
-    The acme-outdoor test kit is a natural fixture — it matches the catalog the reference
-    implementation (bragent) ships and is already used by other SI scenarios. A conformant
-    brand agent that prefers a different identity may substitute its own kit; the assertions
-    below are configuration-independent.
+    The acme-outdoor test kit is the fixture this storyboard is scoped to — it matches the
+    catalog the reference implementation (bragent) ships and is already used by other SI
+    scenarios. The receipt literals above are fixed to the Acme identity
+    (`acmeoutdoor.example` / "Acme Outdoor"), so this is not configuration-independent: a
+    brand agent under a different identity would need the receipt literals updated to match,
+    or the receipt's principal no longer corresponds to the agent's own declaration.
   test_kit: "test-kits/acme-outdoor.yaml"
 
 phases:
@@ -149,10 +151,10 @@ phases:
       - id: si_send_message_presentation_accepted
         title: "si_send_message with a matching accepted receipt"
         narrative: |
-          The host echoes the brand's sponsored_context back inside a receipt whose
-          `accepted_context_use` matches the declared value. A conformant brand agent accepts
-          the receipt, persists it for audit, and emits a fresh sponsored_context on the
-          response.
+          The receipt is a fixed Acme literal whose `accepted_context_use` matches the value
+          declared in the prior turn — it is not an echo of the agent's own emission. A
+          conformant brand agent accepts the receipt, persists it for audit, and emits a
+          fresh sponsored_context on the response.
         task: si_send_message
         schema_ref: "sponsored-intelligence/si-send-message-request.json"
         response_schema_ref: "sponsored-intelligence/si-send-message-response.json"

package/compliance/cache/{3.1.0.previous → 3.1.1.previous}/index.json

@@ -1,7 +1,7 @@
 {
-  "published_version": "3.1.0",
-  "adcp_version": "3.1.0",
-  "generated_at": "2026-06-18T08:17:07.117Z",
+  "published_version": "3.1.1",
+  "adcp_version": "3.1.1",
+  "generated_at": "2026-06-30T19:14:45.365Z",
   "universal": [
     "billing-gate-dispatch",
     "canonical-format-validate-input",
@@ -14,6 +14,7 @@
     "error-compliance-signals",
     "fictional-entities",
     "get-media-buys-pagination-integrity",
+    "get-products-pagination-integrity",
     "get-signals-pagination-integrity",
     "idempotency",
     "notification-config-event-scope",

package/compliance/cache/{3.1.0.previous → 3.1.1.previous}/protocols/media-buy/index.yaml

@@ -64,29 +64,37 @@ prerequisites:
   test_kit: "test-kits/acme-outdoor.yaml"
   controller_seeding: true
 
+# The base media-buy lifecycle exercises the universal NON-GUARANTEED
+# (auction-based) path so that every media-buy seller can run it — including
+# sellers that declare only `specialisms: ["sales-non-guaranteed"]`. A
+# non-guaranteed-only seller correctly rejects a guaranteed buy with
+# DELIVERY_MODE_NOT_SUPPORTED, so guaranteed-only fixtures here failed the whole
+# base flow (create_buy + the dependent steps) for that entire seller class. The
+# guaranteed lifecycle (human IO approval, proposal_finalize) is covered by the
+# `sales-guaranteed` specialism bundle, which carries its own guaranteed fixtures.
 fixtures:
   products:
     - product_id: "sports_preroll_q2"
-      delivery_type: "guaranteed"
+      delivery_type: "non_guaranteed"
       channels: ["video"]
       format_ids:
         - id: "video_30s"
     - product_id: "lifestyle_display_q2"
-      delivery_type: "guaranteed"
+      delivery_type: "non_guaranteed"
       channels: ["display"]
       format_ids:
         - id: "display_300x250"
   pricing_options:
     - product_id: "sports_preroll_q2"
-      pricing_option_id: "cpm_guaranteed"
+      pricing_option_id: "cpm_non_guaranteed"
       pricing_model: "cpm"
       currency: "USD"
-      fixed_price: 22.0
+      floor_price: 22.0
     - product_id: "lifestyle_display_q2"
       pricing_option_id: "cpm_standard"
       pricing_model: "cpm"
       currency: "USD"
-      fixed_price: 8.0
+      floor_price: 8.0
 
 phases:
   - id: capability_discovery
@@ -485,7 +493,7 @@ phases:
           packages:
             - product_id: "sports_preroll_q2"
               budget: 25000
-              pricing_option_id: "cpm_guaranteed"
+              pricing_option_id: "cpm_non_guaranteed"
               creative_assignments:
                 - creative_id: "video_30s_trail_pro"
             - product_id: "lifestyle_display_q2"

package/compliance/cache/{3.1.0.previous/domains → 3.1.1.previous/protocols}/media-buy/scenarios/create_media_buy_async.yaml

@@ -125,6 +125,9 @@ phases:
 
         sample_request:
           account:
+            brand:
+              domain: "acmeoutdoor.example"
+            operator: "pinnacle-agency.example"
             sandbox: true
           scenario: "force_create_media_buy_arm"
           params:

package/compliance/cache/{3.1.0.previous → 3.1.1.previous}/protocols/media-buy/scenarios/dependency_impairment.yaml

@@ -9,9 +9,24 @@ required_tools:
   - create_media_buy
   - get_media_buys
   - sync_creatives
+  - list_creatives
   - 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).
+requires_capability:
+  path: media_buy.propagation_surfaces
+  contains: "snapshot"
+
 narrative: |
   Per the dependency-impairment surface ([adcp#2855](https://github.com/adcontextprotocol/adcp/issues/2855)
   and `core/impairment.json`), sellers MUST propagate resource-state transitions
@@ -417,6 +432,48 @@ phases:
       invariant grades the cross-resource match.
 
     steps:
+      - id: reread_creative_rejected
+        title: "Re-read the creative — runner observes rejected (closes impairment.coherence)"
+        narrative: |
+          The impairment.coherence invariant ledgers each resource's last status
+          OBSERVED ON THE WIRE (sync_creatives / list_creatives), not the
+          comply_test_controller force directive (the runner has no observation
+          hook for the forced transition). Without this re-read the creative's
+          last observed status stays its pre-rejection value (e.g. pending_review
+          from the sync step), so the next get_media_buys — which correctly
+          reports health: impaired — trips coherence because impairments[]
+          references a creative the ledger still considers online. This re-read
+          surfaces the rejected status so the ledger and the buy agree.
+        task: list_creatives
+        schema_ref: "creative/list-creatives-request.json"
+        response_schema_ref: "creative/list-creatives-response.json"
+        doc_ref: "/creative/task-reference/list_creatives"
+        comply_scenario: creative_library
+        stateful: true
+        expected: |
+          The rejected creative is returned with status: rejected.
+        sample_request:
+          account:
+            brand:
+              domain: "acmeoutdoor.example"
+            operator: "pinnacle-agency.example"
+          filters:
+            creative_ids:
+              - "acme_dep_banner_001"
+          context:
+            correlation_id: "dependency_impairment--reread_creative_rejected"
+        validations:
+          - check: response_schema
+            description: "Response matches list-creatives-response.json schema"
+          - check: field_value
+            path: "creatives[0].creative_id"
+            value: "acme_dep_banner_001"
+            description: "Filter returned the rejected creative specifically — the status assertion below is grounded on this creative, not another library entry"
+          - check: field_value
+            path: "creatives[0].status"
+            value: "rejected"
+            description: "Creative observed as rejected on the wire — closes the impairment.coherence ledger for the impaired read that follows"
+
       - id: get_buy_impaired
         title: "Read the buy — health: impaired, impairment entry present"
         task: get_media_buys

package/compliance/cache/{3.1.0.previous/domains → 3.1.1.previous/protocols}/media-buy/scenarios/dependency_impairment_cardinality.yaml

@@ -9,9 +9,24 @@ required_tools:
   - create_media_buy
   - get_media_buys
   - sync_creatives
+  - list_creatives
   - 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).
+requires_capability:
+  path: media_buy.propagation_surfaces
+  contains: "snapshot"
+
 narrative: |
   The base dependency_impairment scenario tests forward + inverse + health-iff
   with one creative on one package — a malicious or buggy seller can pass the
@@ -417,6 +432,48 @@ phases:
             allowed_values: [true]
             description: "Controller acknowledged the rejection directive"
 
+      - id: reread_a_rejected
+        title: "Re-read creative A — runner observes rejected"
+        narrative: |
+          The impairment.coherence invariant ledgers each resource's last status
+          OBSERVED ON THE WIRE (sync_creatives / list_creatives), not the
+          comply_test_controller force directive (the runner has no observation
+          hook for the forced transition). Without this re-read the creative's
+          last observed status stays its pre-rejection value (e.g. pending_review
+          from the sync step), so the next get_media_buys — which correctly
+          reports health: impaired — trips coherence because impairments[]
+          references a creative the ledger still considers online. This re-read
+          surfaces the rejected status so the ledger and the buy agree.
+        task: list_creatives
+        schema_ref: "creative/list-creatives-request.json"
+        response_schema_ref: "creative/list-creatives-response.json"
+        doc_ref: "/creative/task-reference/list_creatives"
+        comply_scenario: creative_library
+        stateful: true
+        expected: |
+          The rejected creative is returned with status: rejected.
+        sample_request:
+          account:
+            brand:
+              domain: "acmeoutdoor.example"
+            operator: "pinnacle-agency.example"
+          filters:
+            creative_ids:
+              - "acme_card_banner_a"
+          context:
+            correlation_id: "dependency_impairment_cardinality--reread_a_rejected"
+        validations:
+          - check: response_schema
+            description: "Response matches list-creatives-response.json schema"
+          - check: field_value
+            path: "creatives[0].creative_id"
+            value: "acme_card_banner_a"
+            description: "Filter returned creative A specifically — proves the rejected status below is A's, not creative B (also rejected by the cardinality-2 point)"
+          - check: field_value
+            path: "creatives[0].status"
+            value: "rejected"
+            description: "Creative observed as rejected on the wire — closes the impairment.coherence ledger for the impaired read that follows"
+
       - id: verify_cardinality_one
         title: "Read the buy — exactly one impairment, scoped to package_a"
         task: get_media_buys
@@ -504,6 +561,48 @@ phases:
             allowed_values: [true]
             description: "Controller acknowledged the rejection directive"
 
+      - id: reread_b_rejected
+        title: "Re-read creative B — runner observes rejected"
+        narrative: |
+          The impairment.coherence invariant ledgers each resource's last status
+          OBSERVED ON THE WIRE (sync_creatives / list_creatives), not the
+          comply_test_controller force directive (the runner has no observation
+          hook for the forced transition). Without this re-read the creative's
+          last observed status stays its pre-rejection value (e.g. pending_review
+          from the sync step), so the next get_media_buys — which correctly
+          reports health: impaired — trips coherence because impairments[]
+          references a creative the ledger still considers online. This re-read
+          surfaces the rejected status so the ledger and the buy agree.
+        task: list_creatives
+        schema_ref: "creative/list-creatives-request.json"
+        response_schema_ref: "creative/list-creatives-response.json"
+        doc_ref: "/creative/task-reference/list_creatives"
+        comply_scenario: creative_library
+        stateful: true
+        expected: |
+          The rejected creative is returned with status: rejected.
+        sample_request:
+          account:
+            brand:
+              domain: "acmeoutdoor.example"
+            operator: "pinnacle-agency.example"
+          filters:
+            creative_ids:
+              - "acme_card_banner_b"
+          context:
+            correlation_id: "dependency_impairment_cardinality--reread_b_rejected"
+        validations:
+          - check: response_schema
+            description: "Response matches list-creatives-response.json schema"
+          - check: field_value
+            path: "creatives[0].creative_id"
+            value: "acme_card_banner_b"
+            description: "Filter returned creative B specifically — proves the rejected status below is B's, not creative A (also rejected at this point)"
+          - check: field_value
+            path: "creatives[0].status"
+            value: "rejected"
+            description: "Creative observed as rejected on the wire — closes the impairment.coherence ledger for the impaired read that follows"
+
       - id: verify_cardinality_two
         title: "Read the buy — exactly two impairments, one per creative"
         task: get_media_buys

package/compliance/cache/{3.1.0/domains → 3.1.1.previous/protocols}/media-buy/scenarios/governance_denied.yaml

@@ -4,11 +4,23 @@ title: "Seller rejects buy when governance denies"
 category: media_buy_seller
 summary: "Verifies that the seller rejects a media buy and propagates the denial when governance denies the transaction."
 track: media_buy
+requires:
+  - multi_agent
+default_agent: sales
 required_tools:
   - sync_governance
   - get_products
   - create_media_buy
 
+# Capability gate: this scenario asserts the seller produces GOVERNANCE_DENIED
+# after consulting a registered governance agent, so it runs only for sellers
+# that declare media_buy.governance_aware: true. Sellers without outbound
+# governance consultation grade not_applicable rather than false-failing on a
+# denial they have no mechanism to produce.
+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 a strict $10K budget, then registers that agent with the seller. The buyer
@@ -18,6 +30,13 @@ narrative: |
   requested budget exceeds the plan total. The seller must reject the buy and propagate
   the denial back to the buyer.
 
+  This scenario requires a runner that can route calls to at least two logical
+  agents: `sales` for the seller under test and `governance` for the governance
+  plan setup. Single-agent runners should only include this storyboard when the
+  endpoint under test deliberately combines seller and governance behavior in
+  one tenant; otherwise it belongs in the governance-aware-seller multi-agent
+  suite.
+
   By default, the governance agent is the training agent at test-agent.adcontextprotocol.org.
   Override by supplying a different `governance_agent_url` in the run's initial context
   (e.g., via `--context` on `adcp storyboard run` once the CLI supports it).
@@ -39,7 +58,9 @@ caller:
 
 prerequisites:
   description: |
-    A governance agent that supports sync_plans and check_governance.
+    A multi-agent runner with `sales` and `governance` agents. The governance
+    agent supports sync_plans and check_governance; the sales agent supports
+    sync_governance and create_media_buy.
   test_kit: "test-kits/acme-outdoor.yaml"
 
 phases:
@@ -53,6 +74,7 @@ phases:
     steps:
       - id: sync_plans
         title: "Create strict governance plan"
+        agent: governance
         task: sync_plans
         schema_ref: "governance/sync-plans-request.json"
         response_schema_ref: "governance/sync-plans-response.json"
@@ -84,6 +106,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"
@@ -108,6 +131,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"
@@ -136,6 +160,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"
@@ -169,6 +194,7 @@ phases:
 
       - id: create_media_buy_denied
         title: "Create buy (governance denies — should fail)"
+        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"

package/compliance/cache/{3.1.0.previous → 3.1.1.previous}/protocols/media-buy/scenarios/governance_denied_recovery.yaml

@@ -4,11 +4,23 @@ title: "Seller accepts corrected buy after governance denial"
 category: media_buy_seller
 summary: "Verifies that a buyer can recover from GOVERNANCE_DENIED by shrinking the buy to within plan limits and retrying."
 track: media_buy
+requires:
+  - multi_agent
+default_agent: sales
 required_tools:
   - sync_governance
   - get_products
   - create_media_buy
 
+# Capability gate: this scenario asserts the seller produces GOVERNANCE_DENIED
+# after consulting a registered governance agent, so it runs only for sellers
+# that declare media_buy.governance_aware: true. Sellers without outbound
+# governance consultation grade not_applicable rather than false-failing on a
+# denial they have no mechanism to produce.
+requires_capability:
+  path: media_buy.governance_aware
+  equals: true
+
 narrative: |
   GOVERNANCE_DENIED is a correctable error, not a dead end. The buyer must be able to
   read the denial findings, adjust the media buy, and retry. This scenario exercises the
@@ -19,6 +31,13 @@ narrative: |
   exactly which constraint was violated (budget authority, brand policy, etc.) and
   correct it.
 
+  This scenario requires a runner that can route calls to at least two logical
+  agents: `sales` for the seller under test and `governance` for the governance
+  plan setup. Single-agent runners should only include this storyboard when the
+  endpoint under test deliberately combines seller and governance behavior in
+  one tenant; otherwise it belongs in the governance-aware-seller multi-agent
+  suite.
+
   By default, the governance agent is the training agent at test-agent.adcontextprotocol.org.
   Override by supplying a different `governance_agent_url` in the run's initial context
   (e.g., via `--context` on `adcp storyboard run` once the CLI supports it).
@@ -40,7 +59,9 @@ caller:
 
 prerequisites:
   description: |
-    A governance agent that supports sync_plans and check_governance.
+    A multi-agent runner with `sales` and `governance` agents. The governance
+    agent supports sync_plans and check_governance; the sales agent supports
+    sync_governance and create_media_buy.
   test_kit: "test-kits/acme-outdoor.yaml"
 
 phases:
@@ -53,6 +74,7 @@ phases:
     steps:
       - id: sync_plans
         title: "Create strict governance plan"
+        agent: governance
         task: sync_plans
         schema_ref: "governance/sync-plans-request.json"
         response_schema_ref: "governance/sync-plans-response.json"
@@ -84,6 +106,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"
@@ -108,6 +131,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"
@@ -136,6 +160,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"
@@ -170,6 +195,7 @@ phases:
 
       - id: create_media_buy_denied
         title: "Attempt $50K buy — denied"
+        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"
@@ -217,6 +243,7 @@ phases:
     steps:
       - id: create_media_buy_retry
         title: "Retry with $8K — approved"
+        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"

package/compliance/cache/{3.1.0 → 3.1.1.previous}/protocols/sponsored-intelligence/sponsored-context-accountability.yaml

@@ -60,10 +60,12 @@ prerequisites:
     not echoes of the agent's own prior emission. The assertions test receipt acceptance and
     rejection semantics, not principal-matching against the agent's own declaration.
 
-    The acme-outdoor test kit is a natural fixture — it matches the catalog the reference
-    implementation (bragent) ships and is already used by other SI scenarios. A conformant
-    brand agent that prefers a different identity may substitute its own kit; the assertions
-    below are configuration-independent.
+    The acme-outdoor test kit is the fixture this storyboard is scoped to — it matches the
+    catalog the reference implementation (bragent) ships and is already used by other SI
+    scenarios. The receipt literals above are fixed to the Acme identity
+    (`acmeoutdoor.example` / "Acme Outdoor"), so this is not configuration-independent: a
+    brand agent under a different identity would need the receipt literals updated to match,
+    or the receipt's principal no longer corresponds to the agent's own declaration.
   test_kit: "test-kits/acme-outdoor.yaml"
 
 phases:
@@ -149,10 +151,10 @@ phases:
       - id: si_send_message_presentation_accepted
         title: "si_send_message with a matching accepted receipt"
         narrative: |
-          The host echoes the brand's sponsored_context back inside a receipt whose
-          `accepted_context_use` matches the declared value. A conformant brand agent accepts
-          the receipt, persists it for audit, and emits a fresh sponsored_context on the
-          response.
+          The receipt is a fixed Acme literal whose `accepted_context_use` matches the value
+          declared in the prior turn — it is not an echo of the agent's own emission. A
+          conformant brand agent accepts the receipt, persists it for audit, and emits a
+          fresh sponsored_context on the response.
         task: si_send_message
         schema_ref: "sponsored-intelligence/si-send-message-request.json"
         response_schema_ref: "sponsored-intelligence/si-send-message-response.json"

package/compliance/cache/{3.1.0 → 3.1.1.previous}/specialisms/sales-broadcast-tv/index.yaml

@@ -75,12 +75,12 @@ fixtures:
   products:
     - product_id: "primetime_30s_mf"
       delivery_type: "guaranteed"
-      channels: ["video"]
+      channels: ["linear_tv"]
       format_ids:
         - id: "broadcast_spot_30s"
     - product_id: "late_fringe_15s_mf"
       delivery_type: "guaranteed"
-      channels: ["video"]
+      channels: ["linear_tv"]
       format_ids:
         - id: "broadcast_spot_15s"
   pricing_options: