@adcp/sdk 13.0.0-rc.0 → 13.0.0-rc.2

package/dist/lib/schemas-data/3.1/protocol/list-tasks-request.json

@@ -1,17 +1,17 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.5/protocol/list-tasks-request.json",
+  "$id": "/schemas/3.1.8/protocol/list-tasks-request.json",
   "title": "List Tasks Request",
   "description": "Request parameters for the list_tasks AdCP tool. This is a 3.x protocol-namespace alias for the legacy AdCP tasks/list reconciliation surface, not a transport-native MCP/A2A tasks/* method. It lists and filters AdCP application-layer async tasks for state reconciliation while preserving the legacy 3.x payload shape.",
   "type": "object",
   "allOf": [
     {
-      "$ref": "/schemas/3.1.5/core/version-envelope.json"
+      "$ref": "/schemas/3.1.8/core/version-envelope.json"
     }
   ],
   "properties": {
     "account": {
-      "$ref": "/schemas/3.1.5/core/account-ref.json",
+      "$ref": "/schemas/3.1.8/core/account-ref.json",
       "description": "Account scope for task reconciliation. Sellers MUST only return tasks created for the caller's authenticated account + principal pair. When omitted, the seller MAY use the credential-bound singleton account, but multi-account credentials SHOULD require an explicit account."
     },
     "filters": {
@@ -19,38 +19,38 @@
       "description": "Filter criteria for querying tasks",
       "properties": {
         "protocol": {
-          "$ref": "/schemas/3.1.5/enums/adcp-protocol.json",
+          "$ref": "/schemas/3.1.8/enums/adcp-protocol.json",
           "description": "Filter by single AdCP protocol"
         },
         "protocols": {
           "type": "array",
           "description": "Filter by multiple AdCP protocols",
           "items": {
-            "$ref": "/schemas/3.1.5/enums/adcp-protocol.json"
+            "$ref": "/schemas/3.1.8/enums/adcp-protocol.json"
           },
           "minItems": 1
         },
         "status": {
-          "$ref": "/schemas/3.1.5/enums/task-status.json",
+          "$ref": "/schemas/3.1.8/enums/task-status.json",
           "description": "Filter by single task status"
         },
         "statuses": {
           "type": "array",
           "description": "Filter by multiple task statuses",
           "items": {
-            "$ref": "/schemas/3.1.5/enums/task-status.json"
+            "$ref": "/schemas/3.1.8/enums/task-status.json"
           },
           "minItems": 1
         },
         "task_type": {
-          "$ref": "/schemas/3.1.5/enums/task-type.json",
+          "$ref": "/schemas/3.1.8/enums/task-type.json",
           "description": "Filter by single task type"
         },
         "task_types": {
           "type": "array",
           "description": "Filter by multiple task types",
           "items": {
-            "$ref": "/schemas/3.1.5/enums/task-type.json"
+            "$ref": "/schemas/3.1.8/enums/task-type.json"
           },
           "minItems": 1
         },
@@ -111,7 +111,7 @@
           "description": "Field to sort by"
         },
         "direction": {
-          "$ref": "/schemas/3.1.5/enums/sort-direction.json",
+          "$ref": "/schemas/3.1.8/enums/sort-direction.json",
           "default": "desc",
           "description": "Sort direction"
         }
@@ -119,7 +119,7 @@
       "additionalProperties": true
     },
     "pagination": {
-      "$ref": "/schemas/3.1.5/core/pagination-request.json"
+      "$ref": "/schemas/3.1.8/core/pagination-request.json"
     },
     "include_history": {
       "type": "boolean",
@@ -127,10 +127,10 @@
       "description": "Include full conversation history for each task (may significantly increase response size)"
     },
     "context": {
-      "$ref": "/schemas/3.1.5/core/context.json"
+      "$ref": "/schemas/3.1.8/core/context.json"
     },
     "ext": {
-      "$ref": "/schemas/3.1.5/core/ext.json"
+      "$ref": "/schemas/3.1.8/core/ext.json"
     }
   },
   "additionalProperties": true,

package/dist/lib/schemas-data/3.1/protocol/list-tasks-response.json

@@ -1,15 +1,15 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.5/protocol/list-tasks-response.json",
+  "$id": "/schemas/3.1.8/protocol/list-tasks-response.json",
   "title": "List Tasks Response",
   "description": "Response from the list_tasks AdCP tool, a 3.x protocol-namespace alias for legacy AdCP tasks/list. Contains filtered AdCP application-layer task results and reconciliation data while preserving the legacy 3.x domain field shape; distinct from transport-native MCP/A2A task responses.",
   "type": "object",
   "allOf": [
     {
-      "$ref": "/schemas/3.1.5/core/version-envelope.json"
+      "$ref": "/schemas/3.1.8/core/version-envelope.json"
     },
     {
-      "$ref": "/schemas/3.1.5/core/protocol-envelope.json"
+      "$ref": "/schemas/3.1.8/core/protocol-envelope.json"
     }
   ],
   "properties": {
@@ -101,7 +101,7 @@
             "x-entity": "task"
           },
           "task_type": {
-            "$ref": "/schemas/3.1.5/enums/task-type.json",
+            "$ref": "/schemas/3.1.8/enums/task-type.json",
             "description": "Type of AdCP operation"
           },
           "domain": {
@@ -114,7 +114,7 @@
             ]
           },
           "status": {
-            "$ref": "/schemas/3.1.5/enums/task-status.json",
+            "$ref": "/schemas/3.1.8/enums/task-status.json",
             "description": "Current task status"
           },
           "created_at": {
@@ -149,13 +149,13 @@
       }
     },
     "pagination": {
-      "$ref": "/schemas/3.1.5/core/pagination-response.json"
+      "$ref": "/schemas/3.1.8/core/pagination-response.json"
     },
     "context": {
-      "$ref": "/schemas/3.1.5/core/context.json"
+      "$ref": "/schemas/3.1.8/core/context.json"
     },
     "ext": {
-      "$ref": "/schemas/3.1.5/core/ext.json"
+      "$ref": "/schemas/3.1.8/core/ext.json"
     }
   },
   "required": [

package/dist/lib/schemas-data/3.1/registries/v1-canonical-mapping.json

@@ -1,10 +1,10 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.5/registries/v1-canonical-mapping.json",
+  "$id": "/schemas/3.1.8/registries/v1-canonical-mapping.json",
   "title": "v1 → v2 Canonical Format Mapping Registry",
-  "description": "Authoritative AAO-published mapping from v1 named formats to v2 canonical declarations. Used by SDKs to project the v1 wire shape into v2 canonical declarations during the migration window.\n\n**Direction of truth (normative).** This registry is authoritative for **v1 → v2 projection only**. v2 → v1 projection MUST rely on `v1_format_ref` on the v2 `ProductFormatDeclaration` — sellers assert the v1 pairing explicitly. SDKs MUST NOT synthesize a v1 `format_id` from the registry by inverting structural matches: the registry's `id` slugs lack the `agent_url` half of a `FormatId`, and registry entries with `format_id_glob: '*'` or pure-structural matches have no single literal to invert to. SDKs that synthesize unilaterally produce inter-SDK divergence on structurally-equal values (different SDKs pick different `agent_url` and `id` patterns for the same v2 declaration). When a v2 declaration carries no `v1_format_ref` and a v1-only buyer queries the product, the SDK reports the canonical as v1-unreachable via `FORMAT_DECLARATION_V1_AMBIGUOUS` and lets the buyer surface it to the seller; the seller's path is to add `v1_format_ref` to disambiguate.\n\nBest-effort inversion is not available from this registry: as of 3.1 all published entries are pure-structural (family-level), and structural matches are not invertible to a specific v1 `format_id`. Future versions MAY add literal `format_id_glob` entries for platform-specific v1 conventions; in that case SDKs MAY do best-effort inversion for non-wildcarded literals only, AND only when the seller hasn't authored a contradicting `v1_format_ref` — even then, the projection is non-normative and downstream consumers MUST NOT depend on it.\n\n**Resolution order** (per RFC #3305 amendment #3767, normative):\n1. **Authoritative v2→v1 link**: if any v2 `ProductFormatDeclaration` on the same product carries `v1_format_ref` pointing at this v1 format_id, use that v2 declaration. Highest priority — seller asserts the link directly. SDKs SHOULD run the *narrows* check (canonical-formats.mdx 'Narrows — formal definition') between the v2 declaration's `params` and the referenced v1 format's `requirements`; on conflict, surface `FORMAT_DECLARATION_DIVERGENT` on the `get_products` response `errors[]`. Without the narrowing check, `v1_format_ref` is a hint rather than a contract.\n2. **Seller-asserted on the v1 file**: if the v1 format declaration carries an explicit `canonical` field, use it. (Note: `canonical_parameters` on the v1 file is deprecated for 3.1; SDKs reading 3.1 catalogs MUST still honor it when present, but `v1_format_ref` is the path forward.)\n3. **Registry glob**: look up `format_id` in this registry's `format_id_glob` entries.\n4. **Structural match**: attempt structural match against this registry's `structural` entries. A successful structural match yields a *family-level* identification only (e.g., 'this is a `video_vast`') — it does NOT yield a specific v1 `format_id`. SDKs use structural match for v1 → v2 projection (the inbound direction) but MUST NOT invert it to a v1 `format_id` on the outbound path.\n5. **Ambiguous family**: if step 4 succeeded but the matched entries are family-only (pure structural, no invertible literal), the canonical is **v1-unreachable for THIS specific product** unless the seller authors `v1_format_ref`. SDKs MUST surface `FORMAT_DECLARATION_V1_AMBIGUOUS` via `errors[]` augmentation rather than synthesize a plausible-but-arbitrary v1 `format_id`. Distinct from canonical-level v1-unreachability (a canonical with `v1_translatable: false` — `agent_placement`, `sponsored_placement`, `responsive_creative`, `image_carousel` — never has any v1 form regardless of registry coverage).\n6. **Fail closed**: SDK MUST NOT emit `format_options` for products carrying this format. SDKs MUST augment the response's `errors[]` array with an entry carrying `source: \"sdk\"`, `sdk_id: \"<package>@<version>\"`, `code: \"FORMAT_PROJECTION_FAILED\"`, `field: \"products[N].format_ids[K]\"`, and `error.details: { format_id, product_id, resolution_failure: \"no_explicit_canonical\" | \"no_registry_match\" | \"no_structural_match\" }`. Single mandated surface (`errors[]` augmentation) — lint-output channels are NOT acceptable; the multi-hop agent network needs warnings to propagate across SDK boundaries via the wire response. Logger-only warnings die in DEBUG. The advisory is non-fatal: the response stays 200/success, the product is still valid on the v1 path, only the v2 `format_options` projection is absent. Consumer-side counterpart to the producer SHOULD (sellers should add a v2 declaration with `v1_format_ref`, an explicit `canonical` field, or file a registry PR).\n\n**Match modes:**\n- `format_id_glob` — exact / glob match against the v1 `format_id.id`. **As of 3.1 the registry carries zero literal entries**: AAO-catalog-published formats (display_300x250_image, video_vast_30s, audio_standard_30s, etc.) project via resolution-order step 2 (catalog entry's `canonical:` annotation), and platform-specific formats (e.g., Meta Reels, TikTok Spark Ads) project via structural fallback or via the platform's own adagents.json `formats[]` block (#4620). A future literal entry is only justified when (a) the v1 name carries semantic narrowing not recoverable from slot shape AND (b) no platform-published adagents.json exists; such entries land via the AAO governance PR process with a documented rationale. The whole point of canonical-formats is parametrization: ONE `image` canonical with width/height params, not 8 per-size variants. Glob syntax: `*` matches any segment.\n- `structural` — match against the format's slot shape, asset types, and version constraints. The PRIMARY fallback for v1 wire traffic — catches custom v1 formats (a publisher's `acme_homepage_300x250` is structurally an IAB MREC) without enumerating every possible v1 name. v1 sellers in the wild naming things their own way are handled here, not by literal globs.\n\n**Alias collision precedence (normative).** When a v1 format's `assets[i]` carries multiple `asset_group_id` aliases that resolve to the same canonical asset_group (e.g., two slots both aliasing to `landing_page_url`), the SDK MUST resolve deterministically: the v1 format's `assets[*]` array order is authoritative — the first slot in declaration order wins, subsequent collisions are dropped from the projected v2 manifest and surfaced via `FORMAT_PROJECTION_FAILED` with `error.details: { collision_kind: \"asset_group_id_alias\", asset_group_id, winning_slot_id, dropped_slot_ids }`. SDKs MUST NOT silently pick one and discard the other without surfacing — silent picking creates inter-SDK divergence. Producers SHOULD avoid the collision by deduplicating aliased slots or using distinct `asset_group_id` values when both slots are semantically meaningful.\n\n**Governance**: same vocabulary-governance rules as `asset-group-vocabulary.json` and `format-shape-vocabulary.json` — additions land via PR with rationale + ≥1 reference adopter; AAO maintainer review; versioned + content-digested. Entries are additive; once published they are not removed (they may be marked `deprecated: true` if superseded).\n\n**Initial scope (3.1)**: 7 pure-structural fallback entries covering VAST 4.x / legacy VAST, DAAST 1.x, HTML5 zip bundles, hosted video, hosted audio, and url-shaped display tags. Per-size and per-duration literals (display_300x250_image, video_vast_30s, etc.) are NOT enumerated here — those project via catalog `canonical:` annotation (resolution-order step 2), keeping the registry aligned with the canonical-formats parametrization principle. Platform-specific formats (Meta Reels, TikTok Spark Ads, etc.) project via structural fallback or via the platform's own adagents.json `formats[]` block (#4620). The full v1-format audit dataset (~76% of formats from the 12-platform / 86-format audit in #3305) seeds the long-term roadmap and informs future literal-entry decisions.\n\nDigest the file content (sha256) when emitting in capabilities responses or referencing from SDK output. Buyers cache by `version` + `digest`.",
-  "version": "1.0.0",
-  "last_updated": "2026-05-01",
+  "description": "Authoritative AAO-published mapping from v1 named formats to v2 canonical declarations. Used by SDKs to project the v1 wire shape into v2 canonical declarations during the migration window.\n\n**Direction of truth (normative).** This registry is authoritative for **v1 → v2 projection only**. v2 → v1 projection MUST rely on `v1_format_ref` on the v2 `ProductFormatDeclaration` — sellers assert the v1 pairing explicitly. SDKs MUST NOT synthesize a v1 `format_id` from the registry by inverting structural matches: the registry's `id` slugs lack the `agent_url` half of a `FormatId`, and registry entries with `format_id_glob: '*'` or pure-structural matches have no single literal to invert to. SDKs that synthesize unilaterally produce inter-SDK divergence on structurally-equal values (different SDKs pick different `agent_url` and `id` patterns for the same v2 declaration). When a v2 declaration carries no `v1_format_ref` and a v1-only buyer queries the product, the SDK reports the canonical as v1-unreachable via `FORMAT_DECLARATION_V1_AMBIGUOUS` and lets the buyer surface it to the seller; the seller's path is to add `v1_format_ref` to disambiguate.\n\nBest-effort inversion is available only from this registry's non-wildcarded literal format_id_glob entries. Structural matches remain family-level and are not invertible to a specific v1 format_id. SDKs MAY do best-effort inversion for non-wildcarded literals only, AND only when the seller hasn't authored a contradicting `v1_format_ref` — even then, the projection is non-normative and downstream consumers MUST NOT depend on it.\n\n**Resolution order** (per RFC #3305 amendment #3767, normative):\n1. **Authoritative v2→v1 link**: if any v2 `ProductFormatDeclaration` on the same product carries `v1_format_ref` pointing at this v1 format_id, use that v2 declaration. Highest priority — seller asserts the link directly. SDKs SHOULD run the *narrows* check (canonical-formats.mdx 'Narrows — formal definition') between the v2 declaration's `params` and the referenced v1 format's `requirements`; on conflict, surface `FORMAT_DECLARATION_DIVERGENT` on the `get_products` response `errors[]`. Without the narrowing check, `v1_format_ref` is a hint rather than a contract.\n2. **Seller-asserted on the v1 file**: if the v1 format declaration carries an explicit `canonical` field, use it. (Note: `canonical_parameters` on the v1 file is deprecated for 3.1; SDKs reading 3.1 catalogs MUST still honor it when present, but `v1_format_ref` is the path forward.)\n3. **Registry glob**: look up `format_id` in this registry's `format_id_glob` entries.\n4. **Structural match**: attempt structural match against this registry's `structural` entries. A successful structural match yields a *family-level* identification only (e.g., 'this is a `video_vast`') — it does NOT yield a specific v1 `format_id`. SDKs use structural match for v1 → v2 projection (the inbound direction) but MUST NOT invert it to a v1 `format_id` on the outbound path.\n5. **Ambiguous family**: if step 4 succeeded but the matched entries are family-only (pure structural, no invertible literal), the canonical is **v1-unreachable for THIS specific product** unless the seller authors `v1_format_ref`. SDKs MUST surface `FORMAT_DECLARATION_V1_AMBIGUOUS` via `errors[]` augmentation rather than synthesize a plausible-but-arbitrary v1 `format_id`. Distinct from canonical-level v1-unreachability (a canonical with `v1_translatable: false` — `agent_placement`, `sponsored_placement`, `responsive_creative`, `image_carousel` — never has any v1 form regardless of registry coverage).\n6. **Fail closed**: SDK MUST NOT emit `format_options` for products carrying this format. SDKs MUST augment the response's `errors[]` array with an entry carrying `source: \"sdk\"`, `sdk_id: \"<package>@<version>\"`, `code: \"FORMAT_PROJECTION_FAILED\"`, `field: \"products[N].format_ids[K]\"`, and `error.details: { format_id, product_id, resolution_failure: \"no_explicit_canonical\" | \"no_registry_match\" | \"no_structural_match\" }`. Single mandated surface (`errors[]` augmentation) — lint-output channels are NOT acceptable; the multi-hop agent network needs warnings to propagate across SDK boundaries via the wire response. Logger-only warnings die in DEBUG. The advisory is non-fatal: the response stays 200/success, the product is still valid on the v1 path, only the v2 `format_options` projection is absent. Consumer-side counterpart to the producer SHOULD (sellers should add a v2 declaration with `v1_format_ref`, an explicit `canonical` field, or file a registry PR).\n\n**Match modes:**\n- `format_id_glob` — exact / glob match against the v1 `format_id.id`. Published non-wildcarded literals cover independently observed legacy conventions whose names carry semantic narrowing (duration, dimensions, or VAST delivery) that slot shape alone cannot recover. Each literal mapping preserves those constraints in canonical parameters; AAO-catalog-published formats with explicit canonical annotations still project via resolution-order step 2. Glob syntax: `*` matches any segment.\n- `structural` — match against the format's slot shape, asset types, and version constraints. The PRIMARY fallback for v1 wire traffic — catches custom v1 formats (a publisher's `acme_homepage_300x250` is structurally an IAB MREC) without enumerating every possible v1 name. v1 sellers in the wild naming things their own way are handled here, not by literal globs.\n\n**Alias collision precedence (normative).** When a v1 format's `assets[i]` carries multiple `asset_group_id` aliases that resolve to the same canonical asset_group (e.g., two slots both aliasing to `landing_page_url`), the SDK MUST resolve deterministically: the v1 format's `assets[*]` array order is authoritative — the first slot in declaration order wins, subsequent collisions are dropped from the projected v2 manifest and surfaced via `FORMAT_PROJECTION_FAILED` with `error.details: { collision_kind: \"asset_group_id_alias\", asset_group_id, winning_slot_id, dropped_slot_ids }`. SDKs MUST NOT silently pick one and discard the other without surfacing — silent picking creates inter-SDK divergence. Producers SHOULD avoid the collision by deduplicating aliased slots or using distinct `asset_group_id` values when both slots are semantically meaningful.\n\n**Governance**: same vocabulary-governance rules as `asset-group-vocabulary.json` and `format-shape-vocabulary.json` — additions land via PR with rationale + ≥1 reference adopter; AAO maintainer review; versioned + content-digested. Entries are additive; once published they are not removed (they may be marked `deprecated: true` if superseded).\n\n**Scope**: 7 structural fallback entries cover VAST 4.x / legacy VAST, DAAST 1.x, HTML5 zip bundles, hosted video, hosted audio, and url-shaped display tags. Literal entries cover independently observed legacy duration-, dimension-, and VAST-token naming conventions. Durationless placement ids video_pre_roll and video_mid_roll are deliberately omitted: projecting either to video_hosted without duration_ms_exact would resolve to an untraffickable format and defer failure until ad-server line-item creation. Failing closed during discovery is safer. Platform-specific formats (Meta Reels, TikTok Spark Ads, etc.) project via structural fallback or via the platform's own adagents.json `formats[]` block (#4620). The full v1-format audit dataset (~76% of formats from the 12-platform / 86-format audit in #3305) seeds the long-term roadmap and informs future literal-entry decisions.\n\nDigest the file content (sha256) when emitting in capabilities responses or referencing from SDK output. Buyers cache by `version` + `digest`.",
+  "version": "1.2.0",
+  "last_updated": "2026-07-28",
   "type": "object",
   "required": [
     "version",
@@ -99,7 +99,7 @@
             ],
             "properties": {
               "canonical": {
-                "$ref": "/schemas/3.1.5/core/canonical-format-kind.json",
+                "$ref": "/schemas/3.1.8/core/canonical-format-kind.json",
                 "description": "v2 canonical format the v1 pattern projects to."
               },
               "parameters": {
@@ -123,6 +123,283 @@
     }
   },
   "mappings": [
+    {
+      "v1_pattern": {
+        "format_id_glob": "display_static"
+      },
+      "v2": {
+        "canonical": "image"
+      },
+      "notes": "Observed AAO-namespace static display id. The absent size constraint is intentional: the id carries no dimensions, so execution narrows size from the matched creative's intrinsic dimensions."
+    },
+    {
+      "v1_pattern": {
+        "format_id_glob": "display_300x250"
+      },
+      "v2": {
+        "canonical": "image",
+        "parameters": {
+          "width": 300,
+          "height": 250
+        }
+      },
+      "notes": "Observed AAO-namespace unsuffixed display size id. Exact pixel dimensions are retained in the projected parameters."
+    },
+    {
+      "v1_pattern": {
+        "format_id_glob": "display_728x90"
+      },
+      "v2": {
+        "canonical": "image",
+        "parameters": {
+          "width": 728,
+          "height": 90
+        }
+      },
+      "notes": "Observed AAO-namespace unsuffixed display size id. Exact pixel dimensions are retained in the projected parameters."
+    },
+    {
+      "v1_pattern": {
+        "format_id_glob": "display_320x50"
+      },
+      "v2": {
+        "canonical": "image",
+        "parameters": {
+          "width": 320,
+          "height": 50
+        }
+      },
+      "notes": "Observed AAO-namespace unsuffixed display size id. Exact pixel dimensions are retained in the projected parameters."
+    },
+    {
+      "v1_pattern": {
+        "format_id_glob": "display_300x600"
+      },
+      "v2": {
+        "canonical": "image",
+        "parameters": {
+          "width": 300,
+          "height": 600
+        }
+      },
+      "notes": "Observed AAO-namespace unsuffixed display size id. Exact pixel dimensions are retained in the projected parameters."
+    },
+    {
+      "v1_pattern": {
+        "format_id_glob": "display_970x250"
+      },
+      "v2": {
+        "canonical": "image",
+        "parameters": {
+          "width": 970,
+          "height": 250
+        }
+      },
+      "notes": "Observed AAO-namespace unsuffixed display size id. Exact pixel dimensions are retained in the projected parameters."
+    },
+    {
+      "v1_pattern": {
+        "format_id_glob": "display_250x250"
+      },
+      "v2": {
+        "canonical": "image",
+        "parameters": {
+          "width": 250,
+          "height": 250
+        }
+      },
+      "notes": "Observed AAO-namespace unsuffixed display size id. Exact pixel dimensions are retained in the projected parameters."
+    },
+    {
+      "v1_pattern": {
+        "format_id_glob": "display_200x200"
+      },
+      "v2": {
+        "canonical": "image",
+        "parameters": {
+          "width": 200,
+          "height": 200
+        }
+      },
+      "notes": "Observed AAO-namespace unsuffixed display size id. Exact pixel dimensions are retained in the projected parameters."
+    },
+    {
+      "v1_pattern": {
+        "format_id_glob": "display_300x50"
+      },
+      "v2": {
+        "canonical": "image",
+        "parameters": {
+          "width": 300,
+          "height": 50
+        }
+      },
+      "notes": "Observed AAO-namespace unsuffixed display size id. Exact pixel dimensions are retained in the projected parameters."
+    },
+    {
+      "v1_pattern": {
+        "format_id_glob": "display_320x480"
+      },
+      "v2": {
+        "canonical": "image",
+        "parameters": {
+          "width": 320,
+          "height": 480
+        }
+      },
+      "notes": "Observed AAO-namespace unsuffixed display size id. Exact pixel dimensions are retained in the projected parameters."
+    },
+    {
+      "v1_pattern": {
+        "format_id_glob": "display_320x400"
+      },
+      "v2": {
+        "canonical": "image",
+        "parameters": {
+          "width": 320,
+          "height": 400
+        }
+      },
+      "notes": "Observed AAO-namespace unsuffixed display size id. Exact pixel dimensions are retained in the projected parameters."
+    },
+    {
+      "v1_pattern": {
+        "format_id_glob": "display_320x320"
+      },
+      "v2": {
+        "canonical": "image",
+        "parameters": {
+          "width": 320,
+          "height": 320
+        }
+      },
+      "notes": "Observed AAO-namespace unsuffixed display size id. Exact pixel dimensions are retained in the projected parameters."
+    },
+    {
+      "v1_pattern": {
+        "format_id_glob": "display_320x250"
+      },
+      "v2": {
+        "canonical": "image",
+        "parameters": {
+          "width": 320,
+          "height": 250
+        }
+      },
+      "notes": "Observed AAO-namespace unsuffixed display size id. Exact pixel dimensions are retained in the projected parameters."
+    },
+    {
+      "v1_pattern": {
+        "format_id_glob": "video_30s"
+      },
+      "v2": {
+        "canonical": "video_hosted",
+        "parameters": {
+          "duration_ms_exact": 30000
+        }
+      },
+      "notes": "Observed legacy duration suffix. Duration is retained so the projected format remains traffickable."
+    },
+    {
+      "v1_pattern": {
+        "format_id_glob": "video_15s"
+      },
+      "v2": {
+        "canonical": "video_hosted",
+        "parameters": {
+          "duration_ms_exact": 15000
+        }
+      },
+      "notes": "Observed legacy duration suffix. Duration is retained so the projected format remains traffickable."
+    },
+    {
+      "v1_pattern": {
+        "format_id_glob": "video_pre_roll_30s"
+      },
+      "v2": {
+        "canonical": "video_hosted",
+        "parameters": {
+          "duration_ms_exact": 30000
+        }
+      },
+      "notes": "Observed legacy placement and duration suffix. Placement does not change the canonical; duration is retained."
+    },
+    {
+      "v1_pattern": {
+        "format_id_glob": "video_pre_roll_15s"
+      },
+      "v2": {
+        "canonical": "video_hosted",
+        "parameters": {
+          "duration_ms_exact": 15000
+        }
+      },
+      "notes": "Observed legacy placement and duration suffix. Placement does not change the canonical; duration is retained."
+    },
+    {
+      "v1_pattern": {
+        "format_id_glob": "video_640x480"
+      },
+      "v2": {
+        "canonical": "video_hosted",
+        "parameters": {
+          "width": 640,
+          "height": 480
+        }
+      },
+      "notes": "Observed legacy dimension suffix. Exact dimensions are retained in the projected parameters."
+    },
+    {
+      "v1_pattern": {
+        "format_id_glob": "video_300x250"
+      },
+      "v2": {
+        "canonical": "video_hosted",
+        "parameters": {
+          "width": 300,
+          "height": 250
+        }
+      },
+      "notes": "Observed legacy dimension suffix. Exact dimensions are retained in the projected parameters."
+    },
+    {
+      "v1_pattern": {
+        "format_id_glob": "video_16x9_30s"
+      },
+      "v2": {
+        "canonical": "video_hosted",
+        "parameters": {
+          "aspect_ratio": "16:9",
+          "duration_ms_exact": 30000
+        }
+      },
+      "notes": "Observed legacy aspect-ratio and duration suffixes. Both constraints are retained in the projected parameters."
+    },
+    {
+      "v1_pattern": {
+        "format_id_glob": "video_640x360_vast"
+      },
+      "v2": {
+        "canonical": "video_vast",
+        "parameters": {
+          "width": 640,
+          "height": 360
+        }
+      },
+      "notes": "The VAST token selects video_vast wherever it occurs in a legacy id, including this observed suffix form; exact dimensions are retained."
+    },
+    {
+      "v1_pattern": {
+        "format_id_glob": "audio_15s"
+      },
+      "v2": {
+        "canonical": "audio_hosted",
+        "parameters": {
+          "duration_ms_exact": 15000
+        }
+      },
+      "notes": "Observed legacy duration suffix. Duration is retained so the projected format remains traffickable."
+    },
     {
       "v1_pattern": {
         "structural": {

package/dist/lib/schemas-data/3.1/signals/activate-signal-request.json

@@ -1,12 +1,12 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.5/signals/activate-signal-request.json",
+  "$id": "/schemas/3.1.8/signals/activate-signal-request.json",
   "title": "Activate Signal Request",
   "description": "Request parameters for activating or deactivating a signal on deployment targets",
   "type": "object",
   "allOf": [
     {
-      "$ref": "/schemas/3.1.5/core/version-envelope.json"
+      "$ref": "/schemas/3.1.8/core/version-envelope.json"
     }
   ],
   "x-mutates-state": true,
@@ -29,7 +29,7 @@
       "type": "array",
       "description": "Target destination(s) for activation. If the authenticated caller matches one of these destinations, activation keys will be included in the response.",
       "items": {
-        "$ref": "/schemas/3.1.5/core/destination.json"
+        "$ref": "/schemas/3.1.8/core/destination.json"
       },
       "minItems": 1
     },
@@ -46,7 +46,7 @@
       "pattern": "^[\\x20-\\x7E]+$"
     },
     "account": {
-      "$ref": "/schemas/3.1.5/core/account-ref.json",
+      "$ref": "/schemas/3.1.8/core/account-ref.json",
       "description": "Account for this activation. Associates with a commercial relationship established via sync_accounts."
     },
     "idempotency_key": {
@@ -57,10 +57,10 @@
       "pattern": "^[A-Za-z0-9_.:-]{16,255}$"
     },
     "context": {
-      "$ref": "/schemas/3.1.5/core/context.json"
+      "$ref": "/schemas/3.1.8/core/context.json"
     },
     "ext": {
-      "$ref": "/schemas/3.1.5/core/ext.json"
+      "$ref": "/schemas/3.1.8/core/ext.json"
     }
   },
   "required": [

package/dist/lib/schemas-data/3.1/signals/activate-signal-response.json

@@ -1,15 +1,15 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.5/signals/activate-signal-response.json",
+  "$id": "/schemas/3.1.8/signals/activate-signal-response.json",
   "title": "Activate Signal Response",
   "description": "Response payload for activate_signal task. Returns either complete success data OR error information, never both. This enforces atomic operation semantics - the signal is either fully activated or not activated at all.",
   "type": "object",
   "allOf": [
     {
-      "$ref": "/schemas/3.1.5/core/version-envelope.json"
+      "$ref": "/schemas/3.1.8/core/version-envelope.json"
     },
     {
-      "$ref": "/schemas/3.1.5/core/protocol-envelope.json"
+      "$ref": "/schemas/3.1.8/core/protocol-envelope.json"
     }
   ],
   "oneOf": [
@@ -22,7 +22,7 @@
           "type": "array",
           "description": "Array of deployment results for each deployment target",
           "items": {
-            "$ref": "/schemas/3.1.5/core/deployment.json"
+            "$ref": "/schemas/3.1.8/core/deployment.json"
           }
         },
         "sandbox": {
@@ -30,10 +30,10 @@
           "description": "When true, this response contains simulated data from sandbox mode."
         },
         "context": {
-          "$ref": "/schemas/3.1.5/core/context.json"
+          "$ref": "/schemas/3.1.8/core/context.json"
         },
         "ext": {
-          "$ref": "/schemas/3.1.5/core/ext.json"
+          "$ref": "/schemas/3.1.8/core/ext.json"
         }
       },
       "required": [
@@ -55,15 +55,15 @@
           "type": "array",
           "description": "Array of errors explaining why activation failed (e.g., platform connectivity issues, signal definition problems, authentication failures)",
           "items": {
-            "$ref": "/schemas/3.1.5/core/error.json"
+            "$ref": "/schemas/3.1.8/core/error.json"
           },
           "minItems": 1
         },
         "context": {
-          "$ref": "/schemas/3.1.5/core/context.json"
+          "$ref": "/schemas/3.1.8/core/context.json"
         },
         "ext": {
-          "$ref": "/schemas/3.1.5/core/ext.json"
+          "$ref": "/schemas/3.1.8/core/ext.json"
         }
       },
       "required": [

package/dist/lib/schemas-data/3.1/signals/get-signals-async-response-submitted.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.5/signals/get-signals-async-response-submitted.json",
+  "$id": "/schemas/3.1.8/signals/get-signals-async-response-submitted.json",
   "title": "Get Signals - Submitted",
   "description": "Async task envelope returned when get_signals cannot be confirmed before the response — for example, when semantic discovery depends on slow provider queries or review. This envelope is valid only for `discovery_mode: \"brief\"`; `discovery_mode: \"wholesale\"` is a synchronous wholesale signals feed read and MUST NOT use the Submitted arm. The caller can always poll `get_task_status` (legacy `tasks/get`) with `task_id`. If the originating request carried `push_notification_config`, the agent also delivers at least the terminal completion/failure notification to that webhook URL; intermediate progress notifications are MAY. The signals array lands on the completion artifact, not this envelope.",
   "type": "object",
@@ -29,14 +29,14 @@
       "type": "array",
       "description": "Optional advisory errors accompanying the submitted envelope. Use only for non-blocking warnings (e.g., throttled_severity advisories or partial provider unavailability). Terminal failures belong in the error branch, not here.",
       "items": {
-        "$ref": "/schemas/3.1.5/core/error.json"
+        "$ref": "/schemas/3.1.8/core/error.json"
       }
     },
     "context": {
-      "$ref": "/schemas/3.1.5/core/context.json"
+      "$ref": "/schemas/3.1.8/core/context.json"
     },
     "ext": {
-      "$ref": "/schemas/3.1.5/core/ext.json"
+      "$ref": "/schemas/3.1.8/core/ext.json"
     }
   },
   "required": [

package/dist/lib/schemas-data/3.1/signals/get-signals-async-response-working.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.1.5/signals/get-signals-async-response-working.json",
+  "$id": "/schemas/3.1.8/signals/get-signals-async-response-working.json",
   "title": "Get Signals - Working",
   "description": "Progress payload for an active get_signals task after a submitted semantic discovery request has started processing. Valid only for `discovery_mode: \"brief\"`; wholesale signals feed reads report partial completion via `incomplete[]`, not async task progress.",
   "type": "object",
@@ -24,10 +24,10 @@
       "description": "Current step number (1-indexed)."
     },
     "context": {
-      "$ref": "/schemas/3.1.5/core/context.json"
+      "$ref": "/schemas/3.1.8/core/context.json"
     },
     "ext": {
-      "$ref": "/schemas/3.1.5/core/ext.json"
+      "$ref": "/schemas/3.1.8/core/ext.json"
     }
   },
   "additionalProperties": true