feat(compliance): add DOOH sales profile

.changeset/add-dooh-interoperability-contracts.md

@@ -0,0 +1,5 @@
+---
+"adcontextprotocol": minor
+---
+
+Add the `sales-dooh` specialism and a digital out-of-home, non-guaranteed compliance storyboard using the existing channel, product, placement, canonical-format, play, and DOOH-metric contracts. Exercise typed DOOH placement identifiers, loop/slot timing, screen resolution, and motion facts while keeping canonical `format_options` authoritative for creative acceptance. Extend deterministic delivery simulation to prove `plays` and `dooh_metrics`, document optional vendor-defined attention without making it part of the core DOOH claim, require every 3.2 product-list path to expose resolved canonical formats without a separate source-mode capability, set a 128 KiB MCP interoperability target with `tools/list` pagination guidance, prevent success-payload duplication across MCP text and `structuredContent`, and clarify that sandbox behavior is selected by the resolved account rather than switched on per media-buy request.

.changeset/dooh-placement-attributes.md

@@ -0,0 +1,5 @@
+---
+"adcontextprotocol": minor
+---
+
+Add DOOH structured selling-unit fields to placements: `dooh_placement_attributes` (slot_duration_seconds, loop_duration_seconds, screen_resolution, motion) and `identifiers[]` on both placement.json and placement-definition.json. Define deterministic publisher/product inheritance, post-merge slot-to-loop validation, versioned OpenOOH identifiers, and canonical-format authority. Add the `dooh-motion-type` enum and supersede pricing-layer loop_duration_seconds in flat-rate-option.json.

docs/building/by-layer/L0/mcp-response-extraction.mdx

@@ -86,6 +86,8 @@ MCP 2025-03-26 introduced `structuredContent` for typed tool results. AdCP serve
 
 The `structuredContent` object IS the AdCP response — task-specific fields (`products`, `media_buy_id`, `status`, etc.) are at the top level, not nested.
 
+When `structuredContent` carries the authoritative success payload, `content` MAY contain a terse human-readable summary. Producers SHOULD NOT serialize the complete AdCP payload again into `content[].text`; doing so doubles the wire bytes and model-context cost without adding information. A server supporting an older MCP client that cannot read `structuredContent` MAY instead put the JSON payload in text as the fallback form below and omit `structuredContent`. It should not emit both full copies.
+
 ### Text Fallback
 
 Older MCP servers (pre-2025-03-26) serialize the response as JSON in `content[].text`:
@@ -127,7 +129,7 @@ All data in `structuredContent` and `content[].text` is seller-controlled. The s
 
 ### Size Limits
 
-Clients SHOULD enforce a maximum payload size before processing. A recommended limit is 1MB for `structuredContent`. For text fallback, apply the limit before `JSON.parse` to prevent memory exhaustion from oversized payloads.
+For pageable reads and other read-only tasks that support field projection, producers SHOULD target at most 128 KiB per serialized MCP response; see [Managing response size](/docs/building/concepts/managing-response-size#interoperability-size-target). Clients SHOULD independently enforce a streamed limit on the complete serialized MCP message before buffering or JSON decoding. The recommended client safety limit is 1 MiB. For text fallback, also check the `content[].text` size before the inner `JSON.parse`. The larger safety limit is not a producer target: it bounds hostile or buggy input after normal interoperability guidance has failed.
 
 ### Prototype Pollution
 
@@ -145,6 +147,7 @@ Client libraries that implement this spec MUST:
 2. **Prefer `structuredContent`.** Only fall back to text parsing when `structuredContent` is absent.
 3. **Validate parsed text.** Only accept non-array objects from `JSON.parse`. Reject arrays, strings, numbers, booleans, and null.
 4. **Handle `adcp_error`-only `structuredContent`.** When `structuredContent` contains only an `adcp_error` key, return null — this is an error response that may be missing the `isError` flag.
+5. **Do not require duplicated success data.** Treat summary-only `content[].text` as normal whenever `structuredContent` is present; never compare it with, or expect it to reproduce, the structured payload.
 
 ## Test Vectors
 

docs/building/by-layer/L4/build-an-agent.mdx

@@ -99,7 +99,7 @@ Each agent declares its `supported_protocols` (domains) and `specialisms` on `ge
 
 | Skill | Typical `supported_protocols` | Typical `specialisms` (pick one or combine) |
 |---|---|---|
-| `build-seller-agent` | `["media_buy", "creative"]` | `sales-guaranteed`, `sales-non-guaranteed` |
+| `build-seller-agent` | `["media_buy", "creative"]` | `sales-guaranteed`, `sales-non-guaranteed`, `sales-dooh` |
 | `build-generative-seller-agent` | `["media_buy", "creative"]` | `creative-generative` + `sales-non-guaranteed` |
 | `build-retail-media-agent` | `["media_buy", "creative"]` | `sales-catalog-driven` |
 | `build-signals-agent` | `["signals"]` | `signal-owned`, `signal-marketplace` |
@@ -108,6 +108,7 @@ Each agent declares its `supported_protocols` (domains) and `specialisms` on `ge
 **Picking a sales specialism:** See [Choosing a sales specialism](/docs/building/verification/compliance-catalog#choosing-a-sales-specialism) in the Compliance Catalog for the full decision tree. Quick reference:
 - **`sales-guaranteed`** — IO approval, fixed pricing. Set `media_buy.supports_proposals: true` if you support RFP/proposal flows; `false` (or omit) for direct-buy only.
 - **`sales-non-guaranteed`** — auction / PMP.
+- **`sales-dooh`** — non-guaranteed digital out-of-home venue and screen inventory.
 - **`sales-broadcast-tv`**, **`sales-catalog-driven`**, **`sales-social`** — channel-specific; see the decision tree.
 
 You can claim more than one. See the [Compliance Catalog](/docs/building/verification/compliance-catalog) for the full taxonomy and per-specialism storyboards.

docs/building/concepts/managing-response-size.mdx

@@ -10,6 +10,16 @@ seller-planned proposals to a wholesale mirror containing detailed product,
 signal, and placement metadata. This page covers the controls that keep those
 responses right-sized—and the client-side projection that matters most.
 
+## Interoperability size target
+
+MCP hosts and gateways impose different undocumented response ceilings. For pageable reads and other read-only tasks that offer field projection, AdCP producers SHOULD keep each serialized MCP response at or below **128 KiB (131,072 bytes)**. This is an interoperability target, not permission for a client to allocate without bounds: clients SHOULD still enforce the streamed 1 MiB whole-message cap described in [MCP response extraction](/docs/building/by-layer/L0/mcp-response-extraction#size-limits).
+
+For those read paths, use the task's cursor, reduce the requested fields or breakdowns, or return a smaller schema-valid page with continuation metadata before the response exceeds 128 KiB. Do not invent a partial response for a task whose schema does not define one.
+
+Do not apply the 128 KiB target by turning a completed mutation into an error. If a producer can determine before execution that it cannot return the mutation's required result within a host limit, it MUST reject the request before side effects. Once side effects occur, it MUST return the schema-valid committed result or a task-defined asynchronous handoff; it must not report failure merely to satisfy the size target.
+
+`tools/list` is cursor-pageable at the MCP layer even though it is not an AdCP task. Servers SHOULD paginate the live tool catalog so each page remains under the same 128 KiB target. Clients that need the complete catalog MUST follow `nextCursor` until it is absent. Capability-selected tool registration and concise `x-tool-summary` descriptions reduce each page further; do not publish the full AdCP catalog, response schemas, or long reference prose in a session's `tools/list` result.
+
 ## Wire response ≠ model context
 
 The single most important point: **the bytes on the wire are not what your model has to consume.**