docs(consent): exempt buyer.consent from the cart and checkout full-replacement rules

docs/specification/shopping/cart/index.md

@@ -214,6 +214,11 @@ Performs a full replacement of the cart session. The platform **MUST** send
 the entire cart resource. The provided resource replaces the existing cart
 state on the business side.
 
+Captured `buyer.consent` is an exception when the buyer-consent capability is
+active: an update that omits `consent` MUST NOT clear previously submitted
+consent. See [Buyer Consent](../extensions/buyer-consent.md#normative-requirements) for
+the persistence rule.
+
 * [REST Binding](rest.md#update-cart)
 * [MCP Binding](mcp.md#update_cart)
 

docs/specification/shopping/checkout/index.md

@@ -1083,6 +1083,11 @@ general replacement rule does not apply during `complete_in_progress` because
 Update Checkout is not permitted; see
 [Accepted completion](#accepted-completion) for the frozen operation contract.
 
+Captured `buyer.consent` is also an exception when the buyer-consent capability
+is active: an update that omits `consent` MUST NOT clear previously submitted
+consent. See [Buyer Consent](../extensions/buyer-consent.md#normative-requirements)
+for the persistence rule.
+
 {{ method_fields('update_checkout', 'shopping/rest.openapi.json', 'shopping/checkout') }}
 
 ### Complete Checkout

docs/specification/shopping/checkout/rest.md

@@ -237,12 +237,20 @@ supplied resource replaces the existing Checkout session state. The Platform
 new Update Checkout request in that state, it **MUST** leave the Checkout
 unchanged and return the current Checkout with a recoverable error Message.
 
+When the buyer-consent capability is active, captured `buyer.consent` is exempt
+from the full replacement: an update that omits `consent` MUST NOT clear
+previously submitted consent. See
+[Buyer Consent](../extensions/buyer-consent.md#normative-requirements).
+
 #### Update Buyer Info
 
 All fields in `buyer` are optional, allowing the Platform to progressively build
 the Checkout state across multiple calls. Outside `complete_in_progress`, each
 Update Checkout replaces the entire Checkout session, so the Platform **MUST**
-include all previously set fields it intends to retain.
+include all previously set fields it intends to retain. Captured `buyer.consent`
+is the exception when the buyer-consent capability is active: an update that omits
+`consent` MUST NOT clear it (see
+[Buyer Consent](../extensions/buyer-consent.md#normative-requirements)).
 
 === "Request"
 

docs/specification/shopping/extensions/buyer-consent.md

@@ -371,7 +371,16 @@ Handling](../checkout/index.md#error-handling) flow.
 
 2. **Confirm semantics.** The `consent` field is optional on requests;
    omitting it provides no consent update and the business retains its prior
-   position. When submitting `consent`, platforms MUST include every advertised
+   position. This persistence is an explicit exception to the cart and checkout
+   full-replacement rules (see
+   [Update Cart](../cart/index.md#update-cart) and
+   [Update Checkout](../checkout/index.md#update-checkout)): a business
+   MUST retain the last submitted `buyer.consent` state across subsequent cart
+   or checkout updates that omit `consent`, and MUST NOT reset it to
+   advertised defaults, so that an update sent for an unrelated field (for
+   example a fulfillment change) does not silently discard captured consent.
+   When submitting `consent`,
+   platforms MUST include every advertised
    purpose and segment key, carrying both `granted` and `source` for each.
    Omitting an advertised key within a submitted `consent` map MUST NOT be
    used to signal any value.