Repository navigation
Version Packages - #8942
Version Packages#8942aao-release-bot[bot] wants to merge 1 commit into
Conversation
…se docs - #8858 merged: drop its markers on the 3.3 support window and the daily-budget spec. - #8864 merged into 3.2.x, so the schema opening ships in 3.2.11: say "3.2.11 (#8864)" instead of "the next 3.2.x patch", with one marker per page on the 3.2.11 release itself (Version Packages #8942). - target_audiences on list_products offer_filters is decided: it stays as it is in 3.3, and any change is 4.x, so media_buy.audience_evidence_targets has no 3.3 surface once the get_products and create_media_buy copies leave. - The available_installment_statuses move is a 3.3 RC item; its markers now point at c4777ebd's PR, and the release-notes installment_lifecycle row carries a marker to move to the canonical location when it lands. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
HOLD: generated release branch requires human reconciliation/review. Automation is preparing a leased update. The PR must remain Draft. |
f0cea82 to
3175211
Compare
|
HOLD: generated release branch requires human reconciliation/review. Release PR changed or left Draft. Prior ref restored and verified. |
3175211 to
f0cea82
Compare
|
HOLD: generated release branch requires human reconciliation/review. Incomplete or previously quarantined action. Prior ref restored and verified. |
…se docs - #8858 merged: drop its markers on the 3.3 support window and the daily-budget spec. - #8864 merged into 3.2.x, so the schema opening ships in 3.2.11: say "3.2.11 (#8864)" instead of "the next 3.2.x patch", with one marker per page on the 3.2.11 release itself (Version Packages #8942). - target_audiences on list_products offer_filters is decided: it stays as it is in 3.3, and any change is 4.x, so media_buy.audience_evidence_targets has no 3.3 surface once the get_products and create_media_buy copies leave. - The available_installment_statuses move is a 3.3 RC item; its markers now point at c4777ebd's PR, and the release-notes installment_lifecycle row carries a marker to move to the canonical location when it lands. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…se docs - #8858 merged: drop its markers on the 3.3 support window and the daily-budget spec. - #8864 merged into 3.2.x, so the schema opening ships in 3.2.11: say "3.2.11 (#8864)" instead of "the next 3.2.x patch", with one marker per page on the 3.2.11 release itself (Version Packages #8942). - target_audiences on list_products offer_filters is decided: it stays as it is in 3.3, and any change is 4.x, so media_buy.audience_evidence_targets has no 3.3 surface once the get_products and create_media_buy copies leave. - The available_installment_statuses move is a 3.3 RC item; its markers now point at c4777ebd's PR, and the release-notes installment_lifecycle row carries a marker to move to the canonical location when it lands. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
HOLD: generated release branch requires human reconciliation/review. Automation is preparing a leased update. The PR must remain Draft. |
f0cea82 to
4652e12
Compare
|
HOLD: generated release branch requires human reconciliation/review. Release PR changed or left Draft. Prior ref restored and verified. |
4652e12 to
f0cea82
Compare
|
HOLD: generated release branch requires human reconciliation/review. Incomplete or previously quarantined action. Prior ref restored and verified. |
…se docs - #8858 merged: drop its markers on the 3.3 support window and the daily-budget spec. - #8864 merged into 3.2.x, so the schema opening ships in 3.2.11: say "3.2.11 (#8864)" instead of "the next 3.2.x patch", with one marker per page on the 3.2.11 release itself (Version Packages #8942). - target_audiences on list_products offer_filters is decided: it stays as it is in 3.3, and any change is 4.x, so media_buy.audience_evidence_targets has no 3.3 surface once the get_products and create_media_buy copies leave. - The available_installment_statuses move is a 3.3 RC item; its markers now point at c4777ebd's PR, and the release-notes installment_lifecycle row carries a marker to move to the canonical location when it lands. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and publish to npm yourself or setup this action to publish automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to 3.2.x, this PR will be updated.
Releases
adcontextprotocol@3.2.11
Patch Changes
creative/policy_backed_rejectionsfailing sellers that do not enforce registry policies (adcp#8850). The storyboard seeds a product withenforced_policiesthrough the controller and then asserted that the seller published and enforced both fixture policies, so a seller that never claimed registry policy enforcement failed it. The 3.2 schemas have no capability a seller can use to opt out, so this patch gates on what the seller publishes instead: the discovery read now asserts only a schema-validget_productsresponse and captures the returned products, and the policy-universe confirmation and the dual-violationsync_creativesphases run only when the first discovered product carries a non-emptyenforced_policieslist. The gate reads the seller's response, not the controller seed. A seller that omits the field, publishes an empty list, or returns no products underrequired_policiesis not sent the violating creative and is not failed; its enforcement phases are skipped. A seller that publishes any enforced policy runs every step and is still graded on the exact two-policy universe and the one-CREATIVE_REJECTED-entry-per-policy result. No schema fields change. The 3.3 line gates the storyboard on the newcreative.supports_registry_policy_enforcementcapability instead (adcp#8857).rate_abusevector grades (adcp#8877). Functional dispatch intest-kits/signed-requests-runner.yamlsigned withtest-ed25519-2026, the same keyid vector 020-rate-abuse caps at 100 for the test counterparty, so a full compliance run could hit the cap before the signed-requests vectors started and fail them withrequest_signature_rate_abuse. Functional dispatch now signs with a dedicatedtest-functional-2026Ed25519 key that no conformance vector uses, published in the request-signingkeys.jsonand declared inrunner_signing_keys. Therate_abuseblock now states that agents MAY lower the per-keyid cap to the grading target for the vector 020 keyid (test-ed25519-2026) only, and MUST NOT apply the lowered cap to the functional-dispatch keyid. Sellers that register the runner signing keys individually rather than loading the publishedkeys.jsonmust addtest-functional-2026to their test counterparty. Sellers that configure one global per-keyid cap on their replay store (as the SDK reference stores take, e.g.maxEntriesPerKeyid: 100) must scope the lowered cap totest-ed25519-2026, for example with a keyid-aware wrapper, or functional storyboards hit the cap ontest-functional-2026instead.