@withpotter/lib 0.13.0-next.101

package/dist/intents/order-progress.d.ts

@@ -0,0 +1,81 @@
+/**
+ * The two axes a merchant actually thinks in, derived from the three status
+ * machines an order carries.
+ *
+ * An order has `status`, `paymentStatus` and `fulfillmentStatus`, each with its
+ * own vocabulary. Nobody opens this page thinking "set fulfillment to partial".
+ * They think "did the money land?" and "has it gone out?" — so this collapses
+ * the three into a **money** axis, a **delivery** axis, and one derived next
+ * action, all driven by the intent's `orderDisplay` so every archetype inherits
+ * the same shape with its own words.
+ *
+ * The underlying statuses stay editable on the detail page: this decides what
+ * leads, not what's reachable.
+ */
+import type { DeliveryMethod, FulfillmentStatus, OrderStatus, PaymentStatus } from '@withpotter/lib/api/types';
+import type { OrderDisplay } from './types';
+export type StepState = 'done' | 'current' | 'upcoming';
+export interface ProgressStep {
+    key: string;
+    label: string;
+    state: StepState;
+}
+export interface ProgressAxis {
+    /** Axis heading, e.g. "Payment" or the intent's fulfillment label. */
+    label: string;
+    steps: ProgressStep[];
+    /**
+     * Set when the axis ended somewhere off the happy path (refunded, partially
+     * refunded). The steps are then meaningless and the caller shows this alone.
+     */
+    terminal?: {
+        label: string;
+        tone: 'error' | 'warning';
+    };
+}
+export type NextActionKey = 'confirm-transfer' | 'fulfill' | 'advance-status' | 'none';
+export interface OrderNextAction {
+    key: NextActionKey;
+    label: string;
+    /** For 'advance-status', the status to move to. */
+    status?: OrderStatus;
+    /** For 'fulfill', the fulfillment state to move to. */
+    fulfillmentStatus?: FulfillmentStatus;
+}
+export declare function resolveMoneyAxis(paymentStatus: PaymentStatus): ProgressAxis;
+/**
+ * The delivery axis is entirely intent-owned: its steps and their words come
+ * from `orderDisplay.fulfillmentLabels`, so a padel club reads "Checked in"
+ * where a shop reads "Shipped" with no branching here.
+ */
+export declare function resolveDeliveryAxis(orderDisplay: OrderDisplay | undefined, fulfillmentStatus: FulfillmentStatus, 
+/**
+ * Overrides the axis vocabulary for orders whose delivery isn't physical —
+ * a ticket order reads "Pending → Tickets issued", not "Unfulfilled → Shipped".
+ */
+overrides?: {
+    label?: string;
+    stepLabels?: Partial<Record<string, string>>;
+}): ProgressAxis;
+interface NextActionInput {
+    status: OrderStatus;
+    paymentStatus: PaymentStatus;
+    fulfillmentStatus: FulfillmentStatus;
+    orderDisplay?: OrderDisplay;
+    intentKey?: string;
+    /** False when this order has nothing to fulfil (tickets, or config says so). */
+    canFulfill: boolean;
+    /**
+     * How this order reaches the customer. Only the fulfil step reads it, and
+     * only to name itself: "Mark as Shipped" is the wrong verb for a rider going
+     * across town, and it is the button the merchant actually clicks.
+     */
+    deliveryMethod?: DeliveryMethod | null;
+}
+/**
+ * The single next thing to do, in the order money actually moves: verify what
+ * the buyer claims, then get the goods out, then advance the workflow. Returns
+ * `none` when the order is settled or the only moves left are escape hatches.
+ */
+export declare function resolveNextAction({ status, paymentStatus, fulfillmentStatus, orderDisplay, intentKey, canFulfill, deliveryMethod, }: NextActionInput): OrderNextAction;
+export {};

package/dist/intents/order-progress.js

@@ -0,0 +1,91 @@
+import {
+  resolveFulfillmentModalCopy,
+  resolveFulfillmentStatusKeys,
+  resolveFulfillmentStatusLabel,
+  resolveOrderStatusLabel
+} from "./order-display";
+import { getAllowedOrderTransitions } from "./order-transitions";
+const MONEY_PATH = ["unpaid", "awaiting_confirmation", "paid"];
+const MONEY_LABELS = {
+  unpaid: "Awaiting payment",
+  awaiting_confirmation: "Claimed",
+  paid: "Paid",
+  partially_refunded: "Partially refunded",
+  refunded: "Refunded"
+};
+function walk(path, current, label) {
+  const index = path.indexOf(current);
+  return path.map((key, i) => ({
+    key,
+    label: label(key),
+    state: index < 0 ? "upcoming" : i < index ? "done" : i === index ? "current" : "upcoming"
+  }));
+}
+function resolveMoneyAxis(paymentStatus) {
+  if (paymentStatus === "refunded" || paymentStatus === "partially_refunded") {
+    return {
+      label: "Payment",
+      steps: [],
+      terminal: {
+        label: MONEY_LABELS[paymentStatus],
+        tone: paymentStatus === "refunded" ? "error" : "warning"
+      }
+    };
+  }
+  return {
+    label: "Payment",
+    steps: walk(MONEY_PATH, paymentStatus, (key) => MONEY_LABELS[key])
+  };
+}
+function resolveDeliveryAxis(orderDisplay, fulfillmentStatus, overrides) {
+  const keys = overrides?.stepLabels ? Object.keys(overrides.stepLabels) : resolveFulfillmentStatusKeys(orderDisplay);
+  return {
+    label: overrides?.label ?? orderDisplay?.fulfillmentLabel ?? "Fulfillment",
+    steps: walk(
+      keys,
+      fulfillmentStatus,
+      (key) => overrides?.stepLabels?.[key] ?? resolveFulfillmentStatusLabel(orderDisplay, key)
+    )
+  };
+}
+const NEVER_SUGGEST = ["cancelled", "refunded"];
+const NEVER_SUGGEST_FULFILLMENT = ["partial"];
+function resolveNextAction({
+  status,
+  paymentStatus,
+  fulfillmentStatus,
+  orderDisplay,
+  intentKey,
+  canFulfill,
+  deliveryMethod
+}) {
+  if (paymentStatus === "awaiting_confirmation") {
+    return { key: "confirm-transfer", label: "Confirm payment" };
+  }
+  if (canFulfill && paymentStatus === "paid") {
+    const keys = resolveFulfillmentStatusKeys(orderDisplay);
+    const next2 = keys.slice(keys.indexOf(fulfillmentStatus) + 1).find((candidate) => !NEVER_SUGGEST_FULFILLMENT.includes(candidate));
+    if (next2) {
+      const handsOver = deliveryMethod === "delivery" || deliveryMethod === "shipping";
+      const label = next2 === "fulfilled" ? handsOver ? "Hand it over" : resolveFulfillmentModalCopy(orderDisplay).actionLabel : `Mark ${resolveFulfillmentStatusLabel(orderDisplay, next2).toLowerCase()}`;
+      return { key: "fulfill", label, fulfillmentStatus: next2 };
+    }
+  }
+  const next = getAllowedOrderTransitions(status, intentKey).find(
+    (candidate) => !NEVER_SUGGEST.includes(candidate)
+  );
+  if (next) {
+    return {
+      key: "advance-status",
+      label: `Mark ${resolveOrderStatusLabel(orderDisplay, next).toLowerCase()}`,
+      status: next
+    };
+  }
+  return { key: "none", label: "" };
+}
+export {
+  resolveDeliveryAxis,
+  resolveMoneyAxis,
+  resolveNextAction
+};
+//# sourceMappingURL=order-progress.js.map

package/dist/intents/order-progress.js.map

@@ -0,0 +1 @@
+{"version":3,"sources":["../../src/intents/order-progress.ts"],"sourcesContent":["/**\n * The two axes a merchant actually thinks in, derived from the three status\n * machines an order carries.\n *\n * An order has `status`, `paymentStatus` and `fulfillmentStatus`, each with its\n * own vocabulary. Nobody opens this page thinking \"set fulfillment to partial\".\n * They think \"did the money land?\" and \"has it gone out?\" — so this collapses\n * the three into a **money** axis, a **delivery** axis, and one derived next\n * action, all driven by the intent's `orderDisplay` so every archetype inherits\n * the same shape with its own words.\n *\n * The underlying statuses stay editable on the detail page: this decides what\n * leads, not what's reachable.\n */\nimport type {\n  DeliveryMethod,\n  FulfillmentStatus,\n  OrderStatus,\n  PaymentStatus,\n} from '@withpotter/lib/api/types';\nimport type { OrderDisplay } from './types';\nimport {\n  resolveFulfillmentModalCopy,\n  resolveFulfillmentStatusKeys,\n  resolveFulfillmentStatusLabel,\n  resolveOrderStatusLabel,\n} from './order-display';\nimport { getAllowedOrderTransitions } from './order-transitions';\n\nexport type StepState = 'done' | 'current' | 'upcoming';\n\nexport interface ProgressStep {\n  key: string;\n  label: string;\n  state: StepState;\n}\n\nexport interface ProgressAxis {\n  /** Axis heading, e.g. \"Payment\" or the intent's fulfillment label. */\n  label: string;\n  steps: ProgressStep[];\n  /**\n   * Set when the axis ended somewhere off the happy path (refunded, partially\n   * refunded). The steps are then meaningless and the caller shows this alone.\n   */\n  terminal?: { label: string; tone: 'error' | 'warning' };\n}\n\nexport type NextActionKey =\n  | 'confirm-transfer'\n  | 'fulfill'\n  | 'advance-status'\n  | 'none';\n\nexport interface OrderNextAction {\n  key: NextActionKey;\n  label: string;\n  /** For 'advance-status', the status to move to. */\n  status?: OrderStatus;\n  /** For 'fulfill', the fulfillment state to move to. */\n  fulfillmentStatus?: FulfillmentStatus;\n}\n\n/** The happy path money walks. Refund states are terminal, not steps. */\nconst MONEY_PATH: PaymentStatus[] = ['unpaid', 'awaiting_confirmation', 'paid'];\n\nconst MONEY_LABELS: Record<PaymentStatus, string> = {\n  unpaid: 'Awaiting payment',\n  awaiting_confirmation: 'Claimed',\n  paid: 'Paid',\n  partially_refunded: 'Partially refunded',\n  refunded: 'Refunded',\n};\n\nfunction walk<T extends string>(\n  path: T[],\n  current: T,\n  label: (key: T) => string,\n): ProgressStep[] {\n  const index = path.indexOf(current);\n  return path.map((key, i) => ({\n    key,\n    label: label(key),\n    state:\n      index < 0\n        ? 'upcoming'\n        : i < index\n          ? 'done'\n          : i === index\n            ? 'current'\n            : 'upcoming',\n  }));\n}\n\nexport function resolveMoneyAxis(paymentStatus: PaymentStatus): ProgressAxis {\n  if (paymentStatus === 'refunded' || paymentStatus === 'partially_refunded') {\n    return {\n      label: 'Payment',\n      steps: [],\n      terminal: {\n        label: MONEY_LABELS[paymentStatus],\n        tone: paymentStatus === 'refunded' ? 'error' : 'warning',\n      },\n    };\n  }\n  return {\n    label: 'Payment',\n    steps: walk(MONEY_PATH, paymentStatus, (key) => MONEY_LABELS[key]),\n  };\n}\n\n/**\n * The delivery axis is entirely intent-owned: its steps and their words come\n * from `orderDisplay.fulfillmentLabels`, so a padel club reads \"Checked in\"\n * where a shop reads \"Shipped\" with no branching here.\n */\nexport function resolveDeliveryAxis(\n  orderDisplay: OrderDisplay | undefined,\n  fulfillmentStatus: FulfillmentStatus,\n  /**\n   * Overrides the axis vocabulary for orders whose delivery isn't physical —\n   * a ticket order reads \"Pending → Tickets issued\", not \"Unfulfilled → Shipped\".\n   */\n  overrides?: { label?: string; stepLabels?: Partial<Record<string, string>> },\n): ProgressAxis {\n  const keys = overrides?.stepLabels\n    ? (Object.keys(overrides.stepLabels) as FulfillmentStatus[])\n    : resolveFulfillmentStatusKeys(orderDisplay);\n\n  return {\n    label: overrides?.label ?? orderDisplay?.fulfillmentLabel ?? 'Fulfillment',\n    steps: walk(\n      keys,\n      fulfillmentStatus,\n      (key) =>\n        overrides?.stepLabels?.[key] ??\n        resolveFulfillmentStatusLabel(orderDisplay, key),\n    ),\n  };\n}\n\n/** Statuses that are an escape hatch, never the thing to nudge someone toward. */\nconst NEVER_SUGGEST: OrderStatus[] = ['cancelled', 'refunded'];\n\n/**\n * Same idea on the delivery axis. \"Partially fulfilled\" is something an order\n * ends up in, not something anyone sets out to do, so the suggested action\n * steps over it. The override menu still reaches it.\n */\nconst NEVER_SUGGEST_FULFILLMENT: FulfillmentStatus[] = ['partial'];\n\ninterface NextActionInput {\n  status: OrderStatus;\n  paymentStatus: PaymentStatus;\n  fulfillmentStatus: FulfillmentStatus;\n  orderDisplay?: OrderDisplay;\n  intentKey?: string;\n  /** False when this order has nothing to fulfil (tickets, or config says so). */\n  canFulfill: boolean;\n  /**\n   * How this order reaches the customer. Only the fulfil step reads it, and\n   * only to name itself: \"Mark as Shipped\" is the wrong verb for a rider going\n   * across town, and it is the button the merchant actually clicks.\n   */\n  deliveryMethod?: DeliveryMethod | null;\n}\n\n/**\n * The single next thing to do, in the order money actually moves: verify what\n * the buyer claims, then get the goods out, then advance the workflow. Returns\n * `none` when the order is settled or the only moves left are escape hatches.\n */\nexport function resolveNextAction({\n  status,\n  paymentStatus,\n  fulfillmentStatus,\n  orderDisplay,\n  intentKey,\n  canFulfill,\n  deliveryMethod,\n}: NextActionInput): OrderNextAction {\n  if (paymentStatus === 'awaiting_confirmation') {\n    return { key: 'confirm-transfer', label: 'Confirm payment' };\n  }\n\n  if (canFulfill && paymentStatus === 'paid') {\n    const keys = resolveFulfillmentStatusKeys(orderDisplay);\n    const next = keys\n      .slice(keys.indexOf(fulfillmentStatus) + 1)\n      .find((candidate) => !NEVER_SUGGEST_FULFILLMENT.includes(candidate));\n    if (next) {\n      // Moving *into* the fulfilled step is the one that opens the handover\n      // dialog, so it borrows that dialog's verb. Which verb depends on the\n      // journey: something physically changes hands on a delivery or a courier\n      // run, and \"Mark as Shipped\" said over a rider was the same wrong noun\n      // the dialog itself used to carry. Where there is no journey at all the\n      // archetype's own wording still wins.\n      const handsOver =\n        deliveryMethod === 'delivery' || deliveryMethod === 'shipping';\n      const label =\n        next === 'fulfilled'\n          ? handsOver\n            ? 'Hand it over'\n            : resolveFulfillmentModalCopy(orderDisplay).actionLabel\n          : `Mark ${resolveFulfillmentStatusLabel(orderDisplay, next).toLowerCase()}`;\n      return { key: 'fulfill', label, fulfillmentStatus: next };\n    }\n  }\n\n  const next = getAllowedOrderTransitions(status, intentKey).find(\n    (candidate) => !NEVER_SUGGEST.includes(candidate),\n  );\n  if (next) {\n    return {\n      key: 'advance-status',\n      label: `Mark ${resolveOrderStatusLabel(orderDisplay, next).toLowerCase()}`,\n      status: next,\n    };\n  }\n\n  return { key: 'none', label: '' };\n}\n"],"mappings":"AAqBA;AAAA,EACE;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,OACK;AACP,SAAS,kCAAkC;AAqC3C,MAAM,aAA8B,CAAC,UAAU,yBAAyB,MAAM;AAE9E,MAAM,eAA8C;AAAA,EAClD,QAAQ;AAAA,EACR,uBAAuB;AAAA,EACvB,MAAM;AAAA,EACN,oBAAoB;AAAA,EACpB,UAAU;AACZ;AAEA,SAAS,KACP,MACA,SACA,OACgB;AAChB,QAAM,QAAQ,KAAK,QAAQ,OAAO;AAClC,SAAO,KAAK,IAAI,CAAC,KAAK,OAAO;AAAA,IAC3B;AAAA,IACA,OAAO,MAAM,GAAG;AAAA,IAChB,OACE,QAAQ,IACJ,aACA,IAAI,QACF,SACA,MAAM,QACJ,YACA;AAAA,EACZ,EAAE;AACJ;AAEO,SAAS,iBAAiB,eAA4C;AAC3E,MAAI,kBAAkB,cAAc,kBAAkB,sBAAsB;AAC1E,WAAO;AAAA,MACL,OAAO;AAAA,MACP,OAAO,CAAC;AAAA,MACR,UAAU;AAAA,QACR,OAAO,aAAa,aAAa;AAAA,QACjC,MAAM,kBAAkB,aAAa,UAAU;AAAA,MACjD;AAAA,IACF;AAAA,EACF;AACA,SAAO;AAAA,IACL,OAAO;AAAA,IACP,OAAO,KAAK,YAAY,eAAe,CAAC,QAAQ,aAAa,GAAG,CAAC;AAAA,EACnE;AACF;AAOO,SAAS,oBACd,cACA,mBAKA,WACc;AACd,QAAM,OAAO,WAAW,aACnB,OAAO,KAAK,UAAU,UAAU,IACjC,6BAA6B,YAAY;AAE7C,SAAO;AAAA,IACL,OAAO,WAAW,SAAS,cAAc,oBAAoB;AAAA,IAC7D,OAAO;AAAA,MACL;AAAA,MACA;AAAA,MACA,CAAC,QACC,WAAW,aAAa,GAAG,KAC3B,8BAA8B,cAAc,GAAG;AAAA,IACnD;AAAA,EACF;AACF;AAGA,MAAM,gBAA+B,CAAC,aAAa,UAAU;AAO7D,MAAM,4BAAiD,CAAC,SAAS;AAuB1D,SAAS,kBAAkB;AAAA,EAChC;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AACF,GAAqC;AACnC,MAAI,kBAAkB,yBAAyB;AAC7C,WAAO,EAAE,KAAK,oBAAoB,OAAO,kBAAkB;AAAA,EAC7D;AAEA,MAAI,cAAc,kBAAkB,QAAQ;AAC1C,UAAM,OAAO,6BAA6B,YAAY;AACtD,UAAMA,QAAO,KACV,MAAM,KAAK,QAAQ,iBAAiB,IAAI,CAAC,EACzC,KAAK,CAAC,cAAc,CAAC,0BAA0B,SAAS,SAAS,CAAC;AACrE,QAAIA,OAAM;AAOR,YAAM,YACJ,mBAAmB,cAAc,mBAAmB;AACtD,YAAM,QACJA,UAAS,cACL,YACE,iBACA,4BAA4B,YAAY,EAAE,cAC5C,QAAQ,8BAA8B,cAAcA,KAAI,EAAE,YAAY,CAAC;AAC7E,aAAO,EAAE,KAAK,WAAW,OAAO,mBAAmBA,MAAK;AAAA,IAC1D;AAAA,EACF;AAEA,QAAM,OAAO,2BAA2B,QAAQ,SAAS,EAAE;AAAA,IACzD,CAAC,cAAc,CAAC,cAAc,SAAS,SAAS;AAAA,EAClD;AACA,MAAI,MAAM;AACR,WAAO;AAAA,MACL,KAAK;AAAA,MACL,OAAO,QAAQ,wBAAwB,cAAc,IAAI,EAAE,YAAY,CAAC;AAAA,MACxE,QAAQ;AAAA,IACV;AAAA,EACF;AAEA,SAAO,EAAE,KAAK,QAAQ,OAAO,GAAG;AAClC;","names":["next"]}

package/dist/intents/order-sections.d.ts

@@ -0,0 +1,173 @@
+import type { IntentConfig } from './types';
+/**
+ * A stable reading order for the union.
+ *
+ * Sections merged from two archetypes must not come out in the order the
+ * merchant ticked their archetypes in — the mistake pass 20 fixed in the
+ * sidebar. The header opens, the timeline closes, and what the order contains
+ * is read before what was paid.
+ */
+/**
+ * `order-header` and `activity-timeline` are both gone from this list.
+ *
+ * The header card said the order number and the date, which the breadcrumb and
+ * the panel below it now both carry — three copies of one string in the first
+ * screenful. The activity section derived four rows from the order's own
+ * columns while `OrderTimeline` renders the real event log from the API on
+ * every order, intent or not; keeping the derived one meant showing a guess at
+ * a history beside the history.
+ */
+export declare const SECTION_ORDER: string[];
+/** Every behaviour named anywhere on the order's lines. */
+export declare function orderBehaviors(order: {
+    items?: {
+        behaviors?: string[];
+    }[] | null;
+}): Set<string>;
+/**
+ * Which of a business's archetypes a thing carrying these behaviours belongs
+ * to. Empty when nothing identifies it.
+ */
+export declare function configsForBehaviors<T extends {
+    key: string;
+}>(configs: T[], behaviors: Iterable<string>): T[];
+export declare function resolveOrderSections(order: {
+    items?: {
+        behaviors?: string[];
+    }[] | null;
+}, configs: IntentConfig[], primary: IntentConfig): string[];
+/**
+ * The filters offered above the order list.
+ *
+ * `primary.pageSections.orderList.filters` again — so a musician whose first
+ * archetype is ticketing was offered Event and Tier and never a date range,
+ * on a list that also holds every record and download they have ever sold.
+ *
+ * Unioned across the archetypes the business runs, deduped by key, in the
+ * merchant's own order with the primary first. Deduped by key rather than
+ * label because two archetypes declaring `dateRange` mean one control, and a
+ * filter's key is what the query is built from.
+ */
+export declare function resolveOrderFilters<T extends {
+    key: string;
+}>(configs: {
+    key: string;
+    pageSections: {
+        orderList: {
+            filters: T[];
+        };
+    };
+}[], primary: {
+    key: string;
+    pageSections: {
+        orderList: {
+            filters: T[];
+        };
+    };
+}): T[];
+/**
+ * The columns of an order list covering more than one archetype.
+ *
+ * `IntentOrderList` took them from `primary.pageSections.orderList.columns` —
+ * one archetype's table over every archetype's rows, and `primary` on an
+ * unscoped view is whichever key last rode an `?intent=` into sessionStorage.
+ * So a restaurant that also sells tickets showed its ticket orders with no
+ * event, no ticket count and no check-in state; and after one visit to
+ * Attendees it showed every plate of food under those three, permanently
+ * blank. The columns moved with where the merchant had last clicked.
+ *
+ * The detail screen fixed this by following the order rather than the
+ * archetype. A list cannot do that per row — a table has one set of headings —
+ * so it does the other half: every column any active archetype declares, once,
+ * in a fixed order. A column no row can fill reads "-", which is the honest
+ * answer for a list holding two kinds of thing.
+ *
+ * Headings are unioned the way nouns are elsewhere: where the archetypes
+ * declaring a column agree on its word, that word is used — a bakery's
+ * takeaway and dining orders both say "Order #". Where they disagree there is
+ * no true word for the mixed column, and the neutral one is used, so a golf
+ * club does not read "Subscription #" over a tee time.
+ *
+ * A single archetype keeps its own table exactly as before.
+ */
+export declare function resolveOrderColumns<T extends {
+    key: string;
+    label: string;
+}>(configs: {
+    key: string;
+    pageSections: {
+        orderList: {
+            columns: T[];
+        };
+    };
+}[]): T[];
+/**
+ * What one order's status is called, on a list covering several archetypes.
+ *
+ * The label came from `primary.orderDisplay.statusLabels`. The three archetypes
+ * of a restaurant that seats, does takeaway and sells tickets agree on every
+ * status but one, and that one is the status the floor reads: `checked_in` is
+ * **Served** to the dining room, **Ready for Pickup** to the kitchen counter
+ * and **Checked In** to the door. One of those three was printed on all of
+ * them, chosen by where the merchant last clicked.
+ *
+ * So the order answers, not the screen: `behaviors` on its lines say which
+ * archetypes it belongs to, the same reading `resolveOrderSections` does.
+ *
+ * Where the matched archetypes disagree the neutral word is used rather than
+ * one of theirs. That case is reachable and not rare — `dine-in` and
+ * `food-orders` are BOTH identified by `sellable`, so no line can tell a plate
+ * from a takeaway bag, and a restaurant running both will read "Checked In"
+ * for either. That is a gap in what an order records, not something a label
+ * can decide: printing "Served" on a takeaway bag is the failure this replaces.
+ */
+export declare function resolveOrderStatusLabel(order: {
+    status: string;
+    items?: {
+        behaviors?: string[];
+    }[] | null;
+}, configs: IntentConfig[], primary: IntentConfig, fallback: (status: string) => string): string;
+/**
+ * The row actions offered on a mixed list.
+ *
+ * `primary`'s again, so a restaurant's ticket orders offered whatever the
+ * dining room declared and nothing the box office did. Unioned by key, first
+ * wording wins — unlike a column heading, an action's word is a verb the
+ * archetype chose for the same operation ("Fulfil" / "Hand over"), and both are
+ * true of the row.
+ *
+ * `isOffered` in the list already hides an action the order has outgrown, so a
+ * wider menu does not mean a longer one on any given row.
+ */
+export declare function resolveOrderActions<T extends {
+    key: string;
+}>(configs: {
+    pageSections: {
+        orderList: {
+            actions: T[];
+        };
+    };
+}[]): T[];
+/**
+ * Whether the list hides fulfilment.
+ *
+ * A narrowing again, and read off one archetype: `hideFulfillment` is true for
+ * eight of the ten, so a shop selling goods beside anything else had its
+ * handover column hidden by the archetype that does not post things. One
+ * archetype that fulfils is enough for the business to fulfil.
+ */
+export declare function resolveHideFulfillment(configs: {
+    orderDisplay: {
+        hideFulfillment: boolean;
+    };
+}[]): boolean;
+type StatusLabelled = {
+    orderDisplay: {
+        statusLabels?: Record<string, string>;
+    };
+};
+export declare function resolveOrderStates(configs: StatusLabelled[], everyConfig: StatusLabelled[], counts: Record<string, number | undefined> | undefined): {
+    value: string;
+    label: string;
+}[];
+export {};

package/dist/intents/order-sections.js

@@ -0,0 +1,188 @@
+const IDENTIFYING_BEHAVIOR = {
+  "sell-products": "shippable",
+  "food-orders": "sellable",
+  "dine-in": "sellable",
+  "digital-products": "downloadable",
+  "event-tickets": "ticketed",
+  subscriptions: "subscribable",
+  "take-bookings": "bookable",
+  "rent-property": "rentable"
+};
+const SECTION_ORDER = [
+  "ticket-info",
+  "event-details",
+  "subscription-details",
+  "order-items",
+  "shipping-info",
+  "download-links",
+  "check-in-status",
+  "attendee-list",
+  "payment-summary"
+];
+function orderBehaviors(order) {
+  const present = /* @__PURE__ */ new Set();
+  for (const item of order.items ?? [])
+    for (const behavior of item.behaviors ?? []) present.add(behavior);
+  return present;
+}
+function configsForBehaviors(configs, behaviors) {
+  const present = new Set(behaviors);
+  return configs.filter((config) => {
+    const behavior = IDENTIFYING_BEHAVIOR[config.key];
+    return behavior ? present.has(behavior) : false;
+  });
+}
+function resolveOrderSections(order, configs, primary) {
+  const present = orderBehaviors(order);
+  const represented = configs.filter((config) => {
+    const behavior = IDENTIFYING_BEHAVIOR[config.key];
+    return behavior ? present.has(behavior) : false;
+  });
+  const sources = represented.length > 0 ? represented : [primary];
+  const keys = new Set(
+    sources.flatMap((config) => config.pageSections.orderDetail)
+  );
+  return [
+    ...SECTION_ORDER.filter((key) => keys.has(key)),
+    // Anything an archetype declares that this list has not been told about
+    // still renders, after the ordered ones rather than not at all.
+    ...[...keys].filter((key) => !SECTION_ORDER.includes(key))
+  ];
+}
+function resolveOrderFilters(configs, primary) {
+  const ordered = [primary, ...configs.filter((c) => c.key !== primary.key)];
+  const seen = /* @__PURE__ */ new Set();
+  const filters = [];
+  for (const config of ordered)
+    for (const filter of config.pageSections.orderList.filters) {
+      if (seen.has(filter.key)) continue;
+      seen.add(filter.key);
+      filters.push(filter);
+    }
+  return filters;
+}
+const COLUMN_ORDER = [
+  "orderNumber",
+  "customer",
+  "eventName",
+  "items",
+  "ticketCount",
+  "total",
+  "status",
+  "fulfillment",
+  "checkedIn",
+  "date"
+];
+const NEUTRAL_COLUMN_LABELS = {
+  orderNumber: "Order #",
+  customer: "Customer",
+  items: "Items",
+  total: "Total",
+  status: "Status",
+  fulfillment: "Fulfillment",
+  date: "Date",
+  eventName: "Event",
+  ticketCount: "Tickets",
+  checkedIn: "Checked In"
+};
+function resolveOrderColumns(configs) {
+  if (configs.length === 1) return configs[0].pageSections.orderList.columns;
+  const byKey = /* @__PURE__ */ new Map();
+  for (const config of configs)
+    for (const column of config.pageSections.orderList.columns)
+      byKey.set(column.key, [...byKey.get(column.key) ?? [], column]);
+  const ordered = [
+    ...COLUMN_ORDER.filter((key) => byKey.has(key)),
+    ...[...byKey.keys()].filter((key) => !COLUMN_ORDER.includes(key))
+  ];
+  return ordered.map((key) => {
+    const declared = byKey.get(key);
+    const labels = new Set(declared.map((column) => column.label));
+    if (labels.size === 1) return declared[0];
+    return { ...declared[0], label: NEUTRAL_COLUMN_LABELS[key] ?? key };
+  });
+}
+function resolveOrderStatusLabel(order, configs, primary, fallback) {
+  const represented = configsForBehaviors(configs, orderBehaviors(order));
+  const sources = represented.length > 0 ? represented : [primary];
+  const labels = new Set(
+    sources.map((config) => config.orderDisplay.statusLabels[order.status]).filter(Boolean)
+  );
+  if (labels.size === 1) return [...labels][0];
+  if (labels.size > 1)
+    return NEUTRAL_STATUS_LABELS[order.status] ?? primary.orderDisplay.statusLabels[order.status] ?? fallback(order.status);
+  return fallback(order.status);
+}
+const NEUTRAL_STATUS_LABELS = {
+  pending: "Pending",
+  confirmed: "Confirmed",
+  processing: "Processing",
+  checked_in: "Checked In",
+  completed: "Completed",
+  cancelled: "Cancelled",
+  refunded: "Refunded"
+};
+function resolveOrderActions(configs) {
+  const byKey = /* @__PURE__ */ new Map();
+  for (const config of configs)
+    for (const action of config.pageSections.orderList.actions)
+      if (!byKey.has(action.key)) byKey.set(action.key, action);
+  return [...byKey.values()];
+}
+function resolveHideFulfillment(configs) {
+  return configs.every((config) => config.orderDisplay.hideFulfillment);
+}
+const NOT_A_STATE = /* @__PURE__ */ new Set([
+  "paid",
+  "unpaid",
+  "awaiting_confirmation",
+  "refunded",
+  "unfulfilled",
+  "going_out",
+  "today",
+  "total",
+  "revenue"
+]);
+const labelsOf = (configs) => {
+  const out = /* @__PURE__ */ new Map();
+  for (const c of configs)
+    for (const [value, label] of Object.entries(
+      c.orderDisplay.statusLabels ?? {}
+    ))
+      if (!out.has(value)) out.set(value, label);
+  return out;
+};
+const ORDER_STATES = {
+  pending: true,
+  confirmed: true,
+  processing: true,
+  checked_in: true,
+  completed: true,
+  cancelled: true,
+  refunded: true
+};
+const isReachableState = (value, configs) => value in ORDER_STATES || configs.some((c) => c.orderDisplay.bookingStatusKeys?.includes(value));
+function resolveOrderStates(configs, everyConfig, counts) {
+  const seen = labelsOf(configs);
+  for (const value of [...seen.keys()])
+    if (!isReachableState(value, configs))
+      seen.delete(value);
+  const vocabulary = labelsOf(everyConfig);
+  for (const [value, n] of Object.entries(counts ?? {}))
+    if (!seen.has(value) && !NOT_A_STATE.has(value) && vocabulary.has(value) && (n ?? 0) > 0)
+      seen.set(value, vocabulary.get(value));
+  return [...seen].map(([value, label]) => ({ value, label }));
+}
+export {
+  SECTION_ORDER,
+  configsForBehaviors,
+  orderBehaviors,
+  resolveHideFulfillment,
+  resolveOrderActions,
+  resolveOrderColumns,
+  resolveOrderFilters,
+  resolveOrderSections,
+  resolveOrderStates,
+  resolveOrderStatusLabel
+};
+//# sourceMappingURL=order-sections.js.map

package/dist/intents/order-sections.js.map

@@ -0,0 +1 @@
+{"version":3,"sources":["../../src/intents/order-sections.ts"],"sourcesContent":["import type { IntentConfig } from './types';\nimport type { OrderStatus } from '@withpotter/lib/api/types';\n\n/**\n * Which sections an order detail screen shows.\n *\n * This used to be `intentConfig.primary.pageSections.orderDetail` — the\n * archetype the merchant happened to list first, for every order they ever\n * open. A musician selling shows, records and downloads has `event-tickets`\n * first, so an order for a **vinyl** rendered ticket info, event details,\n * check-in status and an attendee list, and rendered neither `order-items` nor\n * `shipping-info`. The merchant could not see what had been bought or where to\n * post it, under four empty sections about a concert.\n *\n * An order already says what it is. Every line carries `behaviors` — the API\n * flattens them onto each item — so the screen can follow the order instead of\n * the archetype.\n *\n * A pure ticket order still renders exactly `event-tickets`' sections, which is\n * the point: nothing is added to orders that did not change. What changes is\n * that an order spanning two archetypes now renders both.\n */\n\n/**\n * The behaviour that means \"this archetype is in this order\".\n *\n * Not `intrinsicBehaviors`, which is a wider claim: `food-orders`, `dine-in`\n * and `sell-products` all list `sellable`, so a takeaway line would drag in\n * three archetypes' sections.\n *\n * The splits follow the API's own reading of an order —\n * `IntentLifecycleService.resolveIntentFromBehaviors` — so the two repos agree\n * on what a line IS: `sellable` with `shippable` is goods, `sellable` alone is\n * food, `bookable` with `rentable` is a stay rather than an appointment.\n *\n * Where this deliberately differs is the shape of the answer. The API returns\n * ONE intent, because a status transition has to belong to one workflow. A\n * screen is not a workflow: an order holding a ticket and a record is both\n * things at once, and picking one is how this bug started.\n *\n * `send-invoices` and `capture-leads` are absent on purpose — neither produces\n * order lines, so neither can be identified from one.\n */\nconst IDENTIFYING_BEHAVIOR: Record<string, string> = {\n  'sell-products': 'shippable',\n  'food-orders': 'sellable',\n  'dine-in': 'sellable',\n  'digital-products': 'downloadable',\n  'event-tickets': 'ticketed',\n  subscriptions: 'subscribable',\n  'take-bookings': 'bookable',\n  'rent-property': 'rentable',\n};\n\n/**\n * A stable reading order for the union.\n *\n * Sections merged from two archetypes must not come out in the order the\n * merchant ticked their archetypes in — the mistake pass 20 fixed in the\n * sidebar. The header opens, the timeline closes, and what the order contains\n * is read before what was paid.\n */\n/**\n * `order-header` and `activity-timeline` are both gone from this list.\n *\n * The header card said the order number and the date, which the breadcrumb and\n * the panel below it now both carry — three copies of one string in the first\n * screenful. The activity section derived four rows from the order's own\n * columns while `OrderTimeline` renders the real event log from the API on\n * every order, intent or not; keeping the derived one meant showing a guess at\n * a history beside the history.\n */\nexport const SECTION_ORDER = [\n  'ticket-info',\n  'event-details',\n  'subscription-details',\n  'order-items',\n  'shipping-info',\n  'download-links',\n  'check-in-status',\n  'attendee-list',\n  'payment-summary',\n];\n\n/** Every behaviour named anywhere on the order's lines. */\nexport function orderBehaviors(order: {\n  items?: { behaviors?: string[] }[] | null;\n}): Set<string> {\n  const present = new Set<string>();\n  for (const item of order.items ?? [])\n    for (const behavior of item.behaviors ?? []) present.add(behavior);\n  return present;\n}\n\n/**\n * Which of a business's archetypes a thing carrying these behaviours belongs\n * to. Empty when nothing identifies it.\n */\nexport function configsForBehaviors<T extends { key: string }>(\n  configs: T[],\n  behaviors: Iterable<string>,\n): T[] {\n  const present = new Set(behaviors);\n  return configs.filter((config) => {\n    const behavior = IDENTIFYING_BEHAVIOR[config.key];\n    return behavior ? present.has(behavior) : false;\n  });\n}\n\nexport function resolveOrderSections(\n  order: { items?: { behaviors?: string[] }[] | null },\n  configs: IntentConfig[],\n  primary: IntentConfig,\n): string[] {\n  const present = orderBehaviors(order);\n\n  const represented = configs.filter((config) => {\n    const behavior = IDENTIFYING_BEHAVIOR[config.key];\n    return behavior ? present.has(behavior) : false;\n  });\n\n  /**\n   * Nothing identifiable falls back to the primary archetype, which is what\n   * this screen did for every order until now.\n   *\n   * It is reached more often than it looks: orders written before the API\n   * flattened `behaviors` onto items carry none, and a single-archetype\n   * business has one answer anyway. Falling back to the old behaviour means\n   * this can only ever add sections that were missing, never remove one a\n   * merchant already relies on.\n   */\n  const sources = represented.length > 0 ? represented : [primary];\n\n  const keys = new Set(\n    sources.flatMap((config) => config.pageSections.orderDetail),\n  );\n\n  return [\n    ...SECTION_ORDER.filter((key) => keys.has(key)),\n    // Anything an archetype declares that this list has not been told about\n    // still renders, after the ordered ones rather than not at all.\n    ...[...keys].filter((key) => !SECTION_ORDER.includes(key)),\n  ];\n}\n\n/**\n * The filters offered above the order list.\n *\n * `primary.pageSections.orderList.filters` again — so a musician whose first\n * archetype is ticketing was offered Event and Tier and never a date range,\n * on a list that also holds every record and download they have ever sold.\n *\n * Unioned across the archetypes the business runs, deduped by key, in the\n * merchant's own order with the primary first. Deduped by key rather than\n * label because two archetypes declaring `dateRange` mean one control, and a\n * filter's key is what the query is built from.\n */\nexport function resolveOrderFilters<T extends { key: string }>(\n  configs: { key: string; pageSections: { orderList: { filters: T[] } } }[],\n  primary: { key: string; pageSections: { orderList: { filters: T[] } } },\n): T[] {\n  const ordered = [primary, ...configs.filter((c) => c.key !== primary.key)];\n  const seen = new Set<string>();\n  const filters: T[] = [];\n\n  for (const config of ordered)\n    for (const filter of config.pageSections.orderList.filters) {\n      if (seen.has(filter.key)) continue;\n      seen.add(filter.key);\n      filters.push(filter);\n    }\n\n  return filters;\n}\n\n/**\n * The summary measures for an order list covering one or more archetypes.\n *\n * A mixed list follows the same primary-first union rule as filters, so the\n * summary does not silently describe only whichever intent happened to be\n * selected first.\n */\n/**\n * A stable reading order for the columns of a mixed list.\n *\n * Same reason `SECTION_ORDER` exists one screen over: a union assembled from\n * several archetypes must not come out in the order the merchant ticked them.\n * Identity first, then what was bought, then the money, then where it is, then\n * when.\n */\nconst COLUMN_ORDER = [\n  'orderNumber',\n  'customer',\n  'eventName',\n  'items',\n  'ticketCount',\n  'total',\n  'status',\n  'fulfillment',\n  'checkedIn',\n  'date',\n];\n\n/**\n * The neutral word for a column several archetypes name differently.\n *\n * Taken from `default-commerce`, which is the platform's own vocabulary, with\n * the ticketing columns added because no neutral config declares them.\n */\nconst NEUTRAL_COLUMN_LABELS: Record<string, string> = {\n  orderNumber: 'Order #',\n  customer: 'Customer',\n  items: 'Items',\n  total: 'Total',\n  status: 'Status',\n  fulfillment: 'Fulfillment',\n  date: 'Date',\n  eventName: 'Event',\n  ticketCount: 'Tickets',\n  checkedIn: 'Checked In',\n};\n\n/**\n * The columns of an order list covering more than one archetype.\n *\n * `IntentOrderList` took them from `primary.pageSections.orderList.columns` —\n * one archetype's table over every archetype's rows, and `primary` on an\n * unscoped view is whichever key last rode an `?intent=` into sessionStorage.\n * So a restaurant that also sells tickets showed its ticket orders with no\n * event, no ticket count and no check-in state; and after one visit to\n * Attendees it showed every plate of food under those three, permanently\n * blank. The columns moved with where the merchant had last clicked.\n *\n * The detail screen fixed this by following the order rather than the\n * archetype. A list cannot do that per row — a table has one set of headings —\n * so it does the other half: every column any active archetype declares, once,\n * in a fixed order. A column no row can fill reads \"-\", which is the honest\n * answer for a list holding two kinds of thing.\n *\n * Headings are unioned the way nouns are elsewhere: where the archetypes\n * declaring a column agree on its word, that word is used — a bakery's\n * takeaway and dining orders both say \"Order #\". Where they disagree there is\n * no true word for the mixed column, and the neutral one is used, so a golf\n * club does not read \"Subscription #\" over a tee time.\n *\n * A single archetype keeps its own table exactly as before.\n */\nexport function resolveOrderColumns<T extends { key: string; label: string }>(\n  configs: { key: string; pageSections: { orderList: { columns: T[] } } }[],\n): T[] {\n  if (configs.length === 1) return configs[0].pageSections.orderList.columns;\n\n  const byKey = new Map<string, T[]>();\n  for (const config of configs)\n    for (const column of config.pageSections.orderList.columns)\n      byKey.set(column.key, [...(byKey.get(column.key) ?? []), column]);\n\n  const ordered = [\n    ...COLUMN_ORDER.filter((key) => byKey.has(key)),\n    ...[...byKey.keys()].filter((key) => !COLUMN_ORDER.includes(key)),\n  ];\n\n  return ordered.map((key) => {\n    const declared = byKey.get(key)!;\n    const labels = new Set(declared.map((column) => column.label));\n    if (labels.size === 1) return declared[0];\n    return { ...declared[0], label: NEUTRAL_COLUMN_LABELS[key] ?? key };\n  });\n}\n\n/**\n * What one order's status is called, on a list covering several archetypes.\n *\n * The label came from `primary.orderDisplay.statusLabels`. The three archetypes\n * of a restaurant that seats, does takeaway and sells tickets agree on every\n * status but one, and that one is the status the floor reads: `checked_in` is\n * **Served** to the dining room, **Ready for Pickup** to the kitchen counter\n * and **Checked In** to the door. One of those three was printed on all of\n * them, chosen by where the merchant last clicked.\n *\n * So the order answers, not the screen: `behaviors` on its lines say which\n * archetypes it belongs to, the same reading `resolveOrderSections` does.\n *\n * Where the matched archetypes disagree the neutral word is used rather than\n * one of theirs. That case is reachable and not rare — `dine-in` and\n * `food-orders` are BOTH identified by `sellable`, so no line can tell a plate\n * from a takeaway bag, and a restaurant running both will read \"Checked In\"\n * for either. That is a gap in what an order records, not something a label\n * can decide: printing \"Served\" on a takeaway bag is the failure this replaces.\n */\nexport function resolveOrderStatusLabel(\n  order: { status: string; items?: { behaviors?: string[] }[] | null },\n  configs: IntentConfig[],\n  primary: IntentConfig,\n  fallback: (status: string) => string,\n): string {\n  const represented = configsForBehaviors(configs, orderBehaviors(order));\n  const sources = represented.length > 0 ? represented : [primary];\n\n  const labels = new Set(\n    sources\n      .map((config) => config.orderDisplay.statusLabels[order.status])\n      .filter(Boolean),\n  );\n\n  if (labels.size === 1) return [...labels][0];\n  if (labels.size > 1)\n    return (\n      NEUTRAL_STATUS_LABELS[order.status] ??\n      primary.orderDisplay.statusLabels[order.status] ??\n      fallback(order.status)\n    );\n  return fallback(order.status);\n}\n\n/** `default-commerce`'s words, plus the two states it does not model. */\nconst NEUTRAL_STATUS_LABELS: Record<string, string> = {\n  pending: 'Pending',\n  confirmed: 'Confirmed',\n  processing: 'Processing',\n  checked_in: 'Checked In',\n  completed: 'Completed',\n  cancelled: 'Cancelled',\n  refunded: 'Refunded',\n};\n\n/**\n * The row actions offered on a mixed list.\n *\n * `primary`'s again, so a restaurant's ticket orders offered whatever the\n * dining room declared and nothing the box office did. Unioned by key, first\n * wording wins — unlike a column heading, an action's word is a verb the\n * archetype chose for the same operation (\"Fulfil\" / \"Hand over\"), and both are\n * true of the row.\n *\n * `isOffered` in the list already hides an action the order has outgrown, so a\n * wider menu does not mean a longer one on any given row.\n */\nexport function resolveOrderActions<T extends { key: string }>(\n  configs: { pageSections: { orderList: { actions: T[] } } }[],\n): T[] {\n  const byKey = new Map<string, T>();\n  for (const config of configs)\n    for (const action of config.pageSections.orderList.actions)\n      if (!byKey.has(action.key)) byKey.set(action.key, action);\n  return [...byKey.values()];\n}\n\n/**\n * Whether the list hides fulfilment.\n *\n * A narrowing again, and read off one archetype: `hideFulfillment` is true for\n * eight of the ten, so a shop selling goods beside anything else had its\n * handover column hidden by the archetype that does not post things. One\n * archetype that fulfils is enough for the business to fulfil.\n */\nexport function resolveHideFulfillment(\n  configs: { orderDisplay: { hideFulfillment: boolean } }[],\n): boolean {\n  return configs.every((config) => config.orderDisplay.hideFulfillment);\n}\n\n/**\n * Keys in the stats tally that are not order states.\n *\n * The tally mixes three axes into one flat object — status, payment,\n * fulfilment — plus totals. Without this the rescue above offered \"Paid 6\" and\n * \"Refunded 1\" as if they were states, on a Reservations list, which is the\n * axis-mixing the field was just cleaned of.\n *\n * `refunded` is on the list for a subtler reason: it is a PaymentStatus that\n * both the OrderStats type and the demo fixture file under \"order status\" —\n * the fixture literally counts `paymentStatus === 'refunded'`. A commerce\n * archetype that genuinely wants it declares it in `statusLabels`, and the\n * declared path above picks it up; it should never arrive by accident.\n */\nconst NOT_A_STATE = new Set([\n  'paid',\n  'unpaid',\n  'awaiting_confirmation',\n  'refunded',\n  'unfulfilled',\n  'going_out',\n  'today',\n  'total',\n  'revenue',\n]);\n\ntype StatusLabelled = {\n  orderDisplay: { statusLabels?: Record<string, string> };\n};\n\ntype BookingStatusKeyed = {\n  orderDisplay: { bookingStatusKeys?: string[] };\n};\n\nconst labelsOf = (configs: StatusLabelled[]) => {\n  const out = new Map<string, string>();\n  for (const c of configs)\n    for (const [value, label] of Object.entries(\n      c.orderDisplay.statusLabels ?? {},\n    ))\n      if (!out.has(value)) out.set(value, label);\n  return out;\n};\n\n/**\n * The states an order can actually be in.\n *\n * Typed `Record<OrderStatus, true>` rather than a bare array, so it cannot\n * drift from the union the API writes: add a status to `OrderStatus` and this\n * fails the build until it is listed here.\n */\nconst ORDER_STATES: Record<OrderStatus, true> = {\n  pending: true,\n  confirmed: true,\n  processing: true,\n  checked_in: true,\n  completed: true,\n  cancelled: true,\n  refunded: true,\n};\n\n/**\n * Booking statuses ride alongside the order ones.\n *\n * An archetype whose queue is a diary sends `in_progress` and `no_show`\n * through the `bookingStatus` filter rather than `status`, so they are real\n * options even though no ORDER holds them. `bookingStatusKeys` is where an\n * archetype says so.\n */\nconst isReachableState = (value: string, configs: BookingStatusKeyed[]) =>\n  value in ORDER_STATES ||\n  configs.some((c) => c.orderDisplay.bookingStatusKeys?.includes(value));\n\nexport function resolveOrderStates(\n  configs: StatusLabelled[],\n  everyConfig: StatusLabelled[],\n  counts: Record<string, number | undefined> | undefined,\n): { value: string; label: string }[] {\n  /**\n   * Declared, and then narrowed to what an order can hold.\n   *\n   * `labelsOf` takes every key every active archetype declares, which is\n   * right until an archetype names states belonging to a different entity.\n   * `subscriptions` declares `active`, `non_renewing` and `attention` — those\n   * are `CustomerSubscription` statuses, and `OrderStatus` is\n   * pending/confirmed/processing/checked_in/completed/cancelled/refunded, so\n   * none of the three can ever match a row.\n   *\n   * A gym running memberships beside a kit shelf therefore offered **Active**,\n   * **Non-renewing** and **Needs attention** on its Orders filter, each of\n   * which emptied the list and kept it empty. The reverse direction was\n   * already guarded — a status the DATA holds that nobody declared is added\n   * below — but nothing checked a declaration against reality.\n   */\n  const seen = labelsOf(configs);\n  for (const value of [...seen.keys()])\n    if (!isReachableState(value, configs as BookingStatusKeyed[]))\n      seen.delete(value);\n\n  /**\n   * Plus anything the data actually holds.\n   *\n   * A record can carry a status this archetype does not declare — the demo\n   * fixture has a reservation sitting at `processing`, which is not even in\n   * the API's BookingStatus enum. Offering only the declared set left that\n   * record reachable by no filter at all, and the counts said so out loud:\n   * six states summing to nine against a total of ten.\n   *\n   * The vocabulary is every archetype's labels, so a real status gets its\n   * proper word while the tally's non-status keys — total, revenue, paid —\n   * cannot leak in as options.\n   */\n  const vocabulary = labelsOf(everyConfig);\n  for (const [value, n] of Object.entries(counts ?? {}))\n    if (\n      !seen.has(value) &&\n      !NOT_A_STATE.has(value) &&\n      vocabulary.has(value) &&\n      (n ?? 0) > 0\n    )\n      seen.set(value, vocabulary.get(value)!);\n\n  return [...seen].map(([value, label]) => ({ value, label }));\n}\n"],"mappings":"AA2CA,MAAM,uBAA+C;AAAA,EACnD,iBAAiB;AAAA,EACjB,eAAe;AAAA,EACf,WAAW;AAAA,EACX,oBAAoB;AAAA,EACpB,iBAAiB;AAAA,EACjB,eAAe;AAAA,EACf,iBAAiB;AAAA,EACjB,iBAAiB;AACnB;AAoBO,MAAM,gBAAgB;AAAA,EAC3B;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AACF;AAGO,SAAS,eAAe,OAEf;AACd,QAAM,UAAU,oBAAI,IAAY;AAChC,aAAW,QAAQ,MAAM,SAAS,CAAC;AACjC,eAAW,YAAY,KAAK,aAAa,CAAC,EAAG,SAAQ,IAAI,QAAQ;AACnE,SAAO;AACT;AAMO,SAAS,oBACd,SACA,WACK;AACL,QAAM,UAAU,IAAI,IAAI,SAAS;AACjC,SAAO,QAAQ,OAAO,CAAC,WAAW;AAChC,UAAM,WAAW,qBAAqB,OAAO,GAAG;AAChD,WAAO,WAAW,QAAQ,IAAI,QAAQ,IAAI;AAAA,EAC5C,CAAC;AACH;AAEO,SAAS,qBACd,OACA,SACA,SACU;AACV,QAAM,UAAU,eAAe,KAAK;AAEpC,QAAM,cAAc,QAAQ,OAAO,CAAC,WAAW;AAC7C,UAAM,WAAW,qBAAqB,OAAO,GAAG;AAChD,WAAO,WAAW,QAAQ,IAAI,QAAQ,IAAI;AAAA,EAC5C,CAAC;AAYD,QAAM,UAAU,YAAY,SAAS,IAAI,cAAc,CAAC,OAAO;AAE/D,QAAM,OAAO,IAAI;AAAA,IACf,QAAQ,QAAQ,CAAC,WAAW,OAAO,aAAa,WAAW;AAAA,EAC7D;AAEA,SAAO;AAAA,IACL,GAAG,cAAc,OAAO,CAAC,QAAQ,KAAK,IAAI,GAAG,CAAC;AAAA;AAAA;AAAA,IAG9C,GAAG,CAAC,GAAG,IAAI,EAAE,OAAO,CAAC,QAAQ,CAAC,cAAc,SAAS,GAAG,CAAC;AAAA,EAC3D;AACF;AAcO,SAAS,oBACd,SACA,SACK;AACL,QAAM,UAAU,CAAC,SAAS,GAAG,QAAQ,OAAO,CAAC,MAAM,EAAE,QAAQ,QAAQ,GAAG,CAAC;AACzE,QAAM,OAAO,oBAAI,IAAY;AAC7B,QAAM,UAAe,CAAC;AAEtB,aAAW,UAAU;AACnB,eAAW,UAAU,OAAO,aAAa,UAAU,SAAS;AAC1D,UAAI,KAAK,IAAI,OAAO,GAAG,EAAG;AAC1B,WAAK,IAAI,OAAO,GAAG;AACnB,cAAQ,KAAK,MAAM;AAAA,IACrB;AAEF,SAAO;AACT;AAiBA,MAAM,eAAe;AAAA,EACnB;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AACF;AAQA,MAAM,wBAAgD;AAAA,EACpD,aAAa;AAAA,EACb,UAAU;AAAA,EACV,OAAO;AAAA,EACP,OAAO;AAAA,EACP,QAAQ;AAAA,EACR,aAAa;AAAA,EACb,MAAM;AAAA,EACN,WAAW;AAAA,EACX,aAAa;AAAA,EACb,WAAW;AACb;AA2BO,SAAS,oBACd,SACK;AACL,MAAI,QAAQ,WAAW,EAAG,QAAO,QAAQ,CAAC,EAAE,aAAa,UAAU;AAEnE,QAAM,QAAQ,oBAAI,IAAiB;AACnC,aAAW,UAAU;AACnB,eAAW,UAAU,OAAO,aAAa,UAAU;AACjD,YAAM,IAAI,OAAO,KAAK,CAAC,GAAI,MAAM,IAAI,OAAO,GAAG,KAAK,CAAC,GAAI,MAAM,CAAC;AAEpE,QAAM,UAAU;AAAA,IACd,GAAG,aAAa,OAAO,CAAC,QAAQ,MAAM,IAAI,GAAG,CAAC;AAAA,IAC9C,GAAG,CAAC,GAAG,MAAM,KAAK,CAAC,EAAE,OAAO,CAAC,QAAQ,CAAC,aAAa,SAAS,GAAG,CAAC;AAAA,EAClE;AAEA,SAAO,QAAQ,IAAI,CAAC,QAAQ;AAC1B,UAAM,WAAW,MAAM,IAAI,GAAG;AAC9B,UAAM,SAAS,IAAI,IAAI,SAAS,IAAI,CAAC,WAAW,OAAO,KAAK,CAAC;AAC7D,QAAI,OAAO,SAAS,EAAG,QAAO,SAAS,CAAC;AACxC,WAAO,EAAE,GAAG,SAAS,CAAC,GAAG,OAAO,sBAAsB,GAAG,KAAK,IAAI;AAAA,EACpE,CAAC;AACH;AAsBO,SAAS,wBACd,OACA,SACA,SACA,UACQ;AACR,QAAM,cAAc,oBAAoB,SAAS,eAAe,KAAK,CAAC;AACtE,QAAM,UAAU,YAAY,SAAS,IAAI,cAAc,CAAC,OAAO;AAE/D,QAAM,SAAS,IAAI;AAAA,IACjB,QACG,IAAI,CAAC,WAAW,OAAO,aAAa,aAAa,MAAM,MAAM,CAAC,EAC9D,OAAO,OAAO;AAAA,EACnB;AAEA,MAAI,OAAO,SAAS,EAAG,QAAO,CAAC,GAAG,MAAM,EAAE,CAAC;AAC3C,MAAI,OAAO,OAAO;AAChB,WACE,sBAAsB,MAAM,MAAM,KAClC,QAAQ,aAAa,aAAa,MAAM,MAAM,KAC9C,SAAS,MAAM,MAAM;AAEzB,SAAO,SAAS,MAAM,MAAM;AAC9B;AAGA,MAAM,wBAAgD;AAAA,EACpD,SAAS;AAAA,EACT,WAAW;AAAA,EACX,YAAY;AAAA,EACZ,YAAY;AAAA,EACZ,WAAW;AAAA,EACX,WAAW;AAAA,EACX,UAAU;AACZ;AAcO,SAAS,oBACd,SACK;AACL,QAAM,QAAQ,oBAAI,IAAe;AACjC,aAAW,UAAU;AACnB,eAAW,UAAU,OAAO,aAAa,UAAU;AACjD,UAAI,CAAC,MAAM,IAAI,OAAO,GAAG,EAAG,OAAM,IAAI,OAAO,KAAK,MAAM;AAC5D,SAAO,CAAC,GAAG,MAAM,OAAO,CAAC;AAC3B;AAUO,SAAS,uBACd,SACS;AACT,SAAO,QAAQ,MAAM,CAAC,WAAW,OAAO,aAAa,eAAe;AACtE;AAgBA,MAAM,cAAc,oBAAI,IAAI;AAAA,EAC1B;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AACF,CAAC;AAUD,MAAM,WAAW,CAAC,YAA8B;AAC9C,QAAM,MAAM,oBAAI,IAAoB;AACpC,aAAW,KAAK;AACd,eAAW,CAAC,OAAO,KAAK,KAAK,OAAO;AAAA,MAClC,EAAE,aAAa,gBAAgB,CAAC;AAAA,IAClC;AACE,UAAI,CAAC,IAAI,IAAI,KAAK,EAAG,KAAI,IAAI,OAAO,KAAK;AAC7C,SAAO;AACT;AASA,MAAM,eAA0C;AAAA,EAC9C,SAAS;AAAA,EACT,WAAW;AAAA,EACX,YAAY;AAAA,EACZ,YAAY;AAAA,EACZ,WAAW;AAAA,EACX,WAAW;AAAA,EACX,UAAU;AACZ;AAUA,MAAM,mBAAmB,CAAC,OAAe,YACvC,SAAS,gBACT,QAAQ,KAAK,CAAC,MAAM,EAAE,aAAa,mBAAmB,SAAS,KAAK,CAAC;AAEhE,SAAS,mBACd,SACA,aACA,QACoC;AAiBpC,QAAM,OAAO,SAAS,OAAO;AAC7B,aAAW,SAAS,CAAC,GAAG,KAAK,KAAK,CAAC;AACjC,QAAI,CAAC,iBAAiB,OAAO,OAA+B;AAC1D,WAAK,OAAO,KAAK;AAerB,QAAM,aAAa,SAAS,WAAW;AACvC,aAAW,CAAC,OAAO,CAAC,KAAK,OAAO,QAAQ,UAAU,CAAC,CAAC;AAClD,QACE,CAAC,KAAK,IAAI,KAAK,KACf,CAAC,YAAY,IAAI,KAAK,KACtB,WAAW,IAAI,KAAK,MACnB,KAAK,KAAK;AAEX,WAAK,IAAI,OAAO,WAAW,IAAI,KAAK,CAAE;AAE1C,SAAO,CAAC,GAAG,IAAI,EAAE,IAAI,CAAC,CAAC,OAAO,KAAK,OAAO,EAAE,OAAO,MAAM,EAAE;AAC7D;","names":[]}

package/dist/intents/order-stats.d.ts

@@ -0,0 +1,24 @@
+/**
+ * The summary measures for an order list covering one or more archetypes.
+ *
+ * A mixed list follows the same primary-first union rule as filters, so the
+ * summary does not silently describe only whichever intent happened to be
+ * selected first.
+ */
+export declare function resolveOrderStats<T extends {
+    key: string;
+}>(configs: {
+    key: string;
+    pageSections: {
+        orderList: {
+            stats?: T[];
+        };
+    };
+}[], primary: {
+    key: string;
+    pageSections: {
+        orderList: {
+            stats?: T[];
+        };
+    };
+}): T[];

package/dist/intents/order-stats.js

@@ -0,0 +1,16 @@
+function resolveOrderStats(configs, primary) {
+  const ordered = [primary, ...configs.filter((c) => c.key !== primary.key)];
+  const seen = /* @__PURE__ */ new Set();
+  const stats = [];
+  for (const config of ordered)
+    for (const stat of config.pageSections.orderList.stats ?? []) {
+      if (seen.has(stat.key)) continue;
+      seen.add(stat.key);
+      stats.push(stat);
+    }
+  return stats;
+}
+export {
+  resolveOrderStats
+};
+//# sourceMappingURL=order-stats.js.map

package/dist/intents/order-stats.js.map

@@ -0,0 +1 @@
+{"version":3,"sources":["../../src/intents/order-stats.ts"],"sourcesContent":["/**\n * The summary measures for an order list covering one or more archetypes.\n *\n * A mixed list follows the same primary-first union rule as filters, so the\n * summary does not silently describe only whichever intent happened to be\n * selected first.\n */\nexport function resolveOrderStats<T extends { key: string }>(\n  configs: { key: string; pageSections: { orderList: { stats?: T[] } } }[],\n  primary: { key: string; pageSections: { orderList: { stats?: T[] } } },\n): T[] {\n  const ordered = [primary, ...configs.filter((c) => c.key !== primary.key)];\n  const seen = new Set<string>();\n  const stats: T[] = [];\n\n  for (const config of ordered)\n    for (const stat of config.pageSections.orderList.stats ?? []) {\n      if (seen.has(stat.key)) continue;\n      seen.add(stat.key);\n      stats.push(stat);\n    }\n\n  return stats;\n}\n"],"mappings":"AAOO,SAAS,kBACd,SACA,SACK;AACL,QAAM,UAAU,CAAC,SAAS,GAAG,QAAQ,OAAO,CAAC,MAAM,EAAE,QAAQ,QAAQ,GAAG,CAAC;AACzE,QAAM,OAAO,oBAAI,IAAY;AAC7B,QAAM,QAAa,CAAC;AAEpB,aAAW,UAAU;AACnB,eAAW,QAAQ,OAAO,aAAa,UAAU,SAAS,CAAC,GAAG;AAC5D,UAAI,KAAK,IAAI,KAAK,GAAG,EAAG;AACxB,WAAK,IAAI,KAAK,GAAG;AACjB,YAAM,KAAK,IAAI;AAAA,IACjB;AAEF,SAAO;AACT;","names":[]}