@adcp/sdk 16.0.0-beta.8 → 16.0.0

package/dist/lib/version.js

@@ -31,12 +31,10 @@ __export(version_exports, {
   toReleasePrecisionVersion: () => toReleasePrecisionVersion
 });
 module.exports = __toCommonJS(version_exports);
-const LIBRARY_VERSION = "16.0.0-beta.8";
+const LIBRARY_VERSION = "16.0.0";
 const ADCP_VERSION = "3.2.5";
 const ADCP_MAJOR_VERSION = 3;
 const COMPATIBLE_ADCP_VERSIONS = [
-  "v2.5",
-  "v2.6",
   "v3",
   "3.0.0",
   "3.0",
@@ -104,10 +102,10 @@ const COMPATIBLE_ADCP_VERSIONS = [
   "3.2.5"
 ];
 const VERSION_INFO = {
-  library: "16.0.0-beta.8",
+  library: "16.0.0",
   adcp: "3.2.5",
   compatibleVersions: COMPATIBLE_ADCP_VERSIONS,
-  generatedAt: "2026-10-18T01:21:23.594Z"
+  generatedAt: "2026-10-19T23:27:30.750Z"
 };
 function getAdcpVersion() {
   return ADCP_VERSION;

package/dist/lib/version.mjs

@@ -1,9 +1,7 @@
-const LIBRARY_VERSION = "16.0.0-beta.8";
+const LIBRARY_VERSION = "16.0.0";
 const ADCP_VERSION = "3.2.5";
 const ADCP_MAJOR_VERSION = 3;
 const COMPATIBLE_ADCP_VERSIONS = [
-  "v2.5",
-  "v2.6",
   "v3",
   "3.0.0",
   "3.0",
@@ -71,10 +69,10 @@ const COMPATIBLE_ADCP_VERSIONS = [
   "3.2.5"
 ];
 const VERSION_INFO = {
-  library: "16.0.0-beta.8",
+  library: "16.0.0",
   adcp: "3.2.5",
   compatibleVersions: COMPATIBLE_ADCP_VERSIONS,
-  generatedAt: "2026-10-18T01:21:23.594Z"
+  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-18
-> @adcp/sdk v16.0.0-beta.8
+> Generated at: 2026-10-19
+> @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/development/PROTOCOL_DIFFERENCES.md

@@ -333,4 +333,4 @@ Look for messages like:
 - [MCP Specification](https://spec.modelcontextprotocol.io)
 - [A2A Protocol Documentation](https://github.com/AgentProtocol/A2A)
 - [AdCP Specification](https://github.com/adcontextprotocol/adcp)
-- [Wire-version compat playbook](https://adcontextprotocol.github.io/adcp-client/development/WIRE-VERSION-COMPAT.md) — orthogonal but commonly conflated with transport differences. Read this if you're touching how the SDK adapts requests/responses across AdCP major versions (v3 ↔ v2.5), not just MCP vs A2A.
+- [Wire-version compat playbook](https://adcontextprotocol.github.io/adcp-client/development/WIRE-VERSION-COMPAT.md) — orthogonal but commonly conflated with transport differences. Read this when adapting requests/responses across maintained AdCP 3 releases. AdCP 2 wire translation was [removed in SDK 16](../migration-drop-adcp-2.md); transport differences remain independent of the selected AdCP release.

package/docs/guides/CONFORMANCE.md

@@ -282,6 +282,31 @@ provenance manifest first. Resolve the release tag to its full commit, then use
 file and verify the release bundle's `.tgz.sha256` sidecar before updating the
 manifest. The command never accepts moving branches or unverified content.
 
+## Property-list reference credential isolation
+
+The storyboard runner implements `check: property_list_reference` and the
+`property_list_reference_runner` requirement for MCP. The protocol-authored
+`universal/property-list-reference-resolution` storyboard creates a shared list
+and a control list under the owner identity. Its probe then starts a fresh MCP
+session with only the issued reference Bearer token, follows every page, checks
+the exact identifier set, and requires authorization denials for a cross-list
+read and a name-changing update. Owner credentials, accounts, cookies, and
+signing keys are never forwarded into that session. The check needs no extra
+runner configuration beyond the storyboard's sandbox/controller setup.
+It uses the MCP endpoint already discovered by the owner client, with a fresh
+transport that does not inherit the owner's `transport.trustedFetchFn`.
+
+Evidence includes initialization, each page, and both denial probes; issued
+tokens are redacted from creation responses and diagnostic strings. Explicit
+A2A runs report `requirement_unmet` before fixture setup or task calls because
+the credential-isolated probe currently implements the MCP baseline.
+
+The storyboard is authored for the next AdCP minor release and is not in the
+bundled 3.2.5 compliance cache. Until that release, load its YAML from a local
+copy of spec PR #8289 and use `runStoryboard` with that checkout's schema root.
+
+Upstream contract: [adcp#8289](https://github.com/adcontextprotocol/adcp/pull/8289).
+
 ## Trusted Match Context router replay
 
 Context Match routers expose raw `POST /context`, not an MCP or A2A tool. A

package/docs/guides/CREATIVE-BUILD-PROBE.md

@@ -0,0 +1,156 @@
+# Creative evaluator build probes
+
+A storyboard may opt into `creative_build_probe: {context_prefix: build,
+message: "Create one sandbox creative"}`. The full runner and standalone step
+runner prepare one route/input binding before controller seeding or dispatch,
+and then enable `creative_build_probe_runner`. Author the gated steps with
+`requires_contract: creative_build_probe_runner` so older engines give no
+executed security credit.
+
+Provision the sandbox account, build entitlement, task authorization, and
+accepted evaluator endpoint separately. Complete format metadata does not prove
+these account/task prerequisites. The resolver does not issue a hidden build.
+
+`test_kit.creative_build_probes` accepts recipes `{match: [...], input: {...}}`.
+Match clauses use the existing fixture-resolution DSL against the catalog entry.
+The operator asserts that the input is valid for **every** matched route for this
+account. Input can contain message, creative_manifest, creative_id, transformer_id,
+config and legacy target_format_id; it cannot replace evaluator, account, auth or trust material. Use a
+specific capability-ID predicate when a kind-only predicate is insufficient.
+Full manifest schema validation runs before dispatch. Config requires a transformer;
+provision its live parameter values and an appropriate output route. Library IDs,
+transformers, source asset URLs, and account authorization are operator fixtures.
+
+The automatic generation path requires a unique advertised build route,
+supports_generation, technical_requirements_complete, a known non-custom kind,
+empty params, and no unhandled declaration metadata (descriptive identity/preference/channel metadata is inert).
+It supplies the brief and `{format_kind: selectedKind, assets: {}}`. Otherwise a
+matched recipe is required; omitted catalog operations still mean build and
+missing catalog IDs remain discoverable but unaddressable through capability-ID routing. Non-build entries and
+unsatisfiable routes do not prevent selecting a later satisfiable route.
+
+Resolved records use fixture_type `creative_format`, the prefix as handle, exact
+matched requirements, and seller_ids.capability_id or seller_ids.format_id. Unsatisfied whole runs have a
+fixture_unsatisfied coverage gap and zero executed security validations; standalone
+steps use skip_reason fixture_unsatisfied and canonical not_applicable, with detail
+naming creative_format:<prefix>. This does not establish producer nonconformance
+or passing security coverage. Malformed catalogs produce a structured failed validation; malformed operator recipes throw authoring errors during applicable preparation
+with the required schemas available. Unavailable catalog/schema prerequisites
+can return a zero-credit fixture gap before exhaustive recipe diagnostics. Routed and
+replicated runs currently report an explicit gap before seeding; run each agent
+independently. Unopted storyboards retain their existing behavior and counters.
+
+The protocol-side harness contract and consuming fixture are tracked in
+[adcp#8240](https://github.com/adcontextprotocol/adcp/issues/8240).
+
+## Payload-bound authorization limitation
+
+Current probe preparation requires a sandbox build fixture that does not need
+a per-request signed governance_context. The runner detects an advertised
+build_creative signed_context enforcement claim and reports fixture_unsatisfied
+with zero security credit; static recipes cannot pre-sign the fresh request.
+Other governed tasks do not disable this build probe. Preparing fresh governed
+probe authorizations is a separate runner integration, not a protocol decision.
+
+Recipe fields stay exactly as provisioned: omitting message does not add the
+storyboard's generation brief. The automatic source manifest is validated too.
+Descriptive metadata (display_name, seller_preference, experimental,
+sample_render_url, format_option_id, publisher_domain, applies_to_channels,
+canonical_formats_only) does not remove security coverage. Unknown metadata and
+constraint-bearing extensions require an operator recipe. The probe-local
+unambiguous-source/config rules do not add restrictions to build_creative wire
+requests in other modes, including refinement.
+
+Operator recipe authoring is bounded to 100,000 traversed nodes, 4 MiB of UTF-8
+string/key bytes, and the existing JSON depth bound per recipe. Repeated aliases
+count on every visit, before match normalization. These are harness configuration
+limits, not producer catalog requirements. Missing required selected-version
+validators yield a zero-credit harness gap; they never authorize a dispatch.
+
+
+## Selected-version routing
+
+The runner uses the existing guarded capabilities-echo authority for catalog
+interpretation. A same-major release-precision echo must be listed in the
+response's supported_versions and have an available bundled or supplied schema
+root. Invalid, missing, unlisted or unavailable echoes retain the pin. Supplied
+servedReleaseSchemaRoots apply to the catalog only. The runner captures build
+request, source-manifest and target-FormatID validators from the pin before
+activating any served catalog root, including overlapping version aliases.
+The public five-argument resolveCreativeBuildProbe works on an already selected
+creative catalog and uses its supplied pin only; it has no full capabilities
+response from which to select an echo. Full and standalone runners use the
+internal preparation path for guarded served-release selection.
+
+Catalog kind, parameter, ID and operation semantics follow that served release;
+build selectors and source inputs retain the request pin. Canonical route IDs
+and automatic generation require canonical routing in both releases. Otherwise
+use a provisioned legacy selector and pinned-valid input; do not synthesize a
+named format or upgrade the request. An advertised 3.2 legacy reference's density
+constraints still apply when a 3.1 request treats pixel_ratio as an opaque
+extension: the old request cannot establish a 2x parameterized binding by adding
+that field. An incompatible binding is a fixture gap, not producer failure.
+
+The reverse direction retains the older catalog's parameter rules. A 3.1
+reference cannot establish density through an omitted or opaque pixel_ratio
+field. Actual named-format requirements still apply: the published 3.1 narrowing
+rule uses an any-value baseline only where the projected legacy requirements
+impose no constraint. A provisioned, live-valid 3.2 target at 2x can
+therefore match a 3.1 reference with no ratio, even if the old payload carries
+an opaque ratio extension. The resolver does not union property sets or invent
+a 1x default for that older catalog. The operator must still provision a valid
+named-format mapping and input for the selected account.
+
+Local schema diagnostics display at most eight AJV error entries and 2048
+escaped characters. Control characters are escaped for display; producer
+catalogs and failed validation outcomes remain unchanged.
+
+Read the selected capabilities schema's format reference and selected build request
+selector. A 3.2 recipe normally binds the advertised capability ID; a provisioned legacy selector remains supported when the selected request declares it. A 3.1 recipe must supply
+an existing schema-valid `target_format_id` and assert that its discovered or
+provisioned named format maps to every matched catalog route. The resolver never
+constructs a named format from a capability ID. Missing legacy capability IDs are
+legal. Without a provisioned legacy selector there is a coverage gap; an unknown
+extra `target_capability_id` is not a valid 3.1 routing contract. Automatic generation
+is restricted to capability-ID routing. Unknown 3.1 canonical kinds remain intact
+as unsupported routes while resolution continues to understood routes. Older
+catalogs do not acquire 3.2 ID-pattern or operations-field producer requirements.
+
+Transformer-only recipes need no dummy brief/source manifest. Provision valid live
+configuration and matching transformer output_capability_ids (3.2) or
+output_format_ids (legacy). Recipe messages are trusted operator-authored input and
+remain exactly as supplied; banning a brief would not prevent a dishonest fixture
+author from biasing other input content. Credential-key and URL checks reject known
+aliases but cannot prove opaque values or custom encodings secret-free. Operators
+must provision non-secret fixture content. A malformed recipe throws an authoring
+error after the runner closes any receiver/connections it owns.
+
+
+An explicit legacy selector recipe is also supported on newer versions that retain
+`target_format_id`; bind exactly one selector. Recipes cannot override
+`canonical_formats_only: true` or contradict an advertised `v1_format_ref` pairing.
+Reference agent URLs use existing canonicalization, and declared dimensions/duration
+must agree. Incompatible pairs are unavailable; continue to another usable route.
+
+
+Resolution certifies preparation of the selected route/input, not complete catalog
+conformance. Unknown legacy kinds remain unvalidated local unsupported routes;
+the consuming storyboard must retain its required whole-response discovery schema
+validation. A standalone boundary step grades its selected probe, not unrelated
+catalog metadata. The evaluator storyboard keeps that independent required check.
+
+
+The provisioned brief is sent as `build_creative.message` to the agent under test,
+where its model may read it as instructions. Author ordinary creative direction;
+do not include instructions about evaluator behavior or expected test verdicts.
+An explicit runner `test_kit` overrides the storyboard's declared kit as a whole:
+include recipes in that override when also supplying auth. Hosted auth defaults
+preserve recipes explicitly supplied by the operator; they do not merge missing
+recipes from a separately declared brand kit.
+
+The normal hosted HTTP/UI flow does not expose arbitrary recipe uploads. Use trusted
+programmatic runner options or the local CLI for operator-provisioned recipes.
+
+The preparer checks the selected route/input binding. It does not certify all
+unselected recipe matches or remote account entitlements; narrow the operator
+match predicates when an input is valid for only one route.

package/docs/guides/CREATIVE-DELIVERY.md

@@ -124,16 +124,69 @@ 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
 `unknown` because a 3.1 version claim does not prove the runtime accepts
 canonical creatives. For MCP peers the client then inspects the advertised
 input schema for the current tool only; support advertised by another creative
-tool is never reused. Unknown peers receive a legacy projection only when the
-selected product provides one unambiguous ref. Ambiguous or unavailable mappings throw
-`CreativeFormatProjectionError` before transport.
+tool is never reused.
+
+For a seller proven to serve AdCP 3.1, an otherwise unknown write uses canonical
+delivery when every selected option and creative is covered by the seller's own
+`format_options`. This follows the 3.1 buyer rule to prefer advertised format
+options over dual-emitted legacy IDs. Creative option references and kinds must
+match, including declared slots and dimensions. Sync assignments must all have
+matching selector containers. Explicit legacy capabilities or tool schemas take
+precedence; experimental declarations and options synthesized by the SDK from
+legacy IDs do not establish canonical support. This also works when a 3.2 buyer
+negotiates down to a 3.1 seller.
+
+Supply the selected product or the result of `packageRefsForFormatOptions()` in
+`creativeFormatProjection.selectorContainers`. Include `package_id` when using
+assignments. After serializing a selection, include `product_id` so the same
+client can recover the seller declaration from account-scoped product discovery,
+including product-cache hits. Product evidence applies to that request only.
+The seller remains responsible for full manifest validation.
+
+Canonical fallback requires affirmative evidence from this client's product
+discovery and an advertised `supported_versions` entry proving the seller serves
+3.1. The fallback uses synchronous discovery and successful conditional catalog
+revalidation. A saved product on a fresh client, including one synthesized from
+legacy IDs, cannot establish support by its shape alone. Rediscover the product
+in the current account and authorization scope first. Evidence expires after
+the discovery TTL (five minutes by default); product-cache hits do not extend
+it. Authorization changes and discovery invalidation invalidate the evidence.
+Request-scoped custom transports require explicit capability or tool-schema
+support and do not reuse this inferred product evidence.
+
+Assignment-only sync and updates containing only an existing `package_id` keep
+their existing wire behavior. Pass the matching selectors for this request to
+use the product-based fallback; package IDs alone do not establish support.
+Without assignments, each creative must match every supplied container; use
+assignments or split mixed-format batches when the products accept different kinds.
+
+Without matching product evidence, unknown peers receive a legacy projection
+only when the selected product provides one unambiguous ref. Ambiguous or
+unavailable mappings throw `CreativeFormatProjectionError` before transport.
 
 Schema inspection follows local JSON Pointer `$ref` targets, including `$defs`,
 and retains the complete listed document through shared discovery-cache reuse.
@@ -141,7 +194,7 @@ Unused definitions and annotations do not establish support. External references
 named anchors, and dynamic references are not resolved; inspection never fetches
 schema URLs. Cycles and traversal limits cannot force a guessed wire mode.
 
-Before building creatives, ask the client which mode that write will use:
+Before building creatives, inspect the tool's wire evidence:
 
 ```ts
 const mode = await agent.resolveCreativeFormatWireMode('sync_creatives');
@@ -150,13 +203,16 @@ const mode = await agent.resolveCreativeFormatWireMode('sync_creatives');
 This method is available on `AgentClient` and `SingleAgentClient`, accepts
 `sync_creatives`, `create_media_buy`, or `update_media_buy`, and shares the
 write path's capability discovery, tool-schema fallback, and buyer wire pin.
+This context-free check does not inspect a write's product options, so an
+`unknown` result can still become canonical for a matching 3.1 write as described
+above.
 It reuses fresh cached or primed evidence; cold discovery may make read calls,
 but it sends no mutation. Pass `{ signal, transport }` as the optional second
 argument to use the same cancellation and transport scope as the write.
 
 The result is `canonical`, `legacy`, or `unknown` (`CreativeFormatWireMode`).
-For older peers with insufficient evidence, `unknown` means projection still
-requires one unambiguous legacy reference. It does not promise canonical
+For older peers without matching product evidence, `unknown` means projection
+still requires one unambiguous legacy reference. It does not promise canonical
 support. Conflicting capability/schema evidence or missing release proof with
 a 3.2+ buyer pin throws `CreativeFormatCapabilityError`, as during a write.
 The standalone `resolveCreativeFormatWireMode(capabilities, version)` helper

package/docs/guides/MEDIA-BUY-3.2-COMPATIBILITY.md

@@ -280,7 +280,7 @@ authoritative completion reconciliation after restart.
 
 ### Tokenless catalog and products-only legacy continuations
 
-An established 2.5, 3.0, or 3.1 seller may return purchasable catalog products
+An established 3.0 or 3.1 seller may return purchasable catalog products
 without a wholesale feed token, or answer a brief with products but no
 proposal. The SDK never invents a proposal, terms digest, or feed fence. When
 `principalScope`, an account, and stable seller-session binding are available,
@@ -301,7 +301,7 @@ invocation receives a fresh continuation even when the catalog is unchanged:
 const continuations = createInMemoryLegacyPurchaseContinuationStore();
 const lifecycle = await agent.negotiateMediaBuyLifecycle({
   principalScope: authenticatedPrincipalId,
-  // Required for established 2.5, 3.0, and 3.1 sellers that provide no server
+  // Required for established 3.0 and 3.1 sellers that provide no server
   // context ID. Persist this non-secret authenticated session ID across rehydration.
   legacyPurchaseSellerSessionScope: authenticatedSellerSessionId,
   legacyPurchaseContinuationStore: continuations,
@@ -331,9 +331,9 @@ after accepting the exact returned loss set. If the application requires an
 enforceable observed catalog/pricing fence, do not accept the continuation;
 the tokenless catalog is read-only for that policy.
 
-On 2.5 the loss set also includes `mutation_idempotency_not_guaranteed`. On 3.0
-and 3.1 it includes that loss whenever the seller does not advertise a usable
-replay TTL. All tokenless catalog continuations include
+On 3.0 and 3.1 the loss set includes `mutation_idempotency_not_guaranteed`
+whenever the seller does not advertise a usable replay TTL. All tokenless
+catalog continuations include
 `feed_version_not_atomic` and `pricing_version_not_atomic`.
 
 The in-memory store is a single-process reference implementation. Production
@@ -462,13 +462,12 @@ issued. It must be a stable, non-secret ID derived by the application from the
 authenticated seller/account session—not a bearer token. Persist and reuse it
 with the continuation store so a restarted coordinator can redeem or replay
 the same operation without making the token portable to another credentialed
-session. This applies to 2.5, 3.0, and 3.1; endpoint identity is not an
+session. This applies to 3.0 and 3.1; endpoint identity is not an
 authenticated session identity. URL userinfo and presigned URLs are rejected
 before the discovered payload can enter durable storage.
 
-Every 2.5 continuation declares `mutation_idempotency_not_guaranteed`.
-3.0/3.1 continuations declare the same loss whenever the seller does not
-advertise a usable replay TTL; accepting an idempotency key alone is not treated
+3.0/3.1 continuations declare `mutation_idempotency_not_guaranteed` whenever
+the seller does not advertise a usable replay TTL; accepting an idempotency key alone is not treated
 as evidence that a mutation can be replayed safely. Submitted completions are
 accepted only for the exact seller task ID recorded at dispatch. Unstructured
 or SDK-synthetic terminal errors remain ambiguous and retain the durable fence.
@@ -584,15 +583,17 @@ mutating prior state.
 
 ## Buyer projection policy
 
+All compatibility lanes require AdCP 3. AdCP 2 agents are rejected during discovery before a coordinator operation can dispatch; see the [AdCP 2 retirement guide](../migration-drop-adcp-2.md).
+
 | Coordinator operation | Compact tool | Established projection | Boundary |
 |---|---|---|---|
-| `listProducts` | `list_products` | `get_products(buying_mode='wholesale')` | Representable `criteria.offer_filters` map field-by-field through the negotiated legacy offer-filter schema; country remains `filters.countries` and is never recast as delivery targeting. Other structured criteria report their exact unsupported field before dispatch. Actual `wholesale_feed_version` is renamed to `feed_version`; no value is invented. An eligible tokenless catalog may expose the SDK-local `purchase_continuation` described above while `raw` remains the canonical SDK source object. The stable response exposes `next_cursor` and `unchanged` in both lanes. The established request includes `pagination` only when the caller supplies a cursor or `max_results`; the SDK does not fabricate a page-size default. v2.5 pagination/field selection, pre-3.1 conditional feed/pricing reads, and response-field names absent from the negotiated enum are typed unsupported. |
+| `listProducts` | `list_products` | `get_products(buying_mode='wholesale')` | Representable `criteria.offer_filters` map field-by-field through the negotiated legacy offer-filter schema; country remains `filters.countries` and is never recast as delivery targeting. Other structured criteria report their exact unsupported field before dispatch. Actual `wholesale_feed_version` is renamed to `feed_version`; no value is invented. An eligible tokenless catalog may expose the SDK-local `purchase_continuation` described above while `raw` remains the canonical SDK source object. The stable response exposes `next_cursor` and `unchanged` in both lanes. The established request includes `pagination` only when the caller supplies a cursor or `max_results`; the SDK does not fabricate a page-size default. Pre-3.1 conditional feed/pricing reads and response-field names absent from the negotiated enum are typed unsupported. |
 | `requestProposals` | `request_proposals` | `get_products(buying_mode='brief')` | Only offer-filter fields and metric values defined by the negotiated release map field-by-field, plus policy IDs. Compact catalog selection lacks the complete legacy catalog metadata and fails closed. Targeting-overlay requirements are forwarded only to a 3.2 established surface; 3.0/3.1 cannot represent them. Product-ID filters, compact-only offer prerequisites, `ext`, opportunity, and governance context fail preflight. |
 | `refineProposals` | `refine_proposals` | `get_products(buying_mode='refine')` | Ask and product include/omit map for revisions. Finalize maps only when it contains no additional refinement fields. Hard constraints, alternatives, criteria, amendment kinds, and finalize extras fail before dispatch. |
 | `declineProposals` | `decline_proposals` | proposal-scoped legacy omit | Rejected by default because omit is not a terminal decline and cannot carry the required compact reason/detail. Explicit opt-in reports `proposal_decline_not_terminal` and `proposal_decline_reason_not_forwarded`. |
-| `buyProducts` | `buy_products` | `create_media_buy` | Feed/pricing fencing is not atomic. Rejected by default; explicit opt-in names `feed_version_not_atomic` and, when present, `pricing_version_not_atomic`. A missing `feed_version` remains unsupported here; tokenless catalogs use the separate SDK-local `continueLegacyPurchase()` handoff. Shared package fields and nested targeting/reporting enums map against the negotiated schema, including 3.1+ `format_option_refs`; newer targeting, metric, and postal shapes fail closed. v2.5 also rejects non-empty compact targeting and push notification configuration. A direct compact `total_budget` and fields introduced on the 3.2 established surface—including allocation, budget-cap, bidding, governance, opportunity, and newer package controls—map only on a negotiated 3.2 established lane. Compact `catalog_ids` and resolved `pricing` remain typed unsupported. |
+| `buyProducts` | `buy_products` | `create_media_buy` | Feed/pricing fencing is not atomic. Rejected by default; explicit opt-in names `feed_version_not_atomic` and, when present, `pricing_version_not_atomic`. A missing `feed_version` remains unsupported here; tokenless catalogs use the separate SDK-local `continueLegacyPurchase()` handoff. Shared package fields and nested targeting/reporting enums map against the negotiated schema, including 3.1+ `format_option_refs`; newer targeting, metric, and postal shapes fail closed. A direct compact `total_budget` and fields introduced on the 3.2 established surface—including allocation, budget-cap, bidding, governance, opportunity, and newer package controls—map only on a negotiated 3.2 established lane. Compact `catalog_ids` and resolved `pricing` remain typed unsupported. |
 | `acceptProposal` | `accept_proposal` | `create_media_buy(proposal_id=...)` | A compact-shaped proposal retains strict digest, immutable-snapshot, account-scope, kind/status, and expiry checks. Caller values cannot override digest-bound budget, budget-cap, timezone, or purchase-order terms. An honest 3.0/3.1 proposal remains executable with its ordinary `proposal_id` semantics only after explicit opt-in to `proposal_terms_digest_not_enforced`, `proposal_terms_digest_unavailable`, and `proposal_snapshot_not_immutable` (plus `proposal_hold_not_verifiable` when it has no expiry). The caller supplies the original brand/flight as `established_fallback`; the SDK does not claim those values came from the seller or synthesize a digest. |
-| `controlMediaBuy` | `control_media_buy` | `update_media_buy` | Account, media-buy ID, and a positive revision are required. Revision and identically shaped fields present in the negotiated established schema map directly; `name` maps on the 3.2 established surface and fails closed on 3.0/3.1, whose update schemas do not define it. v2.5 requires explicit `revision_not_atomic` opt-in and rejects cancellation plus v3-only package controls. Pre-3.2 lanes reject the broader compact optimization-goal union and nested targeting/keyword shapes they cannot represent. Compact `catalog_ids` cannot be cast to established `catalogs` objects, so it fails closed in every established lane. |
+| `controlMediaBuy` | `control_media_buy` | `update_media_buy` | Account, media-buy ID, and a positive revision are required. Revision and identically shaped fields present in the negotiated established schema map directly; `name` maps on the 3.2 established surface and fails closed on 3.0/3.1, whose update schemas do not define it. Pre-3.2 lanes reject the broader compact optimization-goal union and nested targeting/keyword shapes they cannot represent. Compact `catalog_ids` cannot be cast to established `catalogs` objects, so it fails closed in every established lane. |
 | Readback | shared tools | `get_media_buys`, `get_media_buy_delivery` | Same public calls and canonical creative projection in every lane. Versioned request additions fail closed: webhook-activity and delivery-window/granularity options require 3.1+, while `indicator_types`, demographic breakdowns, and spot breakdowns require 3.2. Native postal reporting shapes require 3.1+. |
 
 Lossy mutations are fail-closed. An adopter may opt into only the exact named
@@ -735,8 +736,7 @@ trusted namespaces, never a buyer-supplied proposal ID alone.
 
 | Buyer surface | Seller surface | Expected path | Guarantee |
 |---|---|---|---|
-| Established `getProducts` / `createMediaBuy` / `updateMediaBuy` | AdCP 2.5–3.1 or a dual-surface 3.2 seller | Established tools are called directly | Existing application behavior remains unchanged; the compact coordinator is not involved. |
-| Compact-first coordinator | AdCP 2.5 | `list_products` → `get_products`; purchase → `create_media_buy`; supported control → `update_media_buy` | The direct common subset remains usable. Proposal objects/binding, media-buy readback, pagination, cancellation, v3-only top-level/package fields, and update reporting-webhook changes are typed unsupported rather than sent into v2.5's permissive additional-properties boundary. Feed fencing and optimistic revision enforcement require their named loss opt-ins. |
+| Established `getProducts` / `createMediaBuy` / `updateMediaBuy` | AdCP 3.0/3.1 or a dual-surface 3.2 seller | Established tools are called directly | Existing application behavior remains unchanged; the compact coordinator is not involved. |
 | Compact-first coordinator | AdCP 3.0, 3.1, or 3.2 legacy-only | `list_products` → `get_products`; proposal discovery/refinement → `get_products`; control → `update_media_buy`; purchase → `create_media_buy` only when its named loss policy permits it | Common-subset reads and control are lossless. Atomic feed/pricing fencing, digest enforcement, and terminal decline are not representable and fail before mutation by default. |
 | Compact-first coordinator | AdCP 3.2 dual-surface | Compact tools are preferred; `preferredLifecycle: 'established'` exercises the compatibility facade | Native by default; the forced established lane has the same explicit boundaries as older sellers. |
 | Compact-first coordinator | AdCP 3.2 compact-only | Compact lifecycle tools | Native compact guarantees. |
@@ -749,7 +749,7 @@ that a 3.0 seller can enforce a 3.2-only atomicity or digest guarantee. The SDK
 must reject that case or report the exact explicitly accepted loss; it must
 never label the weaker mutation as equivalent.
 
-The coordinator test matrix covers SDK 14 compact-first callers against v2.5,
+The coordinator test matrix covers compact-first callers against
 3.0, 3.1, 3.2 legacy-only, 3.2 dual-surface (compact preferred and established
 forced), and 3.2 compact-only discovery. The dual-surface MCP lane also holds
 the maximum at 3.2 while defaulting unversioned discovery and dispatch to 3.1,
@@ -761,9 +761,6 @@ validating every request and response against the corresponding cached wire
 bundle. Those lanes assert canonical format projection, pagination,
 feed/pricing provenance, account/brand/context/currency continuity, exact
 replay, changed-payload conflict, no duplicate mutation, control, and shared
-readback. The honest v2.5 fixture executes its complete representable direct
-subset, validates exact legacy wire, and asserts typed failures for pagination,
-proposals, cancellation, unsupported create/update fields, and media-buy
 readback. Versioned MCP fixtures also preserve submitted and input-required
 proposal states without inventing completed outcomes. A normal 3.2 server
 profile is exercised by 3.0 and 3.1 buyers through hidden established routes,

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/guides/VALIDATE-YOUR-AGENT.md

@@ -835,3 +835,8 @@ Random seed on nightly broadens the surface; fixed seed on per-PR keeps reproduc
 - [`MULTI-INSTANCE-TESTING.md`](./MULTI-INSTANCE-TESTING.md) — horizontal scaling bug hunt
 - [`BUILD-AN-AGENT.md`](./BUILD-AN-AGENT.md) — server-side implementation
 - `skills/build-*-agent/SKILL.md` — per-specialism obligations and storyboard IDs
+
+
+For creative evaluator security fixtures, see
+[Creative evaluator build probes](CREATIVE-BUILD-PROBE.md) for valid route/input
+preparation, provisioned legacy selectors and explicit coverage gaps.

package/docs/llms.txt

@@ -1,7 +1,7 @@
 # Ad Context Protocol (AdCP)
 
-> Generated at: 2026-10-18
-> Library: @adcp/sdk v16.0.0-beta.8
+> Generated at: 2026-10-19
+> 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-13-to-14.md

@@ -929,10 +929,12 @@ acceptance, caller-supplied budget,
 budget-cap, timezone, or purchase-order values must match any digest-bound
 seller terms; a conflict fails before `create_media_buy`.
 
-For v2.5 specifically, proposal operations, `get_media_buys`, pagination,
-cancellation, and v3-only package controls return typed unsupported errors.
-Supported pause/resume updates require explicit `revision_not_atomic` opt-in
-because v2.5 has no optimistic revision token.
+Historically, the SDK 14 v2.5 lane rejected proposal operations,
+`get_media_buys`, pagination, cancellation, and v3-only package controls with
+typed unsupported errors. Pause/resume updates required explicit
+`revision_not_atomic` opt-in because v2.5 has no optimistic revision token.
+SDK 16 removes that lane and rejects AdCP 2 agents before dispatch; see the
+[AdCP 2 retirement guide](./migration-drop-adcp-2.md).
 
 Run the same compact CLI storyboards against established sellers with
 `--media-buy-lifecycle-compat`. Use `--media-buy-compat-losses` only for the
@@ -1171,18 +1173,20 @@ configuration error; a tool or response variant absent from an installed
 bundle returns `undefined`. Neither case silently falls back to the current
 schema.
 
-Every `TaskResult.metadata` now exposes the selected seller wire generation as
-`serverVersion: 'v2' | 'v3'`. `serverVersionSynthetic` distinguishes an
-authoritative capability declaration (`false`) from the SDK's compatibility
-fallback (`true`). Both fields survive submitted/deferred continuations and
-durable restart recovery. `adcpVersion` remains the distinct, release-precision
-value echoed by a seller response.
-
-The v2.5 `get_products` response adapter also accepts explicitly zoned legacy
-forecast timestamps, including offset variants and single `$date`/`value`
-wrappers. It converts them to UTC RFC 3339 without losing fractional precision;
-ambiguous or unzoned values remain untouched, and the preserved seller wire
-object is not mutated.
+In SDK 14, every `TaskResult.metadata` exposed the selected seller wire
+generation as `serverVersion: 'v2' | 'v3'`. `serverVersionSynthetic`
+distinguishes an authoritative capability declaration (`false`) from the SDK's
+compatibility fallback (`true`). Both fields survive submitted/deferred
+continuations and durable restart recovery. `adcpVersion` remains the distinct,
+release-precision value echoed by a seller response. SDK 16 only dispatches
+AdCP 3 and rejects stored AdCP 2 continuations before resuming them; see the
+[AdCP 2 retirement guide](./migration-drop-adcp-2.md).
+
+The SDK 14 v2.5 `get_products` response adapter also accepted explicitly zoned
+legacy forecast timestamps, including offset variants and single `$date`/`value`
+wrappers. It converted them to UTC RFC 3339 without losing fractional precision;
+ambiguous or unzoned values remained untouched, and the preserved seller wire
+object was not mutated. That AdCP 2 adapter was removed in SDK 16.
 
 SDK 14 also adds semantic refinements to public object schemas. Behavior when
 composing a refined schema varies across supported Zod 4 releases: `.extend()`

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

@@ -16,18 +16,18 @@ pin using `ADCP_VERSION` inside that tarball.
 
 | Fact | Value |
 | --- | --- |
-| Checkout `package.json` version | `@adcp/sdk@16.0.0-beta.8` |
-| npm integrity | registry-derived after publication; run `npm view @adcp/sdk@16.0.0-beta.8 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 | `v2.5`, `v2.6`, `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` |
+| 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` |
 | Canonical migration notes | [SDK 15 OAuth](./migration-oauth-issuer-bindings.md), [issuer-binding and storage](./guides/OAUTH-ISSUER-BINDING.md); historical [13.x → 14](./migration-13-to-14.md) |
 
 For a checkout at the published release commit, install the exact package version:
 
 ```bash
-npm install --save-exact '@adcp/sdk@16.0.0-beta.8'
-npm view '@adcp/sdk@16.0.0-beta.8' dist.integrity
+npm install --save-exact '@adcp/sdk@16.0.0'
+npm view '@adcp/sdk@16.0.0' dist.integrity
 ```
 
 ### Required and optional peers