@withpotter/lib 0.13.0-next.101

package/dist/intents/analytics-labels.d.ts

@@ -0,0 +1,70 @@
+import type { AnalyticsBookingMetricLabels, IntentConfig } from './types';
+export declare function resolveBookingLabels(configs: IntentConfig[], primary: IntentConfig): AnalyticsBookingMetricLabels | undefined;
+/**
+ * Whether the Operations hub's headline tile counts bookings or orders.
+ *
+ * It asked `primary.orderDisplay.hideShipping` and showed the booking count
+ * when that was true — a shipping flag standing in for "is this a booking
+ * business". `hideShipping` is true for eight of the ten archetypes, including
+ * `digital-products`, `subscriptions` and `event-tickets`, none of which book
+ * anything. So a business selling downloads had one large tile reading Orders,
+ * linking to Orders, showing **today's bookings**: zero, forever, while its
+ * actual pending orders went uncounted.
+ *
+ * The archetypes whose queue really is a diary are the three that send this
+ * tile to /dashboard/bookings, so the count follows the destination rather
+ * than guessing at it from an unrelated flag.
+ */
+export declare function tileCountsBookings(orderHref: string): boolean;
+/**
+ * The first-run copy under an empty Customers directory.
+ *
+ * The directory itself stays "Customers" for every archetype — one back
+ * office, not four — and this is where the business describes who will land in
+ * it. Read off `primary`, a gym that named its membership first said "No
+ * subscribers yet" and the same gym that named its classes first said "No
+ * clients yet".
+ *
+ * For a business that is several things the honest answer is the generic one:
+ * the people arriving are subscribers AND clients AND attendees, and one list
+ * holds all of them.
+ */
+export declare function resolveCustomersEmptyState<T>(configs: {
+    emptyStates: {
+        customers: T;
+    };
+}[], primary: {
+    emptyStates: {
+        customers: T;
+    };
+}, generic: {
+    emptyStates: {
+        customers: T;
+    };
+}): T;
+/**
+ * Which analytics views this business admits.
+ *
+ * `analyticsPage.tabs` is a NARROWING: an archetype that names views is saying
+ * "only these apply to me". Both readers — the provider and the sidebar's
+ * Analytics group — resolved it with
+ * `configs.find((c) => c.analyticsPage?.tabs?.length)`, which is not a
+ * narrowing but a veto. The first archetype to hold an opinion spoke for every
+ * archetype beside it.
+ *
+ * `event-tickets` is the only archetype in the registry that fills the field,
+ * and it names `sales` and `retention`. So a restaurant that also sells tickets
+ * to its Friday night lost the Reviews panel out of Retention — decided by the
+ * smallest part of its business, and by a config the other two archetypes never
+ * saw.
+ *
+ * The rule that follows from what the field MEANS: an archetype that declares
+ * nothing admits everything, so one silent archetype is enough to lift the
+ * narrowing entirely. Only where every active archetype has named its views is
+ * the business narrowed, and then to the union of what they named — never to
+ * one of them.
+ *
+ * `undefined` is the answer for "no narrowing", which is what both callers
+ * already treat as "show all views".
+ */
+export declare function resolveAnalyticsViews(configs: Pick<IntentConfig, 'analyticsPage'>[]): string[] | undefined;

package/dist/intents/analytics-labels.js

@@ -0,0 +1,39 @@
+const BOOKS = /* @__PURE__ */ new Set([
+  "take-bookings",
+  "dine-in",
+  "rent-property",
+  "event-tickets",
+  "food-orders"
+]);
+const NEUTRAL = {
+  today: "Booked today",
+  upcoming: "Upcoming this week",
+  noShow: "No-shows",
+  revenue: "Booking revenue"
+};
+function resolveBookingLabels(configs, primary) {
+  const booking = configs.filter((config) => BOOKS.has(config.key));
+  if (booking.length === 0) return primary.analyticsLabels?.bookingMetrics;
+  if (booking.length === 1)
+    return booking[0].analyticsLabels?.bookingMetrics ?? { ...NEUTRAL };
+  return { ...NEUTRAL };
+}
+function tileCountsBookings(orderHref) {
+  return orderHref.startsWith("/dashboard/bookings");
+}
+function resolveCustomersEmptyState(configs, primary, generic) {
+  return configs.length > 1 ? generic.emptyStates.customers : primary.emptyStates.customers;
+}
+function resolveAnalyticsViews(configs) {
+  if (!configs.length) return void 0;
+  const declared = configs.map((config) => config.analyticsPage?.tabs);
+  if (declared.some((tabs) => !tabs?.length)) return void 0;
+  return [...new Set(declared.flat())];
+}
+export {
+  resolveAnalyticsViews,
+  resolveBookingLabels,
+  resolveCustomersEmptyState,
+  tileCountsBookings
+};
+//# sourceMappingURL=analytics-labels.js.map

package/dist/intents/analytics-labels.js.map

@@ -0,0 +1 @@
+{"version":3,"sources":["../../src/intents/analytics-labels.ts"],"sourcesContent":["import type { AnalyticsBookingMetricLabels, IntentConfig } from './types';\n\n/**\n * What to call the booking numbers on Analytics.\n *\n * These came from `primary.analyticsLabels.bookingMetrics` — the archetype the\n * merchant listed first. A farm with a veg-box scheme, tours, a table and\n * supper clubs lists `subscriptions` first, so its booking panel read\n *\n *     New today · Renewals this week · Churned · Subscription revenue\n *\n * over numbers counting farm tours, table reservations and supper-club tickets.\n *\n * **\"Churned\" was labelling the no-show count.** That is worse than a wrong\n * word: the number underneath is unchanged while the label asserts something\n * false about it. A merchant reading \"Churned: 4\" would believe four people\n * cancelled their veg-box that week, when four people did not turn up for\n * dinner.\n *\n * `subscriptions` does not produce bookings at all — its `bookingStatusKeys` is\n * empty and its booking entity is the generic noun. It was never describing\n * this panel.\n */\n\n/** Archetypes whose lines are actually counted by the booking metrics. */\nconst BOOKS = new Set([\n  'take-bookings',\n  'dine-in',\n  'rent-property',\n  'event-tickets',\n  'food-orders',\n]);\n\n/**\n * The words when several kinds of booking are pooled into one number.\n *\n * Not borrowed from whichever books first. A farm's tours, tables and supper\n * clubs are one aggregate and no archetype's own noun is true of all of it —\n * the same reason the sidebar calls a shared row Catalog rather than Menu.\n */\nconst NEUTRAL: AnalyticsBookingMetricLabels = {\n  today: 'Booked today',\n  upcoming: 'Upcoming this week',\n  noShow: 'No-shows',\n  revenue: 'Booking revenue',\n};\n\nexport function resolveBookingLabels(\n  configs: IntentConfig[],\n  primary: IntentConfig,\n): AnalyticsBookingMetricLabels | undefined {\n  const booking = configs.filter((config) => BOOKS.has(config.key));\n\n  // Nothing here books, so the panel is not about any of them: leave the\n  // answer where it was rather than invent one.\n  if (booking.length === 0) return primary.analyticsLabels?.bookingMetrics;\n\n  if (booking.length === 1)\n    return booking[0].analyticsLabels?.bookingMetrics ?? { ...NEUTRAL };\n\n  return { ...NEUTRAL };\n}\n\n/**\n * Whether the Operations hub's headline tile counts bookings or orders.\n *\n * It asked `primary.orderDisplay.hideShipping` and showed the booking count\n * when that was true — a shipping flag standing in for \"is this a booking\n * business\". `hideShipping` is true for eight of the ten archetypes, including\n * `digital-products`, `subscriptions` and `event-tickets`, none of which book\n * anything. So a business selling downloads had one large tile reading Orders,\n * linking to Orders, showing **today's bookings**: zero, forever, while its\n * actual pending orders went uncounted.\n *\n * The archetypes whose queue really is a diary are the three that send this\n * tile to /dashboard/bookings, so the count follows the destination rather\n * than guessing at it from an unrelated flag.\n */\nexport function tileCountsBookings(orderHref: string): boolean {\n  return orderHref.startsWith('/dashboard/bookings');\n}\n\n/**\n * The first-run copy under an empty Customers directory.\n *\n * The directory itself stays \"Customers\" for every archetype — one back\n * office, not four — and this is where the business describes who will land in\n * it. Read off `primary`, a gym that named its membership first said \"No\n * subscribers yet\" and the same gym that named its classes first said \"No\n * clients yet\".\n *\n * For a business that is several things the honest answer is the generic one:\n * the people arriving are subscribers AND clients AND attendees, and one list\n * holds all of them.\n */\nexport function resolveCustomersEmptyState<T>(\n  configs: { emptyStates: { customers: T } }[],\n  primary: { emptyStates: { customers: T } },\n  generic: { emptyStates: { customers: T } },\n): T {\n  return configs.length > 1\n    ? generic.emptyStates.customers\n    : primary.emptyStates.customers;\n}\n\n/**\n * Which analytics views this business admits.\n *\n * `analyticsPage.tabs` is a NARROWING: an archetype that names views is saying\n * \"only these apply to me\". Both readers — the provider and the sidebar's\n * Analytics group — resolved it with\n * `configs.find((c) => c.analyticsPage?.tabs?.length)`, which is not a\n * narrowing but a veto. The first archetype to hold an opinion spoke for every\n * archetype beside it.\n *\n * `event-tickets` is the only archetype in the registry that fills the field,\n * and it names `sales` and `retention`. So a restaurant that also sells tickets\n * to its Friday night lost the Reviews panel out of Retention — decided by the\n * smallest part of its business, and by a config the other two archetypes never\n * saw.\n *\n * The rule that follows from what the field MEANS: an archetype that declares\n * nothing admits everything, so one silent archetype is enough to lift the\n * narrowing entirely. Only where every active archetype has named its views is\n * the business narrowed, and then to the union of what they named — never to\n * one of them.\n *\n * `undefined` is the answer for \"no narrowing\", which is what both callers\n * already treat as \"show all views\".\n */\nexport function resolveAnalyticsViews(\n  configs: Pick<IntentConfig, 'analyticsPage'>[],\n): string[] | undefined {\n  if (!configs.length) return undefined;\n  const declared = configs.map((config) => config.analyticsPage?.tabs);\n  if (declared.some((tabs) => !tabs?.length)) return undefined;\n  return [...new Set(declared.flat() as string[])];\n}\n"],"mappings":"AAyBA,MAAM,QAAQ,oBAAI,IAAI;AAAA,EACpB;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AACF,CAAC;AASD,MAAM,UAAwC;AAAA,EAC5C,OAAO;AAAA,EACP,UAAU;AAAA,EACV,QAAQ;AAAA,EACR,SAAS;AACX;AAEO,SAAS,qBACd,SACA,SAC0C;AAC1C,QAAM,UAAU,QAAQ,OAAO,CAAC,WAAW,MAAM,IAAI,OAAO,GAAG,CAAC;AAIhE,MAAI,QAAQ,WAAW,EAAG,QAAO,QAAQ,iBAAiB;AAE1D,MAAI,QAAQ,WAAW;AACrB,WAAO,QAAQ,CAAC,EAAE,iBAAiB,kBAAkB,EAAE,GAAG,QAAQ;AAEpE,SAAO,EAAE,GAAG,QAAQ;AACtB;AAiBO,SAAS,mBAAmB,WAA4B;AAC7D,SAAO,UAAU,WAAW,qBAAqB;AACnD;AAeO,SAAS,2BACd,SACA,SACA,SACG;AACH,SAAO,QAAQ,SAAS,IACpB,QAAQ,YAAY,YACpB,QAAQ,YAAY;AAC1B;AA2BO,SAAS,sBACd,SACsB;AACtB,MAAI,CAAC,QAAQ,OAAQ,QAAO;AAC5B,QAAM,WAAW,QAAQ,IAAI,CAAC,WAAW,OAAO,eAAe,IAAI;AACnE,MAAI,SAAS,KAAK,CAAC,SAAS,CAAC,MAAM,MAAM,EAAG,QAAO;AACnD,SAAO,CAAC,GAAG,IAAI,IAAI,SAAS,KAAK,CAAa,CAAC;AACjD;","names":[]}

package/dist/intents/archetype-flow.d.ts

@@ -0,0 +1,146 @@
+import type { LucideIcon } from 'lucide-react';
+/**
+ * How an archetype shapes the flow.
+ *
+ * Two registries used to live in this file and both are gone. NEEDS assembled a
+ * per-archetype "details" screen that asked one required question (country, now
+ * guessed from the browser and confirmed on screen one) and one optional one.
+ * FIRST_OBJECT drove an activation screen offering to create the merchant's
+ * first product, booking or invoice; the dashboard they land in offers exactly
+ * that, with the real form rather than a link to it.
+ *
+ * ---------------------------------------------------------------------------
+ *
+ * The one archetype that is not a commerce archetype.
+ *
+ * potter-api models this first-class and exclusively: provision does
+ * `isBioIntent ? [] : resolveIntentBehaviors(...)`, so picking bio means ZERO
+ * commerce behaviors plus `bioSettings.enabled`. Selecting it alongside
+ * "Sell products online" would silently zero out the shop, which is why the
+ * picker treats it as exclusive rather than as one more chip in the grid.
+ *
+ * It deliberately has no IntentConfig. The registry's shape is built around
+ * order lists, item lists, columns and stats, and the smallest real config is
+ * 274 lines of it; writing that for a creator with no orders would put "Link in
+ * bio" in front of every `getAllIntentConfigs()` consumer as though it were a
+ * commerce model. The cost of leaving it out is that `useIntentConfig` finds no
+ * config and falls back to defaultCommerceConfig for the order/item page
+ * shells. Those pages are unreachable for a tenant with no behaviors, so the
+ * fallback is inert, but it is a fallback and not a decision.
+ */
+export declare const BIO_INTENT = "bio";
+/**
+ * Is the link in bio this merchant's whole business model?
+ *
+ * Read from `selectedIntents` — the business model the merchant picked and can
+ * still change in Settings — and NOT from `bioSettings.enabled`, which the bio
+ * editor writes for anyone who builds a bio page beside a real shop. Because
+ * the intent is exclusive, seeing it at all means it is the only one.
+ *
+ * `useIntentConfig` cannot answer this: bio has no IntentConfig, so a bio
+ * tenant resolves to `defaultCommerceConfig` like any tenant with no picks.
+ */
+export declare function isBioOnly(settings: Record<string, unknown> | undefined): boolean;
+/**
+ * Sales channel is a refinement OF an archetype, not a peer question. It only
+ * means anything for the archetypes that could plausibly go either way — a
+ * digital download is never "in person", and a dine-in service is never
+ * anything else.
+ */
+export declare function channelApplies(intents: string[]): boolean;
+/** Falls back to the general store, which every archetype can operate from. */
+export declare const FALLBACK_TEMPLATE = "standard-store-01";
+export declare function templateForIntents(intents: string[]): string;
+/**
+ * The template to preselect, resolved against the shelf the merchant can see.
+ *
+ * THE RULE THIS ENFORCES: never recommend something that is not on screen. A
+ * recommendation the merchant cannot see is not a recommendation, it is the
+ * template being chosen behind their back — the exact failure the template step
+ * was added to end. Returning null is a valid answer and means "let them choose".
+ *
+ * Order: the named preference if it is really there, then the first template
+ * that can do what this archetype needs, then nothing. Deliberately NOT
+ * "fall back to the first tile" — a cosmetics store preselected for a padel
+ * club is a worse lie than no preselection, because it looks considered.
+ */
+/**
+ * Whether a template has said ANYTHING about what it can present.
+ *
+ * `archetypes` is what the registry derives from the pages a template actually
+ * ships — not `behaviors`, which lagoon-house-01 and listening-room-01 declare
+ * identically while being nothing alike, and which is how a property business
+ * was provisioned onto a listening bar.
+ *
+ * Its absence is the normal case today rather than an edge, so it gets a name:
+ * see the two functions below, which read the same silence in opposite
+ * directions on purpose.
+ */
+export declare function declaresCoverage(template: {
+    archetypes?: string[] | null;
+}): boolean;
+/**
+ * What a template cannot show this business — a WARNING, so silence is silence.
+ *
+ * This used to read `archetypes ?? []` and difference against the empty set,
+ * which reports EVERY archetype as missing on a template that never declared
+ * any. The comment above it claimed the opposite ("claims nothing rather than
+ * everything") and the code did the everything.
+ *
+ * That would be a defensible reading if the field were populated. It is not:
+ * the surfaces work that emits `archetypes` landed on web-render `staging`
+ * (60466ab), and web-render deploys `develop`, which has never carried it — and
+ * the templates-table fallback does not carry it either. So the registry
+ * declares coverage on NOTHING, and every tile in the gallery read "No page for
+ * products" underneath a storefront whose only page is products.
+ *
+ * A note that is wrong on every template is worse than no note, because by the
+ * time it is right nobody is reading it. It switches back on per template, the
+ * moment that template declares anything.
+ */
+export declare function missingFor(template: {
+    archetypes?: string[] | null;
+}, intents: string[]): string[];
+/**
+ * Has this template PROVEN it can present everything the business runs?
+ *
+ * Deliberately not `missingFor(...).length === 0`, and the difference is the
+ * whole point: the two answer opposite questions about the same silence.
+ * `missingFor` warns a merchant, so an undeclared template earns no warning.
+ * This one picks for them, so an undeclared template earns no recommendation —
+ * matching on a claim nobody made is how a short-let was provisioned onto a
+ * listening bar. Absence of evidence, in the direction that costs nothing.
+ */
+export declare function covers(template: {
+    archetypes?: string[] | null;
+}, intents: string[]): boolean;
+export declare function recommendTemplate(intents: string[], catalogue: {
+    id: string;
+    behaviors?: string[] | null;
+    archetypes?: string[] | null;
+}[]): string | null;
+/**
+ * The first real object worth creating, per archetype.
+ *
+ * This drove an activation SCREEN once, and deleting that screen was right: a
+ * step in a linear flow, offering to create something before the merchant had
+ * seen the app, competing with the dashboard's own SetupCards. The registry
+ * itself was never the problem. It is the one action on the arrival modal now,
+ * where it is the payoff rather than a gate.
+ */
+/** The first real object worth creating, per archetype. Drives activation. */
+export interface FirstObject {
+    noun: string;
+    cta: string;
+    href: string;
+    icon: LucideIcon;
+    blurb: string;
+}
+export declare function firstObjectFor(primary: string | undefined): FirstObject;
+export declare function shelfForIntents<T extends {
+    id: string;
+    behaviors?: string[] | null;
+}>(templates: T[], intents: string[]): {
+    shelf: T[];
+    narrowed: boolean;
+};

package/dist/intents/archetype-flow.js

@@ -0,0 +1,185 @@
+import { AtSign, CalendarClock, MapPin, Package } from "lucide-react";
+const BIO_INTENT = "bio";
+function isBioOnly(settings) {
+  const intents = settings?.selectedIntents;
+  return Array.isArray(intents) && intents.includes(BIO_INTENT);
+}
+function channelApplies(intents) {
+  return intents.some((i) => i === "sell-products" || i === "food-orders");
+}
+const TEMPLATE_BY_INTENT = {
+  "sell-products": "standard-store-01",
+  "event-tickets": "ebe-events-01",
+  "rent-property": "lagoon-house-01"
+  // No dining preference. `ezinulo-dining-01` sounds like one and is not: its
+  // pages are /venues, /venues/:slug and /private-events, so the registry
+  // reports it as rent-property. Naming it here would have been the same
+  // mistake as `food-classic`, made twice in one day.
+  //
+  // Nothing is written for dine-in yet, so it falls through to coverage, which
+  // finds whichever template actually ships a menu.
+  // Intents with NO named preference fall through to the behavior match below,
+  // which is the honest answer when no template is really written for them.
+  //
+  // `services-pro`, `creator-digital`, `stay-and-events` and `food-classic`
+  // used to sit here and NONE of them has ever existed in the registry. A dead
+  // id fails the `catalogue.some` check silently and drops to the behavior
+  // fallback, which is how a short-let business was provisioned onto a
+  // listening bar: both are `bookable`, and `find` returns whichever the
+  // registry happened to list first. Naming a template that does not exist is
+  // worse than naming none, because it reads as a decision.
+};
+const FALLBACK_TEMPLATE = "standard-store-01";
+function templateForIntents(intents) {
+  return TEMPLATE_BY_INTENT[intents[0] ?? ""] ?? FALLBACK_TEMPLATE;
+}
+const BEHAVIOR_BY_INTENT = {
+  "take-bookings": "bookable",
+  // NOT `bookable`. A listening bar, a salon and a padel court are all
+  // bookable, so matching on it hands a short-let whichever of them the
+  // registry lists first. `rentable` is the behavior that actually means
+  // "sells time in a space by the night or the day".
+  "rent-property": "rentable",
+  "dine-in": "bookable",
+  "capture-leads": "bookable",
+  "send-invoices": "bookable",
+  "event-tickets": "ticketed",
+  "sell-products": "shippable",
+  "food-orders": "sellable",
+  "digital-products": "sellable",
+  subscriptions: "sellable"
+};
+function declaresCoverage(template) {
+  return !!template.archetypes && template.archetypes.length > 0;
+}
+function missingFor(template, intents) {
+  if (!declaresCoverage(template)) return [];
+  const covered = new Set(template.archetypes);
+  return intents.filter((i) => !covered.has(i));
+}
+function covers(template, intents) {
+  if (!declaresCoverage(template)) return false;
+  return missingFor(template, intents).length === 0;
+}
+function recommendTemplate(intents, catalogue) {
+  if (catalogue.length === 0) return null;
+  const preferred = TEMPLATE_BY_INTENT[intents[0] ?? ""];
+  if (preferred && catalogue.some((t) => t.id === preferred)) return preferred;
+  const active = intents.filter(Boolean);
+  if (active.length > 0) {
+    const fits = catalogue.find((t) => covers(t, active));
+    if (fits) return fits.id;
+  }
+  if (preferred && process.env.NODE_ENV !== "production") {
+    console.warn(
+      `[archetype-flow] TEMPLATE_BY_INTENT names "${preferred}" for intent "${intents[0]}", but no such template is in the catalogue. Falling back to a behavior match, which is arbitrary between templates that share it.`
+    );
+  }
+  const needed = BEHAVIOR_BY_INTENT[intents[0] ?? ""];
+  if (!needed) return null;
+  return catalogue.find((t) => t.behaviors?.includes(needed))?.id ?? null;
+}
+const FIRST_OBJECT = {
+  "sell-products": {
+    noun: "product",
+    cta: "Add your first product",
+    href: "/dashboard/catalog/new",
+    icon: Package,
+    blurb: "A name, a price, a photo. You can refine it later."
+  },
+  "take-bookings": {
+    noun: "bookable service",
+    cta: "Add something to book",
+    href: "/dashboard/resources",
+    icon: CalendarClock,
+    blurb: "A court, a room, a chair. Whatever customers reserve."
+  },
+  "rent-property": {
+    noun: "space",
+    cta: "Add your first space",
+    href: "/dashboard/resources",
+    icon: MapPin,
+    blurb: "The place people book. Photos and rates can come later."
+  },
+  "food-orders": {
+    noun: "menu item",
+    cta: "Add your first menu item",
+    href: "/dashboard/catalog/new",
+    icon: Package,
+    blurb: "One dish is enough to take an order."
+  },
+  "dine-in": {
+    noun: "table",
+    cta: "Set up your tables",
+    href: "/dashboard/resources",
+    icon: MapPin,
+    blurb: "Tables you can seat a guest at and run a tab on."
+  },
+  "digital-products": {
+    noun: "download",
+    cta: "Add your first download",
+    href: "/dashboard/catalog/new",
+    icon: Package,
+    blurb: "Upload the file and set a price."
+  },
+  subscriptions: {
+    noun: "plan",
+    cta: "Create your first plan",
+    href: "/dashboard/catalog/new",
+    icon: Package,
+    blurb: "What members pay for, and how often."
+  },
+  "event-tickets": {
+    noun: "event",
+    cta: "Create your first event",
+    href: "/dashboard/catalog/new",
+    icon: Package,
+    blurb: "A date, a place, and what a ticket costs."
+  },
+  "send-invoices": {
+    noun: "invoice",
+    cta: "Send your first invoice",
+    href: "/dashboard/invoices",
+    icon: Package,
+    blurb: "Bill a client and get paid into your account."
+  },
+  // Route matches the sidebar's "Link in bio" item, not the older
+  // /dashboard/bio, which both still exist.
+  [BIO_INTENT]: {
+    noun: "link",
+    cta: "Build your link in bio",
+    href: "/dashboard/business/bio",
+    icon: AtSign,
+    blurb: "One page holding everything you point people at."
+  }
+};
+function firstObjectFor(primary) {
+  return primary && FIRST_OBJECT[primary] || FIRST_OBJECT["sell-products"];
+}
+const ROW = 4;
+function shelfForIntents(templates, intents) {
+  const wanted = new Set(
+    intents.map((i) => BEHAVIOR_BY_INTENT[i]).filter(Boolean)
+  );
+  if (wanted.size === 0) return { shelf: templates, narrowed: false };
+  const matches = templates.filter(
+    (t) => (t.behaviors ?? []).some((b) => wanted.has(b))
+  );
+  if (matches.length >= ROW) return { shelf: matches, narrowed: true };
+  const rest = templates.filter((t) => !matches.includes(t));
+  return { shelf: [...matches, ...rest], narrowed: false };
+}
+export {
+  BIO_INTENT,
+  FALLBACK_TEMPLATE,
+  channelApplies,
+  covers,
+  declaresCoverage,
+  firstObjectFor,
+  isBioOnly,
+  missingFor,
+  recommendTemplate,
+  shelfForIntents,
+  templateForIntents
+};
+//# sourceMappingURL=archetype-flow.js.map

package/dist/intents/archetype-flow.js.map

@@ -0,0 +1 @@
+{"version":3,"sources":["../../src/intents/archetype-flow.ts"],"sourcesContent":["import type { LucideIcon } from 'lucide-react';\nimport { AtSign, CalendarClock, MapPin, Package } from 'lucide-react';\n\n/**\n * How an archetype shapes the flow.\n *\n * Two registries used to live in this file and both are gone. NEEDS assembled a\n * per-archetype \"details\" screen that asked one required question (country, now\n * guessed from the browser and confirmed on screen one) and one optional one.\n * FIRST_OBJECT drove an activation screen offering to create the merchant's\n * first product, booking or invoice; the dashboard they land in offers exactly\n * that, with the real form rather than a link to it.\n *\n * ---------------------------------------------------------------------------\n *\n * The one archetype that is not a commerce archetype.\n *\n * potter-api models this first-class and exclusively: provision does\n * `isBioIntent ? [] : resolveIntentBehaviors(...)`, so picking bio means ZERO\n * commerce behaviors plus `bioSettings.enabled`. Selecting it alongside\n * \"Sell products online\" would silently zero out the shop, which is why the\n * picker treats it as exclusive rather than as one more chip in the grid.\n *\n * It deliberately has no IntentConfig. The registry's shape is built around\n * order lists, item lists, columns and stats, and the smallest real config is\n * 274 lines of it; writing that for a creator with no orders would put \"Link in\n * bio\" in front of every `getAllIntentConfigs()` consumer as though it were a\n * commerce model. The cost of leaving it out is that `useIntentConfig` finds no\n * config and falls back to defaultCommerceConfig for the order/item page\n * shells. Those pages are unreachable for a tenant with no behaviors, so the\n * fallback is inert, but it is a fallback and not a decision.\n */\nexport const BIO_INTENT = 'bio';\n\n/**\n * Is the link in bio this merchant's whole business model?\n *\n * Read from `selectedIntents` — the business model the merchant picked and can\n * still change in Settings — and NOT from `bioSettings.enabled`, which the bio\n * editor writes for anyone who builds a bio page beside a real shop. Because\n * the intent is exclusive, seeing it at all means it is the only one.\n *\n * `useIntentConfig` cannot answer this: bio has no IntentConfig, so a bio\n * tenant resolves to `defaultCommerceConfig` like any tenant with no picks.\n */\nexport function isBioOnly(settings: Record<string, unknown> | undefined) {\n  const intents = settings?.selectedIntents;\n  return Array.isArray(intents) && intents.includes(BIO_INTENT);\n}\n\n/**\n * Sales channel is a refinement OF an archetype, not a peer question. It only\n * means anything for the archetypes that could plausibly go either way — a\n * digital download is never \"in person\", and a dine-in service is never\n * anything else.\n */\nexport function channelApplies(intents: string[]): boolean {\n  return intents.some((i) => i === 'sell-products' || i === 'food-orders');\n}\n\n/**\n * The storefront template a business starts on.\n *\n * Onboarding used to ask. That question was removed as the most stalling one in\n * the set — a design decision demanded before there is a business to look at —\n * on the stated promise that \"archetypes pick a sensible default\". The promise\n * was never implemented: `templateId || 'default'` shipped on every provision,\n * and `default` is not a template. Provisioning rejected it, so from the moment\n * the template step was deleted, NO business could be created. A real signed-in\n * run is the only thing that surfaces this; the failure path looked healthy.\n *\n * THESE IDS DRIFT, AND FIVE OF THEM ARE ALREADY PHANTOMS. `services-pro`,\n * `creator-digital`, `stay-and-events` and `food-classic` are in no catalogue\n * the product serves — measured against the live registry, only\n * `standard-store-01` and `ebe-events-01` resolve. The map was written against a\n * catalogue someone intended to build, and nothing failed loudly when that\n * catalogue did not arrive: the template step happily preselected\n * `services-pro`, showed no tile as chosen because none matched, and left\n * Continue enabled.\n *\n * So this is a PREFERENCE, not an answer. `recommendTemplate` resolves it\n * against the templates actually on screen and falls back to matching by\n * behavior, which is the durable relationship — a bookings business needs a\n * `bookable` template, whatever it happens to be called this month.\n */\nconst TEMPLATE_BY_INTENT: Record<string, string> = {\n  'sell-products': 'standard-store-01',\n  'event-tickets': 'ebe-events-01',\n  'rent-property': 'lagoon-house-01',\n  // No dining preference. `ezinulo-dining-01` sounds like one and is not: its\n  // pages are /venues, /venues/:slug and /private-events, so the registry\n  // reports it as rent-property. Naming it here would have been the same\n  // mistake as `food-classic`, made twice in one day.\n  //\n  // Nothing is written for dine-in yet, so it falls through to coverage, which\n  // finds whichever template actually ships a menu.\n  // Intents with NO named preference fall through to the behavior match below,\n  // which is the honest answer when no template is really written for them.\n  //\n  // `services-pro`, `creator-digital`, `stay-and-events` and `food-classic`\n  // used to sit here and NONE of them has ever existed in the registry. A dead\n  // id fails the `catalogue.some` check silently and drops to the behavior\n  // fallback, which is how a short-let business was provisioned onto a\n  // listening bar: both are `bookable`, and `find` returns whichever the\n  // registry happened to list first. Naming a template that does not exist is\n  // worse than naming none, because it reads as a decision.\n};\n\n/** Falls back to the general store, which every archetype can operate from. */\nexport const FALLBACK_TEMPLATE = 'standard-store-01';\n\nexport function templateForIntents(intents: string[]): string {\n  return TEMPLATE_BY_INTENT[intents[0] ?? ''] ?? FALLBACK_TEMPLATE;\n}\n\n/**\n * What a template must be able to DO for each archetype.\n *\n * The durable half of the relationship. Template ids are named things that come\n * and go; `bookable` is a capability the registry declares on every template and\n * potter-api resolves into tenant behaviors. Matching on it means a padel club\n * gets whichever bookable template exists today rather than a name someone typed\n * into a map in March.\n */\nconst BEHAVIOR_BY_INTENT: Record<string, string> = {\n  'take-bookings': 'bookable',\n  // NOT `bookable`. A listening bar, a salon and a padel court are all\n  // bookable, so matching on it hands a short-let whichever of them the\n  // registry lists first. `rentable` is the behavior that actually means\n  // \"sells time in a space by the night or the day\".\n  'rent-property': 'rentable',\n  'dine-in': 'bookable',\n  'capture-leads': 'bookable',\n  'send-invoices': 'bookable',\n  'event-tickets': 'ticketed',\n  'sell-products': 'shippable',\n  'food-orders': 'sellable',\n  'digital-products': 'sellable',\n  subscriptions: 'sellable',\n};\n\n/**\n * The template to preselect, resolved against the shelf the merchant can see.\n *\n * THE RULE THIS ENFORCES: never recommend something that is not on screen. A\n * recommendation the merchant cannot see is not a recommendation, it is the\n * template being chosen behind their back — the exact failure the template step\n * was added to end. Returning null is a valid answer and means \"let them choose\".\n *\n * Order: the named preference if it is really there, then the first template\n * that can do what this archetype needs, then nothing. Deliberately NOT\n * \"fall back to the first tile\" — a cosmetics store preselected for a padel\n * club is a worse lie than no preselection, because it looks considered.\n */\n/**\n * Whether a template has said ANYTHING about what it can present.\n *\n * `archetypes` is what the registry derives from the pages a template actually\n * ships — not `behaviors`, which lagoon-house-01 and listening-room-01 declare\n * identically while being nothing alike, and which is how a property business\n * was provisioned onto a listening bar.\n *\n * Its absence is the normal case today rather than an edge, so it gets a name:\n * see the two functions below, which read the same silence in opposite\n * directions on purpose.\n */\nexport function declaresCoverage(template: {\n  archetypes?: string[] | null;\n}): boolean {\n  return !!template.archetypes && template.archetypes.length > 0;\n}\n\n/**\n * What a template cannot show this business — a WARNING, so silence is silence.\n *\n * This used to read `archetypes ?? []` and difference against the empty set,\n * which reports EVERY archetype as missing on a template that never declared\n * any. The comment above it claimed the opposite (\"claims nothing rather than\n * everything\") and the code did the everything.\n *\n * That would be a defensible reading if the field were populated. It is not:\n * the surfaces work that emits `archetypes` landed on web-render `staging`\n * (60466ab), and web-render deploys `develop`, which has never carried it — and\n * the templates-table fallback does not carry it either. So the registry\n * declares coverage on NOTHING, and every tile in the gallery read \"No page for\n * products\" underneath a storefront whose only page is products.\n *\n * A note that is wrong on every template is worse than no note, because by the\n * time it is right nobody is reading it. It switches back on per template, the\n * moment that template declares anything.\n */\nexport function missingFor(\n  template: { archetypes?: string[] | null },\n  intents: string[],\n): string[] {\n  if (!declaresCoverage(template)) return [];\n  const covered = new Set(template.archetypes);\n  return intents.filter((i) => !covered.has(i));\n}\n\n/**\n * Has this template PROVEN it can present everything the business runs?\n *\n * Deliberately not `missingFor(...).length === 0`, and the difference is the\n * whole point: the two answer opposite questions about the same silence.\n * `missingFor` warns a merchant, so an undeclared template earns no warning.\n * This one picks for them, so an undeclared template earns no recommendation —\n * matching on a claim nobody made is how a short-let was provisioned onto a\n * listening bar. Absence of evidence, in the direction that costs nothing.\n */\nexport function covers(\n  template: { archetypes?: string[] | null },\n  intents: string[],\n): boolean {\n  if (!declaresCoverage(template)) return false;\n  return missingFor(template, intents).length === 0;\n}\n\nexport function recommendTemplate(\n  intents: string[],\n  catalogue: {\n    id: string;\n    behaviors?: string[] | null;\n    archetypes?: string[] | null;\n  }[],\n): string | null {\n  if (catalogue.length === 0) return null;\n\n  const preferred = TEMPLATE_BY_INTENT[intents[0] ?? ''];\n  if (preferred && catalogue.some((t) => t.id === preferred)) return preferred;\n\n  // Coverage first: the template that can present everything this business\n  // runs. This is the answer the old behavior match was groping at — it took\n  // the first template sharing ONE behavior, which is how `bookable` handed a\n  // short-let a listening bar.\n  const active = intents.filter(Boolean);\n  if (active.length > 0) {\n    const fits = catalogue.find((t) => covers(t, active));\n    if (fits) return fits.id;\n  }\n\n  // A named preference that is not on the shelf is a bug in this file, not a\n  // fact about the merchant, and it used to fail completely silently: the id\n  // simply lost the `some` check and the behavior fallback picked someone\n  // else's template. Say so where a developer will see it.\n  if (preferred && process.env.NODE_ENV !== 'production') {\n    console.warn(\n      `[archetype-flow] TEMPLATE_BY_INTENT names \"${preferred}\" for intent ` +\n        `\"${intents[0]}\", but no such template is in the catalogue. Falling ` +\n        `back to a behavior match, which is arbitrary between templates that ` +\n        `share it.`,\n    );\n  }\n\n  const needed = BEHAVIOR_BY_INTENT[intents[0] ?? ''];\n  if (!needed) return null;\n  return catalogue.find((t) => t.behaviors?.includes(needed))?.id ?? null;\n}\n\n/**\n * The first real object worth creating, per archetype.\n *\n * This drove an activation SCREEN once, and deleting that screen was right: a\n * step in a linear flow, offering to create something before the merchant had\n * seen the app, competing with the dashboard's own SetupCards. The registry\n * itself was never the problem. It is the one action on the arrival modal now,\n * where it is the payoff rather than a gate.\n */\n/** The first real object worth creating, per archetype. Drives activation. */\nexport interface FirstObject {\n  noun: string;\n  cta: string;\n  href: string;\n  icon: LucideIcon;\n  blurb: string;\n}\n\nconst FIRST_OBJECT: Record<string, FirstObject> = {\n  'sell-products': {\n    noun: 'product',\n    cta: 'Add your first product',\n    href: '/dashboard/catalog/new',\n    icon: Package,\n    blurb: 'A name, a price, a photo. You can refine it later.',\n  },\n  'take-bookings': {\n    noun: 'bookable service',\n    cta: 'Add something to book',\n    href: '/dashboard/resources',\n    icon: CalendarClock,\n    blurb: 'A court, a room, a chair. Whatever customers reserve.',\n  },\n  'rent-property': {\n    noun: 'space',\n    cta: 'Add your first space',\n    href: '/dashboard/resources',\n    icon: MapPin,\n    blurb: 'The place people book. Photos and rates can come later.',\n  },\n  'food-orders': {\n    noun: 'menu item',\n    cta: 'Add your first menu item',\n    href: '/dashboard/catalog/new',\n    icon: Package,\n    blurb: 'One dish is enough to take an order.',\n  },\n  'dine-in': {\n    noun: 'table',\n    cta: 'Set up your tables',\n    href: '/dashboard/resources',\n    icon: MapPin,\n    blurb: 'Tables you can seat a guest at and run a tab on.',\n  },\n  'digital-products': {\n    noun: 'download',\n    cta: 'Add your first download',\n    href: '/dashboard/catalog/new',\n    icon: Package,\n    blurb: 'Upload the file and set a price.',\n  },\n  subscriptions: {\n    noun: 'plan',\n    cta: 'Create your first plan',\n    href: '/dashboard/catalog/new',\n    icon: Package,\n    blurb: 'What members pay for, and how often.',\n  },\n  'event-tickets': {\n    noun: 'event',\n    cta: 'Create your first event',\n    href: '/dashboard/catalog/new',\n    icon: Package,\n    blurb: 'A date, a place, and what a ticket costs.',\n  },\n  'send-invoices': {\n    noun: 'invoice',\n    cta: 'Send your first invoice',\n    href: '/dashboard/invoices',\n    icon: Package,\n    blurb: 'Bill a client and get paid into your account.',\n  },\n  // Route matches the sidebar's \"Link in bio\" item, not the older\n  // /dashboard/bio, which both still exist.\n  [BIO_INTENT]: {\n    noun: 'link',\n    cta: 'Build your link in bio',\n    href: '/dashboard/business/bio',\n    icon: AtSign,\n    blurb: 'One page holding everything you point people at.',\n  },\n};\n\nexport function firstObjectFor(primary: string | undefined): FirstObject {\n  return (primary && FIRST_OBJECT[primary]) || FIRST_OBJECT['sell-products'];\n}\n\n/**\n * The shelf, narrowed to what the business actually said it does.\n *\n * John, 2026-09-08: *\"that intent shoudl also define the templates we show, if\n * you choose sell products then the templates we show shoudl only be templates\n * that enable that intent\"*.\n *\n * ── WHY `behaviors` AND NOT `archetypes` ──\n *\n * `archetypes` is the better field and `missingFor` above says so at length. It\n * is also EMPTY on every template the live registry serves: the surfaces work\n * that emits it landed on web-render `staging` and web-render deploys\n * `develop`. Filtering on a field nothing populates does not narrow a shelf, it\n * empties one. `behaviors` is declared on all 26 templates today, so it is what\n * this can actually match on. Swap when the registry catches up.\n *\n * ── WHY IT DOES NOT ALWAYS NARROW ──\n *\n * Counted against the real catalogue: sell-products matches 22 templates,\n * take-bookings 11, memberships 6, tickets 4, rent-a-space 3, menu 3 — and\n * invoicing and enquiries match NOTHING. A strict filter on the last two hands\n * a merchant an empty shelf on the last screen of onboarding, which is worse\n * than a broad one.\n *\n * So the rule is a floor, not a switch: narrow when there is enough left to\n * fill a row of the grid, otherwise show everything with the matches first.\n * A merchant is never shown less than a row, and never shown a lie about what\n * exists.\n */\nconst ROW = 4;\n\nexport function shelfForIntents<\n  T extends { id: string; behaviors?: string[] | null },\n>(templates: T[], intents: string[]): { shelf: T[]; narrowed: boolean } {\n  const wanted = new Set(\n    intents.map((i) => BEHAVIOR_BY_INTENT[i]).filter(Boolean),\n  );\n  if (wanted.size === 0) return { shelf: templates, narrowed: false };\n\n  const matches = templates.filter((t) =>\n    (t.behaviors ?? []).some((b) => wanted.has(b)),\n  );\n  if (matches.length >= ROW) return { shelf: matches, narrowed: true };\n\n  const rest = templates.filter((t) => !matches.includes(t));\n  return { shelf: [...matches, ...rest], narrowed: false };\n}\n"],"mappings":"AACA,SAAS,QAAQ,eAAe,QAAQ,eAAe;AA+BhD,MAAM,aAAa;AAanB,SAAS,UAAU,UAA+C;AACvE,QAAM,UAAU,UAAU;AAC1B,SAAO,MAAM,QAAQ,OAAO,KAAK,QAAQ,SAAS,UAAU;AAC9D;AAQO,SAAS,eAAe,SAA4B;AACzD,SAAO,QAAQ,KAAK,CAAC,MAAM,MAAM,mBAAmB,MAAM,aAAa;AACzE;AA2BA,MAAM,qBAA6C;AAAA,EACjD,iBAAiB;AAAA,EACjB,iBAAiB;AAAA,EACjB,iBAAiB;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAkBnB;AAGO,MAAM,oBAAoB;AAE1B,SAAS,mBAAmB,SAA2B;AAC5D,SAAO,mBAAmB,QAAQ,CAAC,KAAK,EAAE,KAAK;AACjD;AAWA,MAAM,qBAA6C;AAAA,EACjD,iBAAiB;AAAA;AAAA;AAAA;AAAA;AAAA,EAKjB,iBAAiB;AAAA,EACjB,WAAW;AAAA,EACX,iBAAiB;AAAA,EACjB,iBAAiB;AAAA,EACjB,iBAAiB;AAAA,EACjB,iBAAiB;AAAA,EACjB,eAAe;AAAA,EACf,oBAAoB;AAAA,EACpB,eAAe;AACjB;AA2BO,SAAS,iBAAiB,UAErB;AACV,SAAO,CAAC,CAAC,SAAS,cAAc,SAAS,WAAW,SAAS;AAC/D;AAqBO,SAAS,WACd,UACA,SACU;AACV,MAAI,CAAC,iBAAiB,QAAQ,EAAG,QAAO,CAAC;AACzC,QAAM,UAAU,IAAI,IAAI,SAAS,UAAU;AAC3C,SAAO,QAAQ,OAAO,CAAC,MAAM,CAAC,QAAQ,IAAI,CAAC,CAAC;AAC9C;AAYO,SAAS,OACd,UACA,SACS;AACT,MAAI,CAAC,iBAAiB,QAAQ,EAAG,QAAO;AACxC,SAAO,WAAW,UAAU,OAAO,EAAE,WAAW;AAClD;AAEO,SAAS,kBACd,SACA,WAKe;AACf,MAAI,UAAU,WAAW,EAAG,QAAO;AAEnC,QAAM,YAAY,mBAAmB,QAAQ,CAAC,KAAK,EAAE;AACrD,MAAI,aAAa,UAAU,KAAK,CAAC,MAAM,EAAE,OAAO,SAAS,EAAG,QAAO;AAMnE,QAAM,SAAS,QAAQ,OAAO,OAAO;AACrC,MAAI,OAAO,SAAS,GAAG;AACrB,UAAM,OAAO,UAAU,KAAK,CAAC,MAAM,OAAO,GAAG,MAAM,CAAC;AACpD,QAAI,KAAM,QAAO,KAAK;AAAA,EACxB;AAMA,MAAI,aAAa,QAAQ,IAAI,aAAa,cAAc;AACtD,YAAQ;AAAA,MACN,8CAA8C,SAAS,iBACjD,QAAQ,CAAC,CAAC;AAAA,IAGlB;AAAA,EACF;AAEA,QAAM,SAAS,mBAAmB,QAAQ,CAAC,KAAK,EAAE;AAClD,MAAI,CAAC,OAAQ,QAAO;AACpB,SAAO,UAAU,KAAK,CAAC,MAAM,EAAE,WAAW,SAAS,MAAM,CAAC,GAAG,MAAM;AACrE;AAoBA,MAAM,eAA4C;AAAA,EAChD,iBAAiB;AAAA,IACf,MAAM;AAAA,IACN,KAAK;AAAA,IACL,MAAM;AAAA,IACN,MAAM;AAAA,IACN,OAAO;AAAA,EACT;AAAA,EACA,iBAAiB;AAAA,IACf,MAAM;AAAA,IACN,KAAK;AAAA,IACL,MAAM;AAAA,IACN,MAAM;AAAA,IACN,OAAO;AAAA,EACT;AAAA,EACA,iBAAiB;AAAA,IACf,MAAM;AAAA,IACN,KAAK;AAAA,IACL,MAAM;AAAA,IACN,MAAM;AAAA,IACN,OAAO;AAAA,EACT;AAAA,EACA,eAAe;AAAA,IACb,MAAM;AAAA,IACN,KAAK;AAAA,IACL,MAAM;AAAA,IACN,MAAM;AAAA,IACN,OAAO;AAAA,EACT;AAAA,EACA,WAAW;AAAA,IACT,MAAM;AAAA,IACN,KAAK;AAAA,IACL,MAAM;AAAA,IACN,MAAM;AAAA,IACN,OAAO;AAAA,EACT;AAAA,EACA,oBAAoB;AAAA,IAClB,MAAM;AAAA,IACN,KAAK;AAAA,IACL,MAAM;AAAA,IACN,MAAM;AAAA,IACN,OAAO;AAAA,EACT;AAAA,EACA,eAAe;AAAA,IACb,MAAM;AAAA,IACN,KAAK;AAAA,IACL,MAAM;AAAA,IACN,MAAM;AAAA,IACN,OAAO;AAAA,EACT;AAAA,EACA,iBAAiB;AAAA,IACf,MAAM;AAAA,IACN,KAAK;AAAA,IACL,MAAM;AAAA,IACN,MAAM;AAAA,IACN,OAAO;AAAA,EACT;AAAA,EACA,iBAAiB;AAAA,IACf,MAAM;AAAA,IACN,KAAK;AAAA,IACL,MAAM;AAAA,IACN,MAAM;AAAA,IACN,OAAO;AAAA,EACT;AAAA;AAAA;AAAA,EAGA,CAAC,UAAU,GAAG;AAAA,IACZ,MAAM;AAAA,IACN,KAAK;AAAA,IACL,MAAM;AAAA,IACN,MAAM;AAAA,IACN,OAAO;AAAA,EACT;AACF;AAEO,SAAS,eAAe,SAA0C;AACvE,SAAQ,WAAW,aAAa,OAAO,KAAM,aAAa,eAAe;AAC3E;AA+BA,MAAM,MAAM;AAEL,SAAS,gBAEd,WAAgB,SAAsD;AACtE,QAAM,SAAS,IAAI;AAAA,IACjB,QAAQ,IAAI,CAAC,MAAM,mBAAmB,CAAC,CAAC,EAAE,OAAO,OAAO;AAAA,EAC1D;AACA,MAAI,OAAO,SAAS,EAAG,QAAO,EAAE,OAAO,WAAW,UAAU,MAAM;AAElE,QAAM,UAAU,UAAU;AAAA,IAAO,CAAC,OAC/B,EAAE,aAAa,CAAC,GAAG,KAAK,CAAC,MAAM,OAAO,IAAI,CAAC,CAAC;AAAA,EAC/C;AACA,MAAI,QAAQ,UAAU,IAAK,QAAO,EAAE,OAAO,SAAS,UAAU,KAAK;AAEnE,QAAM,OAAO,UAAU,OAAO,CAAC,MAAM,CAAC,QAAQ,SAAS,CAAC,CAAC;AACzD,SAAO,EAAE,OAAO,CAAC,GAAG,SAAS,GAAG,IAAI,GAAG,UAAU,MAAM;AACzD;","names":[]}

package/dist/intents/booking-query-style.d.ts

@@ -0,0 +1,32 @@
+import type { BookingQueryStyle, IntentConfig } from './types';
+/**
+ * What kinds of booking the diary shows, for a business that books more than
+ * one kind of thing.
+ *
+ * `queryStyle` is not wording. `bookingTypes` and `bookingModes` go into the
+ * request as filters (`use-bookings-data.ts`), so the archetype that supplies
+ * it decides which rows come back at all — and both readers took it from
+ * `intentConfig.primary`.
+ *
+ * `primary` on an unscoped view is whichever key last rode an `?intent=` into
+ * sessionStorage. A restaurant that seats guests and ticketets its Friday night
+ * declares `table` + `resource` + `appointment` under dine-in and `event` under
+ * event-tickets. Open Attendees once, come back to the diary without a param,
+ * and the query narrows to `type=event`: every table reservation the restaurant
+ * has silently vanishes, and "New booking" offers Event as the only thing you
+ * can create. Nothing errors and the list is not empty, which is the worst
+ * shape this bug could take — it looks like a quiet evening.
+ *
+ * So the diary asks every archetype on screen. The allowed sets are unioned;
+ * an archetype that books nothing (`food-orders`, `subscriptions`) declares no
+ * queryStyle and contributes nothing, which is right — it has no rows here.
+ *
+ * The defaults for a NEW booking cannot be unioned, so they come from the first
+ * archetype in `active` that books. That is `all` order — the merchant's own
+ * pick order, fixed at onboarding — and never sessionStorage, so the create
+ * form stops changing what it offers based on where you last clicked.
+ *
+ * Returns undefined when nothing on screen books, leaving the caller's own
+ * default in place rather than sending empty filters that mean "everything".
+ */
+export declare function resolveBookingQueryStyle(configs: Pick<IntentConfig, 'key' | 'queryStyle'>[]): BookingQueryStyle | undefined;

package/dist/intents/booking-query-style.js

@@ -0,0 +1,22 @@
+function resolveBookingQueryStyle(configs) {
+  const booking = configs.flatMap(
+    (config) => config.queryStyle ? [config.queryStyle] : []
+  );
+  if (!booking.length) return void 0;
+  if (booking.length === 1) return booking[0];
+  const [first] = booking;
+  return {
+    // Names the set rather than borrowing one archetype's key, which is read
+    // back in `use-bookings-data` to reset the controls when the diary changes
+    // shape — and a combined diary is not any single archetype's shape.
+    key: booking.map((style) => style.key).join("+"),
+    bookingTypes: [...new Set(booking.flatMap((style) => style.bookingTypes))],
+    bookingModes: [...new Set(booking.flatMap((style) => style.bookingModes))],
+    defaultBookingType: first.defaultBookingType,
+    defaultBookingMode: first.defaultBookingMode
+  };
+}
+export {
+  resolveBookingQueryStyle
+};
+//# sourceMappingURL=booking-query-style.js.map

package/dist/intents/booking-query-style.js.map

@@ -0,0 +1 @@
+{"version":3,"sources":["../../src/intents/booking-query-style.ts"],"sourcesContent":["import type { BookingQueryStyle, IntentConfig } from './types';\n\n/**\n * What kinds of booking the diary shows, for a business that books more than\n * one kind of thing.\n *\n * `queryStyle` is not wording. `bookingTypes` and `bookingModes` go into the\n * request as filters (`use-bookings-data.ts`), so the archetype that supplies\n * it decides which rows come back at all — and both readers took it from\n * `intentConfig.primary`.\n *\n * `primary` on an unscoped view is whichever key last rode an `?intent=` into\n * sessionStorage. A restaurant that seats guests and ticketets its Friday night\n * declares `table` + `resource` + `appointment` under dine-in and `event` under\n * event-tickets. Open Attendees once, come back to the diary without a param,\n * and the query narrows to `type=event`: every table reservation the restaurant\n * has silently vanishes, and \"New booking\" offers Event as the only thing you\n * can create. Nothing errors and the list is not empty, which is the worst\n * shape this bug could take — it looks like a quiet evening.\n *\n * So the diary asks every archetype on screen. The allowed sets are unioned;\n * an archetype that books nothing (`food-orders`, `subscriptions`) declares no\n * queryStyle and contributes nothing, which is right — it has no rows here.\n *\n * The defaults for a NEW booking cannot be unioned, so they come from the first\n * archetype in `active` that books. That is `all` order — the merchant's own\n * pick order, fixed at onboarding — and never sessionStorage, so the create\n * form stops changing what it offers based on where you last clicked.\n *\n * Returns undefined when nothing on screen books, leaving the caller's own\n * default in place rather than sending empty filters that mean \"everything\".\n */\nexport function resolveBookingQueryStyle(\n  configs: Pick<IntentConfig, 'key' | 'queryStyle'>[],\n): BookingQueryStyle | undefined {\n  const booking = configs.flatMap((config) =>\n    config.queryStyle ? [config.queryStyle] : [],\n  );\n  if (!booking.length) return undefined;\n  if (booking.length === 1) return booking[0];\n\n  const [first] = booking;\n  return {\n    // Names the set rather than borrowing one archetype's key, which is read\n    // back in `use-bookings-data` to reset the controls when the diary changes\n    // shape — and a combined diary is not any single archetype's shape.\n    key: booking.map((style) => style.key).join('+'),\n    bookingTypes: [...new Set(booking.flatMap((style) => style.bookingTypes))],\n    bookingModes: [...new Set(booking.flatMap((style) => style.bookingModes))],\n    defaultBookingType: first.defaultBookingType,\n    defaultBookingMode: first.defaultBookingMode,\n  };\n}\n"],"mappings":"AAgCO,SAAS,yBACd,SAC+B;AAC/B,QAAM,UAAU,QAAQ;AAAA,IAAQ,CAAC,WAC/B,OAAO,aAAa,CAAC,OAAO,UAAU,IAAI,CAAC;AAAA,EAC7C;AACA,MAAI,CAAC,QAAQ,OAAQ,QAAO;AAC5B,MAAI,QAAQ,WAAW,EAAG,QAAO,QAAQ,CAAC;AAE1C,QAAM,CAAC,KAAK,IAAI;AAChB,SAAO;AAAA;AAAA;AAAA;AAAA,IAIL,KAAK,QAAQ,IAAI,CAAC,UAAU,MAAM,GAAG,EAAE,KAAK,GAAG;AAAA,IAC/C,cAAc,CAAC,GAAG,IAAI,IAAI,QAAQ,QAAQ,CAAC,UAAU,MAAM,YAAY,CAAC,CAAC;AAAA,IACzE,cAAc,CAAC,GAAG,IAAI,IAAI,QAAQ,QAAQ,CAAC,UAAU,MAAM,YAAY,CAAC,CAAC;AAAA,IACzE,oBAAoB,MAAM;AAAA,IAC1B,oBAAoB,MAAM;AAAA,EAC5B;AACF;","names":[]}

package/dist/intents/capture-leads.config.d.ts

@@ -0,0 +1,31 @@
+import type { IntentConfig } from './types';
+/**
+ * Enquire & Qualify — businesses whose whole model is the enquiry: estate
+ * agents, insurance brokers, schools taking admissions, B2B services.
+ *
+ * Nothing is sold from a catalogue and nothing is checked out. The thing that
+ * arrives is a person asking a question, and the work is answering, qualifying
+ * and following up until it becomes business elsewhere — a viewing, a policy,
+ * a place, a contract.
+ *
+ * The loop exists end to end and nothing here builds it: the API has inquiries
+ * with quote, follow-ups, stats and respond, and the Inquiries inbox is already
+ * in the sidebar for everyone, deliberately ungated, because leads arrive
+ * whether or not a merchant declared they wanted them.
+ *
+ * This comment used to claim that *every* storefront template ships a contact
+ * form that feeds it. Counted rather than assumed, it was ten of the sixteen
+ * built templates, and the misses included the portfolio — whose entire
+ * conversion is a commission. Written from intent rather than from a grep,
+ * which is the kind of claim worth checking before repeating.
+ *
+ * What was missing was a way to *say so* at onboarding. Without an intent,
+ * these businesses landed on the generic commerce shell and were handed a
+ * catalogue to fill and an Orders list that would never have a row in it.
+ *
+ * So: Orders is deliberately absent, exactly as it is for send-invoices. An
+ * always-empty Orders list reads as broken software, not as an empty state.
+ * The order entity labels still resolve for shared surfaces that ask for them
+ * (analytics, exports).
+ */
+export declare const captureLeadsConfig: IntentConfig;