feat: add policies[] to order, decouple refund

   - Add `policies[]` to `order` as a read-only snapshot of the policies
     that applied at checkout (`ucp_request: omit`), mirroring how
     `order.attribution` snapshots checkout data. Completes the catalog ->
     cart -> checkout -> order lifecycle; returns are post-purchase, so the
     order is the durable home for their terms.
   - Remove the refund `allOf` overlay from `policy.json` and delete the
     now-empty `policy_refund.json`. Core stays a pure generic container;
     the refund type attaches its body via extension composition (#257).
   - Type `policy.type` via `$ref` to `reverse_domain_name.json`, so the
     reverse-DNS format is enforced rather than described only in prose.
   - State in Precedence that a Platform MUST NOT merge same-type policy
     bodies: a consumer cannot infer combine-vs-replace semantics, so it
     resolves a single governing policy by structure alone. Composition is
     authored into the most-specific policy, not resolved at read time.
   - Collapse the disclosure-pairing passage to one paragraph plus two
     numbered rules (editorial).

Author: igrigorik

docs/specification/order.md

@@ -94,6 +94,11 @@ Businesses MAY surface a snapshot of the originating checkout's
 `order.attribution`. See [Attribution](overview.md#attribution) for the
 underlying contract.
 
+### Policies
+
+Businesses MAY surface a snapshot of the policies that applied at checkout on
+the order. See [Policies](overview.md#policies) for the underlying contract.
+
 ### Adjustments
 
 **Adjustments** are post-order events that exist independently of

docs/specification/overview.md

@@ -2280,7 +2280,7 @@ presenting the policy from its `description` (see
 
 `applies_to` is an array of RFC 9535 JSONPath expressions, evaluated relative to
 the **embedding response root** — the same convention `messages[].path` uses.
-The root differs by surface: `$.line_items[N]` on cart and checkout,
+The root differs by surface: `$.line_items[N]` on cart, checkout, and order,
 `$.products[N]` on catalog search and lookup, `$.product` on get_product. A
 policy targets nodes in one of three forms:
 
@@ -2306,9 +2306,12 @@ Policies of **different** `type` are independent: each applies on its own, so a
 single node can carry a warranty policy and a price-match policy at once.
 
 Policies of the **same** `type` can contest a node. When they do, exactly one
-governs and **replaces** the rest at that node — same-type policies do not
-compose, so their bodies are never merged. Resolving which one governs is a
-**longest-prefix match** against the response in hand.
+governs and **replaces** the rest — a Platform **MUST NOT** merge their bodies.
+Merging would mean inferring whether policies combine or replace, which a
+Platform cannot read from the data; resolution selects one governing policy by
+structure alone. When terms genuinely stack, the Business folds them into the
+most-specific policy — composition is authored, not resolved. Resolving which
+one governs is a **longest-prefix match** against the response in hand.
 
 Every node has a canonical identity: its **Normalized Path** ([RFC 9535
 §2.7](https://www.rfc-editor.org/rfc/rfc9535#section-2.7)), the sequence of
@@ -2371,14 +2374,12 @@ final-sale terms to regulatory notices.
 
 A disclosure pairs with the policy that **governs** its `path` node — the one
 [Precedence](#precedence) selects when several policies of the same `type` cover
-that node. Precedence yields at most one such policy, so the pairing is
-unambiguous.
-
-Two authoring rules apply:
+that node. Precedence yields at most one, so the pairing is unambiguous. Two
+rules apply:
 
 1. A disclosure's content **MUST** agree with the policy it pairs with — the
    notice and the policy are two statements about the same node.
-2. A disclosure **SHOULD** resolve to a governing policy. When its `code` names
+2. A disclosure **SHOULD** resolve to a governing policy: when its `code` names
    a `type` no policy covers at that node, the notice still displays, but
    nothing structured stands behind it.
 

source/schemas/shopping/order.json

@@ -96,6 +96,14 @@
       "$ref": "types/totals.json",
       "description": "Different totals for the order."
     },
+    "policies": {
+      "type": "array",
+      "items": {
+        "$ref": "types/policy.json"
+      },
+      "description": "Snapshot of the policies that applied to the items at checkout, captured on the order as a durable record. `applies_to` targets are relative to the response root.",
+      "ucp_request": "omit"
+    },
     "messages": {
       "type": "array",
       "items": {

source/schemas/shopping/types/policy.json

@@ -11,7 +11,7 @@
   "additionalProperties": true,
   "properties": {
     "type": {
-      "type": "string",
+      "$ref": "../../common/types/reverse_domain_name.json",
       "description": "Policy type discriminator. Open reverse-DNS vocabulary. Well-known values: `dev.ucp.shopping.policy.refund` (return/refund terms), `dev.ucp.shopping.policy.warranty` (warranty terms). Businesses MAY define custom types in their own domain (e.g., `com.example.policy.price_match`). Platforms MUST tolerate unknown values."
     },
     "description": {
@@ -30,22 +30,5 @@
       "format": "uri",
       "description": "Optional link to the full policy document."
     }
-  },
-  "allOf": [
-    {
-      "if": {
-        "required": [
-          "type"
-        ],
-        "properties": {
-          "type": {
-            "const": "dev.ucp.shopping.policy.refund"
-          }
-        }
-      },
-      "then": {
-        "$ref": "policy_refund.json"
-      }
-    }
-  ]
+  }
 }