@blamejs/blamejs-shop 0.4.25 → 0.4.26

package/CHANGELOG.md

@@ -8,6 +8,8 @@ upgrading across more than a few patches at a time.
 
 ## v0.4.x
 
+- v0.4.26 (2026-06-06) — **Guest orders attach to an account on verified sign-in; privacy exports and erasures now cover suggestions, saved-for-later, and store credit; HSTS ships on container responses behind the CDN; and internal cron POSTs are secret-checked at the edge.** A guest-order-claim, privacy-completeness, and edge-hardening release. When a shopper who checked out as a guest later signs in or registers with a verified email that matches the order, those orders now attach to their account and appear in their order history. A subject-access export now includes the customer's suggestion-box submissions, their save-for-later list, and their store-credit ledger, and an erasure anonymizes the suggestions, deletes the saved list, and retains the store-credit ledger under its accounting basis — a domain whose reader isn't wired still shows in the export manifest rather than being silently dropped. Strict-Transport-Security now ships on responses served directly by the container behind the Cloudflare proxy, not only on edge-rendered pages. The worker now verifies the shared secret on internal cron and event POSTs before forwarding them to the container. Upgrade applies one D1 migration. **Added:** *Guest orders reconcile to an account on verified sign-in* — An order placed as a guest carries the buyer's email as a one-way hash. When that buyer later signs in or registers — including through Sign in with Google — and their verified email hashes to the same value, the matching guest orders attach to their account and show up under their order history. Attachment is driven only by verified-email ownership, never by unauthenticated email knowledge, and is idempotent: re-signing-in attaches nothing new, a non-matching email attaches nothing, and the placing-browser cookie and emailed-access-token routes to a guest order keep working unchanged. **Changed:** *Privacy export and erasure cover suggestions, saved-for-later, and store credit* — A full subject-access export now includes three more customer-keyed domains: the customer's suggestion-box submissions (product ideas and complaints, matched on the account id or the hashed email the submission carried), their save-for-later list, and their store-credit balance and ledger history. Erasure anonymizes each suggestion in place — severing both identity keys so the row can no longer be traced to the person while leaving the de-identified roadmap signal — deletes the save-for-later list outright, and retains the store-credit ledger under the same accounting / legal-obligation basis the loyalty ledger and gift cards already use. Each domain reports its effect in the request's completeness manifest, so a domain whose reader isn't wired is visible as absent rather than silently omitted. **Security:** *HSTS ships on container responses behind the proxy* — Strict-Transport-Security is emitted on responses served directly by the application container, not only on pages rendered at the edge. Behind the Cloudflare proxy the container connection is plain HTTP and the real scheme arrives in the forwarded-proto header; the security-headers middleware now trusts that header, so a direct-to-container or edge-render-off response carries the same two-year, includeSubDomains, preload HSTS value the edge sends. Plain-HTTP local and direct connections still omit the header, which user agents ignore over HTTP anyway. · *Internal cron and event POSTs are secret-checked at the edge* — The worker now verifies the shared secret on its internal cron and event POSTs (cart-recovery, stock-alert and wishlist sweeps, the stale-order reap, portal-session expiry, and campaign sends) before forwarding them to the container, refusing a forged public request at the edge instead of relying solely on the container's own check. The check is skipped when the secret isn't configured, so a deployment that hasn't set it still forwards rather than refusing every scheduled task.
+
 - v0.4.25 (2026-06-06) — **The admin role gate fails closed, payment-processor calls are host-pinned, the public catalog API stops leaking unpublished products, and privacy requests show their statutory deadline.** A security-hardening release. The staff role matrix now denies an unmapped admin action by default (owner-only) instead of leaving it manager-reachable; outbound Stripe and PayPal calls are pinned to the configured processor host with their idempotency keys validated before they leave; the public catalog API no longer honors a caller-supplied status filter, so draft and archived products can't be enumerated; the privacy-request console surfaces each request's statutory response deadline; and the Apple Pay well-known bot-guard exemption is tightened to an exact-path match. No migrations. **Changed:** *Privacy-request console shows the statutory response deadline* — Each export and erasure request now displays its statutory response deadline — one month under GDPR, 45 days under CCPA, 15 days under LGPD — derived from the request's recorded jurisdiction and timestamp, and flags an open request whose deadline has passed. Requests under no statutory regime show no deadline rather than an invented one. **Security:** *Admin role gate fails closed on unmapped actions* — The operator role matrix is now a declarative registry with role inheritance (owner ⊃ manager ⊃ viewer) validated at boot. A mutating admin action that isn't explicitly mapped to a permission now requires the owner role, instead of falling through to a manager-grantable default — so a newly added admin route can't be reached by a manager or viewer by accident. Existing mapped routes keep their grants. · *Public catalog API no longer leaks unpublished products* — GET /api/catalog/products accepted a caller-supplied ?status= filter and passed it straight through, so an unauthenticated request could list draft or archived products by asking for them. The endpoint now always lists only published products; operators browse other statuses through the authenticated admin catalog screens. · *Payment-processor calls are host-pinned with validated idempotency keys* — Every outbound Stripe and PayPal call is now pinned to the configured processor host (defense-in-depth over the existing private-address and metadata-endpoint blocking), and a malformed or non-HTTPS processor base URL fails at the first call rather than dialing in the clear. The idempotency key each call carries is validated before it leaves, refusing path-traversal, slash, and control-character shapes. · *Apple Pay well-known bot-guard exemption is exact-match* — The bot-guard skip for the Apple Pay domain-association path was matched as a prefix, which would also have exempted any sibling path beneath it. It is now an exact-path match, so only the single static association file skips the guard.
 
 - v0.4.24 (2026-06-06) — **Order timelines, in-console new-order alerts, partial refunds, a customer idea board, storefront sidebar widgets, and Stripe wallet checkout — alongside refund-accounting, inventory-race, and access-control hardening.** This release adds operator and storefront surfaces that compose primitives already in the tree, and closes a set of value-conservation, concurrency, and access-control gaps in the same areas. Operators get a single order-story timeline, an in-console inbox that flags new paid orders with an unread badge, a browser partial-refund control, and curated storefront sidebar widgets. Shoppers get a receipt download on their orders, a suggestion board, and Stripe wallet buttons (Apple Pay, Google Pay, Link) at checkout. The fixes make partial refunds return gift-card and loyalty value in exact proportion, make inventory and quote state transitions race-proof under concurrency, gate the privacy export/erasure routes behind the operator role matrix, and harden the audit log, gift-card ledger, session revocation, and magic-link throttling. Upgrade applies six new D1 migrations and adds one optional environment variable for Apple Pay. **Added:** *Order timeline on the admin order screen* — /admin/orders/:id now shows one chronological feed of the whole order story — state changes, payments and refunds, shipments and carrier tracking events, customer-service notes, returns, and shipping labels — instead of separate panels. Each source is optional; an unwired source simply drops out of the feed. Wire orderTimeline into admin.mount to enable it. · *New-order inbox with an unread badge* — When an order is paid, an entry lands in a new in-console inbox at /admin/inbox and the admin navigation shows an unread count, so a sale is visible on the next page load without polling. Mark a message read once actioned, or archive it. The inbox is addressed to a role broadcast, so a single shared-credential console still sees the badge. Wire operatorInbox into admin.mount to enable it. · *Partial refunds from the browser* — The order screen gains a Refunds panel: enter an amount and the framework charges it back through the payment provider, validates it server-side, and caps it at the order's remaining balance — an over-refund is refused before any money moves. The provider call is keyed so a double-click cannot refund twice. A refund that clears the balance moves the order to refunded; a smaller refund leaves it on its current track and records the slice. · *Customer receipt download* — A customer can download a receipt for their own order from the order page. The document streams in chunks rather than buffering, and the route is gated to the order's owner (and guest-order token holders, matching the existing order-page guard). · *Customer suggestion board* — Shoppers can submit and vote on product and feature ideas at /suggestions (linked from the footer). Operators triage from a new admin console: respond, move ideas along a status flow, merge duplicates, flag spam, or archive. Submissions are rate-limited and bot-guarded, the submitter's email is hashed before storage, and all free text is escaped on both the public board and the admin screen. · *Operator-curated storefront sidebar widgets* — Operators can place an ordered set of sidebar content blocks (newsletter signup, trust badges, social proof, size chart, countdown, featured collection, and more) per page across product, cart, search, and collection pages. The content is operator-authored and global, so it renders identically from the edge cache and the container. Manage widgets and per-page placement from the new Sidebar widgets admin screen. · *Stripe wallet checkout (Apple Pay, Google Pay, Link)* — The pay page now offers the Stripe Express Checkout Element, surfacing the wallet buttons a shopper's browser supports against the existing PaymentIntent. It degrades to the card form when no wallet is available or when payments are unconfigured. Apple Pay additionally needs the domain-association file served (see Migration) and each web domain registered with Stripe. · *Email-change guidance on the profile screen* — The profile screen now explains that a sign-in email cannot be changed in place: addresses are stored as a hash by design, so changing one means re-registering. The copy states what is and is not possible and why, rather than leaving the field unexplained. **Fixed:** *Partial refunds return gift-card and loyalty value in proportion* — A partial refund previously re-minted the entire gift-card spend and clawed back 100% of earned loyalty points the moment the order reached the refunded state, and restored nothing on a smaller slice — so a buyer could keep goods plus the full re-minted gift-card balance. Refunds now re-mint gift-card spend, claw earned loyalty, and restore redeemed loyalty points in exact proportion to the amount refunded, and a partial-then-final refund sequence converges on exactly the amount returned. · *Redeemed loyalty points are restored on refund* — Loyalty points spent as a checkout tender were never returned when the order was refunded, even though gift-card spend was — an inconsistency that cost the customer. Redeemed points are now restored on refund, in proportion to the refunded amount. · *Referral rewards reverse on refund or cancel* — A referral's qualifying first order being refunded or cancelled now rolls back the both-rewarded completion and decrements the referrer's leaderboard count, closing a buy-then-refund reward-farming path. The reversal is claimed once so a re-delivered refund webhook cannot double-reverse. · *Inventory and quote state transitions are race-proof* — Stock-transfer reconcile, inventory receive and reverse, write-off reversal, allocation commit, cycle-count finalize, and quote accept and convert all read state and then mutated it without an atomic guard, so two concurrent calls could both proceed — double-crediting a destination shelf, double-restocking, or minting two orders from one quote. Each transition now claims its state atomically and proceeds only if it won the claim. The stock-transfer and inventory-receipt lifecycles are additionally validated against a declared state machine. **Security:** *Privacy export and erasure now enforce the operator role matrix* — The data-subject export (full customer PII) and erasure routes did not pass through the role check every other mutating admin route uses, so a read-only viewer could export a customer's data and run an irreversible erasure. Both are now gated by the role matrix, and the mutating admin routes were swept to confirm each maps to a required permission. · *Operator audit log no longer self-reports tampering under concurrency* — Two operator actions recorded at the same instant could each read the same chain head and append rows sharing one previous-hash, forking the tamper-evident chain so verification reported a break where no tampering occurred. Audit appends are now serialized per chain, so the hash chain stays linear under concurrent writes. · *Gift-card ledger is now tamper-evident* — The gift-card balance ledger carried no cryptographic linkage, so a direct database edit that inflated a balance or dropped a debit passed balance reads undetected. Each ledger row now carries a per-card hash chain (the same construction the operator audit log uses), and a verification pass surfaces any insert, rewrite, reorder, or deletion. · *Erasure, passkey-revoke, and sign-out terminate live sessions* — The sealed sign-in cookie is self-validating for up to 14 days, so an erased or anonymized account stayed usable until the cookie expired. A per-customer session boundary now lets erasure, passkey revocation, and explicit sign-out invalidate every cookie minted before the boundary. A customer with no boundary is unaffected, so upgrading does not sign anyone out. · *Marketing email honors the suppression list everywhere* — Wishlist price-drop and back-in-stock alerts did not consult the marketing suppression list, and a newsletter one-click unsubscribe recorded the opt-out without adding the address to suppressions — so a hard-bounced, complained, or unsubscribed address could still be mailed by another flow. Both paths now consult and feed the suppression list, matching the transactional and campaign paths. · *Per-recipient throttle on magic-link sign-in* — Magic-link minting was throttled per source address only, so a distributed source could email-bomb one victim's inbox. A per-recipient limit now caps how often a link can be sent to a single address, alongside the existing per-source limit. · *Strict validation of inbound webhook idempotency keys* — The inbound webhook idempotency key was validated against a broad printable-ASCII pattern that accepted path-traversal shapes. It now uses the framework's strict idempotency-key guard, which refuses slash, backslash, and dot-dot sequences. The strict profile permits a space (harmless in the parameterized lookup) while refusing the traversal shapes. **Migration:** *Six new D1 migrations* — 0220 adds the gift-card ledger hash-chain columns; 0221, 0223, 0224, and 0225 add proportional-reversal tracking to gift-card redemptions, loyalty transactions, the loyalty earn log, and referral invitations; 0222 adds the per-customer session-revocation boundary table. All apply cleanly over existing rows (new columns default to nothing-reversed-yet; the revocation table is empty, which is the default-allow state). Run pending migrations and sync theme assets as usual. · *Optional APPLE_PAY_DOMAIN_ASSOCIATION environment variable* — To show the Apple Pay wallet button, set APPLE_PAY_DOMAIN_ASSOCIATION to the file contents Stripe provides (Stripe owns Apple merchant validation, so no Apple Developer account is needed) and register each web domain with Stripe. The shop serves the value verbatim at /.well-known/apple-developer-merchantid-domain-association on both the edge and container. Unset, the path returns 404 and the Apple Pay button stays hidden; card, Google Pay, Link, and PayPal are unaffected.

package/README.md

@@ -69,7 +69,7 @@ Every primitive is composed on the vendored blamejs surface — no npm runtime d
 | **`lib/delivery-estimate.js`** | "Get it by <date>" promises. Operators define carrier transit times, warehouse cutoffs, holidays, and postal-prefix zones at `/admin/delivery-estimates`; the product and cart pages then show a signed-in customer a delivery date computed against their saved shipping address and the configured origin (`SHOP_ESTIMATE_ORIGIN` or the `shop.estimate_origin` config row). Anonymous, edge-cached pages deliberately render no date — estimates are destination-specific and never bake into the shared cache. Unconfigured stores render nothing, never an error. |
 | **`lib/promo-banners.js`** | Placement-targeted marketing banners (top strip, homepage hero, PDP-side, cart-side, empty-search, footer) with schedule windows, audience targeting, themes, priorities, and click/impression counts. Authored at `/admin/promo-banners`; rendered on both substrates with edge-cache-safe resolution. |
 | **`lib/payment.js`** | Payment adapters — **Stripe** (verify webhook HMAC-SHA256 via upstream `b.webhook.verify`, create / retrieve / confirm / cancel PaymentIntent, refund, register / list payment-method domains for Apple/Google Pay) and **PayPal** (`adapter: "paypal"` — OAuth2 client-credentials token, create / capture / get / refund Orders v2, webhook verify via PayPal's verify-webhook-signature API). No `stripe` / `paypal` npm dep — outbound through `b.httpClient` (SSRF-gated, retried, circuit-broken). |
-| **`lib/order.js`** | FSM-driven post-checkout record via upstream `b.fsm`. States: pending → paid → fulfilling → shipped → delivered (+ refunded / cancelled). Every transition appends to `order_transitions`. |
+| **`lib/order.js`** | FSM-driven post-checkout record via upstream `b.fsm`. States: pending → paid → fulfilling → shipped → delivered (+ refunded / cancelled). Every transition appends to `order_transitions`. Guest orders carry the buyer's email as a one-way hash and attach to a customer account when a verified sign-in (passkey / Google / Apple) proves ownership of the same address — never from email knowledge alone — after which they appear in the account's order history. |
 | **`lib/checkout.js`** | Orchestrator. `quote()` returns priced quote; `confirm()` validates the ship-to address (real ISO 3166-1 country; US/CA state + ZIP/postal formats; lenient elsewhere) and the customer email shape, then creates a Stripe PaymentIntent + persists order pending; `handleStripeEvent()` verifies webhook + fires the FSM transition. PayPal path: `createPaypalOrder()` opens a PayPal order + persists pending, `capturePaypalOrder()` captures → paid, `handlePaypalEvent()` is the webhook backstop. All idempotent on re-delivery. |
 | **`lib/email.js`** | Transactional templates — order receipt, ship notification, refund confirmation, wishlist price-drop, abandoned-cart, review request, back-in-stock, **wishlist digest** (the periodic saved-items rollup, rendered per-line from the structured digest so every title / price is independently escaped), and **email magic-link sign-in**. Strict `{{var}}` renderer with HTML escape + refusal of unknown / unused placeholders. Composed on `b.mail` (DKIM/SPF/DMARC/BIMI upstream). |
 | **`lib/storefront.js`** | Server-rendered HTML — utility bar + sticky header + dark hero with code-preview card + primitives marquee + featured-product callout + collections grid + framework feature band + designed catalog grid + newsletter band + four-column footer. Designed surfaces also for PDP, cart, checkout, pay, order, account login / register / dashboard, quote review / accept, search results, `/admin` API landing, 404. Image-bearing cards on the home + search grids pull from `catalog.media`. The default theme stylesheet is external (R2-served `themes/default/assets/css/main.css`) and CSP-compliant; the typeface (Inter / Inter Tight) is self-hosted from `themes/default/assets/fonts`, so no page loads a cross-origin font. Operators override by uploading a replacement at the same key, by passing `opts.theme_css` to renderers, or by registering a named theme through the `theme` primitive. |

package/SECURITY.md

@@ -142,7 +142,12 @@ node -e "
   ticks): those paths skip the bot guard's browser-fingerprint
   heuristics — the Worker's machine-to-machine calls carry no browser
   headers — so the constant-time secret check is the deciding gate,
-  and an unauthenticated caller gets a 401. Generate ≥ 32 bytes of OS
+  and an unauthenticated caller gets a 401. The Worker also verifies
+  the same secret on these cron/event POSTs before forwarding them, so
+  a forged public request is refused at the edge before it reaches the
+  container (the edge check is skipped when the secret is unset, so a
+  deployment that hasn't wired it still forwards rather than dropping
+  every scheduled task). Generate ≥ 32 bytes of OS
   randomness and set the value identically on the Worker (`wrangler
   secret put D1_BRIDGE_SECRET`) and the container env. Rotate
   quarterly or after any Worker-credential compromise.
@@ -293,6 +298,33 @@ node -e "
   (success / failure / denied) and paginated. Opening the log is itself
   recorded (an `audit.read` row), so reviewing the audit trail leaves
   its own forensic mark.
+- **Privacy exports hold the whole record; erasure states a basis per
+  domain.** A subject-access export walks every table that keys a row
+  by the customer — identity, orders, subscriptions, addresses, saved
+  payment-method metadata, support tickets, loyalty, reviews, the
+  consent ledger, wishlist, surveys, recently-viewed, suggestion-box
+  submissions, the save-for-later list, and the store-credit ledger —
+  so the bundle is the full record, not just the order/identity core.
+  The bundle carries a completeness manifest: every in-scope domain is
+  marked exported, empty, or absent, so a domain whose reader isn't
+  wired is visible rather than silently dropped. Erasure deletes the
+  pure-personalization domains (wishlist, recently-viewed, save-for-
+  later), anonymizes the suggestion-box rows in place (both identity
+  keys cleared, the de-identified text left as roadmap signal), revokes
+  every sign-in path and anonymizes the customer profile, and RETAINS
+  the records a controller keeps under a legal-obligation / accounting
+  basis (orders, loyalty ledger, store-credit ledger, consent
+  evidence, published reviews) — each with a stated basis in the
+  per-domain result. Preview a deletion with the dry-run flag to see
+  the blast radius before the irreversible call.
+- **HSTS on every TLS response, edge and container.** Both substrates
+  send `Strict-Transport-Security: max-age=63072000; includeSubDomains;
+  preload` (two years, above the preload-list minimum). The container
+  emits it behind the Cloudflare proxy by trusting the Worker-set
+  `X-Forwarded-Proto`, so a direct-to-container or edge-render-off
+  response carries the same header the edge sends; a plain-HTTP request
+  (local dev, direct non-TLS) omits it, which user agents ignore over
+  HTTP anyway.
 - **Email deliverability — SPF / DKIM / DMARC + one-click unsubscribe.**
   Transactional and broadcast mail is composed on `b.mail`, which signs
   each message with DKIM, but the receiving server still rejects or

package/lib/asset-manifest.json

@@ -1,5 +1,5 @@
 {
-  "version": "0.4.25",
+  "version": "0.4.26",
   "assets": {
     "css/admin.css": {
       "integrity": "sha384-imfe0otYErcB8rr2h6KLSGTtStirysptpXETSPY4zLv3bZoIT75Lo1dOvkOav+xL",
@@ -38,8 +38,8 @@
       "fingerprinted": "js/passkey-register.02b0e196fb9608d8.js"
     },
     "js/pay-trusted-types.js": {
-      "integrity": "sha384-jD90N8l7J3Vcu+aPSFRi6AE/5XKHQl58/avwHE9PH0mHwMavX991OCsEcznEf3n5",
-      "fingerprinted": "js/pay-trusted-types.53d0df13f9480a66.js"
+      "integrity": "sha384-h+/EjwX7ee88MouudamS26SgRg1bUXasRs9qD0Wcg6bGkK51CluebA3iATzedwdz",
+      "fingerprinted": "js/pay-trusted-types.08dc910a5c35d38a.js"
     },
     "js/pay.js": {
       "integrity": "sha384-W11JVQhv1RZq4WhsAOglu56gTZTDz1ByLd+b1HFQBCi8xGoEhJ0PZ2yI3FqbYzt6",

package/lib/compliance-export.js

@@ -11,9 +11,10 @@
  *   The primitive owns the request lifecycle + composes per-domain
  *   readers (customers, order, order-notes, subscriptions,
  *   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.
+ *   consent ledger, wishlist, surveys, recently-viewed, suggestion
+ *   box, save-for-later, store credit) 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
@@ -83,7 +84,8 @@
  *                          orders, subscriptions, addresses, payment
  *                          methods, support tickets, loyalty, reviews,
  *                          consent ledger, wishlist, surveys,
- *                          recently-viewed).
+ *                          recently-viewed, suggestion box,
+ *                          save-for-later, store credit).
  *     - `orders_only`    — only `order` + `orderNotes` contribute;
  *                          identity / loyalty / subscriptions /
  *                          addresses / payment methods / support
@@ -101,7 +103,7 @@
  * @related    customers, order, orderNotes, subscriptions, addresses,
  *             paymentMethods, supportTickets, loyalty, reviews,
  *             consentLedger, wishlist, customerSurveys, recentlyViewed,
- *             orderExport
+ *             suggestionBox, saveForLater, storeCredit, orderExport
  */
 
 var b = require("./vendor/blamejs");
@@ -188,6 +190,11 @@ var SCOPE_SECTIONS = Object.freeze({
     "customers", "addresses", "order", "orderNotes",
     "subscriptions", "paymentMethods", "supportTickets", "loyalty",
     "reviews", "consentLedger", "wishlist", "surveys", "recentlyViewed",
+    // Customer-authored feedback (ideas + complaints, keyed by id or a
+    // hashed email), the save-for-later holdover list, and the store-
+    // credit wallet ledger — each keys a row by the customer, so a
+    // subject-access export holds them too.
+    "suggestionBox", "saveForLater", "storeCredit",
   ]),
   orders_only: Object.freeze(["order", "orderNotes"]),
   identity_only: Object.freeze(["customers", "addresses"]),
@@ -361,6 +368,9 @@ function create(opts) {
     wishlist:       opts.wishlist       || null,
     surveys:        opts.surveys        || null,
     recentlyViewed: opts.recentlyViewed || null,
+    suggestionBox:  opts.suggestionBox  || null,
+    saveForLater:   opts.saveForLater   || null,
+    storeCredit:    opts.storeCredit    || null,
   };
 
   // ---- requestExport -------------------------------------------------
@@ -609,9 +619,10 @@ function create(opts) {
     }
 
     var domainOrder = [
-      "recentlyViewed", "wishlist", "surveys", "reviews", "consentLedger",
+      "recentlyViewed", "wishlist", "saveForLater", "suggestionBox",
+      "surveys", "reviews", "consentLedger",
       "supportTickets", "orderNotes", "order", "subscriptions",
-      "paymentMethods", "loyalty", "addresses", "customers",
+      "paymentMethods", "loyalty", "storeCredit", "addresses", "customers",
     ];
     var perDomain     = [];
     var domainsAbsent = [];

package/lib/order.js

@@ -110,6 +110,14 @@ var ORDER_STATES = Object.freeze([
   "pending", "paid", "fulfilling", "shipped", "delivered", "refunded", "cancelled",
 ]);
 
+// The proof routes a guest-order reconciliation can be attributed to.
+// "verified-email" = an OIDC sign-in whose provider verified the address;
+// "magic-link" = the buyer clicked a sign-in link emailed to the address.
+// Both prove control of the email — the trust anchor for the attach. An
+// unknown linked_via falls back to "verified-email" so a typo can't write
+// an unfiltered audit string.
+var RECONCILE_LINKED_VIA = Object.freeze(["verified-email", "magic-link"]);
+
 // Cursor key for listForCustomer — paginates by (updated_at DESC, id
 // DESC) so a newly transitioned order surfaces at the top of the
 // customer's order history without a stable-id tie-break flake.
@@ -1051,22 +1059,98 @@ function create(opts) {
 
     // Claim guest orders into a customer account by matching the
     // recorded buyer-email hash. The CALLER must only pass a hash for an
-    // email the identity provider VERIFIED — this method does not (and
-    // cannot) re-verify; linking an unverified email would be account
-    // takeover. Only touches orders with no owner yet (customer_id IS
-    // NULL), so it never re-assigns another customer's order. Returns
-    // the count linked.
-    linkGuestOrdersByEmailHash: async function (customerId, emailHash) {
+    // email the identity provider VERIFIED (an OIDC email_verified claim)
+    // or the buyer has otherwise proven control of (clicking an emailed
+    // magic-link) — this method does not (and cannot) re-verify; linking
+    // an unverified email would be account takeover. Only touches orders
+    // with no owner yet (customer_id IS NULL), so it never re-assigns
+    // another customer's order.
+    //
+    // Each newly-attached order also gets one append-only row in
+    // guest_order_reconciliations recording WHEN it was attached, to WHICH
+    // customer, by WHICH proof (linked_via), and the email_hash matched —
+    // so a disputed link is traceable and an operator/DSR review can replay
+    // it without inferring it from a customer_id that was overwritten. The
+    // audit row is the verified linking key only (the plaintext address is
+    // never stored anywhere).
+    //
+    // Idempotent at BOTH layers: the per-order claim-guard UPDATE only
+    // flips a still-unowned order (so a re-run links nothing new), and the
+    // audit INSERT is INSERT-OR-IGNORE against a UNIQUE (order_id,
+    // customer_id) index (so even a forced re-write records nothing new).
+    // The audit table is optional — when the migration hasn't run (a
+    // partial-schema test, or a deploy mid-migration) the INSERT throws and
+    // is swallowed so reconciliation never fails on the audit write; the
+    // attach (the load-bearing effect) still lands.
+    //
+    // `linkedVia` names the proof route — defaulted + constrained to a known
+    // token so a typo can't write an unfiltered string; an unknown value
+    // falls back to "verified-email". Returns the count linked.
+    linkGuestOrdersByEmailHash: async function (customerId, emailHash, opts2) {
       _uuid(customerId, "customer id");
       if (typeof emailHash !== "string" || !emailHash.length) {
         throw new TypeError("order.linkGuestOrdersByEmailHash: emailHash must be a non-empty string");
       }
-      var r = await query(
-        "UPDATE orders SET customer_id = ?1, updated_at = ?2 " +
-        "WHERE customer_id IS NULL AND customer_email_hash = ?3",
-        [customerId, _now(), emailHash],
-      );
-      return Number(r.rowCount || 0);
+      var linkedVia = (opts2 && opts2.linked_via) || "verified-email";
+      if (RECONCILE_LINKED_VIA.indexOf(linkedVia) === -1) linkedVia = "verified-email";
+
+      // The candidate set: every still-unowned order placed under this
+      // verified email. Claiming per-id (not one bulk UPDATE) is what lets
+      // the audit trail name the exact orders attached AND keeps the attach
+      // race-safe — a concurrent reconciliation for the same email can't
+      // double-claim because each UPDATE re-checks customer_id IS NULL.
+      var candidates = (await query(
+        "SELECT id FROM orders WHERE customer_id IS NULL AND customer_email_hash = ?1",
+        [emailHash],
+      )).rows;
+      var linked = 0;
+      for (var i = 0; i < candidates.length; i += 1) {
+        var orderId = candidates[i].id;
+        var ts = _now();
+        // Claim-guard: only flip an order STILL unowned at write time.
+        var upd = await query(
+          "UPDATE orders SET customer_id = ?1, updated_at = ?2 " +
+          "WHERE id = ?3 AND customer_id IS NULL",
+          [customerId, ts, orderId],
+        );
+        if (Number(upd.rowCount || 0) === 0) continue; // lost the race — another writer claimed it.
+        linked += 1;
+        // Append-only audit row. INSERT OR IGNORE against the UNIQUE
+        // (order_id, customer_id) index, so a re-run records nothing new.
+        // Swallowed on a missing-table error so the attach never fails on
+        // the audit write (the attach already landed above).
+        try {
+          await query(
+            "INSERT OR IGNORE INTO guest_order_reconciliations " +
+            "(id, order_id, customer_id, email_hash, linked_via, occurred_at) " +
+            "VALUES (?1, ?2, ?3, ?4, ?5, ?6)",
+            [b.uuid.v7(), orderId, customerId, emailHash, linkedVia, ts],
+          );
+        } catch (_e) { /* drop-silent — audit table optional; the attach is the load-bearing effect */ }
+      }
+      return linked;
+    },
+
+    // Every guest order reconciled into a customer account, newest first —
+    // the operator/DSR "how did this order get attached?" view. Returns the
+    // append-only audit rows (order_id, email_hash, linked_via, occurred_at)
+    // for the customer; an account that never claimed a guest order returns
+    // []. Defensive: when the audit table hasn't been migrated yet the read
+    // throws and is collapsed to [] (the feature degrades to "no trail",
+    // never a 500).
+    reconciliationsForCustomer: async function (customerId) {
+      _uuid(customerId, "customer id");
+      try {
+        var rows = (await query(
+          "SELECT id, order_id, customer_id, email_hash, linked_via, occurred_at " +
+          "FROM guest_order_reconciliations WHERE customer_id = ?1 " +
+          "ORDER BY occurred_at DESC, id DESC",
+          [customerId],
+        )).rows;
+        return rows;
+      } catch (_e) {
+        return [];
+      }
     },
 
     // Has this customer purchased this product? True iff an order

package/lib/save-for-later.js

@@ -56,6 +56,12 @@
  *       current; returns the count of rows actually changed.
  *     - `expireOlderThan(days)` — operator-scheduler entry point
  *       that prunes saves older than the supplied age.
+ *     - `exportForCustomer(customer_id)` — DSR export reader: the
+ *       subject's saved rows.
+ *     - `eraseForCustomer(customer_id, { dry_run? })` — DSR erasure:
+ *       deletes the subject's saved rows (pure personalization, no
+ *       retention basis). Returns the `{ table, deleted }` reader
+ *       contract.
  *
  *   Storage:
  *     - `save_for_later` (migration `0041_save_for_later.sql`).
@@ -641,6 +647,46 @@ function create(opts) {
       return { changed: changed };
     },
 
+    // ---- exportForCustomer / eraseForCustomer (DSR) -----------------
+    //
+    // Subject-access-request hooks consumed by complianceExport. A
+    // save-for-later row keys directly on `customer_id` — there is no
+    // hashed-identity branch (every row is account-bound).
+    //
+    // exportForCustomer(customer_id) — the subject's saved rows. Pure
+    // read; capped at MAX_LIMIT so one customer can't unbounded-stream
+    // the export.
+    exportForCustomer: async function (customerId) {
+      var cid = _uuid(customerId, "customer_id");
+      var rows = (await query(
+        "SELECT * FROM save_for_later WHERE customer_id = ?1 " +
+        "ORDER BY saved_at DESC, id DESC LIMIT ?2",
+        [cid, MAX_LIMIT],
+      )).rows;
+      return rows;
+    },
+
+    // eraseForCustomer(customer_id, { dry_run }) — GDPR Art. 17
+    // erasure. A save-for-later list is pure personalization with no
+    // retention basis, so erasure DELETES every row for the customer
+    // (the same effect as `clear`, returned in the complianceExport
+    // reader contract shape `{ table, deleted }`). dry_run counts the
+    // rows it WOULD remove without mutating. A re-run finds none
+    // (idempotent).
+    eraseForCustomer: async function (customerId, opts) {
+      var cid = _uuid(customerId, "customer_id");
+      var dryRun = !!(opts && opts.dry_run);
+      if (dryRun) {
+        var c = (await query(
+          "SELECT COUNT(*) AS n FROM save_for_later WHERE customer_id = ?1",
+          [cid],
+        )).rows[0];
+        return { table: "save_for_later", deleted: c ? Number(c.n) : 0 };
+      }
+      var r = await query("DELETE FROM save_for_later WHERE customer_id = ?1", [cid]);
+      return { table: "save_for_later", deleted: Number(r.rowCount || 0) };
+    },
+
     // Operator scheduler entry point: remove every save older than
     // the supplied age. Returns the count of removed rows so the
     // cron / scheduled-worker layer can emit a metric.

package/lib/security-middleware.js

@@ -290,7 +290,25 @@ function clientKey(req) {
  * so both substrates stay header-consistent.
  */
 function securityHeadersOpts() {
-  return { documentPolicy: false, referrerPolicy: "same-origin" };
+  // `trustProxy: true` is what lets the vendored HSTS header actually
+  // ship from the container. The vendored securityHeaders middleware
+  // emits Strict-Transport-Security ONLY when the request protocol
+  // resolves to https (RFC 6797 §7.2: HSTS over plain HTTP is ignored by
+  // UAs, so the middleware suppresses it on non-TLS requests). Behind the
+  // Cloudflare Worker the container socket is plain http and the real
+  // scheme rides in the Worker-set `x-forwarded-proto: https` — without
+  // trustProxy the middleware reads `http`, decides the request isn't
+  // TLS, and drops HSTS on EVERY container-served response. The edge
+  // Worker sets its own HSTS on edge-rendered pages, but a direct-to-
+  // container request (edge render off, or an internal hop that returns
+  // HTML) then carries no HSTS at all. Opting into the forwarded-proto
+  // header — the same stance the csrf gate already takes (mountRouteGuards
+  // passes trustProxy:true) and the storefront session-cookie path takes
+  // (`_secureForReq`) — restores the header on container responses. HSTS
+  // stays OWNED by the vendored middleware (we set no header ourselves),
+  // so there is no double-set: on an edge-rendered page only the Worker's
+  // header is present; on a container-served page only this one is.
+  return { documentPolicy: false, referrerPolicy: "same-origin", trustProxy: true };
 }
 
 // ---- route-scoped CSP (payment processors + CAPTCHA providers) ----------

package/lib/store-credit.js

@@ -52,6 +52,11 @@
  *     - expiringWithin({ customer_id, days })
  *     - bulkBalance({ customer_ids })
  *     - cleanupExpired({ now })
+ *     - exportForCustomer(customer_id) — DSR export reader: the
+ *       subject's balance + full ledger history.
+ *     - eraseForCustomer(customer_id, { dry_run? }) — DSR erasure:
+ *       RETAINS (financial ledger, legal-obligation basis). Returns
+ *       the `{ table, deleted: 0, note }` reader contract.
  *
  *   Storage:
  *     - store_credit_ledger (migration 0094).
@@ -491,6 +496,42 @@ function create(opts) {
       return out;
     },
 
+    // ---- exportForCustomer / eraseForCustomer (DSR) -----------------
+    //
+    // Subject-access-request hooks consumed by complianceExport. The
+    // ledger keys on `customer_id`.
+    //
+    // exportForCustomer(customer_id) — the subject's current balance +
+    // their full ledger history (the financial record of every credit /
+    // debit / expire against their wallet). Pure read; the history is
+    // capped at the same 500-row ceiling `history()` enforces.
+    exportForCustomer: async function (customerId) {
+      var cid = _uuid(customerId, "customer_id");
+      var bal = await _currentBalance(cid);
+      var r = await query(
+        "SELECT id, customer_id, kind, amount_minor, source, source_ref, order_id, " +
+        "balance_after_minor, expires_at, occurred_at FROM store_credit_ledger " +
+        "WHERE customer_id = ?1 ORDER BY occurred_at DESC, id DESC LIMIT 500",
+        [cid],
+      );
+      return { balance_minor: bal, history: r.rows };
+    },
+
+    // eraseForCustomer(customer_id, { dry_run }) — store credit is a
+    // financial ledger: an audited record of money owed to and spent by
+    // the customer, retained under the controller's legal-obligation /
+    // accounting basis (the same posture as the loyalty ledger and gift
+    // cards in the DSR reader map). Erasure RETAINS — deleting the rows
+    // would destroy the proof of a balance the customer may still be
+    // entitled to and the accounting trail a tax / chargeback audit
+    // needs. Returns `{ table, deleted: 0, note }`; dry_run reports the
+    // same retain decision (0 rows would be removed). The customer-
+    // identity scrub rides the anonymized customers row.
+    eraseForCustomer: async function (customerId, _opts) {
+      _uuid(customerId, "customer_id");
+      return { table: "store_credit_ledger", deleted: 0, note: "retained-financial-ledger" };
+    },
+
     cleanupExpired: async function (input) {
       input = input || {};
       var now = _epochMs(input.now, "now");

package/lib/storefront.js

@@ -15873,7 +15873,8 @@ function mount(router, deps) {
           try {
             var portalCust = await deps.customers.get(rv.customer_id);
             if (portalCust && portalCust.email_hash) {
-              await deps.order.linkGuestOrdersByEmailHash(rv.customer_id, portalCust.email_hash);
+              await deps.order.linkGuestOrdersByEmailHash(
+                rv.customer_id, portalCust.email_hash, { linked_via: "magic-link" });
             }
           } catch (_eLink) { /* drop-silent — sign-in itself succeeds */ }
         }
@@ -16124,6 +16125,17 @@ function mount(router, deps) {
             if (anonCart) await deps.cart.setCustomer(anonCart.id, customer.id);
           } catch (_e) { /* best-effort merge; sign-in itself succeeds */ }
         }
+        // Guest-order reconciliation is deliberately NOT done here. A passkey
+        // assertion proves control of the AUTHENTICATOR, not of the account's
+        // email — and a passkey-registered account's email_hash was never
+        // verified (the register path stores whatever address was typed). The
+        // attach is gated strictly on PROVEN email ownership: an OIDC sign-in
+        // the provider verified, or a magic-link the buyer clicked. Linking on
+        // the account's unverified email_hash here would let an attacker who
+        // registered a passkey under a victim's address inherit the victim's
+        // guest orders — the takeover class the customers model guards against.
+        // A passkey-account holder who wants their guest orders attached signs
+        // in once via the magic-link, which proves the email and reconciles.
         _clearChallengeCookie(res);
         _setAuthCookie(req, res, {
           customer_id: customer.id,
@@ -16949,7 +16961,8 @@ function mount(router, deps) {
         if (claims.email_verified === true && claims.email && deps.order &&
             typeof deps.order.linkGuestOrdersByEmailHash === "function") {
           try {
-            await deps.order.linkGuestOrdersByEmailHash(rv.customer.id, deps.customers.hashEmail(claims.email));
+            await deps.order.linkGuestOrdersByEmailHash(
+              rv.customer.id, deps.customers.hashEmail(claims.email), { linked_via: "verified-email" });
           } catch (_e) { /* best-effort reconciliation; sign-in succeeds regardless */ }
         }
         // Attribute a referral ONLY on a genuinely new account
@@ -17063,7 +17076,8 @@ function mount(router, deps) {
         if (emailVerified && claims.email && deps.order &&
             typeof deps.order.linkGuestOrdersByEmailHash === "function") {
           try {
-            await deps.order.linkGuestOrdersByEmailHash(rv.customer.id, deps.customers.hashEmail(claims.email));
+            await deps.order.linkGuestOrdersByEmailHash(
+              rv.customer.id, deps.customers.hashEmail(claims.email), { linked_via: "verified-email" });
           } catch (_e) { /* best-effort reconciliation; sign-in succeeds regardless */ }
         }
         // Attribute a referral ONLY on a genuinely new account (rv.created)

package/lib/suggestion-box.js

@@ -102,6 +102,13 @@
  *     - metricsForCategory({ category, from, to })
  *     - archiveSuggestion(id)
  *     - flagAsSpam({ suggestion_id, flagged })
+ *     - exportForCustomer({ customer_id?, email_hash? }) — DSR export
+ *       reader: the subject's own suggestion rows (matched on
+ *       customer_id OR the suggestion-box-namespace email hash).
+ *     - eraseForCustomer({ customer_id?, email_hash?, dry_run? }) —
+ *       DSR erasure: anonymizes the subject's rows in place (both
+ *       identity keys -> NULL), keeping the de-identified roadmap
+ *       signal. Returns the `{ table, deleted }` reader contract.
  *
  *   Storage: `migrations-d1/0181_suggestion_box.sql` —
  *     `suggestions` + `suggestion_votes`.
@@ -850,6 +857,121 @@ function create(opts) {
     return _decode(await _getRaw(sid));
   }
 
+  // ---- exportForCustomer / eraseForCustomer (DSR) -----------------------
+  //
+  // Subject-access-request hooks consumed by complianceExport. A
+  // suggestion row is keyed to a person by EITHER `customer_id` (an
+  // authenticated submission) OR `customer_email_hash` (a storefront
+  // visitor who supplied a confirmed email but wasn't signed in). The
+  // email is hashed under the `suggestion-box-email` namespace
+  // (EMAIL_NAMESPACE), distinct from the customers table's own
+  // `customer-email` namespace, and the raw email is never stored —
+  // so an email-only row can be matched to a customer ONLY when the
+  // caller can supply that same suggestion-box namespace hash.
+  //
+  // The DSR composition root resolves a customer by `customer_id`
+  // (no raw email is held anywhere in the system to re-hash), so it
+  // passes `customer_id` and — when the requesting customer's email
+  // is known in-session — the derived `email_hash`. Both keys are
+  // matched with OR so a customer's authenticated AND email-only
+  // submissions are covered. A caller WITH the raw email derives the
+  // hash via the exported EMAIL_NAMESPACE + b.crypto.namespaceHash.
+
+  // Normalize the DSR selector: at least one of customer_id /
+  // email_hash must be present. Returns { custId, emailHash } with
+  // validated/null values. Defensive request-shape reader at the
+  // primitive boundary — bad UUID shape throws (operator catches the
+  // typo); a null/absent key is simply not used in the predicate.
+  function _dsrSelector(input, method) {
+    if (!input || typeof input !== "object") {
+      throw new TypeError("suggestionBox." + method + ": input object required");
+    }
+    var custId    = _customerIdOpt(input.customer_id);
+    var emailHash = null;
+    if (input.email_hash != null) {
+      if (typeof input.email_hash !== "string" || !input.email_hash.length || input.email_hash.length > 256) {
+        throw new TypeError("suggestionBox." + method + ": email_hash must be a non-empty string <= 256 chars when provided");
+      }
+      if (CONTROL_BYTE_STRICT_RE.test(input.email_hash) || ZERO_WIDTH_RE.test(input.email_hash)) {
+        throw new TypeError("suggestionBox." + method + ": email_hash contains control / zero-width bytes");
+      }
+      emailHash = input.email_hash;
+    }
+    if (custId == null && emailHash == null) {
+      throw new TypeError("suggestionBox." + method + ": at least one of customer_id / email_hash is required");
+    }
+    return { custId: custId, emailHash: emailHash };
+  }
+
+  // Build the `customer_id = ? OR customer_email_hash = ?` predicate
+  // from whichever selector keys are present, returning { clause,
+  // params }. Shared by export + erase so the two never diverge on
+  // which rows belong to the subject.
+  function _dsrWhere(sel) {
+    var ors    = [];
+    var params = [];
+    var idx    = 1;
+    if (sel.custId != null)    { ors.push("customer_id = ?" + idx);         params.push(sel.custId);    idx += 1; }
+    if (sel.emailHash != null) { ors.push("customer_email_hash = ?" + idx); params.push(sel.emailHash); idx += 1; }
+    return { clause: "(" + ors.join(" OR ") + ")", params: params };
+  }
+
+  // exportForCustomer({ customer_id?, email_hash? }) — returns the
+  // subject's own suggestion rows (decoded). Read-only; capped at
+  // MAX_LIST_LIMIT so a single customer's history can't unbounded-
+  // stream the export. Spam-flagged / archived rows ARE included —
+  // the subject is entitled to a copy of everything held about them,
+  // including operator-only tombstoned rows.
+  async function exportForCustomer(input) {
+    var sel = _dsrSelector(input, "exportForCustomer");
+    var w   = _dsrWhere(sel);
+    var r = await query(
+      "SELECT * FROM suggestions WHERE " + w.clause +
+      " ORDER BY created_at DESC, id DESC LIMIT ?" + (w.params.length + 1),
+      w.params.concat([MAX_LIST_LIMIT]),
+    );
+    var out = [];
+    for (var i = 0; i < r.rows.length; i += 1) out.push(_decode(r.rows[i]));
+    return out;
+  }
+
+  // eraseForCustomer({ customer_id?, email_hash?, dry_run? }) —
+  // GDPR Art. 17 erasure. A suggestion (especially a `complaint`)
+  // carries the customer's own free-text words + a hashed email, so
+  // it is personal data with no retention basis once the subject
+  // asks for erasure. Rather than DELETE the row (which would orphan
+  // any votes / canonical-link pointers and lose the operator's
+  // roadmap signal), this ANONYMIZES it in place: severs both
+  // identity keys (customer_id + customer_email_hash → NULL) so the
+  // row can no longer be traced to the person, while the
+  // already-published title/body/votes stay as de-identified
+  // roadmap input. dry_run counts the rows it WOULD anonymize
+  // without mutating. Returns the complianceExport reader contract
+  // shape `{ table, deleted }`.
+  async function eraseForCustomer(input) {
+    var dryRun = !!(input && input.dry_run);
+    var sel = _dsrSelector(input, "eraseForCustomer");
+    var w   = _dsrWhere(sel);
+    // Only rows still carrying an identity key need anonymizing —
+    // a re-run finds none (idempotent).
+    var countRow = (await query(
+      "SELECT COUNT(*) AS n FROM suggestions WHERE " + w.clause +
+      " AND (customer_id IS NOT NULL OR customer_email_hash IS NOT NULL)",
+      w.params,
+    )).rows[0];
+    var n = countRow ? Number(countRow.n) : 0;
+    if (dryRun) return { table: "suggestions", deleted: n };
+    if (n === 0) return { table: "suggestions", deleted: 0 };
+    var ts = _now();
+    var res = await query(
+      "UPDATE suggestions SET customer_id = NULL, customer_email_hash = NULL, updated_at = ?" +
+      (w.params.length + 1) + " WHERE " + w.clause +
+      " AND (customer_id IS NOT NULL OR customer_email_hash IS NOT NULL)",
+      w.params.concat([ts]),
+    );
+    return { table: "suggestions", deleted: Number((res && res.rowCount) || 0) };
+  }
+
   // ---- flagAsSpam -------------------------------------------------------
   //
   // Operator-only. Sets spam_flagged = 1 (or back to 0 if the
@@ -897,6 +1019,8 @@ function create(opts) {
     metricsForCategory:   metricsForCategory,
     archiveSuggestion:    archiveSuggestion,
     flagAsSpam:           flagAsSpam,
+    exportForCustomer:    exportForCustomer,
+    eraseForCustomer:     eraseForCustomer,
   };
 }
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@blamejs/blamejs-shop",
-  "version": "0.4.25",
+  "version": "0.4.26",
   "description": "Open-source framework built on blamejs. Vendored stack, zero npm runtime deps, PQC-first crypto, security-on by default.",
   "main": "lib/index.js",
   "scripts": {