@wildo-ai/saas-frontend-lib 1.1.4 → 1.1.5

package/dist/esm/core/config/engine-settings-destinations.js

@@ -41,10 +41,20 @@
  * `companion-exports`: a symbol reachable through two public doors is a symbol whose two doors
  * drift. Every consumer — including this package's own — imports it from `@wildo-ai/saas-models`.
  */
-import { CoreFeature, CoreResourceOperation, CoreResourceType, CORE_ORG_ROLES, EngineSettingsDestinationRef, ResourcePrimaryScope } from '@wildo-ai/saas-models';
+import { CoreFeature, CoreResourceOperation, CoreResourceType, CORE_APP_ROLES, CORE_ORG_ROLES, EngineSettingsDestinationRef, ResourcePrimaryScope } from '@wildo-ai/saas-models';
 import { SettingsPanelRef, SettingsSectionTargetKind } from './settings-hub.frontend.schemas.js';
 /** Org-management destinations are visible to organization owners and admins. */
 const ORG_MANAGEMENT_ROLES = [CORE_ORG_ROLES.ORG_OWNER, CORE_ORG_ROLES.ORG_ADMIN];
+/**
+ * Application-administration destinations are visible to the application's own super-administrator.
+ *
+ * ONE role, deliberately, and not the wider `APP_ADMIN_*` family: every destination gated with this
+ * is a surface whose resource ALSO requires `APP_ADMIN_SUPER_ADMIN` server-side, so admitting
+ * `APP_ADMIN_VIEWER` or `APP_ADMIN_BILLING_MANAGER` here would render a rail entry that answers 403
+ * on open — worse than absent, because it reads as a permission the operator has and a bug they hit.
+ * Widen this only alongside the operation roles it would then have to match.
+ */
+const APPLICATION_ADMINISTRATION_ROLES = [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN];
 /**
  * Runtime capability key for "billing is enabled for this app". Wired in
  * `useLauncherRuntimeAvailabilityContext` (`runtimeCapabilities.billingEnabled`);
@@ -54,12 +64,32 @@ const ORG_MANAGEMENT_ROLES = [CORE_ORG_ROLES.ORG_OWNER, CORE_ORG_ROLES.ORG_ADMIN
 const BILLING_ENABLED_CAPABILITY = 'billingEnabled';
 /**
  * Runtime capability keys for the enterprise-config features. Unlike billing
- * (which reads `appConfig.billing.enabled`), these have no app-config toggle —
- * they are wired in `useLauncherRuntimeAvailabilityContext` from
- * resource-registration presence (`hasResource(ORGANIZATION_*_CONFIG)`), so a
- * destination auto-hides when its app excludes the resource and otherwise
- * degrades to org-admin role gating. Keep these string literals in sync with the
- * keys emitted there.
+ * (which reads `appConfig.billing.enabled`), these have no app-config toggle.
+ *
+ * **They are ENTITLEMENT keys, not registration keys**, and the difference decides whether these
+ * sections appear at all. `useLauncherRuntimeAvailabilityContext` computes each one as
+ * `isFeatureOffered(CoreFeature.X)` — "does this application OFFER the feature", meaning the
+ * organization is entitled to it OR an upgrade/add-on in the billing catalogue grants it. Keep
+ * these string literals in sync with the keys emitted there.
+ *
+ * This docblock said the opposite until 2026-09-17: that they were "wired from resource-registration
+ * presence (`hasResource(ORGANIZATION_*_CONFIG)`), so a destination auto-hides when its app excludes
+ * the resource and otherwise degrades to org-admin role gating." No `hasResource` call has ever
+ * produced these keys. The correction matters because the two readings differ exactly where it hurts:
+ * under the old one, an application that REGISTERS the resource always sees the section, so the
+ * sections are effectively always on; under the truth, an application that registers the resource,
+ * migrates its tables and places the destination still shows NOTHING unless some product grants the
+ * feature or the feature defaults on.
+ *
+ * That is not hypothetical — it is how Wonder Todos, which has every one of these tables, offered
+ * none of the four to any account on any plan until the gap was measured.
+ *
+ * **A false capability REMOVES the destination; it does not lock it.** `requiredCapabilities` is a
+ * survival filter (`isLauncherRuntimeAvailabilitySatisfied`), so an unoffered feature produces an
+ * absent rail entry rather than an upgrade prompt. `isFeatureOffered` is deliberately the OFFERED
+ * axis rather than the ENTITLED one so that a billing-on organization whose plan lacks the feature
+ * still survives the filter and can render an upgrade prompt via `FeatureGate`; an application whose
+ * catalogue grants the feature nowhere offers it to nobody, and the section vanishes.
  */
 const SSO_ENABLED_CAPABILITY = 'ssoEnabled';
 const SCIM_ENABLED_CAPABILITY = 'scimEnabled';
@@ -174,6 +204,19 @@ export const ENGINE_SETTINGS_DESTINATIONS = [
             operation: CoreResourceOperation.LIST,
         },
     },
+    {
+        // The tenant's internal structure, on the rail rather than as a tab inside General. Two
+        // different kinds of surface: General is a RECORD — a column of decisions about the tenant — and
+        // a unit hierarchy is a POPULATION you navigate. Nested, it was also reachable only by opening a
+        // pane a reader had no other reason to open, which is a poor place to keep the org chart.
+        ref: EngineSettingsDestinationRef.ORGANIZATION_UNITS,
+        requiredRoles: ORG_MANAGEMENT_ROLES,
+        target: {
+            kind: SettingsSectionTargetKind.RESOURCE_OPERATION,
+            resourceType: CoreResourceType.ORGANIZATION_UNITS,
+            operation: CoreResourceOperation.LIST,
+        },
+    },
     {
         ref: EngineSettingsDestinationRef.BILLING,
         requiredRoles: ORG_MANAGEMENT_ROLES,
@@ -360,6 +403,299 @@ export const ENGINE_SETTINGS_DESTINATIONS = [
             operation: CoreResourceOperation.LIST,
         },
     },
+    {
+        /**
+         * What this organization is entitled to, and — for a platform administrator — the console that
+         * changes it.
+         *
+         * **No `requiredRoles`, and that is the substantive decision.** `organizationFeatures` READ is
+         * `ORG_MEMBER`, so any member may see what their organization actually has; the three operations
+         * that MUTATE it (`enable_feature`, `disable_feature`, `reset_features`) plus UPDATE are
+         * `APP_ADMIN_SUPER_ADMIN` on the resource itself. One screen therefore serves both readers
+         * honestly — a read-only summary for a member, a grant/withdraw console for an operator — without
+         * this destination having to know which one is looking.
+         *
+         * Gating it on org management instead would hide from members the exact page that explains why a
+         * feature they were just told to upgrade for is unavailable, which is the moment it is worth most.
+         *
+         * READ rather than LIST, because the resource is 1:1 with its organization: the URL builder drops
+         * the `{id}` segment for a one-to-one parent, and the factory declares no LIST at all.
+         */
+        ref: EngineSettingsDestinationRef.ORGANIZATION_ENTITLEMENTS,
+        target: {
+            kind: SettingsSectionTargetKind.RESOURCE_OPERATION,
+            resourceType: CoreResourceType.ORGANIZATION_FEATURES,
+            operation: CoreResourceOperation.READ,
+        },
+    },
+    {
+        // Referral codes belong to the billing DOMAIN and to the ORGANIZATION scope — the resource's
+        // primary scope really is `ORGANIZATIONS`, unlike products/prices/promotions beside it, which are
+        // application-scoped. So it is placed with the tenant's settings rather than the operator's
+        // catalogue, and gated on `ORG_OWNER` to match the resource's own READ/LIST roles.
+        ref: EngineSettingsDestinationRef.ORGANIZATION_REFERRALS,
+        requiredRoles: [CORE_ORG_ROLES.ORG_OWNER],
+        target: {
+            kind: SettingsSectionTargetKind.RESOURCE_OPERATION,
+            resourceType: CoreResourceType.REFERRALS,
+            operation: CoreResourceOperation.LIST,
+        },
+    },
+    // ── Application administration ─────────────────────────────────
+    //
+    // The operator's own surfaces. An application places these in a category scoped to
+    // `ResourcePrimaryScope.APPLICATION`, and that scope is what hides the whole group from a tenant.
+    //
+    // None of them carries a `runtimeAvailability` capability gate, and the omission is a decision
+    // rather than an oversight. The org-scope SSO/SCIM/SIEM/webhook destinations gate on
+    // `isFeatureOffered(CoreFeature.X)` because those are features a TENANT buys, and a tenant that
+    // cannot buy one should not see its configuration screen. An APPLICATION does not buy anything
+    // from itself: it either ships the capability or it does not, and if it does not, the destination
+    // is simply not placed. Gating the operator's own screens on the tenant entitlement catalogue
+    // would make an application's configuration depend on its own price list.
+    {
+        ref: EngineSettingsDestinationRef.APPLICATION_GENERAL,
+        requiredRoles: APPLICATION_ADMINISTRATION_ROLES,
+        // 1:1 with the application, so READ addresses it with no id segment.
+        target: {
+            kind: SettingsSectionTargetKind.RESOURCE_OPERATION,
+            resourceType: CoreResourceType.APPLICATION_METADATA,
+            operation: CoreResourceOperation.READ,
+        },
+    },
+    {
+        ref: EngineSettingsDestinationRef.APPLICATION_VERSIONS,
+        requiredRoles: APPLICATION_ADMINISTRATION_ROLES,
+        target: {
+            kind: SettingsSectionTargetKind.RESOURCE_OPERATION,
+            resourceType: CoreResourceType.APPLICATION_VERSIONS,
+            operation: CoreResourceOperation.LIST,
+        },
+    },
+    {
+        // The application-scope twin of ORGANIZATION_ENTITLEMENTS, and the pair is not a duplication:
+        // `M2M_WEBHOOK_DELIVERY` is declared `scopeBoundary: true`, so enabling it for the application
+        // does NOT enable it for any organization. An operator who cannot see both states cannot tell
+        // which of the two refused a delivery.
+        ref: EngineSettingsDestinationRef.APPLICATION_ENTITLEMENTS,
+        requiredRoles: APPLICATION_ADMINISTRATION_ROLES,
+        target: {
+            kind: SettingsSectionTargetKind.RESOURCE_OPERATION,
+            resourceType: CoreResourceType.APPLICATION_FEATURES,
+            operation: CoreResourceOperation.READ,
+        },
+    },
+    {
+        ref: EngineSettingsDestinationRef.APPLICATION_API_KEYS,
+        requiredRoles: APPLICATION_ADMINISTRATION_ROLES,
+        target: {
+            kind: SettingsSectionTargetKind.RESOURCE_OPERATION,
+            resourceType: CoreResourceType.APPLICATION_API_KEYS,
+            operation: CoreResourceOperation.LIST,
+        },
+    },
+    {
+        ref: EngineSettingsDestinationRef.APPLICATION_SSO,
+        requiredRoles: APPLICATION_ADMINISTRATION_ROLES,
+        // Two tabs mirroring the organization sibling: the singleton configuration, then the collection
+        // of connections. LIST rather than READ for the connections because the application variant's
+        // READ is an `INTERNAL_CALL` and has no route — only LIST is `API_CALL`.
+        target: {
+            kind: SettingsSectionTargetKind.SUB_TABS,
+            subTabs: [
+                {
+                    ref: 'application-sso-configuration',
+                    label: 'Configuration',
+                    target: {
+                        kind: SettingsSectionTargetKind.RESOURCE_OPERATION,
+                        resourceType: CoreResourceType.APPLICATION_SSO_CONFIG,
+                        operation: CoreResourceOperation.READ,
+                    },
+                },
+                {
+                    ref: 'application-sso-connections',
+                    label: 'Connections',
+                    target: {
+                        kind: SettingsSectionTargetKind.RESOURCE_OPERATION,
+                        resourceType: CoreResourceType.APPLICATION_SSO_CONNECTIONS,
+                        operation: CoreResourceOperation.LIST,
+                    },
+                },
+            ],
+        },
+    },
+    {
+        // ONE target where the organization sibling has two, because `APPLICATION_SCIM_TOKENS` does not
+        // exist — the token resource is organization-scoped only. A second tab here would have nothing
+        // to address.
+        ref: EngineSettingsDestinationRef.APPLICATION_SCIM,
+        requiredRoles: APPLICATION_ADMINISTRATION_ROLES,
+        target: {
+            kind: SettingsSectionTargetKind.RESOURCE_OPERATION,
+            resourceType: CoreResourceType.APPLICATION_SCIM_PROVISIONING_CONFIG,
+            operation: CoreResourceOperation.READ,
+        },
+    },
+    {
+        ref: EngineSettingsDestinationRef.APPLICATION_SIEM,
+        requiredRoles: APPLICATION_ADMINISTRATION_ROLES,
+        // LIST for the dead-letter queue: its READ is `REPOSITORY_ONLY` and therefore route-less, same
+        // as the organization sibling.
+        target: {
+            kind: SettingsSectionTargetKind.SUB_TABS,
+            subTabs: [
+                {
+                    ref: 'application-siem-export',
+                    label: 'Export',
+                    target: {
+                        kind: SettingsSectionTargetKind.RESOURCE_OPERATION,
+                        resourceType: CoreResourceType.APPLICATION_SIEM_EXPORT_CONFIG,
+                        operation: CoreResourceOperation.READ,
+                    },
+                },
+                {
+                    ref: 'application-siem-failed-deliveries',
+                    label: 'Failed deliveries',
+                    target: {
+                        kind: SettingsSectionTargetKind.RESOURCE_OPERATION,
+                        resourceType: CoreResourceType.APPLICATION_SIEM_DELIVERY_DLQ,
+                        operation: CoreResourceOperation.LIST,
+                    },
+                },
+            ],
+        },
+    },
+    {
+        ref: EngineSettingsDestinationRef.APPLICATION_WEBHOOKS,
+        requiredRoles: APPLICATION_ADMINISTRATION_ROLES,
+        target: {
+            kind: SettingsSectionTargetKind.SUB_TABS,
+            subTabs: [
+                {
+                    ref: 'application-webhooks-endpoints',
+                    label: 'Endpoints',
+                    target: {
+                        kind: SettingsSectionTargetKind.RESOURCE_OPERATION,
+                        resourceType: CoreResourceType.APPLICATION_WEBHOOK_CONFIG,
+                        operation: CoreResourceOperation.READ,
+                    },
+                },
+                {
+                    ref: 'application-webhooks-delivery-log',
+                    label: 'Delivery log',
+                    target: {
+                        kind: SettingsSectionTargetKind.RESOURCE_OPERATION,
+                        resourceType: CoreResourceType.APPLICATION_M2M_WEBHOOK_DELIVERY_LOG,
+                        operation: CoreResourceOperation.LIST,
+                    },
+                },
+            ],
+        },
+    },
+    {
+        /**
+         * What the application SELLS. Not to be merged with the organization `BILLING` destination,
+         * which is what one tenant BOUGHT — same domain, opposite side of the transaction, and only one
+         * of them is editable by the person looking at it.
+         *
+         * Tabs rather than separate destinations because a promotion is meaningless without the product
+         * it discounts: an operator pricing a plan moves between them continuously, and splitting them
+         * across the rail would make that a navigation task.
+         *
+         * ## There is no PRICES tab, and its removal is the point of this note
+         *
+         * One was placed here until 2026-09-18, targeting `PRICES.LIST`, and it could never load: a
+         * price is a COMPOSITION child of a product, so the only LIST route the engine generates for it
+         * is `/api/v1/products/{productId}/prices`. Measured against the running backend that day —
+         * `/api/v1/products` 200, `/api/v1/promotions` 200, `/api/v1/prices` **404** — and the pane
+         * rendered "We couldn't load the list" because the frontend could not build a URL for a tab
+         * the engine itself was placing at rail level.
+         *
+         * Making a bare `/prices` exist was tried and REJECTED on measurement, which is worth recording
+         * so it is not retried. Declaring the product edge `OPTIONAL_CONTEXT` changes nothing on its
+         * own, because `generateParentCombinations` drops the empty parent combination whenever any URL
+         * parent exists. Removing that guard DOES produce `/api/v1/prices` — and, in the same pass, 16
+         * tenant-free `organizationMembers` routes (`/api/v1/organization-members`,
+         * `/api/v1/organization-members/{id}`, …), because that resource's organization parent is also
+         * optional in its built configuration. The guard is load-bearing tenancy, not an oversight.
+         *
+         * So prices are reached where they live: the Products tab lists products, and a product's own
+         * record surfaces its prices as the composition child it is. That is one navigation step, and
+         * it is the step the domain already describes — this destination's original note said it
+         * itself, that "a price is meaningless without its product".
+         */
+        ref: EngineSettingsDestinationRef.BILLING_CATALOG,
+        requiredRoles: APPLICATION_ADMINISTRATION_ROLES,
+        runtimeAvailability: { requiredCapabilities: [BILLING_ENABLED_CAPABILITY] },
+        target: {
+            kind: SettingsSectionTargetKind.SUB_TABS,
+            subTabs: [
+                {
+                    ref: 'billing-catalog-products',
+                    label: 'Products',
+                    target: {
+                        kind: SettingsSectionTargetKind.RESOURCE_OPERATION,
+                        resourceType: CoreResourceType.PRODUCTS,
+                        operation: CoreResourceOperation.LIST,
+                    },
+                },
+                {
+                    ref: 'billing-catalog-promotions',
+                    label: 'Promotions',
+                    target: {
+                        kind: SettingsSectionTargetKind.RESOURCE_OPERATION,
+                        resourceType: CoreResourceType.PROMOTIONS,
+                        operation: CoreResourceOperation.LIST,
+                    },
+                },
+            ],
+        },
+    },
+    {
+        ref: EngineSettingsDestinationRef.APPLICATION_OAUTH_CLIENTS,
+        requiredRoles: APPLICATION_ADMINISTRATION_ROLES,
+        target: {
+            kind: SettingsSectionTargetKind.RESOURCE_OPERATION,
+            resourceType: CoreResourceType.OAUTH_CLIENTS_APPLICATION,
+            operation: CoreResourceOperation.LIST,
+        },
+    },
+    {
+        // The review queue for application-wide elevations. Role-gated like its neighbours and NOT
+        // additionally grant-gated, deliberately: reading which elevations exist is how the two-person
+        // rule is supervised, and putting the supervision behind the thing it supervises would mean an
+        // administrator needs an elevation to discover that elevations are being taken.
+        ref: EngineSettingsDestinationRef.APPLICATION_ACCESS_GRANTS,
+        requiredRoles: APPLICATION_ADMINISTRATION_ROLES,
+        target: {
+            kind: SettingsSectionTargetKind.RESOURCE_OPERATION,
+            resourceType: CoreResourceType.APPLICATION_ACCESS_GRANTS,
+            operation: CoreResourceOperation.LIST,
+        },
+    },
+    {
+        /**
+         * The application-wide trail.
+         *
+         * `requiredRoles` names BOTH roles the resource accepts, not just the super-administrator:
+         * `APP_AUDIT_EVIDENCE_READER` exists precisely so that reading the trail can be granted without
+         * granting anything else, and a rail that hid the section from that role would make the role
+         * unusable through the product — the holder would have the permission and no way to exercise it.
+         * This is the one Administration destination whose gate is deliberately wider than
+         * `APPLICATION_ADMINISTRATION_ROLES`.
+         */
+        ref: EngineSettingsDestinationRef.APPLICATION_AUDIT_LOGS,
+        requiredRoles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN, CORE_APP_ROLES.APP_AUDIT_EVIDENCE_READER],
+        target: {
+            kind: SettingsSectionTargetKind.RESOURCE_OPERATION,
+            resourceType: CoreResourceType.APPLICATION_AUDIT_LOGS,
+            operation: CoreResourceOperation.LIST,
+        },
+    },
+    // NO tenant-directory and NO user-directory destination here, deliberately — see the note under
+    // `EngineSettingsDestinationRef` for why neither is a placement problem. Both reads that look like
+    // they would serve one are confined or grant-gated ON PURPOSE, and placing them would advertise a
+    // population the section cannot actually show.
 ];
 /**
  * The full placement set `wildo init` scaffolds into a new application's config.
@@ -384,26 +720,69 @@ export const SCAFFOLD_SETTINGS_HUB_CONFIG = {
     categories: [
         { ref: 'account', label: 'Account', scope: ResourcePrimaryScope.USER_SELF, order: 0 },
         { ref: 'organization', label: 'Organization', scope: ResourcePrimaryScope.ORGANIZATIONS, order: 1 },
+        // The operator's own scope. Scaffolded like everything else so a new application starts
+        // complete: `APPLICATION` scope plus `APP_ADMIN_SUPER_ADMIN` on every destination means an
+        // ordinary member never sees the heading, and a category whose sections are all gated out is
+        // dropped rather than rendered empty — so placing it costs an application nothing and NOT
+        // placing it would hide the whole administration surface behind documentation.
+        { ref: 'administration', label: 'Administration', scope: ResourcePrimaryScope.APPLICATION, order: 2 },
     ],
     placements: [
+        /*
+         * A rail label NAMES the thing. It is not a friendlier word for it.
+         *
+         * Five of these were a gloss and every one of them cost a reader: "User provisioning" is SCIM,
+         * "Audit streaming" is SIEM, "Connected accounts" is integrations, "Single sign-on" is a choice
+         * between OIDC and SAML, and "Teams" is the organization-unit hierarchy. An administrator
+         * arrives at this rail having been told to "set up SCIM" or "point the SIEM at us", and none of
+         * those words was on the screen — so the item that answers the question is the one they scroll
+         * past. The gloss is also ambiguous in the direction that matters: "user provisioning" is what
+         * SSO just-in-time creation does as well, and "connected accounts" reads as the user's own
+         * social logins, which is a different pane in a different category.
+         *
+         * The protocol name is not jargon here. It is the term the vendor documentation, the IdP's own
+         * setup page and the person's ticket all use, and it is what they will search this rail for.
+         * Where a plain word IS the precise one — Members, Billing, Webhooks, API keys — it stays.
+         */
         { destinationRef: EngineSettingsDestinationRef.PROFILE, categoryRef: 'account', label: 'Profile', order: 0 },
         { destinationRef: EngineSettingsDestinationRef.SECURITY, categoryRef: 'account', label: 'Security', order: 1 },
         { destinationRef: EngineSettingsDestinationRef.APPEARANCE, categoryRef: 'account', label: 'Appearance', order: 2 },
         { destinationRef: EngineSettingsDestinationRef.PREFERENCES, categoryRef: 'account', label: 'Preferences', order: 3 },
         { destinationRef: EngineSettingsDestinationRef.MY_INVITATIONS, categoryRef: 'account', label: 'Invitations', order: 4 },
         // Same label as the organization placement below, deliberately: it is the same feature, and the
-        // CATEGORY is what says whose accounts these are.
-        { destinationRef: EngineSettingsDestinationRef.MY_PROVIDER_CREDENTIALS, categoryRef: 'account', label: 'Connected accounts', order: 5 },
+        // CATEGORY is what says whose integrations these are.
+        { destinationRef: EngineSettingsDestinationRef.MY_PROVIDER_CREDENTIALS, categoryRef: 'account', label: 'Integrations', order: 5 },
         { destinationRef: EngineSettingsDestinationRef.ORGANIZATION_GENERAL, categoryRef: 'organization', label: 'General', order: 0 },
         { destinationRef: EngineSettingsDestinationRef.MEMBERS, categoryRef: 'organization', label: 'Members', order: 1 },
-        { destinationRef: EngineSettingsDestinationRef.BILLING, categoryRef: 'organization', label: 'Billing', order: 3 },
-        { destinationRef: EngineSettingsDestinationRef.API_KEYS, categoryRef: 'organization', label: 'API keys', order: 4 },
-        { destinationRef: EngineSettingsDestinationRef.PROVIDER_CREDENTIALS, categoryRef: 'organization', label: 'Connected accounts', order: 5 },
-        { destinationRef: EngineSettingsDestinationRef.SSO, categoryRef: 'organization', label: 'Single sign-on', order: 6 },
-        { destinationRef: EngineSettingsDestinationRef.SCIM, categoryRef: 'organization', label: 'User provisioning', order: 7 },
-        { destinationRef: EngineSettingsDestinationRef.SIEM, categoryRef: 'organization', label: 'Audit streaming', order: 8 },
-        { destinationRef: EngineSettingsDestinationRef.WEBHOOKS, categoryRef: 'organization', label: 'Webhooks', order: 9 },
-        { destinationRef: EngineSettingsDestinationRef.AUDIT_LOGS, categoryRef: 'organization', label: 'Audit log', order: 10 },
+        // Beside Members, because the two are the same KIND of surface — who is in this tenant, and how
+        // it is arranged — and a reader looking for one is usually looking for the other.
+        { destinationRef: EngineSettingsDestinationRef.ORGANIZATION_UNITS, categoryRef: 'organization', label: 'Organization units', order: 2 },
+        { destinationRef: EngineSettingsDestinationRef.ORGANIZATION_ENTITLEMENTS, categoryRef: 'organization', label: 'Entitlements', order: 3 },
+        { destinationRef: EngineSettingsDestinationRef.BILLING, categoryRef: 'organization', label: 'Billing', order: 4 },
+        { destinationRef: EngineSettingsDestinationRef.ORGANIZATION_REFERRALS, categoryRef: 'organization', label: 'Referrals', order: 5 },
+        { destinationRef: EngineSettingsDestinationRef.API_KEYS, categoryRef: 'organization', label: 'API keys', order: 6 },
+        { destinationRef: EngineSettingsDestinationRef.PROVIDER_CREDENTIALS, categoryRef: 'organization', label: 'Integrations', order: 7 },
+        { destinationRef: EngineSettingsDestinationRef.SSO, categoryRef: 'organization', label: 'SSO — OIDC / SAML', order: 8 },
+        { destinationRef: EngineSettingsDestinationRef.SCIM, categoryRef: 'organization', label: 'SCIM provisioning', order: 9 },
+        { destinationRef: EngineSettingsDestinationRef.SIEM, categoryRef: 'organization', label: 'SIEM export', order: 10 },
+        { destinationRef: EngineSettingsDestinationRef.WEBHOOKS, categoryRef: 'organization', label: 'Webhooks', order: 11 },
+        { destinationRef: EngineSettingsDestinationRef.AUDIT_LOGS, categoryRef: 'organization', label: 'Audit log', order: 12 },
+        // Administration mirrors the organization order — General, the population, entitlements and
+        // commerce, then the integration surfaces in the same sequence — so an operator who has learned
+        // one rail has learned the other, and the scope distinction reads as a scope distinction rather
+        // than as two unrelated menus.
+        { destinationRef: EngineSettingsDestinationRef.APPLICATION_GENERAL, categoryRef: 'administration', label: 'General', order: 0 },
+        { destinationRef: EngineSettingsDestinationRef.APPLICATION_ENTITLEMENTS, categoryRef: 'administration', label: 'Entitlements', order: 1 },
+        { destinationRef: EngineSettingsDestinationRef.BILLING_CATALOG, categoryRef: 'administration', label: 'Plans & pricing', order: 2 },
+        { destinationRef: EngineSettingsDestinationRef.APPLICATION_API_KEYS, categoryRef: 'administration', label: 'API keys', order: 3 },
+        { destinationRef: EngineSettingsDestinationRef.APPLICATION_OAUTH_CLIENTS, categoryRef: 'administration', label: 'OAuth clients', order: 4 },
+        { destinationRef: EngineSettingsDestinationRef.APPLICATION_SSO, categoryRef: 'administration', label: 'SSO — OIDC / SAML', order: 5 },
+        { destinationRef: EngineSettingsDestinationRef.APPLICATION_SCIM, categoryRef: 'administration', label: 'SCIM provisioning', order: 6 },
+        { destinationRef: EngineSettingsDestinationRef.APPLICATION_SIEM, categoryRef: 'administration', label: 'SIEM export', order: 7 },
+        { destinationRef: EngineSettingsDestinationRef.APPLICATION_WEBHOOKS, categoryRef: 'administration', label: 'Webhooks', order: 8 },
+        { destinationRef: EngineSettingsDestinationRef.APPLICATION_AUDIT_LOGS, categoryRef: 'administration', label: 'Audit log', order: 9 },
+        { destinationRef: EngineSettingsDestinationRef.APPLICATION_ACCESS_GRANTS, categoryRef: 'administration', label: 'Access grants', order: 10 },
+        { destinationRef: EngineSettingsDestinationRef.APPLICATION_VERSIONS, categoryRef: 'administration', label: 'Versions', order: 11 },
     ],
     defaultSectionRef: 'profile',
 };