@blamejs/blamejs-shop 0.4.29 → 0.4.30

package/CHANGELOG.md

@@ -8,6 +8,8 @@ upgrading across more than a few patches at a time.
 
 ## v0.4.x
 
+- v0.4.30 (2026-06-11) — **Privacy exports and erasures now cover every customer-keyed table — including the guest-order claim audit, stock alerts' plaintext email, quotes, ratings, Q&A, operator notes, gift cards, and referrals.** A privacy-completeness release. A subject-access export now walks eight more customer-keyed domains, and erasure handles each with a stated basis: the guest-order claim audit's email hash — a verbatim copy of the lookup key the account erasure deliberately severs, which previously survived in full — is tombstoned under its own derivation while the order linkage stays under the audit basis; a stock-alert subscription's plaintext email is deleted outright; quotes, ratings, and Q&A keep their de-identified business records with the customer's free text and identity keys cleared; operator notes are deleted; gift cards and referral records stay under their accounting basis with the identity links severed. A stock-alert subscription made while signed in now links to the account, so it follows the customer through export and erasure rather than floating free. Every new domain reports in the export's completeness manifest and in the erasure's per-domain results — an unwired reader shows as absent, never silently dropped. No migration to apply. **Changed:** *Six more domains in the export, each with stated erasure semantics* — Quote requests and their negotiation messages, fulfillment ratings, product Q&A, operator customer notes, gift-card issue records, and referral activity (in both directions — as referrer and as referred) now stream into the subject-access export. Erasure treats each by its nature: the customer's quote message and Q&A identity are cleared in place with the de-identified business record retained, ratings and operator notes are deleted, and gift cards and referral accounting stay under their legal-obligation basis with the identity links severed and referred-email hashes tombstoned. Each domain reports its effect in the deletion result, and a deletion preview (dry run) touches nothing — verified per domain. **Fixed:** *Guest-order claim records join the export and erasure* — When a guest order attaches to an account on verified sign-in, the attachment is recorded with the buyer's email hash as the linking key. Those records are now part of the subject-access export, and an erasure tombstones the email hash under a derivation distinct from the account-level tombstone — so the two can never be cross-correlated — while the order linkage itself is retained under the same audit basis orders use. Previously the records were absent from the export, untouched by erasure, and invisible in the completeness manifest, and the surviving hash defeated the account erasure's deliberate severing of that key. · *Stock-alert subscriptions stop outliving an erasure* — A back-in-stock subscription stores the subscriber's email in plaintext — it has to send mail to it — but those rows survived an account erasure and never appeared in the export. The export now includes the customer's subscriptions (minus the bearer token hashes), erasure deletes the rows outright — freeing the address to subscribe again — and a subscription made while signed in is linked to the account so it follows the customer. Anonymous subscriptions keep their existing bounded lifetime and stay reachable by their unsubscribe token.
+
 - v0.4.29 (2026-06-11) — **A gift card can no longer pay for two orders at once — credits debit before any charge — and store-credit wallets, capped discounts, and the gift-card audit chain all hold under concurrency.** A money-integrity release closing five concurrency windows, each reproduced before fixing. The serious one: gift-card and loyalty credits were debited after the order existed, with failures captured for reconciliation — so two simultaneous checkouts presenting the same gift card both produced paid orders while the card was only debited once. Credits now debit before any charge: the database balance gate decides the race, the loser gets a clean re-quote, and a checkout that fails after the debit but before the order exists reverses the debit automatically. Store-credit wallets stop computing balances from a stale read — concurrent debits can no longer overdraw, and two grants landing in the same millisecond both count. Capped automatic discounts are reserved atomically before charging, so a last-redemption race refuses one buyer with a clear message instead of granting both. Every gift-card ledger entry — debits included — now participates in the per-card tamper-evidence hash chain, a uniqueness fence keeps concurrent writes from forking it, and a new verifyChain call recomputes a card's chain on demand. The payment idempotency cache absorbs same-key races instead of failing one of them. Upgrade applies two D1 migrations. **Fixed:** *Store-credit wallets hold under concurrent writes* — Wallet writes computed the new balance from a separately-read snapshot, so two concurrent debits could both fulfill against one balance — overdrawing the wallet — and two grants landing in the same millisecond could tie on their timestamp and silently drop one. Every wallet write now computes the live balance and a strictly-monotonic per-customer timestamp inside a single guarded insert: a debit that loses the race is refused as insufficient, both same-instant grants land and sum, and the scheduled expiry sweep keeps its degrade-gracefully cap. · *Capped automatic discounts are reserved before charging* — A rule's redemption caps were only read at quote time and counted after the order existed, so a single-use discount applied to every order that raced the last redemption. The applied rules are now claimed atomically before any charge — total cap and per-customer cap both enforced inside single guarded statements — and a refused claim fails the checkout closed with a clear message and re-quote, never a silently different price. A checkout that fails before its order exists releases its reservations, recording a redemption is idempotent per order, and a retried checkout reuses its own claim instead of double-reserving. · *Same-key payment calls absorb their race* — Two concurrent calls carrying the same idempotency key could both miss the replay cache and collide on its primary key, failing one of them with a constraint error. The cache claim is now conflict-aware: one call stores its response, the other defers to it and replays — and a same-key call carrying a different request body is still refused as a collision, racing or not. **Security:** *Gift-card and loyalty credits debit before any charge* — A checkout's gift-card and loyalty debits are now the first money movement, ahead of the payment intent and the order row, on the card-payment and PayPal paths alike. The database balance predicate is the cross-checkout double-spend gate: two carts presenting the same card race it directly, exactly one wins, and the loser's checkout rolls back cleanly — stock holds released, cart reusable, a clear message and re-quote, nothing charged. A checkout that dies between the debit and order creation reverses the debit (claim-guarded, exactly once). Once the order exists the debit is attached to it, so refunds and cancellations keep reversing credit proportionally exactly as before. · *Every gift-card ledger entry is chained, and the chain can't fork* — Debit rows — previously written outside the hash chain by the atomic overdraft guard — now carry the same parent and row hashes as credits and expirations, with the overdraft gate still enforced inside the insert. A per-card uniqueness fence (one child per chain tip) makes concurrent writes serialize instead of forking the chain or basing a balance on a stale snapshot; a writer that loses the race re-reads the tip and retries. A new verifyChain call recomputes a card's chain end to end and reports the first divergence, tolerating rows that predate the chain columns as a counted, unverifiable prefix.
 
 - v0.4.28 (2026-06-11) — **Console refunds reach PayPal, refund webhooks apply their stated amount instead of reversing everything, and gift cards and loyalty points now ride the PayPal button.** A payment-lifecycle release for stores taking PayPal. Refunding a PayPal-paid order from the console — full, partial, or through the returns flow — now dials PayPal; previously every console refund dialed the card processor with a PayPal id and failed, leaving the PayPal dashboard as the only way to refund. Refund webhooks from both processors now apply the amount they state: a partial refund issued from the processor's dashboard reverses gift-card and loyalty credit proportionally, where before it triggered the full terminal reversal and could hand a customer the entire credited value back for a five-dollar refund. PayPal webhook deliveries are now claimed in a replay store after signature verification, the verification call runs on its own circuit breaker behind a per-IP budget so a forged-delivery flood can't fast-fail live checkouts, and a buyer paying with the PayPal button can now apply a gift card or spend loyalty points like any other checkout. A deployment with PayPal credentials but no webhook id gets a boot warning naming the missing variable. Upgrade applies two D1 migrations. **Fixed:** *Console refunds route by the order's payment provider* — Orders persist which processor took the payment, and every refund surface — the order console's full and partial refund, the returns console's provider refund, and the refund-automation library — routes to that processor. PayPal refunds dial the capture (recovered from the order record, the payment transition's metadata, or the PayPal API, in that order), and the operator's idempotency key flows through as the PayPal request id so a retried partial refund deduplicates while distinct partial refunds execute distinctly. Orders that predate the provider column fall back to the payment-id shape. The refund button now reflects provider reality: it offers a refund only when the processor that took the payment is configured, and refuses with a specific reason — provider not configured, no capture on record — instead of a generic failure. · *Refund webhooks apply their stated amount* — A refund event arriving from the processor now reads the refunded amount instead of unconditionally driving the order to the terminal refunded state. A partial refund reverses gift-card and loyalty credit proportionally through the same accounting the console's partial refund uses; only a balance-clearing refund transitions the order to refunded. Both processors are covered: PayPal events carry a per-refund amount and deduplicate on the refund id, card-processor events carry a cumulative total and apply the delta against the local ledger. An event with a missing or unparseable amount is refused so the processor redelivers it — the handler never guesses a full refund. · *Gift cards and loyalty points apply to PayPal button payments* — The PayPal button now sends the gift-card code and loyalty-points fields from the pay form, matching card checkout. When a gift card covers the whole total, the page completes the order and redirects without opening the PayPal popup — the previous behavior surfaced a payment error to the buyer after the order had already been created, paid, and the card debited. **Security:** *PayPal webhook deliveries are claimed once and verified in isolation* — Each verified PayPal event id is claimed in a replay store before any state transition — matching the card-processor webhook discipline — so a replayed or re-delivered event is absorbed exactly once across the redelivery window. The signature-verification call to PayPal runs on its own circuit breaker, and the webhook path carries a per-IP request budget, so a flood of forged deliveries can neither trip the breaker that live checkout dials ride nor crowd out legitimate redeliveries. · *Boot warning when the PayPal webhook id is missing* — A deployment with PayPal client credentials but no PAYPAL_WEBHOOK_ID logs a warning at boot naming the variable. Verification itself remains mandatory and fails closed — without the id every webhook delivery is refused, which keeps forged events out but also means dashboard-issued refunds never mirror locally and PayPal will eventually disable the webhook endpoint; the warning makes that state visible instead of silent.

package/SECURITY.md

@@ -325,20 +325,29 @@ node -e "
   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 —
+  submissions, the save-for-later list, the store-credit ledger, the
+  guest-order claim audit trail, back-in-stock alerts, quotes, order
+  ratings, product Q&A questions, operator notes about the customer,
+  gift cards issued to them, and referral activity in both directions —
   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
+  later, stock alerts — including the alert's plaintext address — order
+  ratings, and operator customer notes), anonymizes in place the rows
+  whose de-identified content stays useful (suggestion-box submissions
+  and product Q&A questions: identity keys cleared, text retained),
+  clears the customer-authored message on retained quotes, 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.
+  basis (orders, loyalty ledger, store-credit ledger, consent evidence,
+  published reviews, gift cards and referral reward accounting with
+  their identity keys severed, and the guest-order claim audit rows
+  with the recorded email hash replaced by a non-reversible tombstone)
+  — 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

package/lib/asset-manifest.json

@@ -1,5 +1,5 @@
 {
-  "version": "0.4.29",
+  "version": "0.4.30",
   "assets": {
     "css/admin.css": {
       "integrity": "sha384-imfe0otYErcB8rr2h6KLSGTtStirysptpXETSPY4zLv3bZoIT75Lo1dOvkOav+xL",

package/lib/compliance-export.js

@@ -12,7 +12,9 @@
  *   readers (customers, order, order-notes, subscriptions,
  *   addresses, payment-methods, support-tickets, loyalty, reviews,
  *   consent ledger, wishlist, surveys, recently-viewed, suggestion
- *   box, save-for-later, store credit) to assemble the bundle —
+ *   box, save-for-later, store credit, guest-order reconciliations,
+ *   stock alerts, quotes, order ratings, product Q&A, customer
+ *   notes, gift cards, referrals) 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
@@ -85,7 +87,10 @@
  *                          methods, support tickets, loyalty, reviews,
  *                          consent ledger, wishlist, surveys,
  *                          recently-viewed, suggestion box,
- *                          save-for-later, store credit).
+ *                          save-for-later, store credit, guest-order
+ *                          reconciliations, stock alerts, quotes,
+ *                          order ratings, product Q&A, customer
+ *                          notes, gift cards, referrals).
  *     - `orders_only`    — only `order` + `orderNotes` contribute;
  *                          identity / loyalty / subscriptions /
  *                          addresses / payment methods / support
@@ -103,7 +108,9 @@
  * @related    customers, order, orderNotes, subscriptions, addresses,
  *             paymentMethods, supportTickets, loyalty, reviews,
  *             consentLedger, wishlist, customerSurveys, recentlyViewed,
- *             suggestionBox, saveForLater, storeCredit, orderExport
+ *             suggestionBox, saveForLater, storeCredit, stockAlerts,
+ *             quotes, orderRatings, productQA, customerNotes,
+ *             giftcards, referrals, orderExport
  */
 
 var b = require("./vendor/blamejs");
@@ -195,6 +202,14 @@ var SCOPE_SECTIONS = Object.freeze({
     // credit wallet ledger — each keys a row by the customer, so a
     // subject-access export holds them too.
     "suggestionBox", "saveForLater", "storeCredit",
+    // The remaining customer-keyed domains: the guest-order
+    // reconciliation audit trail, back-in-stock alert subscriptions
+    // (which hold a plaintext email), RFQ quotes, post-fulfillment
+    // ratings, product Q&A questions, operator CRM notes about the
+    // customer, gift cards issued to them, and referral activity in
+    // both directions (as referrer and as referred friend).
+    "guestOrderReconciliations", "stockAlerts", "quotes", "orderRatings",
+    "productQa", "customerNotes", "giftcards", "referrals",
   ]),
   orders_only: Object.freeze(["order", "orderNotes"]),
   identity_only: Object.freeze(["customers", "addresses"]),
@@ -371,6 +386,14 @@ function create(opts) {
     suggestionBox:  opts.suggestionBox  || null,
     saveForLater:   opts.saveForLater   || null,
     storeCredit:    opts.storeCredit    || null,
+    guestOrderReconciliations: opts.guestOrderReconciliations || null,
+    stockAlerts:    opts.stockAlerts    || null,
+    quotes:         opts.quotes         || null,
+    orderRatings:   opts.orderRatings   || null,
+    productQa:      opts.productQa      || null,
+    customerNotes:  opts.customerNotes  || null,
+    giftcards:      opts.giftcards      || null,
+    referrals:      opts.referrals      || null,
   };
 
   // ---- requestExport -------------------------------------------------
@@ -619,10 +642,12 @@ function create(opts) {
     }
 
     var domainOrder = [
-      "recentlyViewed", "wishlist", "saveForLater", "suggestionBox",
-      "surveys", "reviews", "consentLedger",
-      "supportTickets", "orderNotes", "order", "subscriptions",
-      "paymentMethods", "loyalty", "storeCredit", "addresses", "customers",
+      "recentlyViewed", "wishlist", "saveForLater", "stockAlerts",
+      "suggestionBox", "surveys", "reviews", "orderRatings", "productQa",
+      "quotes", "customerNotes", "consentLedger",
+      "supportTickets", "orderNotes", "order", "guestOrderReconciliations",
+      "subscriptions", "paymentMethods", "loyalty", "storeCredit",
+      "giftcards", "referrals", "addresses", "customers",
     ];
     var perDomain     = [];
     var domainsAbsent = [];

package/lib/order.js

@@ -1219,6 +1219,52 @@ function create(opts) {
       }
     },
 
+    // Erasure scrub for the reconciliation audit trail. The attach linkage
+    // (order_id / customer_id / linked_via / occurred_at) is RETAINED under
+    // the same audit basis the orders themselves carry — a disputed link
+    // must stay traceable after the account is gone. But the recorded
+    // email_hash is a verbatim copy of the live customer-email lookup key,
+    // and account erasure deliberately severs that key on the customers
+    // row, so a surviving copy here would defeat the severance for any
+    // customer who ever claimed a guest order. This rewrites it to a
+    // per-customer, non-reversible tombstone under its OWN hash namespace
+    // ("guest-recon-erased-email" — deliberately distinct from the
+    // customers row's "customer-erased-email" label, so the two tombstones
+    // never share a digest and can't be correlated as the same
+    // derivation). Only live (non-tombstoned) hashes rewrite, so a re-run
+    // is a no-op.
+    //
+    // `dry_run: true` counts the rows a wet run WOULD rewrite without
+    // mutating anything — the side-effect-free preview the deletion
+    // pipeline's dry-run contract requires. Returns `{ table, deleted }`
+    // where `deleted` is the rows tombstoned (the rows themselves stay).
+    // Defensive: a schema without the audit table collapses to
+    // `{ table, deleted: 0 }` (drop-silent, same posture as the sibling
+    // reads) so a partial schema never fails the caller's erasure run.
+    scrubReconciliationEmailHashForCustomer: async function (customerId, opts2) {
+      _uuid(customerId, "customer id");
+      var dryRun = !!(opts2 && opts2.dry_run);
+      try {
+        if (dryRun) {
+          var c = (await query(
+            "SELECT COUNT(*) AS n FROM guest_order_reconciliations " +
+            "WHERE customer_id = ?1 AND email_hash NOT LIKE 'erased:%'",
+            [customerId],
+          )).rows[0];
+          return { table: "guest_order_reconciliations", deleted: c ? Number(c.n) : 0 };
+        }
+        var tombstone = "erased:" + b.crypto.namespaceHash("guest-recon-erased-email", customerId);
+        var r = await query(
+          "UPDATE guest_order_reconciliations SET email_hash = ?1 " +
+          "WHERE customer_id = ?2 AND email_hash NOT LIKE 'erased:%'",
+          [tombstone, customerId],
+        );
+        return { table: "guest_order_reconciliations", deleted: Number((r && r.rowCount) || 0) };
+      } catch (_e) {
+        return { table: "guest_order_reconciliations", deleted: 0 };
+      }
+    },
+
     // Has this customer purchased this product? True iff an order
     // line for any variant of the product sits in an order owned by
     // the customer whose status is a real purchase — anything except

package/lib/stock-alerts.js

@@ -33,6 +33,15 @@
  *   prior row's terminal state is cleared from the unique-index slot
  *   first.
  *
+ *   Privacy requests. `exportForCustomer({ customer_id?, email_hash? })`
+ *   returns the subject's subscription rows (the plaintext address
+ *   included — it is the subject's own data; token hashes excluded)
+ *   and `eraseForCustomer({ customer_id?, email_hash?, dry_run? })`
+ *   hard-deletes them — a stock alert is convenience data with no
+ *   retention basis. Both match on customer_id OR the stock-alert-
+ *   namespace email hash, so a caller holding either key covers the
+ *   subject's rows.
+ *
  *   Composes:
  *     - `b.crypto.namespaceHash` — email hash + token hash.
  *     - `b.crypto.generateBytes` — 24 random bytes →
@@ -157,6 +166,43 @@ function _hashUnsubToken(plaintext) {
   return b.crypto.namespaceHash(UNSUB_NAMESPACE, plaintext);
 }
 
+// Normalize the DSR selector for exportForCustomer / eraseForCustomer:
+// at least one of customer_id / email_hash must be present. Bad UUID
+// shape throws (operator catches the typo at the boundary); a null /
+// absent key is simply not used in the predicate. `email_hash` is the
+// stock-alert-namespace digest (hex from b.crypto.namespaceHash), so a
+// generous shape gate (non-empty printable string) is all it needs.
+function _dsrSelector(input, method) {
+  if (!input || typeof input !== "object") {
+    throw new TypeError("stockAlerts." + method + ": input object required");
+  }
+  var custId    = _optUuid(input.customer_id, "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 || /[\x00-\x1f\x7f]/.test(input.email_hash)) {
+      throw new TypeError("stockAlerts." + method + ": email_hash must be a non-empty printable string <= 256 chars when provided");
+    }
+    emailHash = input.email_hash;
+  }
+  if (custId == null && emailHash == null) {
+    throw new TypeError("stockAlerts." + method + ": at least one of customer_id / email_hash is required");
+  }
+  return { custId: custId, emailHash: emailHash };
+}
+
+// Build the `customer_id = ? OR email_hash = ?` predicate from whichever
+// selector keys are present. 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("email_hash = ?" + idx);  params.push(sel.emailHash); idx += 1; }
+  return { clause: "(" + ors.join(" OR ") + ")", params: params };
+}
+
 // ---- factory ------------------------------------------------------------
 
 function create(opts) {
@@ -235,6 +281,14 @@ function create(opts) {
       if (existing) {
         var stillLive = existing.notified_at == null && Number(existing.expires_at) > now;
         if (stillLive) {
+          // A re-subscribe NEVER re-keys the existing row's customer_id.
+          // The email on this request is caller-supplied and unproven, so
+          // adopting a row first created by someone else would let a
+          // signed-in caller pull a stranger's subscription into their own
+          // account scope. A row stays owned by whoever the INSERT linked
+          // it to (or anonymous); anonymous rows are reachable for privacy
+          // requests via the email_hash key + bearer token, exactly as
+          // eraseForCustomer's residual-scope note documents.
           return {
             id:         existing.id,
             status:     existing.confirmed_at == null ? "already-pending" : "already-confirmed",
@@ -427,6 +481,62 @@ function create(opts) {
       return rows;
     },
 
+    // exportForCustomer({ customer_id?, email_hash? }) — subject-access
+    // (Art. 15) read. A subscription is keyed to a person by EITHER
+    // customer_id (a signed-in subscriber) OR the module's own
+    // stock-alert-namespace email hash (an anonymous subscriber). Both
+    // keys are matched with OR so a caller holding both covers every row;
+    // a caller resolving the subject by customer_id alone (the DSR
+    // composition root — no raw email is held anywhere to re-hash under
+    // this namespace) covers every account-linked row. The exported shape
+    // includes `email_normalised` — the subject's own address, stored
+    // plaintext by design for the notification dispatcher — and excludes
+    // the confirmation / unsubscribe token hashes (bearer credentials,
+    // not subject data).
+    exportForCustomer: async function (input) {
+      var sel = _dsrSelector(input, "exportForCustomer");
+      var w   = _dsrWhere(sel);
+      return (await query(
+        "SELECT id, email_hash, email_normalised, sku, variant_id, customer_id, " +
+        "confirmed_at, notified_at, expires_at, created_at " +
+        "FROM stock_alerts WHERE " + w.clause +
+        " ORDER BY created_at DESC, id DESC LIMIT ?" + (w.params.length + 1),
+        w.params.concat([MAX_LIST_LIMIT]),
+      )).rows;
+    },
+
+    // eraseForCustomer({ customer_id?, email_hash?, dry_run? }) — GDPR
+    // Art. 17 erasure. A stock alert is pure convenience data holding a
+    // PLAINTEXT email with no retention basis, so erasure hard-DELETEs
+    // the rows (which also frees the (email, sku, variant) unique-index
+    // slot cleanly — the person can re-subscribe later). Same dual-key
+    // selector as the export so the two never diverge on which rows
+    // belong to the subject. `dry_run: true` counts the rows a wet run
+    // WOULD delete without mutating. Returns the DSR reader contract
+    // shape `{ table, deleted }`.
+    //
+    // Residual scope, stated rather than implied: rows subscribed
+    // anonymously (customer_id NULL) are reachable only via the
+    // email_hash key — a customer_id-only call cannot match them because
+    // the system never holds the raw address to re-derive this
+    // namespace's hash. Those rows stay covered by the retention TTL
+    // (default 90 days, swept by cleanupExpired) and by the per-row
+    // bearer unsubscribe token the subscriber holds.
+    eraseForCustomer: async function (input) {
+      var dryRun = !!(input && input.dry_run);
+      var sel = _dsrSelector(input, "eraseForCustomer");
+      var w   = _dsrWhere(sel);
+      if (dryRun) {
+        var c = (await query(
+          "SELECT COUNT(*) AS n FROM stock_alerts WHERE " + w.clause,
+          w.params,
+        )).rows[0];
+        return { table: "stock_alerts", deleted: c ? Number(c.n) : 0 };
+      }
+      var r = await query("DELETE FROM stock_alerts WHERE " + w.clause, w.params);
+      return { table: "stock_alerts", deleted: Number((r && r.rowCount) || 0) };
+    },
+
     // Operator-driven sweeper. Walks every pending (confirmed +
     // un-notified + un-expired) subscription whose SKU now has
     // catalog.inventory.stock_on_hand - stock_held > 0 and:

package/lib/storefront.js

@@ -21025,11 +21025,22 @@ function mount(router, deps) {
       var body = req.body || {};
       var cartCount = 0;
       try { cartCount = await _cartCountForReq(req); } catch (_e) { /* drop-silent — empty cart fallback */ }
+      // Link the subscription to the signed-in customer when there is one,
+      // so the row joins the account's privacy export / erasure scope. A
+      // missing, stale, or revoked auth cookie reads as signed-out and the
+      // anonymous subscribe (the primary, edge-served PDP flow — this route
+      // stays in EDGE_POST_PATHS, no auth required) is unchanged.
+      var saCustomerId = null;
+      try {
+        var saEnv = _currentCustomerEnv(req);
+        if (saEnv && !(await _sessionRevoked(saEnv))) saCustomerId = saEnv.customer_id;
+      } catch (_e) { saCustomerId = null; }
       try {
         var result = await deps.stockAlerts.subscribe({
-          email:      body.email,
-          sku:        body.sku,
-          variant_id: (body.variant_id != null && body.variant_id !== "") ? body.variant_id : null,
+          email:       body.email,
+          sku:         body.sku,
+          variant_id:  (body.variant_id != null && body.variant_id !== "") ? body.variant_id : null,
+          customer_id: saCustomerId,
         });
         // Only a brand-new subscription carries a plaintext token. Send the
         // confirmation email best-effort; a mailer hiccup must not 500 the

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@blamejs/blamejs-shop",
-  "version": "0.4.29",
+  "version": "0.4.30",
   "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": {