@adcp/sdk 13.0.0-rc.6 → 13.0.0-rc.7

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.8/protocol/list-tasks-request.json",
+  "$id": "/schemas/3.1.10/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.8/core/version-envelope.json"
+      "$ref": "/schemas/3.1.10/core/version-envelope.json"
     }
   ],
   "properties": {
     "account": {
-      "$ref": "/schemas/3.1.8/core/account-ref.json",
+      "$ref": "/schemas/3.1.10/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.8/enums/adcp-protocol.json",
+          "$ref": "/schemas/3.1.10/enums/adcp-protocol.json",
           "description": "Filter by single AdCP protocol"
         },
         "protocols": {
           "type": "array",
           "description": "Filter by multiple AdCP protocols",
           "items": {
-            "$ref": "/schemas/3.1.8/enums/adcp-protocol.json"
+            "$ref": "/schemas/3.1.10/enums/adcp-protocol.json"
           },
           "minItems": 1
         },
         "status": {
-          "$ref": "/schemas/3.1.8/enums/task-status.json",
+          "$ref": "/schemas/3.1.10/enums/task-status.json",
           "description": "Filter by single task status"
         },
         "statuses": {
           "type": "array",
           "description": "Filter by multiple task statuses",
           "items": {
-            "$ref": "/schemas/3.1.8/enums/task-status.json"
+            "$ref": "/schemas/3.1.10/enums/task-status.json"
           },
           "minItems": 1
         },
         "task_type": {
-          "$ref": "/schemas/3.1.8/enums/task-type.json",
+          "$ref": "/schemas/3.1.10/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.8/enums/task-type.json"
+            "$ref": "/schemas/3.1.10/enums/task-type.json"
           },
           "minItems": 1
         },
@@ -111,7 +111,7 @@
           "description": "Field to sort by"
         },
         "direction": {
-          "$ref": "/schemas/3.1.8/enums/sort-direction.json",
+          "$ref": "/schemas/3.1.10/enums/sort-direction.json",
           "default": "desc",
           "description": "Sort direction"
         }
@@ -119,7 +119,7 @@
       "additionalProperties": true
     },
     "pagination": {
-      "$ref": "/schemas/3.1.8/core/pagination-request.json"
+      "$ref": "/schemas/3.1.10/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.8/core/context.json"
+      "$ref": "/schemas/3.1.10/core/context.json"
     },
     "ext": {
-      "$ref": "/schemas/3.1.8/core/ext.json"
+      "$ref": "/schemas/3.1.10/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.8/protocol/list-tasks-response.json",
+  "$id": "/schemas/3.1.10/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.8/core/version-envelope.json"
+      "$ref": "/schemas/3.1.10/core/version-envelope.json"
     },
     {
-      "$ref": "/schemas/3.1.8/core/protocol-envelope.json"
+      "$ref": "/schemas/3.1.10/core/protocol-envelope.json"
     }
   ],
   "properties": {
@@ -101,7 +101,7 @@
             "x-entity": "task"
           },
           "task_type": {
-            "$ref": "/schemas/3.1.8/enums/task-type.json",
+            "$ref": "/schemas/3.1.10/enums/task-type.json",
             "description": "Type of AdCP operation"
           },
           "domain": {
@@ -114,7 +114,7 @@
             ]
           },
           "status": {
-            "$ref": "/schemas/3.1.8/enums/task-status.json",
+            "$ref": "/schemas/3.1.10/enums/task-status.json",
             "description": "Current task status"
           },
           "created_at": {
@@ -149,13 +149,13 @@
       }
     },
     "pagination": {
-      "$ref": "/schemas/3.1.8/core/pagination-response.json"
+      "$ref": "/schemas/3.1.10/core/pagination-response.json"
     },
     "context": {
-      "$ref": "/schemas/3.1.8/core/context.json"
+      "$ref": "/schemas/3.1.10/core/context.json"
     },
     "ext": {
-      "$ref": "/schemas/3.1.8/core/ext.json"
+      "$ref": "/schemas/3.1.10/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.8/registries/v1-canonical-mapping.json",
+  "$id": "/schemas/3.1.10/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 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",
+  "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**Image rendition-set exception (normative).** This specific rule takes precedence over the generic alias-collision rule above. When the matched mapping declares an image slot with `required_pixel_ratios`, v1 image assets sharing that slot's `asset_group_id` are intentional renditions rather than collisions. The SDK MUST validate each asset against a distinct accepted density and collect them, in v1 declaration order, into the canonical slot array. Missing or duplicate required densities fail under the rendition-set rules; only remaining same-group assets enter ordinary collision handling.\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.3.0",
+  "last_updated": "2026-08-03",
   "type": "object",
   "required": [
     "version",
@@ -99,7 +99,7 @@
             ],
             "properties": {
               "canonical": {
-                "$ref": "/schemas/3.1.8/core/canonical-format-kind.json",
+                "$ref": "/schemas/3.1.10/core/canonical-format-kind.json",
                 "description": "v2 canonical format the v1 pattern projects to."
               },
               "parameters": {
@@ -288,6 +288,356 @@
       },
       "notes": "Observed AAO-namespace unsuffixed display size id. Exact pixel dimensions are retained in the projected parameters."
     },
+    {
+      "v1_pattern": {
+        "format_id_glob": "display_300x250_image_2x"
+      },
+      "v2": {
+        "canonical": "image",
+        "parameters": {
+          "width": 300,
+          "height": 250,
+          "pixel_ratios": [
+            2
+          ]
+        }
+      },
+      "notes": "Unversioned legacy reference-catalog compatibility format requiring only a 600x500 asset for a logical 300x250 image. pixel_ratios is opaque forward-projection metadata interpreted only by a 3.2-aware SDK; it is not pre-3.2 canonical protocol support."
+    },
+    {
+      "v1_pattern": {
+        "format_id_glob": "display_728x90_image_2x"
+      },
+      "v2": {
+        "canonical": "image",
+        "parameters": {
+          "width": 728,
+          "height": 90,
+          "pixel_ratios": [
+            2
+          ]
+        }
+      },
+      "notes": "Unversioned legacy reference-catalog compatibility format requiring only a 1456x180 asset for a logical 728x90 image. pixel_ratios is opaque forward-projection metadata interpreted only by a 3.2-aware SDK; it is not pre-3.2 canonical protocol support."
+    },
+    {
+      "v1_pattern": {
+        "format_id_glob": "display_320x50_image_2x"
+      },
+      "v2": {
+        "canonical": "image",
+        "parameters": {
+          "width": 320,
+          "height": 50,
+          "pixel_ratios": [
+            2
+          ]
+        }
+      },
+      "notes": "Unversioned legacy reference-catalog compatibility format requiring only a 640x100 asset for a logical 320x50 image. pixel_ratios is opaque forward-projection metadata interpreted only by a 3.2-aware SDK; it is not pre-3.2 canonical protocol support."
+    },
+    {
+      "v1_pattern": {
+        "format_id_glob": "display_160x600_image_2x"
+      },
+      "v2": {
+        "canonical": "image",
+        "parameters": {
+          "width": 160,
+          "height": 600,
+          "pixel_ratios": [
+            2
+          ]
+        }
+      },
+      "notes": "Unversioned legacy reference-catalog compatibility format requiring only a 320x1200 asset for a logical 160x600 image. pixel_ratios is opaque forward-projection metadata interpreted only by a 3.2-aware SDK; it is not pre-3.2 canonical protocol support."
+    },
+    {
+      "v1_pattern": {
+        "format_id_glob": "display_336x280_image_2x"
+      },
+      "v2": {
+        "canonical": "image",
+        "parameters": {
+          "width": 336,
+          "height": 280,
+          "pixel_ratios": [
+            2
+          ]
+        }
+      },
+      "notes": "Unversioned legacy reference-catalog compatibility format requiring only a 672x560 asset for a logical 336x280 image. pixel_ratios is opaque forward-projection metadata interpreted only by a 3.2-aware SDK; it is not pre-3.2 canonical protocol support."
+    },
+    {
+      "v1_pattern": {
+        "format_id_glob": "display_300x600_image_2x"
+      },
+      "v2": {
+        "canonical": "image",
+        "parameters": {
+          "width": 300,
+          "height": 600,
+          "pixel_ratios": [
+            2
+          ]
+        }
+      },
+      "notes": "Unversioned legacy reference-catalog compatibility format requiring only a 600x1200 asset for a logical 300x600 image. pixel_ratios is opaque forward-projection metadata interpreted only by a 3.2-aware SDK; it is not pre-3.2 canonical protocol support."
+    },
+    {
+      "v1_pattern": {
+        "format_id_glob": "display_970x250_image_2x"
+      },
+      "v2": {
+        "canonical": "image",
+        "parameters": {
+          "width": 970,
+          "height": 250,
+          "pixel_ratios": [
+            2
+          ]
+        }
+      },
+      "notes": "Unversioned legacy reference-catalog compatibility format requiring only a 1940x500 asset for a logical 970x250 image. pixel_ratios is opaque forward-projection metadata interpreted only by a 3.2-aware SDK; it is not pre-3.2 canonical protocol support."
+    },
+    {
+      "v1_pattern": {
+        "format_id_glob": "display_300x250_image_1x_2x"
+      },
+      "v2": {
+        "canonical": "image",
+        "parameters": {
+          "width": 300,
+          "height": 250,
+          "pixel_ratios": [
+            1,
+            2
+          ],
+          "slots": [
+            {
+              "asset_group_id": "image_main",
+              "asset_type": "image",
+              "required": true,
+              "min": 2,
+              "max": 2,
+              "pixel_ratios": [
+                1,
+                2
+              ],
+              "required_pixel_ratios": [
+                1,
+                2
+              ]
+            }
+          ]
+        }
+      },
+      "notes": "Unversioned legacy reference-catalog compatibility format requiring 300x250 and 600x500 renditions of one logical image. Density and required-coverage values are opaque forward-projection metadata for 3.2-aware SDKs, not pre-3.2 canonical protocol support."
+    },
+    {
+      "v1_pattern": {
+        "format_id_glob": "display_728x90_image_1x_2x"
+      },
+      "v2": {
+        "canonical": "image",
+        "parameters": {
+          "width": 728,
+          "height": 90,
+          "pixel_ratios": [
+            1,
+            2
+          ],
+          "slots": [
+            {
+              "asset_group_id": "image_main",
+              "asset_type": "image",
+              "required": true,
+              "min": 2,
+              "max": 2,
+              "pixel_ratios": [
+                1,
+                2
+              ],
+              "required_pixel_ratios": [
+                1,
+                2
+              ]
+            }
+          ]
+        }
+      },
+      "notes": "Unversioned legacy reference-catalog compatibility format requiring 728x90 and 1456x180 renditions of one logical image. Density and required-coverage values are opaque forward-projection metadata for 3.2-aware SDKs, not pre-3.2 canonical protocol support."
+    },
+    {
+      "v1_pattern": {
+        "format_id_glob": "display_320x50_image_1x_2x"
+      },
+      "v2": {
+        "canonical": "image",
+        "parameters": {
+          "width": 320,
+          "height": 50,
+          "pixel_ratios": [
+            1,
+            2
+          ],
+          "slots": [
+            {
+              "asset_group_id": "image_main",
+              "asset_type": "image",
+              "required": true,
+              "min": 2,
+              "max": 2,
+              "pixel_ratios": [
+                1,
+                2
+              ],
+              "required_pixel_ratios": [
+                1,
+                2
+              ]
+            }
+          ]
+        }
+      },
+      "notes": "Unversioned legacy reference-catalog compatibility format requiring 320x50 and 640x100 renditions of one logical image. Density and required-coverage values are opaque forward-projection metadata for 3.2-aware SDKs, not pre-3.2 canonical protocol support."
+    },
+    {
+      "v1_pattern": {
+        "format_id_glob": "display_160x600_image_1x_2x"
+      },
+      "v2": {
+        "canonical": "image",
+        "parameters": {
+          "width": 160,
+          "height": 600,
+          "pixel_ratios": [
+            1,
+            2
+          ],
+          "slots": [
+            {
+              "asset_group_id": "image_main",
+              "asset_type": "image",
+              "required": true,
+              "min": 2,
+              "max": 2,
+              "pixel_ratios": [
+                1,
+                2
+              ],
+              "required_pixel_ratios": [
+                1,
+                2
+              ]
+            }
+          ]
+        }
+      },
+      "notes": "Unversioned legacy reference-catalog compatibility format requiring 160x600 and 320x1200 renditions of one logical image. Density and required-coverage values are opaque forward-projection metadata for 3.2-aware SDKs, not pre-3.2 canonical protocol support."
+    },
+    {
+      "v1_pattern": {
+        "format_id_glob": "display_336x280_image_1x_2x"
+      },
+      "v2": {
+        "canonical": "image",
+        "parameters": {
+          "width": 336,
+          "height": 280,
+          "pixel_ratios": [
+            1,
+            2
+          ],
+          "slots": [
+            {
+              "asset_group_id": "image_main",
+              "asset_type": "image",
+              "required": true,
+              "min": 2,
+              "max": 2,
+              "pixel_ratios": [
+                1,
+                2
+              ],
+              "required_pixel_ratios": [
+                1,
+                2
+              ]
+            }
+          ]
+        }
+      },
+      "notes": "Unversioned legacy reference-catalog compatibility format requiring 336x280 and 672x560 renditions of one logical image. Density and required-coverage values are opaque forward-projection metadata for 3.2-aware SDKs, not pre-3.2 canonical protocol support."
+    },
+    {
+      "v1_pattern": {
+        "format_id_glob": "display_300x600_image_1x_2x"
+      },
+      "v2": {
+        "canonical": "image",
+        "parameters": {
+          "width": 300,
+          "height": 600,
+          "pixel_ratios": [
+            1,
+            2
+          ],
+          "slots": [
+            {
+              "asset_group_id": "image_main",
+              "asset_type": "image",
+              "required": true,
+              "min": 2,
+              "max": 2,
+              "pixel_ratios": [
+                1,
+                2
+              ],
+              "required_pixel_ratios": [
+                1,
+                2
+              ]
+            }
+          ]
+        }
+      },
+      "notes": "Unversioned legacy reference-catalog compatibility format requiring 300x600 and 600x1200 renditions of one logical image. Density and required-coverage values are opaque forward-projection metadata for 3.2-aware SDKs, not pre-3.2 canonical protocol support."
+    },
+    {
+      "v1_pattern": {
+        "format_id_glob": "display_970x250_image_1x_2x"
+      },
+      "v2": {
+        "canonical": "image",
+        "parameters": {
+          "width": 970,
+          "height": 250,
+          "pixel_ratios": [
+            1,
+            2
+          ],
+          "slots": [
+            {
+              "asset_group_id": "image_main",
+              "asset_type": "image",
+              "required": true,
+              "min": 2,
+              "max": 2,
+              "pixel_ratios": [
+                1,
+                2
+              ],
+              "required_pixel_ratios": [
+                1,
+                2
+              ]
+            }
+          ]
+        }
+      },
+      "notes": "Unversioned legacy reference-catalog compatibility format requiring 970x250 and 1940x500 renditions of one logical image. Density and required-coverage values are opaque forward-projection metadata for 3.2-aware SDKs, not pre-3.2 canonical protocol support."
+    },
     {
       "v1_pattern": {
         "format_id_glob": "video_30s"

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.8/signals/activate-signal-request.json",
+  "$id": "/schemas/3.1.10/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.8/core/version-envelope.json"
+      "$ref": "/schemas/3.1.10/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.8/core/destination.json"
+        "$ref": "/schemas/3.1.10/core/destination.json"
       },
       "minItems": 1
     },
@@ -46,7 +46,7 @@
       "pattern": "^[\\x20-\\x7E]+$"
     },
     "account": {
-      "$ref": "/schemas/3.1.8/core/account-ref.json",
+      "$ref": "/schemas/3.1.10/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.8/core/context.json"
+      "$ref": "/schemas/3.1.10/core/context.json"
     },
     "ext": {
-      "$ref": "/schemas/3.1.8/core/ext.json"
+      "$ref": "/schemas/3.1.10/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.8/signals/activate-signal-response.json",
+  "$id": "/schemas/3.1.10/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.8/core/version-envelope.json"
+      "$ref": "/schemas/3.1.10/core/version-envelope.json"
     },
     {
-      "$ref": "/schemas/3.1.8/core/protocol-envelope.json"
+      "$ref": "/schemas/3.1.10/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.8/core/deployment.json"
+            "$ref": "/schemas/3.1.10/core/deployment.json"
           }
         },
         "sandbox": {
@@ -30,10 +30,10 @@
           "description": "When true, this response contains simulated data from sandbox mode."
         },
         "context": {
-          "$ref": "/schemas/3.1.8/core/context.json"
+          "$ref": "/schemas/3.1.10/core/context.json"
         },
         "ext": {
-          "$ref": "/schemas/3.1.8/core/ext.json"
+          "$ref": "/schemas/3.1.10/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.8/core/error.json"
+            "$ref": "/schemas/3.1.10/core/error.json"
           },
           "minItems": 1
         },
         "context": {
-          "$ref": "/schemas/3.1.8/core/context.json"
+          "$ref": "/schemas/3.1.10/core/context.json"
         },
         "ext": {
-          "$ref": "/schemas/3.1.8/core/ext.json"
+          "$ref": "/schemas/3.1.10/core/ext.json"
         }
       },
       "required": [