fix(schema): keep 3.3 additions off the deprecated create_media_buy and update_media_buy (#8501)

.changeset/withdraw-create-update-media-buy-3-3-fields.md

@@ -0,0 +1,16 @@
+---
+"adcontextprotocol": minor
+---
+
+Keep 3.3 additions off the deprecated `create_media_buy` and `update_media_buy` tasks (adcp#8501). Both are compatibility tasks that buyers are moving off, so 3.3 adds nothing to them: a field that exists only there is one more gap for every migration. Six fields that the 3.3 betas added to them are removed from them. Where a live task (`buy_products`, `accept_proposal`, `control_media_buy`, `get_media_buys`, `sync_creatives` `assignment_operations`) has the same field, it stays there unchanged.
+
+**This is a beta-to-beta change.** No stable release carried these fields. The betas are immutable, so a buyer, seller, or SDK built from a beta bundle has them to remove. The schemas are open, so a seller on the later schema ignores them like any unknown field rather than rejecting the request.
+
+- **`predecessor_media_buy_id` and `lineage_reason` (experimental `media_buy.lineage`, #8038, from `3.3.0-beta.0`).** Removed from the `create_media_buy` request, with their paired `dependencies`. They stay on the `buy_products` and `accept_proposal` requests, on `get_media_buys` readback and its `predecessor_media_buy_id` filter, and on `core/media-buy.json`.
+- **`artifact_webhook.signing_profile` (experimental, #7894, from `3.3.0-beta.0`).** Removed from the `create_media_buy` request, with its rule against sending it next to `authentication`. No live task has `artifact_webhook`, so it lives nowhere: an `artifact_webhook` without `authentication` is signed with `adcp/webhook-signing/v1`. `signing_profile` stays on `push_notification_config`, `reporting_webhook`, and the notification configurations, and `webhook_signing.profiles` no longer lists `artifact_webhook`.
+- **`start_requires_all_creatives_approved` (#8485, from `3.3.0-beta.1`).** Removed from `media-buy/package-request.json` (`create_media_buy` packages and `update_media_buy` `new_packages`), `media-buy/package-update.json`, and `core/package.json` (the package readback in their responses). It stays on `control_media_buy` package controls (`media-buy/package-control.json`), `get_media_buys` package readback, the `update_creative_start_policy` available action, and `media_buy.features.creative_start_policy`, whose description now names only `control_media_buy`.
+- **`target_audiences[]` (experimental `media_buy.audience_evidence_targets`, #8215, from `3.3.0-beta.1`).** Removed from `media-buy/package-request.json`, with its `dependencies` entry. With the `get_products` filters copy withdrawn in the same release, no 3.3 wire form remains: sellers stop listing the feature id, and `core/audience-evidence-target.json` and `enums/audience-evidence-relationship.json` are removed, along with their `index.json` registrations and `tests/audience-evidence-targets.test.cjs`. The stable inline `relationship` enums on audience evidence are unchanged. The design and its matching rules are kept under the 4.0 check `purchase_target_audiences_required_in_4_0`, whose detection no longer depends on the retired feature id.
+- **`trackers` and `landing_page_url` on package creative assignments (#8220, #8180, from `3.3.0-beta.0`).** Removed from `core/creative-assignment.json`, which only `create_media_buy` and `update_media_buy` requests and their package readback use. They stay on `sync_creatives` `assignment_operations` `assign`, read back on `list_creatives` and `get_media_buys`, which defines its own assignment rows. `creative.supports_assignment_trackers` and `creative.supports_assignment_landing_page` now name only `sync_creatives`.
+- **`billing_measurement.counting_mechanisms[]` (experimental `media_buy.measurement_provenance`, #7940, from `3.3.0-beta.2`).** Removed from `core/measurement-terms.json`, which only `get_products` products and `create_media_buy` and `update_media_buy` packages use, so this covers all three tasks. It lives nowhere in 3.3; the canonical commercial terms, held closed until 4.0, gain it then (`canonical_counting_mechanisms_required_in_4_0`, whose design notes now record it). `vendor_metric_provenance[]` and `enums/collection-mechanism.json` stay.
+
+`expected_confirmation_at` stays on every `submitted` response, `create_media_buy` included. The training agent stops echoing the start gate on `create_media_buy` and `update_media_buy` packages. It ignores assignment `trackers` and `landing_page_url` on their creative assignments and does not echo assign-set ones in their responses. `get_media_buys` still reads back what `sync_creatives` `assign` set. The 3.3 release notes, What's new, the 3.2 to 3.3 migration guide, and the 3.3 beta page list the removals under "Withdrawn from the deprecated tasks".

docs/building/by-layer/L1/wba-profile.mdx

@@ -197,7 +197,7 @@ An unsigned request to an operation in `required_for`, from a caller with no oth
 
 A webhook signed under this profile is an ordinary signed request from the seller's identity. The seller signs the delivery with the rules in [Profile rules](#profile-rules). Its `Signature-Agent` member names the seller's origin, and the signature covers `content-type` and `content-digest`. The receiver resolves the seller's keys from the seller's key directory with the same one resolution rule, and applies [Verification](#verification) and [Replay protection](#replay-protection) as a seller does.
 
-A subscriber states which profile it verifies in the optional `signing_profile` field of every webhook registration: `push_notification_config`, `reporting_webhook`, `artifact_webhook`, `accounts[].notification_configs[]`, and the agent-level notification configuration. `web-bot-auth` selects this profile, and `adcp/webhook-signing/v1` selects the AdCP webhook profile. A registration that omits the field is signed as before: with the AdCP webhook profile, or with the legacy scheme when `authentication` is present. A registration carries `signing_profile` or `authentication`, never both, and the schemas refuse one that carries both. The field has no schema `default`, so a validator or a generated SDK that fills in defaults never adds it next to `authentication`. The seller signs every delivery to that registration with the one selected profile and never signs a delivery both ways. This keeps the mode-selection rule of [Webhook callbacks](/docs/building/by-layer/L1/security#webhook-callbacks). The two profiles encode binary header values differently: the AdCP webhook profile uses unpadded Base64URL, and this profile uses RFC 8941 Base64. A receiver therefore selects one parser from the registration and never tries both.
+A subscriber states which profile it verifies in the optional `signing_profile` field of every webhook registration: `push_notification_config`, `reporting_webhook`, `accounts[].notification_configs[]`, and the agent-level notification configuration. `artifact_webhook` on the deprecated `create_media_buy` has no `signing_profile`, so without `authentication` it is signed with the AdCP webhook profile. `web-bot-auth` selects this profile, and `adcp/webhook-signing/v1` selects the AdCP webhook profile. A registration that omits the field is signed as before: with the AdCP webhook profile, or with the legacy scheme when `authentication` is present. A registration carries `signing_profile` or `authentication`, never both, and the schemas refuse one that carries both. The field has no schema `default`, so a validator or a generated SDK that fills in defaults never adds it next to `authentication`. The seller signs every delivery to that registration with the one selected profile and never signs a delivery both ways. This keeps the mode-selection rule of [Webhook callbacks](/docs/building/by-layer/L1/security#webhook-callbacks). The two profiles encode binary header values differently: the AdCP webhook profile uses unpadded Base64URL, and this profile uses RFC 8941 Base64. A receiver therefore selects one parser from the registration and never tries both.
 
 A seller advertises the profiles it can sign webhooks with in `webhook_signing.profiles`. A seller that does not list the profile a subscriber selects rejects the configuration as a validation failure.
 

docs/creative/creative-libraries.mdx

@@ -159,8 +159,9 @@ After upload, the creative enters the library's review process. Check `list_crea
 In AdCP 3.3, a buyer can book first and assign a library creative while it is
 `pending_review` or `rejected`. The assignment persists through correction and
 review under the same ID. Eligible approved assignments serve by default;
-`start_requires_all_creatives_approved: true` on a package holds its first
-delivery until every assignment has package approval. See the [creative start policy](/docs/media-buy/specification#starting-with-assigned-creatives-under-review).
+`start_requires_all_creatives_approved: true`, set on a package through
+`control_media_buy`, holds its first delivery until every assignment has
+package approval. See the [creative start policy](/docs/media-buy/specification#starting-with-assigned-creatives-under-review).
 
 ### Prepare creatives before a time-sensitive launch