test(compliance): cover the absent measurement_terms_acceptance gate for measurement_terms_accepted

.changeset/pre/account-change-outcomes.md

@@ -0,0 +1,11 @@
+---
+"adcontextprotocol": minor
+---
+
+Close five gaps in the 3.3 account-attribute model found while implementing against beta.1.
+
+- **"Yes, but as a separate account."** A `request_account` change request can now resolve as `created`, with a new `account_id` carrying the requested change, or as `matched`, pointing to an account the caller already holds. In both cases the named account is untouched. The seller MUST NOT move media buys, creatives, or reporting between the accounts; the buyer chooses which one carries new buys. A buyer tells these outcomes apart because the resolved `account_id` differs from `requested.account_id`. `enums/account-request-resolution.json` and `core/account-request-record.json` describe the change-request meanings.
+- **A refused `sync_accounts` update is visible.** On a settings-update row whose change the seller is reviewing (`pending_approval`), a seller that supports `account.requests` MUST include the review's `request_id`. The request resolves as a `request_account` change does (`updated`, `created`, `matched`, or `rejected`), so a refusal no longer looks the same as a review that is still running.
+- **Accounts that end up alike.** An attribute change that leaves an account with the same brand, operator, and attributes as another account is not a conflict. Both keep their `account_id`, media buys, and history, and the seller MUST NOT merge them. Natural-key references that match both return `ACCOUNT_AMBIGUOUS`, and the deprecated `ACCOUNT_IDENTITY_CONFLICT` does not apply.
+- **What `countries` mean.** `brand.countries` declares the markets an account serves. A seller MAY use it to decide products, prices, terms, and reviews, and MAY refuse a new buy or package whose targeting reaches a market outside it. It never targets delivery. Narrowing it never changes, pauses, or cancels an accepted media buy or its targeting, pricing, or terms, and widening it never extends an accepted buy.
+- **Migration guide.** It now says what a 3.3 buyer does when a 3.0 to 3.2 seller can't take a `countries` change: keep using the existing account reference, and open a new account only by choice.

.changeset/pre/account-identity-is-account-id.md

@@ -0,0 +1,15 @@
+---
+"adcontextprotocol": minor
+---
+
+Make brand identity the domain and account identity the seller's `account_id` (#8280, #8442). A brand is its `domain`, plus `brand_id` where its `brand.json` lists several brands. `brand.countries`, `currency`, `timezone`, `sandbox`, and `operator_unit` are account attributes: they no longer distinguish account identity.
+
+- `sync_accounts`: a provisioning entry without `account` opens an account, and a retry with the same `idempotency_key` returns the original result. A provisioning entry never changes an existing account. When it matches exactly one account in the seller's account scope, on `brand` and `operator` with its attributes as filters, as the `request_account` deduplication guidance describes, the seller SHOULD return that `account_id` instead of opening another, and the exact-or-reject rules for `billing` and `payment_terms` still apply. Sellers MUST return `account_id` once the account is resolved, accept it on every account-scoped task, and never change it; a seller never issues an `account_id` it might later change. A seller that opens buyer-declared accounts through `sync_accounts` accepts settings-update entries keyed by `account_id`. Such an entry updates account attributes, `brand.countries` and `billing` included, on the same account, and the seller validates a changed attribute as it does at opening. Settings-update mode permits `brand`, `operator_unit`, `currency`, `timezone`, and `billing`. `currency`, `timezone`, and `sandbox` are set at opening: a seller MAY refuse a `currency` or `timezone` change with `UNSUPPORTED_FEATURE`, and `sandbox` never changes. A seller can review a `countries` change: the entry's result row reports `action: "unchanged"` and `status: "pending_approval"`, and the account keeps its current countries until the seller approves. `delete_missing` counts an account as included only when an entry names it by `account` or the seller returns its `account_id`.
+- A natural-key `AccountRef` resolves only when exactly one of the caller's accounts matches. Each supplied attribute must equal the account's value, `countries` as a set and `operator_unit` by `id`. An omitted attribute does not filter, except `sandbox`, which defaults to `false`. Otherwise the seller returns `ACCOUNT_AMBIGUOUS` and MAY list the candidates in `error.details.candidates`.
+- `brand-key.json` and `brand-ref.json`: `countries` is an account attribute, and the rule to sort country codes before computing keys is gone. `request_proposals` binds a proposal to the brand and the resolved `account_id`.
+
+**Deprecated in 3.3, planned for removal in 4.0:** the `account.identity_updates` capability, `operator_identity` and `destination_billing_entity` on `sync_accounts`, `identity_change` and `identity_change_preview`, the `ACCOUNT_MOVED` and `ACCOUNT_IDENTITY_CONFLICT` error codes, `error-details/account-moved.json`, and `account.stable_account_id`. No wire field is removed.
+
+Compliance: `media_buy_seller/stable_account_id` re-sends its provisioning entry and checks, as an advisory SHOULD, that the seller returns the same `account_id`. `media_buy_seller/account_timezone_buyer_selected` drops the re-sync reconnect phases.
+
+Training agent: a settings-update entry that changes an account attribute returns `UNSUPPORTED_FEATURE`, and one that carries `operator` returns `INVALID_REQUEST`.

.changeset/pre/account-request-money-terms-and-timezone.md

@@ -0,0 +1,10 @@
+---
+"adcontextprotocol": minor
+---
+
+Account requests (experimental): resolved requests carry money terms, money changes say when they take effect, and timezone changeability is consistent.
+
+- A request that resolves as `matched` or `created` now MUST carry `account`, with the account's `billing`, `billing_entity` (without write-only fields) and `payment_terms`, because they can differ from the terms requested.
+- A request that resolves as `updated` and changed `billing`, `billing_entity` or `payment_terms` carries `effective_at`, when the new money terms take effect.
+- A change request that resolves as `created` (a separate account) carries `not_carried_over`: the account-level configurations the new account doesn't have.
+- `currency` and `timezone` change through `request_account` only on sellers that list them in `account.requests.changeable_attributes`; a seller that changes timezone MUST list it. `request_account` and `sync_principal` docs now agree.

.changeset/account-requests.md → .changeset/pre/account-requests.md

@@ -2,12 +2,12 @@
 "adcontextprotocol": minor
 ---
 
-Add experimental account requests under the new feature id `account.requests` (#8280, P10 of #8118). A buyer agent calls `request_account` to ask a seller for an advertiser account; the seller matches an existing account or creates one, possibly after human review on either side. The request is its own object (`core/account-request-record.json`) with four states: `in_review` (with a `pending_action` saying whether it is waiting on the seller or the buyer, what kind of action is needed, and where), `resolved` (`account_id`, `resolution: matched | created`), `ambiguous` (`candidates[]` the caller is already granted), and `rejected`. No account exists until the request resolves, so a match never changes an `account_id`. Retries are safe through `idempotency_key`; deduplicating separate requests for the same advertiser is non-normative guidance (per calling agent, matching on brand and operator, with countries, currency, timezone, sandbox and `operator_unit` as filters). `get_account_requests` reads requests back, and the caller-anchored `account_request.changed` webhook announces seller-driven transitions. Sellers declare support in `account.requests` on `get_adcp_capabilities`.
+Add experimental account requests under the new feature id `account.requests` (#8280, P10 of #8118). A buyer agent calls `request_account` to ask a seller for an advertiser account; the seller matches an existing account or creates one, possibly after human review on either side. The request is its own object (`core/account-request-record.json`) with four states: `in_review` (with a `pending_action` saying whether it is waiting on the seller or the buyer, what kind of action is needed, and where), `resolved` (`account_id`, `resolution: matched | created`), `ambiguous` (`candidates[]` the caller is already granted), and `rejected`. No account exists until the request resolves, so a match never changes an `account_id`. Retries are safe through `idempotency_key`; deduplicating separate requests for the same advertiser is non-normative guidance (per calling agent, matching on brand and operator, with countries, currency, timezone, sandbox and `operator_unit` as filters). `list_accounts` reads requests back (`include_requests`), and the caller-anchored `account_request.changed` webhook announces seller-driven transitions. Sellers declare support in `account.requests` on `get_adcp_capabilities`.
 
 New shared schemas: `core/pending-action.json` and the extensible `enums/pending-action-kind.json` (`review`, `sign_up`, `accept_terms`, `credit_application`, `add_payment`, `grant`, `connect_credentials`), `enums/pending-action-party.json` (`seller`, `buyer`), `core/account-candidate.json`, `enums/account-request-state.json`, `enums/account-request-resolution.json`, and `error-details/account-ambiguous.json`.
 
 `sync_accounts` provisioning rows become a projection of the same request. Results gain optional `request_id` and `resolution`, and `setup` (on results and on `Account`) gains optional `waiting_on` and `kind`. A matched result reports `action: unchanged` with `resolution: matched`, and a declined request reports `status: rejected` with the reason in `warnings`, as today; no enum values are added. `request_id` appears only on `pending_approval` rows without an `account_id`, and `resolution` only with an `account_id`. `ACCOUNT_AMBIGUOUS` may carry `details.candidates[]`.
 
-A seller never issues an `account_id` it might later change. While a row is `pending_approval` and may resolve to a different account, it carries `request_id` and no `account_id`; a seller whose placeholder ID is the one the account keeps MAY issue it early. This replaces the narrower `account.stable_account_id` placeholder rule, and the unreleased `stable_account_id` text now says the seller returns `account_id` once the account is resolved. A request-mode seller reports pending transitions through `account_request.changed`; on resolution it activates the row's account-level subscribers and then fires `account.status_changed` with the resolved `account_id`, so buyers that predate account requests still learn the outcome. `account.requests.event_type` is optional, and declaring it requires caller-scoped notification support. Requests never act as an existence oracle: answers for accounts outside the caller's grants are indistinguishable from no match, and action URLs are not bearer links.
+A seller never issues an `account_id` it might later change. While a row is `pending_approval` and may resolve to a different account, it carries `request_id` and no `account_id`; a seller whose placeholder ID is the one the account keeps MAY issue it early. This replaces the narrower `account.stable_account_id` placeholder rule. With that flag deprecated, the rule applies to every seller. A request-mode seller reports pending transitions through `account_request.changed`; on resolution it activates the row's account-level subscribers and then fires `account.status_changed` with the resolved `account_id`, so buyers that predate account requests still learn the outcome. `account.requests.event_type` is optional, and declaring it requires caller-scoped notification support. Requests never act as an existence oracle: answers for accounts outside the caller's grants are indistinguishable from no match, and action URLs are not bearer links.
 
 The caller relationship on `get_principal` (`core/principal-relationship.json`) gains the same optional `setup.waiting_on` and `setup.kind`. `list_accounts` guidance for seller-owned namespaces: sellers SHOULD return `account_scope` on every account, with `brand` and/or `operator` where the scope names them. There is no preference order between scopes, because the choice decides who is invoiced and a person makes it.

.changeset/pre/account-single-write.md

@@ -0,0 +1,12 @@
+---
+"adcontextprotocol": minor
+---
+
+Make `request_account` the single account write where the seller supports `account.requests`, with `sync_accounts` superseded there and stable everywhere else (#8543, Part A).
+
+- `request_account` changes an existing account as well as opening one. With `account_id` and other fields, each field is a requested change: the brand's `countries` (with a matching `domain` and `brand_id`), `operator_unit`, `billing`, `billing_entity`, and `payment_terms`. `currency` and `timezone` may be refused, and `sandbox` never changes. A new `revision` guards the change (`CONFLICT` when stale). It is required when the change touches `billing`, `billing_entity`, or `payment_terms`, and optional otherwise. A change resolves with the new `resolution: updated`, and the request record gains an optional `account` snapshot on `resolved`. A change the seller must approve goes `in_review` with a pending action, and the account keeps its current attributes until the request resolves.
+- `list_accounts` reads requests: new optional `include_requests` and `request_ids` return `account_requests[]` beside `accounts[]`. Requests page independently of accounts, through the new `requests_pagination` (request) and `account_requests_pagination` (response); the top-level `pagination` pages accounts only. The unreleased `get_account_requests` task is removed. `account.requests.read_task` is now `list_accounts`.
+- `sync_accounts` stays stable and available in 3.3. Where the seller supports `account.requests`, `request_account`, `list_accounts` and `sync_principal` supersede it, and buyers SHOULD use them there. Its formal deprecation follows `account.requests` leaving experimental status. A `sync_accounts` entry that carries only `notification_configs` and/or `reporting_delivery_configs` is a subscription write: it MUST name an account the caller already holds (otherwise `ACCOUNT_NOT_FOUND`), and the seller MUST NOT provision, run account review, or change account attributes for it.
+- `request_account` change mode authorization: the seller resolves `account_id` against the caller's access before any other validation, so an unreachable account answers exactly like an unknown one. A change requires `request_account` in the grant's `allowed_tasks` with `read_only: false`, and when the grant lists `request_account` under `field_scopes` every changed field must be in it (`SCOPE_INSUFFICIENT`, `READ_ONLY_SCOPE`, `FIELD_NOT_PERMITTED`). An `in_review` change re-checks `revision` when it resolves (`CONFLICT`). A newer change request from the same caller supersedes the open one: it gets its own `request_id` and carries every change still wanted, and the old one is rejected with `CONFLICT` and `details.superseded_by`. Another caller's requests are never affected. Subscription writes don't advance the account `revision`.
+- `request_account` gains `request_id`, to pick a candidate from an `ambiguous` request or name the account created after a `sign_up` action (the request resolves as `matched`). Change requests are never edited in place. `account.requests` gains `changeable_attributes`. The `requested` echo never includes write-only fields.
+- The 3.3 creative MCP role profile gains `request_account`.

.changeset/pre/auction-only-seller-compliance.md

@@ -0,0 +1,5 @@
+---
+"adcontextprotocol": patch
+---
+
+Allow auction-only sellers to run shared media-buy lifecycle and measurement-term rejection checks without fixed-price inventory. Discover selectable pricing options without a fixed-price filter, and opt the semantic rejection probe into request enrichment so it sends valid auction pricing. Run the healthy stale-response probe before forcing an outage, keep the same sandbox account for cache warming and outage forcing, and gate the forced-cache checks on the declared controller scenario.

.changeset/pre/beta3-curated-release-notes.md

@@ -0,0 +1,4 @@
+---
+---
+
+Docs: curated 3.3.0-beta.3 notes in What's new in 3.3 and the beta program page.

.changeset/pre/billing-cutover-stubs-and-delivery-stop.md

@@ -0,0 +1,11 @@
+---
+"adcontextprotocol": minor
+---
+
+Reporting subscriptions (experimental): billing coverage has no unowed stretch, and the flight ends when delivery stops.
+
+- **Billing stubs.** When a cutover hands periods to a billing feed whose schedule has no boundary at the handoff instant E, the stretch from E to the first incoming boundary is now owed as one stub period instead of under neither schedule. Its obligation carries the new `stub: true` (`core/reporting-obligation.json`, billing only). This covers account timezone changes on billing offerings, so no billable hour goes unreported. Pacing and analytics feeds still leave the stretch unowed.
+- **Delivery stop on cancellation.** `cancellation_effective_at` (experimental), a sibling of `cancellation` on `core/media-buy.json` and `get_media_buys`, is when delivery stops under the cancellation, later than `canceled_at` when the seller delivers through a notice period. Sellers advertising `media_buy.reporting_subscriptions` MUST populate it, and the coverage rule's stop time uses it instead of the instant the cancellation was recorded.
+- **Delivery stays inside the flight.** A seller advertising `media_buy.reporting_subscriptions` MUST NOT deliver on a buy outside its flight. To deliver later, including a make-good under `makegood_policy` remedy `additional_delivery`, it first extends `end_time`; a canceled or completed buy's make-good goes on a subsequent buy.
+- The cutover text now says exactly when the stretch is empty: when E is also an incoming boundary. That always holds when moving to a finer schedule (daily to hourly) on the same alignment, timezone, and anchor, but not when moving to a coarser one (hourly to daily). The coverage vectors and reference model gain billing stubs (`stub: true` rows) and the `billing-cutover-owes-a-stub` case, and read `cancellation_effective_at` (`cancellation-notice-period-is-owed-through-the-delivery-stop`).
+- Account-level billing configurations (`sync_accounts` `reporting_delivery_configs`) follow the same rules: a new generation or an account timezone change is a cutover that owes a stub when E isn't an incoming boundary, and a seller with an active billing generation delivers on a buy only inside its flight (`x-adcp-validation.billing_continuity`).