@blamejs/blamejs-shop 0.4.98 → 0.4.100

package/CHANGELOG.md

@@ -8,6 +8,10 @@ upgrading across more than a few patches at a time.
 
 ## v0.4.x
 
+- 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.
 
 - v0.4.97 (2026-06-25) — **Constraint-collision handling no longer depends on the database error text, so duplicate detection works in production instead of only in tests.** Several write paths detected a UNIQUE (or related) constraint collision by matching the database error message — looking for the literal text 'UNIQUE constraint failed'. That text only survives in local/test runs: in production, the data layer redacts the underlying SQLite error to a generic 'HTTP 500' with no constraint text, so the match silently failed and the intended collision handling was skipped — the raw error surfaced instead of the idempotent replay, the typed duplicate error, the regenerate-and-retry, or the claim reuse. Every such site now detects the collision by re-reading state through the unique key after the insert fails: if the row is present the failure was the collision and the site runs its existing handling; if not, the original error is re-thrown. This makes idempotent webhook replays, duplicate-key errors, code/token retries, and discount-claim reuse behave correctly in production, not just under tests. No configuration changes. **Fixed:** *Constraint-collision detection is now state-based, not error-message-based* — Duplicate-delivery webhook replays (webhook receiver), duplicate-key errors (tenant domain + slug, vendor SKU), regenerate-and-retry on a code/token collision (referral codes, gift-redemption tokens, API keys, affiliate codes), and the auto-discount per-order claim reuse all decided 'was this a constraint collision?' by scanning the SQLite error message. Production redacts that message to a bare 'HTTP 500', so the check was blind there and the collision branch never ran. Each site now re-reads by its unique key after an insert error and runs its handling only when the row is actually present, re-throwing any other error — the same approach the gift-card and affiliate-commission ledgers already use. The admin error-to-response mapper, which has no single key to re-read, now prefers a typed constraint code over the message text where the driver provides one.

package/lib/asset-manifest.json

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

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/lib/dunning.js

@@ -421,18 +421,32 @@ function create(opts) {
     var attemptCount = Number(enrollment.attempt_count);
     var stepIndex    = attemptCount;
     if (stepIndex >= schedule.length) {
-      // Walked off the end. Either we've hit the attempt cap or
-      // we close the enrollment as abandoned (the schedule was
-      // exhausted without recovery and without the operator
-      // configuring an explicit cancel step).
+      // Walked off the end with no step left to run. If the attempt cap
+      // has been reached this is the "tried everything" auto-cancel, so
+      // we COMPOSE the subscription-side cancel (exitDunning) — not just
+      // flip the row, otherwise the enrollment reads cancelled while the
+      // recurring charge keeps firing. Below the cap it's an
+      // operator-authored schedule that ran out before resolution, which
+      // closes 'abandoned' with no cancel intent. Either way the audit
+      // event records what actually happened — never a fabricated cancel.
       var closeAs = attemptCount >= cancelAfterAttempts ? "cancelled" : "abandoned";
+      var exhaustOutcome = closeAs === "cancelled"
+        ? await _executeAction("cancel_subscription", enrollment)
+        : null;
       await query(
         "UPDATE dunning_enrollments SET status = ?1, next_action_at = NULL, " +
         "ended_at = ?2, end_reason = ?3, last_action = ?4, last_action_at = ?2 " +
         "WHERE id = ?5 AND status = 'active'",
-        [closeAs, now, "schedule_exhausted", "schedule_exhausted", enrollment.id],
+        [closeAs, now, "schedule_exhausted",
+          closeAs === "cancelled" ? "cancel_subscription" : "schedule_exhausted",
+          enrollment.id],
+      );
+      await _writeEvent(
+        enrollment.id, attemptCount,
+        closeAs === "cancelled" ? "cancel_subscription" : "schedule_exhausted",
+        closeAs === "cancelled" ? exhaustOutcome : "ok",
+        now,
       );
-      await _writeEvent(enrollment.id, attemptCount, "cancel_subscription", "ok", now);
       return await _refetchEnrollment(enrollment.id);
     }
 
@@ -444,13 +458,28 @@ function create(opts) {
     var terminal = (action === "cancel_subscription") || (newAttemptCount >= cancelAfterAttempts);
 
     if (terminal) {
+      // A `cancel_subscription` STEP already composed the subscription
+      // cancel via _executeAction above. When the ATTEMPT CAP fires on a
+      // non-cancel step (send_reminder / retry_charge), the enrollment
+      // still closes 'cancelled' — so the subscription-side cancel must
+      // be composed here too; the bare status flip would leave the
+      // subscription billing. The step's own action event is preserved;
+      // the composed cancel is recorded as its own event with the real
+      // outcome (so a failed cancel is visible, not masked as success).
+      var capCancelOutcome = null;
+      if (action !== "cancel_subscription") {
+        capCancelOutcome = await _executeAction("cancel_subscription", enrollment);
+      }
       await query(
         "UPDATE dunning_enrollments SET status = 'cancelled', next_action_at = NULL, " +
-        "attempt_count = ?1, last_action = ?2, last_action_at = ?3, " +
-        "ended_at = ?3, end_reason = ?4 WHERE id = ?5 AND status = 'active'",
-        [newAttemptCount, action, now, action === "cancel_subscription" ? "policy_cancel_step" : "attempt_cap", enrollment.id],
+        "attempt_count = ?1, last_action = 'cancel_subscription', last_action_at = ?2, " +
+        "ended_at = ?2, end_reason = ?3 WHERE id = ?4 AND status = 'active'",
+        [newAttemptCount, now, action === "cancel_subscription" ? "policy_cancel_step" : "attempt_cap", enrollment.id],
       );
       await _writeEvent(enrollment.id, newAttemptCount, action, outcome, now);
+      if (action !== "cancel_subscription") {
+        await _writeEvent(enrollment.id, newAttemptCount, "cancel_subscription", capCancelOutcome, now);
+      }
       return await _refetchEnrollment(enrollment.id);
     }
 

package/package.json

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