@blamejs/blamejs-shop 0.0.121 → 0.0.123

package/CHANGELOG.md

@@ -8,6 +8,10 @@ upgrading across more than a few patches at a time.
 
 ## v0.0.x
 
+- v0.0.123 (2026-05-24) — **Wishlist — save products to your account, with social-proof counts on the product page.** Signed-in customers can now save products to a wishlist from the product page. A "N shoppers saved this" count surfaces social proof, and saved items live on a new account page where they can be removed or reopened. The save control and count render identically on the edge and container paths; the toggle is idempotent (saving twice is a no-op, toggling again removes) and login-gated, since a wishlist is scoped to one customer. **Added:** *Save to wishlist on the product page* — The PDP renders a "Save to wishlist" control and, once any customer has saved it, a "N shoppers saved this" social-proof count. Both render server-side on the edge and container paths. The count is public; the save action requires sign-in. · *`/account/wishlist` — saved items* — A new account page lists the customer's saved products with a thumbnail, a link back to the product, and a Remove control. Entries whose product was archived render as "no longer available" rather than breaking the list (wishlist rows are orphan-tolerant by design). The account dashboard links to it. · *`POST /wishlist/toggle`* — Login-required endpoint that saves the product if it isn't saved and removes it if it is. Idempotent (`INSERT OR IGNORE`). Redirects back to the product by resolving its canonical slug from the product id, or to a safe same-origin `return_to` (the account page's Remove uses it) — a forged or off-site redirect target is rejected.
+
+- v0.0.122 (2026-05-24) — **Product reviews on the storefront — verified-buyer submission, operator moderation, and rich-snippet ratings.** The product page now shows customer reviews: an average rating, a per-star distribution, and the published review list, with `AggregateRating` structured data so star ratings can surface in search results. Submission is gated to signed-in customers who have actually purchased the product — the route confirms a completed order for that product before accepting a review, and re-checks on submit. Reviews land in a pending state; operators publish or reject them through new bearer-token admin endpoints. Display and structured data are identical whether the page is served at the edge or from the container. **Added:** *Reviews on the product page* — The PDP renders an average rating, a per-star distribution bar chart, and the published reviews (newest first, verified-buyer badge, date). Products with no reviews show an invite to be the first. Rendered server-side on both the edge and container paths. · *Verified-buyer review submission* — `GET /products/:slug/review` shows the review form to a signed-in customer who has purchased the product; everyone else is redirected to sign in or told only verified buyers can review. `POST /products/:slug/review` re-checks the purchase before accepting the review, so a direct POST can't bypass the gate. Submitted reviews start pending. · *Operator review moderation* — `GET /admin/reviews?status=pending` lists the moderation queue across all products; `GET /admin/reviews/:id` reads one; `POST /admin/reviews/:id/publish` and `POST /admin/reviews/:id/reject` move it. Bearer-token-gated like the rest of the admin API. Pending and rejected reviews never appear on the storefront. · *`AggregateRating` structured data* — The product page emits Schema.org `AggregateRating` (rating value + review count) nested in the existing `Product` JSON-LD when published reviews exist, so eligible products can show star ratings in search results. Omitted entirely at zero reviews to stay valid. The container render path now emits the full `Product` + `AggregateOffer` + `BreadcrumbList` JSON-LD that the edge already did. · *`order.hasPurchasedProduct(customerId, productId)`* — Existence check — true when the customer has an order line for any variant of the product in an order that reached `paid` or later (excludes `pending` and `cancelled`). Backs the review purchase gate. · *`reviews.listByStatus(status, opts)`* — Lists reviews across all products by status, newest first, with the same opaque tuple cursor as `listForProduct`. Backs the admin moderation queue.
+
 - v0.0.121 (2026-05-24) — **Codebase-patterns detector blocks SHA3 primitives in `worker/` — prevents the regression that broke newsletter signup.** v0.0.120 fixed the newsletter signup by routing the POST to the container instead of computing `b.crypto.namespaceHash` (SHA3-512) at the edge — Workers' `nodejs_compat` doesn't expose SHA3-family digests. New `worker-uses-sha3-primitive` codebase-patterns detector flags any `b.crypto.{sha3Hash, hmacSha3, namespaceHash, shake256, shake512, hkdfSha3}(...)` call under `worker/` so the next operator can't re-introduce the substrate-mismatch bug. Catalog grows 121 → 122. Detector targets the exact SHA3-family primitive names rather than a general regex match — Worker code that legitimately uses `b.crypto.toBase64Url`, `b.crypto.timingSafeEqual`, `b.crypto.generateBytes`, `b.crypto.hmacSha256` (the Stripe webhook augment), etc. is unaffected. **Added:** *`worker-uses-sha3-primitive` detector* — Flags `b.crypto.sha3Hash(...)`, `hmacSha3(...)`, `namespaceHash(...)`, `shake256(...)`, `shake512(...)`, and `hkdfSha3(...)` in any file under `worker/`. Catches the substrate-mismatch class that broke v0.0.92's edge newsletter handler (live for 28 versions before being routed back to the container in v0.0.120). When edge code needs a stable hash: route to the container OR use `b.crypto.hmacSha256` IFF both sides read with the same SHA-256 path. Never have one substrate write SHA3 and another read SHA-256 — silent divergence breaks cross-substrate lookups (e.g. unsubscribe-by-email_hash).
 
 - v0.0.120 (2026-05-24) — **Route POST /newsletter through the container — Workers `nodejs_compat` can't compute SHA3-512 (`b.crypto.namespaceHash`).** The v0.0.92 edge-served newsletter handler was 500-ing every submission with `Error: Digest method not supported`. Root cause surfaced via the temporary `X-Newsletter-Diag` header (added in v0.0.119): Cloudflare Workers' `nodejs_compat` runtime exposes `node:crypto` but the supported digest set is a subset of full Node — `createHash("sha3-512")` isn't in it. Working around with a Web-Crypto-API SHA-256 fallback would silently diverge the Worker's `email_hash` values from the container's SHA3-512 values, breaking the unsubscribe lookup (different hash → different row → silent unsubscribe failure). The edge handler was the wrong substrate for this primitive. The POST falls through to `_forwardToContainer` so the framework's SHA3-512 path runs server-side and the `email_hash` column stays consistent across reads. The ~200ms container hop on signup submit is paid back by a working unsubscribe flow. The dead `_edgeNewsletter` function + its `renderNewsletterThanks` / `renderNewsletterError` imports + the diagnostic `X-Newsletter-Diag` header are all removed in the same patch. **Fixed:** *Newsletter signup now uses the framework's SHA3-512 hash via the container* — Removed: `_edgeNewsletter` handler (123 lines), `renderNewsletterThanks` / `renderNewsletterError` imports in `worker/index.js`, the `X-Newsletter-Diag` diagnostic response header (its job is done). The dispatch comment above the now-removed `if (pathname === "/newsletter" && ...)` block documents the substrate decision + the SHA3-512 / Workers-runtime constraint so the next operator doesn't re-introduce the edge handler.

package/README.md

@@ -63,9 +63,11 @@ Every primitive is composed on the vendored blamejs surface — no npm runtime d
 | **`lib/email.js`** | Transactional templates — order receipt, ship notification, refund confirmation. 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, 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 — 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. |
 | **`lib/customers.js`** | Customer accounts — passkey-only (WebAuthn). Email is stored hash-only (`b.crypto.namespaceHash` namespace `customer-email`); the raw address never lands in D1. Passkey credentials carry CBOR-encoded public keys, transport hints, and SHA3-512-fingerprinted attestation. Account routes (`/account/login`, `/account/register`, `/account`) ship as designed cards on the storefront. |
+| **`lib/reviews.js`** | Operator-moderated product ratings. Submission requires a signed-in customer **and** a verified purchase — `/products/:slug/review` confirms a completed order for the product (via `order.hasPurchasedProduct`) before accepting, re-checked on POST; reviews land `pending`. Author identity is hash-only (`b.crypto.namespaceHash`); the raw email is never stored. The PDP renders the average, per-star distribution, and published reviews with `AggregateRating` JSON-LD. `/admin/reviews` is the moderation queue (`listByStatus` → publish / reject). |
+| **`lib/wishlist.js`** | Per-customer saved products. The PDP renders a login-gated "Save to wishlist" toggle and a "N shoppers saved this" social-proof count; `/account/wishlist` lists saved items (remove + reopen, orphan-tolerant when a product is archived). `POST /wishlist/toggle` is idempotent (`INSERT OR IGNORE`) and redirects to the canonical product slug or a safe same-origin `return_to`. UUID-shape-validated ids, `b.pagination` HMAC cursors. |
 | **`lib/subscriptions.js`** | Stripe-backed recurring billing — `subscription_plans` (interval / amount / trial) + `subscriptions` (mirrors Stripe's object byte-for-byte). `subscriptions.create` POSTs to Stripe via the payment dep, then persists the returned object locally. `handleStripeEvent` replays `customer.subscription.*` events into the local row so the shop has an authoritative view without round-tripping. |
 | **`lib/newsletter.js`** | Operator-collected email broadcast list — `signup({ email, source })` composes `b.guardEmail` for shape validation, `b.crypto.namespaceHash` for the dedup key, and `INSERT OR IGNORE` for idempotency. Storefront POST `/newsletter` route renders a designed thank-you card with separate copy for the `new` vs `dedup` branches. |
-| **`lib/admin.js`** | Bearer-token-gated CRUD over catalog + orders + refunds + bulk CSV import + subscription plans. Token compared via `b.crypto.timingSafeEqual`. Errors as RFC 9457 problem documents via `b.problemDetails`. Audit emission on every mutation. |
+| **`lib/admin.js`** | Bearer-token-gated CRUD over catalog + orders + refunds + bulk CSV import + subscription plans + review moderation. Token compared via `b.crypto.timingSafeEqual`. Errors as RFC 9457 problem documents via `b.problemDetails`. Audit emission on every mutation. |
 | **`lib/catalog-import.js`** | Bulk CSV import — `POST /admin/catalog/import` accepts a `text/csv` body, parses via `b.csv`, content-safety-filters every cell through `b.guardCsv` (formula-injection / bidi / control / dangerous-function denylist), validates exact header order, de-dupes rows by `product_slug`, returns per-row errors without aborting. Default 1 MiB / 10000 rows caps. |
 | **`lib/theme.js`** | File-backed templates with fallback chain. Operators register a named theme under `<themesDir>/<name>/*.html` and the storefront dispatches every renderer through it. `assetUrl(path)` resolves to `/assets/themes/<name>/<path>`. The shipped `default` theme is the fallback. |
 
@@ -80,6 +82,8 @@ Every primitive is composed on the vendored blamejs surface — no npm runtime d
 - `migrations-d1/0008_inventory_thresholds.sql` — low-stock alert thresholds + alerts
 - `migrations-d1/0009_subscriptions.sql` — subscription_plans + subscriptions (Stripe-mirrored)
 - `migrations-d1/0010_newsletter_signups.sql` — email signups with hash-based dedup
+- `migrations-d1/0011_reviews.sql` — operator-moderated product reviews (hash-only author identity)
+- `migrations-d1/0012_wishlist.sql` — per-customer saved products (unique customer + product + variant)
 
 ### Demo seed
 

package/SECURITY.md

@@ -92,8 +92,8 @@ node -e "
 
 | Purpose                           | Algorithm  | Fingerprint               |
 |-----------------------------------|------------|---------------------------|
-| Maintainer commit/tag signing key | SSH-ED25519 | *(populate on first signed tag — see below)* |
-| Release-signing public key        | ML-DSA-65 (FIPS 204) | `0d9d241e23c333201911afd6d6d0b0ba9a2feb4f60bf5fdd976bb33e0678f7ff0ec3db816c3cb2d9caf50c681caf8b04939ffe8cf4652eae9e6c90c988bfb87e` (SHA3-512 of `keys/release-pqc-pub.json#publicKey`) |
+| Maintainer commit/tag signing key | SSH-ED25519 | `SHA256:5oF/XWhFpMde9TRfEX2GAHiApAq/MXOS4vti5zQbD7g` (cross-check against `https://github.com/<maintainer>.keys` — see below) |
+| Release-signing public key        | ML-DSA-65 (FIPS 204) | `d40e1e2b06a2509271cc3cf76bd34c63d2fbb093f42e1e1f6b349288900ec044509ca183b3d735cda003d80eb6cf5d80fd9181ad897889e1c1f701d61b7902c9` (SHA3-512 of `keys/release-pqc-pub.json#publicKey`) |
 
 To populate the maintainer SSH fingerprint:
 ```
@@ -139,3 +139,12 @@ node -e "
   framework's at-rest key material. Operators MUST rotate the
   passphrase via `b.vault.rotate` after any container image rebuild
   that changed a vendored crypto dependency.
+- **Reviews are purchase-gated and operator-moderated.** A review can
+  only be submitted by a signed-in customer who has a completed order
+  for that product; the route confirms the purchase before accepting
+  and re-checks it on the POST, so a direct request can't plant a
+  review for a product the account never bought. Submissions land in a
+  `pending` state and never reach the storefront until an operator
+  publishes them through `/admin/reviews`. The author identity is
+  stored hash-only (`b.crypto.namespaceHash`) — the raw email is never
+  persisted.

package/lib/admin.js

@@ -162,6 +162,7 @@ function mount(router, deps) {
   var r2            = deps.r2_bridge     || null;   // media-upload endpoint disabled when absent
   var assetPrefix   = typeof deps.asset_prefix === "string" ? deps.asset_prefix : "/assets/";
   var catalogImport = deps.catalogImport || null;   // bulk-import route disabled when absent
+  var reviews       = deps.reviews       || null;   // moderation endpoints disabled when absent
 
   try { _b().audit.registerNamespace(AUDIT_NAMESPACE); } catch (_e) { /* idempotent */ }
 
@@ -529,6 +530,56 @@ function mount(router, deps) {
     }));
   }
 
+  // ---- reviews (moderation) -------------------------------------------
+
+  // Operator-side review moderation. The queue lists reviews across all
+  // products in one status (defaults to `pending`); publish / reject
+  // drive the same transitions the storefront submit path leaves in
+  // `pending`. Endpoints are omitted entirely when no reviews primitive
+  // is wired.
+  if (reviews) {
+    router.get("/admin/reviews", R(async function (req, res) {
+      var url = req.url ? new URL(req.url, "http://localhost") : null;
+      var status = (url && url.searchParams.get("status")) || "pending";
+      var cursor = url && url.searchParams.get("cursor");
+      var limitS = url && url.searchParams.get("limit");
+      var limit  = limitS == null ? undefined : parseInt(limitS, 10);
+      var page = await reviews.listByStatus(status, { cursor: cursor || undefined, limit: limit });
+      _json(res, 200, page);
+    }));
+
+    router.get("/admin/reviews/:id", R(async function (req, res) {
+      var rev = await reviews.get(req.params.id);
+      if (!rev) return _problem(res, 404, "review-not-found");
+      _json(res, 200, rev);
+    }));
+
+    router.post("/admin/reviews/:id/publish", W("review.publish", async function (req, res) {
+      var rev;
+      try {
+        rev = await reviews.publish(req.params.id);
+      } catch (e) {
+        if (e && e.code === "REVIEW_NOT_FOUND") return _problem(res, 404, "review-not-found");
+        throw e;
+      }
+      _json(res, 200, rev);
+      return rev;
+    }));
+
+    router.post("/admin/reviews/:id/reject", W("review.reject", async function (req, res) {
+      var body = req.body || {};
+      var rev;
+      try {
+        rev = await reviews.reject(req.params.id, body.reason);
+      } catch (e) {
+        if (e && e.code === "REVIEW_NOT_FOUND") return _problem(res, 404, "review-not-found");
+        throw e;
+      }
+      _json(res, 200, rev);
+      return rev;
+    }));
+  }
+
   // ---- config ---------------------------------------------------------
 
   var config = deps.config || null;

package/lib/order.js

@@ -368,6 +368,29 @@ function create(opts) {
       if (r.rowCount === 0) return null;
       return await this.get(orderId);
     },
+
+    // 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
+    // pending (never captured) or cancelled (reversed before
+    // fulfillment). paid|fulfilling|shipped|delivered|refunded all
+    // count as purchased. The review gate composes this so only
+    // verified buyers can leave a review. Existence check, one round
+    // trip.
+    hasPurchasedProduct: async function (customerId, productId) {
+      _uuid(customerId, "customer id");
+      _uuid(productId, "product id");
+      var rows = (await query(
+        "SELECT 1 FROM order_lines ol " +
+        "JOIN orders o   ON o.id = ol.order_id " +
+        "JOIN variants v ON v.id = ol.variant_id " +
+        "WHERE o.customer_id = ?1 AND v.product_id = ?2 " +
+        "AND o.status NOT IN ('pending','cancelled') " +
+        "LIMIT 1",
+        [customerId, productId],
+      )).rows;
+      return rows.length > 0;
+    },
   };
 }
 

package/lib/reviews.js

@@ -349,6 +349,35 @@ function create(opts) {
       return { rows: r.rows, next_cursor: _encodeNext(r.rows, REVIEW_ORDER_KEY, limit) };
     },
 
+    // Cross-product moderation listing — every review in one status
+    // regardless of product. The moderation queue needs all `pending`
+    // rows globally, which listForProduct (per-product) can't serve.
+    // status is required here (the queue is always status-scoped). Same
+    // (created_at DESC, id DESC) tuple cursor as listForProduct.
+    listByStatus: async function (status, listOpts) {
+      status = _statusFilter(status);
+      if (status === undefined) {
+        throw new TypeError("reviews.listByStatus: status is required (one of " + ALLOWED_STATUSES.join(", ") + ")");
+      }
+      listOpts = listOpts || {};
+      var limit  = _limit(listOpts.limit);
+      var cursorVals = _decodeCursor(listOpts.cursor, REVIEW_ORDER_KEY, "listByStatus");
+
+      var sql, params;
+      if (cursorVals) {
+        sql = "SELECT * FROM reviews WHERE status = ?1 " +
+              "AND (created_at < ?2 OR (created_at = ?2 AND id < ?3)) " +
+              "ORDER BY created_at DESC, id DESC LIMIT ?4";
+        params = [status, cursorVals[0], cursorVals[1], limit];
+      } else {
+        sql = "SELECT * FROM reviews WHERE status = ?1 " +
+              "ORDER BY created_at DESC, id DESC LIMIT ?2";
+        params = [status, limit];
+      }
+      var r = await query(sql, params);
+      return { rows: r.rows, next_cursor: _encodeNext(r.rows, REVIEW_ORDER_KEY, limit) };
+    },
+
     // Aggregate ratings — published-only by construction; counts
     // every star bucket so the storefront can draw the distribution
     // bar chart without a second query.