@withpotter/components 0.13.0-next.101

package/dist/sidebar/spine-groups.d.ts

@@ -0,0 +1,23 @@
+import { useIntentConfig } from '@withpotter/lib/intents/use-intent-config';
+import { useCurrentTemplate } from '@withpotter/lib/template-context';
+import { usePermissions } from '@withpotter/lib/use-permissions';
+import { resolveEnabledBehaviors } from '@withpotter/lib/resolve-enabled-behaviors';
+import { type NavItem, type NavGroup } from './config';
+export interface SpineDeps {
+    filterItems: (items: NavItem[]) => NavItem[];
+    coreItem: (id: string, labelOverride?: string) => NavItem | null;
+    group: (g: NavGroup) => NavGroup[];
+    /**
+     * Rows several archetypes share — one Catalog, one Orders — as their own
+     * links above the archetype groups. They belong to no single archetype, so
+     * they are not filed under one.
+     */
+    sharedGroups: NavGroup[];
+    intentGroups: NavGroup[];
+    catalogToolsGroup: NavGroup[];
+    can: ReturnType<typeof usePermissions>['can'];
+    enabledBehaviors: ReturnType<typeof resolveEnabledBehaviors>;
+    intentConfig: ReturnType<typeof useIntentConfig>;
+    template: ReturnType<typeof useCurrentTemplate>['template'];
+}
+export declare function buildSpineGroups({ filterItems, coreItem, group, sharedGroups, intentGroups, catalogToolsGroup, can, enabledBehaviors, intentConfig, }: SpineDeps): NavGroup[];

package/dist/sidebar/spine-groups.js

@@ -0,0 +1,290 @@
+import {
+  Route,
+  ChartNoAxesCombined,
+  Users,
+  Building2,
+  ToggleLeft,
+  Mail,
+  Bell,
+  Percent,
+  Scale,
+  Settings
+} from "lucide-react";
+import { resolveAnalyticsViews } from "@withpotter/lib/intents/analytics-labels";
+import { buildWebsiteGroup } from "./spine-website";
+import { buildOperationsGroup } from "./spine-operations";
+import { buildMarketingGroup } from "./spine-marketing";
+import { buildMoneyGroup } from "./spine-money";
+import { buildCustomersGroup } from "./spine-customers";
+import { shellTakesMoney } from "./takes-money";
+import { groupItems } from "./flatten-work-groups";
+import { makeFlatGroup } from "./nav-gates";
+function buildSpineGroups({
+  filterItems,
+  coreItem,
+  group,
+  sharedGroups,
+  intentGroups,
+  catalogToolsGroup,
+  can,
+  enabledBehaviors,
+  intentConfig
+}) {
+  const takesMoney = shellTakesMoney(enabledBehaviors);
+  const owns = (id) => intentGroups.some(
+    (group2) => group2.items?.some(
+      (item) => item.id === id || item.children?.some((child) => child.id === id)
+    )
+  );
+  const intentOwnsInvoices = owns("invoices");
+  const runsMembershipArchetype = intentConfig.all.some(
+    (config) => config.key === "subscriptions"
+  );
+  const runsSubscriptions = runsMembershipArchetype || enabledBehaviors.includes("subscribable");
+  const customersGroup = buildCustomersGroup({
+    filterItems,
+    takesMoney,
+    runsSubscriptions,
+    runsMembershipArchetype
+  });
+  const paymentsGroup = buildMoneyGroup({
+    filterItems,
+    intentOwnsInvoices,
+    canSeeFinance: can("canViewFinance") || can("canManageFinance")
+  });
+  const analyticsViews = resolveAnalyticsViews(intentConfig.all);
+  const analyticsGroup = {
+    id: "analytics",
+    label: "Analytics",
+    icon: ChartNoAxesCombined,
+    href: "/dashboard/analytics",
+    /**
+     * The landing view IS the sales view — there is no "Overview". An overview
+     * of a two-page hub is a summary of what is already on the next screen, and
+     * the word names nothing: every hub has one, so it distinguishes nothing
+     * about this one.
+     *
+     * `Sales summary`, not `Sales`, and that is a correction. Money already
+     * carries a row called Sales — the cross-rail register of everything sold,
+     * where each row opens the record to act on it — so a multi-model merchant
+     * saw the word twice in one sidebar, pointing at two different screens. It
+     * went unseen for the usual reason: the `sales` row is gated on `isMulti`,
+     * so the collision only exists on the businesses that run more than one
+     * model, which is 16 of the walkthrough set.
+     *
+     * The hub had already made this exact call one row down: Retention is named
+     * Retention BECAUSE "Customers" was taken by the spine row above it. Same
+     * rule, applied to the row that was missed.
+     *
+     * The report takes the qualifier rather than the register, because the
+     * register is the place and this is the measurement of it — and because
+     * `VIEW_TITLES` in the hub's layout has titled this document "Sales
+     * summary" all along. The row and the title agreeing costs nothing here;
+     * they were allowed to differ, not required to.
+     */
+    landingLabel: "Sales overview",
+    requiredPermission: ["canViewAnalytics"],
+    // One child plus the landing page. Without this, `renderHub` collapses a
+    // lone child into a flat link and Retention would never appear.
+    alwaysHub: true,
+    items: filterItems(
+      [
+        // No `Orders` row. The order report is an INSTRUMENT, not a subject:
+        // it is one object — a measure crossed with a dimension over a
+        // window — and Square's seven report rows are that same object with
+        // different `Group metric by` presets, not seven different things.
+        // Listing it beside Sales and Retention put a tool in a list of
+        // topics, which is why the hub read as three unrelated pages.
+        //
+        // It is reached by drilling instead: every panel that has a cut
+        // carries a link into `/dashboard/analytics/orders` with its own
+        // dimension already set, the way Shopify's overview cards each open
+        // the report that owns them. The route still exists and is still
+        // addressable — it just is not a place you navigate to cold, because
+        // arriving with no question is what made it a wall of controls.
+        {
+          /**
+           * Attribution, which was a fourth row under Marketing until
+           * 2026-08-27.
+           *
+           * It always answered to `canViewAnalytics` — the old row said so in
+           * its own comment — which is the tell that it was filed under the
+           * wrong parent: a row whose permission belongs to another group is
+           * a report that has been shelved with the tools.
+           *
+           * The campaign-level answer never lived on it anyway. What a send
+           * earned is the Attributable sales column on the campaigns table,
+           * and `useCampaignRevenue` gets it from the SAME endpoint this page
+           * calls. What is left — Sources, Channels, Promotions — is not
+           * campaign-scoped at all: it is where the money came from, which is
+           * the same kind of question as Sales and Retention beside it.
+           *
+           * Checked live in Square (2026-08-27): they have no attribution
+           * page. It is a column called "Attributable Sales" on the campaign
+           * row and nothing more. We keep the report because Sources and
+           * Channels answer what a column cannot — an order that carried no
+           * campaign still came from somewhere — but not as a marketing row.
+           */
+          id: "analytics-attribution",
+          name: "Acquisition",
+          href: "/dashboard/analytics/acquisition",
+          icon: Route,
+          requiredPermission: ["canViewAnalytics"]
+        },
+        {
+          // Not `Customers`. That word is already a spine row directly above
+          // this one, and two rows reading the same noun at different depths
+          // is the confusion this hub exists to avoid. It is also not the
+          // right word: the Customers hub owns the PEOPLE — a list you open
+          // and edit — while this measures their BEHAVIOUR, which is a thing
+          // you cannot click into one of.
+          //
+          // Renaming would not have fixed it either: a hotel that relabels
+          // the hub to "Guests" would simply have read "Guests" twice.
+          id: "analytics-retention",
+          name: "Retention",
+          href: "/dashboard/analytics/retention",
+          icon: Users,
+          requiredPermission: ["canViewAnalytics"]
+        }
+      ].filter(
+        // An archetype that names its analytics views gets only those. The
+        // row and the page have to agree: the view decides its own sections
+        // from the same declaration, so a nav child pointing at a view that
+        // renders nothing would be a link to an empty screen.
+        (item) => !analyticsViews || analyticsViews.includes(item.id.replace("analytics-", ""))
+      )
+    )
+  };
+  const marketingGroup = buildMarketingGroup({
+    filterItems,
+    enabledBehaviors
+  });
+  const websiteGroup = buildWebsiteGroup({ filterItems, coreItem });
+  const staffTaken = [...sharedGroups, ...intentGroups].some(
+    (g) => groupItems(g).some(
+      (item) => item.name === "Staff" || item.children?.some((child) => child.name === "Staff")
+    )
+  );
+  const operationsGroup = buildOperationsGroup(filterItems, { staffTaken });
+  const settingsGroup = {
+    id: "settings",
+    label: "Settings",
+    icon: Settings,
+    sections: [
+      {
+        id: "settings-business",
+        // Same three buckets, same names as the settings rail (BUSINESS_GROUPS)
+        // and the workspace hub. They used to read Workspace / Operations /
+        // Compliance here and Setup / Selling / Records there, for the same
+        // destinations — so whichever a merchant learned first was wrong in
+        // the other place.
+        label: "Setup",
+        items: filterItems([
+          {
+            id: "business-profile",
+            // 'General' everywhere. The rail and the hub already call it
+            // that; only this list said 'Business profile'.
+            name: "General",
+            href: "/dashboard/settings",
+            icon: Building2,
+            requiredPermission: ["canManageBusinessProfile"]
+          },
+          {
+            id: "features",
+            name: "Features",
+            href: "/dashboard/settings/features",
+            icon: ToggleLeft,
+            requiredPermission: ["canManageSettings"]
+          },
+          // Configuration, not history — it was filed under Records beside
+          // Activity, which is the log group. No requiredPermission: every
+          // active member has a personal notification section on this page,
+          // and the tenant-wide config is gated inside it.
+          {
+            id: "notifications",
+            name: "Notifications",
+            href: "/dashboard/settings/notifications",
+            icon: Bell
+          }
+          // Connectors lives in Customize now. See config.ts.
+        ])
+      },
+      {
+        id: "settings-operations",
+        label: "Selling",
+        items: filterItems([
+          {
+            id: "taxes",
+            name: "Taxes",
+            href: "/dashboard/business/checkout?tab=taxes",
+            icon: Percent,
+            requiredPermission: ["canManageSettings"]
+          },
+          {
+            id: "policies",
+            name: "Policies",
+            href: "/dashboard/settings/policies",
+            icon: Scale,
+            requiredPermission: ["canManageSettings"]
+          }
+          // Plan & billing is per-WORKSPACE. This comment used to claim the
+          // opposite while `config.ts` two files away claimed the truth, and
+          // the schema settles it: `billing_subscriptions.tenantId` is unique,
+          // and every credit table is `tenant_*` keyed on `tenantId`. It is
+          // listed in the business-scoped Setup group, not the account menu.
+        ])
+      },
+      {
+        id: "settings-compliance",
+        label: "Records",
+        items: filterItems([
+          {
+            id: "email",
+            name: "Email",
+            href: "/dashboard/settings/email",
+            icon: Mail,
+            requiredPermission: ["canManageCommunications"]
+          }
+        ])
+      }
+    ].filter((section) => section.items.length > 0)
+  };
+  return [
+    ...sharedGroups,
+    ...intentGroups,
+    ...catalogToolsGroup,
+    // Hubs, not flat links: Customers expands to Reviews, Money to its three
+    // logs, Analytics to its Sales and Customers views. `group` keeps them
+    // collapsible. Analytics was the last flat row in the spine — its views
+    // existed only as an in-page tab strip, which advertised them to nobody
+    // who hadn't already opened the page.
+    ...group(customersGroup),
+    // Only for a shell that charges somebody. See `takes-money.ts`.
+    ...takesMoney ? group(paymentsGroup) : [],
+    /**
+     * STILL NO TOP-LEVEL HARDWARE ROW. John, 2026-09-03, moved it to Settings
+     * because hardware is infrastructure a business sets up and then operates,
+     * not a place it visits; and on 2026-10-05 moved it again, to Money, where
+     * the machines that take the money sit beside the money they take. It is a
+     * row inside that group (see `spine-money.ts`), not a rail row of its own.
+     *
+     * `buildHardwareGroup` is unchanged and still exported, so the machines, the
+     * requests and their permissions keep one definition.
+     */
+    ...group(analyticsGroup),
+    ...group(marketingGroup),
+    ...group(operationsGroup),
+    // Website is gated on its own permission, not on its children: every row
+    // inside needs a manage grant, so a member who may only LOOK at the site
+    // (canViewWebsite) has none left, and `group` dropped the hub for them. The
+    // hub's landing page ("Your site") is theirs to open, and a childless hub
+    // draws as a plain link.
+    ...makeFlatGroup(can)(websiteGroup),
+    ...group(settingsGroup)
+  ];
+}
+export {
+  buildSpineGroups
+};
+//# sourceMappingURL=spine-groups.js.map

package/dist/sidebar/spine-groups.js.map

@@ -0,0 +1 @@
+{"version":3,"sources":["../../src/sidebar/spine-groups.ts"],"sourcesContent":["/**\n * The fixed spine of the sidebar: Catalog, Customers, Payments, Analytics,\n * Marketing, Website and Settings.\n *\n * Split out of build-nav-groups.ts to keep both files under the 500-line house\n * limit. It reads nothing from component state — the four helpers it needs are\n * passed in, so the rules about what a member may see live in ONE place rather\n * than being re-derived here.\n */\nimport {\n  Route,\n  ChartNoAxesCombined,\n  Users,\n  Building2,\n  ToggleLeft,\n  Mail,\n  Bell,\n  Percent,\n  Scale,\n  Settings,\n} from 'lucide-react';\nimport { useIntentConfig } from '@withpotter/lib/intents/use-intent-config';\nimport { resolveAnalyticsViews } from '@withpotter/lib/intents/analytics-labels';\nimport { useCurrentTemplate } from '@withpotter/lib/template-context';\nimport { usePermissions } from '@withpotter/lib/use-permissions';\nimport { resolveEnabledBehaviors } from '@withpotter/lib/resolve-enabled-behaviors';\nimport { type NavItem, type NavGroup } from './config';\nimport { buildWebsiteGroup } from './spine-website';\nimport { buildOperationsGroup } from './spine-operations';\nimport { buildMarketingGroup } from './spine-marketing';\nimport { buildMoneyGroup } from './spine-money';\nimport { buildCustomersGroup } from './spine-customers';\nimport { shellTakesMoney } from './takes-money';\nimport { groupItems } from './flatten-work-groups';\nimport { makeFlatGroup } from './nav-gates';\n\nexport interface SpineDeps {\n  filterItems: (items: NavItem[]) => NavItem[];\n  coreItem: (id: string, labelOverride?: string) => NavItem | null;\n  group: (g: NavGroup) => NavGroup[];\n  /**\n   * Rows several archetypes share — one Catalog, one Orders — as their own\n   * links above the archetype groups. They belong to no single archetype, so\n   * they are not filed under one.\n   */\n  sharedGroups: NavGroup[];\n  intentGroups: NavGroup[];\n  catalogToolsGroup: NavGroup[];\n  can: ReturnType<typeof usePermissions>['can'];\n  enabledBehaviors: ReturnType<typeof resolveEnabledBehaviors>;\n  intentConfig: ReturnType<typeof useIntentConfig>;\n  template: ReturnType<typeof useCurrentTemplate>['template'];\n}\n\nexport function buildSpineGroups({\n  filterItems,\n  coreItem,\n  group,\n  sharedGroups,\n  intentGroups,\n  catalogToolsGroup,\n  can,\n  enabledBehaviors,\n  intentConfig,\n}: SpineDeps): NavGroup[] {\n  // ── Spine groups ──────────────────────────────────────────────────────\n  // Home is rendered separately (a fixed link). Everything below is the\n  // adaptive money-model work surfaces, then the fixed spine.\n\n  const takesMoney = shellTakesMoney(enabledBehaviors);\n  // Customers is the relationship hub: the directory (header link), segments,\n  // loyalty. The Inbox is not in it any more; it is a row of its own under\n  // Home (`inbox-row.ts`).\n  const owns = (id: string) =>\n    intentGroups.some((group) =>\n      group.items?.some(\n        (item) =>\n          item.id === id || item.children?.some((child) => child.id === id),\n      ),\n    );\n\n  // Same question for invoices, and for the same reason: `shares` collapses one\n  // archetype against another, never an archetype row against a spine child.\n  const intentOwnsInvoices = owns('invoices');\n\n  // The archetype OR the behaviour, because they come apart: a shop can switch\n  // `subscribable` on in Settings → Business model without picking the\n  // membership archetype, and it has subscribers all the same.\n  const runsMembershipArchetype = intentConfig.all.some(\n    (config) => config.key === 'subscriptions',\n  );\n  const runsSubscriptions =\n    runsMembershipArchetype || enabledBehaviors.includes('subscribable');\n\n  const customersGroup = buildCustomersGroup({\n    filterItems,\n    takesMoney,\n    runsSubscriptions,\n    runsMembershipArchetype,\n  });\n\n  const paymentsGroup = buildMoneyGroup({\n    filterItems,\n    intentOwnsInvoices,\n    canSeeFinance: can('canViewFinance') || can('canManageFinance'),\n  });\n\n  // Every active archetype, through the same resolver the Analytics provider\n  // uses — the row and the view have to agree about which views exist, and they\n  // cannot if each works it out for itself.\n  const analyticsViews = resolveAnalyticsViews(intentConfig.all);\n\n  // Analytics measures; it never owns records. Every child here answers a\n  // question the merchant asks about the business, and links out to the surface\n  // that owns the thing being measured.\n  //\n  // The children are deliberately NOT the nouns of the other spine rows.\n  // `analytics-retention` carries its own id because an item id does not\n  // identify a screen: reusing `customers` here would have collided with the\n  // Customers hub in three separate places (icon lookup by id, destination\n  // sharing, and label renaming by module).\n  //\n  // Traffic IS here, last. It lived under Website beside the storefront it\n  // measures, and was moved in 2026-10-06: it is a report, and reports are\n  // found under Analytics. The screen is still the Website's\n  // (`/dashboard/business/traffic`); only the way in moved. It sits outside\n  // the archetype filter below because that filter is about which BUSINESS\n  // views a model has, and every site has visitors.\n  const analyticsGroup: NavGroup = {\n    id: 'analytics',\n    label: 'Analytics',\n    icon: ChartNoAxesCombined,\n    href: '/dashboard/analytics',\n    /**\n     * The landing view IS the sales view — there is no \"Overview\". An overview\n     * of a two-page hub is a summary of what is already on the next screen, and\n     * the word names nothing: every hub has one, so it distinguishes nothing\n     * about this one.\n     *\n     * `Sales summary`, not `Sales`, and that is a correction. Money already\n     * carries a row called Sales — the cross-rail register of everything sold,\n     * where each row opens the record to act on it — so a multi-model merchant\n     * saw the word twice in one sidebar, pointing at two different screens. It\n     * went unseen for the usual reason: the `sales` row is gated on `isMulti`,\n     * so the collision only exists on the businesses that run more than one\n     * model, which is 16 of the walkthrough set.\n     *\n     * The hub had already made this exact call one row down: Retention is named\n     * Retention BECAUSE \"Customers\" was taken by the spine row above it. Same\n     * rule, applied to the row that was missed.\n     *\n     * The report takes the qualifier rather than the register, because the\n     * register is the place and this is the measurement of it — and because\n     * `VIEW_TITLES` in the hub's layout has titled this document \"Sales\n     * summary\" all along. The row and the title agreeing costs nothing here;\n     * they were allowed to differ, not required to.\n     */\n    landingLabel: 'Sales overview',\n    requiredPermission: ['canViewAnalytics'],\n    // One child plus the landing page. Without this, `renderHub` collapses a\n    // lone child into a flat link and Retention would never appear.\n    alwaysHub: true,\n    items: filterItems(\n      (\n        [\n          // No `Orders` row. The order report is an INSTRUMENT, not a subject:\n          // it is one object — a measure crossed with a dimension over a\n          // window — and Square's seven report rows are that same object with\n          // different `Group metric by` presets, not seven different things.\n          // Listing it beside Sales and Retention put a tool in a list of\n          // topics, which is why the hub read as three unrelated pages.\n          //\n          // It is reached by drilling instead: every panel that has a cut\n          // carries a link into `/dashboard/analytics/orders` with its own\n          // dimension already set, the way Shopify's overview cards each open\n          // the report that owns them. The route still exists and is still\n          // addressable — it just is not a place you navigate to cold, because\n          // arriving with no question is what made it a wall of controls.\n          {\n            /**\n             * Attribution, which was a fourth row under Marketing until\n             * 2026-08-27.\n             *\n             * It always answered to `canViewAnalytics` — the old row said so in\n             * its own comment — which is the tell that it was filed under the\n             * wrong parent: a row whose permission belongs to another group is\n             * a report that has been shelved with the tools.\n             *\n             * The campaign-level answer never lived on it anyway. What a send\n             * earned is the Attributable sales column on the campaigns table,\n             * and `useCampaignRevenue` gets it from the SAME endpoint this page\n             * calls. What is left — Sources, Channels, Promotions — is not\n             * campaign-scoped at all: it is where the money came from, which is\n             * the same kind of question as Sales and Retention beside it.\n             *\n             * Checked live in Square (2026-08-27): they have no attribution\n             * page. It is a column called \"Attributable Sales\" on the campaign\n             * row and nothing more. We keep the report because Sources and\n             * Channels answer what a column cannot — an order that carried no\n             * campaign still came from somewhere — but not as a marketing row.\n             */\n            id: 'analytics-attribution',\n            name: 'Acquisition',\n            href: '/dashboard/analytics/acquisition',\n            icon: Route,\n            requiredPermission: ['canViewAnalytics'],\n          },\n          {\n            // Not `Customers`. That word is already a spine row directly above\n            // this one, and two rows reading the same noun at different depths\n            // is the confusion this hub exists to avoid. It is also not the\n            // right word: the Customers hub owns the PEOPLE — a list you open\n            // and edit — while this measures their BEHAVIOUR, which is a thing\n            // you cannot click into one of.\n            //\n            // Renaming would not have fixed it either: a hotel that relabels\n            // the hub to \"Guests\" would simply have read \"Guests\" twice.\n            id: 'analytics-retention',\n            name: 'Retention',\n            href: '/dashboard/analytics/retention',\n            icon: Users,\n            requiredPermission: ['canViewAnalytics'],\n          },\n        ] as NavItem[]\n      ).filter(\n        // An archetype that names its analytics views gets only those. The\n        // row and the page have to agree: the view decides its own sections\n        // from the same declaration, so a nav child pointing at a view that\n        // renders nothing would be a link to an empty screen.\n        (item) =>\n          !analyticsViews ||\n          analyticsViews.includes(item.id.replace('analytics-', '')),\n      ),\n    ),\n  };\n\n  const marketingGroup = buildMarketingGroup({\n    filterItems,\n    enabledBehaviors,\n  });\n\n  const websiteGroup = buildWebsiteGroup({ filterItems, coreItem });\n  const staffTaken = [...sharedGroups, ...intentGroups].some((g) =>\n    groupItems(g).some(\n      (item) =>\n        item.name === 'Staff' ||\n        item.children?.some((child) => child.name === 'Staff'),\n    ),\n  );\n  const operationsGroup = buildOperationsGroup(filterItems, { staffTaken });\n\n  // Settings is scoped to THIS business (the current tenant). Account-level\n  // concerns — your personal profile/login, and switching between the\n  // businesses in your account — are a separate tier that belongs in the\n  // account menu, not here; they're intentionally left out of this group.\n  const settingsGroup: NavGroup = {\n    id: 'settings',\n    label: 'Settings',\n    icon: Settings,\n    sections: [\n      {\n        id: 'settings-business',\n        // Same three buckets, same names as the settings rail (BUSINESS_GROUPS)\n        // and the workspace hub. They used to read Workspace / Operations /\n        // Compliance here and Setup / Selling / Records there, for the same\n        // destinations — so whichever a merchant learned first was wrong in\n        // the other place.\n        label: 'Setup',\n        items: filterItems([\n          {\n            id: 'business-profile',\n            // 'General' everywhere. The rail and the hub already call it\n            // that; only this list said 'Business profile'.\n            name: 'General',\n            href: '/dashboard/settings',\n            icon: Building2,\n            requiredPermission: ['canManageBusinessProfile'],\n          },\n          {\n            id: 'features',\n            name: 'Features',\n            href: '/dashboard/settings/features',\n            icon: ToggleLeft,\n            requiredPermission: ['canManageSettings'],\n          },\n          // Configuration, not history — it was filed under Records beside\n          // Activity, which is the log group. No requiredPermission: every\n          // active member has a personal notification section on this page,\n          // and the tenant-wide config is gated inside it.\n          {\n            id: 'notifications',\n            name: 'Notifications',\n            href: '/dashboard/settings/notifications',\n            icon: Bell,\n          },\n          // Connectors lives in Customize now. See config.ts.\n        ]),\n      },\n      {\n        id: 'settings-operations',\n        label: 'Selling',\n        items: filterItems([\n          {\n            id: 'taxes',\n            name: 'Taxes',\n            href: '/dashboard/business/checkout?tab=taxes',\n            icon: Percent,\n            requiredPermission: ['canManageSettings'],\n          },\n          {\n            id: 'policies',\n            name: 'Policies',\n            href: '/dashboard/settings/policies',\n            icon: Scale,\n            requiredPermission: ['canManageSettings'],\n          },\n          // Plan & billing is per-WORKSPACE. This comment used to claim the\n          // opposite while `config.ts` two files away claimed the truth, and\n          // the schema settles it: `billing_subscriptions.tenantId` is unique,\n          // and every credit table is `tenant_*` keyed on `tenantId`. It is\n          // listed in the business-scoped Setup group, not the account menu.\n        ]),\n      },\n      {\n        id: 'settings-compliance',\n        label: 'Records',\n        items: filterItems([\n          {\n            id: 'email',\n            name: 'Email',\n            href: '/dashboard/settings/email',\n            icon: Mail,\n            requiredPermission: ['canManageCommunications'],\n          },\n        ]),\n      },\n    ].filter((section) => section.items.length > 0),\n  };\n\n  // No Today row anywhere any more. It and the Appointments calendar drew the\n  // same day over the same records and only one of them could act on it, so\n  // they are one surface with a view switch — /dashboard/bookings?view=today —\n  // and /dashboard/today redirects into it.\n  //\n  // No Sales row here either. It is a child of Money now: it stood beside\n  // Orders as a peer and the two words do not carry their difference, so the\n  // read moved to the hub whose question it answers. See `spine-money.ts`.\n\n  return [\n    ...sharedGroups,\n    ...intentGroups,\n    ...catalogToolsGroup,\n    // Hubs, not flat links: Customers expands to Reviews, Money to its three\n    // logs, Analytics to its Sales and Customers views. `group` keeps them\n    // collapsible. Analytics was the last flat row in the spine — its views\n    // existed only as an in-page tab strip, which advertised them to nobody\n    // who hadn't already opened the page.\n    ...group(customersGroup),\n    // Only for a shell that charges somebody. See `takes-money.ts`.\n    ...(takesMoney ? group(paymentsGroup) : []),\n    /**\n     * STILL NO TOP-LEVEL HARDWARE ROW. John, 2026-09-03, moved it to Settings\n     * because hardware is infrastructure a business sets up and then operates,\n     * not a place it visits; and on 2026-10-05 moved it again, to Money, where\n     * the machines that take the money sit beside the money they take. It is a\n     * row inside that group (see `spine-money.ts`), not a rail row of its own.\n     *\n     * `buildHardwareGroup` is unchanged and still exported, so the machines, the\n     * requests and their permissions keep one definition.\n     */\n    ...group(analyticsGroup),\n    ...group(marketingGroup),\n    ...group(operationsGroup),\n    // Website is gated on its own permission, not on its children: every row\n    // inside needs a manage grant, so a member who may only LOOK at the site\n    // (canViewWebsite) has none left, and `group` dropped the hub for them. The\n    // hub's landing page (\"Your site\") is theirs to open, and a childless hub\n    // draws as a plain link.\n    ...makeFlatGroup(can)(websiteGroup),\n    ...group(settingsGroup),\n  ];\n}\n"],"mappings":"AASA;AAAA,EACE;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,OACK;AAEP,SAAS,6BAA6B;AAKtC,SAAS,yBAAyB;AAClC,SAAS,4BAA4B;AACrC,SAAS,2BAA2B;AACpC,SAAS,uBAAuB;AAChC,SAAS,2BAA2B;AACpC,SAAS,uBAAuB;AAChC,SAAS,kBAAkB;AAC3B,SAAS,qBAAqB;AAoBvB,SAAS,iBAAiB;AAAA,EAC/B;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AACF,GAA0B;AAKxB,QAAM,aAAa,gBAAgB,gBAAgB;AAInD,QAAM,OAAO,CAAC,OACZ,aAAa;AAAA,IAAK,CAACA,WACjBA,OAAM,OAAO;AAAA,MACX,CAAC,SACC,KAAK,OAAO,MAAM,KAAK,UAAU,KAAK,CAAC,UAAU,MAAM,OAAO,EAAE;AAAA,IACpE;AAAA,EACF;AAIF,QAAM,qBAAqB,KAAK,UAAU;AAK1C,QAAM,0BAA0B,aAAa,IAAI;AAAA,IAC/C,CAAC,WAAW,OAAO,QAAQ;AAAA,EAC7B;AACA,QAAM,oBACJ,2BAA2B,iBAAiB,SAAS,cAAc;AAErE,QAAM,iBAAiB,oBAAoB;AAAA,IACzC;AAAA,IACA;AAAA,IACA;AAAA,IACA;AAAA,EACF,CAAC;AAED,QAAM,gBAAgB,gBAAgB;AAAA,IACpC;AAAA,IACA;AAAA,IACA,eAAe,IAAI,gBAAgB,KAAK,IAAI,kBAAkB;AAAA,EAChE,CAAC;AAKD,QAAM,iBAAiB,sBAAsB,aAAa,GAAG;AAkB7D,QAAM,iBAA2B;AAAA,IAC/B,IAAI;AAAA,IACJ,OAAO;AAAA,IACP,MAAM;AAAA,IACN,MAAM;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAyBN,cAAc;AAAA,IACd,oBAAoB,CAAC,kBAAkB;AAAA;AAAA;AAAA,IAGvC,WAAW;AAAA,IACX,OAAO;AAAA,MAEH;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,QAcE;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,UAuBE,IAAI;AAAA,UACJ,MAAM;AAAA,UACN,MAAM;AAAA,UACN,MAAM;AAAA,UACN,oBAAoB,CAAC,kBAAkB;AAAA,QACzC;AAAA,QACA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,UAUE,IAAI;AAAA,UACJ,MAAM;AAAA,UACN,MAAM;AAAA,UACN,MAAM;AAAA,UACN,oBAAoB,CAAC,kBAAkB;AAAA,QACzC;AAAA,MACF,EACA;AAAA;AAAA;AAAA;AAAA;AAAA,QAKA,CAAC,SACC,CAAC,kBACD,eAAe,SAAS,KAAK,GAAG,QAAQ,cAAc,EAAE,CAAC;AAAA,MAC7D;AAAA,IACF;AAAA,EACF;AAEA,QAAM,iBAAiB,oBAAoB;AAAA,IACzC;AAAA,IACA;AAAA,EACF,CAAC;AAED,QAAM,eAAe,kBAAkB,EAAE,aAAa,SAAS,CAAC;AAChE,QAAM,aAAa,CAAC,GAAG,cAAc,GAAG,YAAY,EAAE;AAAA,IAAK,CAAC,MAC1D,WAAW,CAAC,EAAE;AAAA,MACZ,CAAC,SACC,KAAK,SAAS,WACd,KAAK,UAAU,KAAK,CAAC,UAAU,MAAM,SAAS,OAAO;AAAA,IACzD;AAAA,EACF;AACA,QAAM,kBAAkB,qBAAqB,aAAa,EAAE,WAAW,CAAC;AAMxE,QAAM,gBAA0B;AAAA,IAC9B,IAAI;AAAA,IACJ,OAAO;AAAA,IACP,MAAM;AAAA,IACN,UAAU;AAAA,MACR;AAAA,QACE,IAAI;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,QAMJ,OAAO;AAAA,QACP,OAAO,YAAY;AAAA,UACjB;AAAA,YACE,IAAI;AAAA;AAAA;AAAA,YAGJ,MAAM;AAAA,YACN,MAAM;AAAA,YACN,MAAM;AAAA,YACN,oBAAoB,CAAC,0BAA0B;AAAA,UACjD;AAAA,UACA;AAAA,YACE,IAAI;AAAA,YACJ,MAAM;AAAA,YACN,MAAM;AAAA,YACN,MAAM;AAAA,YACN,oBAAoB,CAAC,mBAAmB;AAAA,UAC1C;AAAA;AAAA;AAAA;AAAA;AAAA,UAKA;AAAA,YACE,IAAI;AAAA,YACJ,MAAM;AAAA,YACN,MAAM;AAAA,YACN,MAAM;AAAA,UACR;AAAA;AAAA,QAEF,CAAC;AAAA,MACH;AAAA,MACA;AAAA,QACE,IAAI;AAAA,QACJ,OAAO;AAAA,QACP,OAAO,YAAY;AAAA,UACjB;AAAA,YACE,IAAI;AAAA,YACJ,MAAM;AAAA,YACN,MAAM;AAAA,YACN,MAAM;AAAA,YACN,oBAAoB,CAAC,mBAAmB;AAAA,UAC1C;AAAA,UACA;AAAA,YACE,IAAI;AAAA,YACJ,MAAM;AAAA,YACN,MAAM;AAAA,YACN,MAAM;AAAA,YACN,oBAAoB,CAAC,mBAAmB;AAAA,UAC1C;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,QAMF,CAAC;AAAA,MACH;AAAA,MACA;AAAA,QACE,IAAI;AAAA,QACJ,OAAO;AAAA,QACP,OAAO,YAAY;AAAA,UACjB;AAAA,YACE,IAAI;AAAA,YACJ,MAAM;AAAA,YACN,MAAM;AAAA,YACN,MAAM;AAAA,YACN,oBAAoB,CAAC,yBAAyB;AAAA,UAChD;AAAA,QACF,CAAC;AAAA,MACH;AAAA,IACF,EAAE,OAAO,CAAC,YAAY,QAAQ,MAAM,SAAS,CAAC;AAAA,EAChD;AAWA,SAAO;AAAA,IACL,GAAG;AAAA,IACH,GAAG;AAAA,IACH,GAAG;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAMH,GAAG,MAAM,cAAc;AAAA;AAAA,IAEvB,GAAI,aAAa,MAAM,aAAa,IAAI,CAAC;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAWzC,GAAG,MAAM,cAAc;AAAA,IACvB,GAAG,MAAM,cAAc;AAAA,IACvB,GAAG,MAAM,eAAe;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAMxB,GAAG,cAAc,GAAG,EAAE,YAAY;AAAA,IAClC,GAAG,MAAM,aAAa;AAAA,EACxB;AACF;","names":["group"]}

package/dist/sidebar/spine-hardware.d.ts

@@ -0,0 +1,2 @@
+import { type NavGroup, type NavItem } from './config';
+export declare function buildHardwareGroup(filterItems: (items: NavItem[]) => NavItem[]): NavGroup;

package/dist/sidebar/spine-hardware.js

@@ -0,0 +1,52 @@
+import { Tablet, PackagePlus } from "lucide-react";
+function buildHardwareGroup(filterItems) {
+  return {
+    id: "hardware",
+    label: "Hardware",
+    icon: Tablet,
+    href: "/dashboard/hardware",
+    /**
+     * The registry, once it sits among its own children.
+     *
+     * "Devices" and not "All hardware": the children are the machines and the
+     * ones on order, and the landing page is specifically the first of those.
+     */
+    landingLabel: "Devices",
+    /**
+     * Hardware, falling back to Finance.
+     *
+     * Both while the two coexist: the api takes either on every device route,
+     * so a custom role built around Finance keeps reaching the machines it
+     * always could, and a shop manager who must never see a payout now reaches
+     * them too.
+     */
+    requiredPermission: [
+      "canViewHardware",
+      "canManageHardware",
+      "canViewFinance"
+    ],
+    items: filterItems([
+      {
+        /**
+         * Machines asked for and not yet owned. A different question from "is
+         * till 2 online", which is what the registry answers.
+         *
+         * "Requests", not "Orders": the spine already has an Orders row for
+         * what customers buy, and two rows carrying one word is what the nav
+         * guard exists to catch. It caught it. Requests is also the merchant's
+         * own word for this — you request a till, you do not order from
+         * yourself.
+         */
+        id: "hardware-requests",
+        name: "Requests",
+        href: "/dashboard/hardware/requests",
+        icon: PackagePlus,
+        requiredPermission: ["canViewHardware", "canViewFinance"]
+      }
+    ])
+  };
+}
+export {
+  buildHardwareGroup
+};
+//# sourceMappingURL=spine-hardware.js.map

package/dist/sidebar/spine-hardware.js.map

@@ -0,0 +1 @@
+{"version":3,"sources":["../../src/sidebar/spine-hardware.ts"],"sourcesContent":["/**\n * Hardware: the machines standing in the merchant's buildings, and what\n * happened at them.\n *\n * A group with two rows: the machines, and the ones asked for and not yet\n * owned. Shifts used to be the third, and it is gone — a drawer session is not\n * something a merchant goes looking for by itself, it is something that\n * happened at a machine, to a person, and it now lives on the machine's record\n * and on the operator's. The reconciliation screen it opened is untouched;\n * only the row above it went.\n *\n * It is here at all because Devices was taken off the Money rail on 2026-08-24\n * with a note saying what it would take to come back: \"If either comes back it\n * is as its own row, not a fourth money log.\" A device that opens a door\n * produces no transaction, so Money was never the right parent.\n */\nimport { Tablet, PackagePlus } from 'lucide-react';\nimport { type NavGroup, type NavItem } from './config';\n\nexport function buildHardwareGroup(\n  filterItems: (items: NavItem[]) => NavItem[],\n): NavGroup {\n  return {\n    id: 'hardware',\n    label: 'Hardware',\n    icon: Tablet,\n    href: '/dashboard/hardware',\n    /**\n     * The registry, once it sits among its own children.\n     *\n     * \"Devices\" and not \"All hardware\": the children are the machines and the\n     * ones on order, and the landing page is specifically the first of those.\n     */\n    landingLabel: 'Devices',\n    /**\n     * Hardware, falling back to Finance.\n     *\n     * Both while the two coexist: the api takes either on every device route,\n     * so a custom role built around Finance keeps reaching the machines it\n     * always could, and a shop manager who must never see a payout now reaches\n     * them too.\n     */\n    requiredPermission: [\n      'canViewHardware',\n      'canManageHardware',\n      'canViewFinance',\n    ],\n    items: filterItems([\n      {\n        /**\n         * Machines asked for and not yet owned. A different question from \"is\n         * till 2 online\", which is what the registry answers.\n         *\n         * \"Requests\", not \"Orders\": the spine already has an Orders row for\n         * what customers buy, and two rows carrying one word is what the nav\n         * guard exists to catch. It caught it. Requests is also the merchant's\n         * own word for this — you request a till, you do not order from\n         * yourself.\n         */\n        id: 'hardware-requests',\n        name: 'Requests',\n        href: '/dashboard/hardware/requests',\n        icon: PackagePlus,\n        requiredPermission: ['canViewHardware', 'canViewFinance'],\n      },\n    ]),\n  };\n}\n"],"mappings":"AAgBA,SAAS,QAAQ,mBAAmB;AAG7B,SAAS,mBACd,aACU;AACV,SAAO;AAAA,IACL,IAAI;AAAA,IACJ,OAAO;AAAA,IACP,MAAM;AAAA,IACN,MAAM;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAON,cAAc;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IASd,oBAAoB;AAAA,MAClB;AAAA,MACA;AAAA,MACA;AAAA,IACF;AAAA,IACA,OAAO,YAAY;AAAA,MACjB;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,QAWE,IAAI;AAAA,QACJ,MAAM;AAAA,QACN,MAAM;AAAA,QACN,MAAM;AAAA,QACN,oBAAoB,CAAC,mBAAmB,gBAAgB;AAAA,MAC1D;AAAA,IACF,CAAC;AAAA,EACH;AACF;","names":[]}

package/dist/sidebar/spine-marketing.d.ts

@@ -0,0 +1,7 @@
+import { type NavItem, type NavGroup } from './config';
+import type { resolveEnabledBehaviors } from '@withpotter/lib/resolve-enabled-behaviors';
+export interface MarketingGroupDeps {
+    filterItems: (items: NavItem[]) => NavItem[];
+    enabledBehaviors: ReturnType<typeof resolveEnabledBehaviors>;
+}
+export declare function buildMarketingGroup({ filterItems, }: MarketingGroupDeps): NavGroup;

package/dist/sidebar/spine-marketing.js

@@ -0,0 +1,131 @@
+import { CreditCard, Gift, Megaphone, Tag, Users, Workflow } from "lucide-react";
+const HIDE_AUTOMATIONS = process.env.NEXT_PUBLIC_BOX_HIDE_AUTOMATIONS === "true";
+function buildMarketingGroup({
+  filterItems
+}) {
+  return {
+    id: "marketing",
+    label: "Marketing",
+    icon: Megaphone,
+    // The hub, not the discounts table. This group pointed at /dashboard/
+    // discounts because Marketing had no route of its own, which left
+    // Campaigns, Automations and Abandoned carts with no way in from here.
+    href: "/dashboard/marketing",
+    // That page IS the campaigns list — nothing else now — so as a child it
+    // can say so plainly. It used to be unnamed on purpose: a child link
+    // pointing at the same screen as its own parent is the nav disagreeing
+    // with itself. Now that the parent is a container and not a screen, there
+    // is nothing to disagree with.
+    //
+    // It also fixes the highlight. `isActive` matches by path prefix and
+    // /dashboard/marketing is not an exact-match route, so every page nested
+    // under it lit this row — a merchant reading Automations was told they
+    // were on Campaigns. The deepest matching row wins, so giving the nested
+    // screens rows of their own is what makes the highlight honest; there is
+    // no longer a screen down there without one.
+    landingLabel: "Campaigns",
+    // Without this `renderHub` folds a lone child into a flat link, exactly as
+    // it did to Analytics before Retention got the same flag. It stays set
+    // whatever the child count, because the count is not the contract.
+    alwaysHub: true,
+    /**
+     * What did we send, what are we offering, and did any of it work.
+     *
+     * Two rows and a landing, each a place. The group used to be one screen
+     * wearing tabs: Campaigns was the landing, Discounts was a query param on
+     * it (`?view=discounts`), Gift cards was a row, and Automations and
+     * Abandoned carts had no row at all — reachable only through a text link
+     * in a rail on one of the two tabs. Three sibling ideas at three depths,
+     * with two real screens off the map entirely.
+     *
+     * The rule now: everything that goes out to a customer is a campaign,
+     * whether you pressed send or an event did — but the ones an event sends
+     * are their own row rather than a card on top of the list, because both
+     * references file them that way and because a page of switches above a
+     * table made the campaigns page open on configuration; an offer is an
+     * offer (Discounts and Gift cards are two tabs on Promotions, at the same
+     * depth, behind the same grant); and what any of it earned is Attribution.
+     * Loyalty stays in Customers, where the members it is about already live;
+     * Reviews (reputation) went there too, and Blog (a CMS) went back to
+     * Website.
+     *
+     * REFERRALS came the other way. It was Loyalty's, behind a link at the
+     * bottom of that page and no row of its own, on the grounds that it pays
+     * in points. Paying in points is the mechanism; the thing itself is asking
+     * your customers to bring you customers, which is a channel — the only one
+     * whose sender is somebody else. It is here for the same reason Campaigns
+     * is.
+     */
+    items: filterItems(
+      [
+        /**
+         * Discounts and Gift cards, at last at the same depth, under the
+         * trade's word rather than "Offers" — a container word covering two
+         * nouns names neither. Gift cards was filed under Payments before that,
+         * where the permissions gave the mistake away: that hub gates on
+         * `canViewFinance` and this on `canManageDiscounts`, so a finance-only
+         * member saw a child they could not open.
+         *
+         * Both tabs are checkout mechanics, so the row needs a checkout: a
+         * billing business's money moment is a document, and neither the
+         * invoice editor nor `create-invoice` has ever taken a code.
+         */
+        // A row again: folded into the campaigns list, the flows became a
+        // card of switches ABOVE the table, so that page opened on
+        // configuration and never said what the sending earned. Square files
+        // these as their own route and Shopify as their own section; neither
+        // stacks them on the list.
+        {
+          // The offers a merchant makes at checkout. They were filed in the
+          // Campaigns page's menu on the three-row cap; a group may hold more
+          // rows than that, and merchants look for this word in the sidebar.
+          id: "discounts",
+          name: "Discounts",
+          href: "/dashboard/marketing/promotions?view=discounts",
+          icon: Tag,
+          requiredPermission: ["canViewDiscounts", "canManageDiscounts"]
+        },
+        {
+          // The same page's second tab, paid out through the loyalty programme.
+          id: "referrals",
+          name: "Referrals",
+          href: "/dashboard/marketing/promotions?view=referrals",
+          icon: Gift,
+          requiredPermission: ["canViewMembers", "canManageMembers"],
+          // Served by the main API only. An engine without a referrals module
+          // does not list the capability, so the row is not drawn there.
+          requiredCapability: "referrals"
+        },
+        !HIDE_AUTOMATIONS && {
+          id: "automations",
+          name: "Automations",
+          href: "/dashboard/marketing/automations",
+          icon: Workflow
+        },
+        {
+          // Always here, for every business: the book of issued cards sits with
+          // what a business offers its customers, and every intent can sell a
+          // card. It is where a merchant who has never sold one goes to start.
+          id: "gift-cards",
+          name: "Gift cards",
+          href: "/dashboard/gift-cards",
+          icon: CreditCard,
+          requiredPermission: ["canViewDiscounts", "canManageDiscounts"]
+        },
+        {
+          // Segments, filed under Marketing as Audiences: who you are sending
+          // to. The screen is the Customers hub's, so the id is its own.
+          id: "audiences",
+          name: "Audiences",
+          href: "/dashboard/marketing/audiences",
+          icon: Users,
+          requiredPermission: ["canViewMembers", "canManageMembers"]
+        }
+      ].filter(Boolean)
+    )
+  };
+}
+export {
+  buildMarketingGroup
+};
+//# sourceMappingURL=spine-marketing.js.map

package/dist/sidebar/spine-marketing.js.map

@@ -0,0 +1 @@
+{"version":3,"sources":["../../src/sidebar/spine-marketing.ts"],"sourcesContent":["/**\n * The Marketing hub, lifted out of `spine-groups.ts`.\n *\n * Same cut as `spine-money.ts` and `spine-website.ts`, and for the same\n * reason: that file sits over the house limit, and this group's own argument —\n * what goes out to a customer, what you are offering, and what any of it\n * earned — is long enough to read on its own. It grew again when Abandoned\n * carts arrived from the archetype configs, which is what pushed the parent\n * over.\n *\n * Two dependencies, both taken as arguments rather than closed over, so the\n * questions the group asks are visible in the signature: what this business\n * can filter to, and what it sells.\n */\nimport { CreditCard, Gift, Megaphone, Tag, Users, Workflow } from 'lucide-react';\nimport { type NavItem, type NavGroup } from './config';\nimport type { resolveEnabledBehaviors } from '@withpotter/lib/resolve-enabled-behaviors';\n\n/** A box that does not offer automations sets this, the same way one hides Billing. */\nconst HIDE_AUTOMATIONS =\n  process.env.NEXT_PUBLIC_BOX_HIDE_AUTOMATIONS === 'true';\n\nexport interface MarketingGroupDeps {\n  filterItems: (items: NavItem[]) => NavItem[];\n  enabledBehaviors: ReturnType<typeof resolveEnabledBehaviors>;\n}\n\nexport function buildMarketingGroup({\n  filterItems,\n}: MarketingGroupDeps): NavGroup {\n  return {\n    id: 'marketing',\n    label: 'Marketing',\n    icon: Megaphone,\n    // The hub, not the discounts table. This group pointed at /dashboard/\n    // discounts because Marketing had no route of its own, which left\n    // Campaigns, Automations and Abandoned carts with no way in from here.\n    href: '/dashboard/marketing',\n    // That page IS the campaigns list — nothing else now — so as a child it\n    // can say so plainly. It used to be unnamed on purpose: a child link\n    // pointing at the same screen as its own parent is the nav disagreeing\n    // with itself. Now that the parent is a container and not a screen, there\n    // is nothing to disagree with.\n    //\n    // It also fixes the highlight. `isActive` matches by path prefix and\n    // /dashboard/marketing is not an exact-match route, so every page nested\n    // under it lit this row — a merchant reading Automations was told they\n    // were on Campaigns. The deepest matching row wins, so giving the nested\n    // screens rows of their own is what makes the highlight honest; there is\n    // no longer a screen down there without one.\n    landingLabel: 'Campaigns',\n    // Without this `renderHub` folds a lone child into a flat link, exactly as\n    // it did to Analytics before Retention got the same flag. It stays set\n    // whatever the child count, because the count is not the contract.\n    alwaysHub: true,\n    /**\n     * What did we send, what are we offering, and did any of it work.\n     *\n     * Two rows and a landing, each a place. The group used to be one screen\n     * wearing tabs: Campaigns was the landing, Discounts was a query param on\n     * it (`?view=discounts`), Gift cards was a row, and Automations and\n     * Abandoned carts had no row at all — reachable only through a text link\n     * in a rail on one of the two tabs. Three sibling ideas at three depths,\n     * with two real screens off the map entirely.\n     *\n     * The rule now: everything that goes out to a customer is a campaign,\n     * whether you pressed send or an event did — but the ones an event sends\n     * are their own row rather than a card on top of the list, because both\n     * references file them that way and because a page of switches above a\n     * table made the campaigns page open on configuration; an offer is an\n     * offer (Discounts and Gift cards are two tabs on Promotions, at the same\n     * depth, behind the same grant); and what any of it earned is Attribution.\n     * Loyalty stays in Customers, where the members it is about already live;\n     * Reviews (reputation) went there too, and Blog (a CMS) went back to\n     * Website.\n     *\n     * REFERRALS came the other way. It was Loyalty's, behind a link at the\n     * bottom of that page and no row of its own, on the grounds that it pays\n     * in points. Paying in points is the mechanism; the thing itself is asking\n     * your customers to bring you customers, which is a channel — the only one\n     * whose sender is somebody else. It is here for the same reason Campaigns\n     * is.\n     */\n    items: filterItems(\n      [\n        /**\n         * Discounts and Gift cards, at last at the same depth, under the\n         * trade's word rather than \"Offers\" — a container word covering two\n         * nouns names neither. Gift cards was filed under Payments before that,\n         * where the permissions gave the mistake away: that hub gates on\n         * `canViewFinance` and this on `canManageDiscounts`, so a finance-only\n         * member saw a child they could not open.\n         *\n         * Both tabs are checkout mechanics, so the row needs a checkout: a\n         * billing business's money moment is a document, and neither the\n         * invoice editor nor `create-invoice` has ever taken a code.\n         */\n        // A row again: folded into the campaigns list, the flows became a\n        // card of switches ABOVE the table, so that page opened on\n        // configuration and never said what the sending earned. Square files\n        // these as their own route and Shopify as their own section; neither\n        // stacks them on the list.\n        {\n          // The offers a merchant makes at checkout. They were filed in the\n          // Campaigns page's menu on the three-row cap; a group may hold more\n          // rows than that, and merchants look for this word in the sidebar.\n          id: 'discounts',\n          name: 'Discounts',\n          href: '/dashboard/marketing/promotions?view=discounts',\n          icon: Tag,\n          requiredPermission: ['canViewDiscounts', 'canManageDiscounts'],\n        },\n        {\n          // The same page's second tab, paid out through the loyalty programme.\n          id: 'referrals',\n          name: 'Referrals',\n          href: '/dashboard/marketing/promotions?view=referrals',\n          icon: Gift,\n          requiredPermission: ['canViewMembers', 'canManageMembers'],\n          // Served by the main API only. An engine without a referrals module\n          // does not list the capability, so the row is not drawn there.\n          requiredCapability: 'referrals',\n        },\n        !HIDE_AUTOMATIONS && {\n          id: 'automations',\n          name: 'Automations',\n          href: '/dashboard/marketing/automations',\n          icon: Workflow,\n        },\n        {\n          // Always here, for every business: the book of issued cards sits with\n          // what a business offers its customers, and every intent can sell a\n          // card. It is where a merchant who has never sold one goes to start.\n          id: 'gift-cards',\n          name: 'Gift cards',\n          href: '/dashboard/gift-cards',\n          icon: CreditCard,\n          requiredPermission: ['canViewDiscounts', 'canManageDiscounts'],\n        },\n        {\n          // Segments, filed under Marketing as Audiences: who you are sending\n          // to. The screen is the Customers hub's, so the id is its own.\n          id: 'audiences',\n          name: 'Audiences',\n          href: '/dashboard/marketing/audiences',\n          icon: Users,\n          requiredPermission: ['canViewMembers', 'canManageMembers'],\n        },\n      ].filter(Boolean) as NavItem[],\n    ),\n  };\n}\n"],"mappings":"AAcA,SAAS,YAAY,MAAM,WAAW,KAAK,OAAO,gBAAgB;AAKlE,MAAM,mBACJ,QAAQ,IAAI,qCAAqC;AAO5C,SAAS,oBAAoB;AAAA,EAClC;AACF,GAAiC;AAC/B,SAAO;AAAA,IACL,IAAI;AAAA,IACJ,OAAO;AAAA,IACP,MAAM;AAAA;AAAA;AAAA;AAAA,IAIN,MAAM;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IAaN,cAAc;AAAA;AAAA;AAAA;AAAA,IAId,WAAW;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,IA6BX,OAAO;AAAA,MACL;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,QAkBE;AAAA;AAAA;AAAA;AAAA,UAIE,IAAI;AAAA,UACJ,MAAM;AAAA,UACN,MAAM;AAAA,UACN,MAAM;AAAA,UACN,oBAAoB,CAAC,oBAAoB,oBAAoB;AAAA,QAC/D;AAAA,QACA;AAAA;AAAA,UAEE,IAAI;AAAA,UACJ,MAAM;AAAA,UACN,MAAM;AAAA,UACN,MAAM;AAAA,UACN,oBAAoB,CAAC,kBAAkB,kBAAkB;AAAA;AAAA;AAAA,UAGzD,oBAAoB;AAAA,QACtB;AAAA,QACA,CAAC,oBAAoB;AAAA,UACnB,IAAI;AAAA,UACJ,MAAM;AAAA,UACN,MAAM;AAAA,UACN,MAAM;AAAA,QACR;AAAA,QACA;AAAA;AAAA;AAAA;AAAA,UAIE,IAAI;AAAA,UACJ,MAAM;AAAA,UACN,MAAM;AAAA,UACN,MAAM;AAAA,UACN,oBAAoB,CAAC,oBAAoB,oBAAoB;AAAA,QAC/D;AAAA,QACA;AAAA;AAAA;AAAA,UAGE,IAAI;AAAA,UACJ,MAAM;AAAA,UACN,MAAM;AAAA,UACN,MAAM;AAAA,UACN,oBAAoB,CAAC,kBAAkB,kBAAkB;AAAA,QAC3D;AAAA,MACF,EAAE,OAAO,OAAO;AAAA,IAClB;AAAA,EACF;AACF;","names":[]}

package/dist/sidebar/spine-money.d.ts

@@ -0,0 +1,18 @@
+import { type NavItem, type NavGroup } from './config';
+/**
+ * A box that files the machines under Money for everyone sets this. The row
+ * then shows for finance roles too, and Operations drops its own.
+ */
+export declare const POS_IN_MONEY: boolean;
+export interface MoneyGroupDeps {
+    filterItems: (items: NavItem[]) => NavItem[];
+    /**
+     * Whether this person can open the money pages. The group's own landing row is
+     * Transactions, a finance page, so without this a hardware-only role would be
+     * shown a link it cannot open. It then keeps one row, Hardware, drawn flat.
+     */
+    canSeeFinance: boolean;
+    /** The billing archetype puts Invoices in its own group; this drops ours. */
+    intentOwnsInvoices: boolean;
+}
+export declare function buildMoneyGroup({ filterItems, canSeeFinance, intentOwnsInvoices, }: MoneyGroupDeps): NavGroup;