@blamejs/blamejs-shop 0.4.21 → 0.4.22

package/CHANGELOG.md

@@ -8,6 +8,8 @@ upgrading across more than a few patches at a time.
 
 ## v0.4.x
 
+- 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/asset-manifest.json

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

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/order-export.js

@@ -212,7 +212,8 @@ function _limit(n) {
 // RFC-4180 quoting: every cell wrapped in `"`, embedded `"` doubled.
 // We quote unconditionally — the cost is a few extra bytes per cell;
 // the win is that a downstream parser never has to track quote-vs-
-// bare-cell state for a column with mixed shapes.
+// bare-cell state for a column with mixed shapes. The injection
+// neutralization runs first via the shared vendored primitive.
 function _csvCell(value) {
   var s = _coerceCell(value);
   s = _neutralizeInjection(s);
@@ -227,23 +228,19 @@ function _coerceCell(value) {
   return JSON.stringify(value);
 }
 
-// Numeric-with-sign detector — `+15.00` / `-3.50` / `+0` parse as
-// legitimate amounts and should pass through unmolested. The
-// detector rejects anything with embedded whitespace or trailing
-// non-numeric tail so `+15 SUM(A1)` still gets escaped.
-var _NUMERIC_SIGN_RE = /^[+-](?:\d+(?:\.\d+)?|\.\d+)$/;
-
-// CSV injection neutralization — see OWASP "CSV Injection". A cell
-// beginning with `=`, `+`, `-`, or `@` is interpreted as a formula
-// by most spreadsheet renderers. The defense is to prefix with `'`
-// so the renderer treats the cell as literal text. Signed numerics
-// are the deliberate exception (legitimate amount strings).
+// CSV injection neutralization — composes the vendored b.guardCsv.escapeCell
+// (OWASP "CSV Injection" defense). The vendored primitive is the single
+// shared neutralizer across every CSV export surface (order-export +
+// customer-segments). It prefixes a leading TAB when a cell starts with ANY
+// formula-trigger char — `= + - @` AND the tab / CR / LF / pipe / full-width
+// variants a hand-rolled `= + - @`-only check misses. A leading tab renders
+// as invisible whitespace in a spreadsheet, so the cell reads as text and
+// never evaluates as a formula. The earlier in-tree check exempted signed
+// numerics (`+15.00`); the shared primitive prefixes those too (the safe
+// OWASP posture — `-2+3+cmd|…` is a real injection that begins like an
+// amount), which is the more complete behavior this consolidation buys.
 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 _csvRow(cells) {

package/lib/security-middleware.js

@@ -58,11 +58,19 @@ var _vendoredSecurityHeaders = require("./vendor/blamejs/lib/middleware/security
 
 var C = b.constants;
 
-// Payment webhooks are server-to-server POSTs from Stripe / PayPal:
-// cross-site by nature, unthrottleable by a per-IP human budget, and
-// already authenticated by an HMAC signature the edge + container both
-// verify. They are exempt from BOTH the rate limiters and fetch-metadata.
-var WEBHOOK_PATHS = ["/api/webhooks/stripe", "/api/webhooks/paypal"];
+// Server-to-server webhooks: cross-site by nature, unthrottleable by a
+// per-IP human budget, and each authenticated by its own gate the handler
+// verifies first thing — an HMAC signature (Stripe / PayPal) or a per-
+// endpoint signing secret (the ESP bounce / complaint intake). They are
+// exempt from the rate limiters, fetch-metadata, and the double-submit CSRF
+// token (a third-party POST carries no session cookie or token). The
+// `/api/` prefix also lands them in the vendored bot-guard's onlyForHtml
+// skip, so the secret / signature gate is the deciding check.
+var WEBHOOK_PATHS = [
+  "/api/webhooks/stripe",
+  "/api/webhooks/paypal",
+  "/api/webhooks/mail-bounce",
+];
 
 // Liveness / readiness probe — the container's Docker HEALTHCHECK hits
 // this on a fixed cadence; never rate-limit it or a slow cold start

package/lib/storefront.js

@@ -19993,7 +19993,22 @@ function mount(router, deps) {
 
     router.post("/unsubscribe", async function (req, res) {
       var body = req.body || {};
-      var token = typeof body.token === "string" ? body.token : "";
+      // RFC 8058 one-click: the mail client POSTs to the EXACT URL in the
+      // List-Unsubscribe header — token in the `?token=` query string —
+      // with a `List-Unsubscribe=One-Click` form body and NOTHING else
+      // (no token of its own). So the URL token is authoritative; the
+      // body `token` is only the fallback the on-page confirm form POSTs
+      // from its hidden field. Reading body.token alone (the prior shape)
+      // meant a native one-click POST carried no token -> "not-found" ->
+      // the recipient was never unsubscribed. Parse the token off req.url
+      // (the router only populates req.query when a route declares a query
+      // validator), then fall back to the confirm-form body field.
+      var urlToken = "";
+      try {
+        var u = req.url ? new URL(req.url, "http://localhost") : null;
+        if (u) urlToken = u.searchParams.get("token") || "";
+      } catch (_eUrl) { urlToken = ""; }
+      var token = urlToken || (typeof body.token === "string" ? body.token : "");
       var cartCount = 0;
       try { cartCount = await _cartCountForReq(req); } catch (_e) { /* drop-silent — empty cart fallback */ }
       var outcome;
@@ -20001,6 +20016,9 @@ function mount(router, deps) {
         // `consumeUnsubscribeToken` returns a structured result (it does
         // not throw on a bad/missing token — it returns `{ ok:false,
         // error:"not-found" }`). An empty token is handled the same way.
+        // It is single-use, so the one-click POST and a later confirm-form
+        // POST of the same token are idempotent (the second reads
+        // "already" — still a success page, no error).
         var result = await deps.newsletter.consumeUnsubscribeToken(token);
         outcome = _unsubscribeOutcome(result);
       } catch (e) {

package/lib/support-tickets.js

@@ -435,11 +435,18 @@ function create(opts) {
       return await _refresh(id);
     },
 
-    // Append a message to the ticket thread. Operator replies flip
-    // `new -> in_progress` and stamp `first_response_at` if unset.
-    // Operator replies also bump `last_action_at`; customer replies
-    // do NOT advance the SLA clock (the clock measures operator
-    // responsiveness, not customer chatter).
+    // Append a message to the ticket thread.
+    //   * A CUSTOMER-VISIBLE operator reply (internal=false) flips
+    //     `new -> in_progress`, stamps `first_response_at` if unset, and
+    //     bumps `last_action_at`. An INTERNAL operator note (internal=true)
+    //     is operator-to-operator: append-only, no status flip, no
+    //     first-response stamp (the customer never sees it, so it can't
+    //     satisfy the response SLA).
+    //   * A customer reply doesn't advance `last_action_at` on the
+    //     operator's-clock states, but DOES requeue the ticket: a reply to
+    //     `waiting_customer` returns it to `in_progress`, and a reply to a
+    //     `resolved` ticket reopens it (`resolved -> reopened`, with a
+    //     fresh SLA clock) so the operator's pushback never goes unseen.
     reply: async function (input) {
       if (!input || typeof input !== "object") {
         throw new TypeError("supportTickets.reply: input object required");
@@ -479,30 +486,57 @@ function create(opts) {
       );
 
       if (author === "operator") {
-        // Operator reply flips `new -> in_progress` automatically.
-        // Other states keep their status; SLA timer + first-response
-        // stamp still advance.
-        var newStatus = ticket.status;
-        if (ticket.status === "new") {
-          newStatus = "in_progress";
-          await _writeStatusHistory(ticketId, ticket.status, newStatus, "operator-reply", ts);
+        // Only a CUSTOMER-VISIBLE operator reply counts as a first
+        // response or advances the workflow. An INTERNAL note (internal=1)
+        // is operator-to-operator — the customer never sees it, so
+        // stamping first_response_at off it would satisfy the SLA with
+        // content that never reached the person waiting. An internal note
+        // is append-only here: no status flip, no first_response_at, no
+        // last_action_at bump (it isn't operator responsiveness TO the
+        // customer). The message row was already inserted above.
+        if (!internal) {
+          // A customer-visible operator reply flips `new -> in_progress`
+          // automatically; other states keep their status. The
+          // first-response stamp + SLA timer advance only on this path.
+          var newStatus = ticket.status;
+          if (ticket.status === "new") {
+            newStatus = "in_progress";
+            await _writeStatusHistory(ticketId, ticket.status, newStatus, "operator-reply", ts);
+          }
+          var firstResp = ticket.first_response_at == null ? ts : ticket.first_response_at;
+          await query(
+            "UPDATE support_tickets SET status = ?1, first_response_at = ?2, last_action_at = ?3 WHERE id = ?4",
+            [newStatus, firstResp, ts, ticketId],
+          );
         }
-        var firstResp = ticket.first_response_at == null ? ts : ticket.first_response_at;
-        await query(
-          "UPDATE support_tickets SET status = ?1, first_response_at = ?2, last_action_at = ?3 WHERE id = ?4",
-          [newStatus, firstResp, ts, ticketId],
-        );
       } else if (author === "customer") {
-        // Customer replies don't advance last_action_at — that
-        // would mask SLA breach. They DO move the ticket out of
-        // `waiting_customer` back into `in_progress` because the
-        // operator now owes the next move.
+        // Customer replies don't advance last_action_at on the
+        // operator's-clock states — that would mask an SLA breach. They DO
+        // move the ticket back into a queue the operator owes the next
+        // move on:
+        //   * waiting_customer -> in_progress (the customer answered)
+        //   * resolved        -> reopened     (the customer pushed back; an
+        //                                       FSM-legal edge, resolved ->
+        //                                       reopened). Without this, a
+        //                                       reply to a resolved ticket
+        //                                       was silently dropped from
+        //                                       every operator queue.
+        // last_action_at bumps ONLY on the resolved->reopened move so the
+        // reopened ticket surfaces with a fresh SLA clock (the operator now
+        // owes a response); the waiting_customer->in_progress move keeps the
+        // existing clock (the operator's responsiveness window never paused).
         if (ticket.status === "waiting_customer") {
           await _writeStatusHistory(ticketId, ticket.status, "in_progress", "customer-reply", ts);
           await query(
             "UPDATE support_tickets SET status = 'in_progress' WHERE id = ?1",
             [ticketId],
           );
+        } else if (ticket.status === "resolved") {
+          await _writeStatusHistory(ticketId, ticket.status, "reopened", "customer-reply", ts);
+          await query(
+            "UPDATE support_tickets SET status = 'reopened', last_action_at = ?1 WHERE id = ?2",
+            [ts, ticketId],
+          );
         }
       }
       // system author: append-only; no state mutation.
@@ -596,56 +630,82 @@ function create(opts) {
       return await _refresh(ticketId);
     },
 
+    // Add a tag. The mutation is a SINGLE atomic JSON1 statement —
+    // `json_insert(..., '$[#]', ?)` appends only when the tag isn't
+    // already present (the json_each NOT-EXISTS guard) AND the ticket is
+    // under the cap (json_array_length guard). A prior read-modify-write
+    // (decode -> push in JS -> write the whole array back) lost one of two
+    // concurrent addTag writes: both read the same array, both appended
+    // their own tag, the last write clobbered the other. Doing the append
+    // inside SQLite removes the read-then-write window entirely. The read
+    // that remains exists ONLY to classify a zero-row update (idempotent
+    // dup vs cap-exceeded error) — it never feeds the write.
     addTag: async function (input) {
       if (!input || typeof input !== "object") {
         throw new TypeError("supportTickets.addTag: input object required");
       }
       var ticketId = _uuid(input.ticket_id, "ticket_id");
       var tag      = _singleTag(input.tag);
-      var ticket = await _getRaw(ticketId);
-      if (!ticket) {
-        var err = new Error("supportTickets.addTag: ticket " + ticketId + " not found");
-        err.code = "SUPPORT_TICKET_NOT_FOUND";
-        throw err;
-      }
-      var tags;
-      try { tags = JSON.parse(ticket.tags_json || "[]"); }
-      catch (_e) { tags = []; }
-      if (tags.indexOf(tag) === -1) {
-        if (tags.length >= MAX_TAG_COUNT) {
+      var res = await query(
+        "UPDATE support_tickets " +
+        "SET tags_json = json_insert(COALESCE(tags_json, '[]'), '$[#]', ?1) " +
+        "WHERE id = ?2 " +
+        "  AND (SELECT COUNT(*) FROM json_each(COALESCE(tags_json, '[]')) WHERE value = ?1) = 0 " +
+        "  AND json_array_length(COALESCE(tags_json, '[]')) < ?3",
+        [tag, ticketId, MAX_TAG_COUNT],
+      );
+      if (Number((res && res.rowCount) || 0) === 0) {
+        // The atomic UPDATE matched no row. Read once to classify: a
+        // missing ticket is a hard error; an already-present tag is an
+        // idempotent no-op; otherwise the ticket is at the tag cap.
+        var ticket = await _getRaw(ticketId);
+        if (!ticket) {
+          var err = new Error("supportTickets.addTag: ticket " + ticketId + " not found");
+          err.code = "SUPPORT_TICKET_NOT_FOUND";
+          throw err;
+        }
+        var tags;
+        try { tags = JSON.parse(ticket.tags_json || "[]"); }
+        catch (_e) { tags = []; }
+        if (tags.indexOf(tag) === -1 && tags.length >= MAX_TAG_COUNT) {
           throw new TypeError("supportTickets.addTag: ticket already has " + MAX_TAG_COUNT + " tags");
         }
-        tags.push(tag);
-        await query(
-          "UPDATE support_tickets SET tags_json = ?1 WHERE id = ?2",
-          [JSON.stringify(tags), ticketId],
-        );
+        // else: tag already present — idempotent success, nothing to do.
       }
       return await _refresh(ticketId);
     },
 
+    // Remove a tag. Single atomic JSON1 statement — rebuild the array
+    // from `json_each` minus the target value. Same lost-update hazard as
+    // addTag if done read-modify-write; doing it in SQLite removes the
+    // window. Idempotent: a tag that isn't present matches no row in the
+    // EXISTS guard and the update is a no-op. A missing ticket is read
+    // back only to raise the not-found error (the update wrote nothing).
     removeTag: async function (input) {
       if (!input || typeof input !== "object") {
         throw new TypeError("supportTickets.removeTag: input object required");
       }
       var ticketId = _uuid(input.ticket_id, "ticket_id");
       var tag      = _singleTag(input.tag);
-      var ticket = await _getRaw(ticketId);
-      if (!ticket) {
-        var err = new Error("supportTickets.removeTag: ticket " + ticketId + " not found");
-        err.code = "SUPPORT_TICKET_NOT_FOUND";
-        throw err;
-      }
-      var tags;
-      try { tags = JSON.parse(ticket.tags_json || "[]"); }
-      catch (_e) { tags = []; }
-      var idx = tags.indexOf(tag);
-      if (idx !== -1) {
-        tags.splice(idx, 1);
-        await query(
-          "UPDATE support_tickets SET tags_json = ?1 WHERE id = ?2",
-          [JSON.stringify(tags), ticketId],
-        );
+      var res = await query(
+        "UPDATE support_tickets " +
+        "SET tags_json = (" +
+        "  SELECT COALESCE(json_group_array(value), '[]') " +
+        "  FROM json_each(COALESCE(tags_json, '[]')) WHERE value <> ?1" +
+        ") " +
+        "WHERE id = ?2 " +
+        "  AND EXISTS (SELECT 1 FROM json_each(COALESCE(tags_json, '[]')) WHERE value = ?1)",
+        [tag, ticketId],
+      );
+      if (Number((res && res.rowCount) || 0) === 0) {
+        // No row changed — either the ticket is missing (hard error) or
+        // the tag simply wasn't present (idempotent no-op).
+        var ticket = await _getRaw(ticketId);
+        if (!ticket) {
+          var err = new Error("supportTickets.removeTag: ticket " + ticketId + " not found");
+          err.code = "SUPPORT_TICKET_NOT_FOUND";
+          throw err;
+        }
       }
       return await _refresh(ticketId);
     },

package/package.json

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