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

package/dist/esm/core/config/onboarding-view.frontend.schemas.js

@@ -2,31 +2,26 @@ import { z } from 'zod';
 import { OnboardingTriggerSchema, OnboardingViewOptionsSchema, OnboardingElementSchema, RequiredFeaturesConfigSchema, } from '@wildo-ai/saas-models';
 import { FrontendView_DefinitionSchema } from './views-frontend.schemas.js';
 /**
- * OnboardingViewDefinition — intersects onboarding primitives (saas-models)
- * with view wiring (FrontendView_DefinitionSchema) for frontend rendering.
+ * @wildo_source:part:start saas.frontend.onboarding-view facet:layer:frontend facet:family:guidance facet:audience:app-developer
  *
- * The onboarding primitives (triggers, elements, options) are shared because
- * the backend guidance system inspects them. The view definition wrapper
- * (scope, parent requirements) is frontend-only.
+ * An onboarding DOCUMENT — guidance that is EMBEDDED in a screen rather than triggered: a welcome
+ * announcement at the top of a dashboard, a getting-started stepper in a column. It is there
+ * whenever that screen is there.
+ *
+ * Declare documents on a frontend module's `onboardingViews` and place one with
+ * `<EmbedOnboarding document={…} />`. Import the type from `@wildo-ai/saas-frontend-lib/companion`.
+ * LISTING it on the module is what makes it remember, per person, whether they dismissed, skipped or
+ * finished it — its `ref` is the saved identity. A document embedded without being listed works but
+ * forgets on every visit, and logs a console warning saying so.
+ *
+ * Its elements render ONE AT A TIME as a stepper ("Step 2 of 4", Back / Skip / Next). For guidance
+ * that appears in response to something the person just did, use a guidance flow instead.
  */
 export const OnboardingViewDefinitionSchema = z.intersection(FrontendView_DefinitionSchema, z.object({
     /**
-     * Stable string identity for this onboarding view. Used by:
-     * - The companion spec layer (`OnboardingViewSpecification` keys
-     *   this ref against `app.<ref>` for application-scope views and
-     *   `resources.<resourceType>.<ref>` for resource-scope views).
-     * - Future ref-based registry lookups (today the runtime accesses
-     *   onboarding documents by direct array reference via
-     *   `<EmbedOnboarding document={…} />`, but per-ref lookup is the
-     *   coming convention — guidance flows already work this way).
-     *
-     * NOTE on uniqueness: `buildFrontendModuleRegistry` collapses
-     * onboarding views to ref-keyed dedup (mirrors guidance-flow
-     * merge). Two modules contributing the same ref therefore overwrite,
-     * with the last-merged module winning — same semantics as
-     * guidance flows. Spec-layer
-     * `buildOnboardingViewSpecificationMap` ALSO fails closed on
-     * duplicate keys for any app that authors the spec.
+     * Stable identity for this document — it keys the person's saved state (dismissed, completed)
+     * and the document's labels. Keep it stable: renaming it forgets everyone's progress. Unique
+     * across the application; two modules declaring the same ref overwrite each other.
      */
     ref: z.string().min(1),
     trigger: OnboardingTriggerSchema.optional(),
@@ -34,4 +29,5 @@ export const OnboardingViewDefinitionSchema = z.intersection(FrontendView_Defini
     elements: z.array(OnboardingElementSchema),
     requiredFeatures: RequiredFeaturesConfigSchema.optional(),
 }));
+/** @wildo_source:part:end saas.frontend.onboarding-view */
 //# sourceMappingURL=onboarding-view.frontend.schemas.js.map

package/dist/esm/core/config/onboarding-view.frontend.schemas.js.map

@@ -1 +1 @@
-{"version":3,"file":"onboarding-view.frontend.schemas.js","sourceRoot":"","sources":["../../../../src/core/config/onboarding-view.frontend.schemas.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AACxB,OAAO,EACL,uBAAuB,EACvB,2BAA2B,EAC3B,uBAAuB,EACvB,4BAA4B,GAC7B,MAAM,uBAAuB,CAAC;AAO/B,OAAO,EAAE,6BAA6B,EAA0B,MAAM,0BAA0B,CAAC;AAGjG;;;;;;;GAOG;AACH,MAAM,CAAC,MAAM,8BAA8B,GAAG,CAAC,CAAC,YAAY,CAC1D,6BAA6B,EAC7B,CAAC,CAAC,MAAM,CAAC;IACP;;;;;;;;;;;;;;;;;OAiBG;IACH,GAAG,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC;IACtB,OAAO,EAAE,uBAAuB,CAAC,QAAQ,EAAE;IAC3C,OAAO,EAAE,2BAA2B;IACpC,QAAQ,EAAE,CAAC,CAAC,KAAK,CAAC,uBAAuB,CAAC;IAC1C,gBAAgB,EAAE,4BAA4B,CAAC,QAAQ,EAAE;CAC1D,CAAC,CACH,CAAC","sourcesContent":["import { z } from 'zod';\nimport {\n  OnboardingTriggerSchema,\n  OnboardingViewOptionsSchema,\n  OnboardingElementSchema,\n  RequiredFeaturesConfigSchema,\n} from '@wildo-ai/saas-models';\nimport type {\n  OnboardingTrigger,\n  OnboardingViewOptions,\n  OnboardingElement,\n  RequiredFeaturesConfig,\n} from '@wildo-ai/saas-models';\nimport { FrontendView_DefinitionSchema, FrontendView_ScopeMode } from './views-frontend.schemas';\nimport type { FrontendResource_ParentResourceRequirement } from '~wildo-frontend-lib/core/resources/resource-path.frontend.schemas';\n\n/**\n * OnboardingViewDefinition — intersects onboarding primitives (saas-models)\n * with view wiring (FrontendView_DefinitionSchema) for frontend rendering.\n *\n * The onboarding primitives (triggers, elements, options) are shared because\n * the backend guidance system inspects them. The view definition wrapper\n * (scope, parent requirements) is frontend-only.\n */\nexport const OnboardingViewDefinitionSchema = z.intersection(\n  FrontendView_DefinitionSchema,\n  z.object({\n    /**\n     * Stable string identity for this onboarding view. Used by:\n     * - The companion spec layer (`OnboardingViewSpecification` keys\n     *   this ref against `app.<ref>` for application-scope views and\n     *   `resources.<resourceType>.<ref>` for resource-scope views).\n     * - Future ref-based registry lookups (today the runtime accesses\n     *   onboarding documents by direct array reference via\n     *   `<EmbedOnboarding document={…} />`, but per-ref lookup is the\n     *   coming convention — guidance flows already work this way).\n     *\n     * NOTE on uniqueness: `buildFrontendModuleRegistry` collapses\n     * onboarding views to ref-keyed dedup (mirrors guidance-flow\n     * merge). Two modules contributing the same ref therefore overwrite,\n     * with the last-merged module winning — same semantics as\n     * guidance flows. Spec-layer\n     * `buildOnboardingViewSpecificationMap` ALSO fails closed on\n     * duplicate keys for any app that authors the spec.\n     */\n    ref: z.string().min(1),\n    trigger: OnboardingTriggerSchema.optional(),\n    options: OnboardingViewOptionsSchema,\n    elements: z.array(OnboardingElementSchema),\n    requiredFeatures: RequiredFeaturesConfigSchema.optional(),\n  }),\n);\n\nexport interface OnboardingViewDefinition {\n  ref: string;\n  scope: FrontendView_ScopeMode;\n  parentResourcesRequirements?: FrontendResource_ParentResourceRequirement[];\n  additionalResourceRequirements?: FrontendResource_ParentResourceRequirement[];\n  trigger?: OnboardingTrigger;\n  options: OnboardingViewOptions;\n  elements: OnboardingElement[];\n  requiredFeatures?: RequiredFeaturesConfig;\n}\n"]}
+{"version":3,"file":"onboarding-view.frontend.schemas.js","sourceRoot":"","sources":["../../../../../src/core/config/onboarding-view.frontend.schemas.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AACxB,OAAO,EACL,uBAAuB,EACvB,2BAA2B,EAC3B,uBAAuB,EACvB,4BAA4B,GAC7B,MAAM,uBAAuB,CAAC;AAO/B,OAAO,EAAE,6BAA6B,EAA0B,MAAM,0BAA0B,CAAC;AAGjG;;;;;;;;;;;;;;;GAeG;AACH,MAAM,CAAC,MAAM,8BAA8B,GAAG,CAAC,CAAC,YAAY,CAC1D,6BAA6B,EAC7B,CAAC,CAAC,MAAM,CAAC;IACP;;;;OAIG;IACH,GAAG,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC;IACtB,OAAO,EAAE,uBAAuB,CAAC,QAAQ,EAAE;IAC3C,OAAO,EAAE,2BAA2B;IACpC,QAAQ,EAAE,CAAC,CAAC,KAAK,CAAC,uBAAuB,CAAC;IAC1C,gBAAgB,EAAE,4BAA4B,CAAC,QAAQ,EAAE;CAC1D,CAAC,CACH,CAAC;AAYF,2DAA2D","sourcesContent":["import { z } from 'zod';\nimport {\n  OnboardingTriggerSchema,\n  OnboardingViewOptionsSchema,\n  OnboardingElementSchema,\n  RequiredFeaturesConfigSchema,\n} from '@wildo-ai/saas-models';\nimport type {\n  OnboardingTrigger,\n  OnboardingViewOptions,\n  OnboardingElement,\n  RequiredFeaturesConfig,\n} from '@wildo-ai/saas-models';\nimport { FrontendView_DefinitionSchema, FrontendView_ScopeMode } from './views-frontend.schemas';\nimport type { FrontendResource_ParentResourceRequirement } from '~wildo-frontend-lib/core/resources/resource-path.frontend.schemas';\n\n/**\n * @wildo_source:part:start saas.frontend.onboarding-view facet:layer:frontend facet:family:guidance facet:audience:app-developer\n *\n * An onboarding DOCUMENT — guidance that is EMBEDDED in a screen rather than triggered: a welcome\n * announcement at the top of a dashboard, a getting-started stepper in a column. It is there\n * whenever that screen is there.\n *\n * Declare documents on a frontend module's `onboardingViews` and place one with\n * `<EmbedOnboarding document={…} />`. Import the type from `@wildo-ai/saas-frontend-lib/companion`.\n * LISTING it on the module is what makes it remember, per person, whether they dismissed, skipped or\n * finished it — its `ref` is the saved identity. A document embedded without being listed works but\n * forgets on every visit, and logs a console warning saying so.\n *\n * Its elements render ONE AT A TIME as a stepper (\"Step 2 of 4\", Back / Skip / Next). For guidance\n * that appears in response to something the person just did, use a guidance flow instead.\n */\nexport const OnboardingViewDefinitionSchema = z.intersection(\n  FrontendView_DefinitionSchema,\n  z.object({\n    /**\n     * Stable identity for this document — it keys the person's saved state (dismissed, completed)\n     * and the document's labels. Keep it stable: renaming it forgets everyone's progress. Unique\n     * across the application; two modules declaring the same ref overwrite each other.\n     */\n    ref: z.string().min(1),\n    trigger: OnboardingTriggerSchema.optional(),\n    options: OnboardingViewOptionsSchema,\n    elements: z.array(OnboardingElementSchema),\n    requiredFeatures: RequiredFeaturesConfigSchema.optional(),\n  }),\n);\n\nexport interface OnboardingViewDefinition {\n  ref: string;\n  scope: FrontendView_ScopeMode;\n  parentResourcesRequirements?: FrontendResource_ParentResourceRequirement[];\n  additionalResourceRequirements?: FrontendResource_ParentResourceRequirement[];\n  trigger?: OnboardingTrigger;\n  options: OnboardingViewOptions;\n  elements: OnboardingElement[];\n  requiredFeatures?: RequiredFeaturesConfig;\n}\n/** @wildo_source:part:end saas.frontend.onboarding-view */\n"]}

package/dist/esm/core/config/resource-owned-view-resolution.frontend.utils.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"resource-owned-view-resolution.frontend.utils.d.ts","sourceRoot":"","sources":["../../../../src/core/config/resource-owned-view-resolution.frontend.utils.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,sBAAsB,EAAE,MAAM,0BAA0B,CAAC;AAClE,OAAO,KAAK,EAAE,yBAAyB,EAAE,MAAM,+DAA+D,CAAC;AAE/G,MAAM,MAAM,uBAAuB,GAAG,WAAW,GAAG,OAAO,GAAG,WAAW,CAAC;AAE1E,MAAM,WAAW,iCAAiC;IAChD,MAAM,EAAE,uBAAuB,CAAC;IAChC,KAAK,EAAE,sBAAsB,CAAC;CAC/B;AAED,MAAM,WAAW,+BAAgC,SAAQ,iCAAiC;IACxF,OAAO,EAAE,MAAM,CAAC;CACjB;AAED,wBAAgB,+BAA+B,CAAC,MAAM,EAAE;IACtD,YAAY,EAAE,MAAM,CAAC;IACrB,QAAQ,EAAE,yBAAyB,CAAC;CACrC,GAAG,+BAA+B,EAAE,CAoBpC;AAED,wBAAgB,qCAAqC,CAAC,MAAM,EAAE;IAC5D,YAAY,EAAE,MAAM,CAAC;IACrB,OAAO,EAAE,MAAM,CAAC;IAChB,QAAQ,EAAE,yBAAyB,CAAC;CACrC,GAAG,+BAA+B,EAAE,CAKpC;AAED,wBAAgB,iCAAiC,CAAC,MAAM,EAAE;IACxD,YAAY,EAAE,MAAM,CAAC;IACrB,OAAO,EAAE,MAAM,CAAC;IAChB,QAAQ,EAAE,yBAAyB,CAAC;CACrC,GAAG,iCAAiC,GAAG,IAAI,CAU3C"}
+{"version":3,"file":"resource-owned-view-resolution.frontend.utils.d.ts","sourceRoot":"","sources":["../../../../../src/core/config/resource-owned-view-resolution.frontend.utils.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,sBAAsB,EAAE,MAAM,0BAA0B,CAAC;AAClE,OAAO,KAAK,EAAE,yBAAyB,EAAE,MAAM,+DAA+D,CAAC;AAE/G,MAAM,MAAM,uBAAuB,GAAG,WAAW,GAAG,OAAO,GAAG,WAAW,CAAC;AAE1E,MAAM,WAAW,iCAAiC;IAChD,MAAM,EAAE,uBAAuB,CAAC;IAChC,KAAK,EAAE,sBAAsB,CAAC;CAC/B;AAED,MAAM,WAAW,+BAAgC,SAAQ,iCAAiC;IACxF,OAAO,EAAE,MAAM,CAAC;CACjB;AAED,wBAAgB,+BAA+B,CAAC,MAAM,EAAE;IACtD,YAAY,EAAE,MAAM,CAAC;IACrB,QAAQ,EAAE,yBAAyB,CAAC;CACrC,GAAG,+BAA+B,EAAE,CAoBpC;AAED,wBAAgB,qCAAqC,CAAC,MAAM,EAAE;IAC5D,YAAY,EAAE,MAAM,CAAC;IACrB,OAAO,EAAE,MAAM,CAAC;IAChB,QAAQ,EAAE,yBAAyB,CAAC;CACrC,GAAG,+BAA+B,EAAE,CAKpC;AAED,wBAAgB,iCAAiC,CAAC,MAAM,EAAE;IACxD,YAAY,EAAE,MAAM,CAAC;IACrB,OAAO,EAAE,MAAM,CAAC;IAChB,QAAQ,EAAE,yBAAyB,CAAC;CACrC,GAAG,iCAAiC,GAAG,IAAI,CAU3C"}

package/dist/esm/core/config/resource-owned-view-resolution.frontend.utils.js.map

@@ -1 +1 @@
-{"version":3,"file":"resource-owned-view-resolution.frontend.utils.js","sourceRoot":"","sources":["../../../../src/core/config/resource-owned-view-resolution.frontend.utils.ts"],"names":[],"mappings":"AAcA,MAAM,UAAU,+BAA+B,CAAC,MAG/C;IACC,MAAM,qBAAqB,GAAG,MAAM,CAAC,QAAQ,CAAC,sBAAsB,CAAC,MAAM,CAAC,YAAY,CAAC,EAAE,qBAAqB,CAAC;IAEjH,OAAO;QACL,GAAG,CAAC,qBAAqB,EAAE,cAAc,IAAI,EAAE,CAAC,CAAC,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,CAAC;YAC9D,OAAO,EAAE,IAAI,CAAC,GAAG;YACjB,MAAM,EAAE,WAAoB;YAC5B,KAAK,EAAE,IAAI,CAAC,KAAK;SAClB,CAAC,CAAC;QACH,GAAG,CAAC,qBAAqB,EAAE,UAAU,IAAI,EAAE,CAAC,CAAC,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,CAAC;YAC1D,OAAO,EAAE,IAAI,CAAC,GAAG;YACjB,MAAM,EAAE,OAAgB;YACxB,KAAK,EAAE,IAAI,CAAC,KAAK;SAClB,CAAC,CAAC;QACH,GAAG,CAAC,qBAAqB,EAAE,cAAc,IAAI,EAAE,CAAC,CAAC,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,CAAC;YAC9D,OAAO,EAAE,IAAI,CAAC,GAAG;YACjB,MAAM,EAAE,WAAoB;YAC5B,KAAK,EAAE,IAAI,CAAC,KAAK;SAClB,CAAC,CAAC;KACJ,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,qCAAqC,CAAC,MAIrD;IACC,OAAO,+BAA+B,CAAC;QACrC,YAAY,EAAE,MAAM,CAAC,YAAY;QACjC,QAAQ,EAAE,MAAM,CAAC,QAAQ;KAC1B,CAAC,CAAC,MAAM,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,IAAI,CAAC,OAAO,KAAK,MAAM,CAAC,OAAO,CAAC,CAAC;AACvD,CAAC;AAED,MAAM,UAAU,iCAAiC,CAAC,MAIjD;IACC,MAAM,OAAO,GAAG,qCAAqC,CAAC,MAAM,CAAC,CAAC;IAC9D,IAAI,OAAO,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;QACzB,OAAO,IAAI,CAAC;IACd,CAAC;IAED,OAAO;QACL,MAAM,EAAE,OAAO,CAAC,CAAC,CAAC,CAAC,MAAM;QACzB,KAAK,EAAE,OAAO,CAAC,CAAC,CAAC,CAAC,KAAK;KACxB,CAAC;AACJ,CAAC","sourcesContent":["import { FrontendView_ScopeMode } from './views-frontend.schemas';\nimport type { FrontendResourcesRegistry } from '~wildo-frontend-lib/core/resources/resources.frontend.schemas';\n\nexport type ResourceOwnedViewFamily = 'composite' | 'chart' | 'execution';\n\nexport interface ResourceOwnedViewResolutionResult {\n  family: ResourceOwnedViewFamily;\n  scope: FrontendView_ScopeMode;\n}\n\nexport interface ResourceOwnedViewReferenceMatch extends ResourceOwnedViewResolutionResult {\n  viewRef: string;\n}\n\nexport function listResourceOwnedViewReferences(params: {\n  resourceType: string;\n  registry: FrontendResourcesRegistry;\n}): ResourceOwnedViewReferenceMatch[] {\n  const frontendConfiguration = params.registry.resourceConfigurations[params.resourceType]?.frontendConfiguration;\n\n  return [\n    ...(frontendConfiguration?.compositeViews ?? []).map((view) => ({\n      viewRef: view.ref,\n      family: 'composite' as const,\n      scope: view.scope,\n    })),\n    ...(frontendConfiguration?.chartViews ?? []).map((view) => ({\n      viewRef: view.ref,\n      family: 'chart' as const,\n      scope: view.scope,\n    })),\n    ...(frontendConfiguration?.executionViews ?? []).map((view) => ({\n      viewRef: view.ref,\n      family: 'execution' as const,\n      scope: view.scope,\n    })),\n  ];\n}\n\nexport function findResourceOwnedViewReferenceMatches(params: {\n  resourceType: string;\n  viewRef: string;\n  registry: FrontendResourcesRegistry;\n}): ResourceOwnedViewReferenceMatch[] {\n  return listResourceOwnedViewReferences({\n    resourceType: params.resourceType,\n    registry: params.registry,\n  }).filter((view) => view.viewRef === params.viewRef);\n}\n\nexport function resolveResourceOwnedViewReference(params: {\n  resourceType: string;\n  viewRef: string;\n  registry: FrontendResourcesRegistry;\n}): ResourceOwnedViewResolutionResult | null {\n  const matches = findResourceOwnedViewReferenceMatches(params);\n  if (matches.length !== 1) {\n    return null;\n  }\n\n  return {\n    family: matches[0].family,\n    scope: matches[0].scope,\n  };\n}\n"]}
+{"version":3,"file":"resource-owned-view-resolution.frontend.utils.js","sourceRoot":"","sources":["../../../../../src/core/config/resource-owned-view-resolution.frontend.utils.ts"],"names":[],"mappings":"AAcA,MAAM,UAAU,+BAA+B,CAAC,MAG/C;IACC,MAAM,qBAAqB,GAAG,MAAM,CAAC,QAAQ,CAAC,sBAAsB,CAAC,MAAM,CAAC,YAAY,CAAC,EAAE,qBAAqB,CAAC;IAEjH,OAAO;QACL,GAAG,CAAC,qBAAqB,EAAE,cAAc,IAAI,EAAE,CAAC,CAAC,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,CAAC;YAC9D,OAAO,EAAE,IAAI,CAAC,GAAG;YACjB,MAAM,EAAE,WAAoB;YAC5B,KAAK,EAAE,IAAI,CAAC,KAAK;SAClB,CAAC,CAAC;QACH,GAAG,CAAC,qBAAqB,EAAE,UAAU,IAAI,EAAE,CAAC,CAAC,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,CAAC;YAC1D,OAAO,EAAE,IAAI,CAAC,GAAG;YACjB,MAAM,EAAE,OAAgB;YACxB,KAAK,EAAE,IAAI,CAAC,KAAK;SAClB,CAAC,CAAC;QACH,GAAG,CAAC,qBAAqB,EAAE,cAAc,IAAI,EAAE,CAAC,CAAC,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,CAAC;YAC9D,OAAO,EAAE,IAAI,CAAC,GAAG;YACjB,MAAM,EAAE,WAAoB;YAC5B,KAAK,EAAE,IAAI,CAAC,KAAK;SAClB,CAAC,CAAC;KACJ,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,qCAAqC,CAAC,MAIrD;IACC,OAAO,+BAA+B,CAAC;QACrC,YAAY,EAAE,MAAM,CAAC,YAAY;QACjC,QAAQ,EAAE,MAAM,CAAC,QAAQ;KAC1B,CAAC,CAAC,MAAM,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,IAAI,CAAC,OAAO,KAAK,MAAM,CAAC,OAAO,CAAC,CAAC;AACvD,CAAC;AAED,MAAM,UAAU,iCAAiC,CAAC,MAIjD;IACC,MAAM,OAAO,GAAG,qCAAqC,CAAC,MAAM,CAAC,CAAC;IAC9D,IAAI,OAAO,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;QACzB,OAAO,IAAI,CAAC;IACd,CAAC;IAED,OAAO;QACL,MAAM,EAAE,OAAO,CAAC,CAAC,CAAC,CAAC,MAAM;QACzB,KAAK,EAAE,OAAO,CAAC,CAAC,CAAC,CAAC,KAAK;KACxB,CAAC;AACJ,CAAC","sourcesContent":["import { FrontendView_ScopeMode } from './views-frontend.schemas';\nimport type { FrontendResourcesRegistry } from '~wildo-frontend-lib/core/resources/resources.frontend.schemas';\n\nexport type ResourceOwnedViewFamily = 'composite' | 'chart' | 'execution';\n\nexport interface ResourceOwnedViewResolutionResult {\n  family: ResourceOwnedViewFamily;\n  scope: FrontendView_ScopeMode;\n}\n\nexport interface ResourceOwnedViewReferenceMatch extends ResourceOwnedViewResolutionResult {\n  viewRef: string;\n}\n\nexport function listResourceOwnedViewReferences(params: {\n  resourceType: string;\n  registry: FrontendResourcesRegistry;\n}): ResourceOwnedViewReferenceMatch[] {\n  const frontendConfiguration = params.registry.resourceConfigurations[params.resourceType]?.frontendConfiguration;\n\n  return [\n    ...(frontendConfiguration?.compositeViews ?? []).map((view) => ({\n      viewRef: view.ref,\n      family: 'composite' as const,\n      scope: view.scope,\n    })),\n    ...(frontendConfiguration?.chartViews ?? []).map((view) => ({\n      viewRef: view.ref,\n      family: 'chart' as const,\n      scope: view.scope,\n    })),\n    ...(frontendConfiguration?.executionViews ?? []).map((view) => ({\n      viewRef: view.ref,\n      family: 'execution' as const,\n      scope: view.scope,\n    })),\n  ];\n}\n\nexport function findResourceOwnedViewReferenceMatches(params: {\n  resourceType: string;\n  viewRef: string;\n  registry: FrontendResourcesRegistry;\n}): ResourceOwnedViewReferenceMatch[] {\n  return listResourceOwnedViewReferences({\n    resourceType: params.resourceType,\n    registry: params.registry,\n  }).filter((view) => view.viewRef === params.viewRef);\n}\n\nexport function resolveResourceOwnedViewReference(params: {\n  resourceType: string;\n  viewRef: string;\n  registry: FrontendResourcesRegistry;\n}): ResourceOwnedViewResolutionResult | null {\n  const matches = findResourceOwnedViewReferenceMatches(params);\n  if (matches.length !== 1) {\n    return null;\n  }\n\n  return {\n    family: matches[0].family,\n    scope: matches[0].scope,\n  };\n}\n"]}

package/dist/esm/core/config/settings-hub-gating.frontend.utils.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"settings-hub-gating.frontend.utils.d.ts","sourceRoot":"","sources":["../../../../src/core/config/settings-hub-gating.frontend.utils.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;GA0BG;AAEH,OAAO,EAAE,oBAAoB,EAAE,MAAM,uBAAuB,CAAC;AAC7D,OAAO,KAAK,EAAE,sBAAsB,EAAE,MAAM,uBAAuB,CAAC;AACpE,OAAO,EAEL,KAAK,kCAAkC,EACxC,MAAM,mEAAmE,CAAC;AAC3E,OAAO,KAAK,EACV,yBAAyB,EAG1B,MAAM,iCAAiC,CAAC;AAEzC,qFAAqF;AACrF,MAAM,WAAW,gBAAgB;IAC/B,aAAa,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;IAC9B,qBAAqB,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;IACtC,oBAAoB,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;IACrC,sBAAsB,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;CACxC;AAED,qEAAqE;AACrE,MAAM,WAAW,wBAAwB;IACvC,QAAQ,EAAE,gBAAgB,CAAC;IAC3B,6EAA6E;IAC7E,SAAS,EAAE,MAAM,EAAE,CAAC;IACpB,8DAA8D;IAC9D,eAAe,EAAE,MAAM,EAAE,CAAC;IAC1B,4EAA4E;IAC5E,cAAc,EAAE,kCAAkC,CAAC;CACpD;AAED;;;GAGG;AACH,wBAAgB,wBAAwB,CACtC,KAAK,EAAE,oBAAoB,GAAG,SAAS,EACvC,QAAQ,EAAE,gBAAgB,GACzB,OAAO,CAaT;AAED;;;;GAIG;AACH,wBAAgB,wBAAwB,CACtC,aAAa,EAAE,MAAM,EAAE,GAAG,SAAS,EACnC,SAAS,EAAE,MAAM,EAAE,GAClB,OAAO,CAGT;AAED;;;;GAIG;AACH,wBAAgB,4BAA4B,CAC1C,gBAAgB,EAAE,sBAAsB,GAAG,SAAS,EACpD,eAAe,EAAE,MAAM,EAAE,GACxB,OAAO,CAYT;AAWD;;;;;;;GAOG;AACH,wBAAgB,uBAAuB,CACrC,MAAM,EAAE,yBAAyB,EACjC,MAAM,EAAE,wBAAwB,GAC/B,yBAAyB,CA0B3B"}
+{"version":3,"file":"settings-hub-gating.frontend.utils.d.ts","sourceRoot":"","sources":["../../../../../src/core/config/settings-hub-gating.frontend.utils.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;GA0BG;AAEH,OAAO,EAAE,oBAAoB,EAAE,MAAM,uBAAuB,CAAC;AAC7D,OAAO,KAAK,EAAE,sBAAsB,EAAE,MAAM,uBAAuB,CAAC;AACpE,OAAO,EAEL,KAAK,kCAAkC,EACxC,MAAM,mEAAmE,CAAC;AAC3E,OAAO,KAAK,EACV,yBAAyB,EAG1B,MAAM,iCAAiC,CAAC;AAEzC,qFAAqF;AACrF,MAAM,WAAW,gBAAgB;IAC/B,aAAa,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;IAC9B,qBAAqB,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;IACtC,oBAAoB,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;IACrC,sBAAsB,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;CACxC;AAED,qEAAqE;AACrE,MAAM,WAAW,wBAAwB;IACvC,QAAQ,EAAE,gBAAgB,CAAC;IAC3B,6EAA6E;IAC7E,SAAS,EAAE,MAAM,EAAE,CAAC;IACpB,8DAA8D;IAC9D,eAAe,EAAE,MAAM,EAAE,CAAC;IAC1B,4EAA4E;IAC5E,cAAc,EAAE,kCAAkC,CAAC;CACpD;AAED;;;GAGG;AACH,wBAAgB,wBAAwB,CACtC,KAAK,EAAE,oBAAoB,GAAG,SAAS,EACvC,QAAQ,EAAE,gBAAgB,GACzB,OAAO,CAaT;AAED;;;;GAIG;AACH,wBAAgB,wBAAwB,CACtC,aAAa,EAAE,MAAM,EAAE,GAAG,SAAS,EACnC,SAAS,EAAE,MAAM,EAAE,GAClB,OAAO,CAGT;AAED;;;;GAIG;AACH,wBAAgB,4BAA4B,CAC1C,gBAAgB,EAAE,sBAAsB,GAAG,SAAS,EACpD,eAAe,EAAE,MAAM,EAAE,GACxB,OAAO,CAYT;AAWD;;;;;;;GAOG;AACH,wBAAgB,uBAAuB,CACrC,MAAM,EAAE,yBAAyB,EACjC,MAAM,EAAE,wBAAwB,GAC/B,yBAAyB,CA0B3B"}

package/dist/esm/core/config/settings-hub-gating.frontend.utils.js.map

@@ -1 +1 @@
-{"version":3,"file":"settings-hub-gating.frontend.utils.js","sourceRoot":"","sources":["../../../../src/core/config/settings-hub-gating.frontend.utils.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;GA0BG;AAEH,OAAO,EAAE,oBAAoB,EAAE,MAAM,uBAAuB,CAAC;AAE7D,OAAO,EACL,sCAAsC,GAEvC,MAAM,mEAAmE,CAAC;AA0B3E;;;GAGG;AACH,MAAM,UAAU,wBAAwB,CACtC,KAAuC,EACvC,QAA0B;IAE1B,QAAQ,KAAK,EAAE,CAAC;QACd,KAAK,SAAS;YACZ,OAAO,IAAI,CAAC;QACd,KAAK,oBAAoB,CAAC,SAAS;YACjC,OAAO,OAAO,CAAC,QAAQ,CAAC,aAAa,CAAC,CAAC;QACzC,KAAK,oBAAoB,CAAC,aAAa;YACrC,OAAO,OAAO,CAAC,QAAQ,CAAC,qBAAqB,CAAC,CAAC;QACjD,KAAK,oBAAoB,CAAC,WAAW;YACnC,OAAO,OAAO,CAAC,QAAQ,CAAC,oBAAoB,CAAC,CAAC;QAChD,KAAK,oBAAoB,CAAC,SAAS;YACjC,OAAO,OAAO,CAAC,QAAQ,CAAC,sBAAsB,CAAC,CAAC;IACpD,CAAC;AACH,CAAC;AAED;;;;GAIG;AACH,MAAM,UAAU,wBAAwB,CACtC,aAAmC,EACnC,SAAmB;IAEnB,IAAI,CAAC,aAAa,EAAE,MAAM;QAAE,OAAO,IAAI,CAAC;IACxC,OAAO,aAAa,CAAC,IAAI,CAAC,IAAI,CAAC,EAAE,CAAC,SAAS,CAAC,QAAQ,CAAC,IAAI,CAAC,CAAC,CAAC;AAC9D,CAAC;AAED;;;;GAIG;AACH,MAAM,UAAU,4BAA4B,CAC1C,gBAAoD,EACpD,eAAyB;IAEzB,IAAI,CAAC,gBAAgB;QAAE,OAAO,IAAI,CAAC;IAEnC,MAAM,WAAW,GAAG,KAAK,CAAC,OAAO,CAAC,gBAAgB,CAAC;QACjD,CAAC,CAAC,gBAAgB;QAClB,CAAC,CAAC,CAAC,gBAAgB,CAAC,QAAQ,IAAI,EAAE,CAAC,CAAC;IACtC,IAAI,WAAW,CAAC,MAAM,KAAK,CAAC;QAAE,OAAO,IAAI,CAAC;IAE1C,MAAM,IAAI,GAAG,KAAK,CAAC,OAAO,CAAC,gBAAgB,CAAC,CAAC,CAAC,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC,gBAAgB,CAAC,IAAI,IAAI,IAAI,CAAC,CAAC;IACtF,OAAO,IAAI,KAAK,IAAI;QAClB,CAAC,CAAC,WAAW,CAAC,IAAI,CAAC,OAAO,CAAC,EAAE,CAAC,eAAe,CAAC,QAAQ,CAAC,OAAO,CAAC,CAAC;QAChE,CAAC,CAAC,WAAW,CAAC,KAAK,CAAC,OAAO,CAAC,EAAE,CAAC,eAAe,CAAC,QAAQ,CAAC,OAAO,CAAC,CAAC,CAAC;AACtE,CAAC;AAED,+FAA+F;AAC/F,SAAS,gBAAgB,CAAC,OAAwB,EAAE,MAAgC;IAClF,OAAO,CACL,sCAAsC,CAAC,OAAO,CAAC,mBAAmB,EAAE,MAAM,CAAC,cAAc,CAAC;QAC1F,wBAAwB,CAAC,OAAO,CAAC,aAAa,EAAE,MAAM,CAAC,SAAS,CAAC;QACjE,4BAA4B,CAAC,OAAO,CAAC,gBAAgB,EAAE,MAAM,CAAC,eAAe,CAAC,CAC/E,CAAC;AACJ,CAAC;AAED;;;;;;;GAOG;AACH,MAAM,UAAU,uBAAuB,CACrC,MAAiC,EACjC,MAAgC;IAEhC,MAAM,gBAAgB,GAAuB,MAAM,CAAC,UAAU,CAAC,MAAM,CAAC,QAAQ,CAAC,EAAE,CAC/E,wBAAwB,CAAC,QAAQ,CAAC,KAAK,EAAE,MAAM,CAAC,QAAQ,CAAC,CAC1D,CAAC;IACF,MAAM,kBAAkB,GAAG,IAAI,GAAG,CAAC,gBAAgB,CAAC,GAAG,CAAC,QAAQ,CAAC,EAAE,CAAC,QAAQ,CAAC,GAAG,CAAC,CAAC,CAAC;IAEnF,MAAM,eAAe,GAAG,MAAM,CAAC,QAAQ,CAAC,MAAM,CAC5C,OAAO,CAAC,EAAE,CAAC,kBAAkB,CAAC,GAAG,CAAC,OAAO,CAAC,WAAW,CAAC,IAAI,gBAAgB,CAAC,OAAO,EAAE,MAAM,CAAC,CAC5F,CAAC;IAEF,4DAA4D;IAC5D,MAAM,qBAAqB,GAAG,IAAI,GAAG,CAAC,eAAe,CAAC,GAAG,CAAC,OAAO,CAAC,EAAE,CAAC,OAAO,CAAC,WAAW,CAAC,CAAC,CAAC;IAC3F,MAAM,iBAAiB,GAAG,gBAAgB,CAAC,MAAM,CAAC,QAAQ,CAAC,EAAE,CAC3D,qBAAqB,CAAC,GAAG,CAAC,QAAQ,CAAC,GAAG,CAAC,CACxC,CAAC;IAEF,MAAM,iBAAiB,GACrB,MAAM,CAAC,iBAAiB,IAAI,eAAe,CAAC,IAAI,CAAC,OAAO,CAAC,EAAE,CAAC,OAAO,CAAC,GAAG,KAAK,MAAM,CAAC,iBAAiB,CAAC;QACnG,CAAC,CAAC,MAAM,CAAC,iBAAiB;QAC1B,CAAC,CAAC,eAAe,CAAC,CAAC,CAAC,EAAE,GAAG,CAAC;IAE9B,OAAO;QACL,UAAU,EAAE,iBAAiB;QAC7B,QAAQ,EAAE,eAAe;QACzB,iBAAiB;KAClB,CAAC;AACJ,CAAC","sourcesContent":["/**\n * Settings Hub — Section Gating (\"face to right management of the user\")\n *\n * Pure, React-free evaluation of which categories/sections the current user may\n * see. Kept separate from the {@link useVisibleSettingsHubConfig} hook so the\n * gating decisions are unit-testable without a React tree.\n *\n * Four orthogonal gates, mirroring the framework's existing launcher/view gating\n * semantics so settings sections behave identically to every other gated surface:\n *\n * 1. **Scope** — a category bound to a {@link ResourcePrimaryScope} is hidden\n *    when that scope has no current value (e.g. the `ORGANIZATIONS` category is\n *    hidden when no organization is selected). Scope-agnostic categories always\n *    pass.\n * 2. **Capability** — `runtimeAvailability.requiredCapabilities` evaluated via\n *    the SAME {@link isLauncherRuntimeAvailabilitySatisfied} the sidebar/command\n *    menu use (e.g. `billingEnabled`).\n * 3. **Role** — `requiredRoles` (OR semantics) evaluated against the merged\n *    app-level + current-organization role set (`buildFeaturePolicyRoles`).\n * 4. **Feature** — `requiredFeatures` ({@link RequiredFeaturesConfig}) boolean\n *    presence check against the resolved feature list. `limitChecks` are\n *    intentionally ignored: a settings section is shown or hidden, never\n *    \"over-limit\".\n *\n * @see settings-hub.frontend.schemas.ts — the gated section contract\n * @see useVisibleSettingsHubConfig.ts — the hook that wires live signals into this\n */\n\nimport { ResourcePrimaryScope } from '@wildo-ai/saas-models';\nimport type { RequiredFeaturesConfig } from '@wildo-ai/saas-models';\nimport {\n  isLauncherRuntimeAvailabilitySatisfied,\n  type LauncherRuntimeAvailabilityContext,\n} from '~wildo-frontend-lib/core/navigation/launcher-runtime-availability';\nimport type {\n  ResolvedSettingsHubConfig,\n  SettingsCategory,\n  SettingsSection,\n} from './settings-hub.frontend.schemas';\n\n/** The current primary-scope values used to evaluate category scope availability. */\nexport interface SettingsScopeIds {\n  currentUserId?: string | null;\n  currentOrganizationId?: string | null;\n  currentApplicationId?: string | null;\n  currentAnonymousUserId?: string | null;\n}\n\n/** Everything the pure filter needs to decide section visibility. */\nexport interface SettingsHubGatingContext {\n  scopeIds: SettingsScopeIds;\n  /** Merged app-level + current-org roles (from `buildFeaturePolicyRoles`). */\n  userRoles: string[];\n  /** Resolved boolean feature identifiers currently enabled. */\n  enabledFeatures: string[];\n  /** Runtime-capability context (reused verbatim from the launcher layer). */\n  runtimeContext: LauncherRuntimeAvailabilityContext;\n}\n\n/**\n * Whether a category's primary scope currently has a value. A category without a\n * `scope` is scope-agnostic and always available.\n */\nexport function isSettingsScopeAvailable(\n  scope: ResourcePrimaryScope | undefined,\n  scopeIds: SettingsScopeIds,\n): boolean {\n  switch (scope) {\n    case undefined:\n      return true;\n    case ResourcePrimaryScope.USER_SELF:\n      return Boolean(scopeIds.currentUserId);\n    case ResourcePrimaryScope.ORGANIZATIONS:\n      return Boolean(scopeIds.currentOrganizationId);\n    case ResourcePrimaryScope.APPLICATION:\n      return Boolean(scopeIds.currentApplicationId);\n    case ResourcePrimaryScope.ANONYMOUS:\n      return Boolean(scopeIds.currentAnonymousUserId);\n  }\n}\n\n/**\n * OR-semantics role check: a section with no `requiredRoles` is open; otherwise\n * the user must hold AT LEAST ONE of the required roles. Matches the role\n * semantics in `evaluateGuidanceAudience`.\n */\nexport function hasRequiredSettingsRoles(\n  requiredRoles: string[] | undefined,\n  userRoles: string[],\n): boolean {\n  if (!requiredRoles?.length) return true;\n  return requiredRoles.some(role => userRoles.includes(role));\n}\n\n/**\n * Boolean feature gate mirroring {@link RequiredFeaturesConfig} semantics\n * (shorthand `string[]` = OR; full form honours `mode`). `limitChecks` are not\n * evaluated for visibility. A section with no `requiredFeatures` is open.\n */\nexport function areSettingsFeaturesSatisfied(\n  requiredFeatures: RequiredFeaturesConfig | undefined,\n  enabledFeatures: string[],\n): boolean {\n  if (!requiredFeatures) return true;\n\n  const featureList = Array.isArray(requiredFeatures)\n    ? requiredFeatures\n    : (requiredFeatures.features ?? []);\n  if (featureList.length === 0) return true;\n\n  const mode = Array.isArray(requiredFeatures) ? 'OR' : (requiredFeatures.mode ?? 'OR');\n  return mode === 'OR'\n    ? featureList.some(feature => enabledFeatures.includes(feature))\n    : featureList.every(feature => enabledFeatures.includes(feature));\n}\n\n/** A section passes every gate except its category's scope (checked at the category level). */\nfunction isSectionVisible(section: SettingsSection, gating: SettingsHubGatingContext): boolean {\n  return (\n    isLauncherRuntimeAvailabilitySatisfied(section.runtimeAvailability, gating.runtimeContext) &&\n    hasRequiredSettingsRoles(section.requiredRoles, gating.userRoles) &&\n    areSettingsFeaturesSatisfied(section.requiredFeatures, gating.enabledFeatures)\n  );\n}\n\n/**\n * Filter a raw {@link ResolvedSettingsHubConfig} down to what the current user may see.\n *\n * Categories are dropped when their scope is unavailable OR when every one of\n * their sections is gated out (an empty rail group would be visual noise). The\n * `defaultSectionRef` is recomputed when the configured default is no longer\n * visible, so the hub never tries to open a section the user cannot access.\n */\nexport function filterSettingsHubConfig(\n  config: ResolvedSettingsHubConfig,\n  gating: SettingsHubGatingContext,\n): ResolvedSettingsHubConfig {\n  const scopedCategories: SettingsCategory[] = config.categories.filter(category =>\n    isSettingsScopeAvailable(category.scope, gating.scopeIds),\n  );\n  const scopedCategoryRefs = new Set(scopedCategories.map(category => category.ref));\n\n  const visibleSections = config.sections.filter(\n    section => scopedCategoryRefs.has(section.categoryRef) && isSectionVisible(section, gating),\n  );\n\n  // Drop categories that ended up with zero visible sections.\n  const populatedCategoryRefs = new Set(visibleSections.map(section => section.categoryRef));\n  const visibleCategories = scopedCategories.filter(category =>\n    populatedCategoryRefs.has(category.ref),\n  );\n\n  const defaultSectionRef =\n    config.defaultSectionRef && visibleSections.some(section => section.ref === config.defaultSectionRef)\n      ? config.defaultSectionRef\n      : visibleSections[0]?.ref;\n\n  return {\n    categories: visibleCategories,\n    sections: visibleSections,\n    defaultSectionRef,\n  };\n}\n"]}
+{"version":3,"file":"settings-hub-gating.frontend.utils.js","sourceRoot":"","sources":["../../../../../src/core/config/settings-hub-gating.frontend.utils.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;GA0BG;AAEH,OAAO,EAAE,oBAAoB,EAAE,MAAM,uBAAuB,CAAC;AAE7D,OAAO,EACL,sCAAsC,GAEvC,MAAM,mEAAmE,CAAC;AA0B3E;;;GAGG;AACH,MAAM,UAAU,wBAAwB,CACtC,KAAuC,EACvC,QAA0B;IAE1B,QAAQ,KAAK,EAAE,CAAC;QACd,KAAK,SAAS;YACZ,OAAO,IAAI,CAAC;QACd,KAAK,oBAAoB,CAAC,SAAS;YACjC,OAAO,OAAO,CAAC,QAAQ,CAAC,aAAa,CAAC,CAAC;QACzC,KAAK,oBAAoB,CAAC,aAAa;YACrC,OAAO,OAAO,CAAC,QAAQ,CAAC,qBAAqB,CAAC,CAAC;QACjD,KAAK,oBAAoB,CAAC,WAAW;YACnC,OAAO,OAAO,CAAC,QAAQ,CAAC,oBAAoB,CAAC,CAAC;QAChD,KAAK,oBAAoB,CAAC,SAAS;YACjC,OAAO,OAAO,CAAC,QAAQ,CAAC,sBAAsB,CAAC,CAAC;IACpD,CAAC;AACH,CAAC;AAED;;;;GAIG;AACH,MAAM,UAAU,wBAAwB,CACtC,aAAmC,EACnC,SAAmB;IAEnB,IAAI,CAAC,aAAa,EAAE,MAAM;QAAE,OAAO,IAAI,CAAC;IACxC,OAAO,aAAa,CAAC,IAAI,CAAC,IAAI,CAAC,EAAE,CAAC,SAAS,CAAC,QAAQ,CAAC,IAAI,CAAC,CAAC,CAAC;AAC9D,CAAC;AAED;;;;GAIG;AACH,MAAM,UAAU,4BAA4B,CAC1C,gBAAoD,EACpD,eAAyB;IAEzB,IAAI,CAAC,gBAAgB;QAAE,OAAO,IAAI,CAAC;IAEnC,MAAM,WAAW,GAAG,KAAK,CAAC,OAAO,CAAC,gBAAgB,CAAC;QACjD,CAAC,CAAC,gBAAgB;QAClB,CAAC,CAAC,CAAC,gBAAgB,CAAC,QAAQ,IAAI,EAAE,CAAC,CAAC;IACtC,IAAI,WAAW,CAAC,MAAM,KAAK,CAAC;QAAE,OAAO,IAAI,CAAC;IAE1C,MAAM,IAAI,GAAG,KAAK,CAAC,OAAO,CAAC,gBAAgB,CAAC,CAAC,CAAC,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC,gBAAgB,CAAC,IAAI,IAAI,IAAI,CAAC,CAAC;IACtF,OAAO,IAAI,KAAK,IAAI;QAClB,CAAC,CAAC,WAAW,CAAC,IAAI,CAAC,OAAO,CAAC,EAAE,CAAC,eAAe,CAAC,QAAQ,CAAC,OAAO,CAAC,CAAC;QAChE,CAAC,CAAC,WAAW,CAAC,KAAK,CAAC,OAAO,CAAC,EAAE,CAAC,eAAe,CAAC,QAAQ,CAAC,OAAO,CAAC,CAAC,CAAC;AACtE,CAAC;AAED,+FAA+F;AAC/F,SAAS,gBAAgB,CAAC,OAAwB,EAAE,MAAgC;IAClF,OAAO,CACL,sCAAsC,CAAC,OAAO,CAAC,mBAAmB,EAAE,MAAM,CAAC,cAAc,CAAC;QAC1F,wBAAwB,CAAC,OAAO,CAAC,aAAa,EAAE,MAAM,CAAC,SAAS,CAAC;QACjE,4BAA4B,CAAC,OAAO,CAAC,gBAAgB,EAAE,MAAM,CAAC,eAAe,CAAC,CAC/E,CAAC;AACJ,CAAC;AAED;;;;;;;GAOG;AACH,MAAM,UAAU,uBAAuB,CACrC,MAAiC,EACjC,MAAgC;IAEhC,MAAM,gBAAgB,GAAuB,MAAM,CAAC,UAAU,CAAC,MAAM,CAAC,QAAQ,CAAC,EAAE,CAC/E,wBAAwB,CAAC,QAAQ,CAAC,KAAK,EAAE,MAAM,CAAC,QAAQ,CAAC,CAC1D,CAAC;IACF,MAAM,kBAAkB,GAAG,IAAI,GAAG,CAAC,gBAAgB,CAAC,GAAG,CAAC,QAAQ,CAAC,EAAE,CAAC,QAAQ,CAAC,GAAG,CAAC,CAAC,CAAC;IAEnF,MAAM,eAAe,GAAG,MAAM,CAAC,QAAQ,CAAC,MAAM,CAC5C,OAAO,CAAC,EAAE,CAAC,kBAAkB,CAAC,GAAG,CAAC,OAAO,CAAC,WAAW,CAAC,IAAI,gBAAgB,CAAC,OAAO,EAAE,MAAM,CAAC,CAC5F,CAAC;IAEF,4DAA4D;IAC5D,MAAM,qBAAqB,GAAG,IAAI,GAAG,CAAC,eAAe,CAAC,GAAG,CAAC,OAAO,CAAC,EAAE,CAAC,OAAO,CAAC,WAAW,CAAC,CAAC,CAAC;IAC3F,MAAM,iBAAiB,GAAG,gBAAgB,CAAC,MAAM,CAAC,QAAQ,CAAC,EAAE,CAC3D,qBAAqB,CAAC,GAAG,CAAC,QAAQ,CAAC,GAAG,CAAC,CACxC,CAAC;IAEF,MAAM,iBAAiB,GACrB,MAAM,CAAC,iBAAiB,IAAI,eAAe,CAAC,IAAI,CAAC,OAAO,CAAC,EAAE,CAAC,OAAO,CAAC,GAAG,KAAK,MAAM,CAAC,iBAAiB,CAAC;QACnG,CAAC,CAAC,MAAM,CAAC,iBAAiB;QAC1B,CAAC,CAAC,eAAe,CAAC,CAAC,CAAC,EAAE,GAAG,CAAC;IAE9B,OAAO;QACL,UAAU,EAAE,iBAAiB;QAC7B,QAAQ,EAAE,eAAe;QACzB,iBAAiB;KAClB,CAAC;AACJ,CAAC","sourcesContent":["/**\n * Settings Hub — Section Gating (\"face to right management of the user\")\n *\n * Pure, React-free evaluation of which categories/sections the current user may\n * see. Kept separate from the {@link useVisibleSettingsHubConfig} hook so the\n * gating decisions are unit-testable without a React tree.\n *\n * Four orthogonal gates, mirroring the framework's existing launcher/view gating\n * semantics so settings sections behave identically to every other gated surface:\n *\n * 1. **Scope** — a category bound to a {@link ResourcePrimaryScope} is hidden\n *    when that scope has no current value (e.g. the `ORGANIZATIONS` category is\n *    hidden when no organization is selected). Scope-agnostic categories always\n *    pass.\n * 2. **Capability** — `runtimeAvailability.requiredCapabilities` evaluated via\n *    the SAME {@link isLauncherRuntimeAvailabilitySatisfied} the sidebar/command\n *    menu use (e.g. `billingEnabled`).\n * 3. **Role** — `requiredRoles` (OR semantics) evaluated against the merged\n *    app-level + current-organization role set (`buildFeaturePolicyRoles`).\n * 4. **Feature** — `requiredFeatures` ({@link RequiredFeaturesConfig}) boolean\n *    presence check against the resolved feature list. `limitChecks` are\n *    intentionally ignored: a settings section is shown or hidden, never\n *    \"over-limit\".\n *\n * @see settings-hub.frontend.schemas.ts — the gated section contract\n * @see useVisibleSettingsHubConfig.ts — the hook that wires live signals into this\n */\n\nimport { ResourcePrimaryScope } from '@wildo-ai/saas-models';\nimport type { RequiredFeaturesConfig } from '@wildo-ai/saas-models';\nimport {\n  isLauncherRuntimeAvailabilitySatisfied,\n  type LauncherRuntimeAvailabilityContext,\n} from '~wildo-frontend-lib/core/navigation/launcher-runtime-availability';\nimport type {\n  ResolvedSettingsHubConfig,\n  SettingsCategory,\n  SettingsSection,\n} from './settings-hub.frontend.schemas';\n\n/** The current primary-scope values used to evaluate category scope availability. */\nexport interface SettingsScopeIds {\n  currentUserId?: string | null;\n  currentOrganizationId?: string | null;\n  currentApplicationId?: string | null;\n  currentAnonymousUserId?: string | null;\n}\n\n/** Everything the pure filter needs to decide section visibility. */\nexport interface SettingsHubGatingContext {\n  scopeIds: SettingsScopeIds;\n  /** Merged app-level + current-org roles (from `buildFeaturePolicyRoles`). */\n  userRoles: string[];\n  /** Resolved boolean feature identifiers currently enabled. */\n  enabledFeatures: string[];\n  /** Runtime-capability context (reused verbatim from the launcher layer). */\n  runtimeContext: LauncherRuntimeAvailabilityContext;\n}\n\n/**\n * Whether a category's primary scope currently has a value. A category without a\n * `scope` is scope-agnostic and always available.\n */\nexport function isSettingsScopeAvailable(\n  scope: ResourcePrimaryScope | undefined,\n  scopeIds: SettingsScopeIds,\n): boolean {\n  switch (scope) {\n    case undefined:\n      return true;\n    case ResourcePrimaryScope.USER_SELF:\n      return Boolean(scopeIds.currentUserId);\n    case ResourcePrimaryScope.ORGANIZATIONS:\n      return Boolean(scopeIds.currentOrganizationId);\n    case ResourcePrimaryScope.APPLICATION:\n      return Boolean(scopeIds.currentApplicationId);\n    case ResourcePrimaryScope.ANONYMOUS:\n      return Boolean(scopeIds.currentAnonymousUserId);\n  }\n}\n\n/**\n * OR-semantics role check: a section with no `requiredRoles` is open; otherwise\n * the user must hold AT LEAST ONE of the required roles. Matches the role\n * semantics in `evaluateGuidanceAudience`.\n */\nexport function hasRequiredSettingsRoles(\n  requiredRoles: string[] | undefined,\n  userRoles: string[],\n): boolean {\n  if (!requiredRoles?.length) return true;\n  return requiredRoles.some(role => userRoles.includes(role));\n}\n\n/**\n * Boolean feature gate mirroring {@link RequiredFeaturesConfig} semantics\n * (shorthand `string[]` = OR; full form honours `mode`). `limitChecks` are not\n * evaluated for visibility. A section with no `requiredFeatures` is open.\n */\nexport function areSettingsFeaturesSatisfied(\n  requiredFeatures: RequiredFeaturesConfig | undefined,\n  enabledFeatures: string[],\n): boolean {\n  if (!requiredFeatures) return true;\n\n  const featureList = Array.isArray(requiredFeatures)\n    ? requiredFeatures\n    : (requiredFeatures.features ?? []);\n  if (featureList.length === 0) return true;\n\n  const mode = Array.isArray(requiredFeatures) ? 'OR' : (requiredFeatures.mode ?? 'OR');\n  return mode === 'OR'\n    ? featureList.some(feature => enabledFeatures.includes(feature))\n    : featureList.every(feature => enabledFeatures.includes(feature));\n}\n\n/** A section passes every gate except its category's scope (checked at the category level). */\nfunction isSectionVisible(section: SettingsSection, gating: SettingsHubGatingContext): boolean {\n  return (\n    isLauncherRuntimeAvailabilitySatisfied(section.runtimeAvailability, gating.runtimeContext) &&\n    hasRequiredSettingsRoles(section.requiredRoles, gating.userRoles) &&\n    areSettingsFeaturesSatisfied(section.requiredFeatures, gating.enabledFeatures)\n  );\n}\n\n/**\n * Filter a raw {@link ResolvedSettingsHubConfig} down to what the current user may see.\n *\n * Categories are dropped when their scope is unavailable OR when every one of\n * their sections is gated out (an empty rail group would be visual noise). The\n * `defaultSectionRef` is recomputed when the configured default is no longer\n * visible, so the hub never tries to open a section the user cannot access.\n */\nexport function filterSettingsHubConfig(\n  config: ResolvedSettingsHubConfig,\n  gating: SettingsHubGatingContext,\n): ResolvedSettingsHubConfig {\n  const scopedCategories: SettingsCategory[] = config.categories.filter(category =>\n    isSettingsScopeAvailable(category.scope, gating.scopeIds),\n  );\n  const scopedCategoryRefs = new Set(scopedCategories.map(category => category.ref));\n\n  const visibleSections = config.sections.filter(\n    section => scopedCategoryRefs.has(section.categoryRef) && isSectionVisible(section, gating),\n  );\n\n  // Drop categories that ended up with zero visible sections.\n  const populatedCategoryRefs = new Set(visibleSections.map(section => section.categoryRef));\n  const visibleCategories = scopedCategories.filter(category =>\n    populatedCategoryRefs.has(category.ref),\n  );\n\n  const defaultSectionRef =\n    config.defaultSectionRef && visibleSections.some(section => section.ref === config.defaultSectionRef)\n      ? config.defaultSectionRef\n      : visibleSections[0]?.ref;\n\n  return {\n    categories: visibleCategories,\n    sections: visibleSections,\n    defaultSectionRef,\n  };\n}\n"]}

package/dist/esm/core/config/settings-hub-presentation.frontend.utils.d.ts

@@ -0,0 +1,22 @@
+import { type ContainerSectionMode } from '@wildo-ai/zod-decorators';
+import { type SettingsSection, type SettingsSectionTarget } from '../../core/config/settings-hub.frontend.schemas';
+export declare function settingsSectionTargetRendersCollection(target: SettingsSectionTarget): boolean;
+/**
+ * Whether the pane at `sectionRef` needs the wide frame. An unresolvable ref — no section, or the
+ * hub opened before its config resolved — answers `false`, which is the narrow width the hub has
+ * always used.
+ *
+ * TWO reasons, and they are the same question asked of different things:
+ *
+ * - the section renders a COLLECTION, so the pane holds a table;
+ * - the resource's layout declares a NAVIGATION container mode, so the pane holds a second vertical
+ *   rail of its own. SSO config is the case: seven groups of fields, presented as vertical tabs, and
+ *   `w-48` of rail comes out of the same content column the 240px hub rail already took. At the
+ *   record width that leaves about 400px for a label-left / value-right row.
+ *
+ * The second reason is why `ResourceLayoutConfig.defaultDisplaySectionAppearance` is a layout
+ * DECLARATION and not seven `appearance` props inside a template: a prop inside a React template is
+ * invisible to anything that has to size the surface around it.
+ */
+export declare function settingsSectionNeedsWideFrame(sections: readonly SettingsSection[], sectionRef: string | undefined, resolveLayoutSectionAppearance: (resourceType: string) => ContainerSectionMode | undefined): boolean;
+//# sourceMappingURL=settings-hub-presentation.frontend.utils.d.ts.map

package/dist/esm/core/config/settings-hub-presentation.frontend.utils.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"settings-hub-presentation.frontend.utils.d.ts","sourceRoot":"","sources":["../../../../../src/core/config/settings-hub-presentation.frontend.utils.ts"],"names":[],"mappings":"AAyBA,OAAO,EAAe,KAAK,oBAAoB,EAAE,MAAM,0BAA0B,CAAC;AAClF,OAAO,EAGL,KAAK,eAAe,EACpB,KAAK,qBAAqB,EAC3B,MAAM,+DAA+D,CAAC;AAoCvE,wBAAgB,sCAAsC,CAAC,MAAM,EAAE,qBAAqB,GAAG,OAAO,CAE7F;AAED;;;;;;;;;;;;;;;;GAgBG;AACH,wBAAgB,6BAA6B,CAC3C,QAAQ,EAAE,SAAS,eAAe,EAAE,EACpC,UAAU,EAAE,MAAM,GAAG,SAAS,EAC9B,8BAA8B,EAAE,CAAC,YAAY,EAAE,MAAM,KAAK,oBAAoB,GAAG,SAAS,GACzF,OAAO,CAiBT"}

package/dist/esm/core/config/settings-hub-presentation.frontend.utils.js

@@ -0,0 +1,91 @@
+/**
+ * How WIDE the Settings Hub needs to be, derived from what the open section renders.
+ *
+ * The hub is one overlay serving two different kinds of surface, and until now one constant served
+ * both. `max-w-4xl` (896px) minus the `w-60` rail (240px) leaves roughly 640px of content. That is
+ * generous for a settings RECORD — a column of label-left / value-right rows, read one at a time to
+ * decide something — and cramped for a COLLECTION: the organization-members table alone carries
+ * name, email, role, status, joined and an actions column, and a table squeezed to 640px is the
+ * surface an administrator came to the hub to work in.
+ *
+ * So the width is DERIVED from the section's declared target rather than authored per section. The
+ * discriminator already exists: a `RESOURCE_OPERATION` target names the operation it renders, and
+ * `LIST` / `SEARCH` are the two core operations that produce a collection. Nothing new is asked of
+ * an application, a section added tomorrow is sized by what it declares, and there is no per-section
+ * width to keep in step with the content.
+ *
+ * Deliberately conservative in both directions:
+ *
+ * - An operation this cannot classify — a custom verb, a bespoke engine panel, an app component —
+ *   is NOT a collection. The narrow width is the current behaviour, so an unclassifiable section is
+ *   unchanged rather than guessed at.
+ * - A SUB_TABS section counts as a collection when ANY of its tabs is one. The tab a reader opens is
+ *   their choice and the overlay cannot resize under them without the panel reflowing mid-read.
+ */
+import { CoreResourceOperation } from '@wildo-ai/saas-models';
+import { SectionMode } from '@wildo-ai/zod-decorators';
+import { SettingsSectionTargetKind, } from '../../core/config/settings-hub.frontend.schemas.js';
+/**
+ * The core operations that render a COLLECTION rather than one record.
+ *
+ * Total over the vocabulary at the point it is read: a core operation added tomorrow is classified
+ * here or is not a collection, and either answer is deliberate rather than silent.
+ */
+const COLLECTION_RENDERING_CORE_OPERATIONS = [
+    CoreResourceOperation.LIST,
+    CoreResourceOperation.SEARCH,
+];
+function leafTargets(target) {
+    return target.kind === SettingsSectionTargetKind.SUB_TABS
+        ? target.subTabs.map((subTab) => subTab.target)
+        : [target];
+}
+/**
+ * The container modes that show ONE section at a time behind their own navigation control. Only
+ * `VERTICAL_TABS` actually spends horizontal room — a horizontal strip and a pill row cost height —
+ * so this is deliberately not "every navigation mode".
+ */
+function isNavigationContainerSectionMode(mode) {
+    return mode === SectionMode.VERTICAL_TABS;
+}
+function leafTargetRendersCollection(target) {
+    if (target.kind !== SettingsSectionTargetKind.RESOURCE_OPERATION) {
+        return false;
+    }
+    return COLLECTION_RENDERING_CORE_OPERATIONS.includes(String(target.operation));
+}
+export function settingsSectionTargetRendersCollection(target) {
+    return leafTargets(target).some(leafTargetRendersCollection);
+}
+/**
+ * Whether the pane at `sectionRef` needs the wide frame. An unresolvable ref — no section, or the
+ * hub opened before its config resolved — answers `false`, which is the narrow width the hub has
+ * always used.
+ *
+ * TWO reasons, and they are the same question asked of different things:
+ *
+ * - the section renders a COLLECTION, so the pane holds a table;
+ * - the resource's layout declares a NAVIGATION container mode, so the pane holds a second vertical
+ *   rail of its own. SSO config is the case: seven groups of fields, presented as vertical tabs, and
+ *   `w-48` of rail comes out of the same content column the 240px hub rail already took. At the
+ *   record width that leaves about 400px for a label-left / value-right row.
+ *
+ * The second reason is why `ResourceLayoutConfig.defaultDisplaySectionAppearance` is a layout
+ * DECLARATION and not seven `appearance` props inside a template: a prop inside a React template is
+ * invisible to anything that has to size the surface around it.
+ */
+export function settingsSectionNeedsWideFrame(sections, sectionRef, resolveLayoutSectionAppearance) {
+    if (!sectionRef) {
+        return false;
+    }
+    const section = sections.find((candidate) => candidate.ref === sectionRef);
+    if (!section) {
+        return false;
+    }
+    if (settingsSectionTargetRendersCollection(section.target)) {
+        return true;
+    }
+    return leafTargets(section.target).some((target) => target.kind === SettingsSectionTargetKind.RESOURCE_OPERATION
+        && isNavigationContainerSectionMode(resolveLayoutSectionAppearance(target.resourceType)));
+}
+//# sourceMappingURL=settings-hub-presentation.frontend.utils.js.map

package/dist/esm/core/config/settings-hub-presentation.frontend.utils.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"settings-hub-presentation.frontend.utils.js","sourceRoot":"","sources":["../../../../../src/core/config/settings-hub-presentation.frontend.utils.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AACH,OAAO,EAAE,qBAAqB,EAAE,MAAM,uBAAuB,CAAC;AAC9D,OAAO,EAAE,WAAW,EAA6B,MAAM,0BAA0B,CAAC;AAClF,OAAO,EACL,yBAAyB,GAI1B,MAAM,+DAA+D,CAAC;AAEvE;;;;;GAKG;AACH,MAAM,oCAAoC,GAAsB;IAC9D,qBAAqB,CAAC,IAAI;IAC1B,qBAAqB,CAAC,MAAM;CAC7B,CAAC;AAEF,SAAS,WAAW,CAAC,MAA6B;IAChD,OAAO,MAAM,CAAC,IAAI,KAAK,yBAAyB,CAAC,QAAQ;QACvD,CAAC,CAAC,MAAM,CAAC,OAAO,CAAC,GAAG,CAAC,CAAC,MAAM,EAAE,EAAE,CAAC,MAAM,CAAC,MAAM,CAAC;QAC/C,CAAC,CAAC,CAAC,MAAM,CAAC,CAAC;AACf,CAAC;AAED;;;;GAIG;AACH,SAAS,gCAAgC,CAAC,IAAsC;IAC9E,OAAO,IAAI,KAAK,WAAW,CAAC,aAAa,CAAC;AAC5C,CAAC;AAED,SAAS,2BAA2B,CAAC,MAA0B;IAC7D,IAAI,MAAM,CAAC,IAAI,KAAK,yBAAyB,CAAC,kBAAkB,EAAE,CAAC;QACjE,OAAO,KAAK,CAAC;IACf,CAAC;IAED,OAAO,oCAAoC,CAAC,QAAQ,CAAC,MAAM,CAAC,MAAM,CAAC,SAAS,CAAC,CAAC,CAAC;AACjF,CAAC;AAED,MAAM,UAAU,sCAAsC,CAAC,MAA6B;IAClF,OAAO,WAAW,CAAC,MAAM,CAAC,CAAC,IAAI,CAAC,2BAA2B,CAAC,CAAC;AAC/D,CAAC;AAED;;;;;;;;;;;;;;;;GAgBG;AACH,MAAM,UAAU,6BAA6B,CAC3C,QAAoC,EACpC,UAA8B,EAC9B,8BAA0F;IAE1F,IAAI,CAAC,UAAU,EAAE,CAAC;QAChB,OAAO,KAAK,CAAC;IACf,CAAC;IAED,MAAM,OAAO,GAAG,QAAQ,CAAC,IAAI,CAAC,CAAC,SAAS,EAAE,EAAE,CAAC,SAAS,CAAC,GAAG,KAAK,UAAU,CAAC,CAAC;IAC3E,IAAI,CAAC,OAAO,EAAE,CAAC;QACb,OAAO,KAAK,CAAC;IACf,CAAC;IAED,IAAI,sCAAsC,CAAC,OAAO,CAAC,MAAM,CAAC,EAAE,CAAC;QAC3D,OAAO,IAAI,CAAC;IACd,CAAC;IAED,OAAO,WAAW,CAAC,OAAO,CAAC,MAAM,CAAC,CAAC,IAAI,CAAC,CAAC,MAAM,EAAE,EAAE,CACjD,MAAM,CAAC,IAAI,KAAK,yBAAyB,CAAC,kBAAkB;WACzD,gCAAgC,CAAC,8BAA8B,CAAC,MAAM,CAAC,YAAY,CAAC,CAAC,CAAC,CAAC;AAC9F,CAAC","sourcesContent":["/**\n * How WIDE the Settings Hub needs to be, derived from what the open section renders.\n *\n * The hub is one overlay serving two different kinds of surface, and until now one constant served\n * both. `max-w-4xl` (896px) minus the `w-60` rail (240px) leaves roughly 640px of content. That is\n * generous for a settings RECORD — a column of label-left / value-right rows, read one at a time to\n * decide something — and cramped for a COLLECTION: the organization-members table alone carries\n * name, email, role, status, joined and an actions column, and a table squeezed to 640px is the\n * surface an administrator came to the hub to work in.\n *\n * So the width is DERIVED from the section's declared target rather than authored per section. The\n * discriminator already exists: a `RESOURCE_OPERATION` target names the operation it renders, and\n * `LIST` / `SEARCH` are the two core operations that produce a collection. Nothing new is asked of\n * an application, a section added tomorrow is sized by what it declares, and there is no per-section\n * width to keep in step with the content.\n *\n * Deliberately conservative in both directions:\n *\n * - An operation this cannot classify — a custom verb, a bespoke engine panel, an app component —\n *   is NOT a collection. The narrow width is the current behaviour, so an unclassifiable section is\n *   unchanged rather than guessed at.\n * - A SUB_TABS section counts as a collection when ANY of its tabs is one. The tab a reader opens is\n *   their choice and the overlay cannot resize under them without the panel reflowing mid-read.\n */\nimport { CoreResourceOperation } from '@wildo-ai/saas-models';\nimport { SectionMode, type ContainerSectionMode } from '@wildo-ai/zod-decorators';\nimport {\n  SettingsSectionTargetKind,\n  type SettingsLeafTarget,\n  type SettingsSection,\n  type SettingsSectionTarget,\n} from '~wildo-frontend-lib/core/config/settings-hub.frontend.schemas';\n\n/**\n * The core operations that render a COLLECTION rather than one record.\n *\n * Total over the vocabulary at the point it is read: a core operation added tomorrow is classified\n * here or is not a collection, and either answer is deliberate rather than silent.\n */\nconst COLLECTION_RENDERING_CORE_OPERATIONS: readonly string[] = [\n  CoreResourceOperation.LIST,\n  CoreResourceOperation.SEARCH,\n];\n\nfunction leafTargets(target: SettingsSectionTarget): SettingsLeafTarget[] {\n  return target.kind === SettingsSectionTargetKind.SUB_TABS\n    ? target.subTabs.map((subTab) => subTab.target)\n    : [target];\n}\n\n/**\n * The container modes that show ONE section at a time behind their own navigation control. Only\n * `VERTICAL_TABS` actually spends horizontal room — a horizontal strip and a pill row cost height —\n * so this is deliberately not \"every navigation mode\".\n */\nfunction isNavigationContainerSectionMode(mode: ContainerSectionMode | undefined): boolean {\n  return mode === SectionMode.VERTICAL_TABS;\n}\n\nfunction leafTargetRendersCollection(target: SettingsLeafTarget): boolean {\n  if (target.kind !== SettingsSectionTargetKind.RESOURCE_OPERATION) {\n    return false;\n  }\n\n  return COLLECTION_RENDERING_CORE_OPERATIONS.includes(String(target.operation));\n}\n\nexport function settingsSectionTargetRendersCollection(target: SettingsSectionTarget): boolean {\n  return leafTargets(target).some(leafTargetRendersCollection);\n}\n\n/**\n * Whether the pane at `sectionRef` needs the wide frame. An unresolvable ref — no section, or the\n * hub opened before its config resolved — answers `false`, which is the narrow width the hub has\n * always used.\n *\n * TWO reasons, and they are the same question asked of different things:\n *\n * - the section renders a COLLECTION, so the pane holds a table;\n * - the resource's layout declares a NAVIGATION container mode, so the pane holds a second vertical\n *   rail of its own. SSO config is the case: seven groups of fields, presented as vertical tabs, and\n *   `w-48` of rail comes out of the same content column the 240px hub rail already took. At the\n *   record width that leaves about 400px for a label-left / value-right row.\n *\n * The second reason is why `ResourceLayoutConfig.defaultDisplaySectionAppearance` is a layout\n * DECLARATION and not seven `appearance` props inside a template: a prop inside a React template is\n * invisible to anything that has to size the surface around it.\n */\nexport function settingsSectionNeedsWideFrame(\n  sections: readonly SettingsSection[],\n  sectionRef: string | undefined,\n  resolveLayoutSectionAppearance: (resourceType: string) => ContainerSectionMode | undefined,\n): boolean {\n  if (!sectionRef) {\n    return false;\n  }\n\n  const section = sections.find((candidate) => candidate.ref === sectionRef);\n  if (!section) {\n    return false;\n  }\n\n  if (settingsSectionTargetRendersCollection(section.target)) {\n    return true;\n  }\n\n  return leafTargets(section.target).some((target) =>\n    target.kind === SettingsSectionTargetKind.RESOURCE_OPERATION\n    && isNavigationContainerSectionMode(resolveLayoutSectionAppearance(target.resourceType)));\n}\n"]}

package/dist/esm/core/config/settings-hub.frontend.schemas.d.ts

@@ -12,8 +12,9 @@
  * - `SettingsSectionTarget` is an interface-based discriminated union on `kind`
  *   (exactly like `LauncherItemRef`), because section targets are config-time
  *   descriptors resolved by the runtime — not Zod-validated wire payloads.
- * - The framework seeds a default `SettingsHubConfig`; apps merge/extend it
- *   (same model as the sidebar/launcher config).
+ * - The engine ships DESTINATIONS (`ENGINE_SETTINGS_DESTINATIONS`) and no
+ *   arrangement; an application authors its own `SettingsHubConfig` — its
+ *   categories, its placements, and any destinations of its own.
  *
  * Runtime concerns live elsewhere:
  * - `NavigationContentType.SETTINGS_HUB` (navigation.schemas.ts) — what renders
@@ -27,6 +28,7 @@
 import { ResourcePrimaryScope } from '@wildo-ai/saas-models';
 import type { RequiredFeaturesConfig } from '@wildo-ai/saas-models';
 import type { LauncherRuntimeAvailabilityConfig } from './launcher-items.frontend.schemas';
+/** @wildo_source:part:start saas.frontend.settings-hub.placement */
 /**
  * What a settings section renders in its content panel.
  *
@@ -45,6 +47,7 @@ export declare enum SettingsSectionTargetKind {
     /** A section that itself splits into horizontal sub-tabs (e.g. Teams → Members / Roles & Permissions). */
     SUB_TABS = "sub_tabs"
 }
+/** @wildo_source:part:end saas.frontend.settings-hub.placement */
 /**
  * Framework-provided settings panels with bespoke (non-CRUD) layout.
  *
@@ -88,8 +91,18 @@ export declare enum SettingsPanelRef {
      * Paired with, never replacing, the credential list: this panel answers what MAY be connected and
      * the list answers what IS, and the empty answer to the second is exactly when the first matters.
      */
-    CONNECTED_ACCOUNTS = "connected-accounts"
+    CONNECTED_ACCOUNTS = "connected-accounts",
+    /**
+     * The same act at the TENANT's scope: connecting an account the whole organization acts as.
+     *
+     * A distinct ref rather than a parameterised one, because a settings destination resolves a ref to
+     * a panel and carries no arguments — and because the two must never be reachable from each other's
+     * screen. The component behind them IS shared: the act is identical, and duplicating it would
+     * guarantee the two drift. What is never shared is the data.
+     */
+    ORGANIZATION_CONNECTED_ACCOUNTS = "organization-connected-accounts"
 }
+/** @wildo_source:part:start saas.frontend.settings-hub.placement */
 /** Renders a framework-owned bespoke panel. */
 export interface SettingsEnginePanelTarget {
     kind: SettingsSectionTargetKind.ENGINE_PANEL;
@@ -141,6 +154,7 @@ export interface SettingsSubTabsTarget {
  * resolver dispatches on it to produce the panel content.
  */
 export type SettingsSectionTarget = SettingsLeafTarget | SettingsSubTabsTarget;
+/** @wildo_source:part:end saas.frontend.settings-hub.placement */
 /**
  * A category groups sections in the vertical rail (the `Account` / `Organization`
  * group headers in the BetterStack reference). Rendered as a label + separator
@@ -173,10 +187,12 @@ export interface SettingsCategory {
  * An addressable settings DESTINATION — what a settings surface *is*, with no
  * opinion on where it appears.
  *
- * This is the half the engine ships (`ENGINE_SETTINGS_DESTINATIONS`). It carries
- * the target and the gating stack, and deliberately carries **no `categoryRef`,
- * no `order` and no `label`**: those are placement, and placement is the
- * application's decision (`SettingsPlacement`).
+ * The engine ships most of them (`ENGINE_SETTINGS_DESTINATIONS`); an application
+ * may declare its own in `SettingsHubConfig.destinations` — a settings surface for
+ * one of its OWN resources, or a component it registers. Either way a destination
+ * carries the target and the gating stack, and deliberately carries **no
+ * `categoryRef`, no `order` and no `label`**: those are placement, and placement is
+ * the application's decision (`SettingsPlacement`).
  *
  * The split exists because the engine shipping a PLACED hub is what made the
  * settings rail unauthorable — an application could not add, remove, reorder or
@@ -216,7 +232,7 @@ export interface SettingsDestination {
  * English string. R9 is a wiring job, not a new mechanism.
  */
 export interface SettingsPlacement {
-    /** The {@link SettingsDestination.ref} being placed. Refused at DEV startup when unknown. */
+    /** The {@link SettingsDestination.ref} being placed — an engine destination or one of `destinations`. Refused at DEV startup when unknown. */
     destinationRef: string;
     /** Which category (rail group) this destination sits under. */
     categoryRef: string;
@@ -292,9 +308,10 @@ export interface SettingsSection {
  * The AUTHORED Settings Hub registry — an application's own settings rail.
  *
  * The framework ships destinations (`ENGINE_SETTINGS_DESTINATIONS`), never a
- * placed hub. This is the application's half: which categories exist, and which
- * destinations are placed where. `wildo init` scaffolds the full destination list
- * as placements so a new application starts complete and edits down.
+ * placed hub. This is the application's half: which categories exist, which
+ * destinations are placed where, and any destinations the application owns.
+ * `wildo init` scaffolds the full engine destination list as placements so a new
+ * application starts complete and edits down.
  *
  * Resolve it with `resolveSettingsHubConfig()` to get the rendered
  * {@link SettingsSection} list; the render path never reads this shape directly.
@@ -310,6 +327,17 @@ export interface SettingsHubConfig {
      * must not be second-guessed by a merge against a framework default.
      */
     placements: SettingsPlacement[];
+    /**
+     * The application's OWN destinations — settings surfaces the engine does not
+     * ship, such as a list of the application's team members or a component it
+     * registers. Declared here, then placed like any other destination; a
+     * declared destination that no placement names does not render.
+     *
+     * The ref must not be an engine destination's ref. The engine keeps owning
+     * what its destinations mean, so on a clash the ENGINE destination is the one
+     * resolved, and the DEV startup verifier reports the clash.
+     */
+    destinations?: SettingsDestination[];
     /**
      * Section opened when the hub is launched without an explicit section
      * (`/settings` with no `:sectionRef`). Falls back to the first section of the

package/dist/esm/core/config/settings-hub.frontend.schemas.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"settings-hub.frontend.schemas.d.ts","sourceRoot":"","sources":["../../../../src/core/config/settings-hub.frontend.schemas.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;GAyBG;AAEH,OAAO,EAAE,oBAAoB,EAAE,MAAM,uBAAuB,CAAC;AAC7D,OAAO,KAAK,EAAE,sBAAsB,EAAE,MAAM,uBAAuB,CAAC;AACpE,OAAO,KAAK,EAAE,iCAAiC,EAAE,MAAM,mCAAmC,CAAC;AAM3F;;;;;;;GAOG;AACH,oBAAY,yBAAyB;IACnC,iEAAiE;IACjE,YAAY,iBAAiB;IAC7B,+FAA+F;IAC/F,kBAAkB,uBAAuB;IACzC,sFAAsF;IACtF,gBAAgB,qBAAqB;IACrC,0GAA0G;IAC1G,QAAQ,aAAa;CACtB;AAMD;;;;;;;;;;GAUG;AACH,oBAAY,gBAAgB;IAC1B,wGAAwG;IACxG,QAAQ,aAAa;IACrB,qEAAqE;IACrE,UAAU,eAAe;IACzB,oFAAoF;IACpF,WAAW,gBAAgB;IAC3B;;;;;;;;;;;OAWG;IACH,OAAO,YAAY;IACnB;;;;;;;;;;;OAWG;IACH,kBAAkB,uBAAuB;CAC1C;AAMD,+CAA+C;AAC/C,MAAM,WAAW,yBAAyB;IACxC,IAAI,EAAE,yBAAyB,CAAC,YAAY,CAAC;IAC7C,QAAQ,EAAE,gBAAgB,CAAC;CAC5B;AAED;;;;GAIG;AACH,MAAM,WAAW,+BAA+B;IAC9C,IAAI,EAAE,yBAAyB,CAAC,kBAAkB,CAAC;IACnD,YAAY,EAAE,MAAM,CAAC;IACrB,SAAS,EAAE,MAAM,CAAC;IAClB,gBAAgB,CAAC,EAAE,MAAM,CAAC;CAC3B;AAED,qFAAqF;AACrF,MAAM,WAAW,6BAA6B;IAC5C,IAAI,EAAE,yBAAyB,CAAC,gBAAgB,CAAC;IACjD,YAAY,EAAE,MAAM,CAAC;CACtB;AAED;;;;GAIG;AACH,MAAM,MAAM,kBAAkB,GAC1B,yBAAyB,GACzB,+BAA+B,GAC/B,6BAA6B,CAAC;AAElC;;;GAGG;AACH,MAAM,WAAW,cAAc;IAC7B,sFAAsF;IACtF,GAAG,EAAE,MAAM,CAAC;IACZ,gCAAgC;IAChC,KAAK,EAAE,MAAM,CAAC;IACd,iDAAiD;IACjD,IAAI,CAAC,EAAE,MAAM,CAAC;IACd,kEAAkE;IAClE,MAAM,EAAE,kBAAkB,CAAC;CAC5B;AAED,kFAAkF;AAClF,MAAM,WAAW,qBAAqB;IACpC,IAAI,EAAE,yBAAyB,CAAC,QAAQ,CAAC;IACzC,OAAO,EAAE,cAAc,EAAE,CAAC;CAC3B;AAED;;;GAGG;AACH,MAAM,MAAM,qBAAqB,GAAG,kBAAkB,GAAG,qBAAqB,CAAC;AAM/E;;;;;;;;;;GAUG;AACH,MAAM,WAAW,gBAAgB;IAC/B,qFAAqF;IACrF,GAAG,EAAE,MAAM,CAAC;IACZ,qCAAqC;IACrC,KAAK,EAAE,MAAM,CAAC;IACd;;;;OAIG;IACH,KAAK,CAAC,EAAE,oBAAoB,CAAC;IAC7B,8CAA8C;IAC9C,IAAI,CAAC,EAAE,MAAM,CAAC;IACd,gEAAgE;IAChE,KAAK,CAAC,EAAE,MAAM,CAAC;CAChB;AAMD,0IAA0I;AAC1I;;;;;;;;;;;;;;GAcG;AACH,MAAM,WAAW,mBAAmB;IAClC,oGAAoG;IACpG,GAAG,EAAE,MAAM,CAAC;IACZ,yDAAyD;IACzD,MAAM,EAAE,qBAAqB,CAAC;IAC9B,+EAA+E;IAC/E,mBAAmB,CAAC,EAAE,iCAAiC,CAAC;IACxD,qFAAqF;IACrF,gBAAgB,CAAC,EAAE,sBAAsB,CAAC;IAC1C,sEAAsE;IACtE,aAAa,CAAC,EAAE,MAAM,EAAE,CAAC;IACzB,iHAAiH;IACjH,oBAAoB,CAAC,EAAE,MAAM,CAAC;CAC/B;AAED;;;;;;;;;;;;;;;;GAgBG;AACH,MAAM,WAAW,iBAAiB;IAChC,6FAA6F;IAC7F,cAAc,EAAE,MAAM,CAAC;IACvB,+DAA+D;IAC/D,WAAW,EAAE,MAAM,CAAC;IACpB,uDAAuD;IACvD,KAAK,CAAC,EAAE,MAAM,CAAC;IACf,4CAA4C;IAC5C,IAAI,CAAC,EAAE,MAAM,CAAC;IACd,6EAA6E;IAC7E,KAAK,CAAC,EAAE,MAAM,CAAC;CAChB;AACD,kEAAkE;AAElE;;;;;;;;;;;;;GAaG;AACH,MAAM,WAAW,eAAe;IAC9B,+FAA+F;IAC/F,GAAG,EAAE,MAAM,CAAC;IACZ,2DAA2D;IAC3D,WAAW,EAAE,MAAM,CAAC;IACpB,6BAA6B;IAC7B,KAAK,EAAE,MAAM,CAAC;IACd,4CAA4C;IAC5C,IAAI,CAAC,EAAE,MAAM,CAAC;IACd,uDAAuD;IACvD,KAAK,CAAC,EAAE,MAAM,CAAC;IACf,qDAAqD;IACrD,MAAM,EAAE,qBAAqB,CAAC;IAC9B,+EAA+E;IAC/E,mBAAmB,CAAC,EAAE,iCAAiC,CAAC;IACxD;;;;;;;;OAQG;IACH,gBAAgB,CAAC,EAAE,sBAAsB,CAAC;IAC1C;;;;;;OAMG;IACH,aAAa,CAAC,EAAE,MAAM,EAAE,CAAC;IACzB;;;;;;;;;OASG;IACH,oBAAoB,CAAC,EAAE,MAAM,CAAC;CAC/B;AAMD,oEAAoE;AACpE;;;;;;;;;;GAUG;AACH,MAAM,WAAW,iBAAiB;IAChC,kFAAkF;IAClF,UAAU,EAAE,gBAAgB,EAAE,CAAC;IAC/B;;;;;;OAMG;IACH,UAAU,EAAE,iBAAiB,EAAE,CAAC;IAChC;;;;OAIG;IACH,iBAAiB,CAAC,EAAE,MAAM,CAAC;CAC5B;AAED;;;;;;GAMG;AACH,MAAM,WAAW,yBAAyB;IACxC,UAAU,EAAE,gBAAgB,EAAE,CAAC;IAC/B,QAAQ,EAAE,eAAe,EAAE,CAAC;IAC5B,iBAAiB,CAAC,EAAE,MAAM,CAAC;CAC5B;AACD,kEAAkE"}
+{"version":3,"file":"settings-hub.frontend.schemas.d.ts","sourceRoot":"","sources":["../../../../../src/core/config/settings-hub.frontend.schemas.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;GA0BG;AAEH,OAAO,EAAE,oBAAoB,EAAE,MAAM,uBAAuB,CAAC;AAC7D,OAAO,KAAK,EAAE,sBAAsB,EAAE,MAAM,uBAAuB,CAAC;AACpE,OAAO,KAAK,EAAE,iCAAiC,EAAE,MAAM,mCAAmC,CAAC;AAM3F,oEAAoE;AACpE;;;;;;;GAOG;AACH,oBAAY,yBAAyB;IACnC,iEAAiE;IACjE,YAAY,iBAAiB;IAC7B,+FAA+F;IAC/F,kBAAkB,uBAAuB;IACzC,sFAAsF;IACtF,gBAAgB,qBAAqB;IACrC,0GAA0G;IAC1G,QAAQ,aAAa;CACtB;AACD,kEAAkE;AAMlE;;;;;;;;;;GAUG;AACH,oBAAY,gBAAgB;IAC1B,wGAAwG;IACxG,QAAQ,aAAa;IACrB,qEAAqE;IACrE,UAAU,eAAe;IACzB,oFAAoF;IACpF,WAAW,gBAAgB;IAC3B;;;;;;;;;;;OAWG;IACH,OAAO,YAAY;IACnB;;;;;;;;;;;OAWG;IACH,kBAAkB,uBAAuB;IACzC;;;;;;;OAOG;IACH,+BAA+B,oCAAoC;CACpE;AAMD,oEAAoE;AACpE,+CAA+C;AAC/C,MAAM,WAAW,yBAAyB;IACxC,IAAI,EAAE,yBAAyB,CAAC,YAAY,CAAC;IAC7C,QAAQ,EAAE,gBAAgB,CAAC;CAC5B;AAED;;;;GAIG;AACH,MAAM,WAAW,+BAA+B;IAC9C,IAAI,EAAE,yBAAyB,CAAC,kBAAkB,CAAC;IACnD,YAAY,EAAE,MAAM,CAAC;IACrB,SAAS,EAAE,MAAM,CAAC;IAClB,gBAAgB,CAAC,EAAE,MAAM,CAAC;CAC3B;AAED,qFAAqF;AACrF,MAAM,WAAW,6BAA6B;IAC5C,IAAI,EAAE,yBAAyB,CAAC,gBAAgB,CAAC;IACjD,YAAY,EAAE,MAAM,CAAC;CACtB;AAED;;;;GAIG;AACH,MAAM,MAAM,kBAAkB,GAC1B,yBAAyB,GACzB,+BAA+B,GAC/B,6BAA6B,CAAC;AAElC;;;GAGG;AACH,MAAM,WAAW,cAAc;IAC7B,sFAAsF;IACtF,GAAG,EAAE,MAAM,CAAC;IACZ,gCAAgC;IAChC,KAAK,EAAE,MAAM,CAAC;IACd,iDAAiD;IACjD,IAAI,CAAC,EAAE,MAAM,CAAC;IACd,kEAAkE;IAClE,MAAM,EAAE,kBAAkB,CAAC;CAC5B;AAED,kFAAkF;AAClF,MAAM,WAAW,qBAAqB;IACpC,IAAI,EAAE,yBAAyB,CAAC,QAAQ,CAAC;IACzC,OAAO,EAAE,cAAc,EAAE,CAAC;CAC3B;AAED;;;GAGG;AACH,MAAM,MAAM,qBAAqB,GAAG,kBAAkB,GAAG,qBAAqB,CAAC;AAC/E,kEAAkE;AAMlE;;;;;;;;;;GAUG;AACH,MAAM,WAAW,gBAAgB;IAC/B,qFAAqF;IACrF,GAAG,EAAE,MAAM,CAAC;IACZ,qCAAqC;IACrC,KAAK,EAAE,MAAM,CAAC;IACd;;;;OAIG;IACH,KAAK,CAAC,EAAE,oBAAoB,CAAC;IAC7B,8CAA8C;IAC9C,IAAI,CAAC,EAAE,MAAM,CAAC;IACd,gEAAgE;IAChE,KAAK,CAAC,EAAE,MAAM,CAAC;CAChB;AAMD,0IAA0I;AAC1I;;;;;;;;;;;;;;;;GAgBG;AACH,MAAM,WAAW,mBAAmB;IAClC,oGAAoG;IACpG,GAAG,EAAE,MAAM,CAAC;IACZ,yDAAyD;IACzD,MAAM,EAAE,qBAAqB,CAAC;IAC9B,+EAA+E;IAC/E,mBAAmB,CAAC,EAAE,iCAAiC,CAAC;IACxD,qFAAqF;IACrF,gBAAgB,CAAC,EAAE,sBAAsB,CAAC;IAC1C,sEAAsE;IACtE,aAAa,CAAC,EAAE,MAAM,EAAE,CAAC;IACzB,iHAAiH;IACjH,oBAAoB,CAAC,EAAE,MAAM,CAAC;CAC/B;AAED;;;;;;;;;;;;;;;;GAgBG;AACH,MAAM,WAAW,iBAAiB;IAChC,8IAA8I;IAC9I,cAAc,EAAE,MAAM,CAAC;IACvB,+DAA+D;IAC/D,WAAW,EAAE,MAAM,CAAC;IACpB,uDAAuD;IACvD,KAAK,CAAC,EAAE,MAAM,CAAC;IACf,4CAA4C;IAC5C,IAAI,CAAC,EAAE,MAAM,CAAC;IACd,6EAA6E;IAC7E,KAAK,CAAC,EAAE,MAAM,CAAC;CAChB;AACD,kEAAkE;AAElE;;;;;;;;;;;;;GAaG;AACH,MAAM,WAAW,eAAe;IAC9B,+FAA+F;IAC/F,GAAG,EAAE,MAAM,CAAC;IACZ,2DAA2D;IAC3D,WAAW,EAAE,MAAM,CAAC;IACpB,6BAA6B;IAC7B,KAAK,EAAE,MAAM,CAAC;IACd,4CAA4C;IAC5C,IAAI,CAAC,EAAE,MAAM,CAAC;IACd,uDAAuD;IACvD,KAAK,CAAC,EAAE,MAAM,CAAC;IACf,qDAAqD;IACrD,MAAM,EAAE,qBAAqB,CAAC;IAC9B,+EAA+E;IAC/E,mBAAmB,CAAC,EAAE,iCAAiC,CAAC;IACxD;;;;;;;;OAQG;IACH,gBAAgB,CAAC,EAAE,sBAAsB,CAAC;IAC1C;;;;;;OAMG;IACH,aAAa,CAAC,EAAE,MAAM,EAAE,CAAC;IACzB;;;;;;;;;OASG;IACH,oBAAoB,CAAC,EAAE,MAAM,CAAC;CAC/B;AAMD,oEAAoE;AACpE;;;;;;;;;;;GAWG;AACH,MAAM,WAAW,iBAAiB;IAChC,kFAAkF;IAClF,UAAU,EAAE,gBAAgB,EAAE,CAAC;IAC/B;;;;;;OAMG;IACH,UAAU,EAAE,iBAAiB,EAAE,CAAC;IAChC;;;;;;;;;OASG;IACH,YAAY,CAAC,EAAE,mBAAmB,EAAE,CAAC;IACrC;;;;OAIG;IACH,iBAAiB,CAAC,EAAE,MAAM,CAAC;CAC5B;AAED;;;;;;GAMG;AACH,MAAM,WAAW,yBAAyB;IACxC,UAAU,EAAE,gBAAgB,EAAE,CAAC;IAC/B,QAAQ,EAAE,eAAe,EAAE,CAAC;IAC5B,iBAAiB,CAAC,EAAE,MAAM,CAAC;CAC5B;AACD,kEAAkE"}

package/dist/esm/core/config/settings-hub.frontend.schemas.js

@@ -12,8 +12,9 @@
  * - `SettingsSectionTarget` is an interface-based discriminated union on `kind`
  *   (exactly like `LauncherItemRef`), because section targets are config-time
  *   descriptors resolved by the runtime — not Zod-validated wire payloads.
- * - The framework seeds a default `SettingsHubConfig`; apps merge/extend it
- *   (same model as the sidebar/launcher config).
+ * - The engine ships DESTINATIONS (`ENGINE_SETTINGS_DESTINATIONS`) and no
+ *   arrangement; an application authors its own `SettingsHubConfig` — its
+ *   categories, its placements, and any destinations of its own.
  *
  * Runtime concerns live elsewhere:
  * - `NavigationContentType.SETTINGS_HUB` (navigation.schemas.ts) — what renders
@@ -27,6 +28,7 @@
 // ════════════════════════════════════════════════════════════════
 // Section Target Kind — discriminant for SettingsSectionTarget
 // ════════════════════════════════════════════════════════════════
+/** @wildo_source:part:start saas.frontend.settings-hub.placement */
 /**
  * What a settings section renders in its content panel.
  *
@@ -46,6 +48,7 @@ export var SettingsSectionTargetKind;
     /** A section that itself splits into horizontal sub-tabs (e.g. Teams → Members / Roles & Permissions). */
     SettingsSectionTargetKind["SUB_TABS"] = "sub_tabs";
 })(SettingsSectionTargetKind || (SettingsSectionTargetKind = {}));
+/** @wildo_source:part:end saas.frontend.settings-hub.placement */
 // ════════════════════════════════════════════════════════════════
 // Engine Panel Ref — framework-owned bespoke settings panels
 // ════════════════════════════════════════════════════════════════
@@ -94,6 +97,15 @@ export var SettingsPanelRef;
      * the list answers what IS, and the empty answer to the second is exactly when the first matters.
      */
     SettingsPanelRef["CONNECTED_ACCOUNTS"] = "connected-accounts";
+    /**
+     * The same act at the TENANT's scope: connecting an account the whole organization acts as.
+     *
+     * A distinct ref rather than a parameterised one, because a settings destination resolves a ref to
+     * a panel and carries no arguments — and because the two must never be reachable from each other's
+     * screen. The component behind them IS shared: the act is identical, and duplicating it would
+     * guarantee the two drift. What is never shared is the data.
+     */
+    SettingsPanelRef["ORGANIZATION_CONNECTED_ACCOUNTS"] = "organization-connected-accounts";
 })(SettingsPanelRef || (SettingsPanelRef = {}));
 /** @wildo_source:part:end saas.frontend.settings-hub.placement */
 //# sourceMappingURL=settings-hub.frontend.schemas.js.map

package/dist/esm/core/config/settings-hub.frontend.schemas.js.map

@@ -1 +1 @@
-{"version":3,"file":"settings-hub.frontend.schemas.js","sourceRoot":"","sources":["../../../../src/core/config/settings-hub.frontend.schemas.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;GAyBG;AAMH,mEAAmE;AACnE,+DAA+D;AAC/D,mEAAmE;AAEnE;;;;;;;GAOG;AACH,MAAM,CAAN,IAAY,yBASX;AATD,WAAY,yBAAyB;IACnC,iEAAiE;IACjE,0DAA6B,CAAA;IAC7B,+FAA+F;IAC/F,sEAAyC,CAAA;IACzC,sFAAsF;IACtF,kEAAqC,CAAA;IACrC,0GAA0G;IAC1G,kDAAqB,CAAA;AACvB,CAAC,EATW,yBAAyB,KAAzB,yBAAyB,QASpC;AAED,mEAAmE;AACnE,6DAA6D;AAC7D,mEAAmE;AAEnE;;;;;;;;;;GAUG;AACH,MAAM,CAAN,IAAY,gBAiCX;AAjCD,WAAY,gBAAgB;IAC1B,wGAAwG;IACxG,yCAAqB,CAAA;IACrB,qEAAqE;IACrE,6CAAyB,CAAA;IACzB,oFAAoF;IACpF,+CAA2B,CAAA;IAC3B;;;;;;;;;;;OAWG;IACH,uCAAmB,CAAA;IACnB;;;;;;;;;;;OAWG;IACH,6DAAyC,CAAA;AAC3C,CAAC,EAjCW,gBAAgB,KAAhB,gBAAgB,QAiC3B;AAgRD,kEAAkE","sourcesContent":["/**\n * Settings Hub — Declarative Section Registry\n *\n * The Settings Hub is the framework's single point of configuration: one overlay\n * surface that consolidates every settings destination (account, security,\n * appearance, organization, members, billing, …) behind a vertical `Tabs` rail\n * grouped by category. Many entry points (user dropdown, sidebar, command menu)\n * all converge on this one hub; links differ only by which section they pre-open.\n *\n * This file owns the **config-time** registry contract. It is declaration-first\n * and mirrors `launcher-items.frontend.schemas.ts`:\n * - `SettingsSectionTarget` is an interface-based discriminated union on `kind`\n *   (exactly like `LauncherItemRef`), because section targets are config-time\n *   descriptors resolved by the runtime — not Zod-validated wire payloads.\n * - The framework seeds a default `SettingsHubConfig`; apps merge/extend it\n *   (same model as the sidebar/launcher config).\n *\n * Runtime concerns live elsewhere:\n * - `NavigationContentType.SETTINGS_HUB` (navigation.schemas.ts) — what renders\n *   in the overlay zone.\n * - `SettingsHub` component (components/settings/) — resolves a section's target\n *   to a rendered panel.\n *\n * @see launcher-items.frontend.schemas.ts — the sibling launcher registry this mirrors\n * @see .claude/plans/unified-settings-hub.md — design + layer trace\n */\n\nimport { ResourcePrimaryScope } from '@wildo-ai/saas-models';\nimport type { RequiredFeaturesConfig } from '@wildo-ai/saas-models';\nimport type { LauncherRuntimeAvailabilityConfig } from './launcher-items.frontend.schemas';\n\n// ════════════════════════════════════════════════════════════════\n// Section Target Kind — discriminant for SettingsSectionTarget\n// ════════════════════════════════════════════════════════════════\n\n/**\n * What a settings section renders in its content panel.\n *\n * Discriminant for the `SettingsSectionTarget` union. The default for\n * data-backed settings is `RESOURCE_OPERATION` (reuse the auto-rendered\n * resource surface); `ENGINE_PANEL` is reserved for the few sections whose\n * bespoke layout earns it (Security, Appearance).\n */\nexport enum SettingsSectionTargetKind {\n  /** A framework-owned bespoke panel (Security, Appearance, …). */\n  ENGINE_PANEL = 'engine_panel',\n  /** An auto-rendered resource-operation surface (members, API tokens, billing, preferences). */\n  RESOURCE_OPERATION = 'resource_operation',\n  /** An app-registered custom React component (resolved via the component registry). */\n  CUSTOM_COMPONENT = 'custom_component',\n  /** A section that itself splits into horizontal sub-tabs (e.g. Teams → Members / Roles & Permissions). */\n  SUB_TABS = 'sub_tabs',\n}\n\n// ════════════════════════════════════════════════════════════════\n// Engine Panel Ref — framework-owned bespoke settings panels\n// ════════════════════════════════════════════════════════════════\n\n/**\n * Framework-provided settings panels with bespoke (non-CRUD) layout.\n *\n * Closed enum — only framework panels belong here. Most settings sections should\n * be `RESOURCE_OPERATION` targets instead; a panel earns a slot here only when a\n * standard resource surface cannot express it (multi-factor enrollment flows,\n * theme/dark-mode toggles, …).\n *\n * The runtime maps each ref to a registered panel component in the\n * `SettingsHub` resolver.\n */\nexport enum SettingsPanelRef {\n  /** Password, MFA enrollment, passkeys, identity links (wraps the former `AppPage_SecuritySettings`). */\n  SECURITY = 'security',\n  /** Theme, dark-mode, density and other look-and-feel preferences. */\n  APPEARANCE = 'appearance',\n  /** The caller's own pending org invitations — accept/reject in-app (Approach P). */\n  INVITATIONS = 'invitations',\n  /**\n   * The billing home: subscription status, plan catalog + checkout, usage,\n   * invoices and the provider portal link — composed from the BillingContext\n   * aggregated state (`GET_STATE`), NOT from per-resource LIST surfaces.\n   *\n   * Bespoke on purpose: the billing child resources (subscriptions, invoice\n   * refs, usage records) are routed UNDER the billing account\n   * (`REQUIRES_CONTEXT`), so a generic org-scoped `RESOURCE_OPERATION` panel\n   * cannot build their URLs. The aggregated billing state is org-addressable\n   * and auto-creates the account, which makes it the correct settings-surface\n   * data source.\n   */\n  BILLING = 'billing',\n  /**\n   * Where a person CONNECTS one of their own third-party accounts.\n   *\n   * Bespoke because connecting is not a row somebody creates: it is a flow that leaves the\n   * application, obtains consent at a vendor, and returns with a grant nobody typed. The generic\n   * resource surface can list, inspect and delete the resulting credentials perfectly — it simply has\n   * no mechanism for an ACTION of that shape, which is why the whole outbound-authorization lane had\n   * no surface that could begin it until this existed.\n   *\n   * Paired with, never replacing, the credential list: this panel answers what MAY be connected and\n   * the list answers what IS, and the empty answer to the second is exactly when the first matters.\n   */\n  CONNECTED_ACCOUNTS = 'connected-accounts',\n}\n\n// ════════════════════════════════════════════════════════════════\n// Section Target — discriminated union on `kind`\n// ════════════════════════════════════════════════════════════════\n\n/** Renders a framework-owned bespoke panel. */\nexport interface SettingsEnginePanelTarget {\n  kind: SettingsSectionTargetKind.ENGINE_PANEL;\n  panelRef: SettingsPanelRef;\n}\n\n/**\n * Renders an auto-generated resource-operation surface inside the section panel.\n * Resolved against the resource registry exactly like a launcher\n * `RESOURCE_OPERATION` target.\n */\nexport interface SettingsResourceOperationTarget {\n  kind: SettingsSectionTargetKind.RESOURCE_OPERATION;\n  resourceType: string;\n  operation: string;\n  operationVariant?: string;\n}\n\n/** Renders an app-registered custom React component (resolved by `componentRef`). */\nexport interface SettingsCustomComponentTarget {\n  kind: SettingsSectionTargetKind.CUSTOM_COMPONENT;\n  componentRef: string;\n}\n\n/**\n * Leaf targets renderable directly in a panel. Sub-tabs may only point at leaf\n * targets — sub-tabs cannot nest further sub-tabs (one level of in-section\n * tabbing, matching the BetterStack reference).\n */\nexport type SettingsLeafTarget =\n  | SettingsEnginePanelTarget\n  | SettingsResourceOperationTarget\n  | SettingsCustomComponentTarget;\n\n/**\n * One horizontal sub-tab within a section (e.g. the \"Members\" / \"Roles &\n * Permissions\" tabs inside a Teams section).\n */\nexport interface SettingsSubTab {\n  /** Sub-tab reference — app-defined, used for i18n + the `value` of the inner Tabs. */\n  ref: string;\n  /** Display label (i18n ref). */\n  label: string;\n  /** Optional icon ref for the sub-tab trigger. */\n  icon?: string;\n  /** What this sub-tab renders. Sub-tabs hold leaf targets only. */\n  target: SettingsLeafTarget;\n}\n\n/** Splits a section into horizontal sub-tabs rendered above the panel content. */\nexport interface SettingsSubTabsTarget {\n  kind: SettingsSectionTargetKind.SUB_TABS;\n  subTabs: SettingsSubTab[];\n}\n\n/**\n * What a settings section renders. Discriminated on `kind`; the `SettingsHub`\n * resolver dispatches on it to produce the panel content.\n */\nexport type SettingsSectionTarget = SettingsLeafTarget | SettingsSubTabsTarget;\n\n// ════════════════════════════════════════════════════════════════\n// Category — the rail group\n// ════════════════════════════════════════════════════════════════\n\n/**\n * A category groups sections in the vertical rail (the `Account` / `Organization`\n * group headers in the BetterStack reference). Rendered as a label + separator\n * inside the `TabsList` — NOT a separate nav widget (the `Tabs` primitive stays\n * the section mechanism).\n *\n * `scope` ties the category to a primary-scope axis so the runtime can hide it\n * when the scope is unavailable — e.g. an `ORGANIZATIONS` category is hidden when\n * no organization is selected. It is derived against `AppScope`, not authored\n * per-user.\n */\nexport interface SettingsCategory {\n  /** Category reference — app-defined, referenced by `SettingsSection.categoryRef`. */\n  ref: string;\n  /** Group header label (i18n ref). */\n  label: string;\n  /**\n   * Primary scope this category belongs to. Drives rail grouping order and\n   * scope-gated visibility (org categories hide when no org is selected).\n   * Omit for a scope-agnostic category.\n   */\n  scope?: ResourcePrimaryScope;\n  /** Optional icon ref for the group header. */\n  icon?: string;\n  /** Sort order among categories in the rail (lower = higher). */\n  order?: number;\n}\n\n// ════════════════════════════════════════════════════════════════\n// Section — one vertical tab in the rail\n// ════════════════════════════════════════════════════════════════\n\n/** @wildo_source:part:start saas.frontend.settings-hub.placement facet:layer:frontend facet:family:config facet:audience:app-developer */\n/**\n * An addressable settings DESTINATION — what a settings surface *is*, with no\n * opinion on where it appears.\n *\n * This is the half the engine ships (`ENGINE_SETTINGS_DESTINATIONS`). It carries\n * the target and the gating stack, and deliberately carries **no `categoryRef`,\n * no `order` and no `label`**: those are placement, and placement is the\n * application's decision (`SettingsPlacement`).\n *\n * The split exists because the engine shipping a PLACED hub is what made the\n * settings rail unauthorable — an application could not add, remove, reorder or\n * rename a section without the framework agreeing. Splitting destination from\n * placement lets the engine keep owning what a destination MEANS (its target,\n * its roles, its entitlement) while the application owns where it sits.\n */\nexport interface SettingsDestination {\n  /** Destination reference — the `/settings/:sectionRef` URL segment and the id a placement names. */\n  ref: string;\n  /** What the destination renders in its content panel. */\n  target: SettingsSectionTarget;\n  /** Declarative runtime capability gating (same contract as launcher items). */\n  runtimeAvailability?: LauncherRuntimeAvailabilityConfig;\n  /** Feature flags required to surface this destination (plan/subscription gating). */\n  requiredFeatures?: RequiredFeaturesConfig;\n  /** RBAC roles required to surface this destination (OR semantics). */\n  requiredRoles?: string[];\n  /** Optional CoreFeature id this destination's content is ENTITLED by (soft gate — renders an upgrade prompt). */\n  entitlementFeatureId?: string;\n}\n\n/**\n * An application's explicit PLACEMENT of one destination in its settings rail.\n *\n * Authored in the application's own config. Nothing is placed implicitly: a\n * destination the application does not place does not render, which is the whole\n * point — \"we should just place things\", with no automatic inference.\n *\n * `label` is optional and is an OVERRIDE. The resolved label otherwise comes from\n * the `settings_hub.sections.<ref>.label` key, so a placed section is localizable\n * without the application authoring an English string.\n *\n * That namespace and its resolver (`tSettingsHubSection`) EXIST and already fall\n * back to the authored label. What does not exist is anything that generates the\n * units: `LabellingTypes.SETTINGS_HUB` is declared with an empty pattern and the\n * companion plans nothing for it, so today every rail label is the authored\n * English string. R9 is a wiring job, not a new mechanism.\n */\nexport interface SettingsPlacement {\n  /** The {@link SettingsDestination.ref} being placed. Refused at DEV startup when unknown. */\n  destinationRef: string;\n  /** Which category (rail group) this destination sits under. */\n  categoryRef: string;\n  /** Sort order within the category (lower = higher). */\n  order?: number;\n  /** Optional icon ref for the rail entry. */\n  icon?: string;\n  /** Rail label override. Omit to take `settings_hub.sections.<ref>.label`. */\n  label?: string;\n}\n/** @wildo_source:part:end saas.frontend.settings-hub.placement */\n\n/**\n * A settings section is one entry in the vertical rail (one `TabsTrigger`) —\n * the RESOLVED union of a {@link SettingsDestination} and the\n * {@link SettingsPlacement} that placed it.\n *\n * Produced by `resolveSettingsHubConfig()`; never authored directly. It\n * belongs to a category, addresses a target, and reuses the existing launcher\n * gating stack:\n * - `runtimeAvailability` — survives the app-shell filtering pass (capabilities).\n * - `requiredFeatures` — plan/subscription gating once resolved.\n * - `requiredRoles` — RBAC gating (e.g. org-admin-only sections).\n *\n * `ref` is the URL-addressable section id (`/settings/:sectionRef`).\n */\nexport interface SettingsSection {\n  /** Section reference — app-defined; the `/settings/:sectionRef` URL segment + Tabs `value`. */\n  ref: string;\n  /** Which category (rail group) this section sits under. */\n  categoryRef: string;\n  /** Rail label (i18n ref). */\n  label: string;\n  /** Optional icon ref for the rail entry. */\n  icon?: string;\n  /** Sort order within the category (lower = higher). */\n  order?: number;\n  /** What the section renders in its content panel. */\n  target: SettingsSectionTarget;\n  /** Declarative runtime capability gating (same contract as launcher items). */\n  runtimeAvailability?: LauncherRuntimeAvailabilityConfig;\n  /**\n   * Feature flags required to surface this section (plan/subscription gating).\n   *\n   * Uses the framework-canonical {@link RequiredFeaturesConfig} contract shared\n   * with views and resource operations — shorthand `string[]` (OR semantics) or\n   * the full `{ features, mode: 'OR' | 'AND' }` form. `limitChecks` are not\n   * evaluated for section visibility (a section is shown or hidden, never\n   * \"over-limit\"); use {@link requiredRoles} / capabilities for hard gating.\n   */\n  requiredFeatures?: RequiredFeaturesConfig;\n  /**\n   * RBAC roles required to surface this section (OR semantics — the user needs\n   * ANY one of these roles). Evaluated against the merged app-level + current-\n   * organization role set, the same effective surface the rest of the frontend\n   * gating layer resolves (see `buildFeaturePolicyRoles`). Org-management\n   * sections gate on `[CORE_ORG_ROLES.ORG_OWNER, CORE_ORG_ROLES.ORG_ADMIN]`.\n   */\n  requiredRoles?: string[];\n  /**\n   * Optional CoreFeature id this section's content is ENTITLED by. Distinct from\n   * {@link requiredFeatures} (a HARD hide-gate): when set, the section still\n   * SURVIVES (per `runtimeAvailability`/roles) and its body is wrapped in a\n   * `FeatureGate` so an OFFERED-but-not-yet-entitled feature renders the\n   * policy-driven upgrade/add-on prompt (`unavailabilityPolicy`) instead of\n   * vanishing. Pair with a `runtimeAvailability.requiredCapabilities` gate whose\n   * capability is the plan-independent \"app offers X\" signal, so a feature the\n   * app does NOT offer at all is hidden outright while an offered one prompts.\n   */\n  entitlementFeatureId?: string;\n}\n\n// ════════════════════════════════════════════════════════════════\n// Hub Config — the registry root\n// ════════════════════════════════════════════════════════════════\n\n/** @wildo_source:part:start saas.frontend.settings-hub.placement */\n/**\n * The AUTHORED Settings Hub registry — an application's own settings rail.\n *\n * The framework ships destinations (`ENGINE_SETTINGS_DESTINATIONS`), never a\n * placed hub. This is the application's half: which categories exist, and which\n * destinations are placed where. `wildo init` scaffolds the full destination list\n * as placements so a new application starts complete and edits down.\n *\n * Resolve it with `resolveSettingsHubConfig()` to get the rendered\n * {@link SettingsSection} list; the render path never reads this shape directly.\n */\nexport interface SettingsHubConfig {\n  /** Rail groups, in render order (also orderable via `SettingsCategory.order`). */\n  categories: SettingsCategory[];\n  /**\n   * Every destination this application places, and where.\n   *\n   * A destination that appears in no placement does not render. That is\n   * deliberate: absence is how an application removes a settings section, and it\n   * must not be second-guessed by a merge against a framework default.\n   */\n  placements: SettingsPlacement[];\n  /**\n   * Section opened when the hub is launched without an explicit section\n   * (`/settings` with no `:sectionRef`). Falls back to the first section of the\n   * first category when omitted.\n   */\n  defaultSectionRef?: string;\n}\n\n/**\n * The RESOLVED hub — categories plus fully-resolved sections, ready to render.\n *\n * Distinct from {@link SettingsHubConfig} (what an application AUTHORS) because\n * conflating the two is what let a placed default ship from the engine. A\n * consumer that renders takes this; a consumer that configures takes the other.\n */\nexport interface ResolvedSettingsHubConfig {\n  categories: SettingsCategory[];\n  sections: SettingsSection[];\n  defaultSectionRef?: string;\n}\n/** @wildo_source:part:end saas.frontend.settings-hub.placement */\n"]}
+{"version":3,"file":"settings-hub.frontend.schemas.js","sourceRoot":"","sources":["../../../../../src/core/config/settings-hub.frontend.schemas.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;GA0BG;AAMH,mEAAmE;AACnE,+DAA+D;AAC/D,mEAAmE;AAEnE,oEAAoE;AACpE;;;;;;;GAOG;AACH,MAAM,CAAN,IAAY,yBASX;AATD,WAAY,yBAAyB;IACnC,iEAAiE;IACjE,0DAA6B,CAAA;IAC7B,+FAA+F;IAC/F,sEAAyC,CAAA;IACzC,sFAAsF;IACtF,kEAAqC,CAAA;IACrC,0GAA0G;IAC1G,kDAAqB,CAAA;AACvB,CAAC,EATW,yBAAyB,KAAzB,yBAAyB,QASpC;AACD,kEAAkE;AAElE,mEAAmE;AACnE,6DAA6D;AAC7D,mEAAmE;AAEnE;;;;;;;;;;GAUG;AACH,MAAM,CAAN,IAAY,gBA0CX;AA1CD,WAAY,gBAAgB;IAC1B,wGAAwG;IACxG,yCAAqB,CAAA;IACrB,qEAAqE;IACrE,6CAAyB,CAAA;IACzB,oFAAoF;IACpF,+CAA2B,CAAA;IAC3B;;;;;;;;;;;OAWG;IACH,uCAAmB,CAAA;IACnB;;;;;;;;;;;OAWG;IACH,6DAAyC,CAAA;IACzC;;;;;;;OAOG;IACH,uFAAmE,CAAA;AACrE,CAAC,EA1CW,gBAAgB,KAAhB,gBAAgB,QA0C3B;AAgSD,kEAAkE","sourcesContent":["/**\n * Settings Hub — Declarative Section Registry\n *\n * The Settings Hub is the framework's single point of configuration: one overlay\n * surface that consolidates every settings destination (account, security,\n * appearance, organization, members, billing, …) behind a vertical `Tabs` rail\n * grouped by category. Many entry points (user dropdown, sidebar, command menu)\n * all converge on this one hub; links differ only by which section they pre-open.\n *\n * This file owns the **config-time** registry contract. It is declaration-first\n * and mirrors `launcher-items.frontend.schemas.ts`:\n * - `SettingsSectionTarget` is an interface-based discriminated union on `kind`\n *   (exactly like `LauncherItemRef`), because section targets are config-time\n *   descriptors resolved by the runtime — not Zod-validated wire payloads.\n * - The engine ships DESTINATIONS (`ENGINE_SETTINGS_DESTINATIONS`) and no\n *   arrangement; an application authors its own `SettingsHubConfig` — its\n *   categories, its placements, and any destinations of its own.\n *\n * Runtime concerns live elsewhere:\n * - `NavigationContentType.SETTINGS_HUB` (navigation.schemas.ts) — what renders\n *   in the overlay zone.\n * - `SettingsHub` component (components/settings/) — resolves a section's target\n *   to a rendered panel.\n *\n * @see launcher-items.frontend.schemas.ts — the sibling launcher registry this mirrors\n * @see .claude/plans/unified-settings-hub.md — design + layer trace\n */\n\nimport { ResourcePrimaryScope } from '@wildo-ai/saas-models';\nimport type { RequiredFeaturesConfig } from '@wildo-ai/saas-models';\nimport type { LauncherRuntimeAvailabilityConfig } from './launcher-items.frontend.schemas';\n\n// ════════════════════════════════════════════════════════════════\n// Section Target Kind — discriminant for SettingsSectionTarget\n// ════════════════════════════════════════════════════════════════\n\n/** @wildo_source:part:start saas.frontend.settings-hub.placement */\n/**\n * What a settings section renders in its content panel.\n *\n * Discriminant for the `SettingsSectionTarget` union. The default for\n * data-backed settings is `RESOURCE_OPERATION` (reuse the auto-rendered\n * resource surface); `ENGINE_PANEL` is reserved for the few sections whose\n * bespoke layout earns it (Security, Appearance).\n */\nexport enum SettingsSectionTargetKind {\n  /** A framework-owned bespoke panel (Security, Appearance, …). */\n  ENGINE_PANEL = 'engine_panel',\n  /** An auto-rendered resource-operation surface (members, API tokens, billing, preferences). */\n  RESOURCE_OPERATION = 'resource_operation',\n  /** An app-registered custom React component (resolved via the component registry). */\n  CUSTOM_COMPONENT = 'custom_component',\n  /** A section that itself splits into horizontal sub-tabs (e.g. Teams → Members / Roles & Permissions). */\n  SUB_TABS = 'sub_tabs',\n}\n/** @wildo_source:part:end saas.frontend.settings-hub.placement */\n\n// ════════════════════════════════════════════════════════════════\n// Engine Panel Ref — framework-owned bespoke settings panels\n// ════════════════════════════════════════════════════════════════\n\n/**\n * Framework-provided settings panels with bespoke (non-CRUD) layout.\n *\n * Closed enum — only framework panels belong here. Most settings sections should\n * be `RESOURCE_OPERATION` targets instead; a panel earns a slot here only when a\n * standard resource surface cannot express it (multi-factor enrollment flows,\n * theme/dark-mode toggles, …).\n *\n * The runtime maps each ref to a registered panel component in the\n * `SettingsHub` resolver.\n */\nexport enum SettingsPanelRef {\n  /** Password, MFA enrollment, passkeys, identity links (wraps the former `AppPage_SecuritySettings`). */\n  SECURITY = 'security',\n  /** Theme, dark-mode, density and other look-and-feel preferences. */\n  APPEARANCE = 'appearance',\n  /** The caller's own pending org invitations — accept/reject in-app (Approach P). */\n  INVITATIONS = 'invitations',\n  /**\n   * The billing home: subscription status, plan catalog + checkout, usage,\n   * invoices and the provider portal link — composed from the BillingContext\n   * aggregated state (`GET_STATE`), NOT from per-resource LIST surfaces.\n   *\n   * Bespoke on purpose: the billing child resources (subscriptions, invoice\n   * refs, usage records) are routed UNDER the billing account\n   * (`REQUIRES_CONTEXT`), so a generic org-scoped `RESOURCE_OPERATION` panel\n   * cannot build their URLs. The aggregated billing state is org-addressable\n   * and auto-creates the account, which makes it the correct settings-surface\n   * data source.\n   */\n  BILLING = 'billing',\n  /**\n   * Where a person CONNECTS one of their own third-party accounts.\n   *\n   * Bespoke because connecting is not a row somebody creates: it is a flow that leaves the\n   * application, obtains consent at a vendor, and returns with a grant nobody typed. The generic\n   * resource surface can list, inspect and delete the resulting credentials perfectly — it simply has\n   * no mechanism for an ACTION of that shape, which is why the whole outbound-authorization lane had\n   * no surface that could begin it until this existed.\n   *\n   * Paired with, never replacing, the credential list: this panel answers what MAY be connected and\n   * the list answers what IS, and the empty answer to the second is exactly when the first matters.\n   */\n  CONNECTED_ACCOUNTS = 'connected-accounts',\n  /**\n   * The same act at the TENANT's scope: connecting an account the whole organization acts as.\n   *\n   * A distinct ref rather than a parameterised one, because a settings destination resolves a ref to\n   * a panel and carries no arguments — and because the two must never be reachable from each other's\n   * screen. The component behind them IS shared: the act is identical, and duplicating it would\n   * guarantee the two drift. What is never shared is the data.\n   */\n  ORGANIZATION_CONNECTED_ACCOUNTS = 'organization-connected-accounts',\n}\n\n// ════════════════════════════════════════════════════════════════\n// Section Target — discriminated union on `kind`\n// ════════════════════════════════════════════════════════════════\n\n/** @wildo_source:part:start saas.frontend.settings-hub.placement */\n/** Renders a framework-owned bespoke panel. */\nexport interface SettingsEnginePanelTarget {\n  kind: SettingsSectionTargetKind.ENGINE_PANEL;\n  panelRef: SettingsPanelRef;\n}\n\n/**\n * Renders an auto-generated resource-operation surface inside the section panel.\n * Resolved against the resource registry exactly like a launcher\n * `RESOURCE_OPERATION` target.\n */\nexport interface SettingsResourceOperationTarget {\n  kind: SettingsSectionTargetKind.RESOURCE_OPERATION;\n  resourceType: string;\n  operation: string;\n  operationVariant?: string;\n}\n\n/** Renders an app-registered custom React component (resolved by `componentRef`). */\nexport interface SettingsCustomComponentTarget {\n  kind: SettingsSectionTargetKind.CUSTOM_COMPONENT;\n  componentRef: string;\n}\n\n/**\n * Leaf targets renderable directly in a panel. Sub-tabs may only point at leaf\n * targets — sub-tabs cannot nest further sub-tabs (one level of in-section\n * tabbing, matching the BetterStack reference).\n */\nexport type SettingsLeafTarget =\n  | SettingsEnginePanelTarget\n  | SettingsResourceOperationTarget\n  | SettingsCustomComponentTarget;\n\n/**\n * One horizontal sub-tab within a section (e.g. the \"Members\" / \"Roles &\n * Permissions\" tabs inside a Teams section).\n */\nexport interface SettingsSubTab {\n  /** Sub-tab reference — app-defined, used for i18n + the `value` of the inner Tabs. */\n  ref: string;\n  /** Display label (i18n ref). */\n  label: string;\n  /** Optional icon ref for the sub-tab trigger. */\n  icon?: string;\n  /** What this sub-tab renders. Sub-tabs hold leaf targets only. */\n  target: SettingsLeafTarget;\n}\n\n/** Splits a section into horizontal sub-tabs rendered above the panel content. */\nexport interface SettingsSubTabsTarget {\n  kind: SettingsSectionTargetKind.SUB_TABS;\n  subTabs: SettingsSubTab[];\n}\n\n/**\n * What a settings section renders. Discriminated on `kind`; the `SettingsHub`\n * resolver dispatches on it to produce the panel content.\n */\nexport type SettingsSectionTarget = SettingsLeafTarget | SettingsSubTabsTarget;\n/** @wildo_source:part:end saas.frontend.settings-hub.placement */\n\n// ════════════════════════════════════════════════════════════════\n// Category — the rail group\n// ════════════════════════════════════════════════════════════════\n\n/**\n * A category groups sections in the vertical rail (the `Account` / `Organization`\n * group headers in the BetterStack reference). Rendered as a label + separator\n * inside the `TabsList` — NOT a separate nav widget (the `Tabs` primitive stays\n * the section mechanism).\n *\n * `scope` ties the category to a primary-scope axis so the runtime can hide it\n * when the scope is unavailable — e.g. an `ORGANIZATIONS` category is hidden when\n * no organization is selected. It is derived against `AppScope`, not authored\n * per-user.\n */\nexport interface SettingsCategory {\n  /** Category reference — app-defined, referenced by `SettingsSection.categoryRef`. */\n  ref: string;\n  /** Group header label (i18n ref). */\n  label: string;\n  /**\n   * Primary scope this category belongs to. Drives rail grouping order and\n   * scope-gated visibility (org categories hide when no org is selected).\n   * Omit for a scope-agnostic category.\n   */\n  scope?: ResourcePrimaryScope;\n  /** Optional icon ref for the group header. */\n  icon?: string;\n  /** Sort order among categories in the rail (lower = higher). */\n  order?: number;\n}\n\n// ════════════════════════════════════════════════════════════════\n// Section — one vertical tab in the rail\n// ════════════════════════════════════════════════════════════════\n\n/** @wildo_source:part:start saas.frontend.settings-hub.placement facet:layer:frontend facet:family:config facet:audience:app-developer */\n/**\n * An addressable settings DESTINATION — what a settings surface *is*, with no\n * opinion on where it appears.\n *\n * The engine ships most of them (`ENGINE_SETTINGS_DESTINATIONS`); an application\n * may declare its own in `SettingsHubConfig.destinations` — a settings surface for\n * one of its OWN resources, or a component it registers. Either way a destination\n * carries the target and the gating stack, and deliberately carries **no\n * `categoryRef`, no `order` and no `label`**: those are placement, and placement is\n * the application's decision (`SettingsPlacement`).\n *\n * The split exists because the engine shipping a PLACED hub is what made the\n * settings rail unauthorable — an application could not add, remove, reorder or\n * rename a section without the framework agreeing. Splitting destination from\n * placement lets the engine keep owning what a destination MEANS (its target,\n * its roles, its entitlement) while the application owns where it sits.\n */\nexport interface SettingsDestination {\n  /** Destination reference — the `/settings/:sectionRef` URL segment and the id a placement names. */\n  ref: string;\n  /** What the destination renders in its content panel. */\n  target: SettingsSectionTarget;\n  /** Declarative runtime capability gating (same contract as launcher items). */\n  runtimeAvailability?: LauncherRuntimeAvailabilityConfig;\n  /** Feature flags required to surface this destination (plan/subscription gating). */\n  requiredFeatures?: RequiredFeaturesConfig;\n  /** RBAC roles required to surface this destination (OR semantics). */\n  requiredRoles?: string[];\n  /** Optional CoreFeature id this destination's content is ENTITLED by (soft gate — renders an upgrade prompt). */\n  entitlementFeatureId?: string;\n}\n\n/**\n * An application's explicit PLACEMENT of one destination in its settings rail.\n *\n * Authored in the application's own config. Nothing is placed implicitly: a\n * destination the application does not place does not render, which is the whole\n * point — \"we should just place things\", with no automatic inference.\n *\n * `label` is optional and is an OVERRIDE. The resolved label otherwise comes from\n * the `settings_hub.sections.<ref>.label` key, so a placed section is localizable\n * without the application authoring an English string.\n *\n * That namespace and its resolver (`tSettingsHubSection`) EXIST and already fall\n * back to the authored label. What does not exist is anything that generates the\n * units: `LabellingTypes.SETTINGS_HUB` is declared with an empty pattern and the\n * companion plans nothing for it, so today every rail label is the authored\n * English string. R9 is a wiring job, not a new mechanism.\n */\nexport interface SettingsPlacement {\n  /** The {@link SettingsDestination.ref} being placed — an engine destination or one of `destinations`. Refused at DEV startup when unknown. */\n  destinationRef: string;\n  /** Which category (rail group) this destination sits under. */\n  categoryRef: string;\n  /** Sort order within the category (lower = higher). */\n  order?: number;\n  /** Optional icon ref for the rail entry. */\n  icon?: string;\n  /** Rail label override. Omit to take `settings_hub.sections.<ref>.label`. */\n  label?: string;\n}\n/** @wildo_source:part:end saas.frontend.settings-hub.placement */\n\n/**\n * A settings section is one entry in the vertical rail (one `TabsTrigger`) —\n * the RESOLVED union of a {@link SettingsDestination} and the\n * {@link SettingsPlacement} that placed it.\n *\n * Produced by `resolveSettingsHubConfig()`; never authored directly. It\n * belongs to a category, addresses a target, and reuses the existing launcher\n * gating stack:\n * - `runtimeAvailability` — survives the app-shell filtering pass (capabilities).\n * - `requiredFeatures` — plan/subscription gating once resolved.\n * - `requiredRoles` — RBAC gating (e.g. org-admin-only sections).\n *\n * `ref` is the URL-addressable section id (`/settings/:sectionRef`).\n */\nexport interface SettingsSection {\n  /** Section reference — app-defined; the `/settings/:sectionRef` URL segment + Tabs `value`. */\n  ref: string;\n  /** Which category (rail group) this section sits under. */\n  categoryRef: string;\n  /** Rail label (i18n ref). */\n  label: string;\n  /** Optional icon ref for the rail entry. */\n  icon?: string;\n  /** Sort order within the category (lower = higher). */\n  order?: number;\n  /** What the section renders in its content panel. */\n  target: SettingsSectionTarget;\n  /** Declarative runtime capability gating (same contract as launcher items). */\n  runtimeAvailability?: LauncherRuntimeAvailabilityConfig;\n  /**\n   * Feature flags required to surface this section (plan/subscription gating).\n   *\n   * Uses the framework-canonical {@link RequiredFeaturesConfig} contract shared\n   * with views and resource operations — shorthand `string[]` (OR semantics) or\n   * the full `{ features, mode: 'OR' | 'AND' }` form. `limitChecks` are not\n   * evaluated for section visibility (a section is shown or hidden, never\n   * \"over-limit\"); use {@link requiredRoles} / capabilities for hard gating.\n   */\n  requiredFeatures?: RequiredFeaturesConfig;\n  /**\n   * RBAC roles required to surface this section (OR semantics — the user needs\n   * ANY one of these roles). Evaluated against the merged app-level + current-\n   * organization role set, the same effective surface the rest of the frontend\n   * gating layer resolves (see `buildFeaturePolicyRoles`). Org-management\n   * sections gate on `[CORE_ORG_ROLES.ORG_OWNER, CORE_ORG_ROLES.ORG_ADMIN]`.\n   */\n  requiredRoles?: string[];\n  /**\n   * Optional CoreFeature id this section's content is ENTITLED by. Distinct from\n   * {@link requiredFeatures} (a HARD hide-gate): when set, the section still\n   * SURVIVES (per `runtimeAvailability`/roles) and its body is wrapped in a\n   * `FeatureGate` so an OFFERED-but-not-yet-entitled feature renders the\n   * policy-driven upgrade/add-on prompt (`unavailabilityPolicy`) instead of\n   * vanishing. Pair with a `runtimeAvailability.requiredCapabilities` gate whose\n   * capability is the plan-independent \"app offers X\" signal, so a feature the\n   * app does NOT offer at all is hidden outright while an offered one prompts.\n   */\n  entitlementFeatureId?: string;\n}\n\n// ════════════════════════════════════════════════════════════════\n// Hub Config — the registry root\n// ════════════════════════════════════════════════════════════════\n\n/** @wildo_source:part:start saas.frontend.settings-hub.placement */\n/**\n * The AUTHORED Settings Hub registry — an application's own settings rail.\n *\n * The framework ships destinations (`ENGINE_SETTINGS_DESTINATIONS`), never a\n * placed hub. This is the application's half: which categories exist, which\n * destinations are placed where, and any destinations the application owns.\n * `wildo init` scaffolds the full engine destination list as placements so a new\n * application starts complete and edits down.\n *\n * Resolve it with `resolveSettingsHubConfig()` to get the rendered\n * {@link SettingsSection} list; the render path never reads this shape directly.\n */\nexport interface SettingsHubConfig {\n  /** Rail groups, in render order (also orderable via `SettingsCategory.order`). */\n  categories: SettingsCategory[];\n  /**\n   * Every destination this application places, and where.\n   *\n   * A destination that appears in no placement does not render. That is\n   * deliberate: absence is how an application removes a settings section, and it\n   * must not be second-guessed by a merge against a framework default.\n   */\n  placements: SettingsPlacement[];\n  /**\n   * The application's OWN destinations — settings surfaces the engine does not\n   * ship, such as a list of the application's team members or a component it\n   * registers. Declared here, then placed like any other destination; a\n   * declared destination that no placement names does not render.\n   *\n   * The ref must not be an engine destination's ref. The engine keeps owning\n   * what its destinations mean, so on a clash the ENGINE destination is the one\n   * resolved, and the DEV startup verifier reports the clash.\n   */\n  destinations?: SettingsDestination[];\n  /**\n   * Section opened when the hub is launched without an explicit section\n   * (`/settings` with no `:sectionRef`). Falls back to the first section of the\n   * first category when omitted.\n   */\n  defaultSectionRef?: string;\n}\n\n/**\n * The RESOLVED hub — categories plus fully-resolved sections, ready to render.\n *\n * Distinct from {@link SettingsHubConfig} (what an application AUTHORS) because\n * conflating the two is what let a placed default ship from the engine. A\n * consumer that renders takes this; a consumer that configures takes the other.\n */\nexport interface ResolvedSettingsHubConfig {\n  categories: SettingsCategory[];\n  sections: SettingsSection[];\n  defaultSectionRef?: string;\n}\n/** @wildo_source:part:end saas.frontend.settings-hub.placement */\n"]}