portage-cli 0.10.0 → 0.12.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: c506344f3b17a2ea4199f84efaf70d658b0debec2fe03d167b847c58617e800b
-  data.tar.gz: 20c00c246e59fa9059611f7bb54380140295eada2c5deb457a11ec94309c1b04
+  metadata.gz: 4e0a17085649f21644b4e373afc590ab69b92cfdbf23c4b83fbf7ed33b1cc1c8
+  data.tar.gz: 75e4435e369e70f529af29ce9891208615d2f0d458df616dbf11a032f8276ed3
 SHA512:
-  metadata.gz: 9a3eff64f57ab81774a2a52034232a4667227aaff13aa7279d26dd41cf52faeafeea691711755fb41fd2f3a0a67f77d144d248d48c2631779a49c10bec9f2882
-  data.tar.gz: ade0a2ba64ba928ec1272a8902858bad1f79897f5059d428528b8978e4045047ee1a0e6e2579dc2f8a468fa73b0c3491cc66c48f2bc1a18951600e05bd2a25e1
+  metadata.gz: d79a48ad6cf39bad956cafbb2e9f3317485af02a14fa3305306a4185839ce3add20326025e9eb4cfa0e0e1709ecbade149b5b2e9109627fb9b3b6112f11e91ed
+  data.tar.gz: 5bbf4e713f496fef30925cb4f59de1ad929e1a51b960c804f6bb60bbce39c8dd0856d3efcd5641f175a25bebfd7868358d63a827d0e6123a3d5b9763a7d27ead

data/CHANGELOG.md

@@ -6,6 +6,135 @@ pre-1.0, so APIs may still shift between minor versions.
 
 ## [Unreleased]
 
+## [0.12.0] - 2026-10-01
+
+- **Release note: the confidence check wants `portage-ucp-decision` 0.1.2.** `portage-ucp-decision` stays an optional install, not a dependency, but 0.1.2 is the version that rejects a malformed backend answer (see its changelog); the README says so.
+
+- **`find --store URL --query Q [--max-price N]` searches one store, live.** The index-search hint, the `buy` skill and the docs already told agents to re-check an index hit this way, but `find` had no `--store`. It now skips the search backends and retailer offer sources and probes and searches only that store's catalogue (read-only: never a cart or checkout), with offers, `offer_ref`, `search_id` and the history entry shaped like any find, so `pick` and `buy --offer` work on them. A hand-off-only host is never fetched and is reported as such; a store without UCP is reported as having no catalogue; a non-http(s) URL is a usage error. The index-search hint now reads `find --store URL --query ...`.
+
+- **Security: a priced line nobody asked for is a checkout mismatch.** `buy` requests exactly one
+  line, but only checked that line, so a store that added an upsell, a "shipping protection"
+  add-on or a second copy of the item (or, on a WebMCP cart, whatever was already in the store's
+  cart) still went through. Any other line now stops a real run with `checkout_mismatch` ("Store
+  added ... to checkout, which wasn't requested."), and a dry run flags it with
+  `checkout_mismatch: true`. An extra line that costs nothing (its own total, or its unit price
+  times quantity, is 0) is allowed, so a free gift or $0 sample doesn't block a purchase; one
+  whose cost can't be read counts as priced.
+
+- **Security: the confidence check sends an allowlisted summary, and compares against the
+  approved quote.** The state sent to the decision backend (`PORTAGE_DECISION_BACKEND`, e.g.
+  `jev`, TypeSafe's hosted API) used to be a slice of the raw checkout hash, so whatever a store
+  nested under `line_items` or `totals` went along with it. It is now built field by field by the
+  new `Portage::Cli::ConfidenceState`: the request (query, store host, quantity, picked item id
+  and title), on a `buy --quote` run the approved quote (store, product id, title, quantity,
+  total, currency), and the checkout's status, currency, per-line item id, title, unit price,
+  quantity, totals and whether it's the requested line, the totals (shipping, tax, fees included),
+  applied discounts' titles and amounts and the selected shipping option's title and price, plus
+  `warnings`. Never the payment token, the address, the buyer's name, phone or email, ids, links,
+  discount codes or environment values; store strings are cut to 200 characters. The question
+  now asks the model to say yes only when the checkout matches the request and the approved
+  quote. `Buy.new` takes `quote_store:` and `quote_title:`, which `buy --quote` passes from the
+  saved quote. The check stays additive: it only sees a checkout the mismatch check, the quote
+  cap and the spend policy let through, and can hold it but never let through one they stop.
+
+- **Security: the non-preset WebMCP hand-off runs the confidence check too.** A page whose WebMCP
+  tools build a checkout (no preset, so `buy` ends in `express_stop` through `finish_checkout`)
+  applied the quote cap and the mismatch stop but not the opt-in confidence check. With a decision
+  backend enabled it now runs before the hand-off, after those two. A hold reports `low_confidence`
+  with the store's `/cart` page as `checkout_url`, as the preset flow's does, and nothing is handed
+  to the checkout (a `profile` target is not navigated there). A backend error holds the same way.
+  No backend enabled: unchanged.
+
+- **Security: the WebMCP hand-off flow runs the quote cap and the confidence check.** Against a
+  page whose preset opens checkout through its own tool (Shopify's `proceed_to_checkout`), `buy`
+  now checks, before that tool runs and before autofill: a `--quote` run's cap (`quote_changed`,
+  never handed off; this flow never checked the quote before), the mismatch check, then, when a
+  decision backend is enabled, the confidence check. A hold reports `low_confidence` with the
+  store's `/cart` page as `checkout_url`; checkout isn't opened and nothing is autofilled. A
+  backend error holds the same way.
+
+- **Security: a quote with no total refuses instead of buying uncapped.** `buy --quote` capped the
+  checkout at the quote's total only when the quote had one. A quote saved from a dry run with no
+  priced total (a WebMCP preset dry run never has one) set no cap at all, so its `--yes` run
+  bought at whatever the store asked. It now ends in `quote_changed`, saying the quote has no
+  total, and nothing is bought or handed off.
+
+- **Security: a checkout mismatch always stops the purchase.** `buy` used to stop on a checkout
+  that didn't match the request (the item dropped, another quantity, another unit price) only under
+  `PORTAGE_ABORT_ON_CHECKOUT_MISMATCH`. Without it the mismatch was a `warnings` entry and the
+  purchase went ahead, so a real `--yes` run could pay for the wrong checkout and report
+  `purchased` (reported by ClawHub's security audit of the `portage-buy` skill). Now every
+  mismatch on a run that isn't `--dry-run` escalates (`decisions.escalation.reason: "mismatch"`)
+  and ends in `checkout_mismatch` before the payment token, policy and completion are reached. The
+  quote it ran under is spent, so the person dry-runs again for a new one. There is no opt-out:
+  `PORTAGE_ABORT_ON_CHECKOUT_MISMATCH` is deprecated and ignored, whatever its value. A
+  `--dry-run` keeps its `dry_run` outcome and `warnings`, and now adds `checkout_mismatch: true`
+  and says in `message` that a real run would stop. The check also compares currency: a checkout
+  in another currency than the catalog's price is a mismatch. The quoted total and currency are
+  still `--quote`'s `quote_changed` check, unchanged.
+
+- **Security: the WebMCP hand-off flow stops on a mismatched cart too.** Against a WebMCP page
+  whose preset opens checkout through its own tool (Shopify's `proceed_to_checkout`), `buy` read
+  the cart back and checked it, but only put a mismatch in `warnings`: it still called the hand-off
+  tool, sending the browser tab to the store's checkout, and ran autofill there when it was
+  approved. Now any mismatch stops the run before that tool, with outcome `checkout_mismatch` and
+  `decisions.escalation.reason: "mismatch"`. Nothing is autofilled, and `checkout_url` is the
+  store's `/cart` page, so the shopper can look at the cart that was built. A matching cart hands
+  off as `express_stop`, as before. The dry run of this flow builds no cart, so it can't check one
+  and never carries `checkout_mismatch: true`.
+
+## [0.11.0] - 2026-10-01
+
+- **Category classification uses the whole taxonomy.** `known-stores/categories.yml` is now generated
+  by `script/categories` (stdlib only) from Google's product taxonomy, edition 2021-09-21, instead of
+  coming from a script that was never committed. It keeps the same ids and the same top-two-level keys
+  (so `~/.portage/categories.yml` overrides still work), but a level-2 node's `keywords` now include
+  its descendants' names ("Chandeliers" counts for Lighting), and its parent's words sit in a separate
+  `parent_keywords` list. The file grows from 20KB to 101KB. A shipped stoplist
+  (`known-stores/category-stoplist.yml`, every word with its reason) removes merchandising and url words
+  ("new", "collection", "sale", "gift", "accessories", "products", ...) from both the data and the input,
+  and a small synonyms file (`category-synonyms.yml`, each word tied to a golden case) adds the few
+  words the taxonomy lacks ("pendant", "sconce"). `Classifier.categories_for` keeps its signature (plus
+  an optional `stoplist_path:`) and returns at most three ids, best first. Scoring: a keyword counts
+  2 and a `parent_keyword` 1, times how often the input repeats the word (1 + ln count) and, for the
+  cut, how rare it is. A word counts once per node, and an id scoring under half the strongest is
+  dropped. Ties go to the node whose own name the input covers most, then to one whose name has no
+  stoplisted word, then to the smaller node. On a 100-case golden set (Light Yard, JB Hi-Fi, shopper
+  queries, browser-import titles and urls) top-1 accuracy goes from 12% to 70%. "Pendant Light" is
+  Lighting, "New Collection" is no longer Toll Collection Devices, and 160 of Light Yard's 164 products
+  classify as Lighting (1 before). Products already in the index keep the category they were crawled
+  with: crawl the store again (`portage index build --sources storefront_products`) to re-classify them.
+- **The local index is now a SQLite file.** `~/.portage/index/index.sqlite3` (mode 0600, WAL)
+  replaces `stores.json` and `products.json`, through the new `sqlite3` gem dependency (`~> 2.9`,
+  precompiled for macOS and Linux). An existing `stores.json`/`products.json` is imported once on
+  first use and renamed to `*.json.migrated`; it is never deleted. `Index::Store` and
+  `Index::ProductStore` keep their APIs, and `ProductStore#upsert_many` writes a batch in one
+  transaction. Index write failures now raise instead of being dropped. `portage doctor` reports the
+  database path, row counts and whether FTS5 is available. The known-stores cache and `index export`
+  output stay JSON.
+- **Storefront catalogue crawl and `portage index search`.** A new opt-in index source,
+  `storefront_products`, reads a Shopify store's public `/products.json` into the local index. Run it
+  with `portage index add URL --crawl` for one store, or `portage index build --sources
+  storefront_products` for stores already indexed (25 a run, least recently crawled first). Each
+  product is mapped through the UCP `Product` shape and stored with its handle, URL, first image,
+  options and variant ids. Price and availability are dropped before anything is written. A crawl
+  reads at most 20 pages of 250 a store, 1s apart. It waits out one 429's `Retry-After` (capped at 60s)
+  and stops on a second, and it obeys `robots.txt` for every page URL. It never contacts a hand-off-only
+  host, and it skips a 404, a redirect or a non-JSON answer (a bot wall). What happened is kept on the
+  store entry as `crawl`. `portage index search QUERY [--category ID] [--store HOST] [--limit N]
+  [--json]` searches the index locally with SQLite FTS5, ranked by bm25, and sends no request. Without
+  FTS5 it falls back to an unranked text match and reports `engine: "like"`. `index show --products` now
+  pages (`--page N`, `--per-page N`, default 50). `portage check` suggests the `index add ... --crawl`
+  command for a Shopify or native-UCP store (`index_hint`) but never runs it. `find` and `buy` never
+  crawl.
+- **Product cards for agents.** `find` offers (and `shopify_catalog` offers) gain a `product` field:
+  the store's UCP `Product` wire hash as served, with `media` cut to the first image, so an agent or
+  UI can draw a card without another request. The flat fields (`title`, `amount`, `currency`, `url`,
+  `product_id`, `store`) are unchanged, the retailer API sources leave `product` out, and `history`
+  does not save it. `portage index search` results are marked `live: false` and each hit gains
+  `product`, built from the fields the index keeps (title, handle, URL, first image, options, variant
+  ids, category), never a price. Text output says the hits are not live.
+
 ## [0.10.0] - 2026-09-29
 
 - **`portage check <url> [--json]`.** Reports whether Portage can buy from a store and

data/README.md

@@ -29,6 +29,20 @@ portage find --query "burton snowboard" --max-price 400
 
 `portage buy` with no URL runs that search and then buys the offer you pick.
 
+Already know the store? `portage find --store URL --query "..."` skips the search
+backends and offer sources and searches only that store's catalogue, live and
+read-only (catalogue search only, never a cart or checkout). Use it to re-check
+an index hit or an earlier offer before quoting its price or stock. The report
+has the same shape as a normal find (`offer_ref`, `search_id`, a history entry),
+so `pick` and `buy --offer` work on its offers. A hand-off-only host is never
+fetched and is reported as such; a store that doesn't speak UCP is reported as
+having no catalogue, with exit code 1 (as for any find with no offers). `--store`
+must be an http(s) URL (a bare host is read as https).
+
+```bash
+portage find --store https://shop.example --query "cold brew" --json
+```
+
 Already have the item and want to know where else it's sold? `portage compare`
 resolves a product you name by URL + product id, then runs the same
 find pipeline against its title and ranks the results by how confident the
@@ -131,6 +145,7 @@ portage buy --offer REF [--qty N] [--yes] [--dry-run] ...
 portage buy --quote QUOTE_ID --yes [--json] ...
 portage buy --query "..." [--store URL] [--max-price N] [--limit N] ...
 portage find --query "..." [--max-price N] [--limit N] [--json]
+portage find --store URL --query "..." [--max-price N] [--json]
 portage compare <url> --product-id ID [--id VALUE ...] [--results N]
                        [--max-price N] [--json]
 portage check <url> [--json]
@@ -155,8 +170,9 @@ portage policy set [--per-transaction-cap N --currency CUR]
 portage orders reconcile [--checkout ID] [--json]
 portage index build [--sources a,b] [--queries FILE] [--dry-run] [--export DIR] [--json]
 portage index refresh [--sources a,b] [--queries FILE] [--dry-run] [--export DIR] [--json]
-portage index show [--stores|--products] [--json]
-portage index add <url> [--json]
+portage index show [--stores|--products [--page N] [--per-page N]] [--json]
+portage index search QUERY [--category ID] [--store HOST] [--limit N] [--json]
+portage index add <url> [--crawl] [--json]
 portage index remove <host> [--json]
 portage index sources [--json]
 portage browser import [--browser chrome|edge|brave|arc|firefox|safari] [--profile-root DIR]
@@ -478,13 +494,16 @@ portage index build --sources shopify_catalog,stores_file
 portage index build --queries queries.txt    # one query per line, instead of the built-in taxonomy sweep
 portage index refresh                        # re-verify entries older than 7 days, add new ones
 portage index show --stores --json
-portage index show --products --json
+portage index show --products --page 2 --json   # 50 a page; --per-page N
+portage index search "wall light" --store some-shop.example --json
 portage index add https://some-shop.example
+portage index add https://some-shop.example --crawl   # also read its /products.json catalogue
+portage index build --sources storefront_products     # crawl the catalogues of stores already indexed
 portage index remove some-shop.example
 portage index sources                        # name, what each fetches, source file path
 ```
 
-Stored at `~/.portage/index/{stores,products}.json`, **never in git** and
+Stored in `~/.portage/index/index.sqlite3` (mode 0600), **never in git** and
 **never containing a price or stock field** — those are always fetched live.
 Each new origin gets exactly one `/.well-known/ucp` probe (capped at 500 new
 probes per run), throttled, with progress output. Sources:
@@ -496,6 +515,18 @@ probes per run), throttled, with progress output. Sources:
 | `browser` | Whatever `portage browser import` (below) already saved — this source itself never reads a browser | on, but yields nothing unless you've run `browser import` |
 | `wikidata` | Retailers'/brands' official sites via a public SPARQL query | opt-in (`--sources wikidata`) |
 | `webmcp_sweep` | Which WebMCP preset an origin matches, when a bridge is attached | opt-in, needs a bridge |
+| `storefront_products` | Each indexed Shopify store's own `/products.json`: title, brand, handle, URL, first image, options and variant ids, mapped through the UCP `Product` shape with price and availability dropped | opt-in (`--sources storefront_products`, or `index add URL --crawl`) |
+
+**Catalogue crawls are polite and opt-in.** `storefront_products` never runs
+from `find` or `buy` (`portage check` only prints the `index add ... --crawl`
+command). It crawls at most 20 pages of 250 products a store and 25 stores a
+run, least recently crawled first, 1s apart. It waits out one 429's
+`Retry-After` (capped at 60s) and stops that store on a second. It obeys
+`robots.txt` for every page URL, never contacts a hand-off-only host, and
+skips a store that answers 404, a redirect or anything but products JSON (a
+bot wall). What happened is kept on the store entry as `crawl`.
+`portage index search` then searches those products locally (SQLite FTS5,
+or a plain text match if FTS5 is missing), with no request.
 
 **The index is untrusted data, on the same footing as any other `find`
 candidate.** It never feeds `Policy#merchant_allowlist` and never counts as
@@ -795,6 +826,30 @@ checkout tool (Shopify's `proceed_to_checkout`) stops after the read-only
 product search: nothing is added to the store's cart, the tab isn't sent to
 checkout and nothing is autofilled. The `dry_run` report carries a `would:`
 key with the line item, the hand-off tool and whether autofill would run.
+Because it builds no cart, it can't check one, so it never carries
+`checkout_mismatch: true`.
+
+A real run against that kind of page reads the cart back after adding to it
+and checks it the same way `buy` checks any checkout (item, quantity, unit
+price, currency, extra lines). Any mismatch stops the run there, with outcome
+`checkout_mismatch` and `decisions.escalation.reason: "mismatch"`: the
+hand-off tool isn't called, so the tab never goes to checkout, and nothing is
+autofilled. The cart is already on the store, so `checkout_url` is the
+store's `/cart` page, for the shopper to look at. Items already sitting in
+the store's cart count as extra lines, so they stop the run too.
+
+The same run then applies the other gates a checkout gets before anything
+leaves the cart: a `--quote` run's cap (`quote_changed`), and, when a
+decision backend is enabled, the confidence check (see "Decisions"). A hold
+from the confidence check reports `low_confidence` with the `/cart` page as
+`checkout_url`; again the tab isn't sent to checkout and nothing is
+autofilled.
+
+A page whose WebMCP tools build a checkout (no preset) gets the same confidence
+check before its `express_stop` hand-off, after the quote cap and the mismatch
+stop. A hold reports `low_confidence` with the `/cart` page as `checkout_url`
+and no navigation to the checkout, so a `profile` hand-off target is never sent
+there. With no decision backend enabled, nothing changes.
 
 Once the flow hands off to the store's own checkout page, the shopper can
 opt into having it pre-filled: `--autofill`, or
@@ -826,7 +881,9 @@ gem install portage-ucp-decision   # only needed for the confidence gate
 ```
 
 The confidence gate is the one feature that needs the gem, because the
-model backends live there.
+model backends live there. Use `portage-ucp-decision` 0.1.2 or newer: it
+rejects a backend answer that isn't a probability between 0 and 1, where
+0.1.1 let an answer above 1 clear any threshold.
 
 Every `portage buy` report carries an `outcome`, so a script or agent loop
 can branch on data rather than on the message text. The text output leads
@@ -836,12 +893,12 @@ with the same value, as `[outcome]`.
 | --- | --- | --- |
 | `purchased` | Completed. | no |
 | `needs_confirmation` | Checkout ready; rerun with `--yes`. | no |
-| `dry_run` | Checkout created, `--dry-run` stopped it. | no |
+| `dry_run` | Checkout created, `--dry-run` stopped it. `checkout_mismatch: true` when a real run would stop on a mismatch. | no |
 | `requires_escalation` | The store wants the shopper to finish. | yes |
-| `checkout_mismatch` | Checkout differs from the request (`PORTAGE_ABORT_ON_CHECKOUT_MISMATCH`). | yes |
+| `checkout_mismatch` | Checkout differs from the request (item, quantity, unit price, currency, or a priced line nobody asked for); stopped before payment. | yes |
 | `no_payment_token` | No `--payment-token` and no default payment method. | yes |
 | `policy_blocked` | Your spend policy denied it; `decisions.policy.reason` says why. | yes |
-| `low_confidence` | The confidence gate held it. | yes |
+| `low_confidence` | The confidence gate held it (before a `--yes` completion, or before a WebMCP hand-off to checkout, preset or not). | yes |
 | `permission_denied` | The store doesn't let this agent complete checkout. | yes |
 | `handoff_only` | Tier C: Amazon or another hand-off-only host. `legal_notice` explains why; see "Hand-off targets and hand-off-only hosts". | yes (built, never fetched) |
 | `store_refused` | The store refused a cart/checkout call (e.g. sold out). | when the store gave one |
@@ -868,9 +925,15 @@ Every verdict has a `reason`: `null` when the gate let the purchase through,
 otherwise a string naming why it stopped it.
 
 - **escalation** — `Support::Escalation`. A `requires_escalation` checkout
-  always escalates (`reason: "requires_escalation"`). A checkout that doesn't
-  match the request escalates (`reason: "mismatch"`) only under
-  `PORTAGE_ABORT_ON_CHECKOUT_MISMATCH`; otherwise it's reported as `warnings`.
+  always escalates (`reason: "requires_escalation"`). So does a checkout that
+  doesn't match the request (`reason: "mismatch"`), on every run but
+  `--dry-run`, where the mismatch is reported in `warnings` and flagged with
+  `checkout_mismatch: true` instead. Nothing turns this off:
+  `PORTAGE_ABORT_ON_CHECKOUT_MISMATCH` is deprecated and ignored. A mismatch
+  is the requested line missing, a different quantity, a different unit
+  price or currency than the store's own catalog, or any extra line the
+  request didn't include. An extra line that costs nothing (a free gift, a
+  $0 sample) is allowed; one whose cost can't be read counts as priced.
 - **policy** — `PolicyGuard`, run on your policy file (see "Policy" above)
   before any `--yes` completion. `reason` is the guard's own
   (`per_transaction_cap_exceeded`, `rolling_spend_cap_exceeded`,
@@ -885,16 +948,39 @@ otherwise a string naming why it stopped it.
   when the store answers that it's purchased.
 - **confidence** — `ConfidenceGate`, off unless `--decision-backend` or
   `PORTAGE_DECISION_BACKEND` names a backend. Right before a `--yes`
-  completion it asks the backend whether the checkout matches the request
-  and is safe to complete unattended. It sends the query, merchant,
-  quantity, line items, totals and warnings, never the payment token. The
-  gate fails closed, so three things hold the purchase: a score below the
-  threshold (`reason: "below_threshold"`), a backend that can't answer
-  (`"backend_error"`), and naming a backend without `portage-ucp-decision`
-  installed (`"not_installed"`). For the last two, `error` says what went
-  wrong. `jev` needs `JEV_API_KEY`; `laya` needs `LAYA_BRIDGE_SCRIPT` (see
-  `portage-ucp-decision`'s README). `portage doctor` flags whichever of
-  these is missing for the selected backend.
+  completion, and before a WebMCP preset flow sends the browser to the
+  store's checkout (and autofills it), it asks the backend whether the
+  checkout matches the request, and the approved quote on a `--quote` run,
+  and is safe to complete unattended. It is additive only: it runs after
+  the mismatch check, the quote cap and the spend policy, on a checkout all
+  of them let through, so it can hold a purchase but never let through one
+  they would stop. The gate fails closed, so three things hold the
+  purchase: a score below the threshold (`reason: "below_threshold"`), a
+  backend that can't answer or answers with something that isn't a
+  probability (`"backend_error"`), and naming a backend without
+  `portage-ucp-decision` installed (`"not_installed"`). For the last two,
+  `error` says what went wrong. `jev` needs `JEV_API_KEY`; `laya` needs
+  `LAYA_BRIDGE_SCRIPT` (see `portage-ucp-decision`'s README). `portage
+  doctor` flags whichever of these is missing for the selected backend.
+
+  `jev` is TypeSafe's hosted API, so what it's sent is kept to a minimal,
+  allowlisted summary (`Portage::Cli::ConfidenceState`); nothing else on
+  the checkout is read:
+
+  - `request`: the search query, the store's host, the quantity, and the
+    picked item's id and title.
+  - `approved_quote` (`--quote` runs only): the quote's store, product id,
+    title, quantity, total and currency.
+  - `checkout`: status, currency; per line, item id, title, unit price,
+    quantity, line totals and whether it's the requested line; the totals
+    (subtotal, shipping, tax, fees, total — whatever the store lists);
+    applied discounts' titles and amounts; the selected shipping option's
+    title and price.
+  - `warnings`.
+
+  Never sent: the payment token, the shipping address, the buyer's name,
+  phone or email, checkout ids, links and URLs, discount codes, or anything
+  from your environment. Store-supplied strings are cut to 200 characters.
 - **policy** also denies a checkout with no `total` line as
   `total_unknown` whenever a spend cap is set, rather than skipping the cap.