@blamejs/blamejs-shop 0.4.99 → 0.4.101

package/CHANGELOG.md

@@ -8,6 +8,10 @@ upgrading across more than a few patches at a time.
 
 ## v0.4.x
 
+- v0.4.101 (2026-06-25) — **Bulk cart operations now use the same per-line quantity ceiling as a normal add-to-cart, so a large line is no longer un-bulk-addable or silently reduced.** The cart enforces a per-line quantity ceiling on every add-to-cart. The bulk-operations surface (bulk add and reorder) carried its own copy of that ceiling that had drifted ten times lower than the cart's. The mismatch meant a line legitimately built up to the cart's ceiling through normal add-to-cart could not be added to in bulk (the whole bulk batch was rejected), and a reorder of such a line silently clamped its quantity down instead of preserving it. Bulk operations now source the ceiling directly from the cart primitive, so the two always agree: the same quantity that add-to-cart accepts is accepted in bulk, and a reorder no longer quietly reduces a line. No configuration changes. **Fixed:** *Bulk add and reorder share the cart's per-line quantity ceiling* — Bulk cart operations validated and clamped line quantities against their own ceiling, which was ten times lower than the one the cart applies on a normal add-to-cart. As a result a line whose quantity was legitimately built up to the cart's ceiling could not be bulk-added to — the entire batch was refused — and a reorder of that line silently clamped its quantity down rather than keeping it. The bulk surface now reads the ceiling from the cart primitive itself, so bulk add accepts exactly what add-to-cart accepts and a reorder preserves a line's quantity instead of reducing it.
+
+- v0.4.100 (2026-06-25) — **A coupon-stacking policy is now enforced at checkout, so two code-gated discounts can no longer combine past a policy that forbids it.** The coupon-stacking policy surface decides which discount codes may combine on one order — whether codes stack at all, a per-order code cap, and codes that are exclusive of everything else. That policy was applied in the admin surface but never on the buy path: checkout summed every code-gated rule a shopper had unlocked, so an operator who authored a policy forbidding combination still had it ignored on the charged price, and a customer could stack two codes the policy said could not combine. Checkout now consults the stacking policy before the discount engine sums anything: when an active policy governs the cart, the presented codes are narrowed to the policy-approved subset (honoring the non-combinable, over-cap, and exclusive-code rules) and only that subset unlocks discounts. Governance is opt-in — with no active policy the presented codes pass through exactly as before, so carts that never used stacking policies are unaffected. Operators who offer multiple combinable codes and want them to keep stacking should define a policy with allow_combine.with_other_codes enabled. **Fixed:** *Code-gated discounts now honor the coupon-stacking policy at checkout* — Checkout resolved automatic discounts by summing every rule a shopper's presented codes unlocked, with no consultation of the coupon-stacking policy — so a policy that forbade combining codes, capped the number of codes per order, or marked a code exclusive was enforced only in the admin surface, never on the price the customer was actually charged. Checkout now evaluates the stacking policy first: when an active policy governs the cart, the presented codes are reduced to the policy-approved subset before any discount is computed, so non-combinable, over-cap, and exclusive-code rules hold on the charged total. When no stacking policy is active the codes are left untouched, so existing carts that don't use stacking policies see no change; to keep multiple codes combining, define a policy with allow_combine.with_other_codes enabled.
+
 - v0.4.99 (2026-06-25) — **A subscription whose dunning retries are exhausted is now actually cancelled, instead of being marked cancelled while it keeps billing.** Dunning walks a failed-payment enrollment through its retry schedule and, when the attempt cap is reached, is documented to auto-cancel the subscription. Only an explicit cancel_subscription step in the schedule actually composed the subscription-side cancel, though: when the cap fired on the final retry/reminder step instead — the common case for a schedule that simply runs out of attempts — the enrollment was flipped to 'cancelled' but the subscription cancel was never propagated, so the recurring charge kept firing against a customer the policy had given up on. The attempt-cap close now composes the same subscription cancel an explicit cancel step does, and records it as its own audit event with its real outcome (a failed cancel is visible, not masked). A separate audit-integrity fix removes a hardcoded 'cancelled the subscription' event that the schedule-exhaustion branch wrote unconditionally, including when no cancel was attempted. No configuration changes; operators running dunning policies that rely on the attempt cap (rather than an explicit cancel step) should upgrade. **Fixed:** *Reaching the dunning attempt cap now cancels the subscription, not just the enrollment row* — When a dunning enrollment reached cancel_after_attempts on a retry or reminder step, the enrollment was closed as 'cancelled' but the subscription-side cancellation was composed only for an explicit cancel_subscription step — so a policy that relied on the attempt cap to give up left the underlying subscription active and continuing to bill. The attempt-cap close now composes the subscription cancel that the documented 'tried everything' exit always promised, resolving the invoice's subscription and signaling its cancellation exactly as an explicit cancel step does. The cancel is recorded as its own entry in the dunning audit log with the actual outcome, so a cancel that fails downstream is surfaced for follow-up rather than reported as success. · *The dunning audit log no longer records a cancellation that did not happen* — The schedule-exhaustion path wrote a fixed 'cancel_subscription / ok' audit entry regardless of how the enrollment actually closed — so an enrollment that ended without a cancellation still showed a successful cancel in the history an operator replays on the customer's timeline. The terminal audit entry now reflects what actually happened: a real cancel with its real outcome when the subscription is cancelled, and a plain schedule-exhausted record when it is not.
 
 - v0.4.98 (2026-06-25) — **A concurrent vendor registration with the same slug now returns a typed duplicate error instead of leaking a raw database error.** Registering a vendor checks whether the slug is already taken before inserting, then inserts. Two registrations of the same slug racing each other can both pass that pre-check, so the second insert collides on the slug primary key. That insert had no failure handling, so the raw database error surfaced — and in production, where the data layer redacts it to a generic 'HTTP 500', the caller got an opaque error rather than the typed 'slug already registered' it gets from the pre-check. The insert is now wrapped: on any failure it re-reads by slug, and if a row exists it raises the same typed duplicate error the pre-check raises, otherwise it re-throws. No configuration changes. **Fixed:** *Racing vendor registrations surface a typed duplicate error, not a raw 500* — vendors.registerVendor pre-checks the slug and then inserts, but a concurrent registration of the same slug can slip past the pre-check and collide on the slug primary key. The insert is now wrapped to detect that state-agnostically — re-reading by slug after a failure and raising the same typed VENDOR_SLUG_TAKEN error the pre-check raises (rather than leaking the raw constraint error, which production redacts to a bare 500). Mirrors the assignSku duplicate handling.

package/lib/asset-manifest.json

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

package/lib/cart-bulk-ops.js

@@ -66,7 +66,13 @@ var SLUG_RE     = /^[a-z0-9](?:[a-z0-9-]{0,198}[a-z0-9])?$/;
 var SKU_RE      = /^[A-Za-z0-9][A-Za-z0-9._-]{0,127}$/;
 var CURRENCY_RE = /^[A-Z]{3}$/;
 var MAX_BULK    = 500;
-var MAX_QTY     = 9999;
+// The per-line quantity ceiling is owned by the cart primitive — source it
+// from there so bulk operations and cart.addLine never diverge on the max a
+// single line may hold. A hand-copied value had drifted 10x lower, which made
+// a line legitimately built past it via cart.addLine un-bulk-addable (addLines
+// threw) and silently clamped on reorder. (cart.js does not require this
+// module, so the top-level require is acyclic.)
+var MAX_QTY     = require("./cart").MAX_QTY;
 var SPLIT_BY    = Object.freeze(["vendor", "category", "drop_ship_supplier"]);
 
 // ---- validators ---------------------------------------------------------

package/lib/checkout.js

@@ -228,6 +228,13 @@ function create(deps) {
   // rule's savings are a shipping concern and are left to the shipping
   // primitive, not folded into the subtotal discount here.
   var autoDiscount  = deps.autoDiscount || null;
+  // Optional coupon-stacking governor. When wired, it decides which of
+  // the shopper-presented codes may combine on one order (the operator's
+  // allow_combine / max_codes_per_order / exclusive_codes policy) before
+  // the discount engine sums anything — so two code-gated rules can't
+  // silently stack past a policy that forbids it. Absent → every
+  // presented code reaches the engine (the pre-governor behaviour).
+  var couponStacking = deps.couponStacking || null;
   // Optional discount-allocation recorder. When wired, a placed order
   // that carried a cart-level discount gets a per-line breakdown of how
   // that discount split across the order lines, recorded as a back-office
@@ -550,6 +557,42 @@ function create(deps) {
           unit_price_minor: l.unit_amount_minor,
         });
       }
+      // Apply the coupon-stacking policy BEFORE the engine sums anything.
+      // Only the surviving subset of presented codes unlocks code-gated
+      // rules, so a non-stackable / exclusive / over-cap code cannot
+      // inflate the discount. Only consulted when the governor is wired
+      // AND more than one code is presented (a single code can never
+      // "stack"); drop-silent on any consult failure so a governor outage
+      // never breaks the buy path — the discount clamp below still bounds
+      // the result to [0, subtotal].
+      var effectiveCodes = Array.isArray(codes) && codes.length ? codes : undefined;
+      if (couponStacking && typeof couponStacking.evaluate === "function" &&
+          typeof couponStacking.activePoliciesForCart === "function" &&
+          Array.isArray(codes) && codes.length > 1) {
+        try {
+          // Governance is opt-in: only an ACTIVE stacking policy narrows the
+          // presented codes. With no governing policy the operator hasn't
+          // asked checkout to police stacking, so the codes pass through
+          // unchanged — the cart accepted them and silently dropping one
+          // here would diverge the charged price from what the cart showed.
+          var govCart  = { subtotal_minor: subtotalMinor };
+          var policies = await couponStacking.activePoliciesForCart({
+            cart: govCart, customer_id: customerId || undefined,
+          });
+          if (Array.isArray(policies) && policies.length > 0) {
+            var stack = await couponStacking.evaluate({
+              codes: codes,
+              cart:  govCart,
+              customer_id: customerId || undefined,
+            });
+            if (stack && Array.isArray(stack.applied)) {
+              effectiveCodes = stack.applied.length ? stack.applied : undefined;
+            }
+          }
+        } catch (_e) {
+          effectiveCodes = Array.isArray(codes) && codes.length ? codes : undefined;
+        }
+      }
       var res = await autoDiscount.evaluate({
         cart: {
           subtotal_minor: subtotalMinor,
@@ -558,8 +601,9 @@ function create(deps) {
         customer_id: customerId || undefined,
         // Shopper-presented coupon codes unlock code-gated rules. Absent /
         // empty leaves only the pure-automatic rules in play, so a quote
-        // with no codes is byte-identical to the pre-code behaviour.
-        codes: Array.isArray(codes) && codes.length ? codes : undefined,
+        // with no codes is byte-identical to the pre-code behaviour. The
+        // coupon-stacking governor (above) may narrow this set.
+        codes: effectiveCodes,
       });
       var appliedRaw = res && Array.isArray(res.applied) ? res.applied : [];
       var total   = 0;

package/package.json

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