@wildo-ai/saas-models 1.1.3 → 1.1.5

package/dist/esm/frontend-definitions/settings-destination-ref.definitions.d.ts

@@ -0,0 +1,217 @@
+/**
+ * The IDENTITY half of the engine's settings-hub catalogue — the refs, and nothing else.
+ *
+ * ## Why the identity lives here and the catalogue does not
+ *
+ * A settings destination has two halves, and only one of them is a rendering concern:
+ *
+ * - **What a destination IS** — its `target` (a resource operation, a bespoke engine panel, a set
+ *   of sub-tabs), its role gating, its runtime-capability gating. That half names components and
+ *   panel refs, so it belongs to `@wildo-ai/saas-frontend-lib`, where `ENGINE_SETTINGS_DESTINATIONS`
+ *   declares it.
+ * - **WHICH destinations exist** — a closed set of ids. That half names nothing renderable. It is
+ *   the vocabulary an application's `SettingsHubConfig` addresses by string, the vocabulary the
+ *   app-creation placement plan names in a `PlacementSubject`, and the vocabulary engine code
+ *   addresses by enum member. It is declared here.
+ *
+ * The split was made 2026-09-09 because the second half had a consumer the first half's package
+ * could never serve. `validatePlacementPlan`'s `UNKNOWN_SUBJECT` finding is a HARD FLOOR — it
+ * refuses a landing — and it can only fire when a caller supplies the universe of subjects that
+ * exist. Its one production caller is the app-creation semantic authority, a backend-side package
+ * that must not depend on `saas-frontend-lib`. So a declared refusal had no holder, for no reason
+ * other than where a list of sixteen strings was written down.
+ *
+ * Nothing is re-exported across the boundary: `saas-frontend-lib` imports the enum from here and
+ * declares only the catalogue.
+ */
+/** @wildo_source:part:start saas.frontend.settings-hub.engine-destinations facet:layer:frontend facet:family:config facet:audience:app-developer */
+/**
+ * Every settings destination the engine ships, as a named vocabulary.
+ *
+ * Imported from `@wildo-ai/saas-models`. Exists because these refs are a CLOSED
+ * vocabulary that engine code addresses by name — the billing command-menu entry
+ * opens `/settings/billing`, and any future engine launcher will do the same.
+ * Before this enum, `'billing'` was a bare literal in `billing-launcher.ts` with
+ * nothing tying it to the catalog entry it names: rename the destination and the
+ * command silently resolves to the hub's DEFAULT section instead of failing, so a
+ * menu item labelled "Billing" would open Profile.
+ *
+ * **Engine code must address a destination through this enum. Application
+ * config addresses one by string**, deliberately: a placement is authored data,
+ * an application should not import an engine enum to write its own rail, and a
+ * typo there is caught at DEV startup by `verifySettingsHubContent`.
+ */
+export declare enum EngineSettingsDestinationRef {
+    /** The signed-in user's own profile record. */
+    PROFILE = "profile",
+    /** Password, MFA, sessions — a bespoke engine panel. */
+    SECURITY = "security",
+    /** Theme and appearance preferences — a bespoke engine panel. */
+    APPEARANCE = "appearance",
+    /** The signed-in user's own preference record. */
+    PREFERENCES = "preferences",
+    /** Invitations addressed TO the signed-in user, across organizations they have not joined. */
+    MY_INVITATIONS = "my-invitations",
+    /** The current organization's own record. Org owner/admin only. */
+    ORGANIZATION_GENERAL = "organization-general",
+    /** Organization membership list, including INVITED rows. Org owner/admin only. */
+    MEMBERS = "members",
+    /**
+     * The organization's internal structure — teams, departments, the hierarchy under the tenant.
+     *
+     * Its own rail entry rather than a tab inside {@link ORGANIZATION_GENERAL}. The general pane is a
+     * record — a column of decisions about the tenant itself — and a unit hierarchy is a population
+     * you navigate, which is a different kind of surface and a different task. Nesting it there also
+     * put it behind a pane a reader had no other reason to open.
+     */
+    ORGANIZATION_UNITS = "organization-units",
+    /** Billing home — subscription, plans, usage, invoices. Gated on the `billingEnabled` capability. */
+    BILLING = "billing",
+    /** Organization API keys. Org owner/admin only. */
+    API_KEYS = "api-keys",
+    /**
+     * The tenant's OWN credentials toward third parties — its Slack workspace token, its CRM key.
+     *
+     * The mirror image of {@link API_KEYS} and easy to confuse with it: an API key is a credential
+     * somebody uses to reach THIS application, and one of these is a credential this application uses
+     * to reach somebody else ON THIS TENANT'S BEHALF. Same administrator, opposite direction.
+     */
+    PROVIDER_CREDENTIALS = "provider-credentials",
+    /**
+     * The signed-in person's OWN credentials toward third parties — their personal API key, the
+     * account they connected themselves.
+     *
+     * Distinct from {@link PROVIDER_CREDENTIALS} by OWNER, not by feature, and the two must never be
+     * merged into one screen. A tenant's credential is a shared integration an administrator
+     * configures for everyone; this one is an individual's own account, which nobody else may see,
+     * spend or remove. Putting them on one page would put a colleague's personal vendor token in an
+     * administrator's view — and the resource's authorization refuses that, so the screen would show
+     * an empty list nobody could explain.
+     */
+    MY_PROVIDER_CREDENTIALS = "my-provider-credentials",
+    /** Single sign-on configuration and connections. */
+    SSO = "sso",
+    /** SCIM directory provisioning configuration and tokens. */
+    SCIM = "scim",
+    /** Audit-event streaming configuration and failed-delivery queue. */
+    SIEM = "siem",
+    /** Outbound webhook endpoints and delivery log. */
+    WEBHOOKS = "webhooks",
+    /** The organization's audit log. Org owner/admin only. */
+    AUDIT_LOGS = "audit-logs",
+    /**
+     * What THIS organization is currently entitled to — its features, its numeric limits, and the
+     * application-administrator exceptions laid over them.
+     *
+     * Readable by any organization member (`organizationFeatures` READ is `ORG_MEMBER`), which is why
+     * it carries no `requiredRoles`: a member who is told a surface needs an upgrade should be able to
+     * see what their organization actually has. The operations that CHANGE it — enable, disable, reset
+     * — are `APP_ADMIN_SUPER_ADMIN` on the resource itself, so the same screen is a read-only summary
+     * for a member and the grant/withdraw console for a platform administrator.
+     *
+     * Until this existed there was no way to reach the entitlement state from anywhere in the product:
+     * the resource had a table, an admin UI behaviour and three custom operations, and no door.
+     */
+    ORGANIZATION_ENTITLEMENTS = "organization-entitlements",
+    /** Referral codes and their redemptions. Organization-scoped despite living in the billing domain. */
+    ORGANIZATION_REFERRALS = "organization-referrals",
+    /** The application's own descriptive record — name, description, the operator's identity. */
+    APPLICATION_GENERAL = "application-general",
+    /** Released versions of the application. */
+    APPLICATION_VERSIONS = "application-versions",
+    /**
+     * OAuth clients registered against the APPLICATION — the credential a machine presents for a
+     * client-credentials or authorization-code exchange.
+     *
+     * The sibling of {@link APPLICATION_API_KEYS} rather than a duplicate of it: under
+     * client-credentials both authenticate the same `APPLICATION_MACHINE` principal, so they are two
+     * credential TYPES for one identity and belong side by side.
+     */
+    APPLICATION_OAUTH_CLIENTS = "application-oauth-clients",
+    /**
+     * The two-person rule, made reviewable — requested, signed, time-bound elevations over the
+     * application-wide reads.
+     *
+     * Placed because a control of this kind is justified by VISIBILITY rather than by prevention:
+     * it does not stop an operator reading across tenants, it makes a second administrator sign for
+     * it and leaves a record. An elevation nobody can read makes nothing visible, so the mechanism
+     * ran without its own justification until this had a door.
+     */
+    APPLICATION_ACCESS_GRANTS = "application-access-grants",
+    /**
+     * The application-wide audit trail — every tenant's events plus the ones belonging to no tenant.
+     *
+     * Distinct from the organization {@link AUDIT_LOGS} by the question it answers, not by scope
+     * alone: the tenant door answers "what happened in my organization", this one answers "what
+     * happened at all", and only the second can support a deployment-level attestation. Every read
+     * through it is a declared crossing and emits one event into each tenant it reached.
+     */
+    APPLICATION_AUDIT_LOGS = "application-audit-logs",
+    /** The application-scope feature and limit state, with administrator exceptions. */
+    APPLICATION_ENTITLEMENTS = "application-entitlements",
+    /** API keys that authenticate a machine to the APPLICATION rather than to one organization. */
+    APPLICATION_API_KEYS = "application-api-keys",
+    /** Application-wide single sign-on: the configuration, and the connections it admits. */
+    APPLICATION_SSO = "application-sso",
+    /**
+     * Application-wide SCIM directory provisioning.
+     *
+     * One target rather than the organization sibling's two tabs, and that asymmetry is real rather
+     * than an omission: there is no `APPLICATION_SCIM_TOKENS` resource — only
+     * `ORGANIZATION_SCIM_TOKENS` exists — so the application scope has a provisioning configuration
+     * and nothing to tab to.
+     */
+    APPLICATION_SCIM = "application-scim",
+    /** Application-wide audit-event streaming, and the deliveries that failed. */
+    APPLICATION_SIEM = "application-siem",
+    /** Application-wide outbound webhooks, and their delivery log. */
+    APPLICATION_WEBHOOKS = "application-webhooks",
+    /**
+     * The billing CATALOGUE the application sells — products, their prices, and promotions.
+     *
+     * Distinct from the organization `BILLING` destination, which is one tenant's subscription and
+     * invoices. This is the operator editing what is on sale; that is a customer reading what they
+     * bought.
+     */
+    BILLING_CATALOG = "billing-catalog"
+}
+/**
+ * ## Two administration surfaces that are DELIBERATELY absent, so neither is re-proposed
+ *
+ * **A tenant directory.** `organizations` LIST looks like one and is not: it is confined by
+ * `assignScopeRootCollectionConfinementToFilter` to the tenants the caller holds an
+ * organization-wide role entry for, so a platform super-administrator sees THEIR OWN organizations
+ * and not every tenant. That confinement is deliberate — the resource's own banner says so, and
+ * says explicitly that an operator who "cannot find the tenant id" should stop rather than widen
+ * the operation, because widening it hands the full customer list to every platform administrator
+ * as a standing privilege. A destination named "Organizations" under Administration would promise
+ * the directory and deliver the memberships, which is worse than having no entry: the reader
+ * cannot tell the difference, and the number looks authoritative.
+ *
+ * **A user directory.** Same shape one level down. The application-wide user read is gated on a
+ * two-person `applicationAccessGrants` window precisely so that it is not a standing privilege, so
+ * a permanently-placed rail entry would either sit there refusing or quietly bypass the control it
+ * is supposed to pass through.
+ *
+ * Both become placeable when a governed cross-tenant read exists — an operation that requires the
+ * grant and says so. Neither becomes placeable by widening the operation that is already there.
+ */
+/** @wildo_source:part:end saas.frontend.settings-hub.engine-destinations */
+/**
+ * Every destination ref the engine ships — the set an authored placement is validated against.
+ *
+ * **Derived from the enum, not from the catalogue, and that is the point.** It used to be
+ * `ENGINE_SETTINGS_DESTINATIONS.map(d => d.ref)`, which made the set a statement about how many
+ * catalogue entries had been written rather than about what the vocabulary contains: a member added
+ * to the enum and not yet given a catalogue entry would have been silently absent from the universe
+ * a hard floor is measured against, so a placement naming it would have been refused as UNKNOWN.
+ * Deriving from the enum is TOTAL over the vocabulary — a member added tomorrow is in this set the
+ * same day — and the reverse obligation (every ref has a catalogue entry) is pinned in
+ * `saas-frontend-lib`, where the catalogue lives and where an omission is a rendering defect.
+ *
+ * Values are bare ids, the shape `placementSubjectLocalKey` publishes for
+ * `ENGINE_SETTINGS_DESTINATION` subjects, so this set can be handed to `validatePlacementPlan`
+ * without being re-spelled.
+ */
+export declare const ENGINE_SETTINGS_DESTINATION_REFS: ReadonlySet<string>;
+//# sourceMappingURL=settings-destination-ref.definitions.d.ts.map

package/dist/esm/frontend-definitions/settings-destination-ref.definitions.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"settings-destination-ref.definitions.d.ts","sourceRoot":"","sources":["../../../../src/frontend-definitions/settings-destination-ref.definitions.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;GAyBG;AAEH,oJAAoJ;AACpJ;;;;;;;;;;;;;;;GAeG;AACH,oBAAY,4BAA4B;IACtC,+CAA+C;IAC/C,OAAO,YAAY;IACnB,wDAAwD;IACxD,QAAQ,aAAa;IACrB,iEAAiE;IACjE,UAAU,eAAe;IACzB,kDAAkD;IAClD,WAAW,gBAAgB;IAC3B,8FAA8F;IAC9F,cAAc,mBAAmB;IACjC,mEAAmE;IACnE,oBAAoB,yBAAyB;IAC7C,kFAAkF;IAClF,OAAO,YAAY;IACnB;;;;;;;OAOG;IACH,kBAAkB,uBAAuB;IACzC,qGAAqG;IACrG,OAAO,YAAY;IACnB,mDAAmD;IACnD,QAAQ,aAAa;IACrB;;;;;;OAMG;IACH,oBAAoB,yBAAyB;IAC7C;;;;;;;;;;OAUG;IACH,uBAAuB,4BAA4B;IACnD,oDAAoD;IACpD,GAAG,QAAQ;IACX,4DAA4D;IAC5D,IAAI,SAAS;IACb,qEAAqE;IACrE,IAAI,SAAS;IACb,mDAAmD;IACnD,QAAQ,aAAa;IACrB,0DAA0D;IAC1D,UAAU,eAAe;IACzB;;;;;;;;;;;;OAYG;IACH,yBAAyB,8BAA8B;IACvD,sGAAsG;IACtG,sBAAsB,2BAA2B;IAejD,6FAA6F;IAC7F,mBAAmB,wBAAwB;IAC3C,4CAA4C;IAC5C,oBAAoB,yBAAyB;IAC7C;;;;;;;OAOG;IACH,yBAAyB,8BAA8B;IACvD;;;;;;;;OAQG;IACH,yBAAyB,8BAA8B;IACvD;;;;;;;OAOG;IACH,sBAAsB,2BAA2B;IACjD,oFAAoF;IACpF,wBAAwB,6BAA6B;IACrD,+FAA+F;IAC/F,oBAAoB,yBAAyB;IAC7C,yFAAyF;IACzF,eAAe,oBAAoB;IACnC;;;;;;;OAOG;IACH,gBAAgB,qBAAqB;IACrC,8EAA8E;IAC9E,gBAAgB,qBAAqB;IACrC,kEAAkE;IAClE,oBAAoB,yBAAyB;IAC7C;;;;;;OAMG;IACH,eAAe,oBAAoB;CACpC;AAED;;;;;;;;;;;;;;;;;;;;GAoBG;AACH,4EAA4E;AAE5E;;;;;;;;;;;;;;;GAeG;AACH,eAAO,MAAM,gCAAgC,EAAE,WAAW,CAAC,MAAM,CAAgE,CAAC"}

package/dist/esm/frontend-definitions/settings-destination-ref.definitions.js

@@ -0,0 +1,230 @@
+/**
+ * The IDENTITY half of the engine's settings-hub catalogue — the refs, and nothing else.
+ *
+ * ## Why the identity lives here and the catalogue does not
+ *
+ * A settings destination has two halves, and only one of them is a rendering concern:
+ *
+ * - **What a destination IS** — its `target` (a resource operation, a bespoke engine panel, a set
+ *   of sub-tabs), its role gating, its runtime-capability gating. That half names components and
+ *   panel refs, so it belongs to `@wildo-ai/saas-frontend-lib`, where `ENGINE_SETTINGS_DESTINATIONS`
+ *   declares it.
+ * - **WHICH destinations exist** — a closed set of ids. That half names nothing renderable. It is
+ *   the vocabulary an application's `SettingsHubConfig` addresses by string, the vocabulary the
+ *   app-creation placement plan names in a `PlacementSubject`, and the vocabulary engine code
+ *   addresses by enum member. It is declared here.
+ *
+ * The split was made 2026-09-09 because the second half had a consumer the first half's package
+ * could never serve. `validatePlacementPlan`'s `UNKNOWN_SUBJECT` finding is a HARD FLOOR — it
+ * refuses a landing — and it can only fire when a caller supplies the universe of subjects that
+ * exist. Its one production caller is the app-creation semantic authority, a backend-side package
+ * that must not depend on `saas-frontend-lib`. So a declared refusal had no holder, for no reason
+ * other than where a list of sixteen strings was written down.
+ *
+ * Nothing is re-exported across the boundary: `saas-frontend-lib` imports the enum from here and
+ * declares only the catalogue.
+ */
+/** @wildo_source:part:start saas.frontend.settings-hub.engine-destinations facet:layer:frontend facet:family:config facet:audience:app-developer */
+/**
+ * Every settings destination the engine ships, as a named vocabulary.
+ *
+ * Imported from `@wildo-ai/saas-models`. Exists because these refs are a CLOSED
+ * vocabulary that engine code addresses by name — the billing command-menu entry
+ * opens `/settings/billing`, and any future engine launcher will do the same.
+ * Before this enum, `'billing'` was a bare literal in `billing-launcher.ts` with
+ * nothing tying it to the catalog entry it names: rename the destination and the
+ * command silently resolves to the hub's DEFAULT section instead of failing, so a
+ * menu item labelled "Billing" would open Profile.
+ *
+ * **Engine code must address a destination through this enum. Application
+ * config addresses one by string**, deliberately: a placement is authored data,
+ * an application should not import an engine enum to write its own rail, and a
+ * typo there is caught at DEV startup by `verifySettingsHubContent`.
+ */
+export var EngineSettingsDestinationRef;
+(function (EngineSettingsDestinationRef) {
+    /** The signed-in user's own profile record. */
+    EngineSettingsDestinationRef["PROFILE"] = "profile";
+    /** Password, MFA, sessions — a bespoke engine panel. */
+    EngineSettingsDestinationRef["SECURITY"] = "security";
+    /** Theme and appearance preferences — a bespoke engine panel. */
+    EngineSettingsDestinationRef["APPEARANCE"] = "appearance";
+    /** The signed-in user's own preference record. */
+    EngineSettingsDestinationRef["PREFERENCES"] = "preferences";
+    /** Invitations addressed TO the signed-in user, across organizations they have not joined. */
+    EngineSettingsDestinationRef["MY_INVITATIONS"] = "my-invitations";
+    /** The current organization's own record. Org owner/admin only. */
+    EngineSettingsDestinationRef["ORGANIZATION_GENERAL"] = "organization-general";
+    /** Organization membership list, including INVITED rows. Org owner/admin only. */
+    EngineSettingsDestinationRef["MEMBERS"] = "members";
+    /**
+     * The organization's internal structure — teams, departments, the hierarchy under the tenant.
+     *
+     * Its own rail entry rather than a tab inside {@link ORGANIZATION_GENERAL}. The general pane is a
+     * record — a column of decisions about the tenant itself — and a unit hierarchy is a population
+     * you navigate, which is a different kind of surface and a different task. Nesting it there also
+     * put it behind a pane a reader had no other reason to open.
+     */
+    EngineSettingsDestinationRef["ORGANIZATION_UNITS"] = "organization-units";
+    /** Billing home — subscription, plans, usage, invoices. Gated on the `billingEnabled` capability. */
+    EngineSettingsDestinationRef["BILLING"] = "billing";
+    /** Organization API keys. Org owner/admin only. */
+    EngineSettingsDestinationRef["API_KEYS"] = "api-keys";
+    /**
+     * The tenant's OWN credentials toward third parties — its Slack workspace token, its CRM key.
+     *
+     * The mirror image of {@link API_KEYS} and easy to confuse with it: an API key is a credential
+     * somebody uses to reach THIS application, and one of these is a credential this application uses
+     * to reach somebody else ON THIS TENANT'S BEHALF. Same administrator, opposite direction.
+     */
+    EngineSettingsDestinationRef["PROVIDER_CREDENTIALS"] = "provider-credentials";
+    /**
+     * The signed-in person's OWN credentials toward third parties — their personal API key, the
+     * account they connected themselves.
+     *
+     * Distinct from {@link PROVIDER_CREDENTIALS} by OWNER, not by feature, and the two must never be
+     * merged into one screen. A tenant's credential is a shared integration an administrator
+     * configures for everyone; this one is an individual's own account, which nobody else may see,
+     * spend or remove. Putting them on one page would put a colleague's personal vendor token in an
+     * administrator's view — and the resource's authorization refuses that, so the screen would show
+     * an empty list nobody could explain.
+     */
+    EngineSettingsDestinationRef["MY_PROVIDER_CREDENTIALS"] = "my-provider-credentials";
+    /** Single sign-on configuration and connections. */
+    EngineSettingsDestinationRef["SSO"] = "sso";
+    /** SCIM directory provisioning configuration and tokens. */
+    EngineSettingsDestinationRef["SCIM"] = "scim";
+    /** Audit-event streaming configuration and failed-delivery queue. */
+    EngineSettingsDestinationRef["SIEM"] = "siem";
+    /** Outbound webhook endpoints and delivery log. */
+    EngineSettingsDestinationRef["WEBHOOKS"] = "webhooks";
+    /** The organization's audit log. Org owner/admin only. */
+    EngineSettingsDestinationRef["AUDIT_LOGS"] = "audit-logs";
+    /**
+     * What THIS organization is currently entitled to — its features, its numeric limits, and the
+     * application-administrator exceptions laid over them.
+     *
+     * Readable by any organization member (`organizationFeatures` READ is `ORG_MEMBER`), which is why
+     * it carries no `requiredRoles`: a member who is told a surface needs an upgrade should be able to
+     * see what their organization actually has. The operations that CHANGE it — enable, disable, reset
+     * — are `APP_ADMIN_SUPER_ADMIN` on the resource itself, so the same screen is a read-only summary
+     * for a member and the grant/withdraw console for a platform administrator.
+     *
+     * Until this existed there was no way to reach the entitlement state from anywhere in the product:
+     * the resource had a table, an admin UI behaviour and three custom operations, and no door.
+     */
+    EngineSettingsDestinationRef["ORGANIZATION_ENTITLEMENTS"] = "organization-entitlements";
+    /** Referral codes and their redemptions. Organization-scoped despite living in the billing domain. */
+    EngineSettingsDestinationRef["ORGANIZATION_REFERRALS"] = "organization-referrals";
+    // ── Application administration ──────────────────────────────────────────────
+    //
+    // Everything below is `ResourcePrimaryScope.APPLICATION`: it configures the APPLICATION ITSELF
+    // rather than one tenant inside it, and it is the operator's surface, not a customer's. The
+    // category an application places these in is what supplies that scope, and
+    // `useVisibleSettingsHubConfig` resolves the application id from `appIdentity` — the access
+    // token does not carry one, so a category scoped this way was unreachable until 2026-09-17.
+    //
+    // Each mirrors an organization-scope sibling above, and the pairs are NOT redundant: an
+    // application-wide SSO connection authenticates everybody who is not covered by a tenant's own,
+    // and an application-wide SIEM export carries the operator's own security events rather than a
+    // customer's. Same mechanism, different principal, different consequence.
+    /** The application's own descriptive record — name, description, the operator's identity. */
+    EngineSettingsDestinationRef["APPLICATION_GENERAL"] = "application-general";
+    /** Released versions of the application. */
+    EngineSettingsDestinationRef["APPLICATION_VERSIONS"] = "application-versions";
+    /**
+     * OAuth clients registered against the APPLICATION — the credential a machine presents for a
+     * client-credentials or authorization-code exchange.
+     *
+     * The sibling of {@link APPLICATION_API_KEYS} rather than a duplicate of it: under
+     * client-credentials both authenticate the same `APPLICATION_MACHINE` principal, so they are two
+     * credential TYPES for one identity and belong side by side.
+     */
+    EngineSettingsDestinationRef["APPLICATION_OAUTH_CLIENTS"] = "application-oauth-clients";
+    /**
+     * The two-person rule, made reviewable — requested, signed, time-bound elevations over the
+     * application-wide reads.
+     *
+     * Placed because a control of this kind is justified by VISIBILITY rather than by prevention:
+     * it does not stop an operator reading across tenants, it makes a second administrator sign for
+     * it and leaves a record. An elevation nobody can read makes nothing visible, so the mechanism
+     * ran without its own justification until this had a door.
+     */
+    EngineSettingsDestinationRef["APPLICATION_ACCESS_GRANTS"] = "application-access-grants";
+    /**
+     * The application-wide audit trail — every tenant's events plus the ones belonging to no tenant.
+     *
+     * Distinct from the organization {@link AUDIT_LOGS} by the question it answers, not by scope
+     * alone: the tenant door answers "what happened in my organization", this one answers "what
+     * happened at all", and only the second can support a deployment-level attestation. Every read
+     * through it is a declared crossing and emits one event into each tenant it reached.
+     */
+    EngineSettingsDestinationRef["APPLICATION_AUDIT_LOGS"] = "application-audit-logs";
+    /** The application-scope feature and limit state, with administrator exceptions. */
+    EngineSettingsDestinationRef["APPLICATION_ENTITLEMENTS"] = "application-entitlements";
+    /** API keys that authenticate a machine to the APPLICATION rather than to one organization. */
+    EngineSettingsDestinationRef["APPLICATION_API_KEYS"] = "application-api-keys";
+    /** Application-wide single sign-on: the configuration, and the connections it admits. */
+    EngineSettingsDestinationRef["APPLICATION_SSO"] = "application-sso";
+    /**
+     * Application-wide SCIM directory provisioning.
+     *
+     * One target rather than the organization sibling's two tabs, and that asymmetry is real rather
+     * than an omission: there is no `APPLICATION_SCIM_TOKENS` resource — only
+     * `ORGANIZATION_SCIM_TOKENS` exists — so the application scope has a provisioning configuration
+     * and nothing to tab to.
+     */
+    EngineSettingsDestinationRef["APPLICATION_SCIM"] = "application-scim";
+    /** Application-wide audit-event streaming, and the deliveries that failed. */
+    EngineSettingsDestinationRef["APPLICATION_SIEM"] = "application-siem";
+    /** Application-wide outbound webhooks, and their delivery log. */
+    EngineSettingsDestinationRef["APPLICATION_WEBHOOKS"] = "application-webhooks";
+    /**
+     * The billing CATALOGUE the application sells — products, their prices, and promotions.
+     *
+     * Distinct from the organization `BILLING` destination, which is one tenant's subscription and
+     * invoices. This is the operator editing what is on sale; that is a customer reading what they
+     * bought.
+     */
+    EngineSettingsDestinationRef["BILLING_CATALOG"] = "billing-catalog";
+})(EngineSettingsDestinationRef || (EngineSettingsDestinationRef = {}));
+/**
+ * ## Two administration surfaces that are DELIBERATELY absent, so neither is re-proposed
+ *
+ * **A tenant directory.** `organizations` LIST looks like one and is not: it is confined by
+ * `assignScopeRootCollectionConfinementToFilter` to the tenants the caller holds an
+ * organization-wide role entry for, so a platform super-administrator sees THEIR OWN organizations
+ * and not every tenant. That confinement is deliberate — the resource's own banner says so, and
+ * says explicitly that an operator who "cannot find the tenant id" should stop rather than widen
+ * the operation, because widening it hands the full customer list to every platform administrator
+ * as a standing privilege. A destination named "Organizations" under Administration would promise
+ * the directory and deliver the memberships, which is worse than having no entry: the reader
+ * cannot tell the difference, and the number looks authoritative.
+ *
+ * **A user directory.** Same shape one level down. The application-wide user read is gated on a
+ * two-person `applicationAccessGrants` window precisely so that it is not a standing privilege, so
+ * a permanently-placed rail entry would either sit there refusing or quietly bypass the control it
+ * is supposed to pass through.
+ *
+ * Both become placeable when a governed cross-tenant read exists — an operation that requires the
+ * grant and says so. Neither becomes placeable by widening the operation that is already there.
+ */
+/** @wildo_source:part:end saas.frontend.settings-hub.engine-destinations */
+/**
+ * Every destination ref the engine ships — the set an authored placement is validated against.
+ *
+ * **Derived from the enum, not from the catalogue, and that is the point.** It used to be
+ * `ENGINE_SETTINGS_DESTINATIONS.map(d => d.ref)`, which made the set a statement about how many
+ * catalogue entries had been written rather than about what the vocabulary contains: a member added
+ * to the enum and not yet given a catalogue entry would have been silently absent from the universe
+ * a hard floor is measured against, so a placement naming it would have been refused as UNKNOWN.
+ * Deriving from the enum is TOTAL over the vocabulary — a member added tomorrow is in this set the
+ * same day — and the reverse obligation (every ref has a catalogue entry) is pinned in
+ * `saas-frontend-lib`, where the catalogue lives and where an omission is a rendering defect.
+ *
+ * Values are bare ids, the shape `placementSubjectLocalKey` publishes for
+ * `ENGINE_SETTINGS_DESTINATION` subjects, so this set can be handed to `validatePlacementPlan`
+ * without being re-spelled.
+ */
+export const ENGINE_SETTINGS_DESTINATION_REFS = new Set(Object.values(EngineSettingsDestinationRef));
+//# sourceMappingURL=settings-destination-ref.definitions.js.map

package/dist/esm/frontend-definitions/settings-destination-ref.definitions.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"settings-destination-ref.definitions.js","sourceRoot":"","sources":["../../../../src/frontend-definitions/settings-destination-ref.definitions.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;GAyBG;AAEH,oJAAoJ;AACpJ;;;;;;;;;;;;;;;GAeG;AACH,MAAM,CAAN,IAAY,4BAmJX;AAnJD,WAAY,4BAA4B;IACtC,+CAA+C;IAC/C,mDAAmB,CAAA;IACnB,wDAAwD;IACxD,qDAAqB,CAAA;IACrB,iEAAiE;IACjE,yDAAyB,CAAA;IACzB,kDAAkD;IAClD,2DAA2B,CAAA;IAC3B,8FAA8F;IAC9F,iEAAiC,CAAA;IACjC,mEAAmE;IACnE,6EAA6C,CAAA;IAC7C,kFAAkF;IAClF,mDAAmB,CAAA;IACnB;;;;;;;OAOG;IACH,yEAAyC,CAAA;IACzC,qGAAqG;IACrG,mDAAmB,CAAA;IACnB,mDAAmD;IACnD,qDAAqB,CAAA;IACrB;;;;;;OAMG;IACH,6EAA6C,CAAA;IAC7C;;;;;;;;;;OAUG;IACH,mFAAmD,CAAA;IACnD,oDAAoD;IACpD,2CAAW,CAAA;IACX,4DAA4D;IAC5D,6CAAa,CAAA;IACb,qEAAqE;IACrE,6CAAa,CAAA;IACb,mDAAmD;IACnD,qDAAqB,CAAA;IACrB,0DAA0D;IAC1D,yDAAyB,CAAA;IACzB;;;;;;;;;;;;OAYG;IACH,uFAAuD,CAAA;IACvD,sGAAsG;IACtG,iFAAiD,CAAA;IAEjD,+EAA+E;IAC/E,EAAE;IACF,+FAA+F;IAC/F,4FAA4F;IAC5F,2EAA2E;IAC3E,4FAA4F;IAC5F,4FAA4F;IAC5F,EAAE;IACF,wFAAwF;IACxF,gGAAgG;IAChG,+FAA+F;IAC/F,0EAA0E;IAE1E,6FAA6F;IAC7F,2EAA2C,CAAA;IAC3C,4CAA4C;IAC5C,6EAA6C,CAAA;IAC7C;;;;;;;OAOG;IACH,uFAAuD,CAAA;IACvD;;;;;;;;OAQG;IACH,uFAAuD,CAAA;IACvD;;;;;;;OAOG;IACH,iFAAiD,CAAA;IACjD,oFAAoF;IACpF,qFAAqD,CAAA;IACrD,+FAA+F;IAC/F,6EAA6C,CAAA;IAC7C,yFAAyF;IACzF,mEAAmC,CAAA;IACnC;;;;;;;OAOG;IACH,qEAAqC,CAAA;IACrC,8EAA8E;IAC9E,qEAAqC,CAAA;IACrC,kEAAkE;IAClE,6EAA6C,CAAA;IAC7C;;;;;;OAMG;IACH,mEAAmC,CAAA;AACrC,CAAC,EAnJW,4BAA4B,KAA5B,4BAA4B,QAmJvC;AAED;;;;;;;;;;;;;;;;;;;;GAoBG;AACH,4EAA4E;AAE5E;;;;;;;;;;;;;;;GAeG;AACH,MAAM,CAAC,MAAM,gCAAgC,GAAwB,IAAI,GAAG,CAAS,MAAM,CAAC,MAAM,CAAC,4BAA4B,CAAC,CAAC,CAAC","sourcesContent":["/**\n * The IDENTITY half of the engine's settings-hub catalogue — the refs, and nothing else.\n *\n * ## Why the identity lives here and the catalogue does not\n *\n * A settings destination has two halves, and only one of them is a rendering concern:\n *\n * - **What a destination IS** — its `target` (a resource operation, a bespoke engine panel, a set\n *   of sub-tabs), its role gating, its runtime-capability gating. That half names components and\n *   panel refs, so it belongs to `@wildo-ai/saas-frontend-lib`, where `ENGINE_SETTINGS_DESTINATIONS`\n *   declares it.\n * - **WHICH destinations exist** — a closed set of ids. That half names nothing renderable. It is\n *   the vocabulary an application's `SettingsHubConfig` addresses by string, the vocabulary the\n *   app-creation placement plan names in a `PlacementSubject`, and the vocabulary engine code\n *   addresses by enum member. It is declared here.\n *\n * The split was made 2026-09-09 because the second half had a consumer the first half's package\n * could never serve. `validatePlacementPlan`'s `UNKNOWN_SUBJECT` finding is a HARD FLOOR — it\n * refuses a landing — and it can only fire when a caller supplies the universe of subjects that\n * exist. Its one production caller is the app-creation semantic authority, a backend-side package\n * that must not depend on `saas-frontend-lib`. So a declared refusal had no holder, for no reason\n * other than where a list of sixteen strings was written down.\n *\n * Nothing is re-exported across the boundary: `saas-frontend-lib` imports the enum from here and\n * declares only the catalogue.\n */\n\n/** @wildo_source:part:start saas.frontend.settings-hub.engine-destinations facet:layer:frontend facet:family:config facet:audience:app-developer */\n/**\n * Every settings destination the engine ships, as a named vocabulary.\n *\n * Imported from `@wildo-ai/saas-models`. Exists because these refs are a CLOSED\n * vocabulary that engine code addresses by name — the billing command-menu entry\n * opens `/settings/billing`, and any future engine launcher will do the same.\n * Before this enum, `'billing'` was a bare literal in `billing-launcher.ts` with\n * nothing tying it to the catalog entry it names: rename the destination and the\n * command silently resolves to the hub's DEFAULT section instead of failing, so a\n * menu item labelled \"Billing\" would open Profile.\n *\n * **Engine code must address a destination through this enum. Application\n * config addresses one by string**, deliberately: a placement is authored data,\n * an application should not import an engine enum to write its own rail, and a\n * typo there is caught at DEV startup by `verifySettingsHubContent`.\n */\nexport enum EngineSettingsDestinationRef {\n  /** The signed-in user's own profile record. */\n  PROFILE = 'profile',\n  /** Password, MFA, sessions — a bespoke engine panel. */\n  SECURITY = 'security',\n  /** Theme and appearance preferences — a bespoke engine panel. */\n  APPEARANCE = 'appearance',\n  /** The signed-in user's own preference record. */\n  PREFERENCES = 'preferences',\n  /** Invitations addressed TO the signed-in user, across organizations they have not joined. */\n  MY_INVITATIONS = 'my-invitations',\n  /** The current organization's own record. Org owner/admin only. */\n  ORGANIZATION_GENERAL = 'organization-general',\n  /** Organization membership list, including INVITED rows. Org owner/admin only. */\n  MEMBERS = 'members',\n  /**\n   * The organization's internal structure — teams, departments, the hierarchy under the tenant.\n   *\n   * Its own rail entry rather than a tab inside {@link ORGANIZATION_GENERAL}. The general pane is a\n   * record — a column of decisions about the tenant itself — and a unit hierarchy is a population\n   * you navigate, which is a different kind of surface and a different task. Nesting it there also\n   * put it behind a pane a reader had no other reason to open.\n   */\n  ORGANIZATION_UNITS = 'organization-units',\n  /** Billing home — subscription, plans, usage, invoices. Gated on the `billingEnabled` capability. */\n  BILLING = 'billing',\n  /** Organization API keys. Org owner/admin only. */\n  API_KEYS = 'api-keys',\n  /**\n   * The tenant's OWN credentials toward third parties — its Slack workspace token, its CRM key.\n   *\n   * The mirror image of {@link API_KEYS} and easy to confuse with it: an API key is a credential\n   * somebody uses to reach THIS application, and one of these is a credential this application uses\n   * to reach somebody else ON THIS TENANT'S BEHALF. Same administrator, opposite direction.\n   */\n  PROVIDER_CREDENTIALS = 'provider-credentials',\n  /**\n   * The signed-in person's OWN credentials toward third parties — their personal API key, the\n   * account they connected themselves.\n   *\n   * Distinct from {@link PROVIDER_CREDENTIALS} by OWNER, not by feature, and the two must never be\n   * merged into one screen. A tenant's credential is a shared integration an administrator\n   * configures for everyone; this one is an individual's own account, which nobody else may see,\n   * spend or remove. Putting them on one page would put a colleague's personal vendor token in an\n   * administrator's view — and the resource's authorization refuses that, so the screen would show\n   * an empty list nobody could explain.\n   */\n  MY_PROVIDER_CREDENTIALS = 'my-provider-credentials',\n  /** Single sign-on configuration and connections. */\n  SSO = 'sso',\n  /** SCIM directory provisioning configuration and tokens. */\n  SCIM = 'scim',\n  /** Audit-event streaming configuration and failed-delivery queue. */\n  SIEM = 'siem',\n  /** Outbound webhook endpoints and delivery log. */\n  WEBHOOKS = 'webhooks',\n  /** The organization's audit log. Org owner/admin only. */\n  AUDIT_LOGS = 'audit-logs',\n  /**\n   * What THIS organization is currently entitled to — its features, its numeric limits, and the\n   * application-administrator exceptions laid over them.\n   *\n   * Readable by any organization member (`organizationFeatures` READ is `ORG_MEMBER`), which is why\n   * it carries no `requiredRoles`: a member who is told a surface needs an upgrade should be able to\n   * see what their organization actually has. The operations that CHANGE it — enable, disable, reset\n   * — are `APP_ADMIN_SUPER_ADMIN` on the resource itself, so the same screen is a read-only summary\n   * for a member and the grant/withdraw console for a platform administrator.\n   *\n   * Until this existed there was no way to reach the entitlement state from anywhere in the product:\n   * the resource had a table, an admin UI behaviour and three custom operations, and no door.\n   */\n  ORGANIZATION_ENTITLEMENTS = 'organization-entitlements',\n  /** Referral codes and their redemptions. Organization-scoped despite living in the billing domain. */\n  ORGANIZATION_REFERRALS = 'organization-referrals',\n\n  // ── Application administration ──────────────────────────────────────────────\n  //\n  // Everything below is `ResourcePrimaryScope.APPLICATION`: it configures the APPLICATION ITSELF\n  // rather than one tenant inside it, and it is the operator's surface, not a customer's. The\n  // category an application places these in is what supplies that scope, and\n  // `useVisibleSettingsHubConfig` resolves the application id from `appIdentity` — the access\n  // token does not carry one, so a category scoped this way was unreachable until 2026-09-17.\n  //\n  // Each mirrors an organization-scope sibling above, and the pairs are NOT redundant: an\n  // application-wide SSO connection authenticates everybody who is not covered by a tenant's own,\n  // and an application-wide SIEM export carries the operator's own security events rather than a\n  // customer's. Same mechanism, different principal, different consequence.\n\n  /** The application's own descriptive record — name, description, the operator's identity. */\n  APPLICATION_GENERAL = 'application-general',\n  /** Released versions of the application. */\n  APPLICATION_VERSIONS = 'application-versions',\n  /**\n   * OAuth clients registered against the APPLICATION — the credential a machine presents for a\n   * client-credentials or authorization-code exchange.\n   *\n   * The sibling of {@link APPLICATION_API_KEYS} rather than a duplicate of it: under\n   * client-credentials both authenticate the same `APPLICATION_MACHINE` principal, so they are two\n   * credential TYPES for one identity and belong side by side.\n   */\n  APPLICATION_OAUTH_CLIENTS = 'application-oauth-clients',\n  /**\n   * The two-person rule, made reviewable — requested, signed, time-bound elevations over the\n   * application-wide reads.\n   *\n   * Placed because a control of this kind is justified by VISIBILITY rather than by prevention:\n   * it does not stop an operator reading across tenants, it makes a second administrator sign for\n   * it and leaves a record. An elevation nobody can read makes nothing visible, so the mechanism\n   * ran without its own justification until this had a door.\n   */\n  APPLICATION_ACCESS_GRANTS = 'application-access-grants',\n  /**\n   * The application-wide audit trail — every tenant's events plus the ones belonging to no tenant.\n   *\n   * Distinct from the organization {@link AUDIT_LOGS} by the question it answers, not by scope\n   * alone: the tenant door answers \"what happened in my organization\", this one answers \"what\n   * happened at all\", and only the second can support a deployment-level attestation. Every read\n   * through it is a declared crossing and emits one event into each tenant it reached.\n   */\n  APPLICATION_AUDIT_LOGS = 'application-audit-logs',\n  /** The application-scope feature and limit state, with administrator exceptions. */\n  APPLICATION_ENTITLEMENTS = 'application-entitlements',\n  /** API keys that authenticate a machine to the APPLICATION rather than to one organization. */\n  APPLICATION_API_KEYS = 'application-api-keys',\n  /** Application-wide single sign-on: the configuration, and the connections it admits. */\n  APPLICATION_SSO = 'application-sso',\n  /**\n   * Application-wide SCIM directory provisioning.\n   *\n   * One target rather than the organization sibling's two tabs, and that asymmetry is real rather\n   * than an omission: there is no `APPLICATION_SCIM_TOKENS` resource — only\n   * `ORGANIZATION_SCIM_TOKENS` exists — so the application scope has a provisioning configuration\n   * and nothing to tab to.\n   */\n  APPLICATION_SCIM = 'application-scim',\n  /** Application-wide audit-event streaming, and the deliveries that failed. */\n  APPLICATION_SIEM = 'application-siem',\n  /** Application-wide outbound webhooks, and their delivery log. */\n  APPLICATION_WEBHOOKS = 'application-webhooks',\n  /**\n   * The billing CATALOGUE the application sells — products, their prices, and promotions.\n   *\n   * Distinct from the organization `BILLING` destination, which is one tenant's subscription and\n   * invoices. This is the operator editing what is on sale; that is a customer reading what they\n   * bought.\n   */\n  BILLING_CATALOG = 'billing-catalog',\n}\n\n/**\n * ## Two administration surfaces that are DELIBERATELY absent, so neither is re-proposed\n *\n * **A tenant directory.** `organizations` LIST looks like one and is not: it is confined by\n * `assignScopeRootCollectionConfinementToFilter` to the tenants the caller holds an\n * organization-wide role entry for, so a platform super-administrator sees THEIR OWN organizations\n * and not every tenant. That confinement is deliberate — the resource's own banner says so, and\n * says explicitly that an operator who \"cannot find the tenant id\" should stop rather than widen\n * the operation, because widening it hands the full customer list to every platform administrator\n * as a standing privilege. A destination named \"Organizations\" under Administration would promise\n * the directory and deliver the memberships, which is worse than having no entry: the reader\n * cannot tell the difference, and the number looks authoritative.\n *\n * **A user directory.** Same shape one level down. The application-wide user read is gated on a\n * two-person `applicationAccessGrants` window precisely so that it is not a standing privilege, so\n * a permanently-placed rail entry would either sit there refusing or quietly bypass the control it\n * is supposed to pass through.\n *\n * Both become placeable when a governed cross-tenant read exists — an operation that requires the\n * grant and says so. Neither becomes placeable by widening the operation that is already there.\n */\n/** @wildo_source:part:end saas.frontend.settings-hub.engine-destinations */\n\n/**\n * Every destination ref the engine ships — the set an authored placement is validated against.\n *\n * **Derived from the enum, not from the catalogue, and that is the point.** It used to be\n * `ENGINE_SETTINGS_DESTINATIONS.map(d => d.ref)`, which made the set a statement about how many\n * catalogue entries had been written rather than about what the vocabulary contains: a member added\n * to the enum and not yet given a catalogue entry would have been silently absent from the universe\n * a hard floor is measured against, so a placement naming it would have been refused as UNKNOWN.\n * Deriving from the enum is TOTAL over the vocabulary — a member added tomorrow is in this set the\n * same day — and the reverse obligation (every ref has a catalogue entry) is pinned in\n * `saas-frontend-lib`, where the catalogue lives and where an omission is a rendering defect.\n *\n * Values are bare ids, the shape `placementSubjectLocalKey` publishes for\n * `ENGINE_SETTINGS_DESTINATION` subjects, so this set can be handed to `validatePlacementPlan`\n * without being re-spelled.\n */\nexport const ENGINE_SETTINGS_DESTINATION_REFS: ReadonlySet<string> = new Set<string>(Object.values(EngineSettingsDestinationRef));\n"]}