@blamejs/blamejs-shop 0.4.103 → 0.4.105

package/CHANGELOG.md

@@ -8,6 +8,10 @@ upgrading across more than a few patches at a time.
 
 ## v0.4.x
 
+- v0.4.105 (2026-06-25) — **A loyalty points balance is now an exactly-once, tamper-evident running ledger instead of a stored counter updated alongside its history.** A customer's loyalty balance, lifetime points, and tier were held in a stored account row and updated in a statement separate from the transaction-history insert. On a backend without interactive transactions, a failure between those two writes could leave the balance and the history disagreeing, and there was no way to make a points credit exactly-once with a stored counter. Every loyalty mutation — earn, redeem, expire, adjust, credit, and the refund-time reverse/restore credits — is now a single guarded insert into the transaction ledger that also carries the new running balance, lifetime, and tier, so the balance change and its audit row are one write with no window to half-apply. The running balance is read from the ledger tip rather than a separate counter, redemptions refuse an overdraft inside that one statement, and concurrent writes to the same customer are serialized by a per-customer chain so two redemptions can never both spend the same points. Each ledger row is linked into a per-customer SHA3-512 hash chain, so the history is tamper-evident and can be verified end to end (the loyalty addition to the store-credit and gift-card ledger tamper-evidence). Balances, tiers, the points ratios, and the entire loyalty API are unchanged; the running-balance columns are added by a migration that anchors each existing customer to their current trusted balance without replaying history. The account row is kept as a denormalized mirror for the tier leaderboard and tier-expiry, refreshed after each write and never on a balance decision path. **Changed:** *Loyalty balance, lifetime, and tier are computed from a single guarded ledger write* — The loyalty balance, lifetime points, and tier are no longer a stored counter mutated next to a separate history insert. Each earn / redeem / expire / adjust / credit and each refund-time reverse or restore is now one guarded insert into the loyalty transaction ledger that records the event and carries the resulting running balance, lifetime, and tier in the same row — so a balance change and its audit entry are a single write that cannot half-apply, and a points credit is exactly-once and crash-safe. The current balance is read from the latest ledger row; a redemption's overdraft refusal lives inside that insert; and concurrent writes to one customer are serialized so two redemptions can't both spend the same balance. The customer's balances, tier, the points-per-dollar and redemption ratios, and the public loyalty API are all unchanged. · *Loyalty history is now a tamper-evident hash chain with a verifyChain audit* — Each loyalty transaction row is linked to the previous one for the same customer by a SHA3-512 hash chain, the same tamper-evidence the store-credit and gift-card ledgers already carry. A new verifyChain audit recomputes the chain to prove no past row was edited or re-ordered. A schema migration adds the running-balance and chain columns and anchors every existing customer to their current trusted balance — it copies the live balance verbatim rather than replaying history, so a balance is never recomputed (and never corrupted) during the upgrade. The migration applies automatically on deploy; no operator action is required.
+
+- v0.4.104 (2026-06-25) — **Compare-and-swap atomic claims across the framework now decide won/lost through the shared row-count primitive instead of hand-rolled checks.** Throughout the framework, an atomic claim on a single-statement-per-request backend is a guarded write — UPDATE ... WHERE the row is still in its expected state, or a conditional INSERT — whose affected-row count decides whether this caller won the race (exactly one row) or lost and must no-op. That won/lost decision was hand-rolled at each site as a Number(result.rowCount || 0) === 1 check, which silently treats a result carrying no recognizable row-count as a lost race. Every such site (104 across commissions, redemption caps, inventory and stock-transfer claims, fulfillment and replenishment leases, gift-card and loyalty ledger writes, webhook delivery leases, and more) now routes that decision through the framework's shared row-count primitive, which owns the exactly-one-row check and the cross-adapter row-count field naming, and surfaces an indeterminate result instead of silently counting it as lost. On the production database path the affected-row count is always reported, so there is no behavior change; the change centralizes the interpretation and makes an otherwise-silent indeterminate result observable. No configuration changes and no schema changes. **Changed:** *Atomic compare-and-swap claims use the shared row-count primitive for their won/lost decision* — Compare-and-swap atomic claims — the guarded UPDATE / conditional INSERT pattern used wherever two requests can race the same row on a backend without interactive transactions — previously decided won-versus-lost with a hand-written row-count comparison at each call site, and a result that carried no recognizable row-count was silently taken as a lost race. These claims now make that decision through the framework's shared row-count primitive, which centralizes the exactly-one-row check and the adapter-specific row-count field naming and raises an error on an indeterminate result rather than treating it as a loss. Because the production database always reports the affected-row count, the won/lost outcome is unchanged on every real path; the benefit is one consistent, audited interpretation and a previously-silent indeterminate result now surfacing. A hand-rolled cross-adapter row-count extraction in the webhook delivery-retry lease is removed in favor of the same primitive.
+
 - v0.4.103 (2026-06-25) — **A return refund that exceeds the order's remaining refundable balance is now refused cleanly, instead of failing at the payment provider.** The direct refund console refuses an over-refund up front: it compares the requested amount against the order's remaining refundable balance and returns a clear 'more than is still refundable' error before any money moves. The provider-backed return (RMA) refund path skipped that check — it issued the RMA's approved amount straight to the payment provider, relying on the provider to reject anything past the captured charge. The result was a late, opaque provider-failure error (and a returns workflow left mid-flight) instead of the clean, actionable refusal the console gives. The RMA refund path now applies the same remaining-balance guard before calling the provider: an approved amount greater than what remains refundable — including a return stacked on top of an earlier partial refund — is refused with the same clear message, the return is left in its received state so the operator can re-approve a corrected amount, and the payment provider is never dialed. A refund of an already-refunded return continues to return the existing conflict response. No configuration changes. **Fixed:** *Return (RMA) refunds honor the order's remaining-balance cap before reaching the payment provider* — A provider-backed return refund issued the return's approved amount directly to Stripe or PayPal with no remaining-balance check, so an amount larger than what was still refundable on the order — for example a return approved for more than the order total, or stacked on top of an earlier partial refund — failed only at the payment provider, surfacing as an opaque provider-failure error rather than the clean refusal the direct refund console returns. The return refund path now compares the approved amount against the order's remaining refundable balance first: an over-cap amount is refused with a clear message, the return stays in its received state so a corrected amount can be re-approved, and the provider is never called. A refund attempt on an already-refunded return still returns the existing conflict response.
 
 - v0.4.102 (2026-06-25) — **Vendored framework refreshed to 0.15.26.** Updates the vendored blamejs framework to 0.15.26. The substantive upstream change is a worker-thread handle leak fix in the sandbox primitive: b.sandbox.run now awaits the worker's termination before resolving, so repeatedly running sandboxed code in a long-lived process no longer accumulates leaked MessagePort handles that keep the event loop alive and slow graceful shutdown. The follow-up 0.15.26 build is upstream test-harness correctness only and ships a library byte-for-byte identical to 0.15.25. No runtime API changes and no behavior change for this storefront, which does not run untrusted code through the sandbox primitive; no operator action required. **Changed:** *Vendored framework refreshed to 0.15.26* — Refreshes the vendored blamejs framework to 0.15.26. Upstream 0.15.25 fixes a worker-thread MessagePort leak in the sandbox primitive (b.sandbox.run now waits for the worker to terminate before resolving), and 0.15.26 is a test-harness-only build whose shipped library is identical to 0.15.25. There are no runtime API changes; this storefront does not expose the sandbox primitive on any request path, so there is no operator-visible behavior change and no action required.

package/README.md

@@ -81,7 +81,7 @@ Every primitive is composed on the vendored blamejs surface — no npm runtime d
 | **`lib/quotes.js`** | Request-for-quote negotiation. A signed-in customer requests a quote from the cart (line quantities + an optional message); the operator responds from the console with per-line pricing and a validity window; the customer reviews and accepts or declines from `/account/quotes` or through a single-use capability link (`/quote/:token` — the token is stored only as a namespaced hash and compared timing-safe). Accepting converts through the normal order path — inventory holds are placed first and rolled back if order creation fails — and every status change replays a `b.fsm` lifecycle (requested → responded → accepted / declined / expired / withdrawn / converted), with expiry enforced at accept time so a stale price is never honored. A scheduled sweep also transitions quotes past their validity window to `expired` (so the console's expired filter reflects the real lifecycle), operators can reprice an open quote (the customer's existing link shows the new pricing) or convert a verbally-approved one to an order with a recorded reason, and the customer view renders the operator's per-line notes and the validity date. |
 | **`lib/addresses.js`** | Per-customer address book at `/account/addresses` — add / edit / set default shipping or billing / remove. One-default-per-role invariant (promoting clears the prior). Every by-id route confirms the address belongs to the signed-in customer before acting (a guessed id returns 404). `b.guardUuid` ids, 2-char ISO country. |
 | **`lib/returns.js`** | Self-serve RMAs. Customer requests a return against their own order at `/account/orders/:id/return` (items + reason, ownership-checked, lines built from the order's own records) and tracks status at `/account/returns`. Operators work `/admin/returns` — approve (refund amount) / mark received / refund / reject — over the pending → approved → received → refunded FSM; illegal transitions are 409, bad ids 404. |
-| **`lib/loyalty.js`** + **`lib/loyalty-earn-rules.js`** + **`lib/loyalty-redemption.js`** | Customer rewards. `loyalty` owns the points balance, lifetime total, tier (bronze → platinum on operator-tunable thresholds), and an audited transaction ledger. `loyalty-earn-rules` defines how points are minted (per-dollar-spent, per-order, signup, birthday, …) keyed to lifecycle events; `loyalty-redemption` is the reward catalog customers spend points against. Customers see all of it at `/account/loyalty` — balance + tier, the earn rules in plain language, the reward catalog with a one-click Redeem, past redemptions, and the paginated earn/redeem ledger (login-gated). Paid orders award points automatically: the order FSM's paid transition fans out to the earn rules fire-and-forget, deduped on the order id so a re-delivered payment webhook never double-credits. At checkout a signed-in customer can spend points for a credit against the order total — valued by the redemption ratio (100 points = $1 default), capped at the order's worth and the balance, debited once behind a balance-guarded SQL decrement, stacking with any gift-card credit; surplus points stay in the balance. |
+| **`lib/loyalty.js`** + **`lib/loyalty-earn-rules.js`** + **`lib/loyalty-redemption.js`** | Customer rewards. `loyalty` owns the points balance, lifetime total, tier (bronze → platinum on operator-tunable thresholds), and an audited transaction ledger — the balance, lifetime, and tier ride that ledger as a per-customer running snapshot written in one guarded row per event (exactly-once, with no separate counter to fall out of step), linked into a per-customer SHA3-512 hash chain like the gift-card and store-credit ledgers, with `loyalty.verifyChain(customerId)` to recompute it end to end. `loyalty-earn-rules` defines how points are minted (per-dollar-spent, per-order, signup, birthday, …) keyed to lifecycle events; `loyalty-redemption` is the reward catalog customers spend points against. Customers see all of it at `/account/loyalty` — balance + tier, the earn rules in plain language, the reward catalog with a one-click Redeem, past redemptions, and the paginated earn/redeem ledger (login-gated). Paid orders award points automatically: the order FSM's paid transition fans out to the earn rules fire-and-forget, deduped on the order id so a re-delivered payment webhook never double-credits. At checkout a signed-in customer can spend points for a credit against the order total — valued by the redemption ratio (100 points = $1 default), capped at the order's worth and the balance, debited once behind a balance-guarded SQL decrement, stacking with any gift-card credit; surplus points stay in the balance. |
 | **`lib/referrals.js`** + **`lib/referral-leaderboard.js`** | Refer-a-friend with two-sided rewards. `referrals` issues each customer an 8-character code (32-glyph confusion-resistant alphabet via `b.crypto.generateBytes`) and tracks each referred friend through the funnel (invited → visited → joined → converted); referred emails are stored hash-only (`b.crypto.namespaceHash`), never plaintext. `referral-leaderboard` sits on top for top-referrer rankings + operator-tunable tier bonuses. Customers see all of it at `/account/referrals` — their code, an absolute shareable link, the friends they've referred (funnel stage + dates, no personal data), and an in-account leaderboard (rank + initials only). A public `/r/<code>` landing captures an inbound referral into a short-lived sealed first-party cookie (first-touch), which attributes the new customer to the referrer when they sign up by passkey / Google / Apple — self-referral and double-attribution guarded. When a referred customer's first order reaches paid, the order FSM's paid transition marks that referral converted and bumps the referrer's count fire-and-forget, deduped on the order id so a re-delivered webhook never double-counts; guest orders and a customer's later orders don't qualify. Issuing the payout itself (gift card / store credit / loyalty points) is an explicit operator action via the referrals reward API, so the reward instrument and any fraud review stay the operator's. |
 | **`lib/product-compare.js`** | Side-by-side product comparison, no sign-in required. Each product page gets an "Add to compare" / "Remove from compare" control; `POST /compare/toggle` adds or removes the product and `GET /compare` renders the comparison table — image, price, availability, and the per-product attributes resolved through the catalog. The basket is keyed on the visitor's existing sealed session cookie (a signed-in shopper's customer id rides alongside), capped at four products (a fifth add is refused with a notice rather than silently dropping one), and is idempotent. Products that go archived or out of stock resolve out of the table with a remove control instead of breaking the render; an empty basket shows a friendly empty state. `POST /compare/clear` empties it. Linked from the footer on every page. |
 | **`lib/bundles.js`** | Sell products together at a set price. A product page shows the bundles it belongs to as a "Bundle & save" offer — the member products, the bundle price, and the saving against the parts. `POST /cart/bundle` adds the whole bundle in one action: the price is recomputed from the live catalog and allocated across the member lines (proportional to list price, remainder on the last line) so the cart subtotal matches the quoted price. The add is atomic — an archived or out-of-stock member shows the bundle unavailable and adds nothing rather than a partial set; an unpriceable bundle (missing member price / currency mismatch) is shown unavailable, never a 500. The client sends only the bundle code; the server prices it. The offer renders identically from the edge worker and the container. |

package/SECURITY.md

@@ -319,15 +319,18 @@ node -e "
   (success / failure / denied) and paginated. Opening the log is itself
   recorded (an `audit.read` row), so reviewing the audit trail leaves
   its own forensic mark.
-- **The gift-card and store-credit ledgers are hash-chained, fork-proof,
-  and verifiable.** Every ledger entry — credits, debits, and
+- **The gift-card, store-credit, and loyalty ledgers are hash-chained,
+  fork-proof, and verifiable.** Every ledger entry — credits, debits, and
   expirations alike — links to its predecessor through a SHA3-512 chain,
-  keyed per card (gift cards) or per customer (store credit), so editing a
-  row or deleting one from the middle breaks the linkage. A uniqueness
-  fence (one child per chain tip) makes concurrent writes serialize rather
-  than fork the chain. `giftCardLedger.verifyChain(cardId)` /
-  `storeCredit.verifyChain(customerId)` recompute a ledger's chain end to
-  end and report the first divergence — run them whenever a balance is
+  keyed per card (gift cards) or per customer (store credit, loyalty), so
+  editing a row or deleting one from the middle breaks the linkage. A
+  uniqueness fence (one child per chain tip) makes concurrent writes
+  serialize rather than fork the chain, and each loyalty / gift-card /
+  store-credit balance change is written in that same single guarded row,
+  so a points or balance mutation is exactly-once even on a backend without
+  interactive transactions. `giftCardLedger.verifyChain(cardId)` /
+  `storeCredit.verifyChain(customerId)` / `loyalty.verifyChain(customerId)`
+  recompute a ledger's chain end to end and report the first divergence — run them whenever a balance is
   disputed; pass a trusted anchor (a row count + head hash from an earlier
   snapshot) to also catch a truncation that deletes the most-recent rows,
   which an append-only chain can't detect on its own. The overdraft

package/lib/affiliates.js

@@ -925,7 +925,7 @@ function create(opts) {
         "WHERE id = ?3 AND status = 'pending'",
         [paidAt, reference, id],
       );
-      if (Number(paidUpd.rowCount || 0) !== 1) {
+      if (!b.sql.casWon(paidUpd).won) {
         var racedPaid = await _getCommissionRaw(id);
         var refusedPaid = new Error(
           "affiliates.markCommissionPaid: refused — commission is " +
@@ -979,7 +979,7 @@ function create(opts) {
         "WHERE id = ?3 AND status = 'pending'",
         [ts, reason, id],
       );
-      if (Number(voidUpd.rowCount || 0) !== 1) {
+      if (!b.sql.casWon(voidUpd).won) {
         var racedVoid = await _getCommissionRaw(id);
         var refusedVoid = new Error(
           "affiliates.markCommissionVoided: refused — commission is " +

package/lib/api-keys.js

@@ -580,7 +580,7 @@ function create(opts) {
         "token_hash_previous = ?2, token_hash = ?3 WHERE id = ?4 AND status = 'active'",
         [ts, current.token_hash, placeholderHash, id],
       );
-      if (Number(rotateClaim.rowCount || 0) !== 1) {
+      if (!b.sql.casWon(rotateClaim).won) {
         var lost = await _getRaw(id);
         var refusedRotate = new Error(
           "apiKeys.rotate: refused — key is " + (lost ? lost.status : "gone")

package/lib/asset-manifest.json

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

package/lib/auto-discount.js

@@ -1170,7 +1170,7 @@ function create(opts) {
       "ON CONFLICT(rule_slug, order_id) DO NOTHING",
       [id, slug, orderId, customerId, savings, appliedAt],
     );
-    if (Number(ins.rowCount || 0) === 1) {
+    if (b.sql.casWon(ins).won) {
       await query(
         "UPDATE auto_discount_rules SET redemptions_used = redemptions_used + 1, updated_at = ?1 WHERE slug = ?2",
         [_now(), slug],
@@ -1252,7 +1252,7 @@ function create(opts) {
       "WHERE slug = ?2 AND (max_redemptions_total IS NULL OR redemptions_used < max_redemptions_total)",
       [ts, slug],
     );
-    if (Number(counter.rowCount || 0) === 0) {
+    if (!b.sql.casWon(counter).won) {
       return { claimed: false, reason: "total-cap" };
     }
 
@@ -1297,7 +1297,7 @@ function create(opts) {
       }
       throw e;
     }
-    if (Number(ins.rowCount || 0) === 0) {
+    if (!b.sql.casWon(ins).won) {
       // Per-customer cap refused — return the total-cap reservation.
       await query(
         "UPDATE auto_discount_rules SET redemptions_used = " +
@@ -1326,7 +1326,7 @@ function create(opts) {
       "UPDATE auto_discount_applications SET order_id = ?1 WHERE rule_slug = ?2 AND order_id = ?3",
       [orderId, slug, claimRef],
     );
-    return Number(res.rowCount || 0) === 1;
+    return b.sql.casWon(res).won;
   }
 
   async function releaseClaim(input) {

package/lib/auto-replenish.js

@@ -770,7 +770,7 @@ function create(opts) {
           "AND (last_run_at IS NULL OR last_run_at <= ?3)",
           [now, policy.slug, now - interval],
         );
-        if (Number(claim.rowCount || 0) !== 1) continue;   // lost the claim / not yet due
+        if (!b.sql.casWon(claim).won) continue;   // lost the claim / not yet due
         var runRow = await _runPolicyOnce(policy, now);
         summaries.push(_shapeRun(runRow));
       }

package/lib/backorder.js

@@ -332,7 +332,7 @@ function create(opts) {
         "WHERE id = ?2 AND status = 'pending'",
         [ts, line.id],
       );
-      if (Number(fulfillClaim.rowCount || 0) !== 1) {
+      if (!b.sql.casWon(fulfillClaim).won) {
         throw new TypeError("backorder.fulfillBackorder: line is no longer pending " +
           "(concurrently fulfilled or cancelled)");
       }
@@ -377,7 +377,7 @@ function create(opts) {
         "WHERE id = ?3 AND status = 'pending'",
         [reason, ts, line.id],
       );
-      if (Number(cancelClaim.rowCount || 0) !== 1) {
+      if (!b.sql.casWon(cancelClaim).won) {
         throw new TypeError("backorder.cancelBackorder: line is no longer pending " +
           "(concurrently fulfilled or cancelled)");
       }

package/lib/carrier-accounts.js

@@ -591,7 +591,7 @@ function create(opts) {
         "WHERE id = ?6 AND status IN ('active','rotating') AND api_key_hash = ?7",
         [hashKey, prevHash, hashSec, now, now, id, prevHash],
       );
-      if (Number(claim.rowCount || 0) !== 1) {
+      if (!b.sql.casWon(claim).won) {
         var lost = await _getRaw(id);
         var conflict = new Error(
           (lost && lost.status === "disabled")

package/lib/cart-bulk-ops.js

@@ -536,7 +536,7 @@ function create(opts) {
         "UPDATE carts SET status = 'abandoned', updated_at = ?1 WHERE id = ?2 AND status = 'active'",
         [ts, input.cart_id],
       );
-      if (Number(claim.rowCount || 0) !== 1) {
+      if (!b.sql.casWon(claim).won) {
         throw new TypeError("cartBulkOps.splitCart: cart " + input.cart_id + " already split/modified");
       }
       var children = [];

package/lib/cart.js

@@ -450,7 +450,7 @@ function create(opts) {
         [ts, cartId],
       );
       var cart = (await query("SELECT * FROM carts WHERE id = ?1", [cartId])).rows[0] || null;
-      return { claimed: Number(r.rowCount || 0) === 1, cart: cart };
+      return { claimed: b.sql.casWon(r).won, cart: cart };
     },
 
     // Release a checkout claim back to 'active' so the buyer can retry. The
@@ -470,7 +470,7 @@ function create(opts) {
         "UPDATE carts SET status = 'active', updated_at = ?1 WHERE id = ?2 AND status = 'converted'",
         [ts, cartId],
       );
-      return Number(r.rowCount || 0) === 1;
+      return b.sql.casWon(r).won;
     },
 
     // ---- abandoned-cart visibility (operator dashboard) ---------------

package/lib/catalog.js

@@ -743,7 +743,7 @@ function _inventoryModule(query, opts) {
         "WHERE sku = ?3 AND (stock_on_hand - stock_held) >= ?1",
         [need, ts, sku],
       );
-      if (rDown.rowCount === 1) {
+      if (b.sql.casWon(rDown).won) {
         await _afterMutation(sku);
         return { adjusted: true, sku: sku, delta: delta };
       }
@@ -796,7 +796,7 @@ function _inventoryModule(query, opts) {
         "WHERE sku = ?3 AND (stock_on_hand - stock_held) >= ?1",
         [qty, ts, sku],
       );
-      if (r.rowCount === 1) {
+      if (b.sql.casWon(r).won) {
         // Hold lowers available; a low-stock threshold may now trip.
         await _afterMutation(sku);
         return { held: true, sku: sku, qty: qty };
@@ -829,7 +829,7 @@ function _inventoryModule(query, opts) {
         "WHERE sku = ?3 AND stock_held >= ?1 AND stock_on_hand >= ?1",
         [qty, ts, sku],
       );
-      if (r.rowCount === 1) {
+      if (b.sql.casWon(r).won) {
         await _afterMutation(sku);
         return { decremented: true, sku: sku, qty: qty };
       }

package/lib/click-and-collect.js

@@ -493,7 +493,7 @@ function create(opts) {
             input.scheduled_window_start, input.scheduled_window_end, now, now,
             bucketStart, bucketEnd, capacity],
         );
-        if (Number(ins.rowCount || 0) === 0) {
+        if (!b.sql.casWon(ins).won) {
           throw new TypeError("click-and-collect.scheduleAtLocation: location_code " +
             JSON.stringify(input.location_code) + " is at capacity for the requested window");
         }
@@ -592,7 +592,7 @@ function create(opts) {
         "WHERE order_id = ?5 AND status = 'ready'",
         [input.picked_up_at, sigHash, proofKind, now, orderId],
       );
-      if (Number(pickupClaim.rowCount || 0) !== 1) {
+      if (!b.sql.casWon(pickupClaim).won) {
         throw new TypeError("click-and-collect.markPickedUp: schedule is no longer ready " +
           "(concurrently picked up)");
       }

package/lib/customer-merge.js

@@ -707,7 +707,7 @@ function create(opts) {
         "executed_at = ?1, executed_by = ?2 WHERE id = ?3 AND status = 'proposed'",
         [ts, executedBy, mergeId],
       );
-      if (Number(claim.rowCount || 0) !== 1) {
+      if (!b.sql.casWon(claim).won) {
         // Lost the race (or the row left 'proposed' between our read
         // and the claim). Re-read: an already-executed row is the
         // winner's result; anything else is a genuine state error.
@@ -818,7 +818,7 @@ function create(opts) {
         "AND EXISTS (SELECT 1 FROM customer_merge_redirects WHERE source_customer_id = ?4)",
         [now, reason, mergeId, row.source_customer_id],
       );
-      if (Number(claim.rowCount || 0) !== 1) {
+      if (!b.sql.casWon(claim).won) {
         var raceErr = new Error("customerMerge.rollbackMerge: merge_id " + mergeId +
           " is no longer executed (or its merge is still finalizing); only fully-executed merges can be rolled back");
         raceErr.code = "CUSTOMER_MERGE_NOT_EXECUTED";

package/lib/customer-surveys.js

@@ -758,7 +758,7 @@ function create(opts) {
       "WHERE id = ?2 AND status = 'issued'",
       [nowTs, invitation.id],
     );
-    if (Number(claim.rowCount || 0) !== 1) {
+    if (!b.sql.casWon(claim).won) {
       var raced = new Error("customerSurveys.submitResponse: invitation already responded");
       raced.code = "SURVEY_INVITATION_ALREADY_RESPONDED";
       throw raced;

package/lib/cycle-counting.js

@@ -627,7 +627,7 @@ function create(opts) {
         "WHERE slug = ?4 AND status IN ('scheduled', 'in_progress')",
         [varianceCount, varianceValueMinor, ts, input.slug],
       );
-      if (Number(claim.rowCount || 0) !== 1) {
+      if (!b.sql.casWon(claim).won) {
         // Lost the claim — a concurrent (or prior) finalize already advanced
         // this count and owns the adjustment writes. Touch no shelves; return
         // the totals computed from the now-frozen lines.

package/lib/dropship-forwarding.js

@@ -358,7 +358,7 @@ function create(opts) {
       " WHERE id = ?" + p + " AND status = ?" + (p + 1),
       params,
     );
-    if (Number(upd.rowCount || 0) !== 1) {
+    if (!b.sql.casWon(upd).won) {
       var raced = new Error("dropship-forwarding: forwarding " + forwardingId +
         " changed state concurrently (no longer " + current.status + ") — transition refused");
       raced.code = "DROPSHIP_FORWARDING_TRANSITION_REFUSED";

package/lib/dunning.js

@@ -411,7 +411,7 @@ function create(opts) {
       "WHERE id = ?1 AND status = 'active' AND next_action_at = ?2",
       [enrollment.id, observedNextAt],
     );
-    if (Number(claim.rowCount || 0) !== 1) {
+    if (!b.sql.casWon(claim).won) {
       // Lost the race — another tick already claimed this row (or it
       // was unset to a terminal status between the snapshot and now).
       // Skip the side-effect; return the current row state.

package/lib/email-campaigns.js

@@ -853,7 +853,7 @@ function create(opts) {
       "VALUES (?1, ?2, ?3, 'claimed', NULL, ?4)",
       [b.uuid.v7(), slug, emailHash, Date.now()],
     );
-    return r.rowCount === 1;
+    return b.sql.casWon(r).won;
   }
 
   async function _finalizeSend(slug, emailHash, outcome, failReason) {
@@ -1200,7 +1200,7 @@ function create(opts) {
         "WHERE slug = ?2 AND status = 'scheduled'",
         [Date.now(), slug],
       );
-      if (Number(claim.rowCount || 0) !== 1) {
+      if (!b.sql.casWon(claim).won) {
         var raceErr = new TypeError(
           "emailCampaigns.sendNow: campaign '" + slug + "' is already being sent"
         );
@@ -1260,7 +1260,7 @@ function create(opts) {
           "WHERE slug = ?2 AND status = 'scheduled'",
           [Date.now(), row.slug],
         );
-        if (Number(claim.rowCount || 0) !== 1) continue;
+        if (!b.sql.casWon(claim).won) continue;
         var stats = await _drainSend(row);
         var midRow = await _getRow(row.slug);
         await _fire(midRow, "complete");
@@ -1582,7 +1582,7 @@ function create(opts) {
           "WHERE slug = ?2 AND status = 'scheduled'",
           [Date.now(), slug],
         );
-        if (Number(claim.rowCount || 0) !== 1) {
+        if (!b.sql.casWon(claim).won) {
           var raceErr = new TypeError(
             "emailCampaigns.broadcast: campaign '" + slug + "' is already being sent"
           );

package/lib/giftcards.js

@@ -322,7 +322,7 @@ function create(opts) {
         "updated_at = ?2 WHERE id = ?3 AND balance_minor >= ?1 AND status = 'active'",
         [input.amount_minor, ts, row.id],
       );
-      if (dec.rowCount === 0) {
+      if (!b.sql.casWon(dec).won) {
         // Race: another redemption beat us to the balance. Refuse
         // with the same shape as the up-front insufficient check so
         // the caller doesn't have to distinguish "checked then
@@ -407,7 +407,7 @@ function create(opts) {
           "UPDATE giftcard_redemptions SET reversed_at = ?1 WHERE id = ?2 AND reversed_at IS NULL",
           [ts, red.id],
         );
-        if (Number(claim.rowCount || 0) === 0) continue;   // lost the claim
+        if (!b.sql.casWon(claim).won) continue;   // lost the claim
         // Restore the spendable balance on the card row. Capped at the card's
         // issued_minor by the schema CHECK; the amount restored is exactly
         // what this redemption debited, so it can't exceed the face value.
@@ -446,7 +446,7 @@ function create(opts) {
         "UPDATE giftcard_redemptions SET order_id = ?1 WHERE id = ?2 AND order_id IS NULL",
         [orderId, redemptionId],
       );
-      return Number(res.rowCount || 0) === 1;
+      return b.sql.casWon(res).won;
     },
 
     // Reverse ONE redemption by its own id — the compensation edge for a
@@ -472,7 +472,7 @@ function create(opts) {
         "UPDATE giftcard_redemptions SET reversed_at = ?1 WHERE id = ?2 AND reversed_at IS NULL",
         [ts, red.id],
       );
-      if (Number(claim.rowCount || 0) === 0) return null;   // lost the claim
+      if (!b.sql.casWon(claim).won) return null;   // lost the claim
       await query(
         "UPDATE giftcards SET balance_minor = balance_minor + ?1, " +
         "status = CASE WHEN status = 'redeemed' THEN 'active' ELSE status END, " +
@@ -554,7 +554,7 @@ function create(opts) {
           "WHERE id = ?4 AND reversed_minor = ?5",
           [target, nowFull ? 1 : 0, ts, red.id, already],
         );
-        if (Number(claim.rowCount || 0) === 0) continue;   // lost the claim to a concurrent reversal
+        if (!b.sql.casWon(claim).won) continue;   // lost the claim to a concurrent reversal
         // Restore the spendable balance on the card row. Capped at the card's
         // issued_minor by the schema CHECK; the cumulative reversed_minor is
         // bounded by amount_minor, so it can't exceed the face value.
@@ -592,7 +592,7 @@ function create(opts) {
       // the row (no schema column) but accepted so a future audit-log
       // primitive can ride alongside without a surface change.
       void opts2.reason;
-      if (Number(upd.rowCount || 0) === 1) {
+      if (b.sql.casWon(upd).won) {
         var after = await query("SELECT * FROM giftcards WHERE id = ?1", [id]);
         return after.rows[0] || null;
       }

package/lib/inventory-allocations.js

@@ -381,7 +381,7 @@ function create(opts) {
       "committed_order_id = ?2 WHERE id = ?3 AND status = 'held'",
       [ts, input.order_id, input.hold_id],
     );
-    if (Number(claim.rowCount || 0) !== 1) {
+    if (!b.sql.casWon(claim).won) {
       throw new TypeError("inventory-allocations.commitHold: hold " + existing.id +
         " is no longer held (committed by a concurrent call)");
     }

package/lib/inventory-audits.js

@@ -642,7 +642,7 @@ function create(opts) {
         "WHERE id = ?4 AND status IN ('open', 'in_progress')",
         [varianceCount, varianceValueMinor, ts, auditId],
       );
-      if (Number(claim.rowCount || 0) !== 1) {
+      if (!b.sql.casWon(claim).won) {
         // Lost the claim — a concurrent (or prior) finalize already
         // advanced this audit and owns the adjustment writes. Touch no
         // shelves; return the totals computed from the now-frozen lines.

package/lib/inventory-receive.js

@@ -351,7 +351,7 @@ function create(opts) {
         "UPDATE inventory_receipts SET status = 'applied', updated_at = ?1 WHERE id = ?2 AND status = 'pending'",
         [ts, receiptId],
       );
-      if (Number(claim.rowCount || 0) !== 1) {
+      if (!b.sql.casWon(claim).won) {
         // A concurrent call won the claim and is restocking (or already did).
         // Replay-safe no-op so the loser doesn't double-apply.
         return { id: receiptId, applied_count: 0, stock_changes: [] };
@@ -422,7 +422,7 @@ function create(opts) {
         "UPDATE inventory_receipts SET status = 'reversed', updated_at = ?1 WHERE id = ?2 AND status = 'applied'",
         [claimTs, receiptId],
       );
-      if (Number(claim.rowCount || 0) !== 1) {
+      if (!b.sql.casWon(claim).won) {
         throw new TypeError("inventory-receive.reverse: receipt " + receiptId +
           " is no longer applied (reversed by a concurrent call)");
       }

package/lib/inventory-writeoffs.js

@@ -555,7 +555,7 @@ function create(opts) {
         "reverse_reason = ?2 WHERE id = ?3 AND status = 'recorded'",
         [ts, reason, id],
       );
-      if (Number(claim.rowCount || 0) !== 1) {
+      if (!b.sql.casWon(claim).won) {
         throw new TypeError("inventory-writeoffs.reverseWriteoff: writeoff " + id +
           " is no longer recorded (reversed by a concurrent call)");
       }

package/lib/invoice-renderer.js

@@ -319,7 +319,7 @@ function create(opts) {
         "WHERE series = ?3 AND next_value = ?4",
         [current + 1, Date.now(), series, current],
       );
-      if (Number(info.rowCount) === 1) return current;
+      if (b.sql.casWon(info).won) return current;
     }
     throw new Error("invoiceRenderer: sequence advance for series " + JSON.stringify(series) + " contended 16 times");
   }

package/lib/knowledge-base.js

@@ -928,7 +928,7 @@ function create(opts) {
         "VALUES (?1, ?2, ?3, ?4, ?5)",
         [b.uuid.v7(), slug, sessionHash, vote, ts],
       );
-      var changed = inserted && (inserted.rowCount === 1 || inserted.changes === 1);
+      var changed = inserted && b.sql.casWon(inserted).won;
       if (changed) {
         var col = vote === "helpful" ? "helpful_count" : "not_helpful_count";
         await query(

package/lib/loyalty-redemption.js

@@ -533,7 +533,7 @@ function create(opts) {
       "WHERE customer_id = ?2 AND reward_slug = ?3 AND status IN ('active','consumed')) < ?7",
       [redemptionId, customerId, rewardSlug, reward.point_cost, ts, expiresAt, reward.max_per_customer],
     );
-    if (Number(claim.rowCount || 0) !== 1) {
+    if (!b.sql.casWon(claim).won) {
       // Lost the cap claim — another redeem filled the last slot between
       // the pre-check and here. Return the points and refuse, so a raced
       // caller is never charged for a redemption it didn't get.
@@ -648,7 +648,7 @@ function create(opts) {
       "WHERE id = ?3 AND status = 'active'",
       [ts, orderId, redemptionId],
     );
-    if (Number(r.rowCount || 0) === 0) {
+    if (!b.sql.casWon(r).won) {
       // Lost the race — re-read so the caller gets the row's actual
       // post-race state. Refuse with the same FSM error so the call
       // surface is identical whether the loser noticed pre- or
@@ -691,7 +691,7 @@ function create(opts) {
       "WHERE id = ?2 AND status = 'active'",
       [reason, redemptionId],
     );
-    if (Number(r.rowCount || 0) === 0) {
+    if (!b.sql.casWon(r).won) {
       var raceAfter = await getRedemption(redemptionId);
       var raceErr = new Error("loyaltyRedemption.cancelRedemption: redemption status is '" + (raceAfter && raceAfter.status) + "', only 'active' may be cancelled with a point refund");
       raceErr.code = "REDEMPTION_NOT_ACTIVE";