feat(protocol): adopt AdCP 3.2.1 GA for SDK 8.0.0 (#1270)

Adopt signed AdCP 3.2.1 and switch Release Please to stable.

Release-As: 8.0.0

Author: bokelley

.github/workflows/ci.yml

@@ -1033,7 +1033,7 @@ jobs:
               for child in schema_root.iterdir()
               if child.is_dir()
           }
-          # Ship released 3.0/3.1 and only the current 3.2 candidate offline.
+          # Ship released 3.0/3.1 and the current 3.2 line offline.
           assert packaged_versions == {
               "3.0", "3.1", current_bundle
           }

MANIFEST.in

@@ -4,29 +4,32 @@ include LICENSE
 include MIGRATION*.md
 recursive-include src/adcp py.typed
 recursive-include src/adcp/reporting/materializer/assets *.json
-recursive-include src/adcp/_compliance/3.2.0-rc.7 *.json *.jsonl *.yaml *.md
+recursive-include src/adcp/_compliance/3.2.1 *.json *.jsonl *.yaml *.md
 # Bundled AdCP JSON schemas. ``scripts/bundle_schemas.py`` mirrors
 # ``schemas/cache/`` into ``src/adcp/_schemas/`` before ``python -m
 # build`` so the validator ships with the wheel. Keep distributions on
-# supported released lines and the current 3.2 release candidate.
+# supported released lines: 3.0, 3.1 and 3.2 (AdCP 3.2.1).
 recursive-include src/adcp/_schemas/3.0 *.json
 recursive-include src/adcp/_schemas/3.1 *.json
-recursive-include src/adcp/_schemas/3.2.0-rc.7 *.json
+recursive-include src/adcp/_schemas/3.2 *.json
 prune src/adcp/_schemas/2.5
 prune src/adcp/_schemas/3.2.0-beta.6
 prune src/adcp/_schemas/3.2.0-rc.3
 prune src/adcp/_schemas/3.2.0-rc.6
+prune src/adcp/_schemas/3.2.0-rc.7
 prune src/adcp/_compliance/3.2.0-rc.6
+prune src/adcp/_compliance/3.2.0-rc.7
 prune src/adcp/_schemas/3.1.0-*
 # A clean VCS source tree has no ignored ``src/adcp/_schemas`` directory.
 # Keep the tracked inputs needed by the build_py hook in source distributions
 # so wheels built from an sdist have the same schema set as direct VCS wheels.
 recursive-include schemas/cache/3.0 *.json
 recursive-include schemas/cache/3.1 *.json
-recursive-include schemas/cache/3.2.0-rc.7 *.json
+recursive-include schemas/cache/3.2 *.json
 prune schemas/cache/2.5
 prune schemas/cache/3.2.0-beta.6
 prune schemas/cache/3.2.0-rc.3
 prune schemas/cache/3.2.0-rc.6
+prune schemas/cache/3.2.0-rc.7
 prune schemas/releases
-include schemas/releases/3.2.0-rc.7.json
+include schemas/releases/3.2.1.json

MIGRATION_ADCP_3.1_TO_3.2.md

@@ -1,6 +1,6 @@
-# Migrating an integration from AdCP 3.1 to 3.2 beta
+# Migrating an integration from AdCP 3.1 to 3.2
 
-Python SDK 8 beta supports the AdCP `3.2.0-beta.4` schemas and the compact
+Python SDK 8 supports the AdCP `3.2.1` schemas and the compact
 product/media-buy lifecycle that becomes the foundation of AdCP 4.0. The SDK
 continues to support AdCP 3.0 and 3.1, and the deprecated
 `get_products`/`create_media_buy`/`update_media_buy` lifecycle remains available
@@ -11,17 +11,20 @@ seller may expose only the old lifecycle, a direct-buy subset of the compact
 lifecycle, or the complete proposal lifecycle. Do not infer supported tools
 from the version alone; read `media_buy.lifecycle_tools` or MCP `tools/list`.
 
-## Pin the beta precisely
+## Pin AdCP 3.2
 
-Use the release-precision prerelease identifier while 3.2 is in beta:
+AdCP 3.2.1 is the 3.2 general-availability release. Pin its release-precision
+wire value:
 
 ```python
-client = ADCPClient(agent, adcp_version="3.2-beta.4")
-server = adcp_server("seller", adcp_version="3.2-beta.4")
+client = ADCPClient(agent, adcp_version="3.2")
+server = adcp_server("seller", adcp_version="3.2")
 ```
 
-`"3.2"` intentionally does not alias to a prerelease. Exact prerelease pins
-prevent a deployment from silently changing contracts when 3.2 stable ships.
+Patch releases do not change the wire contract, so `"3.2"` covers 3.2.1 and
+later 3.2 patches. AdCP 3.2.0 was withdrawn; do not target it. Prerelease pins
+such as `"3.2-beta.4"` or `"3.2-rc.7"` are no longer advertised; this SDK
+advertises `3.0`, `3.1` and `3.2`. Replace them with `"3.2"`.
 
 ## Beta.4 integration notes
 

MIGRATION_v7_to_v8.md

@@ -1,16 +1,14 @@
 # Migrating from Python SDK 7 to 8
 
-For the upcoming Reliable Reporting prerelease, read the
-[reporting upgrade and release notes](docs/reporting-release-notes.md) before
-deploying. They cover the account-qualified `generation_key` API change,
+Before deploying Reliable Reporting, read the
+[reporting upgrade and release notes](docs/reporting-release-notes.md). They cover the account-qualified `generation_key` API change,
 PostgreSQL drain/migration/activation sequence, all nine historical comparison
 boundaries, and the distinction between offline schemas and live rc.6 mounts.
-Final package and full-rollout qualification remain pending.
 
-SDK 8 beta also updates the generated protocol surface from AdCP 3.1.15 to
-AdCP 3.2.0-beta.4 and adds the compact product/media-buy lifecycle. The old
+SDK 8 also updates the generated protocol surface from AdCP 3.1.15 to
+AdCP 3.2.1 and adds the compact product/media-buy lifecycle. The old
 3.x lifecycle remains supported. See
-[Migrating an integration from AdCP 3.1 to 3.2 beta](MIGRATION_ADCP_3.1_TO_3.2.md)
+[Migrating an integration from AdCP 3.1 to 3.2](MIGRATION_ADCP_3.1_TO_3.2.md)
 for lifecycle selection, capability declarations, and the compatibility test
 matrix.
 

README.md

@@ -333,16 +333,18 @@ async with ADCPMultiAgentClient(
 
 ## AdCP version support
 
-The SDK 8 beta line is built against **AdCP 3.2.0-beta.10**, makes canonical
-creatives the primary Python contract, and negotiates AdCP 3.0, 3.1, and the
-exact 3.2 beta wire dialect. The SDK package version and protocol version are
+SDK 8 is built against **AdCP 3.2.1**, the AdCP 3.2 general-availability
+release, and makes canonical creatives the primary Python contract. It
+negotiates AdCP 3.0, 3.1, and 3.2. On the wire, 3.2 is `"3.2"`, because
+`adcp_version` carries release precision only. AdCP 3.2.0 was withdrawn and
+is not a supported target. The SDK package version and protocol version are
 intentionally independent:
 
 ```python
 import adcp
 
-adcp.get_adcp_sdk_version()   # SDK package version, e.g. "8.0.0b11"
-adcp.get_adcp_spec_version()  # AdCP spec this build targets, e.g. "3.2.0-beta.10"
+adcp.get_adcp_sdk_version()   # SDK package version, e.g. "8.0.0"
+adcp.get_adcp_spec_version()  # AdCP spec this build targets, e.g. "3.2.1"
 ```
 
 If you talk to an agent on a newer spec than this SDK validates, the response
@@ -360,7 +362,7 @@ forward traffic degrades gracefully rather than failing.
 - **[Reporting source adapters](docs/reporting-source-adapters.md)** - Per-metric availability evidence, coverage, and control totals for inline delivery fetches
 - **[Migrating from SDK 6 to 7](https://github.com/adcontextprotocol/adcp-client-python/blob/main/MIGRATION_v6_to_v7.md)** - Breaking API, security, concurrency, and webhook changes
 - **[Migrating from SDK 7 to 8](https://github.com/adcontextprotocol/adcp-client-python/blob/main/MIGRATION_v7_to_v8.md)** - Secure webhook defaults and telemetry changes
-- **[Migrating from AdCP 3.1 to 3.2 beta](MIGRATION_ADCP_3.1_TO_3.2.md)** - Compact lifecycle adoption and old/new compatibility matrix
+- **[Migrating from AdCP 3.1 to 3.2](MIGRATION_ADCP_3.1_TO_3.2.md)** - Compact lifecycle adoption and old/new compatibility matrix
 - **[Durable legacy purchase continuations](docs/legacy-purchase-continuations.md)** - Safe products-only compatibility redemption and crash recovery
 - **[Media-buy lifecycle coordinator](docs/media-buy-lifecycle-coordinator.md)** - Negotiated catalog-to-purchase workflow across AdCP 3.0, 3.1, and 3.2; remaining buyer parity is tracked in [#1154](https://github.com/adcontextprotocol/adcp-client-python/issues/1154)
 - **[Media-buy action rights](docs/media-buy-action-rights.md)** - Assess product possibilities, accepted change rights, and currently available actions

SCHEMA_DELTAS.md

@@ -1,22 +1,43 @@
 # Generated-types delta
 
+## Files added
+
+- `core/outcome_target_cost_per.py` — OutcomeTargetCostPer
+- `core/product_execution_requirement.py` — Connection, ProductExecutionRequirement, ProductExecutionRequirement1, ProductExecutionRequirement2, ProductExecutionRequirement3, RequiredForItem, Status
+- `core/reporting_delivery_offering_id.py` — ReportingDeliveryOfferingId
+- `enums/outcome_target_cost_strength.py` — OutcomeTargetCostStrength
+- `error_details/execution_requirement_unmet.py` — ExecutionRequirementUnmetDetails, Reason, UnmetRequirement
+
 ## Field changes
 
 - `bundled/protocol/get_adcp_capabilities_response.py`
-  - `SupportedOptimizationMetric`: `+viewable_rate`
-- `core/budget_allocation.py`
-  - `Metric`: `+viewable_rate`
-  - `OptimizationGoal1`: `+standard`, `+vendor`
-- `core/canonical_optimization_goal.py`
-  - `CanonicalOptimizationGoal1`: `+standard`, `+vendor`
-  - `Metric`: `+viewable_rate`
-- `core/optimization_goal.py`
-  - `Metric`: `+viewable_rate`
-  - `OptimizationGoal8`: `+standard`, `+vendor`
+  - `Features1`: `+seller_optimized_min_spend_targets`, `+seller_optimized_package_budgets`, `+seller_optimized_package_pacing`
+- `core/canonical_media_buy_features.py`
+  - `CanonicalMediaBuyFeatures`: `+seller_optimized_min_spend_targets`, `+seller_optimized_package_budgets`, `+seller_optimized_package_pacing`
+- `core/canonical_product.py`
+  - `CanonicalProduct`: `+collection_targeting_allowed`, `+collections`, `+execution_requirements`, `+targeting_resolution`
+- `core/canonical_reporting_capabilities.py`
+  - `CanonicalReportingCapabilities`: `+reporting_delivery_offering_ids`
+- `core/media_buy_features.py`
+  - `MediaBuyFeatures`: `+seller_optimized_min_spend_targets`, `+seller_optimized_package_budgets`, `+seller_optimized_package_pacing`
 - `core/product.py`
-  - `MetricOptimization`: `+supported_viewability_standards`
-  - `SupportedMetric`: `+viewable_rate`
-- `media_buy/list_creative_formats_request.py`
-  - `ListCreativeFormatsRequest`: `+account`
-- `protocol/get_adcp_capabilities_response.py`
-  - `SupportedOptimizationMetric`: `+viewable_rate`
+  - `Product`: `+execution_requirements`
+- `core/reporting_capabilities.py`
+  - **classes removed**: ReportingDeliveryOfferingId
+- `governance/sync_plans_response.py`
+  - **classes added**: Status51
+  - **classes removed**: Status50
+- `media_buy/get_media_buy_delivery_response.py`
+  - `ReportingPeriod`: `+timezone`
+- `media_buy/get_products_request.py`
+  - `Field1`: `+execution_requirements`
+  - `Fields`: `-collection_targeting_allowed`, `-collections`, `-targeting_resolution`
+- `media_buy/media_buy_delivery_webhook_result.py`
+  - `ReportingPeriod`: `+timezone`
+- `media_buy/outcome_target.py`
+  - `OutcomeTarget`: `+cost_per`
+- `media_buy/product_fields.py`
+  - `ProductResponseField`: `+collection_targeting_allowed`, `+collections`, `+execution_requirements`, `+targeting_resolution`
+- `sponsored_intelligence/si_sponsored_context_receipt.py`
+  - **classes added**: Status46
+  - **classes removed**: Status45

docs/releasing.md

@@ -2,8 +2,17 @@
 
 Release Please opens or updates the release PR after a push to `main`. It uses the
 release App credential so the release PR receives normal CI. The workflow
-normalizes the proposed `pyproject.toml` prerelease version to PEP 440. Review
-and merge that PR once its required checks and reviews pass.
+normalizes the proposed `pyproject.toml` prerelease version to PEP 440 (a
+no-op for stable versions). Review and merge that PR once its required checks
+and reviews pass.
+
+SDK 8 uses normal SemVer versioning: `release-please-config.json` has no
+`versioning: prerelease`, `prerelease-type`, or `prerelease` keys. To choose an
+exact version (for example the first stable release after an rc series), the
+squash commit that lands on `main` must end its body with a
+`Release-As: X.Y.Z` footer. The repository squashes with the branch commit
+messages as the default body, so check the final message in the merge dialog
+before confirming; the PR title and description alone are not parsed.
 After re-enabling a disabled Release Please workflow, run it once manually on
 `main` to process the current head; subsequent main pushes start it automatically.
 

docs/reporting-production.md

@@ -11,10 +11,10 @@ deploying these changes. They collect the historical comparison boundaries,
 feature-tier requirements and operational limits; final release qualification
 remains separate from the integrated source.
 
-The default protocol is AdCP 3.2.0-rc.7. Set `ReportingProductionSupport`'s
-`adcp_version="3.2-rc.7"` or omit the pin for the packaged default. Historical
-rc.3 and rc.6 schemas are available offline but are not advertised as live reporting
-contracts. See [rc.7 adoption](protocol-3.2-rc7.md) and
+The default protocol is AdCP 3.2.1. Set `ReportingProductionSupport`'s
+`adcp_version="3.2"` or omit the pin for the packaged default. Historical
+rc.3, rc.6 and rc.7 schemas are not advertised as live reporting contracts.
+See [rc.7 adoption](protocol-3.2-rc7.md) and
 [signed rc.6 inputs and history boundaries](protocol-3.2-rc6.md) for
 version-aligned mounts and integrated-parent continuation limits. Existing
 schema manifests and stored snapshot bytes are unchanged.
@@ -185,7 +185,7 @@ rejection is never a materializer retry signal.
 A generation owes only complete periods whose start is at or after activation
 and strictly before deactivation. A period already begun at deactivation remains
 owed in full, including its SLA. The producer and captured feed use the same rule.
-For the current `3.2-rc.7` contract, an open summary's `next_expected_at` is its
+For the current `3.2` contract, an open summary's `next_expected_at` is its
 nearest future obligation due time. A **complete summary** instead reports the
 nearest future period **start**, strictly after the captured `ledger_as_of`,
 across the committed generations in scope. It is absent when no such period

docs/reporting-receipt-ingress.md

@@ -91,9 +91,9 @@ path or rewrite receipt history to make an error disappear.
 
 ## Wire and replay contract
 
-Requests negotiate `adcp_version: "3.2-rc.7"`. This is the wire release spelling;
-`3.2.0-rc.7` is the bundle's semantic-version spelling. The reporting handler's
-public mount pin also selects unnegotiated traffic; its default is rc.7. General
+Requests negotiate `adcp_version: "3.2"`. This is the wire release spelling;
+`3.2.1` is the bundle's semantic-version spelling. The reporting handler's
+public mount pin also selects unnegotiated traffic; its default is 3.2. General
 SDK fallback behavior and unsupported-version rejection remain unchanged.
 Pinned, unpinned and fallback MCP inventories use an isolated schema overlay.
 Cached upstream schemas, generated models and older required protocols remain

docs/reporting-release-notes.md

@@ -1,10 +1,18 @@
 # Reliable Reporting upgrade and release notes
 
-## 8.0.0 release candidate
+## 8.0.0
 
-`adcp` 8.0.0rc1 freezes the SDK API for 8.0.0. The final 8.0.0 release
-follows AdCP 3.2.0 final. The release candidate includes AdCP 3.0, 3.1 and
-3.2.0-rc.7 schema bundles.
+`adcp` 8.0.0 is the first stable SDK 8 release. It targets AdCP 3.2.1, the
+AdCP 3.2 general-availability release (`3.2` on the wire), and ships the
+AdCP 3.0, 3.1 and 3.2.1 schema bundles. The 3.2 release-candidate bundles
+are no longer shipped. AdCP 3.2.0 was withdrawn and is not a supported
+target.
+
+Buyer receipt submission plans stored under `3.2-rc.6` or `3.2-rc.7` keep
+their exact request bytes and idempotency keys. A completed plan still
+replays for the same receipt list, and a new `3.2` reservation can follow it.
+A pending release-candidate plan remains readable, but the SDK refuses to send
+it (`INVALID_SUBMISSION_PLAN`) and never rewrites it as a `3.2` request.
 
 ## PostgreSQL worker contention
 
@@ -85,13 +93,13 @@ reauthorization and per-session destination authorization.
 
 ## Current and historical protocol versions
 
-Live reporting mounts and callers use AdCP `3.2-rc.7`, whose bundle spelling is
-`3.2.0-rc.7`. Omit an explicit pin to use the packaged default, or configure the
+Live reporting mounts and callers use AdCP `3.2`, whose bundle spelling is
+`3.2.1`. Omit an explicit pin to use the packaged default, or configure the
 current supported reporting version consistently across the composition and
 its mounts. Cross-cohort reporting requests are rejected even when optional
 request validation is disabled.
 
-Historical beta.6, rc.3 and rc.6 schema bundles support offline validation and
+Historical beta.6, rc.3, rc.6 and rc.7 schema bundles support offline validation and
 retained historical walks. Their presence does not enable a historical live
 mount or client pin. In rc.6, an exactly scoped bilateral waiver can retire
 the public mismatch and project underlying seller health while retaining the