@withpotter/lib 0.13.0-next.101

package/dist/intents/intent-nav.d.ts

@@ -0,0 +1,95 @@
+import { type LucideIcon } from 'lucide-react';
+/**
+ * What each archetype puts in the sidebar, and what each row is called.
+ *
+ * This list — not the intent configs — decides what a merchant can reach and
+ * what it is named. The configs supply the href and the permission; the label
+ * and the membership come from here. That asymmetry is deliberate (a config can
+ * declare a surface before the nav is ready for it) but it used to live inside
+ * sidebar.tsx, which meant nothing else could tell the truth about the nav.
+ *
+ * Onboarding previews exactly this, so the pages it promises while the merchant
+ * is picking archetypes are the pages the sidebar will actually render, under
+ * the names it will actually use. Drift between this and the configs is still
+ * shouted about in dev by warnOnUnreachableNavItems.
+ */
+export interface IntentNavDefinition {
+    key: string;
+    label: string;
+    groupIcon?: LucideIcon;
+    items: {
+        id: string;
+        label: string;
+        icon: LucideIcon;
+        /**
+         * What this item actually manages, in the merchant's words.
+         *
+         * A business that seats guests *and* does takeaway has one menu, not two,
+         * so both intents point at the same `shares: 'menu'` and the sidebar shows
+         * it once. Where two intents genuinely manage different things — a
+         * restaurant's menu and its retail shelf — the nouns differ and both stay.
+         *
+         * Omitted means "unique to this archetype" (Reservations, Tables, Tabs):
+         * only one intent ever contributes it, so there is nothing to collapse.
+         */
+        shares?: string;
+        /**
+         * Rows that live *under* this one, revealed by the sidebar's disclosure.
+         *
+         * An Operations row is often a surface with a smaller surface attached:
+         * Appointments has the queue of people who could not get one. Those are
+         * not peers — putting a Waitlist row beside Appointments says they are two
+         * equal destinations, when one is a state of the other. As children they
+         * stay one click away and cost the sidebar no height until opened.
+         */
+        children?: {
+            id: string;
+            label: string;
+            icon: LucideIcon;
+            /** Same meaning as on a top-level row: what this manages. */
+            shares?: string;
+        }[];
+        /**
+         * What this row's own screen is called once it has children.
+         *
+         * Required for any row that declares `children`: the disclosure rule moves
+         * the row's page into the group as its first child, and the renderer's
+         * "Overview" fallback exists only so a half-built hub renders rather than
+         * throwing. `{label}` interpolates the row's post-rename label.
+         */
+        landingLabel?: string;
+    }[];
+}
+/**
+ * NO CHILDREN UNDER ORDERS. Abandoned carts was the only one, and it moved to
+ * Marketing on John's call, 2026-09-03 — the argument is written where the row
+ * now lives, in `spine-groups`.
+ *
+ * The declaration is deleted rather than emptied. A `children: []` on eight
+ * archetypes is an invitation to nest the next thing that is *about* orders
+ * under Orders, which is how this one ended up here: an abandoned cart is an
+ * order that never happened, so it looked like an order's child. What a record
+ * IS decides its permission; what you come to DO with it decides its row.
+ *
+ * What the old note here was right about, kept because it will be true again
+ * the day something is genuinely nested: seven archetypes declare `orders`, it
+ * collapses to one row, and the folding archetypes' children are grafted onto
+ * the survivor — so an untagged child came out once per archetype. A musician
+ * selling shows, merch and downloads had one Orders row carrying four
+ * identical "Abandoned carts". Any future child needs `shares`.
+ */
+export declare const INTENT_NAV_DEFINITIONS: IntentNavDefinition[];
+/**
+ * The nav rows a set of archetypes adds, in sidebar order, de-duplicated.
+ *
+ * Two rules keep this honest, and both were broken when onboarding read the raw
+ * configs instead: an item only counts if the chosen intent's config actually
+ * declares it (the sidebar drops it otherwise), and only intent-group rows
+ * count at all. The fixed spine (Collections, Discounts, Invoices, Marketing,
+ * Website) is there for every merchant regardless of what they pick, so listing
+ * it as a consequence of a pick is a promise the pick did not make.
+ */
+export declare function intentNavRows(intentKeys: string[]): {
+    label: string;
+    icon: LucideIcon;
+}[];

package/dist/intents/intent-nav.js

@@ -0,0 +1,423 @@
+import {
+  Banknote,
+  BookOpen,
+  Building2,
+  CalendarClock,
+  CalendarRange,
+  BadgeCheck,
+  FileText,
+  Layers,
+  LayoutGrid,
+  ListChecks,
+  Package,
+  Receipt,
+  ReceiptText,
+  TicketCheck,
+  RefreshCw,
+  UtensilsCrossed,
+  Wrench,
+  MessageSquare
+} from "lucide-react";
+import { getIntentConfig, defaultCommerceConfig } from "./registry";
+import { BIO_INTENT } from "./archetype-flow";
+const INTENT_NAV_DEFINITIONS = [
+  // No Fulfillment row, for `default` or `sell-products`. Both used to list one
+  // and no config ever declared a `shipping` nav item, so the row could not be
+  // built and never was — the definition promised a work surface that does not
+  // exist. Shipping is a Settings page (Settings → Selling → Shipping), which
+  // is where the spine already puts it and where `nav-coverage` says it lives.
+  {
+    key: "default",
+    label: "Products",
+    items: [
+      { id: "catalog", label: "Inventory", icon: Package, shares: "catalogue" },
+      // "Orders", not "Product Orders". A qualifier earns its place by telling
+      // one archetype's queue from another's, and it is dropped the moment it
+      // does that job — multi mode collapses every contributor of `orders` to
+      // the plain noun. So the merchant running four archetypes read "Orders"
+      // and the shop running one read "Product Orders": the qualified label
+      // went to the only business with nothing to qualify against, one line
+      // under a group already called Products.
+      //
+      // Where the archetype's own word says something the generic cannot, it
+      // stays: a takeaway's "Kitchen Orders" names the queue it prints to.
+      {
+        id: "orders",
+        label: "Orders",
+        icon: Receipt,
+        shares: "orders",
+        landingLabel: "All {label}"
+      }
+    ]
+  },
+  {
+    key: "sell-products",
+    label: "Products",
+    items: [
+      { id: "catalog", label: "Inventory", icon: Package, shares: "catalogue" },
+      // See `default` above: the qualifier told this shop's orders from queues
+      // it does not run.
+      {
+        id: "orders",
+        label: "Orders",
+        icon: Receipt,
+        shares: "orders",
+        landingLabel: "All {label}"
+      }
+    ]
+  },
+  {
+    key: "digital-products",
+    label: "Digital products",
+    items: [
+      {
+        // Package, and the same shelf as Inventory. A print and a preset are
+        // both things this business sells, and they sell from ONE screen: every
+        // archetype's `catalog` resolves to /dashboard/catalog. Giving downloads
+        // their own row made a filter wear the clothes of a destination — and
+        // since `sell-products` claims the shelf first, that row was deleted
+        // anyway, taking the whole Digital Products heading with it. The
+        // narrowing lives on the page now, in exactly these nouns.
+        // "Products" and "Orders", not "Digital Catalog" and "Download
+        // Orders". Judged by the rule pass 1 set: a qualifier earns its place
+        // by telling one archetype's queue from another's, and for a business
+        // that only sells downloads there is nothing to tell apart —
+        // everything in the catalogue is digital and every order is a
+        // download. The group above already says Digital Products.
+        //
+        // Where a word says something the generic cannot it stays, which is
+        // why a takeaway keeps "Kitchen Orders". "Download Orders" says only
+        // what the heading said.
+        // "Downloads", which is what they are — and which tells them from the
+        // prints on the same shelf when a photographer sells both. Pass 7 was
+        // right to drop "Digital Catalog" and wrong to land on "Products".
+        id: "catalog",
+        label: "Downloads",
+        icon: Package,
+        shares: "catalogue"
+      },
+      {
+        id: "orders",
+        label: "Orders",
+        icon: Receipt,
+        shares: "orders",
+        landingLabel: "All {label}"
+      }
+    ]
+  },
+  {
+    key: "event-tickets",
+    label: "Ticketing",
+    items: [
+      {
+        id: "orders",
+        label: "Ticket orders",
+        icon: TicketCheck,
+        shares: "orders",
+        landingLabel: "All {label}"
+      },
+      {
+        id: "events",
+        label: "Events",
+        icon: CalendarRange,
+        landingLabel: "All {label}",
+        children: [
+          {
+            id: "collections",
+            label: "Collections",
+            icon: Layers
+          },
+          // No Check-ins row. The config dropped it deliberately — it was
+          // Attendees minus the list, plus a scan log that rendered empty on
+          // every load — and this list never got the memo, so it went on
+          // naming a row that `buildIntentItem` could not build and silently
+          // returned null for. Twelve ticketing businesses had it in the
+          // definitions and none of them could see it.
+          //
+          // The route stays, reached from an event: scanning is a phone job at
+          // a door. Nor is there an Attendees row any more (2026-09-03) — an
+          // attendee is a customer, so the identity lives in Customers.
+          {
+            id: "waitlist",
+            label: "Waitlist",
+            icon: ListChecks,
+            // One waiting list, like one Orders. A club with courts and
+            // ticketed nights had Waitlist under Appointments and Waitlist
+            // under Attendees — one screen, twice, differing only by a filter
+            // the screen itself carries.
+            shares: "waitlist"
+          }
+        ]
+      }
+      // No Calendar Sync row. A Google connection is made once and then
+      // forgotten, which is the definition of a setting, and it lives at
+      // Settings → Operations → Calendar sync for every archetype now. It used
+      // to be a row here, a row called Availability on rentals and a tab on
+      // appointments: one screen under three names in three places.
+    ]
+  },
+  {
+    key: "take-bookings",
+    label: "Bookings",
+    groupIcon: BookOpen,
+    items: [
+      // No Today row. It and the Appointments calendar were drawing the same
+      // picture — resources across, the day down — over the same records, and
+      // only the desk board could act on it. They are one surface with a view
+      // switch now, defaulting to the day, which is the screen a front desk
+      // keeps open. /dashboard/today redirects into it.
+      { id: "catalog", label: "Services", icon: Wrench, shares: "catalogue" },
+      {
+        id: "orders",
+        label: "Appointments",
+        icon: CalendarClock,
+        shares: "bookings",
+        landingLabel: "All {label}",
+        children: [
+          {
+            id: "waitlist",
+            label: "Waitlist",
+            icon: ListChecks,
+            // One waiting list, like one Orders. A club with courts and
+            // ticketed nights had Waitlist under Appointments and Waitlist
+            // under Attendees — one screen, twice, differing only by a filter
+            // the screen itself carries.
+            shares: "waitlist"
+          }
+        ]
+      },
+      // No 'calendar' row. It and Appointments were sibling rows over the same
+      // records — the list could act but not show time, the grid could show
+      // time but not act — and they are one surface with a view switch now.
+      // /dashboard/calendar is a redirect into it, so a row here would be a
+      // second door to a screen that already has one.
+      //
+      // Nor a 'Scheduling' row: that is a Google Calendar connection, an act
+      // performed once, and it lives in Settings.
+      {
+        id: "resources",
+        label: "Staff",
+        icon: LayoutGrid,
+        shares: "resources"
+      }
+    ]
+  },
+  {
+    key: "rent-property",
+    label: "Rentals",
+    items: [
+      // No Today row: the day board is the default view of Reservations now.
+      // A hotel's day is arrivals, departures and who is in house, and
+      // `buildDayLanes` still draws exactly those three columns.
+      {
+        id: "catalog",
+        label: "Properties",
+        icon: Building2,
+        shares: "catalogue"
+      },
+      {
+        id: "orders",
+        label: "Reservations",
+        icon: CalendarClock,
+        shares: "bookings",
+        landingLabel: "All {label}",
+        children: [
+          {
+            id: "waitlist",
+            label: "Waitlist",
+            icon: ListChecks,
+            // One waiting list, like one Orders. A club with courts and
+            // ticketed nights had Waitlist under Appointments and Waitlist
+            // under Attendees — one screen, twice, differing only by a filter
+            // the screen itself carries.
+            shares: "waitlist"
+          }
+        ]
+      }
+      // No Availability row, and no Calendar Sync row either. Availability was
+      // the calendar-CONNECTION screen — channel in, Google out — while a
+      // short-let's availability is its bookings, its blocked dates and what a
+      // channel is holding, none of which were on it. Reservations' calendar
+      // view is that answer, and it can finally draw properties: it built its
+      // columns from bookable_resources, which a rental business has none of,
+      // so a landlord with ten flats got an empty board asking for the
+      // properties they already had. The connection is a setting.
+    ]
+  },
+  {
+    key: "subscriptions",
+    label: "Memberships",
+    items: [
+      // A hub, because the screen behind it is two screens — and the sidebar
+      // used to reach them from two SECTIONS: this row under Operations, and a
+      // "Members" row under Customers on the same screen's other tab. One
+      // module, two doors, filed apart. They are children now, the way
+      // Resources holds its tabs; spine-groups.ts keeps the Customers row only
+      // for a `subscribable` shop that has no hub of its own.
+      // "Memberships", not "Plans": the row's word is also the page heading, so
+      // Plans headed a tab strip whose first tab said Plans. Tiers, not a box
+      // of stock — Plans wore Inventory's Package glyph.
+      {
+        id: "catalog",
+        label: "Memberships",
+        icon: BadgeCheck,
+        shares: "plans",
+        landingLabel: "Plans",
+        children: [{ id: "subscribers", label: "Members", icon: RefreshCw }]
+      },
+      // Orders stays and keeps sharing: a membership business still takes
+      // one-off payments, and when it also sells products there is one queue
+      // for both.
+      //
+      // It is not the subscriber list, and it was: one row, id `orders`,
+      // labelled "Subscribers", pointing at /dashboard/orders — so a
+      // membership business clicking Subscribers got a list of orders, which
+      // has never contained a subscriber.
+      {
+        id: "orders",
+        label: "Orders",
+        icon: Receipt,
+        shares: "orders",
+        landingLabel: "All {label}"
+      }
+      // No Subscribers row at this level: it was a peer of Plans pointing at
+      // Plans' own screen. It is Memberships' `subscribers` child now.
+    ]
+  },
+  {
+    key: "food-orders",
+    label: "Food orders",
+    items: [
+      {
+        id: "catalog",
+        label: "Menu",
+        icon: UtensilsCrossed,
+        shares: "catalogue"
+      },
+      {
+        id: "orders",
+        label: "Kitchen orders",
+        icon: Receipt,
+        shares: "orders",
+        landingLabel: "All {label}"
+      }
+    ]
+  },
+  {
+    // Billing businesses have no storefront order flow, so Orders is
+    // deliberately absent — Invoices is the work surface.
+    key: "send-invoices",
+    label: "Invoicing",
+    // Settings → Billing is what the merchant pays Box.
+    groupIcon: Receipt,
+    items: [
+      // Wrench, matching the other archetype that sells services — same key,
+      // same screen. Invoices takes the written receipt so it stops wearing the
+      // plain one that every archetype's order queue already wears.
+      { id: "catalog", label: "Services", icon: Wrench, shares: "catalogue" },
+      {
+        id: "invoices",
+        label: "Invoices",
+        icon: ReceiptText,
+        shares: "invoices"
+      }
+    ]
+  },
+  {
+    // Nothing is sold from a catalogue here, so Orders is deliberately absent
+    // exactly as it is for Billing — Enquiries is the work surface. `shares`
+    // is set so a business that also sells does not end up with two inboxes.
+    key: "capture-leads",
+    label: "Enquiries",
+    groupIcon: MessageSquare,
+    items: [
+      { id: "catalog", label: "Listings", icon: FileText, shares: "catalogue" },
+      {
+        id: "inquiries",
+        label: "Enquiries",
+        icon: MessageSquare,
+        shares: "inquiries"
+      }
+    ]
+  },
+  {
+    key: "dine-in",
+    label: "Dine-in",
+    groupIcon: UtensilsCrossed,
+    items: [
+      // No Today row: the floor right now is the default view of the queue.
+      {
+        id: "reservations",
+        label: "Reservations",
+        // Not the concierge bell: this row joined the `bookings` collapse, and
+        // one subject wears one glyph (see `nav-icons.test.ts`).
+        icon: CalendarClock,
+        landingLabel: "All {label}",
+        // The dining room's diary is `/dashboard/bookings`, the screen
+        // `take-bookings` calls Appointments and `rent-property` calls
+        // Reservations — both tagged `bookings`, this one was not. So a bakery
+        // taking cake consultations got two rows opening one diary under two
+        // words, which the label check cannot see: only the destination
+        // repeats. Tagging costs dine-in nothing — alone behind the row, the
+        // agreement pass gives "Reservations" straight back.
+        shares: "bookings",
+        children: [
+          {
+            id: "waitlist",
+            label: "Waitlist",
+            icon: ListChecks,
+            // One waiting list, like one Orders. A club with courts and
+            // ticketed nights had Waitlist under Appointments and Waitlist
+            // under Attendees — one screen, twice, differing only by a filter
+            // the screen itself carries.
+            shares: "waitlist"
+          }
+        ]
+      },
+      {
+        id: "resources",
+        label: "Tables",
+        icon: LayoutGrid,
+        shares: "resources"
+      },
+      { id: "tabs", label: "Tabs", icon: Banknote },
+      {
+        id: "catalog",
+        label: "Menu",
+        icon: UtensilsCrossed,
+        shares: "catalogue"
+      },
+      {
+        id: "orders",
+        label: "Orders",
+        icon: Receipt,
+        shares: "orders",
+        landingLabel: "All {label}"
+      }
+    ]
+  }
+];
+function intentNavRows(intentKeys) {
+  if (intentKeys.includes(BIO_INTENT)) return [];
+  const seen = /* @__PURE__ */ new Set();
+  const rows = [];
+  for (const key of intentKeys) {
+    const definition = INTENT_NAV_DEFINITIONS.find((d) => d.key === key);
+    const config = getIntentConfig(key) ?? (key === "default" ? defaultCommerceConfig : void 0);
+    if (!definition || !config) continue;
+    for (const item of definition.items) {
+      const declared = config.navigation.groups.some(
+        (g) => g.items.some((i) => i.id === item.id)
+      );
+      if (!declared || seen.has(item.label)) continue;
+      seen.add(item.label);
+      rows.push({ label: item.label, icon: item.icon });
+    }
+  }
+  return rows;
+}
+export {
+  INTENT_NAV_DEFINITIONS,
+  intentNavRows
+};
+//# sourceMappingURL=intent-nav.js.map

package/dist/intents/intent-nav.js.map

@@ -0,0 +1 @@
+{"version":3,"sources":["../../src/intents/intent-nav.ts"],"sourcesContent":["import {\n  Banknote,\n  BookOpen,\n  Building2,\n  CalendarClock,\n  CalendarRange,\n  BadgeCheck,\n  FileText,\n  Layers,\n  LayoutGrid,\n  ListChecks,\n  Package,\n  Receipt,\n  ReceiptText,\n  TicketCheck,\n  RefreshCw,\n  UtensilsCrossed,\n  Wrench,\n  type LucideIcon,\n  MessageSquare,\n} from 'lucide-react';\nimport { getIntentConfig, defaultCommerceConfig } from './registry';\nimport { BIO_INTENT } from './archetype-flow';\n\n/**\n * What each archetype puts in the sidebar, and what each row is called.\n *\n * This list — not the intent configs — decides what a merchant can reach and\n * what it is named. The configs supply the href and the permission; the label\n * and the membership come from here. That asymmetry is deliberate (a config can\n * declare a surface before the nav is ready for it) but it used to live inside\n * sidebar.tsx, which meant nothing else could tell the truth about the nav.\n *\n * Onboarding previews exactly this, so the pages it promises while the merchant\n * is picking archetypes are the pages the sidebar will actually render, under\n * the names it will actually use. Drift between this and the configs is still\n * shouted about in dev by warnOnUnreachableNavItems.\n */\nexport interface IntentNavDefinition {\n  key: string;\n  label: string;\n  groupIcon?: LucideIcon;\n  items: {\n    id: string;\n    label: string;\n    icon: LucideIcon;\n    /**\n     * What this item actually manages, in the merchant's words.\n     *\n     * A business that seats guests *and* does takeaway has one menu, not two,\n     * so both intents point at the same `shares: 'menu'` and the sidebar shows\n     * it once. Where two intents genuinely manage different things — a\n     * restaurant's menu and its retail shelf — the nouns differ and both stay.\n     *\n     * Omitted means \"unique to this archetype\" (Reservations, Tables, Tabs):\n     * only one intent ever contributes it, so there is nothing to collapse.\n     */\n    shares?: string;\n    /**\n     * Rows that live *under* this one, revealed by the sidebar's disclosure.\n     *\n     * An Operations row is often a surface with a smaller surface attached:\n     * Appointments has the queue of people who could not get one. Those are\n     * not peers — putting a Waitlist row beside Appointments says they are two\n     * equal destinations, when one is a state of the other. As children they\n     * stay one click away and cost the sidebar no height until opened.\n     */\n    children?: {\n      id: string;\n      label: string;\n      icon: LucideIcon;\n      /** Same meaning as on a top-level row: what this manages. */\n      shares?: string;\n    }[];\n    /**\n     * What this row's own screen is called once it has children.\n     *\n     * Required for any row that declares `children`: the disclosure rule moves\n     * the row's page into the group as its first child, and the renderer's\n     * \"Overview\" fallback exists only so a half-built hub renders rather than\n     * throwing. `{label}` interpolates the row's post-rename label.\n     */\n    landingLabel?: string;\n  }[];\n}\n\n/**\n * NO CHILDREN UNDER ORDERS. Abandoned carts was the only one, and it moved to\n * Marketing on John's call, 2026-09-03 — the argument is written where the row\n * now lives, in `spine-groups`.\n *\n * The declaration is deleted rather than emptied. A `children: []` on eight\n * archetypes is an invitation to nest the next thing that is *about* orders\n * under Orders, which is how this one ended up here: an abandoned cart is an\n * order that never happened, so it looked like an order's child. What a record\n * IS decides its permission; what you come to DO with it decides its row.\n *\n * What the old note here was right about, kept because it will be true again\n * the day something is genuinely nested: seven archetypes declare `orders`, it\n * collapses to one row, and the folding archetypes' children are grafted onto\n * the survivor — so an untagged child came out once per archetype. A musician\n * selling shows, merch and downloads had one Orders row carrying four\n * identical \"Abandoned carts\". Any future child needs `shares`.\n */\n\nexport const INTENT_NAV_DEFINITIONS: IntentNavDefinition[] = [\n  // No Fulfillment row, for `default` or `sell-products`. Both used to list one\n  // and no config ever declared a `shipping` nav item, so the row could not be\n  // built and never was — the definition promised a work surface that does not\n  // exist. Shipping is a Settings page (Settings → Selling → Shipping), which\n  // is where the spine already puts it and where `nav-coverage` says it lives.\n  {\n    key: 'default',\n    label: 'Products',\n    items: [\n      { id: 'catalog', label: 'Inventory', icon: Package, shares: 'catalogue' },\n      // \"Orders\", not \"Product Orders\". A qualifier earns its place by telling\n      // one archetype's queue from another's, and it is dropped the moment it\n      // does that job — multi mode collapses every contributor of `orders` to\n      // the plain noun. So the merchant running four archetypes read \"Orders\"\n      // and the shop running one read \"Product Orders\": the qualified label\n      // went to the only business with nothing to qualify against, one line\n      // under a group already called Products.\n      //\n      // Where the archetype's own word says something the generic cannot, it\n      // stays: a takeaway's \"Kitchen Orders\" names the queue it prints to.\n      {\n        id: 'orders',\n        label: 'Orders',\n        icon: Receipt,\n        shares: 'orders',\n        landingLabel: 'All {label}',\n      },\n    ],\n  },\n  {\n    key: 'sell-products',\n    label: 'Products',\n    items: [\n      { id: 'catalog', label: 'Inventory', icon: Package, shares: 'catalogue' },\n      // See `default` above: the qualifier told this shop's orders from queues\n      // it does not run.\n      {\n        id: 'orders',\n        label: 'Orders',\n        icon: Receipt,\n        shares: 'orders',\n        landingLabel: 'All {label}',\n      },\n    ],\n  },\n  {\n    key: 'digital-products',\n    label: 'Digital products',\n    items: [\n      {\n        // Package, and the same shelf as Inventory. A print and a preset are\n        // both things this business sells, and they sell from ONE screen: every\n        // archetype's `catalog` resolves to /dashboard/catalog. Giving downloads\n        // their own row made a filter wear the clothes of a destination — and\n        // since `sell-products` claims the shelf first, that row was deleted\n        // anyway, taking the whole Digital Products heading with it. The\n        // narrowing lives on the page now, in exactly these nouns.\n        // \"Products\" and \"Orders\", not \"Digital Catalog\" and \"Download\n        // Orders\". Judged by the rule pass 1 set: a qualifier earns its place\n        // by telling one archetype's queue from another's, and for a business\n        // that only sells downloads there is nothing to tell apart —\n        // everything in the catalogue is digital and every order is a\n        // download. The group above already says Digital Products.\n        //\n        // Where a word says something the generic cannot it stays, which is\n        // why a takeaway keeps \"Kitchen Orders\". \"Download Orders\" says only\n        // what the heading said.\n        // \"Downloads\", which is what they are — and which tells them from the\n        // prints on the same shelf when a photographer sells both. Pass 7 was\n        // right to drop \"Digital Catalog\" and wrong to land on \"Products\".\n        id: 'catalog',\n        label: 'Downloads',\n        icon: Package,\n        shares: 'catalogue',\n      },\n      {\n        id: 'orders',\n        label: 'Orders',\n        icon: Receipt,\n        shares: 'orders',\n        landingLabel: 'All {label}',\n      },\n    ],\n  },\n  {\n    key: 'event-tickets',\n    label: 'Ticketing',\n    items: [\n      {\n        id: 'orders',\n        label: 'Ticket orders',\n        icon: TicketCheck,\n        shares: 'orders',\n        landingLabel: 'All {label}',\n      },\n      {\n        id: 'events',\n        label: 'Events',\n        icon: CalendarRange,\n        landingLabel: 'All {label}',\n        children: [\n          {\n            id: 'collections',\n            label: 'Collections',\n            icon: Layers,\n          },\n          // No Check-ins row. The config dropped it deliberately — it was\n          // Attendees minus the list, plus a scan log that rendered empty on\n          // every load — and this list never got the memo, so it went on\n          // naming a row that `buildIntentItem` could not build and silently\n          // returned null for. Twelve ticketing businesses had it in the\n          // definitions and none of them could see it.\n          //\n          // The route stays, reached from an event: scanning is a phone job at\n          // a door. Nor is there an Attendees row any more (2026-09-03) — an\n          // attendee is a customer, so the identity lives in Customers.\n          {\n            id: 'waitlist',\n            label: 'Waitlist',\n            icon: ListChecks,\n            // One waiting list, like one Orders. A club with courts and\n            // ticketed nights had Waitlist under Appointments and Waitlist\n            // under Attendees — one screen, twice, differing only by a filter\n            // the screen itself carries.\n            shares: 'waitlist',\n          },\n        ],\n      },\n      // No Calendar Sync row. A Google connection is made once and then\n      // forgotten, which is the definition of a setting, and it lives at\n      // Settings → Operations → Calendar sync for every archetype now. It used\n      // to be a row here, a row called Availability on rentals and a tab on\n      // appointments: one screen under three names in three places.\n    ],\n  },\n  {\n    key: 'take-bookings',\n    label: 'Bookings',\n    groupIcon: BookOpen,\n    items: [\n      // No Today row. It and the Appointments calendar were drawing the same\n      // picture — resources across, the day down — over the same records, and\n      // only the desk board could act on it. They are one surface with a view\n      // switch now, defaulting to the day, which is the screen a front desk\n      // keeps open. /dashboard/today redirects into it.\n      { id: 'catalog', label: 'Services', icon: Wrench, shares: 'catalogue' },\n      {\n        id: 'orders',\n        label: 'Appointments',\n        icon: CalendarClock,\n        shares: 'bookings',\n        landingLabel: 'All {label}',\n        children: [\n          {\n            id: 'waitlist',\n            label: 'Waitlist',\n            icon: ListChecks,\n            // One waiting list, like one Orders. A club with courts and\n            // ticketed nights had Waitlist under Appointments and Waitlist\n            // under Attendees — one screen, twice, differing only by a filter\n            // the screen itself carries.\n            shares: 'waitlist',\n          },\n        ],\n      },\n      // No 'calendar' row. It and Appointments were sibling rows over the same\n      // records — the list could act but not show time, the grid could show\n      // time but not act — and they are one surface with a view switch now.\n      // /dashboard/calendar is a redirect into it, so a row here would be a\n      // second door to a screen that already has one.\n      //\n      // Nor a 'Scheduling' row: that is a Google Calendar connection, an act\n      // performed once, and it lives in Settings.\n      {\n        id: 'resources',\n        label: 'Staff',\n        icon: LayoutGrid,\n        shares: 'resources',\n      },\n    ],\n  },\n  {\n    key: 'rent-property',\n    label: 'Rentals',\n    items: [\n      // No Today row: the day board is the default view of Reservations now.\n      // A hotel's day is arrivals, departures and who is in house, and\n      // `buildDayLanes` still draws exactly those three columns.\n      {\n        id: 'catalog',\n        label: 'Properties',\n        icon: Building2,\n        shares: 'catalogue',\n      },\n      {\n        id: 'orders',\n        label: 'Reservations',\n        icon: CalendarClock,\n        shares: 'bookings',\n        landingLabel: 'All {label}',\n        children: [\n          {\n            id: 'waitlist',\n            label: 'Waitlist',\n            icon: ListChecks,\n            // One waiting list, like one Orders. A club with courts and\n            // ticketed nights had Waitlist under Appointments and Waitlist\n            // under Attendees — one screen, twice, differing only by a filter\n            // the screen itself carries.\n            shares: 'waitlist',\n          },\n        ],\n      },\n      // No Availability row, and no Calendar Sync row either. Availability was\n      // the calendar-CONNECTION screen — channel in, Google out — while a\n      // short-let's availability is its bookings, its blocked dates and what a\n      // channel is holding, none of which were on it. Reservations' calendar\n      // view is that answer, and it can finally draw properties: it built its\n      // columns from bookable_resources, which a rental business has none of,\n      // so a landlord with ten flats got an empty board asking for the\n      // properties they already had. The connection is a setting.\n    ],\n  },\n  {\n    key: 'subscriptions',\n    label: 'Memberships',\n    items: [\n      // A hub, because the screen behind it is two screens — and the sidebar\n      // used to reach them from two SECTIONS: this row under Operations, and a\n      // \"Members\" row under Customers on the same screen's other tab. One\n      // module, two doors, filed apart. They are children now, the way\n      // Resources holds its tabs; spine-groups.ts keeps the Customers row only\n      // for a `subscribable` shop that has no hub of its own.\n      // \"Memberships\", not \"Plans\": the row's word is also the page heading, so\n      // Plans headed a tab strip whose first tab said Plans. Tiers, not a box\n      // of stock — Plans wore Inventory's Package glyph.\n      {\n        id: 'catalog',\n        label: 'Memberships',\n        icon: BadgeCheck,\n        shares: 'plans',\n        landingLabel: 'Plans',\n        children: [{ id: 'subscribers', label: 'Members', icon: RefreshCw }],\n      },\n      // Orders stays and keeps sharing: a membership business still takes\n      // one-off payments, and when it also sells products there is one queue\n      // for both.\n      //\n      // It is not the subscriber list, and it was: one row, id `orders`,\n      // labelled \"Subscribers\", pointing at /dashboard/orders — so a\n      // membership business clicking Subscribers got a list of orders, which\n      // has never contained a subscriber.\n      {\n        id: 'orders',\n        label: 'Orders',\n        icon: Receipt,\n        shares: 'orders',\n        landingLabel: 'All {label}',\n      },\n      // No Subscribers row at this level: it was a peer of Plans pointing at\n      // Plans' own screen. It is Memberships' `subscribers` child now.\n    ],\n  },\n  {\n    key: 'food-orders',\n    label: 'Food orders',\n    items: [\n      {\n        id: 'catalog',\n        label: 'Menu',\n        icon: UtensilsCrossed,\n        shares: 'catalogue',\n      },\n      {\n        id: 'orders',\n        label: 'Kitchen orders',\n        icon: Receipt,\n        shares: 'orders',\n        landingLabel: 'All {label}',\n      },\n    ],\n  },\n  {\n    // Billing businesses have no storefront order flow, so Orders is\n    // deliberately absent — Invoices is the work surface.\n    key: 'send-invoices',\n    label: 'Invoicing', // Settings → Billing is what the merchant pays Box.\n    groupIcon: Receipt,\n    items: [\n      // Wrench, matching the other archetype that sells services — same key,\n      // same screen. Invoices takes the written receipt so it stops wearing the\n      // plain one that every archetype's order queue already wears.\n      { id: 'catalog', label: 'Services', icon: Wrench, shares: 'catalogue' },\n      {\n        id: 'invoices',\n        label: 'Invoices',\n        icon: ReceiptText,\n        shares: 'invoices',\n      },\n    ],\n  },\n  {\n    // Nothing is sold from a catalogue here, so Orders is deliberately absent\n    // exactly as it is for Billing — Enquiries is the work surface. `shares`\n    // is set so a business that also sells does not end up with two inboxes.\n    key: 'capture-leads',\n    label: 'Enquiries',\n    groupIcon: MessageSquare,\n    items: [\n      { id: 'catalog', label: 'Listings', icon: FileText, shares: 'catalogue' },\n      {\n        id: 'inquiries',\n        label: 'Enquiries',\n        icon: MessageSquare,\n        shares: 'inquiries',\n      },\n    ],\n  },\n  {\n    key: 'dine-in',\n    label: 'Dine-in',\n    groupIcon: UtensilsCrossed,\n    items: [\n      // No Today row: the floor right now is the default view of the queue.\n      {\n        id: 'reservations',\n        label: 'Reservations',\n        // Not the concierge bell: this row joined the `bookings` collapse, and\n        // one subject wears one glyph (see `nav-icons.test.ts`).\n        icon: CalendarClock,\n        landingLabel: 'All {label}',\n        // The dining room's diary is `/dashboard/bookings`, the screen\n        // `take-bookings` calls Appointments and `rent-property` calls\n        // Reservations — both tagged `bookings`, this one was not. So a bakery\n        // taking cake consultations got two rows opening one diary under two\n        // words, which the label check cannot see: only the destination\n        // repeats. Tagging costs dine-in nothing — alone behind the row, the\n        // agreement pass gives \"Reservations\" straight back.\n        shares: 'bookings',\n        children: [\n          {\n            id: 'waitlist',\n            label: 'Waitlist',\n            icon: ListChecks,\n            // One waiting list, like one Orders. A club with courts and\n            // ticketed nights had Waitlist under Appointments and Waitlist\n            // under Attendees — one screen, twice, differing only by a filter\n            // the screen itself carries.\n            shares: 'waitlist',\n          },\n        ],\n      },\n      {\n        id: 'resources',\n        label: 'Tables',\n        icon: LayoutGrid,\n        shares: 'resources',\n      },\n      { id: 'tabs', label: 'Tabs', icon: Banknote },\n      {\n        id: 'catalog',\n        label: 'Menu',\n        icon: UtensilsCrossed,\n        shares: 'catalogue',\n      },\n      {\n        id: 'orders',\n        label: 'Orders',\n        icon: Receipt,\n        shares: 'orders',\n        landingLabel: 'All {label}',\n      },\n    ],\n  },\n];\n\n/**\n * The nav rows a set of archetypes adds, in sidebar order, de-duplicated.\n *\n * Two rules keep this honest, and both were broken when onboarding read the raw\n * configs instead: an item only counts if the chosen intent's config actually\n * declares it (the sidebar drops it otherwise), and only intent-group rows\n * count at all. The fixed spine (Collections, Discounts, Invoices, Marketing,\n * Website) is there for every merchant regardless of what they pick, so listing\n * it as a consequence of a pick is a promise the pick did not make.\n */\nexport function intentNavRows(\n  intentKeys: string[],\n): { label: string; icon: LucideIcon }[] {\n  // Bio adds no dashboard navigation rows.\n  if (intentKeys.includes(BIO_INTENT)) return [];\n\n  const seen = new Set<string>();\n  const rows: { label: string; icon: LucideIcon }[] = [];\n\n  for (const key of intentKeys) {\n    const definition = INTENT_NAV_DEFINITIONS.find((d) => d.key === key);\n    const config =\n      getIntentConfig(key) ??\n      (key === 'default' ? defaultCommerceConfig : undefined);\n    if (!definition || !config) continue;\n\n    for (const item of definition.items) {\n      // The sidebar takes the href from the config, so an item the config does\n      // not declare is never rendered no matter what this list says.\n      const declared = config.navigation.groups.some((g) =>\n        g.items.some((i) => i.id === item.id),\n      );\n      if (!declared || seen.has(item.label)) continue;\n      seen.add(item.label);\n      rows.push({ label: item.label, icon: item.icon });\n    }\n  }\n\n  return rows;\n}\n"],"mappings":"AAAA;AAAA,EACE;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EAEA;AAAA,OACK;AACP,SAAS,iBAAiB,6BAA6B;AACvD,SAAS,kBAAkB;AAmFpB,MAAM,yBAAgD;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,EAM3D;AAAA,IACE,KAAK;AAAA,IACL,OAAO;AAAA,IACP,OAAO;AAAA,MACL,EAAE,IAAI,WAAW,OAAO,aAAa,MAAM,SAAS,QAAQ,YAAY;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,MAWxE;AAAA,QACE,IAAI;AAAA,QACJ,OAAO;AAAA,QACP,MAAM;AAAA,QACN,QAAQ;AAAA,QACR,cAAc;AAAA,MAChB;AAAA,IACF;AAAA,EACF;AAAA,EACA;AAAA,IACE,KAAK;AAAA,IACL,OAAO;AAAA,IACP,OAAO;AAAA,MACL,EAAE,IAAI,WAAW,OAAO,aAAa,MAAM,SAAS,QAAQ,YAAY;AAAA;AAAA;AAAA,MAGxE;AAAA,QACE,IAAI;AAAA,QACJ,OAAO;AAAA,QACP,MAAM;AAAA,QACN,QAAQ;AAAA,QACR,cAAc;AAAA,MAChB;AAAA,IACF;AAAA,EACF;AAAA,EACA;AAAA,IACE,KAAK;AAAA,IACL,OAAO;AAAA,IACP,OAAO;AAAA,MACL;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,QAqBE,IAAI;AAAA,QACJ,OAAO;AAAA,QACP,MAAM;AAAA,QACN,QAAQ;AAAA,MACV;AAAA,MACA;AAAA,QACE,IAAI;AAAA,QACJ,OAAO;AAAA,QACP,MAAM;AAAA,QACN,QAAQ;AAAA,QACR,cAAc;AAAA,MAChB;AAAA,IACF;AAAA,EACF;AAAA,EACA;AAAA,IACE,KAAK;AAAA,IACL,OAAO;AAAA,IACP,OAAO;AAAA,MACL;AAAA,QACE,IAAI;AAAA,QACJ,OAAO;AAAA,QACP,MAAM;AAAA,QACN,QAAQ;AAAA,QACR,cAAc;AAAA,MAChB;AAAA,MACA;AAAA,QACE,IAAI;AAAA,QACJ,OAAO;AAAA,QACP,MAAM;AAAA,QACN,cAAc;AAAA,QACd,UAAU;AAAA,UACR;AAAA,YACE,IAAI;AAAA,YACJ,OAAO;AAAA,YACP,MAAM;AAAA,UACR;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,UAWA;AAAA,YACE,IAAI;AAAA,YACJ,OAAO;AAAA,YACP,MAAM;AAAA;AAAA;AAAA;AAAA;AAAA,YAKN,QAAQ;AAAA,UACV;AAAA,QACF;AAAA,MACF;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAMF;AAAA,EACF;AAAA,EACA;AAAA,IACE,KAAK;AAAA,IACL,OAAO;AAAA,IACP,WAAW;AAAA,IACX,OAAO;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,MAML,EAAE,IAAI,WAAW,OAAO,YAAY,MAAM,QAAQ,QAAQ,YAAY;AAAA,MACtE;AAAA,QACE,IAAI;AAAA,QACJ,OAAO;AAAA,QACP,MAAM;AAAA,QACN,QAAQ;AAAA,QACR,cAAc;AAAA,QACd,UAAU;AAAA,UACR;AAAA,YACE,IAAI;AAAA,YACJ,OAAO;AAAA,YACP,MAAM;AAAA;AAAA;AAAA;AAAA;AAAA,YAKN,QAAQ;AAAA,UACV;AAAA,QACF;AAAA,MACF;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,MASA;AAAA,QACE,IAAI;AAAA,QACJ,OAAO;AAAA,QACP,MAAM;AAAA,QACN,QAAQ;AAAA,MACV;AAAA,IACF;AAAA,EACF;AAAA,EACA;AAAA,IACE,KAAK;AAAA,IACL,OAAO;AAAA,IACP,OAAO;AAAA;AAAA;AAAA;AAAA,MAIL;AAAA,QACE,IAAI;AAAA,QACJ,OAAO;AAAA,QACP,MAAM;AAAA,QACN,QAAQ;AAAA,MACV;AAAA,MACA;AAAA,QACE,IAAI;AAAA,QACJ,OAAO;AAAA,QACP,MAAM;AAAA,QACN,QAAQ;AAAA,QACR,cAAc;AAAA,QACd,UAAU;AAAA,UACR;AAAA,YACE,IAAI;AAAA,YACJ,OAAO;AAAA,YACP,MAAM;AAAA;AAAA;AAAA;AAAA;AAAA,YAKN,QAAQ;AAAA,UACV;AAAA,QACF;AAAA,MACF;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IASF;AAAA,EACF;AAAA,EACA;AAAA,IACE,KAAK;AAAA,IACL,OAAO;AAAA,IACP,OAAO;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,MAUL;AAAA,QACE,IAAI;AAAA,QACJ,OAAO;AAAA,QACP,MAAM;AAAA,QACN,QAAQ;AAAA,QACR,cAAc;AAAA,QACd,UAAU,CAAC,EAAE,IAAI,eAAe,OAAO,WAAW,MAAM,UAAU,CAAC;AAAA,MACrE;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,MASA;AAAA,QACE,IAAI;AAAA,QACJ,OAAO;AAAA,QACP,MAAM;AAAA,QACN,QAAQ;AAAA,QACR,cAAc;AAAA,MAChB;AAAA;AAAA;AAAA,IAGF;AAAA,EACF;AAAA,EACA;AAAA,IACE,KAAK;AAAA,IACL,OAAO;AAAA,IACP,OAAO;AAAA,MACL;AAAA,QACE,IAAI;AAAA,QACJ,OAAO;AAAA,QACP,MAAM;AAAA,QACN,QAAQ;AAAA,MACV;AAAA,MACA;AAAA,QACE,IAAI;AAAA,QACJ,OAAO;AAAA,QACP,MAAM;AAAA,QACN,QAAQ;AAAA,QACR,cAAc;AAAA,MAChB;AAAA,IACF;AAAA,EACF;AAAA,EACA;AAAA;AAAA;AAAA,IAGE,KAAK;AAAA,IACL,OAAO;AAAA;AAAA,IACP,WAAW;AAAA,IACX,OAAO;AAAA;AAAA;AAAA;AAAA,MAIL,EAAE,IAAI,WAAW,OAAO,YAAY,MAAM,QAAQ,QAAQ,YAAY;AAAA,MACtE;AAAA,QACE,IAAI;AAAA,QACJ,OAAO;AAAA,QACP,MAAM;AAAA,QACN,QAAQ;AAAA,MACV;AAAA,IACF;AAAA,EACF;AAAA,EACA;AAAA;AAAA;AAAA;AAAA,IAIE,KAAK;AAAA,IACL,OAAO;AAAA,IACP,WAAW;AAAA,IACX,OAAO;AAAA,MACL,EAAE,IAAI,WAAW,OAAO,YAAY,MAAM,UAAU,QAAQ,YAAY;AAAA,MACxE;AAAA,QACE,IAAI;AAAA,QACJ,OAAO;AAAA,QACP,MAAM;AAAA,QACN,QAAQ;AAAA,MACV;AAAA,IACF;AAAA,EACF;AAAA,EACA;AAAA,IACE,KAAK;AAAA,IACL,OAAO;AAAA,IACP,WAAW;AAAA,IACX,OAAO;AAAA;AAAA,MAEL;AAAA,QACE,IAAI;AAAA,QACJ,OAAO;AAAA;AAAA;AAAA,QAGP,MAAM;AAAA,QACN,cAAc;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,QAQd,QAAQ;AAAA,QACR,UAAU;AAAA,UACR;AAAA,YACE,IAAI;AAAA,YACJ,OAAO;AAAA,YACP,MAAM;AAAA;AAAA;AAAA;AAAA;AAAA,YAKN,QAAQ;AAAA,UACV;AAAA,QACF;AAAA,MACF;AAAA,MACA;AAAA,QACE,IAAI;AAAA,QACJ,OAAO;AAAA,QACP,MAAM;AAAA,QACN,QAAQ;AAAA,MACV;AAAA,MACA,EAAE,IAAI,QAAQ,OAAO,QAAQ,MAAM,SAAS;AAAA,MAC5C;AAAA,QACE,IAAI;AAAA,QACJ,OAAO;AAAA,QACP,MAAM;AAAA,QACN,QAAQ;AAAA,MACV;AAAA,MACA;AAAA,QACE,IAAI;AAAA,QACJ,OAAO;AAAA,QACP,MAAM;AAAA,QACN,QAAQ;AAAA,QACR,cAAc;AAAA,MAChB;AAAA,IACF;AAAA,EACF;AACF;AAYO,SAAS,cACd,YACuC;AAEvC,MAAI,WAAW,SAAS,UAAU,EAAG,QAAO,CAAC;AAE7C,QAAM,OAAO,oBAAI,IAAY;AAC7B,QAAM,OAA8C,CAAC;AAErD,aAAW,OAAO,YAAY;AAC5B,UAAM,aAAa,uBAAuB,KAAK,CAAC,MAAM,EAAE,QAAQ,GAAG;AACnE,UAAM,SACJ,gBAAgB,GAAG,MAClB,QAAQ,YAAY,wBAAwB;AAC/C,QAAI,CAAC,cAAc,CAAC,OAAQ;AAE5B,eAAW,QAAQ,WAAW,OAAO;AAGnC,YAAM,WAAW,OAAO,WAAW,OAAO;AAAA,QAAK,CAAC,MAC9C,EAAE,MAAM,KAAK,CAAC,MAAM,EAAE,OAAO,KAAK,EAAE;AAAA,MACtC;AACA,UAAI,CAAC,YAAY,KAAK,IAAI,KAAK,KAAK,EAAG;AACvC,WAAK,IAAI,KAAK,KAAK;AACnB,WAAK,KAAK,EAAE,OAAO,KAAK,OAAO,MAAM,KAAK,KAAK,CAAC;AAAA,IAClD;AAAA,EACF;AAEA,SAAO;AACT;","names":[]}

package/dist/intents/intent-scope.d.ts

@@ -0,0 +1,52 @@
+import { type ReactNode } from 'react';
+/** What a composed route says its screen is called and what it is about. */
+export interface ScopeLabels {
+    /** The route's own name — the heading of the screen it mounts. */
+    title: string;
+    /** The nouns of the owning intent, as it declares them. */
+    vocabulary: {
+        item?: readonly [string, string];
+        order?: readonly [string, string];
+        booking?: readonly [string, string];
+        resource?: readonly [string, string];
+    };
+    /** What the screen says when it has nothing to show, if the route declares it. */
+    empty?: {
+        title: string;
+        description: string;
+    };
+    /** Where this intent's items are listed and created, when it has screens for them. */
+    links?: {
+        list?: string;
+        create?: string;
+        orders?: string;
+        bookings?: string;
+        invoices?: string;
+        resources?: string;
+    };
+}
+/**
+ * Renders a screen as one intent.
+ *
+ * A composed route belongs to exactly one intent, and the screen it mounts must
+ * speak that intent's words and ask for that intent's data — a Ticket orders
+ * route that listed a restaurant's pizza under "Event" was the screen reading
+ * the URL's `?intent=` filter, or the business's first archetype, instead of
+ * the route it was mounted by. Inside this boundary `useIntentConfig` answers
+ * for the one intent, and the label hooks answer from the labels the composer
+ * file declared, so every existing component (nouns, columns, filters, create
+ * labels, headings) follows without being rewritten.
+ *
+ * The labels outrank what the tenant's own settings hold. Those were stamped
+ * at provisioning from whichever intent was ticked first, so a restaurant that
+ * also sold tickets read "Events" over its own menu.
+ */
+export declare function IntentScope({ intentKey, labels, children, }: {
+    intentKey: string;
+    labels?: ScopeLabels | null;
+    children: ReactNode;
+}): import("react").JSX.Element;
+/** The intent this subtree is scoped to, or null outside any composed route. */
+export declare const useIntentScope: () => string | null;
+/** The labels the composer declared for this screen, or null outside one. */
+export declare const useScopeLabels: () => ScopeLabels | null;

package/dist/intents/intent-scope.js

@@ -0,0 +1,19 @@
+"use client";
+import { jsx } from "react/jsx-runtime";
+import { createContext, useContext } from "react";
+const IntentScopeContext = createContext(null);
+function IntentScope({
+  intentKey,
+  labels = null,
+  children
+}) {
+  return /* @__PURE__ */ jsx(IntentScopeContext.Provider, { value: { intentKey, labels }, children });
+}
+const useIntentScope = () => useContext(IntentScopeContext)?.intentKey ?? null;
+const useScopeLabels = () => useContext(IntentScopeContext)?.labels ?? null;
+export {
+  IntentScope,
+  useIntentScope,
+  useScopeLabels
+};
+//# sourceMappingURL=intent-scope.js.map

package/dist/intents/intent-scope.js.map

@@ -0,0 +1 @@
+{"version":3,"sources":["../../src/intents/intent-scope.tsx"],"sourcesContent":["'use client';\n\nimport { createContext, useContext, type ReactNode } from 'react';\n\n/** What a composed route says its screen is called and what it is about. */\nexport interface ScopeLabels {\n  /** The route's own name — the heading of the screen it mounts. */\n  title: string;\n  /** The nouns of the owning intent, as it declares them. */\n  vocabulary: {\n    item?: readonly [string, string];\n    order?: readonly [string, string];\n    booking?: readonly [string, string];\n    resource?: readonly [string, string];\n  };\n  /** What the screen says when it has nothing to show, if the route declares it. */\n  empty?: { title: string; description: string };\n  /** Where this intent's items are listed and created, when it has screens for them. */\n  links?: {\n    list?: string;\n    create?: string;\n    orders?: string;\n    bookings?: string;\n    invoices?: string;\n    resources?: string;\n  };\n}\n\ninterface ScopeValue {\n  intentKey: string;\n  labels: ScopeLabels | null;\n}\n\nconst IntentScopeContext = createContext<ScopeValue | null>(null);\n\n/**\n * Renders a screen as one intent.\n *\n * A composed route belongs to exactly one intent, and the screen it mounts must\n * speak that intent's words and ask for that intent's data — a Ticket orders\n * route that listed a restaurant's pizza under \"Event\" was the screen reading\n * the URL's `?intent=` filter, or the business's first archetype, instead of\n * the route it was mounted by. Inside this boundary `useIntentConfig` answers\n * for the one intent, and the label hooks answer from the labels the composer\n * file declared, so every existing component (nouns, columns, filters, create\n * labels, headings) follows without being rewritten.\n *\n * The labels outrank what the tenant's own settings hold. Those were stamped\n * at provisioning from whichever intent was ticked first, so a restaurant that\n * also sold tickets read \"Events\" over its own menu.\n */\nexport function IntentScope({\n  intentKey,\n  labels = null,\n  children,\n}: {\n  intentKey: string;\n  labels?: ScopeLabels | null;\n  children: ReactNode;\n}) {\n  return (\n    <IntentScopeContext.Provider value={{ intentKey, labels }}>\n      {children}\n    </IntentScopeContext.Provider>\n  );\n}\n\n/** The intent this subtree is scoped to, or null outside any composed route. */\nexport const useIntentScope = (): string | null =>\n  useContext(IntentScopeContext)?.intentKey ?? null;\n\n/** The labels the composer declared for this screen, or null outside one. */\nexport const useScopeLabels = (): ScopeLabels | null =>\n  useContext(IntentScopeContext)?.labels ?? null;\n"],"mappings":";AA6DI;AA3DJ,SAAS,eAAe,kBAAkC;AA+B1D,MAAM,qBAAqB,cAAiC,IAAI;AAkBzD,SAAS,YAAY;AAAA,EAC1B;AAAA,EACA,SAAS;AAAA,EACT;AACF,GAIG;AACD,SACE,oBAAC,mBAAmB,UAAnB,EAA4B,OAAO,EAAE,WAAW,OAAO,GACrD,UACH;AAEJ;AAGO,MAAM,iBAAiB,MAC5B,WAAW,kBAAkB,GAAG,aAAa;AAGxC,MAAM,iBAAiB,MAC5B,WAAW,kBAAkB,GAAG,UAAU;","names":[]}