@wix/agent-skills 1.35.1 → 1.36.1

package/skills/wix-replatform/resources/rp-target-wix/lib/gift-card-redemption-build.js

@@ -1,249 +0,0 @@
-'use strict';
-
-const { isBlank } = require('./value-utils.js');
-const { WIX_GIFT_CARDS_APP_ID } = require('./gift-card-build.js');
-
-// rp-target-wix — given the bridge-plugin activity rows
-// for one card, netted per source order, build the deterministic
-// POST /ecom/v1/gift-cards/redeem request body: { code, amount, orderId, appId }.
-//
-// The mechanism itself is LIVE-VERIFIED IN ISOLATION 2026-08-17: a real Redeem Gift Card call against a real imported
-// order correctly decremented a card's balance (10 -> 7) and returned a transactionId. What this
-// module is BLOCKED on is the INPUT, not the mechanism: the activity row shape it consumes comes
-// from the bridge plugin, which is code-only and not yet installed/live-tested on any
-// real WordPress site. This builder is ready to consume that
-// data the moment it exists.
-//
-// Ordering requirement: the source card's issuance must already
-// be recorded in the crosswalk (gift-card-build.js ran first) and the order this redemption
-// belongs to must already be imported (order-channel-build.js), before a
-// redemption can be linked — this module does not check either precondition itself, it only
-// requires the caller to already have both resolved ids in hand.
-
-// A single activity row's `action` label is NOT independently confirmed against the plugin's
-// exact stored string — the available evidence only documents the function name
-// (`debit_gift_cards()`), not the literal VARCHAR value it writes. Classifying by the SIGN of
-// `amount` instead is grounded directly in the plugin's own documented balance computation
-// (balance = SUM(activity.amount)), not a guessed string.
-function isRedemptionActivityRow(row) {
-  return row != null && Number(row.amount) < 0;
-}
-
-// Fixed 2026-08-18: a naive "replay every negative row" double-removes value the
-// source has already restored. Most gift-card plugins (PW Gift Cards included, per its own
-// debit/credit activity model) can credit a card back when an order tied
-// to a prior debit is later cancelled, refunded, or fails — a -10/+10 pair for the SAME order
-// must net to zero, not emit a 10.00 redemption. This exact reversal mechanism is not
-// independently verified against the plugin's own PHP source in this repo yet, but netting per
-// order is the only sound behavior regardless of the specific trigger, since ANY reversal for ANY
-// reason produces exactly this shape: two-or-more rows, same order, opposite signs.
-//
-// Returns an array of 0 or 1 netted-activity objects (`{ orderId, amount, activityIds, rows }`) —
-// an array, not a bare object, so a fully-reversed or never-redeemed order (net >= 0) can return
-// "nothing to build" the same way a not-found lookup would, rather than a sentinel the caller has
-// to remember to check.
-function findRedemptionActivityForOrder(activityRows, sourceOrderId) {
-  const rowsForOrder = (activityRows || []).filter(
-    (row) => row != null && Number(row.order_id) === Number(sourceOrderId)
-  );
-  if (rowsForOrder.length === 0) return [];
-
-  const net = rowsForOrder.reduce((sum, row) => {
-    const rowAmount = Number(row.amount);
-    return sum + (Number.isFinite(rowAmount) ? rowAmount : 0);
-  }, 0);
-
-  // net >= 0: no debit at all for this order, or a later reversal already restored it in full —
-  // either way, nothing left to redeem in Wix.
-  if (net >= 0) return [];
-
-  return [{
-    orderId: sourceOrderId,
-    amount: net,
-    activityIds: rowsForOrder.map((row) => row.activity_id),
-    rows: rowsForOrder,
-  }];
-}
-
-// Fixed 2026-08-18: Policy C's own soundness has a precondition this
-// module did not check. Replaying every order-linked redemption reaches the CORRECT final balance
-// only when the drift between face value and the bridge's reported current balance is FULLY
-// explained by order-linked activity. The bridge explicitly allows manual, non-order-linked
-// adjustments (extract_order_id() returns null for these): a
-// card can carry face value 25, a manual credit +5 (order_id null), and a real redemption -10
-// (order-linked) — the bridge's own current balance is 20, but blindly replaying only the
-// order-linked -10 debit would leave the Wix card at 25 - 10 = 15, silently wrong by 5.
-//
-// This is the pre-write reconciliation required before Policy C may be used
-// for a card: predict the final balance IF only order-linked activity is replayed (summing, per
-// order, the same net-per-order computation findRedemptionActivityForOrder itself uses — a
-// net-positive order, like the one that issued the card, correctly contributes nothing to
-// replay, exactly the way findRedemptionActivityForOrder already treats it), then compare that
-// prediction against the bridge's own reported CURRENT balance (which sums literally every row,
-// order-linked or not — no need to specifically detect "the issuance row" or "manual rows"; any
-// unaccounted-for activity of any kind surfaces as a mismatch here). A mismatch means Policy C is
-// not safe for this card — it must gap for manual review, or fall back to Policy B (create
-// directly at the bridge's verified current balance) instead.
-function verifyPolicyCReplaySufficiency({ activityRows, faceValue, bridgeCurrentBalance } = {}) {
-  const face = faceValue == null ? NaN : Number(faceValue);
-  const bridgeBalance = bridgeCurrentBalance == null ? NaN : Number(bridgeCurrentBalance);
-  if (!Number.isFinite(face) || !Number.isFinite(bridgeBalance)) {
-    return {
-      safe: false,
-      gap: {
-        code: 'policy-c-verification-missing-input',
-        summary: `faceValue (${JSON.stringify(faceValue)}) and bridgeCurrentBalance (${JSON.stringify(bridgeCurrentBalance)}) must both be finite numbers to verify Policy C is safe for this card.`,
-      },
-    };
-  }
-
-  const orderIds = Array.from(
-    new Set((activityRows || []).map((row) => (row == null ? null : row.order_id)).filter((orderId) => orderId != null))
-  );
-
-  const totalReplayAmount = orderIds.reduce((sum, orderId) => {
-    const net = findRedemptionActivityForOrder(activityRows, orderId);
-    return sum + net.reduce((s, entry) => s + Math.abs(entry.amount), 0);
-  }, 0);
-
-  const predictedFinalBalance = Math.round((face - totalReplayAmount) * 100) / 100;
-  const roundedBridgeBalance = Math.round(bridgeBalance * 100) / 100;
-  const drift = Math.round((roundedBridgeBalance - predictedFinalBalance) * 100) / 100;
-
-  if (Math.abs(drift) > 0.005) {
-    return {
-      safe: false,
-      predictedFinalBalance,
-      bridgeCurrentBalance: roundedBridgeBalance,
-      drift,
-      gap: {
-        code: 'policy-c-unexplained-activity',
-        summary: `replaying only this card's order-linked activity would leave it at ${predictedFinalBalance}, but the bridge reports a current balance of ${roundedBridgeBalance} (drift ${drift}) — some activity (e.g. a manual, non-order-linked adjustment) is not accounted for by order-linked replay. Policy C is not safe for this card; either gap it for manual review, or use Policy B (create directly at the bridge's verified current balance) instead.`,
-      },
-    };
-  }
-
-  return { safe: true, predictedFinalBalance, bridgeCurrentBalance: roundedBridgeBalance };
-}
-
-// One order's redemption -> one Redeem Gift Card body. `sourceOrderId` is the WooCommerce order
-// id whose redemption is being linked; the netted activity for it is DERIVED INTERNALLY from
-// `options.activityRows` via findRedemptionActivityForOrder — see the fix note below for why this
-// is no longer a caller-supplied parameter. `wixCode` is the code the card was actually CREATED
-// with (gift-card-build.js's payload.code — after any options.normalizeCode stripping), resolved
-// from the crosswalk row this card's issuance produced (sourceStableKey
-// `woocommerce:giftCard:<number>`), never re-derived from the raw source number here. `wixOrderId`
-// is the real Wix order id returned by Import Order for the order this redemption belongs to.
-//
-// Fixed 2026-08-18: `options.balancePolicy` is now REQUIRED and must be
-// `'C'` — the only one of the three balance policies (A, B, C) a redemption replay is
-// safe under. Policy A is explicitly defined as "face value, no replay"; building a redemption
-// for an 'A' card would contradict that policy's own accepted-overstatement design instead of
-// implementing it (an 'A' card's overstatement is meant to be corrected manually, via
-// disable-and-replace, or accepted — not silently patched by a redemption call the card's own
-// policy never called for). Policy B already creates the card at its verified CURRENT balance —
-// replaying the same historical redemption on a 'B' card would double-decrement it (once
-// implicitly, by never having had the spend reflected in a face-value creation that never
-// happened; once again by this call). 'C' is the one policy that means what a redemption call
-// does: create at face value, then bring the balance down to correct by replaying real,
-// order-linked redemptions — see gift-card-build.js's resolveCardBalance for its (identical to
-// 'A') creation-time behavior.
-//
-// Fixed 2026-08-18: declaring Policy C is not by itself proof that
-// replay will reach the correct balance for THIS card — see verifyPolicyCReplaySufficiency's own
-// comment for the manual-adjustment failure mode this closes. `options.activityRows`,
-// `options.faceValue`, and `options.bridgeCurrentBalance` are now REQUIRED alongside
-// `balancePolicy: 'C'`, and this function runs that verification itself on every call rather than
-// trusting a boolean the caller claims to have already checked — a card that fails verification
-// gets a named gap here, never a payload.
-//
-// Fixed 2026-08-18: the fourth pass's own verification was DISCONNECTED
-// from the payload it gated. `netActivity` used to be a second, independently caller-supplied
-// argument — nothing checked that it was actually derived from the same `activityRows` the
-// verification ran against, so a caller (or a bug) could pass activity rows that verify cleanly
-// while separately passing a fabricated `netActivity.amount` and still get a real redemption
-// payload built for an amount that was never verified at all. There is now exactly ONE source of
-// truth: `sourceOrderId` plus `options.activityRows`, and this function derives the netted
-// activity itself via `findRedemptionActivityForOrder` — the same call, on the same rows,
-// `verifyPolicyCReplaySufficiency` already used — so the built payload can never diverge from
-// what was verified.
-function buildGiftCardRedemption(sourceOrderId, options) {
-  const { wixCode, wixOrderId, wixAppId = WIX_GIFT_CARDS_APP_ID, balancePolicy, activityRows, faceValue, bridgeCurrentBalance } = options || {};
-  const notes = [];
-
-  if (balancePolicy !== 'C') {
-    return {
-      payload: null,
-      gaps: [{
-        code: 'redemption-replay-requires-policy-c',
-        summary: `options.balancePolicy must be "C" to build a redemption — got ${JSON.stringify(balancePolicy)}. Policy A means "face value, no replay"; replaying a redemption on an 'A' card contradicts that policy instead of implementing it. Policy B already creates the card at its verified current balance; replaying the same redemption on a 'B' card would double-decrement it. Only a card explicitly declared Policy C — face value now, corrected later by replaying real order-linked redemptions — may be redeemed here.`,
-      }],
-      notes,
-    };
-  }
-
-  const verification = verifyPolicyCReplaySufficiency({ activityRows, faceValue, bridgeCurrentBalance });
-  if (!verification.safe) {
-    return { payload: null, gaps: [verification.gap], notes };
-  }
-
-  if (isBlank(wixCode)) {
-    return {
-      payload: null,
-      gaps: [{ code: 'missing-wix-code', summary: 'options.wixCode is required — resolve it from the crosswalk row this card was issued under (sourceStableKey woocommerce:giftCard:<number>) before building a redemption; never re-derive it from the raw source number, which may have been normalized at creation.' }],
-      notes,
-    };
-  }
-  if (isBlank(wixOrderId)) {
-    return {
-      payload: null,
-      gaps: [{ code: 'missing-wix-order-id', summary: 'options.wixOrderId is required — the order this redemption is linked to must already be imported before its redemptions can be recorded.' }],
-      notes,
-    };
-  }
-
-  // Derived from the SAME activityRows the verification above just ran against — never a
-  // separately caller-supplied value (see the fifth-pass fix note above).
-  const [netActivity = null] = findRedemptionActivityForOrder(activityRows, sourceOrderId);
-
-  const netAmount = netActivity == null ? null : Number(netActivity.amount);
-  if (netActivity == null || !Number.isFinite(netAmount) || netAmount >= 0) {
-    return {
-      payload: null,
-      gaps: [{
-        code: 'not-a-net-redemption',
-        summary: `net activity for order ${sourceOrderId} is "${netActivity && netActivity.amount}" — not a negative net amount once every activity row for this order is netted together, so there is nothing to redeem (either no debit occurred, or a later same-order reversal already restored it).`,
-      }],
-      notes,
-    };
-  }
-
-  const amount = Math.abs(netAmount);
-  if (amount <= 0) {
-    return {
-      payload: null,
-      gaps: [{ code: 'invalid-redemption-amount', summary: `net activity for order ${netActivity.orderId} has amount "${netActivity.amount}", not a positive value once its sign is taken.` }],
-      notes,
-    };
-  }
-
-  notes.push(`redemption sourced from netted bridge-plugin activity for order_id ${netActivity.orderId} (activity rows: ${JSON.stringify(netActivity.activityIds)}) — net amount after any same-order reversal is ${netActivity.amount}.`);
-
-  return {
-    payload: {
-      code: wixCode,
-      amount: amount.toFixed(2),
-      orderId: wixOrderId,
-      appId: wixAppId,
-    },
-    gaps: [],
-    notes,
-  };
-}
-
-module.exports = {
-  isRedemptionActivityRow,
-  findRedemptionActivityForOrder,
-  verifyPolicyCReplaySufficiency,
-  buildGiftCardRedemption,
-};

package/skills/wix-replatform/resources/rp-target-wix/lib/ndjson.js

@@ -1,260 +0,0 @@
-'use strict';
-
-// rp-target-wix — NDJSON record-stream I/O for migration data files.
-//
-// Every migration writes the same shape of intermediate data: a long stream of per-entity
-// records that a later stage scans, batches and cursors through. That is a line-delimited
-// format, not a single JSON document, so it is built once here rather than re-derived by
-// codegen per project.
-//
-// WHY NDJSON over a JSON array (`{ entity, records: [...] }`):
-//   - scan: counting or filtering never parses the whole file, and never holds it in memory
-//   - batch: a bulk endpoint's page is `readBatches(file, 100)` — no slicing a giant array.
-//     Use `readBatchesByLimits` when the endpoint caps several dimensions at once (Wix bulk
-//     product create caps products, variants AND options per request).
-//   - cursor: resume from record N is a byte offset or a line skip, not a full re-parse
-//   - append: a producer can emit records as it finds them; a crash leaves a valid prefix
-//   - a single malformed record is one bad line, not an unparseable file
-//
-// USE IT FOR record streams (`data/source-extract/<entity>.ndjson`, crosswalks, audit logs).
-// Do NOT use it for single documents — a manifest, mapping plan, decisions or completion
-// report is one object and stays `.json`. Line-delimiting a document buys nothing and makes
-// it unreadable.
-//
-// Dependency-free and streaming, like the source adapters' transport modules. Codegen
-// vendors a copy into the project (e.g. `src/lib/ndjson.js`) and imports from it.
-
-const fs = require('node:fs');
-const fsp = require('node:fs/promises');
-const path = require('node:path');
-const readline = require('node:readline');
-
-const EXT = '.ndjson';
-
-function ensureDir(filePath) {
-  fs.mkdirSync(path.dirname(filePath), { recursive: true });
-}
-
-// One record per line. JSON.stringify escapes embedded newlines, so a record can never
-// break the line framing.
-function encodeRecord(record) {
-  if (record === undefined) throw new Error('ndjson: cannot encode undefined');
-  const line = JSON.stringify(record);
-  if (line === undefined) throw new Error('ndjson: record is not JSON-serialisable');
-  return `${line}\n`;
-}
-
-// --- writing ---------------------------------------------------------------
-
-// Streaming write of a whole stream. Accepts arrays, generators and async generators, so a
-// reader can hand over records as it produces them without materialising them all.
-async function writeRecords(filePath, records) {
-  ensureDir(filePath);
-  const out = fs.createWriteStream(filePath, { flags: 'w' });
-  let count = 0;
-  try {
-    for await (const record of records) {
-      count += 1;
-      if (!out.write(encodeRecord(record))) {
-        await new Promise((resolve) => out.once('drain', resolve));
-      }
-    }
-  } finally {
-    await new Promise((resolve, reject) => {
-      out.end((err) => (err ? reject(err) : resolve()));
-    });
-  }
-  return count;
-}
-
-// Incremental appender for producers that emit over time (crosswalk, audit log). `flush`
-// is per-record and O(1) — the whole point of not rewriting a JSON array each time.
-function createAppender(filePath) {
-  ensureDir(filePath);
-  let count = 0;
-  return {
-    file: filePath,
-    append(record) {
-      fs.appendFileSync(filePath, encodeRecord(record));
-      count += 1;
-      return record;
-    },
-    appendAll(records) {
-      let buffer = '';
-      for (const record of records) buffer += encodeRecord(record);
-      if (buffer) fs.appendFileSync(filePath, buffer);
-      count += records.length;
-      return records.length;
-    },
-    written: () => count,
-  };
-}
-
-// --- reading ---------------------------------------------------------------
-
-// Streams records without loading the file. readline handles \n, \r\n and the chunk-boundary
-// case that a naive split('\n') gets wrong.
-//
-// A blank line is skipped (a trailing newline is normal). A malformed line throws, naming the
-// line number — silently dropping records would corrupt a migration invisibly.
-async function* readRecords(filePath, { skipMalformed = false, onMalformed = null } = {}) {
-  if (!fs.existsSync(filePath)) return;
-  const input = fs.createReadStream(filePath, { encoding: 'utf8' });
-  const rl = readline.createInterface({ input, crlfDelay: Infinity });
-  let lineNumber = 0;
-  try {
-    for await (const line of rl) {
-      lineNumber += 1;
-      if (line.trim() === '') continue;
-      let record;
-      try {
-        record = JSON.parse(line);
-      } catch (err) {
-        const detail = `${filePath}:${lineNumber} is not valid JSON (${err.message})`;
-        if (onMalformed) onMalformed({ file: filePath, line: lineNumber, raw: line, error: err.message });
-        if (skipMalformed) continue;
-        throw new Error(`ndjson: ${detail}. Refusing to continue — a dropped record is invisible data loss.`);
-      }
-      yield record;
-    }
-  } finally {
-    rl.close();
-    input.destroy();
-  }
-}
-
-// The batching primitive bulk endpoints consume. `size` is a record count; when a target
-// caps something else too (Wix bulk product create allows 100 products AND 1000 variants
-// per request) use readBatchesBy instead.
-async function* readBatches(filePath, size = 100, options = {}) {
-  if (!Number.isInteger(size) || size < 1) throw new Error('ndjson: batch size must be a positive integer');
-  let batch = [];
-  for await (const record of readRecords(filePath, options)) {
-    batch.push(record);
-    if (batch.length >= size) {
-      yield batch;
-      batch = [];
-    }
-  }
-  if (batch.length) yield batch;
-}
-
-// Batch against SEVERAL simultaneous caps. Real bulk endpoints rarely have just one: Wix
-// bulk product create allows 100 products AND 1000 variants AND 100 options AND 100
-// modifiers AND 100 infoSections per request, and exceeding any single one rejects the whole
-// batch. Batching on record count alone silently produces requests that 428.
-//
-//   readBatchesByLimits(file, {
-//     limits: { records: 100, variants: 1000, options: 100 },
-//     cost: (p) => ({ variants: p.variants.length, options: p.options.length }),
-//   })
-//
-// `records` is implicit and always counted. Any dimension absent from `limits` is ignored,
-// so a cost function may report more than the caller caps.
-//
-// A single record that alone exceeds a cap is still emitted, in a batch of one, with
-// `oversized` reported through `onOversized`. Dropping it would be silent data loss and
-// splitting it is impossible — the caller has to decide (skip it, or fail loudly).
-async function* readBatchesByLimits(filePath, { limits = {}, cost = () => ({}), onOversized = null, ...options } = {}) {
-  const caps = { records: 100, ...limits };
-  for (const [dim, cap] of Object.entries(caps)) {
-    if (!(Number.isFinite(cap) && cap >= 1)) throw new Error(`ndjson: limit "${dim}" must be a number >= 1 (got ${cap})`);
-  }
-
-  let batch = [];
-  let running = {};
-  const costOf = (record) => {
-    const c = cost(record) || {};
-    return { ...c, records: 1 };
-  };
-  const wouldExceed = (c) => Object.keys(caps).some((dim) => (running[dim] || 0) + (c[dim] || 0) > caps[dim]);
-  const aloneExceeds = (c) => Object.keys(caps).some((dim) => (c[dim] || 0) > caps[dim]);
-
-  for await (const record of readRecords(filePath, options)) {
-    const c = costOf(record);
-    if (batch.length && wouldExceed(c)) {
-      yield batch;
-      batch = [];
-      running = {};
-    }
-    if (aloneExceeds(c) && onOversized) {
-      const over = Object.keys(caps).filter((dim) => (c[dim] || 0) > caps[dim]);
-      onOversized({ record, cost: c, exceeded: over, caps });
-    }
-    batch.push(record);
-    for (const dim of Object.keys(c)) running[dim] = (running[dim] || 0) + c[dim];
-  }
-  if (batch.length) yield batch;
-}
-
-// Single-dimension convenience wrapper over readBatchesByLimits, kept because plenty of
-// endpoints really do have just one cap.
-async function* readBatchesBy(filePath, { maxCount = 100, maxCost = Infinity, cost = () => 1, ...options } = {}) {
-  const limits = { records: maxCount };
-  if (Number.isFinite(maxCost)) limits.cost = maxCost;
-  yield* readBatchesByLimits(filePath, { ...options, limits, cost: (r) => ({ cost: cost(r) }) });
-}
-
-// Cursor: skip `offset` records, take at most `limit`. Used for resume — no need to parse
-// what has already been processed into objects.
-async function* readSlice(filePath, { offset = 0, limit = Infinity, ...options } = {}) {
-  let index = 0;
-  let taken = 0;
-  for await (const record of readRecords(filePath, options)) {
-    if (index++ < offset) continue;
-    if (taken++ >= limit) return;
-    yield record;
-  }
-}
-
-// Cheap count — parses nothing, just counts non-empty lines.
-async function countRecords(filePath) {
-  if (!fs.existsSync(filePath)) return 0;
-  const input = fs.createReadStream(filePath, { encoding: 'utf8' });
-  const rl = readline.createInterface({ input, crlfDelay: Infinity });
-  let count = 0;
-  try {
-    for await (const line of rl) if (line.trim() !== '') count += 1;
-  } finally {
-    rl.close();
-    input.destroy();
-  }
-  return count;
-}
-
-// Escape hatch for small streams that genuinely need to be in memory at once (a 6-record
-// category list). Named so that using it on a large stream is an obvious mistake.
-async function readAllRecords(filePath, options = {}) {
-  const out = [];
-  for await (const record of readRecords(filePath, options)) out.push(record);
-  return out;
-}
-
-// --- migration of existing projects ---------------------------------------
-
-// Converts a legacy `{ entity, recordCount, records: [...] }` document to NDJSON. Kept so a
-// project generated before this format change can be moved forward without re-extracting.
-async function convertLegacyJsonFile(jsonPath, ndjsonPath, { recordsKey = 'records' } = {}) {
-  const parsed = JSON.parse(await fsp.readFile(jsonPath, 'utf8'));
-  const records = Array.isArray(parsed) ? parsed : parsed[recordsKey];
-  if (!Array.isArray(records)) {
-    throw new Error(`ndjson: ${jsonPath} has no array at "${recordsKey}" to convert`);
-  }
-  const count = await writeRecords(ndjsonPath, records);
-  return { from: jsonPath, to: ndjsonPath, count };
-}
-
-module.exports = {
-  EXT,
-  encodeRecord,
-  writeRecords,
-  createAppender,
-  readRecords,
-  readBatches,
-  readBatchesBy,
-  readBatchesByLimits,
-  readSlice,
-  countRecords,
-  readAllRecords,
-  convertLegacyJsonFile,
-};

package/skills/wix-replatform/resources/rp-target-wix/lib/order-applied-discount-build.js

@@ -1,63 +0,0 @@
-'use strict';
-
-// Coupon usage per order, as the imported order's appliedDiscounts.
-//
-// There is no standalone write: an applied discount rides in the Import Order body (entity
-// ecom/order-applied-discount, preferredWrite importOrder). So this module turns a source order's
-// coupon lines into `appliedDiscounts[]` entries for the order body, resolving each code through
-// the coupon crosswalk. A code the crosswalk cannot resolve produces NO entry and one unresolved
-// report line -- a dangling reference would name a coupon that does not exist on the target.
-//
-// Every entry is the `coupon` one-of variant, which is the only honest one here: the discount
-// genuinely was a coupon redemption. The plugin-computed `merchantDiscount` variant is a
-// different entity (ecom/discount-rule's records) and is not this module's business.
-//
-// Pure. Amounts are kept as the source recorded them; Import Order stores money as-is and never
-// recalculates, so the caller's priceSummary must already agree with these.
-
-const OUTCOMES = Object.freeze({
-  WRITTEN: 'coupon-usage-written',
-  UNRESOLVED: 'coupon-usage-unresolved',
-  NONE: 'coupon-usage-none',
-});
-
-function canonicalAmount(value) {
-  const text = value === undefined || value === null ? '' : String(value).trim();
-  if (!/^-?\d+(\.\d+)?$/.test(text)) return null;
-  const n = Math.abs(Number(text));
-  return n.toFixed(2);
-}
-
-// `couponLines`: WooCommerce order `coupon_lines[]` ({ code, discount, discount_tax }) or any
-// { code, discount } shape. `resolveCoupon(code)` -> { id, name? } | null (the coupon crosswalk).
-function buildCouponAppliedDiscounts({ couponLines = [], resolveCoupon, includeTax = false } = {}) {
-  if (typeof resolveCoupon !== 'function') throw new Error('buildCouponAppliedDiscounts needs resolveCoupon(code) backed by the coupon crosswalk');
-  if (!Array.isArray(couponLines)) throw new Error('couponLines must be an array');
-  const appliedDiscounts = [];
-  const unresolved = [];
-  const findings = [];
-  for (const line of couponLines) {
-    const code = line && line.code !== undefined && line.code !== null ? String(line.code).trim() : '';
-    if (!code) { findings.push({ code: 'coupon-line-without-code' }); continue; }
-    let amount = canonicalAmount(line.discount);
-    if (amount === null) { unresolved.push({ code, reason: 'amount-not-decimal', discount: line.discount }); continue; }
-    if (includeTax) {
-      const tax = canonicalAmount(line.discount_tax);
-      if (tax !== null) amount = (Number(amount) + Number(tax)).toFixed(2);
-    }
-    const resolved = resolveCoupon(code);
-    if (!resolved || !resolved.id) {
-      unresolved.push({ code, reason: 'coupon-not-imported', amount });
-      continue;
-    }
-    appliedDiscounts.push({
-      // Order-level: WooCommerce records a coupon's total discount against the order, not per line.
-      discountType: 'GLOBAL',
-      coupon: { id: String(resolved.id), code, name: resolved.name ? String(resolved.name) : code, amount: { amount } },
-    });
-  }
-  const outcome = couponLines.length === 0 ? OUTCOMES.NONE : (appliedDiscounts.length > 0 ? OUTCOMES.WRITTEN : OUTCOMES.UNRESOLVED);
-  return { appliedDiscounts, unresolved, findings, outcome, counts: { written: appliedDiscounts.length, unresolved: unresolved.length } };
-}
-
-module.exports = { OUTCOMES, buildCouponAppliedDiscounts, canonicalAmount };