@blamejs/blamejs-shop 0.4.62 → 0.4.63

package/CHANGELOG.md

@@ -8,6 +8,8 @@ upgrading across more than a few patches at a time.
 
 ## v0.4.x
 
+- v0.4.63 (2026-06-19) — **Fulfillment and customer-data actions can't double-fire under concurrent calls.** Closes a further set of concurrency races where a fulfillment or customer-data action read a row, checked its status in application code, and then performed an irreversible side-effect (open an inventory hold, create shipments, restock received stock, create an order, reparent customer records, requeue a print job, mint child carts) before an unconditional update committed — so two concurrent calls could both pass the check and both perform the side-effect. Each now claims the transition with a single conditional update and performs the side-effect only when that claim wins, reverting the claim if the side-effect then fails so a row is never stranded. Approving an exchange opens its replacement hold once; executing a split-shipment plan creates the parcels once; recording a partial purchase-order receipt restocks each line once (claimed per line); completing a pick list creates its shipment once; converting or launching a pre-order creates the order once and a reservation can't oversell its cap; merging or rolling back a customer reparents the records once; an impersonation notice, a duplicate-suggestion link, a print-job retry, and a cart split each happen once. Behavior for a single sequential caller is unchanged. **Fixed:** *Fulfillment transitions claim before their side-effect* — Approving an exchange now claims pending-to-approved (WHERE id = ? AND status = 'pending') before opening the replacement inventory hold, reverting to pending if the hold fails. Executing a split-shipment plan claims proposed-to-executed before creating any shipment. Recording a partial purchase-order receipt claims each receipt line by advancing its received quantity conditionally before restocking, rolling the claimed lines back if a later line fails. Completing a pick list claims its completion before creating the shipment. In each case two concurrent calls can no longer both create the holds / shipments / restock for one row. · *Pre-order conversion, launch, cancel, and reserve are atomic* — Converting a reservation to an order claims active-to-converted before creating the order (reverting on failure), so a reservation can't spawn two orders; launching a campaign claims active-to-launched before walking reservations; cancelling claims active-to-cancelled before decrementing the reserved counter. Reserving now enforces the campaign cap inside the increment itself (units_reserved + qty <= max_units_available in the update's WHERE), so concurrent reservations can't oversell the pool; a reservation that loses the cap is compensated. · *Customer merge/rollback, impersonation notice, suggestion dedup, print retry, and cart split run once* — Executing or rolling back a customer merge claims the transition before reparenting records, reverting if the reparent fails. Sending the 'an operator viewed your account' notice claims the notified stamp (WHERE customer_notified_at IS NULL) before enqueuing, so it's sent once. Linking a duplicate suggestion claims the source before migrating its votes to the canonical row. Marking a print job failed claims the transition before inserting the retry job, so a job isn't reprinted twice. Splitting a cart claims the source's abandon before minting the child carts, so a concurrent split can't create two sets of children.
+
 - v0.4.62 (2026-06-19) — **Money and approval actions can't double-fire under concurrent calls.** Closes a set of concurrency races in money- and approval-critical paths where the action read a row, checked its status in application code, and then performed an irreversible side-effect (retry a card, execute an approved action, register a vendor, bill a subscription change) before an unconditional update committed — so two concurrent calls could both pass the check and both perform the side-effect. Each now claims the transition with a single conditional update and performs the side-effect only when that claim wins. A scheduled payment retry is claimed out of the due set before the processor is called, so an overlapping scheduler tick can't retry the same card twice; a payment outcome is claimed by its attempt number before the attempt is recorded, so a redelivered webhook can't double-count it. Executing an approved operator request claims the approved-to-executed transition before returning success, so the underlying money move runs once. Approving a seller application claims the in-review-to-approved transition before registering the vendor (rolling back to in-review if registration fails), so one application can't create two vendors. Applying scheduled subscription plan changes claims each pending change before updating the plan and recording its proration invoice, and stamps a deterministic idempotency key on the invoice, so an overlapping or retried scheduler run can't bill the proration twice. Behavior for a single sequential caller is unchanged. **Fixed:** *Scheduled payment retries and recorded outcomes claim before acting* — The retry scheduler now claims each due enrollment (nulling its next-retry time, conditional on the value the tick observed) before composing the processor retry, so two overlapping ticks can't both retry the same card for one scheduled slot — only the claim winner calls the processor. Recording a retry outcome claims the enrollment by bumping its attempt count conditionally on the observed value before writing the attempt row, so a redelivered webhook (or a manual record racing it) can't write a duplicate attempt or double-count toward the cap; the loser returns the already-advanced row. · *Executing an approved request runs the action once* — markExecuted now flips the request from approved to executed with a conditional update (WHERE id = ? AND status = 'approved') and returns success only when that update changes one row; a concurrent second call is refused with a typed error before the application runs the underlying action (a large refund, vendor payout, or bulk operation) a second time. · *Approving a seller application creates one vendor* — approveApplication now claims the in-review-to-approved transition first and registers the vendor only when the claim wins, so two concurrent approvals can't both register a vendor for one application. If vendor registration fails after the claim, the application is rolled back to in-review so it can be approved again rather than stranded as approved with no vendor. · *Applying scheduled plan changes bills the proration once* — applyScheduledChanges now claims each pending change (WHERE id = ? AND status = 'pending') before updating the subscription plan and recording the proration invoice, so an overlapping or retried scheduler run skips an already-applied change instead of billing it twice. Both the scheduled and the immediate plan-change paths now stamp a deterministic idempotency key on the proration invoice, so even a re-run that reached the billing call would dedupe against the unique invoice id rather than write a second charge. A regression test asserts a second apply pass records no additional invoice.
 
 - v0.4.61 (2026-06-19) — **Scheduled and dispatched sends no longer double-fire under concurrent ticks.** Closes a class of concurrency races in the scheduled-send and dispatch paths where a tick read a row, checked its status or schedule cursor in application code, and then performed the send (and its ledger write) before an unconditional update committed — so two overlapping ticks (a cron overrun, two workers, or a manual tick racing the schedule) could both pass the check and both send. Each path now claims the row with a single conditional update — flipping the status, or advancing the schedule cursor, only when the row is still in the expected state — and performs the send only when that claim wins; the losing tick changes zero rows and skips. The affected sends: an email campaign drain (the whole audience could be mailed twice), a queued push notification, a wishlist digest email and its sent-ledger row, a reorder reminder, a survey response record, and a dunning step's reminder email / subscription action. Behavior for a single (sequential) caller is unchanged; only the concurrent double-fire is removed. Where a send fails after the claim wins, the schedule cursor is rolled back so the row is retried on the next tick rather than skipped. **Fixed:** *Email campaign sends claim the campaign before draining* — sendNow, the scheduled dispatch tick, and the consent-gated broadcast drain now flip the campaign from scheduled to sending with a conditional update (WHERE slug = ? AND status = 'scheduled') and drain only when that update changes exactly one row. Previously the status check ran in application code before an unconditional flip, so two concurrent sends could both drain and mail the entire audience twice. The losing caller refuses (a typed send-race error) or, for the tick, skips the campaign. · *Push, wishlist-digest, and reorder-reminder ticks claim each row before sending* — Each per-row advance is now the atomic claim: a queued push notification advances to sent/failed only via WHERE id = ? AND status = 'queued'; a wishlist digest and a reorder reminder advance their schedule cursor with WHERE id = ? AND next_*_at = <the observed value>. The external send (and, for the digest, its sent-ledger row) runs only when the claim changes one row, so two overlapping ticks can't both dispatch the same row. A send that fails after winning the reminder claim rolls the cursor back so the row retries next tick. · *Survey responses and dunning steps gate their side-effect on an atomic claim* — Submitting a survey response now flips the invitation from issued to responded with WHERE id = ? AND status = 'issued' and inserts the response row only when that claim wins (a lost race returns a typed already-responded error), so a double-submit can't record two responses for one invitation. A dunning tick now claims the enrollment with WHERE id = ? AND status = 'active' AND next_action_at = <the observed value> before executing the step (the reminder email / in-app notification / pause or cancel), so overlapping dunning ticks can't send a step twice; the subsequent state transitions carry the same status guard.

package/lib/asset-manifest.json

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

package/lib/cart-bulk-ops.js

@@ -516,12 +516,23 @@ function create(opts) {
       // carts are not the shopper's working cart, they're scratch
       // carts for downstream fulfillment / split-order quoting).
       var ts = _now();
-      // Mark source abandoned first so the active-session index is
-      // free for any reuse.
-      await query(
-        "UPDATE carts SET status = 'abandoned', updated_at = ?1 WHERE id = ?2",
+      // Atomic claim: mark the source abandoned in a single
+      // conditional UPDATE that re-checks `status = 'active'` in its
+      // own WHERE. `_loadCart` read the status in JS, but two
+      // concurrent splitCart calls would both pass that check and
+      // both mint a full set of child carts (double-create). SQLite /
+      // D1 serializes writers, so exactly one of the racing UPDATEs
+      // flips active→abandoned (rowCount === 1) and earns the right
+      // to mint the children; the loser sees rowCount === 0 and
+      // refuses rather than producing a second set of child carts.
+      // This also frees the active-session index for any reuse.
+      var claim = await query(
+        "UPDATE carts SET status = 'abandoned', updated_at = ?1 WHERE id = ?2 AND status = 'active'",
         [ts, input.cart_id],
       );
+      if (Number(claim.rowCount || 0) !== 1) {
+        throw new TypeError("cartBulkOps.splitCart: cart " + input.cart_id + " already split/modified");
+      }
       var children = [];
       for (var gi = 0; gi < groupOrder.length; gi += 1) {
         var groupKey = groupOrder[gi];

package/lib/customer-impersonation.js

@@ -492,6 +492,20 @@ function create(opts) {
       if (!notifications) {
         return { notified: false, customer_notified_at: null };
       }
+
+      // Enqueue FIRST, then record the confirmation stamp — so
+      // `customer_notified_at` only ever means "the notice was
+      // successfully enqueued", never "claimed but the enqueue may have
+      // failed". A claim-before-enqueue stamp let a concurrent caller
+      // observe the provisional stamp and report `notified: true` while
+      // the winner's enqueue was still pending (and might then throw and
+      // roll the stamp back), silently dropping the privacy notice.
+      // Recording the stamp only on enqueue success closes that. A
+      // concurrent caller that also slipped past the null-check above may
+      // enqueue a second time; a duplicate "an operator viewed your
+      // account" notice is benign and strictly preferable to missing it,
+      // and the audit stamp still resolves to a single value.
+      var now = _now();
       await notifications.enqueue({
         recipient_id: existing.customer_id,
         channel:      "account-impersonation",
@@ -506,12 +520,21 @@ function create(opts) {
           expires_at:       Number(existing.expires_at),
         },
       });
-      var now = _now();
+
+      // Stamp the confirmation idempotently — the first writer to land
+      // wins (WHERE customer_notified_at IS NULL); a concurrent second
+      // caller's UPDATE matches zero rows and returns the already-
+      // recorded stamp. An enqueue throw above propagates before this,
+      // leaving the row un-stamped so a retry re-attempts delivery.
       await query(
-        "UPDATE impersonations SET customer_notified_at = ?1 WHERE id = ?2",
+        "UPDATE impersonations SET customer_notified_at = ?1 " +
+        "WHERE id = ?2 AND customer_notified_at IS NULL",
         [now, id],
       );
-      return { notified: true, customer_notified_at: now };
+      var stampedRow = await _getRow(id);
+      var stampedAt  = stampedRow && stampedRow.customer_notified_at != null
+        ? Number(stampedRow.customer_notified_at) : now;
+      return { notified: true, customer_notified_at: stampedAt };
     },
 
     // ---- listForOperator ------------------------------------------------

package/lib/customer-merge.js

@@ -693,26 +693,70 @@ function create(opts) {
         throw drErr;
       }
 
-      // Commit every reparent.
-      var actual = await _reparentAll(row.source_customer_id, row.target_customer_id);
-
-      // Archive the source customer + insert the redirect marker.
-      await customers.archiveCustomer(row.source_customer_id);
+      // Atomically CLAIM the proposed->executed transition BEFORE
+      // running any exactly-once side effect. SQLite serializes
+      // writers, so this conditional UPDATE is the race-free claim:
+      // two concurrent executeMerge calls on the same proposed row
+      // both pass the JS status check above, but only one lands
+      // rowCount===1 here — the loser sees rowCount 0 and bails out
+      // returning the now-executed row, so the reparent / archive /
+      // redirect-insert fire exactly once.
       var ts = _now();
-      await query(
-        "INSERT INTO customer_merge_redirects " +
-        "(source_customer_id, target_customer_id, merge_id, executed_at) " +
-        "VALUES (?1, ?2, ?3, ?4)",
-        [row.source_customer_id, row.target_customer_id, mergeId, ts],
+      var claim = await query(
+        "UPDATE customer_merges SET status = 'executed', " +
+        "executed_at = ?1, executed_by = ?2 WHERE id = ?3 AND status = 'proposed'",
+        [ts, executedBy, mergeId],
       );
+      if (Number(claim.rowCount || 0) !== 1) {
+        // 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.
+        var current = await _getMergeRow(mergeId);
+        if (current && current.status === "executed") {
+          return _hydrateMerge(current);
+        }
+        var raceErr = new Error("customerMerge.executeMerge: merge_id " + mergeId +
+          " is no longer proposed, only proposed merges can be executed");
+        raceErr.code = "CUSTOMER_MERGE_NOT_PROPOSED";
+        throw raceErr;
+      }
 
-      // Land the merge in executed; freeze the actual reparent
-      // counts on plan_json so rollback has the exact footprint.
+      // Claim won — now run the exactly-once side effects. If any
+      // throws, REVERT the claim (self-targeting the row we just
+      // flipped) so the merge isn't stranded in 'executed' with the
+      // reparents only partially applied; then rethrow.
+      var actual;
+      try {
+        // Commit every reparent.
+        actual = await _reparentAll(row.source_customer_id, row.target_customer_id);
+
+        // Archive the source customer + insert the redirect marker.
+        await customers.archiveCustomer(row.source_customer_id);
+        await query(
+          "INSERT INTO customer_merge_redirects " +
+          "(source_customer_id, target_customer_id, merge_id, executed_at) " +
+          "VALUES (?1, ?2, ?3, ?4)",
+          [row.source_customer_id, row.target_customer_id, mergeId, ts],
+        );
+      } catch (sideErr) {
+        await query(
+          "UPDATE customer_merges SET status = 'proposed', " +
+          "executed_at = NULL, executed_by = NULL WHERE id = ?1 AND status = 'executed'",
+          [mergeId],
+        );
+        throw sideErr;
+      }
+
+      // Freeze the actual reparent counts on plan_json so rollback
+      // has the exact footprint. Status / executed_at / executed_by
+      // already landed in the claim above.
       var sealed = Object.assign({}, capturedPlan, { actual: actual });
+      // Gate on still-'executed' so this metadata seal can't land on a
+      // row a concurrent rollback (now allowed once the redirect exists)
+      // has already flipped to 'rolled_back'.
       await query(
-        "UPDATE customer_merges SET status = 'executed', plan_json = ?1, " +
-        "executed_at = ?2, executed_by = ?3 WHERE id = ?4",
-        [JSON.stringify(sealed), ts, executedBy, mergeId],
+        "UPDATE customer_merges SET plan_json = ?1 WHERE id = ?2 AND status = 'executed'",
+        [JSON.stringify(sealed), mergeId],
       );
       return _hydrateMerge(await _getMergeRow(mergeId));
     },
@@ -743,6 +787,8 @@ function create(opts) {
         throw stErr;
       }
       var now = _now();
+      // Keep the in-window check BEFORE the claim — a past-window
+      // merge must refuse without flipping status.
       if (now - Number(row.executed_at) > ROLLBACK_WINDOW_MS) {
         var winErr = new Error("customerMerge.rollbackMerge: merge_id " + mergeId +
           " executed " + Math.floor((now - Number(row.executed_at)) / C.TIME.days(1)) +
@@ -752,21 +798,56 @@ function create(opts) {
         throw winErr;
       }
 
-      // Reverse every reparent (target -> source).
-      await _reparentAll(row.target_customer_id, row.source_customer_id);
-
-      // Restore the source customer + drop the redirect marker.
-      await customers.restoreCustomer(row.source_customer_id);
-      await query(
-        "DELETE FROM customer_merge_redirects WHERE source_customer_id = ?1",
-        [row.source_customer_id],
-      );
-
-      await query(
+      // Atomically CLAIM the executed->rolled_back transition BEFORE
+      // running the reverse reparent / restore / redirect-delete.
+      // The conditional UPDATE is the race-free guard: two concurrent
+      // rollbackMerge calls both pass the JS status + window checks,
+      // but only one lands rowCount===1 here — the loser bails out so
+      // the reverse side effects fire exactly once.
+      // Gate the claim on the redirect row EXISTING. executeMerge flips
+      // status to 'executed' BEFORE its reparent/archive complete and
+      // inserts the redirect as its LAST side effect, so the redirect's
+      // presence is the proof that the reparent + archive are durable.
+      // Without this gate a rollback racing an in-flight execute (status
+      // already 'executed', reparents not yet done) would flip to
+      // 'rolled_back' and reverse nothing. If the redirect isn't there
+      // yet the merge is still finalizing — refuse so the caller retries.
+      var claim = await query(
         "UPDATE customer_merges SET status = 'rolled_back', " +
-        "rolled_back_at = ?1, rollback_reason = ?2 WHERE id = ?3",
-        [now, reason, mergeId],
+        "rolled_back_at = ?1, rollback_reason = ?2 WHERE id = ?3 AND status = 'executed' " +
+        "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) {
+        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";
+        throw raceErr;
+      }
+
+      // Claim won — now run the reverse side effects. If any throws,
+      // REVERT the claim (self-targeting the row we just flipped) so
+      // the merge isn't stranded in 'rolled_back' with the reparents
+      // only partially reversed; then rethrow.
+      try {
+        // Reverse every reparent (target -> source).
+        await _reparentAll(row.target_customer_id, row.source_customer_id);
+
+        // Restore the source customer + drop the redirect marker.
+        await customers.restoreCustomer(row.source_customer_id);
+        await query(
+          "DELETE FROM customer_merge_redirects WHERE source_customer_id = ?1",
+          [row.source_customer_id],
+        );
+      } catch (sideErr) {
+        await query(
+          "UPDATE customer_merges SET status = 'executed', " +
+          "rolled_back_at = NULL, rollback_reason = NULL WHERE id = ?1 AND status = 'rolled_back'",
+          [mergeId],
+        );
+        throw sideErr;
+      }
+
       return _hydrateMerge(await _getMergeRow(mergeId));
     },
 

package/lib/order-exchanges.js

@@ -286,28 +286,59 @@ function create(opts) {
       }
       _assertTransition(existing.status, "approveExchange");
 
-      // Pin the replacement shelf BEFORE flipping the DB row. A
-      // hold failure (insufficient stock, unknown location)
-      // surfaces to the caller; the row stays pending so the next
-      // operator attempt decides whether to retry, source from a
-      // different shelf, or reject the exchange.
-      if (invAllocs) {
-        await invAllocs.holdForCart({
-          cart_id:    existing.id,
-          sku:        existing.replacement_sku,
-          variant_id: existing.replacement_variant_id || null,
-          quantity:   existing.replacement_qty,
-          // allow:raw-time-literal — hold TTL in SECONDS (passed to holdForCart's ttl_seconds); C.TIME returns ms
-          ttl_seconds: input.hold_ttl_seconds || 86400,
-        });
-      }
-
+      // Claim pending -> approved ATOMICALLY before the inventory
+      // hold. The conditional WHERE (status = 'pending') is the
+      // serialization point: two operators racing the same exchange
+      // both pass the JS _assertTransition above, but only the writer
+      // whose UPDATE matches a still-pending row wins (rowCount === 1).
+      // The loser's UPDATE matches zero rows -> it refuses here and
+      // never opens a duplicate hold. Without this, both callers would
+      // reach holdForCart and pin the replacement SKU twice.
       var ts = _monotonicTs();
-      await query(
+      var claim = await query(
         "UPDATE order_exchanges SET status = 'approved', approver_id = ?1, updated_at = ?2 " +
-        "WHERE id = ?3",
+        "WHERE id = ?3 AND status = 'pending'",
         [approverId, ts, exchangeId],
       );
+      if (Number(claim.rowCount || 0) !== 1) {
+        var refused = new Error(
+          "order-exchanges: transition 'approveExchange' refused from state '" +
+          existing.status + "' (lost the race to a concurrent transition)"
+        );
+        refused.code = "EXCHANGE_TRANSITION_REFUSED";
+        throw refused;
+      }
+
+      // Pin the replacement shelf AFTER winning the claim. A hold
+      // failure (insufficient stock, unknown location) surfaces to the
+      // caller; we revert the claim back to pending so the next
+      // operator attempt decides whether to retry, source from a
+      // different shelf, or reject the exchange — the row is never
+      // stranded in `approved` without a hold.
+      if (invAllocs) {
+        try {
+          await invAllocs.holdForCart({
+            cart_id:    existing.id,
+            sku:        existing.replacement_sku,
+            variant_id: existing.replacement_variant_id || null,
+            quantity:   existing.replacement_qty,
+            // allow:raw-time-literal — hold TTL in SECONDS (passed to holdForCart's ttl_seconds); C.TIME returns ms
+            ttl_seconds: input.hold_ttl_seconds || 86400,
+          });
+        } catch (holdErr) {
+          // Self-targeting revert: only un-claim the row WE just
+          // claimed (status still 'approved'). A concurrent follow-on
+          // transition that already moved the row off `approved` is
+          // left untouched.
+          await query(
+            "UPDATE order_exchanges SET status = 'pending', approver_id = NULL, updated_at = ?1 " +
+            "WHERE id = ?2 AND status = 'approved'",
+            [_monotonicTs(), exchangeId],
+          );
+          throw holdErr;
+        }
+      }
+
       return await _getRow(exchangeId);
     },
 

package/lib/pick-lists.js

@@ -548,31 +548,69 @@ function create(opts) {
         }
         perOrder[oid].push(list.lines[k]);
       }
-      var shipments = [];
-      for (var m = 0; m < orderSeq.length; m += 1) {
-        var ord = orderSeq[m];
-        // A picked-from-shelf parcel has no carrier yet — the operator
-        // assigns one when they hand it off. orderTracking's carrier enum
-        // doesn't carry a "pickup" / "none" value, so the parcel rides the
-        // 'other' escape hatch with a "pickup" label until a real carrier
-        // is recorded against it (the operator updates the shipment, or a
-        // shipping-label record supplies the carrier).
-        var s = await orderTracking.createShipment({
-          order_id:           ord,
-          carrier:            "other",
-          carrier_other_name: "pickup",
-          notes:              "pick-list:" + listId,
-        });
-        shipments.push({
-          order_id:    ord,
-          shipment_id: s.id,
-        });
-      }
+
+      // Atomically claim completion BEFORE fanning out any shipment.
+      // The JS status check above is necessary (it produces the
+      // operator-facing "list is <status>" refusal) but NOT sufficient:
+      // two concurrent markListComplete callers both read 'in_progress'
+      // and would each run the createShipment loop, double-creating one
+      // shipment per parent order. The conditional UPDATE — guarded by
+      // the same precondition in its own WHERE — is the atomic claim
+      // (SQLite/D1 serializes writers, so exactly one UPDATE matches a
+      // row in an eligible state). The loser sees rowCount===0 and
+      // refuses; only the winner proceeds to createShipment.
       var ts = _now();
-      await query(
-        "UPDATE pick_lists SET status = 'complete', completed_at = ?1 WHERE id = ?2",
+      var claim = await query(
+        "UPDATE pick_lists SET status = 'complete', completed_at = ?1 " +
+        "WHERE id = ?2 AND status IN ('generated', 'in_progress')",
         [ts, listId],
       );
+      if (Number(claim.rowCount || 0) !== 1) {
+        // Lost the race (or the row left an eligible state between the
+        // read and the claim). Surface the same terminal-state refusal
+        // a sequential caller would see — the shipments belong to the
+        // caller that won the claim.
+        throw new TypeError("pick-lists.markListComplete: list is no longer " +
+          "generated or in_progress (already completed or cancelled by a concurrent caller)");
+      }
+
+      var shipments = [];
+      try {
+        for (var m = 0; m < orderSeq.length; m += 1) {
+          var ord = orderSeq[m];
+          // A picked-from-shelf parcel has no carrier yet — the operator
+          // assigns one when they hand it off. orderTracking's carrier enum
+          // doesn't carry a "pickup" / "none" value, so the parcel rides the
+          // 'other' escape hatch with a "pickup" label until a real carrier
+          // is recorded against it (the operator updates the shipment, or a
+          // shipping-label record supplies the carrier).
+          var s = await orderTracking.createShipment({
+            order_id:           ord,
+            carrier:            "other",
+            carrier_other_name: "pickup",
+            notes:              "pick-list:" + listId,
+          });
+          shipments.push({
+            order_id:    ord,
+            shipment_id: s.id,
+          });
+        }
+      } catch (e) {
+        // The side-effect threw after the claim landed. Revert the claim
+        // (self-targeting WHERE so we only undo a row WE moved to
+        // 'complete') so the list isn't stranded terminal with a
+        // partial / zero shipment fan-out — the operator can retry once
+        // the createShipment fault clears.
+        try {
+          await query(
+            "UPDATE pick_lists SET status = ?1, completed_at = NULL " +
+            "WHERE id = ?2 AND status = 'complete'",
+            [list.status, listId],
+          );
+        } catch (_e) { /* drop-silent — the original createShipment error is what the operator needs */ }
+        throw e;
+      }
+
       var hydrated = await _getHydrated(listId);
       hydrated.shipments = shipments;
       return hydrated;

package/lib/preorder.js

@@ -245,29 +245,67 @@ function create(opts) {
   // order surface they used). The per-campaign counter is NOT
   // decremented on conversion — the reserved capacity is consumed by
   // the order, not freed.
+  //
+  // Returns `{ won: <bool>, orderId }`. `won` is false when the
+  // conditional claim lost the race (the row was already flipped out
+  // of 'active' by a concurrent converter) — the caller skips the
+  // exactly-once side-effect for that row.
+  //
+  // Concurrency: the status flip is the atomic claim and runs FIRST,
+  // gated by `AND status = 'active'`, so two concurrent converters
+  // can't both mint an order for the same reservation. SQLite
+  // serialises writers, so exactly one UPDATE matches; the loser sees
+  // rowCount 0 and bails without calling `createFromCart`. When the
+  // order side-effect throws after the claim, the claim is reverted
+  // (self-targeting `WHERE id=? AND status='converted'`) so the row
+  // isn't stranded in 'converted' with no backing order.
   async function _convertOne(reservation, campaign, ts) {
+    var claim = await query(
+      "UPDATE preorder_reservations SET status = 'converted', converted_at = ?1 " +
+      "WHERE id = ?2 AND status = 'active'",
+      [ts, reservation.id],
+    );
+    if (Number(claim.rowCount || 0) !== 1) {
+      // Lost the race — a concurrent converter already claimed this
+      // reservation. Skip the side-effect; the winner mints the order.
+      return { won: false, orderId: null };
+    }
     var convertedOrderId = null;
     if (orderHandle) {
-      var orderResult = await orderHandle.createFromCart({
-        customer_id: reservation.customer_id,
-        lines: [{
-          sku:             campaign.sku,
-          variant_id:      campaign.variant_id,
-          quantity:        reservation.quantity,
-          unit_price_minor: campaign.full_price_minor,
-          currency:        campaign.currency,
-        }],
-        preorder_reservation_id: reservation.id,
-        preorder_campaign_slug:  campaign.slug,
-      });
+      var orderResult;
+      try {
+        orderResult = await orderHandle.createFromCart({
+          customer_id: reservation.customer_id,
+          lines: [{
+            sku:             campaign.sku,
+            variant_id:      campaign.variant_id,
+            quantity:        reservation.quantity,
+            unit_price_minor: campaign.full_price_minor,
+            currency:        campaign.currency,
+          }],
+          preorder_reservation_id: reservation.id,
+          preorder_campaign_slug:  campaign.slug,
+        });
+      } catch (e) {
+        // The order create failed after we claimed the row — revert
+        // the claim so the reservation returns to 'active' and a retry
+        // (or the next launch sweep) can convert it cleanly.
+        await query(
+          "UPDATE preorder_reservations SET status = 'active', converted_at = NULL " +
+          "WHERE id = ?1 AND status = 'converted'",
+          [reservation.id],
+        );
+        throw e;
+      }
       convertedOrderId = orderResult && orderResult.id ? orderResult.id : null;
     }
+    // Backfill the order id onto the already-claimed row.
     await query(
-      "UPDATE preorder_reservations SET status = 'converted', converted_at = ?1, " +
-      "converted_order_id = ?2 WHERE id = ?3 AND status = 'active'",
-      [ts, convertedOrderId, reservation.id],
+      "UPDATE preorder_reservations SET converted_order_id = ?1 " +
+      "WHERE id = ?2 AND status = 'converted'",
+      [convertedOrderId, reservation.id],
     );
-    return convertedOrderId;
+    return { won: true, orderId: convertedOrderId };
   }
 
   return {
@@ -369,6 +407,15 @@ function create(opts) {
         throw new TypeError("preorder.reserve: campaign is " + campaign.status +
           ", only active campaigns accept reservations");
       }
+      // The JS cap pre-check below stays for a precise, friendly error
+      // message on the common (uncontended) path — but it is NOT the
+      // guard. Two concurrent reserves could both pass this read-time
+      // check against the same `units_reserved` and both insert,
+      // overshooting `max_units_available` (oversell). The ATOMIC guard
+      // is the conditional increment further down: the cap is folded
+      // into the UPDATE's WHERE so the increment only applies when it
+      // stays within the cap, and SQLite serialises the two writers so
+      // exactly one wins.
       if (campaign.max_units_available !== null && campaign.max_units_available !== undefined) {
         if (campaign.units_reserved + input.quantity > campaign.max_units_available) {
           throw new TypeError("preorder.reserve: would exceed max_units_available " +
@@ -378,23 +425,46 @@ function create(opts) {
       }
 
       var ts = _now();
+      // Claim capacity FIRST via a conditional increment that gates on
+      // the cap inside its own WHERE. rowCount 0 means the cap would be
+      // exceeded (or the campaign vanished) — refuse before writing any
+      // reservation row, so the counter never overshoots the cap under
+      // concurrency.
+      var claim = await query(
+        "UPDATE preorder_campaigns SET units_reserved = units_reserved + ?1, updated_at = ?2 " +
+        "WHERE slug = ?3 AND status = 'active' " +
+        "AND (max_units_available IS NULL OR units_reserved + ?1 <= max_units_available)",
+        [input.quantity, ts, input.campaign_slug],
+      );
+      if (Number(claim.rowCount || 0) !== 1) {
+        throw new TypeError("preorder.reserve: would exceed max_units_available " +
+          "(cap=" + campaign.max_units_available + ", reserved=" + campaign.units_reserved +
+          ", requested=" + input.quantity + ")");
+      }
       // Pass the monotonic ts into uuid.v7 so the 48-bit timestamp
       // prefix is strictly increasing across consecutive reservations
       // — the (id) keyset cursor used by reservationsForCustomer is
       // monotonic without depending on Date.now() ticking between
       // calls.
       var id = b.uuid.v7({ now: ts });
-      await query(
-        "INSERT INTO preorder_reservations (id, campaign_slug, customer_id, quantity, " +
-        "payment_intent_id, status, reservation_at) " +
-        "VALUES (?1, ?2, ?3, ?4, ?5, 'active', ?6)",
-        [id, input.campaign_slug, input.customer_id, input.quantity, paymentIntentId, ts],
-      );
-      await query(
-        "UPDATE preorder_campaigns SET units_reserved = units_reserved + ?1, updated_at = ?2 " +
-        "WHERE slug = ?3",
-        [input.quantity, ts, input.campaign_slug],
-      );
+      try {
+        await query(
+          "INSERT INTO preorder_reservations (id, campaign_slug, customer_id, quantity, " +
+          "payment_intent_id, status, reservation_at) " +
+          "VALUES (?1, ?2, ?3, ?4, ?5, 'active', ?6)",
+          [id, input.campaign_slug, input.customer_id, input.quantity, paymentIntentId, ts],
+        );
+      } catch (e) {
+        // The reservation insert failed after we claimed capacity —
+        // compensate by releasing the units we reserved so the counter
+        // doesn't strand capacity the customer never got.
+        await query(
+          "UPDATE preorder_campaigns SET units_reserved = MAX(0, units_reserved - ?1), " +
+          "updated_at = ?2 WHERE slug = ?3",
+          [input.quantity, _now(), input.campaign_slug],
+        );
+        throw e;
+      }
       return await _getReservation(id);
     },
 
@@ -447,11 +517,24 @@ function create(opts) {
           ", only active reservations can be cancelled");
       }
       var ts = _now();
-      await query(
+      // Claim the cancel atomically, gated on `status = 'active'`. The
+      // JS check above is advisory; this conditional UPDATE is the
+      // guard. Two concurrent cancels of the same reservation would
+      // otherwise both pass the JS check and both decrement the
+      // counter — double-freeing capacity. SQLite serialises writers,
+      // so exactly one UPDATE matches; the loser sees rowCount 0 and
+      // refuses WITHOUT decrementing, so the counter stays correct.
+      var claim = await query(
         "UPDATE preorder_reservations SET status = 'cancelled', cancelled_at = ?1, " +
-        "cancel_reason = ?2 WHERE id = ?3",
+        "cancel_reason = ?2 WHERE id = ?3 AND status = 'active'",
         [ts, reason, reservation.id],
       );
+      if (Number(claim.rowCount || 0) !== 1) {
+        throw new TypeError("preorder.cancelReservation: reservation " +
+          JSON.stringify(reservation.id) + " was already cancelled or converted concurrently");
+      }
+      // Only the winner of the claim frees capacity. MAX(0, …) clamps
+      // the counter against out-of-band corruption.
       await query(
         "UPDATE preorder_campaigns SET units_reserved = MAX(0, units_reserved - ?1), " +
         "updated_at = ?2 WHERE slug = ?3",
@@ -484,10 +567,18 @@ function create(opts) {
           JSON.stringify(reservation.campaign_slug) + " not found");
       }
       var ts = _now();
-      var orderId = await _convertOne(reservation, campaign, ts);
+      // `_convertOne` does the atomic claim internally. If a concurrent
+      // converter beat us to this reservation we lose the race and
+      // refuse — the JS `status === "active"` check above is advisory;
+      // the conditional UPDATE is the real guard.
+      var outcome = await _convertOne(reservation, campaign, ts);
+      if (!outcome.won) {
+        throw new TypeError("preorder.convertReservationToOrder: reservation " +
+          JSON.stringify(reservation.id) + " was already converted concurrently");
+      }
       return {
         reservation_id:     reservation.id,
-        converted_order_id: orderId,
+        converted_order_id: outcome.orderId,
         status:             "converted",
       };
     },
@@ -516,22 +607,54 @@ function create(opts) {
         throw new TypeError("preorder.launchCampaign: now (" + input.now +
           ") is before launch_at (" + campaign.launch_at + ")");
       }
+      var ts = _now();
+      // Claim the campaign FIRST, gated on `status = 'active'`. The JS
+      // status check above is advisory; this conditional UPDATE is the
+      // atomic guard. SQLite serialises writers, so exactly one of two
+      // concurrent launches matches — the loser sees rowCount 0 and
+      // refuses, so the reservation-conversion sweep below runs at most
+      // once for the campaign. (Each individual reservation is ALSO
+      // claim-guarded inside `_convertOne`, so even a torn interleave
+      // can't double-mint an order.)
+      var claim = await query(
+        "UPDATE preorder_campaigns SET status = 'launched', launched_at = ?1, updated_at = ?1 " +
+        "WHERE slug = ?2 AND status = 'active'",
+        [ts, input.slug],
+      );
+      if (Number(claim.rowCount || 0) !== 1) {
+        throw new TypeError("preorder.launchCampaign: campaign " +
+          JSON.stringify(input.slug) + " was already launched concurrently");
+      }
       var activeRows = (await query(
         "SELECT * FROM preorder_reservations WHERE campaign_slug = ?1 AND status = 'active' " +
         "ORDER BY id ASC",
         [input.slug],
       )).rows;
-      var ts = _now();
       var converted = [];
-      for (var i = 0; i < activeRows.length; i += 1) {
-        var orderId = await _convertOne(activeRows[i], campaign, ts);
-        converted.push({ reservation_id: activeRows[i].id, converted_order_id: orderId });
+      try {
+        for (var i = 0; i < activeRows.length; i += 1) {
+          var outcome = await _convertOne(activeRows[i], campaign, ts);
+          // A reservation cancelled/converted out-of-band between the
+          // SELECT and the per-row claim is skipped silently — it's no
+          // longer 'active', so it isn't ours to convert.
+          if (outcome.won) {
+            converted.push({ reservation_id: activeRows[i].id, converted_order_id: outcome.orderId });
+          }
+        }
+      } catch (convErr) {
+        // A conversion threw mid-sweep. Revert the campaign claim back to
+        // 'active' so a retry can re-launch and pick up the reservations
+        // still left active (the ones already converted stay converted —
+        // _convertOne skips non-active rows on the retry). Without this
+        // the campaign is stranded 'launched' and the unconverted
+        // reservations can never be swept into orders.
+        await query(
+          "UPDATE preorder_campaigns SET status = 'active', launched_at = NULL, updated_at = ?1 " +
+          "WHERE slug = ?2 AND status = 'launched'",
+          [_now(), input.slug],
+        );
+        throw convErr;
       }
-      await query(
-        "UPDATE preorder_campaigns SET status = 'launched', launched_at = ?1, updated_at = ?1 " +
-        "WHERE slug = ?2",
-        [ts, input.slug],
-      );
       return {
         slug:              input.slug,
         launched_at:       ts,

package/lib/print-queue.js

@@ -437,12 +437,28 @@ function create(opts) {
           JSON.stringify(input.station_id));
       }
       var ts = _now();
-      await query(
+      // The in_progress -> failed transition IS the atomic claim: gate
+      // it on `status = 'in_progress'` in the WHERE so two concurrent
+      // markFailed callers (e.g. an operator retry plus an automated
+      // jam-detector) can't both win the JS check above and both fire
+      // the retry INSERT below. SQLite serializes writers, so exactly
+      // one UPDATE flips the row; the loser sees rowCount === 0 and
+      // returns the already-failed state WITHOUT re-requeueing —
+      // otherwise a single failure could mint two duplicate queued
+      // jobs (double-print).
+      var upd = await query(
         "UPDATE print_jobs SET status = 'failed', failed_at = ?1, fail_reason = ?2 " +
-        "WHERE id = ?3",
+        "WHERE id = ?3 AND status = 'in_progress'",
         [ts, reason, jobId],
       );
       var failed = await _getRow(jobId);
+      if (Number(upd.rowCount || 0) !== 1) {
+        // Another caller already transitioned this job out of
+        // in_progress. Return its current state; do not re-insert a
+        // retry row (that's the exactly-once side-effect we're
+        // protecting).
+        return { failed: failed };
+      }
       var out = { failed: failed };
 
       if (retry) {

package/lib/purchase-orders.js

@@ -599,17 +599,103 @@ function create(opts) {
         }
       }
 
-      // Compose inventoryReceive.draft + apply BEFORE advancing the
-      // PO counters. If the catalog refuses (unknown SKU, decimal
-      // qty, etc.) the PO state stays consistent with the catalog —
-      // a half-applied receipt across two writeable surfaces is the
-      // worst-case for reconciliation. The receipt primitive's draft
-      // step requires a unique `reference`; when the caller didn't
-      // supply one, derive a deterministic-per-call value from the
-      // PO id + occurrence timestamp so two recordPartialReceipt
-      // calls on the same PO produce distinct receipt rows.
-      var ts = _now();
+      var ts          = _now();
+      var priorStatus = current.status;
+
+      // Claim the receipt atomically by advancing the per-line
+      // counters BEFORE composing the inventoryReceive restock — the
+      // line counter is the true exactly-once gate here. A PO-level
+      // status claim can't serialize two concurrent receipts on its
+      // own: 'partially_received' is both a legal source AND a legal
+      // destination (a partial receipt that leaves the PO still
+      // partial is a status self-loop), so a status-only WHERE matches
+      // for both racers. Instead each line increment is guarded by the
+      // exact prior quantity the caller observed AND the ordered cap:
+      //   SET quantity_received = quantity_received + addQ
+      //   WHERE id = lineId
+      //     AND quantity_received = observedPrior   -- optimistic CAS
+      //     AND quantity_received + addQ <= quantity_ordered  -- cap
+      // Two concurrent receipts both observe prior=P; the winner's
+      // increment lands (P -> P+addQ), the loser's `= P` no longer
+      // matches (the row now reads P+addQ) so its rowCount is 0 — it
+      // refuses, and the restock + counter advance run for exactly one
+      // caller. The cap clause also makes over-receipt a hard refusal
+      // at write time, not just at the JS pre-flight above.
+      var claimed = [];
+      for (var c = 0; c < rxSkus.length; c += 1) {
+        var cLine  = skuToLine[rxSkus[c]];
+        var cRxe   = rxMap[rxSkus[c]];
+        var cPrior = Number(cLine.quantity_received || 0);
+        var cAdd   = cRxe.quantity_received;
+        var lineClaim;
+        if (cRxe.unit_cost_minor != null) {
+          lineClaim = await query(
+            "UPDATE purchase_order_lines SET quantity_received = quantity_received + ?1, " +
+            "unit_cost_minor = ?2, updated_at = ?3 " +
+            "WHERE id = ?4 AND quantity_received = ?5 AND quantity_received + ?1 <= quantity_ordered",
+            [cAdd, cRxe.unit_cost_minor, ts, cLine.id, cPrior],
+          );
+        } else {
+          lineClaim = await query(
+            "UPDATE purchase_order_lines SET quantity_received = quantity_received + ?1, " +
+            "updated_at = ?2 " +
+            "WHERE id = ?3 AND quantity_received = ?4 AND quantity_received + ?1 <= quantity_ordered",
+            [cAdd, ts, cLine.id, cPrior],
+          );
+        }
+        if (Number(lineClaim.rowCount || 0) !== 1) {
+          // Lost the race on this line (a concurrent receipt already
+          // advanced it past the value we observed) — roll back the
+          // line claims we already won this call, self-targeting the
+          // exact amount each added so a concurrent winner isn't
+          // clobbered, then refuse. No restock has fired yet.
+          for (var rb = 0; rb < claimed.length; rb += 1) {
+            if (claimed[rb].costChanged) {
+              await query(
+                "UPDATE purchase_order_lines SET quantity_received = quantity_received - ?1, " +
+                "unit_cost_minor = ?2, updated_at = ?3 WHERE id = ?4 AND quantity_received >= ?1",
+                [claimed[rb].add, claimed[rb].priorCost, ts, claimed[rb].id],
+              );
+            } else {
+              await query(
+                "UPDATE purchase_order_lines SET quantity_received = quantity_received - ?1, updated_at = ?2 " +
+                "WHERE id = ?3 AND quantity_received >= ?1",
+                [claimed[rb].add, ts, claimed[rb].id],
+              );
+            }
+          }
+          var lost = new Error("purchase-orders.recordPartialReceipt: refused — PO " +
+            poId + " line for sku " + JSON.stringify(rxSkus[c]) +
+            " changed under us (receipt recorded by a concurrent call)");
+          lost.code = "PO_TRANSITION_REFUSED";
+          throw lost;
+        }
+        claimed.push({
+          id: cLine.id, add: cAdd,
+          // Capture whether this claim overwrote unit_cost_minor and its
+          // prior value, so a rollback can restore the cost — not just
+          // the quantity — when no stock ends up landing.
+          costChanged: cRxe.unit_cost_minor != null,
+          priorCost:   cLine.unit_cost_minor,
+        });
+      }
+
+      // From here the line claims are held. Any throw past this point
+      // must release them (self-targeting subtraction) so the PO isn't
+      // stranded with advanced counters but no restock landed.
       var receiptResult = null;
+      try {
+
+      // Compose inventoryReceive.draft + apply for the winner. If the
+      // catalog refuses (unknown SKU, decimal qty, etc.) the rollback
+      // below releases the line claims so the PO state stays
+      // consistent with the catalog — a half-applied receipt across
+      // two writeable surfaces is the worst-case for reconciliation.
+      // The receipt primitive's draft step requires a unique
+      // `reference`; when the caller didn't supply one, derive a
+      // deterministic-per-call value from the PO id + occurrence
+      // timestamp so two recordPartialReceipt calls on the same PO
+      // produce distinct receipt rows.
       if (receiveHandle) {
         var receiptRef = reference != null
           ? reference
@@ -645,33 +731,18 @@ function create(opts) {
         };
       }
 
-      // Now advance the PO counters. The pre-flight cap above
-      // guarantees no over-receipt; the inventoryReceive composition
-      // (if wired) has already landed without throwing.
-      for (var v = 0; v < rxSkus.length; v += 1) {
-        var line2  = skuToLine[rxSkus[v]];
-        var rxe2   = rxMap[rxSkus[v]];
-        var newQty = Number(line2.quantity_received || 0) + rxe2.quantity_received;
-        if (rxe2.unit_cost_minor != null) {
-          await query(
-            "UPDATE purchase_order_lines SET quantity_received = ?1, " +
-            "unit_cost_minor = ?2, updated_at = ?3 WHERE id = ?4",
-            [newQty, rxe2.unit_cost_minor, ts, line2.id],
-          );
-        } else {
-          await query(
-            "UPDATE purchase_order_lines SET quantity_received = ?1, updated_at = ?2 WHERE id = ?3",
-            [newQty, ts, line2.id],
-          );
-        }
-      }
-
-      // Recompute the PO-level status from the now-current line
-      // state. The status transition only flips forward (no
-      // 'received' -> 'partially_received' regression).
+      // The line counters were already advanced by the claim loop
+      // above (the SET quantity_received = quantity_received + addQ
+      // increment); no further per-line write is needed. Recompute the
+      // PO-level status from the now-current line state and flip it
+      // forward (any-received -> partially_received, every-line-full ->
+      // received). The status read is from the freshest line state so a
+      // concurrent winner that advanced a different line is reflected;
+      // the transition only moves forward (no received -> partial
+      // regression).
       var updatedLines = await _getLinesRaw(poId);
-      var nextStatus   = _statusAfterReceipt(updatedLines, current.status);
-      if (nextStatus !== current.status) {
+      var nextStatus   = _statusAfterReceipt(updatedLines, priorStatus);
+      if (nextStatus !== priorStatus) {
         await query(
           "UPDATE purchase_orders SET status = ?1, updated_at = ?2 WHERE id = ?3",
           [nextStatus, ts, poId],
@@ -683,6 +754,30 @@ function create(opts) {
         );
       }
 
+      } catch (e) {
+        // A step after the line claims threw (catalog refusal). Release
+        // every line claim this call won, self-targeting the exact
+        // amount each added (guarded by `>= add` so a concurrent winner
+        // that advanced the line further isn't clobbered) so the PO
+        // isn't stranded with advanced counters but no restock landed.
+        for (var rk = 0; rk < claimed.length; rk += 1) {
+          if (claimed[rk].costChanged) {
+            await query(
+              "UPDATE purchase_order_lines SET quantity_received = quantity_received - ?1, " +
+              "unit_cost_minor = ?2, updated_at = ?3 WHERE id = ?4 AND quantity_received >= ?1",
+              [claimed[rk].add, claimed[rk].priorCost, ts, claimed[rk].id],
+            );
+          } else {
+            await query(
+              "UPDATE purchase_order_lines SET quantity_received = quantity_received - ?1, updated_at = ?2 " +
+              "WHERE id = ?3 AND quantity_received >= ?1",
+              [claimed[rk].add, ts, claimed[rk].id],
+            );
+          }
+        }
+        throw e;
+      }
+
       var hydrated = await _hydrated(poId);
       hydrated.receipt = receiptResult;
       return hydrated;

package/lib/split-shipments.js

@@ -603,26 +603,67 @@ function create(opts) {
       }
 
       var hydrated = _hydratePlan(row);
+      var ts = _now();
+      // Atomic claim BEFORE any shipment is created. The JS status
+      // check above is racy: two concurrent callers both read a
+      // `proposed` row and both fall through to createShipment,
+      // double-creating shipments. The conditional UPDATE is the real
+      // gate — SQLite serializes writers, so exactly one caller flips
+      // proposed → executed and gets rowCount === 1; the loser sees 0
+      // and refuses without touching orderTracking.
+      var claim = await query(
+        "UPDATE split_shipment_plans SET status = 'executed', executed_at = ?1 " +
+        "WHERE id = ?2 AND status = 'proposed'",
+        [ts, input.plan.id],
+      );
+      if (Number(claim.rowCount || 0) !== 1) {
+        // Lost the race (or the row was concurrently cancelled/executed
+        // between the read above and the claim). Re-read so the message
+        // reflects the row's actual current status.
+        var lost = await _getPlanRow(input.plan.id);
+        throw new TypeError("split-shipments.executeSplit: plan " + input.plan.id +
+          " is " + ((lost && lost.status) || "gone") +
+          ", only proposed plans can be executed");
+      }
+
       var shipmentIds = [];
-      for (var i = 0; i < hydrated.shipments.length; i += 1) {
-        var parcel = hydrated.shipments[i];
-        var notes = "split:" + parcel.rationale + " (" + (i + 1) + "/" + hydrated.shipments.length + ")";
-        var createInput = {
-          order_id: input.order_id,
-          carrier:  carrier,
-          notes:    notes,
-        };
-        if (carrier === "other") {
-          createInput.carrier_other_name = carrierOtherName;
+      try {
+        for (var i = 0; i < hydrated.shipments.length; i += 1) {
+          var parcel = hydrated.shipments[i];
+          var notes = "split:" + parcel.rationale + " (" + (i + 1) + "/" + hydrated.shipments.length + ")";
+          var createInput = {
+            order_id: input.order_id,
+            carrier:  carrier,
+            notes:    notes,
+          };
+          if (carrier === "other") {
+            createInput.carrier_other_name = carrierOtherName;
+          }
+          var s = await orderTracking.createShipment(createInput);
+          shipmentIds.push(s.id);
         }
-        var s = await orderTracking.createShipment(createInput);
-        shipmentIds.push(s.id);
+      } catch (e) {
+        // A createShipment throw after the claim would strand the plan
+        // in `executed` with a partial shipment set. Revert the claim
+        // (self-targeting WHERE so it only fires on the row WE claimed)
+        // and rethrow so the operator can retry once the underlying
+        // failure clears. Any shipment rows already written by earlier
+        // parcels are reconciled via the orderTracking primitive's own
+        // per-shipment flow — the plan returns to `proposed`.
+        await query(
+          "UPDATE split_shipment_plans SET status = 'proposed', executed_at = NULL " +
+          "WHERE id = ?1 AND status = 'executed'",
+          [input.plan.id],
+        );
+        throw e;
       }
-      var ts = _now();
+
+      // Second UPDATE persists the shipment-id list now that every
+      // parcel landed. Self-targeting WHERE id keyed off the row we
+      // already claimed — the status gate was the first UPDATE.
       await query(
-        "UPDATE split_shipment_plans SET status = 'executed', executed_shipment_ids_json = ?1, " +
-        "executed_at = ?2 WHERE id = ?3",
-        [JSON.stringify(shipmentIds), ts, input.plan.id],
+        "UPDATE split_shipment_plans SET executed_shipment_ids_json = ?1 WHERE id = ?2",
+        [JSON.stringify(shipmentIds), input.plan.id],
       );
       return _hydratePlan(await _getPlanRow(input.plan.id));
     },

package/lib/suggestion-box.js

@@ -754,11 +754,44 @@ function create(opts) {
     var ts        = _now();
     var srcVotes  = Number(src.vote_count) || 0;
 
-    await query(
+    // Atomic claim: flip the source to 'duplicate' under a WHERE that
+    // re-asserts the JS preconditions (not already a duplicate, not
+    // archived). SQLite/D1 serializes writers, so this conditional
+    // UPDATE is the exactly-once gate — two concurrent linkers both
+    // pass the read-time checks above, but only one wins this claim.
+    // The loser (rowCount === 0) did NOT transition the row, so it
+    // must NOT migrate votes a second time (which would double-count
+    // srcVotes onto the canonical); it returns the already-linked row.
+    var claim = await query(
       "UPDATE suggestions SET status = 'duplicate', canonical_id = ?1, " +
-      "vote_count = 0, updated_at = ?2 WHERE id = ?3",
+      "vote_count = 0, updated_at = ?2 " +
+      "WHERE id = ?3 AND status <> 'duplicate' AND archived_at IS NULL",
       [cid, ts, sid],
     );
+    if (Number(claim.rowCount || 0) !== 1) {
+      // Lost the race (a concurrent linkDuplicates already flipped the
+      // source) — or it was archived between the read and the claim.
+      // Re-read to distinguish: a row now in 'duplicate' is the
+      // expected concurrent-link outcome, so return it idempotently;
+      // anything else means the precondition genuinely no longer holds.
+      var current = await _getRaw(sid);
+      if (current && current.status === "duplicate") {
+        return {
+          suggestion_id:    sid,
+          canonical_id:     current.canonical_id,
+          migrated_votes:   0,
+          source:           _decode(current),
+          canonical:        _decode(await _getRaw(current.canonical_id)),
+        };
+      }
+      var lost = new Error("suggestionBox.linkDuplicates: source could not be claimed for linking");
+      lost.code = "SUGGESTION_ALREADY_DUPLICATE";
+      throw lost;
+    }
+
+    // Only the claim winner reaches here — migrate the source's net
+    // vote_count (captured from the row this claim transitioned) onto
+    // the canonical exactly once.
     if (srcVotes !== 0) {
       await query(
         "UPDATE suggestions SET vote_count = vote_count + ?1, updated_at = ?2 WHERE id = ?3",

package/package.json

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