@adcp/sdk 16.0.0-beta.9 → 16.0.0

package/dist/lib/version.d.ts

@@ -1,7 +1,7 @@
 /**
  * AdCP SDK library version
  */
-export declare const LIBRARY_VERSION = "16.0.0-beta.9";
+export declare const LIBRARY_VERSION = "16.0.0";
 /**
  * AdCP specification version this library is built for
  */
@@ -33,10 +33,10 @@ export type AdcpVersion = (typeof COMPATIBLE_ADCP_VERSIONS)[number];
  * Full version information
  */
 export declare const VERSION_INFO: {
-    readonly library: "16.0.0-beta.9";
+    readonly library: "16.0.0";
     readonly adcp: "3.2.5";
     readonly compatibleVersions: readonly ["v3", "3.0.0", "3.0", "3.0.1", "3.0.2", "3.0.3", "3.0.4", "3.0.5", "3.0.6", "3.0.7", "3.0.8", "3.0.9", "3.0.10", "3.0.11", "3.0.12", "3.0.13", "3.0.14", "3.0.15", "3.0.16", "3.0.17", "3.0.18", "3.0.19", "3.0.20", "3.0.21", "3.0.22", "3.0.23", "3.0.24", "3.0.25", "3.1.0", "3.1", "3.1.1", "3.1.2", "3.1.3", "3.1.4", "3.1.5", "3.1.6", "3.1.7", "3.1.8", "3.1.9", "3.1.10", "3.1.11", "3.1.12", "3.1.13", "3.1.14", "3.1.15", "3.1.16", "3.1.17", "3.1.18", "3.1.19", "3.1.20", "3.1.21", "3.1.22", "3.1.23", "3.1.24", "3.1.25", "3.1.26", "3.1.27", "3.1.28", "3.1.29", "3.2.1", "3.2", "3.2.2", "3.2.3", "3.2.4", "3.2.5"];
-    readonly generatedAt: "2026-10-19T19:41:05.601Z";
+    readonly generatedAt: "2026-10-19T23:27:30.750Z";
 };
 /**
  * Get the AdCP specification version this library is built for

package/dist/lib/version.js

@@ -31,7 +31,7 @@ __export(version_exports, {
   toReleasePrecisionVersion: () => toReleasePrecisionVersion
 });
 module.exports = __toCommonJS(version_exports);
-const LIBRARY_VERSION = "16.0.0-beta.9";
+const LIBRARY_VERSION = "16.0.0";
 const ADCP_VERSION = "3.2.5";
 const ADCP_MAJOR_VERSION = 3;
 const COMPATIBLE_ADCP_VERSIONS = [
@@ -102,10 +102,10 @@ const COMPATIBLE_ADCP_VERSIONS = [
   "3.2.5"
 ];
 const VERSION_INFO = {
-  library: "16.0.0-beta.9",
+  library: "16.0.0",
   adcp: "3.2.5",
   compatibleVersions: COMPATIBLE_ADCP_VERSIONS,
-  generatedAt: "2026-10-19T19:41:05.601Z"
+  generatedAt: "2026-10-19T23:27:30.750Z"
 };
 function getAdcpVersion() {
   return ADCP_VERSION;

package/dist/lib/version.mjs

@@ -1,4 +1,4 @@
-const LIBRARY_VERSION = "16.0.0-beta.9";
+const LIBRARY_VERSION = "16.0.0";
 const ADCP_VERSION = "3.2.5";
 const ADCP_MAJOR_VERSION = 3;
 const COMPATIBLE_ADCP_VERSIONS = [
@@ -69,10 +69,10 @@ const COMPATIBLE_ADCP_VERSIONS = [
   "3.2.5"
 ];
 const VERSION_INFO = {
-  library: "16.0.0-beta.9",
+  library: "16.0.0",
   adcp: "3.2.5",
   compatibleVersions: COMPATIBLE_ADCP_VERSIONS,
-  generatedAt: "2026-10-19T19:41:05.601Z"
+  generatedAt: "2026-10-19T23:27:30.750Z"
 };
 function getAdcpVersion() {
   return ADCP_VERSION;

package/docs/TYPE-SUMMARY.md

@@ -1,7 +1,7 @@
 # AdCP Type Summary
 
 > Generated at: 2026-10-19
-> @adcp/sdk v16.0.0-beta.9
+> @adcp/sdk v16.0.0
 
 Curated reference of the types that matter for using the AdCP client. For full generated types see `src/lib/types/tools.generated.ts` and `src/lib/types/core.generated.ts`.
 

package/docs/guides/CREATIVE-DELIVERY.md

@@ -124,7 +124,24 @@ await agent.syncCreatives(
 The same pure functions are available from the explicit
 `@adcp/sdk/v2/projection` migration subpath for composition outside a client call:
 `projectCreativeForDelivery()`, `projectMediaBuyCreativesForDelivery()`, and
-`projectSyncCreativesForDelivery()`. Capability resolution uses the client's
+`projectSyncCreativesForDelivery()`.
+
+When these helpers emit a legacy `format_id`, they also map assets to the
+definition's `asset_id` keys. Definitions come from the bundled reference
+catalog, or from an optional final `legacyFormatDefinitions` array supplied to
+any of the three helpers. Caller definitions take precedence and must match
+both the format agent URL and ID. No network lookup occurs during projection.
+
+Existing declared asset keys keep their values. Other assets move only to one
+unoccupied slot with the same `asset_type`; URL assets must also match
+`requirements.url_type`, and pixel trackers must match the slot's `event`.
+Custom tracker events also match `custom_event_name`. Definitions containing
+repeatable groups retain all asset keys; projection does not infer group membership.
+Unmatched assets, ambiguous matches, and assets competing for the same slot
+keep their original keys. Unknown definitions leave assets unchanged. Canonical
+delivery retains its asset keys, and projection never mutates the caller's data.
+
+Capability resolution uses the client's
 emitted wire release pin: AdCP 3.2+ is canonical by contract, 3.0 is legacy, and 3.1
 checks the explicit `media_buy.features.canonical_creatives` declaration. A
 3.1 peer without the feature is deliberately

package/docs/guides/REPORTING-STABILITY.md

@@ -44,7 +44,7 @@ If you are unsure about a symbol, read its TSDoc. An `@experimental` tag means i
 
 ## How the two packages line up
 
-`@adcp/reporting-storage` declares `@adcp/sdk` as a **peer dependency** (`^16.0.0-beta.0` while SDK 16 is in beta), not a dependency. The store, its errors and the handlers share types and symbol-keyed guards, so the host must hold one copy of `@adcp/sdk`. A change to a storage interface in the SDK ships with a matching storage release; the changeset for each says which pair to install. The cloud SDKs (`@aws-sdk/client-s3`, `@azure/storage-blob`, `@google-cloud/storage`) are optional peers of the storage package. `@adcp/sdk` does not import `@adcp/reporting-storage`, and a test and a lint rule keep it that way.
+`@adcp/reporting-storage` declares `@adcp/sdk` as a **peer dependency** (`^16.0.0` for SDK 16), not a dependency. The store, its errors and the handlers share types and symbol-keyed guards, so the host must hold one copy of `@adcp/sdk`. A change to a storage interface in the SDK ships with a matching storage release; the changeset for each says which pair to install. The cloud SDKs (`@aws-sdk/client-s3`, `@azure/storage-blob`, `@google-cloud/storage`) are optional peers of the storage package. `@adcp/sdk` does not import `@adcp/reporting-storage`, and a test and a lint rule keep it that way.
 
 ## How to pin
 
@@ -53,19 +53,19 @@ Pin the storage package with a tilde range. A caret range on a `0.x` version alr
 ```json
 {
   "dependencies": {
-    "@adcp/sdk": "^16.0.0-beta.0",
-    "@adcp/reporting-storage": "~0.1.0-beta.0"
+    "@adcp/sdk": "^16.0.0",
+    "@adcp/reporting-storage": "~0.1.0"
   }
 }
 ```
 
-Those are the beta pins. A prerelease range such as `~0.1.0` does not match `0.1.0-beta.0`, so use the `-beta.0` form until stable releases exist, then move to `^16.0.0` and `~0.1.0`.
+These pins select SDK 16 and storage 0.1 stable versions. A stable range such as `~0.1.0` does not match `0.1.0-beta.0`; migrate both packages from their beta pins together.
 
-- `~0.1.0` (after the first stable release) takes patches only (recommended).
-- An exact version (`"0.1.0-beta.0"`) is stricter still.
+- `~0.1.0` takes patches only (recommended).
+- An exact version (`"0.1.0"`) is stricter still.
 - Read the changelog before widening to a new minor, and apply any migration it names.
 
-`@adcp/sdk` itself can use a caret range as usual, because the SDK's own surface follows semver. While SDK 16 is in beta, install both packages with the `beta` dist-tag (`npm install @adcp/sdk@beta @adcp/reporting-storage@beta`) until stable releases exist.
+`@adcp/sdk` itself can use a caret range as usual, because the SDK's own surface follows semver. Install the stable pair with `npm install @adcp/sdk@^16.0.0 @adcp/reporting-storage@~0.1.0`. The storage API remains experimental under the policy above.
 
 ## Migrations
 

package/docs/llms.txt

@@ -1,7 +1,7 @@
 # Ad Context Protocol (AdCP)
 
 > Generated at: 2026-10-19
-> Library: @adcp/sdk v16.0.0-beta.9
+> Library: @adcp/sdk v16.0.0
 > AdCP major version: 3
 > Canonical URL: https://adcontextprotocol.github.io/adcp-client/llms.txt
 > Note: the `Library` stamp reflects the package.json version at doc-generation time. The narrative below describes the surface that lands on the next-published minor — including any 6.7 helpers documented here ahead of the release tag.
@@ -13,7 +13,7 @@ AdCP is an open protocol for AI agents to buy, manage, and optimize advertising
 
 ## Start here: AdCP 3.2
 
-The SDK requires Node.js `^20.19.0 || >=22.12.0`. Install this reference's release train with `npm install @adcp/sdk@beta`; use the documentation from the exact published SDK version you install. For reproducible CLI runs, pin that exact SDK version. After installation, `node -p "require('@adcp/sdk').ADCP_VERSION"` reports its protocol pin; `ls node_modules/@adcp/sdk/compliance/cache` lists its packaged compliance versions. The legacy `adcp-3.2` npm tag selects SDK 14 and does not receive the refreshed compliance caches.
+The SDK requires Node.js `^20.19.0 || >=22.12.0`. Install this reference's release train with `npm install @adcp/sdk@16.0`; use the documentation from the exact published SDK version you install. For reproducible CLI runs, pin that exact SDK version. After installation, `node -p "require('@adcp/sdk').ADCP_VERSION"` reports its protocol pin; `ls node_modules/@adcp/sdk/compliance/cache` lists its packaged compliance versions. The legacy `adcp-3.2` npm tag selects SDK 14 and does not receive the refreshed compliance caches.
 
 The SDK is compact-lifecycle first: `list_products → buy_products → control_media_buy`, with `request_proposals → refine_proposals → accept_proposal` when terms need negotiation.
 

package/docs/migration-14.x-rc-worksheet.md

@@ -16,8 +16,8 @@ pin using `ADCP_VERSION` inside that tarball.
 
 | Fact | Value |
 | --- | --- |
-| Checkout `package.json` version | `@adcp/sdk@16.0.0-beta.9` |
-| npm integrity | registry-derived after publication; run `npm view @adcp/sdk@16.0.0-beta.9 dist.integrity` |
+| Checkout `package.json` version | `@adcp/sdk@16.0.0` |
+| npm integrity | registry-derived after publication; run `npm view @adcp/sdk@16.0.0 dist.integrity` |
 | Node.js runtime | `^20.19.0 || >=22.12.0` |
 | Default AdCP wire release | `3.2.5` |
 | Maintained wire releases | `v3`, `3.0.0`, `3.0`, `3.0.1`, `3.0.2`, `3.0.3`, `3.0.4`, `3.0.5`, `3.0.6`, `3.0.7`, `3.0.8`, `3.0.9`, `3.0.10`, `3.0.11`, `3.0.12`, `3.0.13`, `3.0.14`, `3.0.15`, `3.0.16`, `3.0.17`, `3.0.18`, `3.0.19`, `3.0.20`, `3.0.21`, `3.0.22`, `3.0.23`, `3.0.24`, `3.0.25`, `3.1.0`, `3.1`, `3.1.1`, `3.1.2`, `3.1.3`, `3.1.4`, `3.1.5`, `3.1.6`, `3.1.7`, `3.1.8`, `3.1.9`, `3.1.10`, `3.1.11`, `3.1.12`, `3.1.13`, `3.1.14`, `3.1.15`, `3.1.16`, `3.1.17`, `3.1.18`, `3.1.19`, `3.1.20`, `3.1.21`, `3.1.22`, `3.1.23`, `3.1.24`, `3.1.25`, `3.1.26`, `3.1.27`, `3.1.28`, `3.1.29`, `3.2.1`, `3.2`, `3.2.2`, `3.2.3`, `3.2.4`, `3.2.5` |
@@ -26,8 +26,8 @@ pin using `ADCP_VERSION` inside that tarball.
 For a checkout at the published release commit, install the exact package version:
 
 ```bash
-npm install --save-exact '@adcp/sdk@16.0.0-beta.9'
-npm view '@adcp/sdk@16.0.0-beta.9' dist.integrity
+npm install --save-exact '@adcp/sdk@16.0.0'
+npm view '@adcp/sdk@16.0.0' dist.integrity
 ```
 
 ### Required and optional peers

package/docs/migration-agent-identity-3.3.md

@@ -3,7 +3,7 @@
 The experimental identity rollout is tracked in
 [adcp-client#3233](https://github.com/adcontextprotocol/adcp-client/issues/3233).
 This release implements the rollout behind explicit experimental configuration.
-The SDK's default `ADCP_VERSION` remains **3.2.4**. Experimental client/server
+The SDK's default `ADCP_VERSION` remains **3.2.5**. Experimental client/server
 instances select the 3.3 carrier and apply the pinned draft overlays to the
 released bundle; they do not regenerate or replace the public 3.2 types.
 Upstream PRs remain open, so the experiment can change before graduation.
@@ -126,18 +126,42 @@ final UTF-8 body, covers the selected `Signature-Agent` member and digest,
 uses a fresh 64-byte nonce, and refuses automatic HTTP redirects. A request
 carries exactly one `web-bot-auth` signature and one `Signature-Agent` member:
 relays were removed from the profile, `signWebBotAuth` throws on `relay: true`
-and on a request that already carries signature fields, and the verifier
-answers a second signature (of any profile) or a second `Signature-Agent`
-member with 403. Signing keys are Ed25519 or RSA-PSS-SHA512 (2048 to 4096
-bits, e = 65537); ES256 stays on the AdCP RFC 9421 profile, and
+and on a request that already carries signature fields. The verifier reads
+only the `Signature-Input` member tagged `web-bot-auth` and ignores members
+with other tags, such as a CDN's own signature. It answers a second
+`web-bot-auth` signature or a second `Signature-Agent` member with 403.
+Signing keys are Ed25519 only; ES256 stays on the AdCP RFC 9421 profile, and
 `createWebBotAuthFetch`, `createWebhookEmitter` and `createAdcpServer` refuse
-a P-256 Web Bot Auth key at wire-up.
+a P-256 or RSA Web Bot Auth key at wire-up.
+
+This also changes two helpers outside the experiment. `verifySignature` and
+`verifySignatureAsync`, which `@adcp/sdk/signing/server` exports, no longer
+verify `rsa-pss-sha512`: they return `false` for it, as for any algorithm they
+don't support. Only Web Bot Auth used it, and the AdCP RFC 9421 profile allows
+only `ed25519` and `ecdsa-p256-sha256`. A caller that verifies RSA-PSS
+signatures with these helpers needs to verify them with `node:crypto` or
+WebCrypto instead.
+
+The covered `Signature-Agent` member must be exactly the canonical https origin
+string, compared as received: a lowercase host, no default port, and no path
+(not even `/`), query, fragment, or userinfo. Any other value, including an
+`http://` origin, is a 403 before any directory fetch. The signers apply the
+same rule: `signWebBotAuth`, `createSignedSignatureDirectory` and
+`createWebBotAuthFetch` canonicalize the agent origin they are given and throw a
+`TypeError` when it is not https, such as `http://localhost:3000`. There is no
+http opt-in. The member's `type`
+parameter is a Token (WBA section 5.2.1), and the verifier accepts
+`type=directory` as a Token or as a String. It ignores a member of any other
+type, which leaves no member to resolve (403).
 
 `SignatureDirectoryResolver` derives the directory from the covered canonical
 origin. Directories must be signed (WBA Appendix B.1): it validates a
-possession signature for every key, covering `"@authority";req` and
-`content-digest`, and the exact body digest before caching keys. An unsigned
-directory is a discovery failure. Its audit proof retains the signed body and
+possession signature for every key the profile can use, covering
+`"@authority";req` and `content-digest`, and the exact body digest before
+caching keys. It ignores keys the profile cannot use, such as a P-256 key, and
+any signature they made (RFC 7517 section 5). An unsigned directory, one
+with no usable key, or one that publishes private key material for any key,
+usable or not, is a discovery failure. Its audit proof retains the signed body and
 headers. Verification requires this resolver so context-free JWKS adapters cannot
 attribute a key to an arbitrary origin. Discovery uses HTTPS, DNS pinning, no redirects, a 256 KiB cap, a
 5-second connect bound and 10-second total bound, at most 64 keys, and bounded
@@ -155,8 +179,7 @@ Serve the exact JWS at `/.well-known/governance-revocations.json` and refresh it
 before `next_update` (the command defaults to five minutes). Pass `--snapshot`
 to sign a list of revoked key thumbprints and optional reasons/dates.
 `createSignedOriginRevocationList` provides the same authoring API. The SDK
-signs and verifies revocation lists with directory keys: EdDSA for Ed25519 keys
-and PS512 for RSA keys (a P-256 key cannot be published in a key directory). Observed key revocations are permanent;
+signs and verifies revocation lists with Ed25519 directory keys, as EdDSA. Observed key revocations are permanent;
 refresh failures use the last verified list only within the published grace
 window. Staleness follows the list's signed `next_update`, never the polling
 interval: the verifier re-polls at least every polling interval (at most 30
@@ -379,7 +402,7 @@ released schemas:
 
 | PR | Pinned head | Surface |
 | --- | --- | --- |
-| [7894](https://github.com/adcontextprotocol/adcp/pull/7894) | `e24eeb090c4365707641099cbbb45f9945c6d6e0` | WBA wire profile (`wba-profile.mdx`), profile selectors, directory and request vectors |
+| [7894](https://github.com/adcontextprotocol/adcp/pull/7894) | `e59294701d733b0ea2a004a2f0c091c8eccdcaae` | WBA wire profile (`wba-profile.mdx`), profile selectors, directory and request vectors |
 | [8121](https://github.com/adcontextprotocol/adcp/pull/8121) | `f5973ac0267b1b94d714c55fc4e3ad8fc2511350` | Origin identity and key-free trust v1 |
 | [8162](https://github.com/adcontextprotocol/adcp/pull/8162) | `5c9914c5c382cc32f3d2ad7842942e548c414705` | Ratified identity, coexistence, revocation |
 | [8168](https://github.com/adcontextprotocol/adcp/pull/8168) | `45540941dfd61e80ab8a463f780cb147c82a32f0` | Relationship and principal response arms |
@@ -388,7 +411,9 @@ released schemas:
 | [8177](https://github.com/adcontextprotocol/adcp/pull/8177) | `b663f8e4235fe4276c73fb9bac6db491b2252bbf` | Reporting authentication omission |
 
 The vectors in `test/fixtures/wba-profile/` are byte-identical to #7894 at that
-head and are all graded except the governance-token vectors (see `PINNED.json`).
+head (see `PINNED.json`). Every vendored request and directory vector is
+graded, and the interop harness (adcontextprotocol/adcp#8298) grades
+`scenarios.json`.
 
 Verification runs in Cloudflare's `http-message-sig` (signature base, coverage,
 window, algorithm and cryptographic checks); the SDK adds the profile rules in
@@ -413,7 +438,7 @@ so verification can run in a CDN or middleware in front of the AdCP server.
   reason is logged, never sent. A 429 for local load shedding (directory fetch
   limiter, replay-store `rate_abuse`) carries `Retry-After` instead.
 - Every signed request carries `created`, `expires` (at most 300 seconds
-  later), `keyid`, `alg` (`ed25519` or `rsa-pss-sha512`) and a `nonce` of 64
+  later), `keyid`, `alg` (`ed25519`) and a `nonce` of 64
   bytes, unpadded Base64URL or canonical padded Base64 (Cloudflare's default).
   The former 16-byte floor is gone: a shorter nonce is a 403. Replay state is
   keyed on the nonce bytes, so the two encodings of one nonce collide.
@@ -454,14 +479,14 @@ so verification can run in a CDN or middleware in front of the AdCP server.
   back off on 429 or 503.
 - `@target-uri` and `@authority` are taken from the target URI as received
   (RFC 9421 §2.2.2), never canonicalized; canonical origins identify the signer
-  only. Ed25519 and RSA-PSS-SHA512 keys are supported; RSA-PSS uses WebCrypto
-  where the runtime has it, so it also works on Cloudflare workerd.
+  only. Web Bot Auth is Ed25519 only, and it also works on Cloudflare workerd.
   `test/fixtures/wba-interop/` holds fixtures verified in both directions against
   Cloudflare's `web-bot-auth`; they already used signed directories and are
   unchanged.
-The #7894 governance-token vectors are vendored but not graded: ratified R4
-keeps the RFC 9421 discovery chain for governance through 3.3, and the profile
-page leaves document signing to a separate decision. `PINNED.json` records this.
+#7894 drops the governance-token checks and the `governance/` vectors from the
+WBA profile. Governance moves to the AdCP layer under a separate R4 erratum,
+which moves JWS artifacts, governance included, to the identity's WBA key
+directory in 3.3. This change leaves the SDK's governance code as it is.
 The buyer default onboarding field is `profiles.adcp.onboarding`, matching the
 schema; the design's `record_profiles` wording names the schema definition.
 

package/docs/migration-reporting-storage-package.md

@@ -1,6 +1,6 @@
 # Reliable Reporting storage moved to `@adcp/reporting-storage`
 
-**Applies to:** SDK 16 beta. **Kind:** breaking, by design. There are no re-export shims: the moved subpaths are gone from `@adcp/sdk`.
+**Applies to:** SDK 16. **Kind:** breaking, by design. There are no re-export shims: the moved subpaths are gone from `@adcp/sdk`.
 
 The Reliable Reporting storage implementations now ship as their own package, `@adcp/reporting-storage`, on its own version line. `@adcp/sdk` keeps the protocol layer. If you import anything from `@adcp/sdk/reporting/gcs`, `/s3`, `/azure` or `/bigquery`, or the PostgreSQL store, row storage, managed delivery or notification activity from `@adcp/sdk/reporting/ledger`, or `createPostgresReliableReportingProductionService` from `@adcp/sdk/reporting/service`, change those imports. Nothing else changes on the wire, in the database schema, or in the ledger's behavior.
 
@@ -11,10 +11,10 @@ Why: storage keeps its own release cadence, as Auth.js, LangGraph and OpenTeleme
 1. Install the package next to the SDK. `@adcp/sdk` is a peer dependency of it, so the host keeps exactly one copy:
 
    ```bash
-   npm install @adcp/sdk@beta @adcp/reporting-storage@beta
+   npm install @adcp/sdk@^16.0.0 @adcp/reporting-storage@~0.1.0
    ```
 
-   Pin the storage package with `~` (`"@adcp/reporting-storage": "~0.1.0-beta.0"` while SDK 16 is in beta, `"~0.1.0"` after a stable release; a prerelease version is not matched by `~0.1.0`): it is pre-1.0 and every export is experimental. The cloud SDKs are optional peers of the new package, not of `@adcp/sdk` any more, so keep `@aws-sdk/client-s3`, `@azure/storage-blob` and `@google-cloud/storage` in your own dependencies for the providers you use.
+   Pin the storage package with `~` (`"@adcp/reporting-storage": "~0.1.0"`; this stable range does not match the earlier `0.1.0-beta.0` prerelease): it is pre-1.0 and every export is experimental. The cloud SDKs are optional peers of the new package, not of `@adcp/sdk` any more, so keep `@aws-sdk/client-s3`, `@azure/storage-blob` and `@google-cloud/storage` in your own dependencies for the providers you use.
 
 2. Change the imports using the table below, then run `tsc --noEmit`. A moved name on `@adcp/sdk/reporting/ledger` or `/service` is `TS2305: Module '"@adcp/sdk/reporting/ledger"' has no exported member 'PostgresReportingLedgerStore'`; a deleted subpath is `TS2307: Cannot find module '@adcp/sdk/reporting/gcs'`. At runtime the deleted subpaths fail with `ERR_PACKAGE_PATH_NOT_EXPORTED`, and a stale CommonJS `require` of a moved name on a kept subpath destructures to `undefined` and fails later as `X is not a constructor`, so grep JavaScript too (see [Self-grade](#self-grade)).
 

package/docs/releases/16.0.0.md

@@ -0,0 +1,20 @@
+# SDK 16.0.0
+
+SDK 16 is the stable AdCP 3.2 release line. Its default protocol pin is **3.2.5**, with maintained AdCP 3.0 and 3.1 compatibility. Install it with `npm install @adcp/sdk@^16.0.0`.
+
+## Upgrade from SDK 15
+
+- **AdCP 2 support is removed.** Sellers must support AdCP 3 capability discovery. Retired adapters, types, schema bundles and `allowV2` configuration are removed. See the [AdCP 2 retirement guide](../migration-drop-adcp-2.md).
+- **Reliable Reporting storage has its own package.** Install `@adcp/reporting-storage@~0.1.0` alongside the SDK and update the moved imports. The storage package remains experimental and pre-1.0 even though SDK 16 is stable. See the [package migration](../migration-reporting-storage-package.md) and [stability policy](../guides/REPORTING-STABILITY.md).
+- **Reporting row storage uses the protocol field names and source-timezone period dates.** Apply the migration and update custom object providers as described in the [row storage alignment guide](../migration-reporting-row-storage-alignment.md). Re-apply the warehouse sink migration when upgrading existing BigQuery sinks; see the [SDK changelog](https://github.com/adcontextprotocol/adcp-client/blob/main/CHANGELOG.md#1600).
+- **Compliance notice codes use the canonical names.** Replace `request_signing.required` with `request_signing_required_in_4_0` and `webhook_signing.legacy_hmac_fallback.removed` with `legacy_hmac_fallback_removed_in_4_0` in comparisons and dashboard keys.
+
+The [changelog](https://github.com/adcontextprotocol/adcp-client/blob/main/CHANGELOG.md#1600) includes the complete SDK 16 changes, including creative wire selection, account sync, property-list workflows and reporting fixes. Use the [release-bound upgrade worksheet](../migration-14.x-rc-worksheet.md) to check the exact package, runtime, peers and protocol bundle.
+
+SDK 16.0.0 also includes [#3350](https://github.com/adcontextprotocol/adcp-client/pull/3350): legacy creative delivery maps asset keys to the selected format's declared asset IDs, including image, click URL and tracker slots, while preserving occupied or ambiguous keys. See [creative delivery](../guides/CREATIVE-DELIVERY.md).
+
+## AdCP 3.3 preview
+
+The explicit `@adcp/sdk/identity-3.3` opt-in remains experimental. Promoting SDK 16 does not graduate that API or change the default wire pin to AdCP 3.3. See the [experimental identity guide](../migration-agent-identity-3.3.md).
+
+SDK 17 beta is the next release line for adopting the published AdCP 3.3 beta bundle. SDK 16 stays on AdCP 3.2 while that work proceeds. The `latest` channel stays on stable releases and `beta` carries the SDK 17 previews; a preview is published only once its protocol bundle is available and its integration passes validation.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@adcp/sdk",
-  "version": "16.0.0-beta.9",
+  "version": "16.0.0",
   "description": "AdCP SDK — client, server, and compliance harnesses for the AdContext Protocol (MCP + A2A)",
   "workspaces": [
     ".",