@wildo-ai/saas-frontend-lib 1.1.9 → 1.1.11

package/dist/esm/core/config/decision-inbox-capability.frontend.utils.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"decision-inbox-capability.frontend.utils.js","sourceRoot":"","sources":["../../../../../src/core/config/decision-inbox-capability.frontend.utils.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAwDG;AACH,OAAO,EAAE,oBAAoB,EAAiC,MAAM,uBAAuB,CAAC;AAC5F,OAAO,EAAE,qBAAqB,EAA+B,MAAM,yDAAyD,CAAC;AAE7H,0GAA0G;AAC1G,MAAM,CAAN,IAAY,uBAOX;AAPD,WAAY,uBAAuB;IACjC;;;;OAIG;IACH,6DAAkC,CAAA;AACpC,CAAC,EAPW,uBAAuB,KAAvB,uBAAuB,QAOlC;AAUD;;;GAGG;AACH,MAAM,UAAU,6BAA6B,CAAC,KAAoC;IAChF,MAAM,cAAc,GAAG,KAAK,CAAC,KAAK,EAAE,cAAc,IAAI,EAAE,CAAC;IACzD,iGAAiG;IACjG,IAAI,cAAc,CAAC,MAAM,KAAK,CAAC;QAAE,OAAO,KAAK,CAAC;IAC9C,MAAM,MAAM,GAAG,KAAK,CAAC,cAAc,CAAC;IACpC,MAAM,OAAO,GAAG,MAAM,CAAC,aAAa,CAAC;IACrC,IAAI,CAAC,OAAO;QAAE,OAAO,qBAAqB,CAAC,cAAc,EAAE,MAAM,CAAC,CAAC;IACnE,MAAM,yBAAyB,GAAG,IAAI,GAAG,EAAU,CAAC;IACpD,KAAK,MAAM,KAAK,IAAI,OAAO,CAAC,WAAW,EAAE,CAAC;QACxC,uHAAuH;QACvH,+GAA+G;QAC/G,IAAI,KAAK,CAAC,mBAAmB,KAAK,oBAAoB,CAAC,aAAa,IAAI,CAAC,KAAK,CAAC,iBAAiB;YAAE,SAAS;QAC3G,KAAK,MAAM,IAAI,IAAI,KAAK,CAAC,KAAK;YAAE,yBAAyB,CAAC,GAAG,CAAC,IAAI,CAAC,CAAC;IACtE,CAAC;IACD,qHAAqH;IACrH,oHAAoH;IACpH,OAAO,qBAAqB,CAAC,cAAc,EAAE,EAAE,GAAG,MAAM,EAAE,iBAAiB,EAAE,CAAC,GAAG,yBAAyB,CAAC,EAAE,CAAC,CAAC;AACjH,CAAC;AAED,yGAAyG;AACzG,MAAM,UAAU,+BAA+B,CAAC,KAAoC;IAClF,OAAO,EAAE,CAAC,uBAAuB,CAAC,QAAQ,CAAC,EAAE,6BAA6B,CAAC,KAAK,CAAC,EAAE,CAAC;AACtF,CAAC","sourcesContent":["/**\n * The runtime capability that decides who is offered the engine's Decisions row (#2527, #2577).\n *\n * ## Why the row does not use `requiredRoles`\n *\n * `runtimeAvailability.requiredRoles` is evaluated against the viewer's application roles and their ORGANIZATION-WIDE\n * roles in the CURRENT organization (`viewerHoldsOneOfRoles`). That is right for every other role-gated launcher entry,\n * because each of them opens something acting in the current organization: a settings section, a view, an operation.\n *\n * The decision inbox is not about the current organization. The server lists a person's decisions from every\n * organization, whatever the current one (`listPendingDecisions`, and each `HumanDecisionHost.listCards`): the\n * decisions assigned to them, the OWNER decisions they raised, and the ROLE decisions of each organization they hold a\n * role entry in, an organization reached through a live relationship included (#2792: read through the same role build\n * as the access profile, `organizationIdsWithRoleEntries`). It then admits each one through the decision organization's\n * role facts, re-read now (`resolveHumanDecisionRoleFacts`): the eligible role held organization-wide, OR in an\n * organization unit that contains the decision's unit, OR through an organization relationship (an assigned decision\n * is admitted that way: the reassignment candidates are the organization's active members, representatives included).\n * Gated on `requiredRoles`, the row was hidden from two people the server answers decisions for:\n * - a unit-only reviewer (a finance approver of one unit), who holds no organization-wide role;\n * - a firm's expert whose current organization is the firm, while the decision waits in a client organization where\n *   the expert stands through the service relationship.\n *\n * Both are LISTED what they may answer, not only offered the row (#2792): the listing used to select ROLE decisions from\n * the organizations of the request's own roles, which a manual controller builds without relationship entries, so the\n * expert was answerable and never listed. It now selects from the same role build the answer path re-reads.\n *\n * ## The decision\n *\n * The row is offered when the viewer holds one of the answering roles in an entry the server reads an answerer from:\n * the application entry (an OWNER route's `APP_USER`), or ANY organization entry of the backend's access profile\n * (`user-self | access_profile`): organization-wide, unit-scoped or relationship, in any organization. The access\n * profile is built by the same role build a decision's role facts are re-read through, so the row follows the server's\n * own facts rather than a second account of them.\n *\n * It is never wider than that: every decision the server lists needs one of those entries to hold the decision's\n * eligible role (or the person to be the OWNER decision's requester, who holds `APP_USER`). It is not narrower than the\n * population either, which a row cannot be without listing: whether a decision is actually waiting in the unit the\n * reviewer covers is the page's question, and the page asks the server.\n *\n * ## Rejected alternatives\n *\n * - **Widen `requiredRoles` for every row** (the issue's option a, applied to the launcher). It would change what every\n *   other role-gated entry means: an `office-manager` section would be offered in an organization where the viewer is\n *   only a member, because they manage another one, and it would open screens the backend then refuses. The decision\n *   inbox gets its own evaluation instead, as a capability, and `requiredRoles` keeps its meaning.\n * - **Offer the row when a decision is pending** (option b's second half). That needs a server read on every shell load\n *   to decide a navigation entry, and the row would come and go as decisions are answered. A reviewer who has answered\n *   everything still has an inbox; its empty state says so.\n *\n * ## Without the access profile\n *\n * When the profile could not be loaded, the shell's documented degradation applies: the roles of the current\n * organization decide, as they did before #2577. A standing elsewhere is then unknown, and the row stays hidden for it\n * rather than being offered on a guess.\n *\n * Presentation, never authorization: the server decides every card on the decision's own route.\n */\nimport { ResourcePrimaryScope, type ApplicationDecisionInbox } from '@wildo-ai/saas-models';\nimport { viewerHoldsOneOfRoles, type LauncherEffectiveRoles } from '~wildo-frontend-lib/core/navigation/launcher-resolution';\n\n/** The runtime capability key the Decisions row requires (`runtimeAvailability.requiredCapabilities`). */\nexport enum DecisionInboxCapability {\n  /**\n   * The viewer holds a role a decision can wait on, in an entry the server reads an answerer from: the application\n   * entry, or any organization entry (organization-wide, unit-scoped or relationship) in any organization. Gates the\n   * engine's Decisions row and its command. An application that places the page itself may require it too.\n   */\n  ANSWERER = 'decisionInboxAnswerer',\n}\n\n/** What the derivation reads: the application's answering roles, and the viewer's roles with the access profile. */\nexport interface DecisionInboxCapabilityInputs {\n  /** `appConfig.decisionInbox`, the roles a decision can wait on. Absent when the application declares none. */\n  readonly offer: ApplicationDecisionInbox | undefined;\n  /** The viewer's roles (`useViewerEffectiveRoles`), carrying the role tables and the backend's access profile. */\n  readonly effectiveRoles: LauncherEffectiveRoles;\n}\n\n/**\n * Whether the viewer may have decisions waiting in the inbox: one of `offer.answeringRoles`, through the role\n * hierarchy, held in the application entry or in any organization entry of the access profile. See the module comment.\n */\nexport function viewerMayHaveDecisionsWaiting(input: DecisionInboxCapabilityInputs): boolean {\n  const answeringRoles = input.offer?.answeringRoles ?? [];\n  // No answering role: the application declares nothing a decision can wait on, and no row exists.\n  if (answeringRoles.length === 0) return false;\n  const viewer = input.effectiveRoles;\n  const profile = viewer.accessProfile;\n  if (!profile) return viewerHoldsOneOfRoles(answeringRoles, viewer);\n  const organizationRolesAnywhere = new Set<string>();\n  for (const entry of profile.roleEntries) {\n    // Every organization entry the server can read an answerer from: organization-wide, unit-scoped (`organizationUnitId`)\n    // and relationship entries alike, in every organization. An application entry is read from `applicationRoles`.\n    if (entry.relatedPrimaryScope !== ResourcePrimaryScope.ORGANIZATIONS || !entry.relatedResourceId) continue;\n    for (const role of entry.roles) organizationRolesAnywhere.add(role);\n  }\n  // OR semantics through the organization role table, as `resolveHumanDecisionRoleFacts` expands a held role. One held\n  // role covering one answering role in one entry is enough, so pooling the entries' roles answers the same question.\n  return viewerHoldsOneOfRoles(answeringRoles, { ...viewer, organizationRoles: [...organizationRolesAnywhere] });\n}\n\n/** The capability. Pure, so the shell hook stays a call and the decision is pinned without providers. */\nexport function deriveDecisionInboxCapabilities(input: DecisionInboxCapabilityInputs): Record<DecisionInboxCapability, boolean> {\n  return { [DecisionInboxCapability.ANSWERER]: viewerMayHaveDecisionsWaiting(input) };\n}\n"]}

package/dist/esm/core/config/directory-provisioning-capabilities.frontend.utils.d.ts

@@ -0,0 +1,69 @@
+/**
+ * The runtime capabilities that decide what the SCIM settings offer for the CURRENT organization (#2613, #2649).
+ *
+ * ## Two questions, and why one capability could not answer both
+ *
+ * Since #2613 SCIM is offered only where the organization's type declares `scimProvisioning`, the one rule the SCIM API
+ * admits a request by (`isOrganizationTypeDirectoryProvisioned`). That made {@link DirectoryProvisioningCapability.ENABLED}
+ * the right gate for everything that CONFIGURES a directory: the provisioning settings, and minting or rotating a token.
+ *
+ * It was also the gate for the whole SCIM section, and that was wrong in one case. An organization of another type can
+ * still HOLD an unrevoked token: one minted before #2613, when generation did not read the type, or one minted in the
+ * instant its type changed. The token does nothing, because the SCIM API refuses every request for that organization,
+ * but it is a live credential, and `organizations.changeType` refuses to move the organization into a SCIM type while
+ * it exists, naming revocation as the remedy. With the section gone, an administrator had no way to see or revoke it
+ * short of calling the API by hand.
+ *
+ * So the section asks a second question, {@link DirectoryProvisioningCapability.SETTINGS_REACHABLE}: is there anything
+ * for this organization in the SCIM settings at all? Yes when a directory may provision it, and yes when it holds an
+ * unrevoked token that only revocation can retire. In that second case only the tokens are shown, with Revoke on each:
+ * the provisioning tab and the Generate and Rotate actions keep requiring {@link DirectoryProvisioningCapability.ENABLED}.
+ *
+ * ## Presentation, never authorization
+ *
+ * The server already decides every one of these: generation and rotation refuse with
+ * `SCIM_TOKEN_ORGANIZATION_TYPE_NOT_DIRECTORY_PROVISIONED` (409, the custom implementation), and revocation never
+ * refuses on the type. The capabilities only stop the settings offering what the server would refuse, and offer the one
+ * thing it would accept.
+ */
+/** The runtime capability keys the SCIM settings require (`runtimeAvailability.requiredCapabilities`). */
+export declare enum DirectoryProvisioningCapability {
+    /**
+     * A directory may provision the current organization: the application offers `DIRECTORY_PROVISIONING` and the
+     * organization's type declares `scimProvisioning`. Gates what configures a directory: the provisioning settings,
+     * and generating or rotating a token.
+     */
+    ENABLED = "scimEnabled",
+    /**
+     * The SCIM settings have something for the current organization: either {@link ENABLED}, or the application offers
+     * the feature and the organization holds an unrevoked token its type lets no directory use, which an administrator
+     * can only revoke (#2649). Gates the section itself.
+     */
+    SETTINGS_REACHABLE = "scimSettingsReachable"
+}
+/** What the derivation reads. Each input is the answer of one existing rule, so this function decides nothing new. */
+export interface DirectoryProvisioningCapabilityInputs {
+    /** `isFeatureOffered(CoreFeature.DIRECTORY_PROVISIONING)`: the OFFERED axis, so a lapsed plan still reaches its settings. */
+    readonly featureOffered: boolean;
+    /** `isOrganizationTypeDirectoryProvisioned` for the current organization's type. `false` while the type is unknown. */
+    readonly organizationTypeDirectoryProvisioned: boolean;
+    /** The organization holds a token with `isActive: true`, whatever its `expiresAt`; `false` until that is known. */
+    readonly holdsUnrevokedToken: boolean;
+}
+/**
+ * Whether the shell must ask the server if the current organization still holds an unrevoked SCIM token.
+ *
+ * Only where the answer can change what is shown: the feature is offered (no SCIM settings exist otherwise), the
+ * organization's type is KNOWN, and that type admits no directory (where it does, the section is shown anyway). Asking
+ * before the type is known would let a directory-provisioned organization's live token open the revoke-only view, which
+ * then grows a provisioning tab when the type arrives: an entry offered one way and changed after. Whether the viewer
+ * may read the tokens is the caller's question, because it needs the registry's operation.
+ */
+export declare function isUnrevokedScimTokenProbeNeeded(input: {
+    readonly featureOffered: boolean;
+    readonly organizationTypeKnown: boolean;
+    readonly organizationTypeDirectoryProvisioned: boolean;
+}): boolean;
+/** The two capabilities. Pure, so the shell hook stays a call and the decision is testable without providers. */
+export declare function deriveDirectoryProvisioningCapabilities(input: DirectoryProvisioningCapabilityInputs): Record<DirectoryProvisioningCapability, boolean>;
+//# sourceMappingURL=directory-provisioning-capabilities.frontend.utils.d.ts.map

package/dist/esm/core/config/directory-provisioning-capabilities.frontend.utils.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"directory-provisioning-capabilities.frontend.utils.d.ts","sourceRoot":"","sources":["../../../../../src/core/config/directory-provisioning-capabilities.frontend.utils.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;GA2BG;AAEH,0GAA0G;AAC1G,oBAAY,+BAA+B;IACzC;;;;OAIG;IACH,OAAO,gBAAgB;IACvB;;;;OAIG;IACH,kBAAkB,0BAA0B;CAC7C;AAED,sHAAsH;AACtH,MAAM,WAAW,qCAAqC;IACpD,6HAA6H;IAC7H,QAAQ,CAAC,cAAc,EAAE,OAAO,CAAC;IACjC,uHAAuH;IACvH,QAAQ,CAAC,oCAAoC,EAAE,OAAO,CAAC;IACvD,mHAAmH;IACnH,QAAQ,CAAC,mBAAmB,EAAE,OAAO,CAAC;CACvC;AAED;;;;;;;;GAQG;AACH,wBAAgB,+BAA+B,CAAC,KAAK,EAAE;IACrD,QAAQ,CAAC,cAAc,EAAE,OAAO,CAAC;IACjC,QAAQ,CAAC,qBAAqB,EAAE,OAAO,CAAC;IACxC,QAAQ,CAAC,oCAAoC,EAAE,OAAO,CAAC;CACxD,GAAG,OAAO,CAEV;AAED,iHAAiH;AACjH,wBAAgB,uCAAuC,CACrD,KAAK,EAAE,qCAAqC,GAC3C,MAAM,CAAC,+BAA+B,EAAE,OAAO,CAAC,CAMlD"}

package/dist/esm/core/config/directory-provisioning-capabilities.frontend.utils.js

@@ -0,0 +1,65 @@
+/**
+ * The runtime capabilities that decide what the SCIM settings offer for the CURRENT organization (#2613, #2649).
+ *
+ * ## Two questions, and why one capability could not answer both
+ *
+ * Since #2613 SCIM is offered only where the organization's type declares `scimProvisioning`, the one rule the SCIM API
+ * admits a request by (`isOrganizationTypeDirectoryProvisioned`). That made {@link DirectoryProvisioningCapability.ENABLED}
+ * the right gate for everything that CONFIGURES a directory: the provisioning settings, and minting or rotating a token.
+ *
+ * It was also the gate for the whole SCIM section, and that was wrong in one case. An organization of another type can
+ * still HOLD an unrevoked token: one minted before #2613, when generation did not read the type, or one minted in the
+ * instant its type changed. The token does nothing, because the SCIM API refuses every request for that organization,
+ * but it is a live credential, and `organizations.changeType` refuses to move the organization into a SCIM type while
+ * it exists, naming revocation as the remedy. With the section gone, an administrator had no way to see or revoke it
+ * short of calling the API by hand.
+ *
+ * So the section asks a second question, {@link DirectoryProvisioningCapability.SETTINGS_REACHABLE}: is there anything
+ * for this organization in the SCIM settings at all? Yes when a directory may provision it, and yes when it holds an
+ * unrevoked token that only revocation can retire. In that second case only the tokens are shown, with Revoke on each:
+ * the provisioning tab and the Generate and Rotate actions keep requiring {@link DirectoryProvisioningCapability.ENABLED}.
+ *
+ * ## Presentation, never authorization
+ *
+ * The server already decides every one of these: generation and rotation refuse with
+ * `SCIM_TOKEN_ORGANIZATION_TYPE_NOT_DIRECTORY_PROVISIONED` (409, the custom implementation), and revocation never
+ * refuses on the type. The capabilities only stop the settings offering what the server would refuse, and offer the one
+ * thing it would accept.
+ */
+/** The runtime capability keys the SCIM settings require (`runtimeAvailability.requiredCapabilities`). */
+export var DirectoryProvisioningCapability;
+(function (DirectoryProvisioningCapability) {
+    /**
+     * A directory may provision the current organization: the application offers `DIRECTORY_PROVISIONING` and the
+     * organization's type declares `scimProvisioning`. Gates what configures a directory: the provisioning settings,
+     * and generating or rotating a token.
+     */
+    DirectoryProvisioningCapability["ENABLED"] = "scimEnabled";
+    /**
+     * The SCIM settings have something for the current organization: either {@link ENABLED}, or the application offers
+     * the feature and the organization holds an unrevoked token its type lets no directory use, which an administrator
+     * can only revoke (#2649). Gates the section itself.
+     */
+    DirectoryProvisioningCapability["SETTINGS_REACHABLE"] = "scimSettingsReachable";
+})(DirectoryProvisioningCapability || (DirectoryProvisioningCapability = {}));
+/**
+ * Whether the shell must ask the server if the current organization still holds an unrevoked SCIM token.
+ *
+ * Only where the answer can change what is shown: the feature is offered (no SCIM settings exist otherwise), the
+ * organization's type is KNOWN, and that type admits no directory (where it does, the section is shown anyway). Asking
+ * before the type is known would let a directory-provisioned organization's live token open the revoke-only view, which
+ * then grows a provisioning tab when the type arrives: an entry offered one way and changed after. Whether the viewer
+ * may read the tokens is the caller's question, because it needs the registry's operation.
+ */
+export function isUnrevokedScimTokenProbeNeeded(input) {
+    return input.featureOffered && input.organizationTypeKnown && !input.organizationTypeDirectoryProvisioned;
+}
+/** The two capabilities. Pure, so the shell hook stays a call and the decision is testable without providers. */
+export function deriveDirectoryProvisioningCapabilities(input) {
+    const enabled = input.featureOffered && input.organizationTypeDirectoryProvisioned;
+    return {
+        [DirectoryProvisioningCapability.ENABLED]: enabled,
+        [DirectoryProvisioningCapability.SETTINGS_REACHABLE]: enabled || (input.featureOffered && input.holdsUnrevokedToken),
+    };
+}
+//# sourceMappingURL=directory-provisioning-capabilities.frontend.utils.js.map

package/dist/esm/core/config/directory-provisioning-capabilities.frontend.utils.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"directory-provisioning-capabilities.frontend.utils.js","sourceRoot":"","sources":["../../../../../src/core/config/directory-provisioning-capabilities.frontend.utils.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;GA2BG;AAEH,0GAA0G;AAC1G,MAAM,CAAN,IAAY,+BAaX;AAbD,WAAY,+BAA+B;IACzC;;;;OAIG;IACH,0DAAuB,CAAA;IACvB;;;;OAIG;IACH,+EAA4C,CAAA;AAC9C,CAAC,EAbW,+BAA+B,KAA/B,+BAA+B,QAa1C;AAYD;;;;;;;;GAQG;AACH,MAAM,UAAU,+BAA+B,CAAC,KAI/C;IACC,OAAO,KAAK,CAAC,cAAc,IAAI,KAAK,CAAC,qBAAqB,IAAI,CAAC,KAAK,CAAC,oCAAoC,CAAC;AAC5G,CAAC;AAED,iHAAiH;AACjH,MAAM,UAAU,uCAAuC,CACrD,KAA4C;IAE5C,MAAM,OAAO,GAAG,KAAK,CAAC,cAAc,IAAI,KAAK,CAAC,oCAAoC,CAAC;IACnF,OAAO;QACL,CAAC,+BAA+B,CAAC,OAAO,CAAC,EAAE,OAAO;QAClD,CAAC,+BAA+B,CAAC,kBAAkB,CAAC,EAAE,OAAO,IAAI,CAAC,KAAK,CAAC,cAAc,IAAI,KAAK,CAAC,mBAAmB,CAAC;KACrH,CAAC;AACJ,CAAC","sourcesContent":["/**\n * The runtime capabilities that decide what the SCIM settings offer for the CURRENT organization (#2613, #2649).\n *\n * ## Two questions, and why one capability could not answer both\n *\n * Since #2613 SCIM is offered only where the organization's type declares `scimProvisioning`, the one rule the SCIM API\n * admits a request by (`isOrganizationTypeDirectoryProvisioned`). That made {@link DirectoryProvisioningCapability.ENABLED}\n * the right gate for everything that CONFIGURES a directory: the provisioning settings, and minting or rotating a token.\n *\n * It was also the gate for the whole SCIM section, and that was wrong in one case. An organization of another type can\n * still HOLD an unrevoked token: one minted before #2613, when generation did not read the type, or one minted in the\n * instant its type changed. The token does nothing, because the SCIM API refuses every request for that organization,\n * but it is a live credential, and `organizations.changeType` refuses to move the organization into a SCIM type while\n * it exists, naming revocation as the remedy. With the section gone, an administrator had no way to see or revoke it\n * short of calling the API by hand.\n *\n * So the section asks a second question, {@link DirectoryProvisioningCapability.SETTINGS_REACHABLE}: is there anything\n * for this organization in the SCIM settings at all? Yes when a directory may provision it, and yes when it holds an\n * unrevoked token that only revocation can retire. In that second case only the tokens are shown, with Revoke on each:\n * the provisioning tab and the Generate and Rotate actions keep requiring {@link DirectoryProvisioningCapability.ENABLED}.\n *\n * ## Presentation, never authorization\n *\n * The server already decides every one of these: generation and rotation refuse with\n * `SCIM_TOKEN_ORGANIZATION_TYPE_NOT_DIRECTORY_PROVISIONED` (409, the custom implementation), and revocation never\n * refuses on the type. The capabilities only stop the settings offering what the server would refuse, and offer the one\n * thing it would accept.\n */\n\n/** The runtime capability keys the SCIM settings require (`runtimeAvailability.requiredCapabilities`). */\nexport enum DirectoryProvisioningCapability {\n  /**\n   * A directory may provision the current organization: the application offers `DIRECTORY_PROVISIONING` and the\n   * organization's type declares `scimProvisioning`. Gates what configures a directory: the provisioning settings,\n   * and generating or rotating a token.\n   */\n  ENABLED = 'scimEnabled',\n  /**\n   * The SCIM settings have something for the current organization: either {@link ENABLED}, or the application offers\n   * the feature and the organization holds an unrevoked token its type lets no directory use, which an administrator\n   * can only revoke (#2649). Gates the section itself.\n   */\n  SETTINGS_REACHABLE = 'scimSettingsReachable',\n}\n\n/** What the derivation reads. Each input is the answer of one existing rule, so this function decides nothing new. */\nexport interface DirectoryProvisioningCapabilityInputs {\n  /** `isFeatureOffered(CoreFeature.DIRECTORY_PROVISIONING)`: the OFFERED axis, so a lapsed plan still reaches its settings. */\n  readonly featureOffered: boolean;\n  /** `isOrganizationTypeDirectoryProvisioned` for the current organization's type. `false` while the type is unknown. */\n  readonly organizationTypeDirectoryProvisioned: boolean;\n  /** The organization holds a token with `isActive: true`, whatever its `expiresAt`; `false` until that is known. */\n  readonly holdsUnrevokedToken: boolean;\n}\n\n/**\n * Whether the shell must ask the server if the current organization still holds an unrevoked SCIM token.\n *\n * Only where the answer can change what is shown: the feature is offered (no SCIM settings exist otherwise), the\n * organization's type is KNOWN, and that type admits no directory (where it does, the section is shown anyway). Asking\n * before the type is known would let a directory-provisioned organization's live token open the revoke-only view, which\n * then grows a provisioning tab when the type arrives: an entry offered one way and changed after. Whether the viewer\n * may read the tokens is the caller's question, because it needs the registry's operation.\n */\nexport function isUnrevokedScimTokenProbeNeeded(input: {\n  readonly featureOffered: boolean;\n  readonly organizationTypeKnown: boolean;\n  readonly organizationTypeDirectoryProvisioned: boolean;\n}): boolean {\n  return input.featureOffered && input.organizationTypeKnown && !input.organizationTypeDirectoryProvisioned;\n}\n\n/** The two capabilities. Pure, so the shell hook stays a call and the decision is testable without providers. */\nexport function deriveDirectoryProvisioningCapabilities(\n  input: DirectoryProvisioningCapabilityInputs,\n): Record<DirectoryProvisioningCapability, boolean> {\n  const enabled = input.featureOffered && input.organizationTypeDirectoryProvisioned;\n  return {\n    [DirectoryProvisioningCapability.ENABLED]: enabled,\n    [DirectoryProvisioningCapability.SETTINGS_REACHABLE]: enabled || (input.featureOffered && input.holdsUnrevokedToken),\n  };\n}\n"]}

package/dist/esm/core/config/engine-settings-destinations.d.ts

@@ -1,4 +1,10 @@
-import type { SettingsDestination, SettingsHubConfig } from './settings-hub.frontend.schemas';
+import type { SettingsCategoryGroup, SettingsDestination, SettingsHubConfig } from './settings-hub.frontend.schemas';
+/**
+ * The runtime capability on in an application that declares at least one professional qualification kind (#2967), set by
+ * `useLauncherRuntimeAvailabilityContext` from the published `professionalQualificationKinds`: an application whose
+ * decisions require no qualification has nothing to record.
+ */
+export declare const PROFESSIONAL_QUALIFICATIONS_DECLARED_CAPABILITY = "professionalQualificationsDeclared";
 /**
  * Every settings destination the engine ships, keyed by `ref`.
  *
@@ -8,6 +14,12 @@ import type { SettingsDestination, SettingsHubConfig } from './settings-hub.fron
  * meant to remove.
  */
 export declare const ENGINE_SETTINGS_DESTINATIONS: readonly SettingsDestination[];
+/**
+ * The rail's sub-categories (#2329), shared by the Organization and Administration categories so the same kind of
+ * surface sits under the same heading in both. A proposal: an application declares its own `groups` and `groupRef`s.
+ * The general and identity-of-the-scope entries (General, Organizations, Versions) stay above the groups.
+ */
+export declare const SCAFFOLD_SETTINGS_RAIL_GROUPS: SettingsCategoryGroup[];
 /**
  * The full placement set `wildo init` scaffolds into a new application's config.
  *

package/dist/esm/core/config/engine-settings-destinations.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"engine-settings-destinations.d.ts","sourceRoot":"","sources":["../../../../../src/core/config/engine-settings-destinations.ts"],"names":[],"mappings":"AA6CA,OAAO,KAAK,EAAE,mBAAmB,EAAE,iBAAiB,EAAE,MAAM,iCAAiC,CAAC;AA0D9F;;;;;;;GAOG;AACH,eAAO,MAAM,4BAA4B,EAAE,SAAS,mBAAmB,EA0xBtE,CAAC;AAGF;;;;;;;;;;;;;;;;;;GAkBG;AACH,eAAO,MAAM,4BAA4B,EAAE,iBAoF1C,CAAC"}
+{"version":3,"file":"engine-settings-destinations.d.ts","sourceRoot":"","sources":["../../../../../src/core/config/engine-settings-destinations.ts"],"names":[],"mappings":"AA8CA,OAAO,KAAK,EAAE,qBAAqB,EAAE,mBAAmB,EAAE,iBAAiB,EAAE,MAAM,iCAAiC,CAAC;AA2BrH;;;;GAIG;AACH,eAAO,MAAM,+CAA+C,uCAAuC,CAAC;AA2CpG;;;;;;;GAOG;AACH,eAAO,MAAM,4BAA4B,EAAE,SAAS,mBAAmB,EA2oCtE,CAAC;AAGF;;;;GAIG;AACH,eAAO,MAAM,6BAA6B,EAAE,qBAAqB,EAOhE,CAAC;AAEF;;;;;;;;;;;;;;;;;;GAkBG;AACH,eAAO,MAAM,4BAA4B,EAAE,iBAqH1C,CAAC"}