@adcp/sdk 14.0.0-rc.38 → 14.0.0-rc.39

package/docs/guides/REPORTING-SOURCE-EXECUTOR.md

@@ -4,6 +4,27 @@
 
 The existing buyer-side `reconcileReporting` API is unchanged.
 
+For the common bounded, non-paginated provider API, prefer
+`createReliableReportingService` from `@adcp/sdk/reporting/service`. Its
+`ReliableReportingAdapterV1` adds trusted account/source/currency routing, the
+existing ledger lifecycle, server handlers, scheduler, and truthful Core
+capabilities.
+
+The adapter takes exactly one of two runtime shapes, and the choice does not
+decide whether you get the service:
+
+- `fetchSlice` — the narrow inline boundary described below. The service builds
+  and owns the executor, including bounded staging and replay. Opt into a
+  bounded replay window with `inlineReplayRetention`.
+- `executor` — any `ReportingSourceWithReaderV1` you build with the raw
+  interfaces in this guide, including a paginated, asynchronous, or externally
+  staged one. The service routes to it unchanged, so those sources get the
+  ledger lifecycle and scheduler too; `inlineReplayRetention` does not apply
+  and is ignored.
+
+Use the raw interfaces here directly, without the service, only when you also
+want to own the ledger lifecycle and scheduling.
+
 ## Day 1: register an executor
 
 Implement `ReportingSourceExecutorV1` and `ReportingSourceStagedObjectReaderV1`. Keep `sourceScope` opaque: the caller defines and freezes it, while the executor echoes it and uses it to scope immutable staged-object reads.
@@ -46,7 +67,48 @@ const source = createInlineReportingSourceExecutor(getMediaBuyDelivery, offering
 
 Return `null` while the report is not ready, `[]` for a real observed zero-row period, and rows for success. A `get_media_buy_delivery` response must include its exact `reporting_period`, matching `currency`, and either `reporting_rows` or `media_buy_deliveries`. An unclassified throw becomes retryable `SOURCE_TRANSIENT`; throw `InlineReportingSourceError` to retain a specific typed classification. Partial-data flags, unavailable counts, response errors, and unproved full constituent coverage fail closed with `PARTIAL_RESULT`.
 
-The inline adapter narrows the supplied offering to `basic`, non-paginated `media_buy` execution. Every nonzero row must identify an admitted `media_buy_id` and contain each requested metric (directly or under `totals`) and requested dimension; extra or unidentified rows are rejected. Only the identifier and requested evidence fields are retained. `[]` is the only implicit proof of an all-zero period. A response that omits both row collections is a failure, and unfinished pagination is partial. Authoritative publication additionally requires `is_final: true` or a `final`/`adjusted` notification. The fetch context carries the frozen source settings and semantic contract; group reads are rejected because this compatibility adapter cannot prove them. Each inline executor instance admits at most 100 retained executions and 32 MiB per caller scope, 1,000 executions and 256 MiB total, 16 concurrent fetches, and 64 MiB per object. Capacity exhaustion is terminal for that instance; replace it with a durable executor when those bounded compatibility limits are too small.
+When availability differs by metric, add the versioned `availability_evidence` envelope to the existing response object. The callback request supplies the frozen `constituents` mapping; use its `constituent_id` values rather than deriving manifest identities from media-buy IDs. Cells cover the exact requested constituent/metric matrix once each. The adapter supplies semantic-contract IDs and checksums from the offering.
+
+```ts
+const source = createInlineReportingSourceExecutor(async input => ({
+  reporting_period: { start: input.start_date, end: input.end_date },
+  currency: 'USD',
+  reporting_rows: [
+    { media_buy_id: input.constituents[0]!.media_buy_id, impressions: 10, clicks: 0 },
+  ],
+  availability_evidence: {
+    version: '1.0',
+    cells: [
+      {
+        constituent_id: input.constituents[0]!.constituent_id,
+        metric: 'impressions',
+        status: 'present',
+        data_through: input.end_date,
+      },
+      {
+        constituent_id: input.constituents[0]!.constituent_id,
+        metric: 'clicks',
+        status: 'explicit_zero',
+        data_through: input.end_date,
+      },
+      {
+        constituent_id: input.constituents[0]!.constituent_id,
+        metric: 'viewability',
+        status: 'delayed',
+        reason: 'Provider processing is not closed',
+      },
+    ],
+  },
+}), offering);
+```
+
+`present` and `explicit_zero` require `data_through` and forbid a reason. `unsupported`, `delayed`, `partial`, `stale`, and `missing` require a bounded reason and may carry `data_through`. Reasons are retained in durable manifest evidence: use stable non-secret explanations, never credentials or raw provider payloads. A row must contain every metric marked `present`; when that constituent has rows, every row must also carry zero for a metric marked `explicit_zero`. A row proves every constituent that names its `media_buy_id`, so when several constituents share one media buy they are each held to their own cells against that same row. Rows cannot contain values for `unsupported`, `delayed`, or `missing` cells. Mixed cells roll up to existing manifest constituent and coverage states in the request's canonical constituent/metric order. A request for full coverage still returns `PARTIAL_RESULT` when the cell matrix proves only partial or no coverage, and an authoritative/final response cannot seal until every cell is present or explicit-zero through period end.
+
+Malformed versions or cells, duplicates, missing cells, unrequested constituent/metric keys, invalid watermarks, and row/evidence contradictions fail with `INTEGRITY_FAILED` before objects are staged. Every semantic verdict -- row scope, requested-cell completeness, duplicate-claim reconciliation, evidence reconciliation across both row collections, temporal evidence, and the coverage and finality roll-ups -- is settled before the response is projected at all, so an incomplete, contradictory or out-of-scope response returns the verdict it earns rather than exhausting the staging budget on rows that were never going to be kept. Evidence with no rows may prove either that every cell is explicit-zero or that cells are unavailable; it cannot combine available and unavailable claims without rows. A row that repeats one metric both directly and under `totals` must repeat the same quantity; a contradictory second claim is `INTEGRITY_FAILED` rather than a silently preferred direct value. The two claims are compared as exact decimals, so a number printed in exponent notation matches the equivalent plain decimal (`1e-7` and `"0.0000001"` are one quantity), while a decimal string is read digit for digit and is never rounded onto a nearby number. The evidence envelope and each of its cells must carry only their own declared fields as plain own data properties, each within a bounded length that is checked before the value reaches validation -- a validator runs every one of its checks even once one has failed, so an unbounded value would otherwise be walked in full before being refused. The key set is checked against that allowlist before any descriptor is read, and an accessor-backed or inherited cell field is refused rather than invoked, so a cell cannot compute or inherit the `status` that proves it. Omitting `availability_evidence` retains the prior all-cells-derived behavior for row arrays and existing response objects, but the envelope must be supplied as a plain own data property: an accessor-backed or inherited `availability_evidence` slot is `INTEGRITY_FAILED` and is never read, because reading it is unsafe and ignoring it would silently downgrade the response to derived availability. That classification comes from one bounded descriptor observation, and the value captured by that same observation is what gets parsed, so a slot that presents itself differently each time it is examined cannot reach the downgrade either. A prototype chain that cannot be walked to an end -- cyclic, or regenerated on every hop -- is likewise `INTEGRITY_FAILED`.
+
+`reporting_rows` and `media_buy_deliveries` are read through the ordinary property channel, so a class instance, a prototype-inherited value, and an accessor-backed slot are all accepted as before; each is read once and the collection that is validated is the collection that is staged. Each row inside them is likewise observed once: its `media_buy_id`, `currency`, `status`, and the direct and `totals` claim for every requested metric and dimension are captured in a single pass, and budgeting, validation, projection and the staged bytes all read that capture. A `totals` that aliases its own row addresses the same slot twice and is read once. Without `availability_evidence` a valid direct value settles its metric, and where every requested metric is settled that way the `totals` slot is not observed at all -- not the property, and not the object behind it. It is observed once, for the whole row, the first time a fallback or a reconciliation actually needs it. With evidence both claims are always read, because a duplicate claim must be reconciled rather than silently preferred. A requested metric or dimension named after one of the adapter's own row fields -- `media_buy_id`, `currency`, `status`, `partial_data`, `totals` -- resolves to that same single observation rather than taking a second one. A row's own `status` is settled before any other field of that row is observed -- `partial_data` included -- so a row its status already settles costs nothing beyond that one read. The same holds for the response envelope itself: `status` is read once and every verdict it decides -- reported failure, unavailable data, and the not-ready states -- is settled before anything else is touched at all, so a response that reports one of them beside a field or collection that throws on access keeps its retryable verdict. Each remaining response field is read at most once and only when a check actually needs it, so a field no check reaches is never observed: `notification_type` goes unread when `is_final` already proves finality. A `status` that is present but is not a string is an unreadable response rather than an absent status. `is_final`, `notification_type`, `partial_data`, `unavailable_count`, `errors`, `pagination`, `reporting_period`, `currency`, `data_through` and `observed_at` are then each read once, each period boundary included, so a period cannot be proven from one object and a currency from another. A control field that is present but malformed -- `unavailable_count: '5'`, `errors: 'boom'`, a non-string watermark -- is treated as the partial or invalid evidence it is, never narrowed into an absent one. Row collections are copied by index against the length they declare, never by spreading, and that length is observed once: a collection whose iterator or second answer disagrees with it cannot materialize more rows than the cap admits, nor have rows it delivered dropped from the staged object. A row whose fields answer differently when read again cannot be priced as one shape and processed as another -- the first answer is the only answer. Only `availability_evidence` is restricted to a plain own data property, because an evidence slot that reads as omitted changes which availability rules apply, whereas a row collection that reads as omitted is simply a failure.
+
+The inline adapter narrows the supplied offering to `basic`, non-paginated `media_buy` execution. Every nonzero row must identify an admitted `media_buy_id` and contain each requested dimension; `media_buy_id` may also be requested as a metric, and the row identity proves it. Without `availability_evidence`, it must also contain every requested metric (directly or under `totals`); extra or unidentified rows are rejected. Only availability verification reads the auxiliary collection's claims, so without evidence its rows are observed for their `media_buy_id` alone -- enough to scope-check them -- and their metric and dimension fields are neither read nor billed. The auxiliary collection is never projected or staged either way: it is validated from its captured claims, so its size does not spend the staging budget the source rows need. Only the identifier and requested evidence fields are retained. `[]` is the only implicit proof of an all-zero period. A response that omits both row collections is a failure, and unfinished pagination is partial. Authoritative publication additionally requires `is_final: true` or a `final`/`adjusted` notification. The fetch context carries the frozen source settings and semantic contract; group reads are rejected because this compatibility adapter cannot prove them. Each inline executor instance admits at most 100 retained executions and 32 MiB per caller scope, 1,000 executions and 256 MiB total, 16 concurrent fetches, 64 MiB per object, and 5,000,000 validation work units per response. One unit is one requested metric or one requested dimension checked against one row for one constituent, so the budget prices metric breadth, dimension breadth and constituent fanout together -- a row is checked against every constituent naming its `media_buy_id`, and sharing one media buy across many constituents spends the budget that many times over. A second budget caps the characters validation may scan while measuring and canonicalizing claims at one staged object's worth (64 MiB), counted per occurrence and per pass, so a long value reused across rows or restated under `totals` cannot buy an unbounded number of scans; a claim is scanned for its byte width, for the zero test and for the canonical decimal form behind a duplicate comparison, and each pass is charged and computed at most once. A number is charged the width it canonicalizes to, not one character, because exponent notation expands when the decimal point is shifted into plain form. A third bound holds the captured claims themselves to the per-object staging ceiling (64 MiB). Claims live in one value array and one flag array shared by every row, so what is held stays proportionate to what is written: with rows capped at 100,000 and the work budget capped at 5,000,000 units the widest admissible request holds about 48 MB, which makes this ceiling an assertion of that arithmetic rather than a limit adopters meet. It is deliberately not the per-scope limit, because the estimate is an upper bound on held bytes while that limit governs written bytes -- held against it, reports the staging cap admits were refused. All three are settled from counts before the work is attempted, so an over-budget request is refused rather than performed. Row status and row currency are decided in their own streaming passes ahead of that capture, so a response whose first row already settles the outcome does not pay to read the rest, and a status too long to be one the adapter recognizes is never case-folded. Capacity exhaustion is terminal for that instance; replace it with a durable executor when those bounded compatibility limits are too small.
 
 The object reader MUST authorize and confine every `objectRef` to the supplied `sourceScope`, account, delivery configuration, report definition, and obligation tuple. The harness supplies scope from the frozen request, never from the manifest. Its default pre-read budget is 512 MiB per object and 2 GiB per slice; pass `objectReadLimits` to conformance when a declared adapter format legitimately needs different bounds.
 

package/docs/guides/SELLER-QUICKSTART-3.2.md

@@ -1,5 +1,7 @@
 # Build an AdCP 3.2 seller in 15 minutes
 
+Use the [MediaBuy action resolver](./MEDIA-BUY-ACTION-ASSESSMENT.md#seller-builder) to materialize explicitly accepted product templates and project accepted rights through current status, authorization, governance, and seller policy.
+
 The compact lifecycle is the SDK 14 starting point. Use Node.js
 `^20.19.0 || >=22.12.0`:
 

package/docs/guides/VALIDATE-YOUR-AGENT.md

@@ -103,6 +103,9 @@ temporary legacy compatibility harnesses rather than routine compliance runs.
 - `--brief <text>` — custom product-discovery brief (default varies by storyboard)
 - `--auth <token>` — bearer token (also accepts `$ADCP_AUTH_TOKEN`)
 - `--oauth` — run the browser OAuth flow inline when the saved alias has no valid tokens (MCP only; equivalent to `adcp --save-auth <alias> <url> --oauth` then re-running)
+- `--signing-transport raw|mcp` — how the `signed_requests` conformance vectors are framed on the wire. Not the same as `--transport`/`--protocol`. Default: inferred from the resolved protocol
+- `--signing-skip-vectors <ids>` — comma-separated vector ids to exclude (graded `operator_skip`); unknown ids are rejected
+- `--signing-skip-rate-abuse` — skip the rate-abuse vector, which floods cap+1 requests at the agent (bare flag; `=false` is rejected, not read as "off")
 
 **Authoring webhook assertions.** Webhook storyboard pseudo-steps share the
 receiver URL and filter contract. Use `triggered_by` to scope the observation
@@ -263,6 +266,32 @@ npx @adcp/sdk@adcp-3.1 grade request-signing https://sandbox.agent.example/mcp -
 npx @adcp/sdk@adcp-3.1 grade request-signing https://sandbox.agent.example/mcp --only 016-replayed-nonce
 ```
 
+#### Same vectors inside `storyboard run`
+
+The `signed_requests` storyboard synthesizes one step per vector and grades them through the same engine. `storyboard run` exposes the knobs that matter there:
+
+```bash
+# Per-operation HTTP endpoints instead of a single MCP mount
+npx @adcp/sdk@adcp-3.1 storyboard run https://sandbox.agent.example/adcp signed_requests \
+  --signing-transport raw --auth $TOKEN
+
+# Drop a vector your deployment can't satisfy, and the cap+1 flood
+npx @adcp/sdk@adcp-3.1 storyboard run https://sandbox.agent.example/mcp signed_requests \
+  --signing-skip-vectors 025-jwk-alg-crv-mismatch --signing-skip-rate-abuse --auth $TOKEN
+```
+
+- **`--signing-transport` is not `--transport`.** `--transport`/`--protocol` selects how the storyboard talks to your agent; `--signing-transport` selects how the conformance vectors are framed. Mirrors `adcp grade request-signing --transport`.
+- **Leave it unset by default.** The vector transport is inferred from the resolved protocol: an MCP run frames every vector as a `tools/call` envelope, so an MCP-only agent no longer collects 404s from raw per-operation replay.
+- **On an A2A run most vectors report `COVERAGE UNAVAILABLE`, and the command exits 3.** The runner dispatches vectors two ways — verbatim REST replay and an MCP `tools/call` re-frame — and it does not yet dispatch them through the official A2A client, so it declines to grade rather than POSTing an MCP envelope at an A2A endpoint and scoring the resulting 405 as a signature failure. Each ungradable vector skips with detailed reason `signing_transport_unavailable` (canonical `not_applicable` plus that token as `skip.detail`, the output contract's registered sub-reason shape). What holds the verdict open is coverage, not the reason: no vector reached the agent, so the storyboard is non-passing (`overall_passed: false`), the `security_transport` track stays `partial` — including when every step in the track skipped, and when a sibling storyboard (`oauth_setup`) passes everything — and the command exits nonzero. **If you advertise `request_signing.supported: true` and are graded over A2A, this is you:** there is no agent-side fix. Grade your verifier through the agent's MCP or REST binding, pass `--signing-transport` when that binding answers on the same URL as the A2A card, or run with `--soft-fail` to report the gap without failing the job.
+- **Only the in-library vector still grades on A2A.** `025-jwk-alg-crv-mismatch` is decided against the SDK verifier with no wire exchange, so the run's protocol is irrelevant to it — and its step says so in the title, because it verifies the SDK and not your agent. Everything probed reports the coverage gap, `028-unsigned-protocol-method-required` included. That is a gap in this runner, not in the A2A client: `@a2a-js/sdk` issues `tasks/cancel` fine, but no signing probe is wired through it yet, and writing the fixture's bytes to the endpoint directly would be a hand-rolled A2A dispatch.
+- **Vectors excluded on their own terms say so, on every protocol.** `026-non-ascii-host` reports `transport_ungradable` (no HTTP client can carry a non-ASCII authority — `fetch` punycodes it first). `028-unsigned-protocol-method-required` reports `capability_profile_mismatch` unless your `get_adcp_capabilities` declares `request_signing.protocol_methods_required_for` — **this applies on MCP runs too, not just A2A**: previously the storyboard dispatched 028 at every agent, so one that never claimed the JSON-RPC bucket could fail it. Declare the bucket (e.g. `['tasks/cancel']`) if you verify signatures on protocol methods; a declaration your AdCP line's schema rejects is discarded rather than treated as "not declared", so it cannot suppress the vector. Note `adcp grade request-signing` does not read your advertisement — it uses the profile you pass it — so the two commands can disagree about 028 by design.
+- **A run that graded nothing exits nonzero.** Skipped steps are `passed: true`, so a coverage gap used to exit 0. `adcp storyboard step` now exits 3 when the runner could not dispatch the step, and the full assessment exits 3 when a storyboard's signing coverage went unverified — including when your own `--signing-skip-vectors` removed every vector, which is the other way to end up with nothing graded. The message names which of the two happened. Everything else keeps exit 0: other `partial` runs, legacy fixture gaps, and single steps you excluded yourself. `--soft-fail` works on both commands and reports the gap while exiting 0.
+- **Library callers get the same knobs.** `comply(agentUrl, { request_signing: { transport: 'mcp', skipVectors: [...], onlyVectors: [...], skipRateAbuse: true, rateAbuseCap: 5 } })` from `@adcp/sdk/testing` mirrors the CLI, plus `onlyVectors`/`rateAbuseCap`, which have no flag yet. `adcp grade request-signing` spells the same knobs `--transport`, `--skip`, `--only`, `--skip-rate-abuse`, `--rate-abuse-cap`; `storyboard run` prefixes them because `--transport` is already taken by the storyboard's own transport.
+- **Mistyped flag values are rejected.** `--signing-skip-vectors` validates every id against the shipped vector set (a typo silently skipped nothing before), and `--signing-skip-rate-abuse` refuses a value — `=false` used to read as "on".
+- **Vector `025-jwk-alg-crv-mismatch` is graded in-library.** It publishes a malformed JWK your agent never serves, so there is no HTTP exchange: the step asserts the grader's verdict (`probe_passed`), not a 401.
+
+> **Published 3.0 line.** These fixes ship on the 3.1+/prerelease line. The `adcp-3.0` dist-tag (`@adcp/sdk@7.11.x`) still defaults the vector transport to `raw` and has no `--signing-*` flags; an MCP-only agent must grade `signed_requests` from the 3.1 CLI (or drive `runStoryboard` with `request_signing: { transport: 'mcp' }`) until that line takes a backport.
+
 ### Multi-instance testing
 
 Exposes `(brand, account)`-scoped state that lives per-process instead of in a shared store — a class of bug that single-URL runs never catch. See [`docs/guides/MULTI-INSTANCE-TESTING.md`](./MULTI-INSTANCE-TESTING.md).
@@ -629,6 +658,12 @@ Hints also land in machine-readable output:
 |---|---|
 | `storyboard run` skips steps with "no webhook_receiver_runner" | Add `--webhook-receiver` |
 | `storyboard run` fails on `security_baseline` | You skipped `authenticate` in `serve()` — see [build-seller-agent/SKILL.md § signed-requests](../../skills/build-seller-agent/SKILL.md) |
+| `None of the required contributions were recorded: ["auth_mechanism_verified"]` | No auth mechanism could be verified. If your steps also show task `mcp_session_probe`, your read surface is outside the probe allowlist and the runner fell back to the MCP session probe — see the next rows |
+| `Skipped (not_applicable / session_probe_ungradable)` | The runner prints the full reason and remedy on the line directly below. Four causes: (1) you advertise no **canonical AdCP** read task the probe can call with an empty body — tool names you invented are not eligible, and public-tier (`get_adcp_capabilities`, `get_products`, `list_products`, `list_creative_formats`) and mutating tools are excluded by design; (2) the step is a positive static-credential probe the session probe cannot grade; (3) the run signs functional dispatch and your `request_signing` advertisement covers every target the probe could call; (4) the run passed a `-H` header the runner can classify neither as a credential nor as routing — that one is about how the run was invoked, not about your agent, and the detail names the header. **A static-credential-only agent with no allowlisted read tool cannot be certified**: the positive probe asserts an AdCP response body no protocol operation produces, so its branch's contribution gate stays closed. Two remedies: advertise one allowlisted read tool (`list_creatives`, `get_media_buy_delivery`, `list_authorized_properties`, `get_signals`, `list_property_lists`, `list_collection_lists`, `list_content_standards`, `list_accounts`) — the durable fix — or serve RFC 9728 metadata and run with `--oauth` so the OAuth branch is verified instead |
+| `Error: MCP session auth probe is inconclusive: …` | A rejection is auth evidence only when a valid credential of the **same kind** reaches the same protected tool. The message names what is missing: no OAuth access token for this run (run with `--oauth`), no API key / Basic credential configured, the valid credential was refused too, or the agent refused the *shape* of the call (advertise a tool that accepts an empty request body) |
+| `Error: MCP session auth probe refuses this as auth evidence: …` | The probe's bad or absent credential got a successful payload from your protected tool — it is serving tenant-scoped data to anyone — or a valid credential failed to reach it |
+| `Error: MCP session probe could not run: …` | Not an authentication result at all: a wire version this SDK does not implement, a response shape the official MCP client rejects, or an exchange that never completed. Nothing was learned about your credentials; fix the named protocol problem and re-run |
+| `extraction.note` reads `MCP session probe graded <tool> at <stage>` | Which protected tool the verdict rests on, and where the agent decided (`initialize` for session-boundary auth, `tools/call` for per-operation auth). The verdict is evidence that the mechanism is enforced **at that tool** — it is not a claim that every tool enforces auth |
 | `storyboard run` reports `Agent requires OAuth` / exits without running | Save tokens once with `adcp --save-auth <alias> <url> --oauth`, or pass `--oauth` to `storyboard run` to complete auth inline |
 | `storyboard run` prints `💡 Hint: Rejected …` below an error | Catalog inconsistency between the two tools — see [§ Reading hint lines](#reading--hint-lines-context-value-rejections) above |
 | `fuzz` reports `500` status with stack trace | Validate inputs and return `adcpError('REFERENCE_NOT_FOUND', ...)` instead |

package/docs/guides/idempotency-crash-recovery.md

@@ -2,6 +2,10 @@
 
 How a buyer agent recovers when a process crashes mid-retry without creating duplicate media buys.
 
+For the complete multi-process path—including durable callback registration,
+polling, continuations, and once-only host publication—see
+[Durable buyer writes across processes](./DURABLE-BUYER-WRITES.md).
+
 ## The failure mode
 
 A buyer process sends `create_media_buy` to a seller, the seller accepts it, but the process crashes before it can persist the response. On restart, the buyer does not know whether the call landed. Three things can happen on the next attempt:

package/docs/llms.txt

@@ -1,7 +1,7 @@
 # Ad Context Protocol (AdCP)
 
-> Generated at: 2026-09-15
-> Library: @adcp/sdk v14.0.0-rc.38
+> Generated at: 2026-09-18
+> Library: @adcp/sdk v14.0.0-rc.39
 > 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.
@@ -17,6 +17,7 @@ SDK 14 requires Node.js `^20.19.0 || >=22.12.0`; install the newest v14 prerelea
 
 SDK 14 is compact-lifecycle first: `list_products → buy_products → control_media_buy`, with `request_proposals → refine_proposals → accept_proposal` when terms need negotiation.
 
+- **MediaBuy change rights:** use `assessMediaBuyAction` from `@adcp/sdk/media-buy/actions` for possible / promised / available-now assessment, and `mediaBuyActionResolver` from `@adcp/sdk/server` for explicit seller acceptance and current projection. See `docs/guides/MEDIA-BUY-ACTION-ASSESSMENT.md`.
 - **Buyer** (calling a seller): read `docs/guides/BUYER-QUICKSTART-3.2.md` first.
 - **Before proposal acceptance:** use `verifyProposalCommercialTerms` from `@adcp/sdk/negotiation/verification` with a complete, independently reviewed snapshot and the seller-served schema version. Never use an unreviewed candidate as its own expected terms. See `docs/guides/PROPOSAL-TERMS-VERIFICATION.md`.
 - **Seller** (implementing an agent that others call): read `docs/guides/SELLER-QUICKSTART-3.2.md` first, then `docs/guides/BUILD-AN-AGENT.md` for the complete framework surface.
@@ -2088,6 +2089,7 @@ These docs are available locally in the repo and hosted at https://adcontextprot
 |------|-----------|--------|
 | Full type signatures | docs/TYPE-SUMMARY.md | [link](https://adcontextprotocol.github.io/adcp-client/TYPE-SUMMARY.md) |
 | Buyer quick start (AdCP 3.2) | docs/guides/BUYER-QUICKSTART-3.2.md | [link](https://adcontextprotocol.github.io/adcp-client/guides/BUYER-QUICKSTART-3.2.md) |
+| Assess and resolve MediaBuy actions | docs/guides/MEDIA-BUY-ACTION-ASSESSMENT.md | [link](https://adcontextprotocol.github.io/adcp-client/guides/MEDIA-BUY-ACTION-ASSESSMENT.md) |
 | Verify proposal terms before acceptance | docs/guides/PROPOSAL-TERMS-VERIFICATION.md | [link](https://adcontextprotocol.github.io/adcp-client/guides/PROPOSAL-TERMS-VERIFICATION.md) |
 | Seller quick start (AdCP 3.2) | docs/guides/SELLER-QUICKSTART-3.2.md | [link](https://adcontextprotocol.github.io/adcp-client/guides/SELLER-QUICKSTART-3.2.md) |
 | Production durability checklist | docs/guides/PRODUCTION-DURABILITY.md | [link](https://adcontextprotocol.github.io/adcp-client/guides/PRODUCTION-DURABILITY.md) |

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

@@ -11,18 +11,18 @@ below as the publication/deployment gate.
 
 | Fact | Value |
 | --- | --- |
-| Exact npm package | `@adcp/sdk@14.0.0-rc.38` |
-| npm integrity | registry-derived after publication; run `npm view @adcp/sdk@14.0.0-rc.38 dist.integrity` |
+| Exact npm package | `@adcp/sdk@14.0.0-rc.39` |
+| npm integrity | registry-derived after publication; run `npm view @adcp/sdk@14.0.0-rc.39 dist.integrity` |
 | Node.js runtime | `^20.19.0 || >=22.12.0` |
 | Default AdCP wire release | `3.2.0-rc.3` |
-| Maintained wire releases | `v2.5`, `v2.6`, `v3`, `3.0.0-beta.1`, `3.0-beta.1`, `3.0-beta`, `3.0.0-beta.3`, `3.0-beta.3`, `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.2.0-rc.3`, `3.2-rc.3` |
+| 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.2.0-rc.3`, `3.2-rc.3` |
 | Canonical migration notes | [13.x → 14](./migration-13-to-14.md) |
 
 Install exact production inputs rather than a moving prerelease range:
 
 ```bash
-npm install --save-exact '@adcp/sdk@14.0.0-rc.38'
-npm view '@adcp/sdk@14.0.0-rc.38' dist.integrity
+npm install --save-exact '@adcp/sdk@14.0.0-rc.39'
+npm view '@adcp/sdk@14.0.0-rc.39' dist.integrity
 ```
 
 ### Required and optional peers

package/docs/migration-7.9-to-7.10.md

@@ -352,7 +352,11 @@ resolver enforces `DEFAULT_MAX_KEYWORDS` before compiling custom
 format schemas; the validation budget remains the caller's per-manifest
 runtime concern.
 
-## 5. AdCP 3.1.0-beta.5 opt-in
+## 5. Historical AdCP 3.1 beta opt-in
+
+> This section describes the 7.10-era preview. Current SDK releases no longer
+> ship the retired 3.1 beta cache or type subpath; use the primary 3.2 types and
+> a maintained stable compatibility pin instead.
 
 Pin to the beta to validate against its schemas (wholesale feed surfaces,
 `format_option_refs` on PackageRequest, etc.):
@@ -365,10 +369,8 @@ const client = new AdCPClient({
 });
 ```
 
-The SDK's primary pin stays at the GA `ADCP_VERSION` — this is a
-side-bundle, not a default move. Schemas live at
-`schemas/cache/3.1.0-beta.5/`; refresh with `npm run sync-schemas:3.1-beta`
-+ `npm run generate-types:3.1-beta`.
+At the time, this was a side-bundle rather than a default pin move. Its sync
+and generation commands were removed when the primary pin advanced beyond it.
 
 ## 6. What v1-only adopters should do
 

package/examples/README.md

@@ -18,6 +18,23 @@ Adding one task to an application that already owns auth and storage? Start
 with [`existing-platform-thin.ts`](./existing-platform-thin.ts) and the
 [existing-platform guide](../docs/guides/EXISTING-PLATFORM.md).
 
+Running buyer writes from request-scoped processes? The
+[`durable-buyer-writes`](./durable-buyer-writes/) example connects the caller,
+fresh callback/poll worker, PostgreSQL receiver stores, and host publication
+outbox described in the
+[durable buyer writes guide](../docs/guides/DURABLE-BUYER-WRITES.md).
+
+Migrating a seller adapter to AdCP 3.2 targeting? The focused
+[`targeting-input-existing-platform.ts`](./targeting-input-existing-platform.ts)
+example carries nullable omit/clear/set commands through provider translation,
+persists strict accepted state, produces strict readback, and refuses clears the
+provider cannot honor.
+
+Adding Reliable Reporting Core to an existing seller? Start with the
+[adapter-first installation example](./reliable-reporting-service/README.md).
+It uses the durable ledger as the sole authority and shows trusted account,
+source-scope, timezone, and currency resolution without sample reporting data.
+
 ## Building an AdCP agent — fork-target reference adapters
 
 Pick the example whose AdCP role and specialism most closely matches what you're building, fork it, replace the `// SWAP:` markers, and follow the `FORK CHECKLIST` block for the unmarked but load-bearing constants. The `hello_*_adapter_*` examples are paired with the three-gate CI test (strict tsc / storyboard / upstream-traffic) where a matching mock server exists; examples without one are called out below with the narrower runtime coverage they currently have. `proxy-seller-snap/` is a lighter bridge-pattern fork target: it proves seed-bridge wiring and must be paired with your live-OAuth sandbox runner for upstream health.