@blamejs/blamejs-shop 0.4.21 → 0.4.23

package/CHANGELOG.md

@@ -8,6 +8,10 @@ upgrading across more than a few patches at a time.
 
 ## v0.4.x
 
+- v0.4.23 (2026-06-06) — **A stolen sign-in cookie stops working on another device, payment-provider outages fail fast and recover, replayed payment webhooks are refused, and the staff audit log is rewrite-evident.** A security-hardening release. The signed-in session cookie now carries a device fingerprint — a cookie lifted from one browser softly signs out instead of working anywhere for two weeks. Payment-provider calls run behind a circuit breaker, so a provider brown-out fails fast into the existing payment-unavailable page and recovers automatically instead of hanging every checkout. A captured payment-webhook payload can no longer be replayed inside the signature tolerance window. And the staff-activity audit log is anchored with post-quantum checkpoint signatures, with a verification endpoint that detects any rewrite of its history. **Security:** *The sign-in cookie is pinned to the device that signed in* — The signed-in session cookie was tamper-proof but portable — exfiltrated once, it worked from any device until expiry. Signing in now embeds a fingerprint of the signing-in browser inside the sealed cookie, and every authenticated request re-checks it in constant time. A mismatch signs the visitor out gently to the sign-in page rather than failing the request mid-page; network changes don't trip it (the fingerprint deliberately excludes the IP address), and sessions issued before this release continue to work until they expire naturally. · *Payment-provider calls are circuit-broken and retried where safe* — A payment-provider brown-out previously failed every checkout serially, each waiting out the full network timeout. Provider calls now run behind a circuit breaker: repeated failures trip it, subsequent checkouts fail fast into the existing payment-unavailable page, and the circuit closes again when the provider recovers. Idempotent calls — reads and writes carrying an idempotency key — retry through brief blips; non-idempotent calls never retry. The TLS configuration for provider connections is unchanged. · *Replayed payment webhooks are refused* — A captured, validly-signed payment-webhook payload could be replayed within the signature timestamp tolerance and re-drive order transitions. Each event is now recorded on first receipt and a replay of the same event answers as an already-processed no-op — enforced with a single atomic write, so two concurrent deliveries of the same event also collapse to one. Replay records expire with the signature tolerance window. · *The staff audit log detects history rewrites* — Staff-activity audit rows were hash-linked, which catches tampering with a single row but not a consistent rewrite of the whole chain. The chain is now anchored with periodic checkpoint signatures (ML-DSA, the same signing the framework audit chain uses), and `/admin/operators/audit/verify` reports both link integrity and checkpoint verification — a rewritten history fails the check. Stores that disable destructive operations behind a second approver were also evaluated: with one active operator the gate would deadlock the store, so gift-card voids, refunds, and operator disables remain single-approver — role-gated, bounded, reversible, and audited — with the stance and its revisit condition documented in the module.
+
+- v0.4.22 (2026-06-06) — **Privacy export covers every table, erasure revokes the login, one-click unsubscribe actually works, and bounces feed the suppression list.** A privacy and email-integrity release. The data-subject export now includes reviews, consent history, wishlist, surveys, and recently-viewed data — with a manifest that makes any absent section visible. Erasing a customer also deletes their passkeys and social-login links and revokes live sessions, so a deleted account can no longer sign in. The one-click unsubscribe that mail clients invoke from their native button now works (it pointed at a route that didn't exist), a new intake endpoint feeds provider bounce and complaint webhooks into the marketing suppression list, support-ticket edge cases are fixed, and the CSV exports share one complete injection-neutralizer. **Added:** *Bounce and complaint webhook intake* — A new `POST /api/webhooks/mail-bounce` endpoint accepts bounce and complaint webhooks from Postmark, SES, or Resend (selectable per request). Spam complaints and permanently-dead addresses land on the marketing suppression list — transactional mail still flows — and campaign metrics gain the bounce events they were built to read. The endpoint is armed only when `MAIL_BOUNCE_SECRET` is set and the provider presents it in the `x-mail-bounce-secret` header; unconfigured, it answers 503 and accepts nothing. **Fixed:** *The data-subject export includes every table that holds the customer* — The export bundle silently omitted reviews, consent history, wishlist items, survey responses, and recently-viewed data. All five are now included, and the bundle carries a completeness manifest listing every section as exported, empty, or absent — an omission is visible rather than silent. · *Erasure revokes the customer's ability to sign in* — Deleting a customer scrubbed their profile but left passkeys, Google/Apple login links, and live sessions intact — the "deleted" account could sign right back in. Erasure now deletes the passkeys and social-login links, revokes live portal sessions, and tombstones the email lookup hash irreversibly, while the anonymized record survives for order-history integrity. · *One-click unsubscribe works from the mail client's native button* — The unsubscribe headers stamped on every campaign pointed at a route that didn't exist, and the unsubscribe endpoint read its token from the form body — which a mail client's native one-click POST never carries. The header now points at the real endpoint and the token rides the URL, so the RFC 8058 one-click flow a mail client fires actually unsubscribes. The browser confirmation page is unchanged. · *Support tickets: reopen on customer reply, atomic tags, honest first-response time* — A customer reply to a resolved ticket silently disappeared from every operator queue — it now reopens the ticket with a fresh activity timestamp. Concurrent tag edits no longer overwrite each other (tag changes are single-statement updates). And an internal-only operator note no longer counts as the first response — only a reply the customer can actually see stamps the first-response time. · *CSV exports share one complete injection neutralizer* — The order-export and segment-members CSV exports each carried their own formula-injection defense, and both missed the tab, carriage-return, newline, and pipe vectors. Both now compose the framework's CSV cell guard, which covers the full vector set — including signed numerics, which the previous neutralizers deliberately exempted.
+
 - v0.4.21 (2026-06-06) — **Subscription changes reach the payment processor, smart collections match real products, refunds claw back earned points, and the remaining balance races are closed.** A correctness release across the commerce surfaces. Changing a subscription's quantity now updates the processor before the local record — what the customer sees is what they're billed — and a cadence change on a processor-backed plan is honestly refused rather than silently ignored. Smart collections, which matched zero products in production because their rules read fields the catalog rows never carried, now evaluate against the real product data. Loyalty points earned on a purchase are reversed when the order is refunded or cancelled. And the loyalty, store-credit, gift-registry, and gift-card-ledger write paths that could lose updates or oversell under concurrency now use atomic guards. **Fixed:** *Subscription quantity changes reach the payment processor* — Changing a subscription's quantity updated the local record and showed a success message while the processor kept billing the original amount. The change is now pushed to the processor first — a processor failure leaves the local record untouched and surfaces the error, so the customer-visible state and the billed state can no longer diverge. Changing delivery frequency on a processor-backed subscription is refused with honest guidance (the billing cadence is bound to the plan's price and cannot be re-cadenced in place); self-managed local subscriptions keep their frequency controls. Self-manage controls also now respect the processor's status — a subscription the processor reports as cancelled or expired shows its state instead of live controls. · *Smart collections match real catalog products* — Smart-collection rules read fields like tags, price, and stock from each product row — fields the real catalog listing never carried, so every smart collection matched zero products in production even though admin previews built on richer mock rows looked right. Rule evaluation now joins the real tag, category, vendor, price, and inventory data onto each product page, and the admin preview routes through the same path the storefront uses. Smart-collection pages also stop re-walking the entire catalog on every paginated request — the matched set is briefly cached and a rule edit invalidates it. · *Refunds and cancellations reverse the loyalty points the order earned* — Points awarded when an order was paid survived a refund or cancellation — buying, earning, and refunding farmed points indefinitely. The earn record is now claimed atomically on the order's refund or cancel transition and the awarded points are clawed back from the balance, floored at zero when some were already spent. The reversal is idempotent (a re-delivered payment webhook reverses exactly once) and lifetime points — which drive tier — are deliberately untouched. · *Balance and inventory-adjacent races closed across loyalty, store credit, gift registry, and gift-card ledger* — Loyalty earn and adjust used read-then-write absolute updates that could lose concurrent updates; the gift-registry purchase check could oversell a registry item under two simultaneous purchases; and the gift-card ledger's overdraft check could let two concurrent debits both pass. All of these now use single-statement conditional writes that refuse cleanly when the guard fails. Store-credit expiry sweeps also stop under-expiring when operator-initiated deductions exist — the sweep now keys on its own prior output rather than netting all expiry rows together. · *Search-ranking click-through metrics are bounded and attributed* — The ranking metrics screen could show click-through rates above 100%, and clicks were attributed from the query string alone — trivially spoofable. A click now only counts when the same session recorded a real impression for that query, and displayed rates are bounded at 100%.
 
 - v0.4.20 (2026-06-06) — **Payment integrity: refunds, gift-card balances, and checkout submission are race-proof, and abandoned checkouts return gift-card funds.** A money-path hardening release. Concurrent refund clicks on the same return can no longer reach the payment provider twice. A gift card that part-paid a checkout gets its balance back when the order is cancelled, fails payment, or is reaped as stale. Double-submitting checkout can no longer create two charges and two orders. Return requests are refused server-side on orders that aren't in a returnable state, the refund confirmation screen shows the currency the provider will actually refund, and a buy-online-pickup-in-store order now reaches its delivered state when picked up. **Fixed:** *A return can only be refunded once, even under concurrent requests* — Two simultaneous refund requests for the same approved return could both pass the status check and both reach the payment provider, each with a fresh idempotency key — a double refund. The refund now claims the return atomically before the provider is called (the second request answers 409), the provider call uses a key derived from the return itself so even a retry collapses into the same refund, and a provider failure releases the claim so the refund can be retried. · *Gift-card funds come back when a part-paid checkout dies* — When a gift card partially covered a checkout and the order was then cancelled, failed payment, or sat abandoned until reaped, the card's debit was never returned — the balance was permanently gone. Redemptions are now reversed on those order transitions: the card balance is restored (a fully drained card is reactivated), the reversal is idempotent, and it rides the same order lifecycle that releases inventory holds. · *Double-submitting checkout creates one charge and one order* — Two concurrent checkout submissions could both pass the cart-status read and each create a payment intent and an order. The cart is now claimed atomically as the single gate — the second submission is redirected back to the cart — and the payment-provider idempotency key is derived from the cart, so even a duplicate that slipped through would collapse into one charge on the provider's side. A failure before the order exists releases the claim so the customer can retry. · *Return requests are validated server-side* — The return-request form and its submission are now refused on orders that are not in a returnable state — a refunded, cancelled, or unpaid order answers with a clear message instead of opening a return that could feed a second refund downstream. Previously only the button's visibility enforced this. · *A failed gift-card settlement no longer strands a completed payment* — If recording a gift card's redemption failed after the payment had already succeeded and the order existed, the checkout aborted mid-way — leaving a paid order with a cart that never converted. The settlement step now completes the order regardless and surfaces the failure for follow-up instead of stranding the purchase. · *The refund confirmation shows the currency the provider refunds* — The confirmation screen displayed the return's approved currency, but the provider refunds in the original charge's currency. The screen now reads the same source the refund uses. · *Pickup orders reach their delivered state* — Marking a pickup order as picked up drove an order transition that was only legal for shipped orders, and the failure was silently swallowed — the pickup schedule said picked up while the order stayed in its paid state. The order lifecycle now has a pickup-completion transition, so a picked-up order genuinely lands in delivered and downstream reporting sees it.

package/README.md

@@ -204,6 +204,7 @@ variables. A signed-in operator can see the live on/off status of each at
 | **PayPal checkout** | A native PayPal button on `/checkout` (PayPal Orders v2 — create / approve / capture), distinct from PayPal-through-Stripe. | `PAYPAL_CLIENT_ID`, `PAYPAL_SECRET` (a PayPal REST app), `PAYPAL_WEBHOOK_ID`, `PAYPAL_ENV` (`sandbox`\|`live`); Stripe checkout must also be live | The shop exchanges the OAuth2 token and creates / captures orders server-side; the button drives `/checkout/paypal/create` + `/checkout/paypal/capture`. Point a PayPal webhook at `/api/webhooks/paypal` (verified through PayPal's API). Allow `www.paypal.com` in your CSP `script-src` / `frame-src` (as you would `js.stripe.com`). |
 | **Transactional email (SMTP)** | Order/ship/refund mail, abandoned-cart recovery, back-in-stock alerts, **wishlist sale + restock alerts and the periodic wishlist digest** (opt-in per customer on `/account/wishlist`), and **email magic-link sign-in** (a *Email me a sign-in link* option on `/account/login` for shoppers without a passkey or social login). | `SMTP_HOST`, `MAIL_FROM` (plus optional `SMTP_PORT` / `SMTP_USER` / `SMTP_PASS`) | Without a mailer these surfaces stay inert — the wishlist crons scan nothing, the magic-link page reports email sign-in unavailable, and passkey / social login are unchanged. **Wishlist alerts + digests are additionally gated on an email-address resolver:** the customer store keeps only a salted email *hash* (never the plaintext), so out of the box there is no deliverable address and the crons send nothing even with SMTP set. They begin sending once you supply a resolver that maps a customer id to a deliverable address from your own plaintext-address store — the same hook abandoned-cart recovery uses. |
 
+| **Email bounce / complaint intake** | Hard bounces and spam complaints from your email provider land on the marketing suppression list automatically (and backfill campaign metrics), so broadcasts stop mailing dead or complaining addresses. | `MAIL_BOUNCE_SECRET` (the value your provider sends in an `x-mail-bounce-secret` header), optional `MAIL_BOUNCE_VENDOR` (`postmark`\|`ses`\|`resend`, default `postmark`); point the provider's bounce/complaint webhook at `POST /api/webhooks/mail-bounce` (a `?vendor=` query overrides per request) | Without the secret the endpoint answers 503 — it never accepts an unauthenticated bounce. Complaints and hard bounces suppress at marketing scope (transactional mail still flows); soft bounces only backfill metrics. |
 **Planned / not available:**
 
 - **Shop Pay / "Sign in with Shop"** — **not available** to a self-hosted,

package/lib/admin.js

@@ -12909,6 +12909,51 @@ function mount(router, deps) {
       },
     ));
 
+    // Operator audit-chain integrity check (ops/tooling, bearer JSON).
+    // Walks the hash linkage (verifyChain) AND re-derives every signed
+    // checkpoint (verifyCheckpoints) so an operator can confirm the chain
+    // is both internally consistent AND anchored — the checkpoint layer is
+    // what catches a full-chain rewrite the hash linkage alone can't.
+    // Read-only: any failure to read degrades to an unavailable verdict,
+    // never a 500. Mounts only when the audit log is wired.
+    if (operatorAuditLog && typeof operatorAuditLog.verifyChain === "function") {
+      router.get("/admin/operators/audit/verify", _pageOrApi(true,
+        R(async function (req, res) {
+          var chain = null;
+          var checkpoints = null;
+          try { chain = await operatorAuditLog.verifyChain(); }
+          catch (_e) { chain = { ok: false, reason: "verify-unavailable" }; }
+          if (typeof operatorAuditLog.verifyCheckpoints === "function") {
+            try { checkpoints = await operatorAuditLog.verifyCheckpoints(); }
+            catch (_e) { checkpoints = { ok: false, reason: "verify-unavailable" }; }
+          }
+          _json(res, 200, {
+            chain:           chain,
+            checkpoints:     checkpoints,
+            signing_available: !!(operatorAuditLog.signingAvailable && operatorAuditLog.signingAvailable()),
+          });
+          return false;
+        }),
+        // No dedicated console screen — the operators page links here for
+        // tooling; a browser hit gets the same JSON verdict.
+        async function (req, res) {
+          var chain = null;
+          var checkpoints = null;
+          try { chain = await operatorAuditLog.verifyChain(); }
+          catch (_e) { chain = { ok: false, reason: "verify-unavailable" }; }
+          if (typeof operatorAuditLog.verifyCheckpoints === "function") {
+            try { checkpoints = await operatorAuditLog.verifyCheckpoints(); }
+            catch (_e) { checkpoints = { ok: false, reason: "verify-unavailable" }; }
+          }
+          _json(res, 200, {
+            chain:           chain,
+            checkpoints:     checkpoints,
+            signing_available: !!(operatorAuditLog.signingAvailable && operatorAuditLog.signingAvailable()),
+          });
+        },
+      ));
+    }
+
     // Create an operator. The first operator is created by the ADMIN_API_KEY
     // owner; thereafter any owner can. `created_by` is the acting operator's
     // id (or the "owner" sentinel for the break-glass key).

package/lib/asset-manifest.json

@@ -1,5 +1,5 @@
 {
-  "version": "0.4.21",
+  "version": "0.4.23",
   "assets": {
     "css/admin.css": {
       "integrity": "sha384-6k53cvkRrxMgmeStLIoLjVXZQHqIJgTmv1Izd8TYhh1HOC4POgE6GCvx1bsalyEP",

package/lib/checkout.js

@@ -246,6 +246,60 @@ function create(deps) {
   var backorder = deps.backorder || null;
   var preorder  = deps.preorder  || null;
 
+  // Optional inbound-webhook replay defense. A validly-signed Stripe event
+  // can be replayed verbatim inside the ±5-minute signature tolerance: the
+  // signature still verifies, so signature-checking alone does not stop a
+  // replay, and the downstream order-state idempotency is keyed on order
+  // state (not event identity) so a refund/cancel replay or a replay that
+  // races the first delivery slips past it. When `webhookReplayQuery` (a
+  // D1 query fn) is wired, every verified Stripe event id is atomically
+  // recorded with an INSERT ... ON CONFLICT DO NOTHING; a replay loses the
+  // PRIMARY-KEY race and is treated as an already-processed no-op. The
+  // store composes b.nonceStore over a D1-backed atomic backend rather
+  // than a hand-rolled has/set (which would race). Absent — the handler is
+  // byte-identical to the un-wired flow (order-state idempotency still
+  // covers the common re-delivery), so this is additive, never required.
+  var webhookReplayQuery = (typeof deps.webhookReplayQuery === "function")
+    ? deps.webhookReplayQuery : null;
+  var STRIPE_REPLAY_TTL_MS = b.constants.TIME.minutes(5); // matches the signature tolerance window
+  var _stripeReplayStore = null;
+  function _stripeReplay() {
+    if (!webhookReplayQuery) return null;
+    if (!_stripeReplayStore) {
+      // Custom b.nonceStore backend: the atomicity lives in the D1
+      // INSERT ... ON CONFLICT DO NOTHING (the PRIMARY KEY race decides
+      // first-seen vs replay), so the check + insert can never interleave.
+      _stripeReplayStore = b.nonceStore.create({
+        backend: {
+          checkAndInsert: async function (eventId, expireAt) {
+            var nowMs = Date.now();
+            var r = await webhookReplayQuery(
+              "INSERT INTO stripe_webhook_events (event_id, first_seen_at, expires_at) " +
+              "VALUES (?1, ?2, ?3) ON CONFLICT (event_id) DO NOTHING",
+              [eventId, nowMs, expireAt],
+            );
+            // rowCount/changes === 1 → first sighting (recorded); 0 → replay.
+            var changes = (r && r.meta && typeof r.meta.changes === "number") ? r.meta.changes
+              : (r && typeof r.rowCount === "number") ? r.rowCount
+              : (r && typeof r.changes === "number") ? r.changes : 0;
+            return changes > 0;
+          },
+          purgeExpired: async function () {
+            var r = await webhookReplayQuery(
+              "DELETE FROM stripe_webhook_events WHERE expires_at < ?1",
+              [Date.now()],
+            );
+            if (r && r.meta && typeof r.meta.changes === "number") return r.meta.changes;
+            if (r && typeof r.rowCount === "number") return r.rowCount;
+            if (r && typeof r.changes === "number") return r.changes;
+            return 0;
+          },
+        },
+      });
+    }
+    return _stripeReplayStore;
+  }
+
   // Reprice a list of cart lines through the quantity-discount engine.
   // Returns a shallow copy with `unit_amount_minor` overwritten by the
   // discounted unit for each line's SKU at its quantity. A line whose
@@ -1261,6 +1315,22 @@ function create(deps) {
       var event = v.event;
       var eventType = event && event.type;
 
+      // Replay defense — atomically claim this event id the moment the
+      // signature verifies, BEFORE any subscription routing or state
+      // transition. A replayed (already-seen) event id loses the
+      // PRIMARY-KEY race and short-circuits to a processed no-op so no
+      // transition, refund-mirror, or subscription update runs twice. A
+      // store error fails CLOSED inside the nonceStore (returns
+      // not-fresh) — a replay is indistinguishable from a wiped store, so
+      // refusing is the safe default. No-op when the store isn't wired.
+      var replay = _stripeReplay();
+      if (replay && event && typeof event.id === "string" && event.id.length > 0) {
+        var fresh = await replay.checkAndInsert(event.id, Date.now() + STRIPE_REPLAY_TTL_MS);
+        if (!fresh) {
+          return { handled: true, event_type: eventType || null, skipped: "replay", event_id: event.id };
+        }
+      }
+
       // Subscription events route to the subscriptions primitive
       // (if wired). The one-time-order PaymentIntent path below
       // stays unchanged.

package/lib/compliance-export.js

@@ -10,8 +10,11 @@
  *   me" (export) or "erase everything you hold on me" (deletion).
  *   The primitive owns the request lifecycle + composes per-domain
  *   readers (customers, order, order-notes, subscriptions,
- *   addresses, payment-methods, support-tickets, loyalty) to
- *   assemble the bundle. Delivery (email / signed URL / secure
+ *   addresses, payment-methods, support-tickets, loyalty, reviews,
+ *   consent ledger, wishlist, surveys, recently-viewed) to assemble
+ *   the bundle — every table that keys a row by the customer, so the
+ *   export holds the whole record, not just the order/identity core.
+ *   Delivery (email / signed URL / secure
  *   download portal) is the operator worker's concern — this
  *   primitive returns the bundle as structured JSON and stamps
  *   the lifecycle row when the worker confirms dispatch.
@@ -76,7 +79,11 @@
  *
  *   Scope semantics on export:
  *
- *     - `full`           — every injected reader contributes.
+ *     - `full`           — every injected reader contributes (identity,
+ *                          orders, subscriptions, addresses, payment
+ *                          methods, support tickets, loyalty, reviews,
+ *                          consent ledger, wishlist, surveys,
+ *                          recently-viewed).
  *     - `orders_only`    — only `order` + `orderNotes` contribute;
  *                          identity / loyalty / subscriptions /
  *                          addresses / payment methods / support
@@ -92,7 +99,9 @@
  *
  * @primitive complianceExport
  * @related    customers, order, orderNotes, subscriptions, addresses,
- *             paymentMethods, supportTickets, loyalty, orderExport
+ *             paymentMethods, supportTickets, loyalty, reviews,
+ *             consentLedger, wishlist, customerSurveys, recentlyViewed,
+ *             orderExport
  */
 
 var b = require("./vendor/blamejs");
@@ -124,10 +133,19 @@ var ZERO_WIDTH_RE   = new RegExp(
 
 // Scope -> which injected readers contribute on export. Keeps the
 // fulfillRequest logic a single lookup instead of nested if-else.
+//
+// `full` enumerates every domain that keys a row by the customer
+// (directly via customer_id, or via a per-customer hash) so a
+// subject-access export holds everything the controller stores about
+// the person — not just the order / identity core. A domain that
+// isn't wired (or whose reader is absent) is reported in
+// `sections_absent`, so an unexported table is always visible in the
+// bundle manifest rather than silently dropped.
 var SCOPE_SECTIONS = Object.freeze({
   full: Object.freeze([
     "customers", "addresses", "order", "orderNotes",
     "subscriptions", "paymentMethods", "supportTickets", "loyalty",
+    "reviews", "consentLedger", "wishlist", "surveys", "recentlyViewed",
   ]),
   orders_only: Object.freeze(["order", "orderNotes"]),
   identity_only: Object.freeze(["customers", "addresses"]),
@@ -220,6 +238,28 @@ function _limit(n) {
 
 function _now() { return Date.now(); }
 
+// Classify a reader's returned section for the completeness manifest.
+// A section is "empty" when the reader is wired but holds nothing for
+// this customer: null, an empty array, or an object whose own values
+// are all themselves empty (e.g. `{ balance: 0, history: [] }`). Any
+// other shape (a non-empty array, an object carrying a row, a scalar)
+// counts as "exported". The distinction lets the auditor tell "we hold
+// nothing here" apart from "this is real PII we exported".
+function _isEmptySection(section) {
+  if (section == null) return true;
+  if (Array.isArray(section)) return section.length === 0;
+  if (typeof section === "object") {
+    var keys = Object.keys(section);
+    if (keys.length === 0) return true;
+    for (var i = 0; i < keys.length; i += 1) {
+      if (!_isEmptySection(section[keys[i]])) return false;
+    }
+    return true;
+  }
+  // A scalar (string / number / boolean) is real exported data.
+  return false;
+}
+
 // ---- row hydration ------------------------------------------------------
 
 function _hydrate(r) {
@@ -267,6 +307,11 @@ function create(opts) {
     paymentMethods: opts.paymentMethods || null,
     supportTickets: opts.supportTickets || null,
     loyalty:        opts.loyalty        || null,
+    reviews:        opts.reviews        || null,
+    consentLedger:  opts.consentLedger  || null,
+    wishlist:       opts.wishlist       || null,
+    surveys:        opts.surveys        || null,
+    recentlyViewed: opts.recentlyViewed || null,
   };
 
   // ---- requestExport -------------------------------------------------
@@ -391,12 +436,21 @@ function create(opts) {
     var bundle          = {};
     var sectionsPresent = [];
     var sectionsAbsent  = [];
+    // Per-section completeness manifest. Every scope section lands here
+    // with an explicit status — "exported" (reader wired + returned
+    // data), "empty" (reader wired but the customer has no rows here),
+    // or "absent" (no reader wired at fulfillment time). An auditor (or
+    // the data subject) reads this to confirm the bundle isn't
+    // surreptitiously incomplete: an unexported table is visible as
+    // `absent`, never silently dropped.
+    var manifest = [];
 
     for (var s = 0; s < sections.length; s += 1) {
       var sectionName = sections[s];
       var reader      = injectedReaders[sectionName];
       if (!reader || typeof reader.forCustomerExport !== "function") {
         sectionsAbsent.push(sectionName);
+        manifest.push({ section: sectionName, status: "absent" });
         continue;
       }
       // The reader returns whatever shape it owns (array of rows,
@@ -406,6 +460,7 @@ function create(opts) {
       var section = await reader.forCustomerExport(row.customer_id);
       bundle[sectionName] = section == null ? null : section;
       sectionsPresent.push(sectionName);
+      manifest.push({ section: sectionName, status: _isEmptySection(section) ? "empty" : "exported" });
     }
 
     var fulfilledAt = _now();
@@ -422,6 +477,7 @@ function create(opts) {
       fulfilled_at:     fulfilledAt,
       sections_present: sectionsPresent,
       sections_absent:  sectionsAbsent,
+      manifest:         manifest,
       data:             bundle,
     };
   }
@@ -504,6 +560,7 @@ function create(opts) {
     }
 
     var domainOrder = [
+      "recentlyViewed", "wishlist", "surveys", "reviews", "consentLedger",
       "supportTickets", "orderNotes", "order", "subscriptions",
       "paymentMethods", "loyalty", "addresses", "customers",
     ];

package/lib/customer-portal.js

@@ -287,6 +287,29 @@ function create(opts) {
       return { revoked: Number(r.rowCount || 0) > 0 };
     },
 
+    // Bulk eject every LIVE (issued) session for one customer in a
+    // single statement. The right-to-erasure / password-reset hammer:
+    // where `revokeSession` kills one id, this kills the whole live set
+    // so a deleted (or compromised) customer's outstanding portal links
+    // all stop working at once. Idempotent — a customer with no issued
+    // session flips zero rows. Only `issued` rows move (consumed /
+    // expired / already-revoked stay terminal). Returns the count.
+    revokeAllForCustomer: async function (customerId, reason) {
+      var cid   = _uuid(customerId, "customer_id");
+      var clean = _optShortString(reason, "reason", MAX_REASON_LEN);
+      if (clean == null) {
+        throw new TypeError("customer-portal.revokeAllForCustomer: reason required (non-empty string ≤ " + MAX_REASON_LEN + " chars)");
+      }
+      var now = _now();
+      var r = await query(
+        "UPDATE customer_portal_sessions " +
+        "SET status = 'revoked', revoked_at = ?1, revoke_reason = ?2 " +
+        "WHERE customer_id = ?3 AND status = 'issued'",
+        [now, clean, cid],
+      );
+      return { revoked: Number(r.rowCount || 0) };
+    },
+
     // Audit / debugging entry point. Returns every session ever
     // minted for a customer, newest-first by created_at (id as
     // tiebreak — both are uuid.v7-derived so the ordering is

package/lib/customer-segments.js

@@ -332,10 +332,13 @@ function _now() { return Date.now(); }
 // ---- CSV helpers (members export) ---------------------------------------
 //
 // Same RFC-4180 quoting + spreadsheet-formula-injection neutralization
-// the order-export primitive uses: every cell is quoted, embedded `"`
-// doubled, and any cell beginning with `=` / `+` / `-` / `@` is prefixed
-// with `'` so a spreadsheet treats it as text (a customer-controlled
-// display_name is the injection vector). Signed numerics pass through.
+// the order-export primitive uses, composing the SAME shared vendored
+// neutralizer (b.guardCsv.escapeCell) so the two CSV surfaces can't drift:
+// every cell is quoted, embedded `"` doubled, and a cell beginning with any
+// formula-trigger char — `= + - @` plus the tab / CR / LF / pipe / full-
+// width variants an `= + - @`-only check misses — gets a leading TAB so a
+// spreadsheet treats it as text (a customer-controlled display_name is the
+// injection vector here).
 
 function _coerceCell(value) {
   if (value == null) return "";
@@ -344,14 +347,8 @@ function _coerceCell(value) {
   return JSON.stringify(value);
 }
 
-var _NUMERIC_SIGN_RE = /^[+-](?:\d+(?:\.\d+)?|\.\d+)$/;
-
 function _neutralizeInjection(s) {
-  if (s.length === 0) return s;
-  var first = s.charAt(0);
-  if (first !== "=" && first !== "+" && first !== "-" && first !== "@") return s;
-  if ((first === "+" || first === "-") && _NUMERIC_SIGN_RE.test(s)) return s;
-  return "'" + s;
+  return b.guardCsv.escapeCell(s);
 }
 
 function _csvCell(value) {

package/lib/customers.js

@@ -535,6 +535,78 @@ function create(opts) {
       return true;
     },
 
+    // Right-to-erasure auth revocation. A subject-access deletion must
+    // leave the customer UNABLE TO SIGN BACK IN — anonymizing the profile
+    // row alone is not erasure if every login credential still resolves.
+    // This deletes the THREE durable sign-in credentials keyed to the
+    // customer and severs the magic-link lookup key in ONE call:
+    //
+    //   * customer_passkeys           — every enrolled WebAuthn authenticator
+    //                                    (passkey sign-in resolves a credential
+    //                                    to this id; gone, the assertion misses).
+    //   * customer_oauth_identities   — every federated link (Google / Apple
+    //                                    OIDC resolves byOAuthIdentity to this
+    //                                    id; gone, the federated sign-in creates
+    //                                    a fresh unrelated account instead).
+    //   * email_hash -> tombstone     — the magic-link / guest-order-claim path
+    //                                    resolves byEmailHash; overwriting the
+    //                                    hash with a per-id, non-reversible
+    //                                    tombstone means no future link for the
+    //                                    erased address can ever resolve this row
+    //                                    (the address itself is never stored, so
+    //                                    there is no plaintext to scrub — only
+    //                                    the lookup key to break).
+    //
+    // The sealed 14-day auth cookie is stateless (no server session row to
+    // kill), but with no credential left to re-mint it and no lookup key to
+    // re-issue a magic link, the account cannot be re-entered after the
+    // cookie expires; the live customer-portal sessions are revoked
+    // separately by the caller (customerPortal.revokeAllForCustomer). Each
+    // step is idempotent — re-running on an already-erased row deletes
+    // nothing more and returns zero counts. dry_run reports the counts the
+    // wet run WOULD remove without mutating, so the operator preview shows
+    // the blast radius. Returns `{ passkeys, oauth_identities, email_hash_cleared }`.
+    eraseAuthForCustomer: async function (id, opts) {
+      _uuid(id, "customer id");
+      var dryRun = !!(opts && opts.dry_run);
+      var pkRows = (await query(
+        "SELECT COUNT(*) AS n FROM customer_passkeys WHERE customer_id = ?1", [id],
+      )).rows[0];
+      var oaRows = (await query(
+        "SELECT COUNT(*) AS n FROM customer_oauth_identities WHERE customer_id = ?1", [id],
+      )).rows[0];
+      var existing = (await query("SELECT email_hash FROM customers WHERE id = ?1", [id])).rows[0];
+      var emailHashSet = !!(existing && existing.email_hash && String(existing.email_hash).indexOf("erased:") !== 0);
+      if (dryRun) {
+        return {
+          passkeys:            pkRows ? Number(pkRows.n) : 0,
+          oauth_identities:    oaRows ? Number(oaRows.n) : 0,
+          email_hash_cleared:  emailHashSet ? 1 : 0,
+        };
+      }
+      var ts = _now();
+      var pkDel = await query("DELETE FROM customer_passkeys WHERE customer_id = ?1", [id]);
+      var oaDel = await query("DELETE FROM customer_oauth_identities WHERE customer_id = ?1", [id]);
+      // Tombstone the lookup key with a per-id, non-reversible value that
+      // can never collide with a real namespaceHash digest (those are hex)
+      // and can never be re-derived from any email address. Only rewrite a
+      // live (non-tombstoned) hash so a re-run is a no-op.
+      var emailHashCleared = 0;
+      if (emailHashSet) {
+        var tombstone = "erased:" + b.crypto.namespaceHash("customer-erased-email", id);
+        var upd = await query(
+          "UPDATE customers SET email_hash = ?1, updated_at = ?2 WHERE id = ?3 AND email_hash = ?4",
+          [tombstone, ts, id, existing.email_hash],
+        );
+        emailHashCleared = Number((upd && upd.rowCount) || 0);
+      }
+      return {
+        passkeys:            Number((pkDel && pkDel.rowCount) || 0),
+        oauth_identities:    Number((oaDel && oaDel.rowCount) || 0),
+        email_hash_cleared:  emailHashCleared,
+      };
+    },
+
     // Mutate a customer's editable profile fields. v1 covers display_name
     // only — the one field a customer can safely change without a
     // verification round trip.

package/lib/email-campaigns.js

@@ -783,7 +783,14 @@ function create(opts) {
     var signup = await newsletter.byEmailHash(emailHash);
     if (!signup || !signup.id) return null;
     var issued = await newsletter.issueUnsubscribeToken(signup.id);
-    var url = unsubscribeBaseUrl + "/newsletter/unsubscribe?token=" + encodeURIComponent(issued.token);
+    // The storefront mounts the one-click unsubscribe at GET/POST
+    // /unsubscribe (lib/storefront.js + EDGE_POST_PATHS). The token rides
+    // in the URL — a mail client's RFC 8058 one-click POST fires at this
+    // exact URL with a `List-Unsubscribe=One-Click` body and no token of
+    // its own, so the route MUST be the real one and MUST read the token
+    // from here. (An earlier `/newsletter/unsubscribe` target had no route
+    // behind it — every native one-click POST 404'd and never unsubscribed.)
+    var url = unsubscribeBaseUrl + "/unsubscribe?token=" + encodeURIComponent(issued.token);
     // Validate the header SHAPE through the vendored RFC 2369 + RFC 8058
     // guard so a malformed link (non-https, control byte) never reaches
     // the wire — Gmail / Yahoo refuse mail that carries a broken pair.

package/lib/operator-accounts.js

@@ -87,9 +87,60 @@
  *
  *   Storage: `migrations-d1/0213_operator_accounts.sql`.
  *
+ *   Dual-control (two-operator approval) — evaluated, deliberately NOT
+ *   wired in v1:
+ *
+ *     `b.dualControl` raises a destructive op to "two distinct named
+ *     operators must approve before it runs." It is the right control for
+ *     a store run by a TEAM, but it is structurally a two-actor M-of-N
+ *     gate — `create()` hard-validates `minApprovers >= 2`, and there is
+ *     no auto-satisfy-on-single-operator path. The dominant deployment of
+ *     this storefront is a SINGLE owner; on such a store a dual-control
+ *     gate would DEADLOCK the destructive op forever — there is no second
+ *     operator to approve, so the op can never consume its grant. Wiring
+ *     it unconditionally is therefore a worse failure than the
+ *     single-operator risk it would close. It is also a two-request async
+ *     workflow (request → a different actor approves → consume), which
+ *     does not fit the synchronous single-POST shape these admin actions
+ *     have today.
+ *
+ *     Per destructive op, the v1 stance:
+ *
+ *       - gift-card void (POST /admin/gift-cards/:id/void): recoverable —
+ *         void is a status flip that PRESERVES the balance (it burns no
+ *         value), so re-issuing or restoring the card's status makes a
+ *         mistaken void recoverable, and the giftcard ledger records the
+ *         acting operator. The cost of a deadlock-on-single-owner
+ *         outweighs the benefit. Stance: role-gate (`orders.write`) +
+ *         audit, no dual-control.
+ *
+ *       - refunds (POST /admin/orders/:id/refund, /admin/returns/:id/
+ *         refund): real money out, but bounded by the order's captured
+ *         amount (the payment primitive refuses to over-refund a PI), and
+ *         every refund is idempotency-keyed + audited with the operator
+ *         id. The damage ceiling is one order's total, not the whole
+ *         book. Stance: role-gate (`orders.write`) + audit, no
+ *         dual-control.
+ *
+ *       - operator disable (POST /admin/operators/:id/disable): the
+ *         highest-blast-radius op (it can revoke a co-owner), but it is
+ *         REVERSIBLE in one click (`/enable`), gated on `operators.manage`
+ *         (owner-only), and audited. A malicious self-lockout still leaves
+ *         the `ADMIN_API_KEY` break-glass owner credential working.
+ *         Stance: role-gate + audit, no dual-control.
+ *
+ *     Re-open condition: when a store carries TWO OR MORE active `owner`/
+ *     `manager` operators, dual-control becomes wire-able WITHOUT the
+ *     deadlock risk — gate the approval flow on `listAccounts({ status:
+ *     "active" })` length >= 2, auto-satisfy below that, and move the
+ *     destructive POST to a request/approve/consume sequence keyed off a
+ *     b.cache grant. That is the natural follow-up the moment a real
+ *     multi-operator store exists; it is not defensible to ship a control
+ *     that bricks the single-operator common case to pre-empt it.
+ *
  * @primitive operatorAccounts
  * @related   operatorRoles, operatorSessions, operatorAuditLog,
- *            b.password, b.crypto, b.guardEmail, b.uuid
+ *            b.password, b.crypto, b.guardEmail, b.uuid, b.dualControl
  */
 
 var EMAIL_NAMESPACE   = "operator-email";