npm - @wildo-ai/saas-models - Versions diffs - 1.1.4 → 1.1.5 - Mend

@wildo-ai/saas-models 1.1.4 → 1.1.5

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (1032) hide show

package/dist/esm/notifications/notifications.shared.schemas.js CHANGED Viewed

@@ -64,8 +64,9 @@ export const UserNotificationChannelSchema = z.union([
  * - **the category switch suppresses the notification entirely**, whether or not an address is
  *   configured. A tenant that turns billing notifications off means it for the members too.
  *
- * `ORGANIZATION` and `ORGANIZATION_USERS` are tenant-wide and belong to no category, so no switch can
- * silence them; a tenant-wide default address still redirects them.
+ * `ORGANIZATION` belongs to no category, so no category switch silences it; the tenant-wide
+ * `defaultEmailAddress` can redirect it. `ORGANIZATION_USERS` always keeps its member fan-out:
+ * neither a category switch nor the tenant-wide default address redirects or suppresses that target.
  *
  * This applies to EMAIL only. The websocket and in-product paths always fan out to the members.
  */
@@ -152,11 +153,18 @@ export const UserNotificationTargetSchema = z.union([
 // =====================================================
 // Celebration & Next-Step Enums (Phase 1a)
 // =====================================================
+/** @wildo_source:part:start saas.models.milestone-celebration */
 /**
- * How the frontend renders a celebration after a successful operation.
- * - OVERLAY: Full-screen overlay with animation (e.g., confetti + message)
- * - CONFETTI: Lightweight confetti burst (no overlay)
- * - LOTTIE: Custom Lottie animation (resolved by notification identifier)
+ * How the frontend renders a celebration after a successful operation — the value a milestone's
+ * `celebrationMode` takes. Import from `@wildo-ai/saas-models`.
+ * - CONFETTI: a lightweight, non-blocking confetti burst over the page. Decorative only: no message,
+ *   no next step, nothing to dismiss.
+ * - OVERLAY: a dialog carrying the celebration animation, the milestone's title, the message, an
+ *   optional next-step action and a dismiss.
+ * - LOTTIE: in the framework's DEFAULT celebration overlay, identical to OVERLAY — the same dialog
+ *   and the same animation. It is the mode to use when the application's OWN celebration-overlay
+ *   preset draws something distinct for it, such as a per-milestone animation chosen from the
+ *   notification identifier the preset receives.
  */
 export var CelebrationDisplayMode;
 (function (CelebrationDisplayMode) {
@@ -164,6 +172,7 @@ export var CelebrationDisplayMode;
     CelebrationDisplayMode["CONFETTI"] = "confetti";
     CelebrationDisplayMode["LOTTIE"] = "lottie";
 })(CelebrationDisplayMode || (CelebrationDisplayMode = {}));
+/** @wildo_source:part:end saas.models.milestone-celebration */
 /**
  * Type of next-step suggestion attached to a notification.
  * - OPERATION: Navigate to and/or trigger a resource operation
@@ -227,8 +236,10 @@ export const FrontendDisplayHintsSchema = z.object({
  *  - a recipient with NO preferences row at all, because preferences are created lazily and a missing
  *    record must never read as "everything off".
  *
- * The `inApp` switch governs the notification CENTRE on the frontend rather than the socket frame —
- * suppressing the frame would also suppress the live UI updates that ride the same channel.
+ * The `inApp` switch suppresses optional personal message presentation (toast, centre and celebration),
+ * not the socket frame. Declarative frames carry target and alwaysDeliver to the frontend gate;
+ * required and responsibility-addressed messages remain visible. Local operation feedback and
+ * resource refresh events are independent of this personal-message preference.
  *
  * ## `condition` gates the notification, not the operation
  *

package/dist/esm/notifications/notifications.shared.schemas.js.map CHANGED Viewed

	@@ -1 +1 @@
1	- {"version":3,"file":"notifications.shared.schemas.js","sourceRoot":"","sources":["../../../src/notifications/notifications.shared.schemas.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AACxB,OAAO,EAAE,oBAAoB,EAAE,MAAM,uCAAuC,CAAC;AAG7E,MAAM,CAAN,IAAY,2BAMX;AAND,WAAY,2BAA2B;IACrC,8CAAe,CAAA;IACf,0CAAW,CAAA;IACX,4CAAa,CAAA;IACb,sDAAuB,CAAA;IACvB,sEAAuC,CAAA;AACzC,CAAC,EANW,2BAA2B,KAA3B,2BAA2B,QAMtC;AAED,MAAM,CAAN,IAAY,qBAKX;AALD,WAAY,qBAAqB;IAC/B,sCAAa,CAAA;IACb,4CAAmB,CAAA;IACnB,4CAAmB,CAAA;IACnB,wCAAe,CAAA;AACjB,CAAC,EALW,qBAAqB,KAArB,qBAAqB,QAKhC;AAED,MAAM,CAAC,MAAM,6BAA6B,GAAG,CAAC,CAAC,KAAK,CAAC;IACjD,CAAC,CAAC,IAAI,CAAC,2BAA2B,CAAC;IACnC,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC;CACpB,CAAC,CAAC;AAGH,iHAAiH;AACjH;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAgDG;AACH,MAAM,CAAN,IAAY,0BAiBX;AAjBD,WAAY,0BAA0B;IAClC,qFAAuD,CAAA;IACvD,yEAA2C,CAAA;IAC3C,yFAA2D,CAAA;IAC3D,2EAA6C,CAAA;IAC7C,yEAA2C,CAAA;IAC3C,qEAAuC,CAAA;IACvC,mFAAqD,CAAA;IACrD,2DAA6B,CAAA;IAC7B,uEAAyC,CAAA;IACzC,2EAA6C,CAAA;IAC7C,2FAA6D,CAAA;IAC7D,yFAA2D,CAAA;IAC3D,6EAA+C,CAAA;IAC/C,qDAAuB,CAAA;IACvB,2DAA6B,CAAA;IAC7B,iEAAmC,CAAA;AACvC,CAAC,EAjBW,0BAA0B,KAA1B,0BAA0B,QAiBrC;AAED;;;;;;;;;;;;;;;;;;;;;GAqBG;AACH,MAAM,UAAU,yDAAyD,CAAC,MAAc;IACtF,OAAO,MAAM,KAAK,0BAA0B,CAAC,SAAS;WACjD,MAAM,KAAK,0BAA0B,CAAC,YAAY,CAAC;AAC1D,CAAC;AAED;;;;;;;;;;;;;;;;GAgBG;AACH,MAAM,UAAU,oCAAoC,CAAC,MAAc;IACjE,OAAO,MAAM,KAAK,0BAA0B,CAAC,oBAAoB;WAC5D,MAAM,KAAK,0BAA0B,CAAC,4BAA4B;WAClE,MAAM,KAAK,0BAA0B,CAAC,2BAA2B;WACjE,MAAM,KAAK,0BAA0B,CAAC,qBAAqB;WAC3D,MAAM,KAAK,0BAA0B,CAAC,yBAAyB;WAC/D,MAAM,KAAK,0BAA0B,CAAC,mBAAmB;WACzD,MAAM,KAAK,0BAA0B,CAAC,2BAA2B;WACjE,MAAM,KAAK,0BAA0B,CAAC,oBAAoB;WAC1D,MAAM,KAAK,0BAA0B,CAAC,mBAAmB;WACzD,MAAM,KAAK,0BAA0B,CAAC,iBAAiB;WACvD,MAAM,KAAK,0BAA0B,CAAC,wBAAwB,CAAC;AACtE,CAAC;AACD,+DAA+D;AAE/D,MAAM,CAAC,MAAM,4BAA4B,GAAG,CAAC,CAAC,KAAK,CAAC;IAChD,CAAC,CAAC,IAAI,CAAC,0BAA0B,CAAC;IAClC,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC;CACpB,CAAC,CAAC;AAIH,wDAAwD;AACxD,2CAA2C;AAC3C,wDAAwD;AAExD;;;;;GAKG;AACH,MAAM,CAAN,IAAY,sBAIX;AAJD,WAAY,sBAAsB;IAChC,6CAAmB,CAAA;IACnB,+CAAqB,CAAA;IACrB,2CAAiB,CAAA;AACnB,CAAC,EAJW,sBAAsB,KAAtB,sBAAsB,QAIjC;AAED;;;;GAIG;AACH,MAAM,CAAN,IAAY,wBAGX;AAHD,WAAY,wBAAwB;IAClC,mDAAuB,CAAA;IACvB,uCAAW,CAAA;AACb,CAAC,EAHW,wBAAwB,KAAxB,wBAAwB,QAGnC;AAED,wDAAwD;AACxD,2CAA2C;AAC3C,wDAAwD;AAExD,MAAM,CAAC,MAAM,qCAAqC,GAAG,CAAC,CAAC,MAAM,CAAC;IAC5D,IAAI,EAAE,CAAC,CAAC,IAAI,CAAC,sBAAsB,CAAC,CAAC,OAAO,CAAC,sBAAsB,CAAC,OAAO,CAAC;CAC7E,CAAC,CAAC;AAGH,MAAM,CAAC,MAAM,kCAAkC,GAAG,CAAC,CAAC,MAAM,CAAC;IACzD,2DAA2D;IAC3D,YAAY,EAAE,CAAC,CAAC,MAAM,EAAE;IACxB,IAAI,EAAE,CAAC,CAAC,IAAI,CAAC,wBAAwB,CAAC,CAAC,OAAO,CAAC,wBAAwB,CAAC,SAAS,CAAC;CACnF,CAAC,CAAC;AAGH,MAAM,CAAC,MAAM,0BAA0B,GAAG,CAAC,CAAC,MAAM,CAAC;IACjD,WAAW,EAAE,qCAAqC,CAAC,QAAQ,EAAE;IAC7D,QAAQ,EAAE,kCAAkC,CAAC,QAAQ,EAAE;CACxD,CAAC,CAAC;AAGH,wDAAwD;AACxD,gEAAgE;AAChE,wDAAwD;AAExD;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAsDG;AACH,MAAM,CAAC,MAAM,qCAAqC,GAAG,CAAC,CAAC,MAAM,CAAC;IAC1D,UAAU,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC;IAC7B,MAAM,EAAE,CAAC,CAAC,MAAM,EAAE;IAClB,KAAK,EAAE,CAAC,CAAC,IAAI,CAAC,qBAAqB,CAAC,CAAC,QAAQ,EAAE;IAC/C,YAAY,EAAE,CAAC,CAAC,IAAI,CAAC,oBAAoB,CAAC;IAC1C;;;OAGG;IACH,SAAS,EAAE,CAAC,CAAC,KAAK,CAAC,CAAC,CAAC,MAAM,EAAE,CAAC,CAAC,QAAQ,EAAE;IACzC,eAAe,EAAE,CAAC,CAAC,MAAM,CAOvB,CAAC,GAAG,EAAE,EAAE,CAAC,OAAO,GAAG,KAAK,UAAU,CAAC,CAAC,QAAQ,EAAE;IAChD;;;;;;;;;;;;;;;;;OAiBG;IACH,SAAS,EAAE,CAAC,CAAC,MAAM,CAOjB,CAAC,GAAG,EAAE,EAAE,CAAC,OAAO,GAAG,KAAK,UAAU,CAAC,CAAC,QAAQ,EAAE;IAChD;;;;;;;;;;;;OAYG;IACH,qBAAqB,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,QAAQ,EAAE;IACnD;;;;;;;;;;;;;;;OAeG;IACH,aAAa,EAAE,CAAC,CAAC,OAAO,EAAE,CAAC,QAAQ,EAAE;CACxC,CAAC,CAAC;AAEH,oCAAoC;AAEpC,2FAA2F;AAC3F,MAAM,CAAC,MAAM,sCAAsC,GAAG,qCAAqC,CAAC,MAAM,CAAC;IAC/F,OAAO,EAAE,CAAC,CAAC,OAAO,CAAC,2BAA2B,CAAC,KAAK,CAAC;IACrD;;;;;;;;;;;;;;;;;;;;;;;;OAwBG;IACH,mBAAmB,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,IAAI,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,QAAQ,EAAE;CAC3D,CAAC,CAAC;AAEH,oEAAoE;AACpE,MAAM,CAAC,MAAM,0CAA0C,GAAG,qCAAqC,CAAC,MAAM,CAAC;IACnG,OAAO,EAAE,CAAC,CAAC,OAAO,CAAC,2BAA2B,CAAC,SAAS,CAAC;CAC5D,CAAC,CAAC;AAEH;;;;;;;;;;;;;;;;;GAiBG;AACH,MAAM,CAAC,MAAM,gDAAgD,GAAG,qCAAqC,CAAC,MAAM,CAAC;IACzG,OAAO,EAAE,CAAC,CAAC,OAAO,CAAC,2BAA2B,CAAC,iBAAiB,CAAC;IACjE,8FAA8F;IAC9F,WAAW,EAAE,qCAAqC,CAAC,QAAQ,EAAE;IAC7D,gGAAgG;IAChG,QAAQ,EAAE,kCAAkC,CAAC,QAAQ,EAAE;CAC1D,CAAC,CAAC;AAEH,oDAAoD;AACpD,MAAM,CAAC,MAAM,oCAAoC,GAAG,qCAAqC,CAAC,MAAM,CAAC;IAC7F,OAAO,EAAE,CAAC,CAAC,OAAO,CAAC,2BAA2B,CAAC,GAAG,CAAC;CACtD,CAAC,CAAC;AAEH,qDAAqD;AACrD,MAAM,CAAC,MAAM,qCAAqC,GAAG,qCAAqC,CAAC,MAAM,CAAC;IAC9F,OAAO,EAAE,CAAC,CAAC,OAAO,CAAC,2BAA2B,CAAC,IAAI,CAAC;CACvD,CAAC,CAAC;AAEH,4EAA4E;AAC5E,MAAM,CAAC,MAAM,8CAA8C,GAAG,qCAAqC,CAAC,MAAM,CAAC;IACvG,OAAO,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC;CAC7B,CAAC,CAAC;AAEH;;;;;GAKG;AACH,MAAM,CAAC,MAAM,gCAAgC,GAAG,CAAC,CAAC,KAAK,CAAC;IACpD,sCAAsC;IACtC,0CAA0C;IAC1C,gDAAgD;IAChD,oCAAoC;IACpC,qCAAqC;IACrC,8CAA8C;CACjD,CAAC;IACA;;;;;;OAMG;KACF,WAAW,CAAC,CAAC,YAAY,EAAE,OAAO,EAAE,EAAE;IACrC,IAAI,YAAY,CAAC,SAAS,KAAK,SAAS,IAAI,CAAC,oCAAoC,CAAC,YAAY,CAAC,MAAM,CAAC,EAAE,CAAC;QACvG,OAAO,CAAC,QAAQ,CAAC;YACf,IAAI,EAAE,QAAQ;YACd,IAAI,EAAE,CAAC,WAAW,CAAC;YACnB,OAAO,EAAE,0EAA0E,YAAY,CAAC,MAAM,KAAK;kBACvG,sGAAsG;kBACtG,yEAAyE;SAC9E,CAAC,CAAC;IACL,CAAC;AACH,CAAC,CAAC,CAAC;AAEL,oFAAoF;AAEpF;;GAEG;AAIH,MAAM,CAAN,IAAY,oBAIT;AAJH,WAAY,oBAAoB;IAC5B,qCAAa,CAAA;IACb,2CAAmB,CAAA;IACnB,uCAAe,CAAA;AACjB,CAAC,EAJS,oBAAoB,KAApB,oBAAoB,QAI7B;AAEH,MAAM,CAAN,IAAY,0BAGX;AAHD,WAAY,0BAA0B;IAClC,2EAA6C,CAAA;IAC7C,yEAA2C,CAAA;AAC/C,CAAC,EAHW,0BAA0B,KAA1B,0BAA0B,QAGrC;AAED,MAAM,CAAC,MAAM,4BAA4B,GAAG,CAAC,CAAC,KAAK,CAAC;IAChD,CAAC,CAAC,IAAI,CAAC,0BAA0B,CAAC;IAClC,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC;CACpB,CAAC,CAAC;AAEH,MAAM,CAAC,MAAM,+BAA+B,GAAG,CAAC,CAAC,MAAM,CAAC;IACpD,UAAU,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC;IAC7B,OAAO,EAAE,CAAC,CAAC,MAAM,EAAE;IACnB,KAAK,EAAE,CAAC,CAAC,IAAI,CAAC,oBAAoB,CAAC,CAAC,QAAQ,EAAE;CACjD,CAAC,CAAC","sourcesContent":["import { z } from \"zod\";\nimport { ResourcePrimaryScope } from \"../resources/resources.shared.schemas\";\n\n\nexport enum CoreUserNotificationChannel {\n EMAIL = 'email',\n SMS = 'sms',\n PUSH = 'push',\n WEBSOCKET = 'websocket',\n FRONT_END_SUCCESS = 'front_end_success',\n}\n\nexport enum UserNotificationLevel {\n INFO = 'info',\n SUCCESS = 'success',\n WARNING = 'warning',\n ERROR = 'error',\n}\n\nexport const UserNotificationChannelSchema = z.union([\n z.enum(CoreUserNotificationChannel),\n z.string().min(1)\n]);\n\n\n/** @wildo_source:part:start saas.models.notifications.targets facet:layer:shared facet:audience:app-developer /\n/\n WHO a declared `userNotifications` entry reaches — and, on the EMAIL channel, whether the tenant\n * gets to redirect or silence it.\n \n Imported from `@wildo-ai/saas-models`. The target is the single most consequential field of a\n * notification declaration, because it decides three separate things at once:\n \n 1. the recipients — resolved per member below;\n * 2. whether the recipient's own channel preference can suppress it — only `USER_SELF` and\n * `USERS_CUSTOM` are suppressible, because only they reach a person about their own affairs. Every\n * other target reaches somebody because of a ROLE they hold, and a personal switch must not\n * silently disable a tenant's administrative monitoring. See\n * {@link userNotificationTargetIsSuppressibleByRecipientPreference};\n * 3. whether `userRoles` is read at all — see {@link userNotificationTargetReadsUserRoles}. On the\n * two tenant-wide targets the field is REFUSED rather than ignored, because \"everyone in the\n * tenant\" is not a set a role list may narrow.\n \n ## Who each target resolves to\n \n \| target \| recipients \|\n * \|---\|---\|\n * \| `USER_SELF` \| the initiator of the operation \|\n * \| `USERS_CUSTOM` \| whatever your `userIdsSelector` returns. Without that function the target resolves nobody \|\n * \| `ORGANIZATION`, `ORGANIZATION_USERS` \| every member of the initiator's tenant. `userRoles` is refused here \|\n * \| `ORGANIZATION_BILLING`, `ORGANIZATION_SECURITY`, `ORGANIZATION_USER_MANAGEMENT`, `ORGANIZATION_ADMINISTRATIVE` \| members of the tenant holding `ORG_OWNER` or `ORG_ADMIN`, unless `userRoles` names a different set \|\n * \| `APPLICATION_BILLING` \| holders of `APP_ADMIN_BILLING_MANAGER` or `APP_ADMIN_SUPER_ADMIN`, application-wide \|\n * \| `APPLICATION_ADMIN_VIEWER` \| holders of `APP_ADMIN_VIEWER` or `APP_ADMIN_SUPER_ADMIN` \|\n * \| every other `APPLICATION_` \| holders of `APP_ADMIN_SUPER_ADMIN` \|\n \| `INBOUND_CONTACT` \| nobody, deliberately. The recipient is not a user of your application, so this target is only usable with an EMAIL notification declaring `recipientEmailField` \|\n \n A target the dispatcher has no rule for resolves nobody and logs a warning — so a custom target\n * string (the schema accepts one) sends nothing on the email and websocket paths.\n \n ## The tenant can redirect or silence an ORGANIZATION-flavoured EMAIL, and you cannot override it\n \n Each tenant owns a notification-settings record with a per-category switch and a per-category\n * address, and the category is DERIVED from the target — `ORGANIZATION_BILLING` to `billing`,\n * `ORGANIZATION_SECURITY` to `security`, and so on. Two consequences to design around:\n \n - a configured address REPLACES the member fan-out, it does not add to it. A tenant routing\n * security mail to a monitoring address is saying where that mail goes, not asking for a copy;\n * - the category switch suppresses the notification entirely, whether or not an address is\n * configured. A tenant that turns billing notifications off means it for the members too.\n \n `ORGANIZATION` and `ORGANIZATION_USERS` are tenant-wide and belong to no category, so no switch can\n * silence them; a tenant-wide default address still redirects them.\n \n This applies to EMAIL only. The websocket and in-product paths always fan out to the members.\n /\nexport enum CoreUserNotificationTarget {\n APPLICATION_ADMINISTRATOR = 'application_administrator',\n APPLICATION_BILLING = 'application_billing',\n APPLICATION_USER_MANAGEMENT = 'application_user_management',\n APPLICATION_SECURITY = 'application_security',\n APPLICATION_SUPPORT = 'application_support',\n APPLICATION_OTHER = 'application_other',\n APPLICATION_ADMIN_VIEWER = 'application_admin_viewer',\n ORGANIZATION = 'organization',\n ORGANIZATION_USERS = 'organization_users',\n ORGANIZATION_BILLING = 'organization_billing',\n ORGANIZATION_USER_MANAGEMENT = 'organization_user_management',\n ORGANIZATION_ADMINISTRATIVE = 'organization_administrative',\n ORGANIZATION_SECURITY = 'organization_security',\n USER_SELF = 'user_self',\n USERS_CUSTOM = 'users_custom',\n INBOUND_CONTACT = 'inbound_contact',\n}\n\n/\n Whether a notification aimed at this target may be SUPPRESSED by the recipient's own channel\n * preference (`UserPreferences.notifications.email` / `.sms` / `.push` / `.inApp`).\n \n DERIVED from the target rather than declared per notification, because the target already carries\n * the distinction and a second field would be one more thing to get wrong on 87 declarations.\n \n `USER_SELF` and `USERS_CUSTOM` reach a PERSON about their own affairs — those are the messages a\n * person is choosing about when they turn a channel off, and honouring that choice is the whole\n * point of the switch existing (#409).\n \n Every other target reaches somebody because of a ROLE they hold: an application administrator, an\n * organization's security or billing contact. A personal channel preference must not silently\n * disable a tenant's or an application's administrative monitoring — the recipient did not choose to\n * receive those as a person and cannot switch them off as one. A tenant that wants role mail\n * elsewhere routes it, which is what the organization notification-settings record is for.\n \n Nothing here reaches account RECOVERY. Password reset, magic link and email verification are sent\n * directly through the email service and never pass through the notification dispatcher, so no\n * channel preference can lock a person out of their own account. That measurement is what made\n * suppression safe to implement at all.\n /\nexport function userNotificationTargetIsSuppressibleByRecipientPreference(target: string): boolean {\n return target === CoreUserNotificationTarget.USER_SELF\n \|\| target === CoreUserNotificationTarget.USERS_CUSTOM;\n}\n\n/\n The targets on which `userRoles` MEANS anything (#495).\n \n `userRoles` is not a recipient FILTER, which is how its name reads and how it has been authored. It\n * is the role-SELECTION override for the eleven role-scoped targets: `mapOrganizationTargetToRoles`\n * and `mapApplicationTargetToRoles` take it in place of their per-target default, and nothing else\n * anywhere reads it.\n \n On every other target it is inert, and inert in three different ways that all looked the same to an\n * author: `USER_SELF` addresses the initiator, `USERS_CUSTOM` goes straight to `userIdsSelector`, and\n * `ORGANIZATION`/`ORGANIZATION_USERS` mean everyone in the tenant by definition. Declaring it there\n * is a filter that silently does nothing, which is what the refinement below now refuses.\n \n Scoped as a POSITIVE list of targets that read it rather than a rule about one target, because the\n * defect was never specific to `USERS_CUSTOM` — refusing it there alone would leave the other three\n * free to mislead the next author in exactly the same way.\n /\nexport function userNotificationTargetReadsUserRoles(target: string): boolean {\n return target === CoreUserNotificationTarget.ORGANIZATION_BILLING\n \|\| target === CoreUserNotificationTarget.ORGANIZATION_USER_MANAGEMENT\n \|\| target === CoreUserNotificationTarget.ORGANIZATION_ADMINISTRATIVE\n \|\| target === CoreUserNotificationTarget.ORGANIZATION_SECURITY\n \|\| target === CoreUserNotificationTarget.APPLICATION_ADMINISTRATOR\n \|\| target === CoreUserNotificationTarget.APPLICATION_BILLING\n \|\| target === CoreUserNotificationTarget.APPLICATION_USER_MANAGEMENT\n \|\| target === CoreUserNotificationTarget.APPLICATION_SECURITY\n \|\| target === CoreUserNotificationTarget.APPLICATION_SUPPORT\n \|\| target === CoreUserNotificationTarget.APPLICATION_OTHER\n \|\| target === CoreUserNotificationTarget.APPLICATION_ADMIN_VIEWER;\n}\n/* @wildo_source:part:end saas.models.notifications.targets /\n\nexport const UserNotificationTargetSchema = z.union([\n z.enum(CoreUserNotificationTarget),\n z.string().min(1)\n]);\n\n\n\n// =====================================================\n// Celebration & Next-Step Enums (Phase 1a)\n// =====================================================\n\n/\n How the frontend renders a celebration after a successful operation.\n * - OVERLAY: Full-screen overlay with animation (e.g., confetti + message)\n * - CONFETTI: Lightweight confetti burst (no overlay)\n * - LOTTIE: Custom Lottie animation (resolved by notification identifier)\n /\nexport enum CelebrationDisplayMode {\n OVERLAY = 'overlay',\n CONFETTI = 'confetti',\n LOTTIE = 'lottie',\n}\n\n/\n Type of next-step suggestion attached to a notification.\n * - OPERATION: Navigate to and/or trigger a resource operation\n * - URL: Navigate to an arbitrary URL (internal or external)\n /\nexport enum NotificationNextStepType {\n OPERATION = 'operation',\n URL = 'url',\n}\n\n// =====================================================\n// Frontend Display Hints Schema (reusable)\n// =====================================================\n\nexport const FrontendDisplayHintsCelebrationSchema = z.object({\n mode: z.enum(CelebrationDisplayMode).default(CelebrationDisplayMode.OVERLAY),\n});\nexport type FrontendDisplayHintsCelebration = z.infer<typeof FrontendDisplayHintsCelebrationSchema>;\n\nexport const FrontendDisplayHintsNextStepSchema = z.object({\n /* Operation path (e.g., \"TASKS.CREATE.default\") or URL /\n operationRef: z.string(),\n type: z.enum(NotificationNextStepType).default(NotificationNextStepType.OPERATION),\n});\nexport type FrontendDisplayHintsNextStep = z.infer<typeof FrontendDisplayHintsNextStepSchema>;\n\nexport const FrontendDisplayHintsSchema = z.object({\n celebration: FrontendDisplayHintsCelebrationSchema.optional(),\n nextStep: FrontendDisplayHintsNextStepSchema.optional(),\n});\nexport type FrontendDisplayHints = z.infer<typeof FrontendDisplayHintsSchema>;\n\n// =====================================================\n// UserNotificationDefinition — Discriminated Union on `channel`\n// =====================================================\n\n/\n @wildo_source:part:start saas.models.notifications.user-notification-definition facet:layer:shared facet:audience:app-developer\n \n One notification an operation sends. Declared as `userNotifications` on a resource operation, in\n * the resource config — an array, so one operation may send several.\n \n ```ts\n * userNotifications: [\n * { target: CoreUserNotificationTarget.USER_SELF, channel: CoreUserNotificationChannel.EMAIL,\n * condition: ({ currentObject }) => currentObject.status === 'INVITED' },\n * { target: CoreUserNotificationTarget.ORGANIZATION_USERS, channel: CoreUserNotificationChannel.WEBSOCKET },\n * ]\n * ```\n \n ## What actually sends\n \n `EMAIL`, `WEBSOCKET` and `FRONT_END_SUCCESS` deliver. *`SMS` and `PUSH` are declaration vocabulary\n only** — the dispatcher's branch for them logs and returns without sending. The framework does have\n * an SMS transport (authentication's one-time codes use it) and this dispatcher is not wired to it,\n * so declaring an SMS notification is inert rather than pending.\n \n For an EMAIL, create the template directory the reference names. The startup validator resolves\n * every declared reference through the configured locale chain before the application takes traffic,\n * and prints the exact directory to create when one is missing.\n \n ## The recipient's preferences are honoured, and three things override them\n \n A recipient who has switched a channel off does not receive it. Three deliberate exceptions:\n \n - a ROLE-addressed target — the recipient did not choose to receive it as a person;\n * - `alwaysDeliver: true` — declare it on a security notice a compromised account's owner must still\n * receive;\n * - a recipient with NO preferences row at all, because preferences are created lazily and a missing\n * record must never read as \"everything off\".\n \n The `inApp` switch governs the notification CENTRE on the frontend rather than the socket frame —\n * suppressing the frame would also suppress the live UI updates that ride the same channel.\n \n ## `condition` gates the notification, not the operation\n \n The predicate goes on the notification. It decides only whether this one message is sent; refusing\n * the CALL is a separate declaration on the operation variant, and the two are independent — a\n * variant can be enabled while its notification is gated off, and the reverse. The form deliberately\n * matches an operation variant's `enabledCondition` so both read the same way.\n \n ## Emailing somebody who is not a user\n \n `recipientEmailField` names a TOP-LEVEL field on the record holding the address. There is no\n * recipient, so there are no recipient preferences and no recipient language: the message goes out in\n * the application's default locale. A nested address cannot be named, nor a list — the path sends\n * exactly one message per notification. Pair it with a `condition` when the same operation also\n * serves rows whose address belongs to somebody who must not be written to.\n \n Base fields shared by all user notification channel variants.\n /\nexport const UserNotificationDefinition_BaseSchema = z.object({\n identifier: z.string().min(1),\n target: z.string(),\n level: z.enum(UserNotificationLevel).optional(),\n primaryScope: z.enum(ResourcePrimaryScope),\n /\n Role-SELECTION override for a role-scoped target — NOT a recipient filter. See\n * {@link userNotificationTargetReadsUserRoles}, which is also what refuses it elsewhere.\n /\n userRoles: z.array(z.string()).optional(),\n userIdsSelector: z.custom<\n (params: {\n currentObject: any;\n inputDto: any;\n objectContext: { parents: Record<string, any>; children: Record<string, any> };\n initiatorIds: { userId?: string; organizationId?: string; applicationId?: string };\n }) => string[]\n >((val) => typeof val === 'function').optional(),\n /\n Optional gate — dispatch this notification ONLY when the predicate returns truthy\n * against the post-operation context. Absent = always dispatches (backward compatible).\n * Evaluated per-notification BEFORE channel resolution, so it uniformly gates every\n * channel (email/websocket/front-end-success/…).\n \n The canonical use is a POLYMORPHIC operation whose notification must fire for only one\n * branch: the org-member CREATE op serves both INVITE (`status` INVITED — send the invite\n * email to `userEmail`) and DIRECT-ADD (`status` ACTIVE — founder / SSO-JIT / SCIM, whose\n * `userEmail` is the member's OWN address, so an \"you've been invited\" email is a\n * misdelivery). Keying on `currentObject.status === INVITED` fires the invite email for\n * invites only.\n \n Params mirror `userIdsSelector` (its sibling), so an author writes the same\n * `({ currentObject }) => …` form used by the operation-variant `enabledCondition`.\n \n @example `({ currentObject }) => currentObject.status === OrganizationMemberStatus.INVITED`\n /\n condition: z.custom<\n (params: {\n currentObject: any;\n inputDto: any;\n objectContext: { parents: Record<string, any>; children: Record<string, any> };\n initiatorIds: { userId?: string; organizationId?: string; applicationId?: string };\n }) => boolean\n >((val) => typeof val === 'function').optional(),\n /\n Custom notification reference for disambiguating multiple notifications of the same type.\n \n REQUIRED when:\n * - There are 2+ notifications with the same target in the same operation\n * - Example: 2+ USERS_CUSTOM notifications (one for creator, one for assignee)\n \n This allows distinguishing between multiple similar notifications\n * in the same operation (e.g., \"notify-creator\" vs \"notify-assignee\").\n \n Format: lowercase-kebab-case (e.g., \"notify-creator\", \"task-assigned\")\n * Will be appended to auto-generated identifier for notification/template lookup.\n /\n customNotificationRef: z.string().min(1).optional(),\n /\n Deliver this notification even when the recipient has switched its channel OFF.\n \n Only meaningful on a target that is suppressible in the first place — `USER_SELF` and\n * `USERS_CUSTOM` (see `userNotificationTargetIsSuppressibleByRecipientPreference`). On a\n * role-addressed target the preference never applied, so this flag changes nothing there.\n \n The narrow escape, for the case the target axis cannot express: a message that reaches a\n * person about their OWN affairs and is nevertheless a security notice they should not be able\n * to silence — a credential minted or destroyed on their account, an authentication factor\n * changed. Those are the alerts a person most needs when they did NOT perform the action.\n \n Author it with the reason at the site. It is deliberately not a default and deliberately not\n * derived: \"is this alert one a compromised account's owner must still receive?\" is a judgement\n * about the message, and inventing a rule for it would be a rule nobody could check.\n /\n alwaysDeliver: z.boolean().optional(),\n});\n\n// --- Channel-specific variants ---\n\n/* EMAIL channel — template-oriented (email-specific fields handled by email templates) /\nexport const UserNotificationDefinition_EmailSchema = UserNotificationDefinition_BaseSchema.extend({\n channel: z.literal(CoreUserNotificationChannel.EMAIL),\n /\n Deliver this email to a raw address read from the current object, rather than\n * to a resolved platform user.\n \n When set, the recipient is `currentObject[recipientEmailField]` (a top-level\n * string field — e.g. `'email'`). The dispatcher sends a single email directly to\n * that address using the application's default locale, BYPASSING the `userId`-based\n * `target` resolution entirely.\n \n This is the framework's mechanism for notifying a party who is *not (yet) a\n platform user** — an organization-invitation invitee, an inbound lead — for whom\n * no `userId` exists. Without it, the only email recipients the dispatcher can\n * resolve are members/initiators by id (`fetchUserContext(userId).email`).\n \n When this is set, `target` no longer selects the recipient; it is retained only\n * to (a) classify the notification, (b) drive the email `templateRef` derivation,\n * and (c) route the dashboard URL (admin app vs main app). Choose a `target` whose\n * dashboard-routing class matches the recipient (e.g. `USER_SELF` for a main-app\n * link).\n \n All other context is built identically to a user-targeted email (organization\n * name, initiator name, and the token `acceptUrl` enricher), so token-bearing\n * emails such as invitations still carry their `<frontendBase><emailLinkPath>?token=`\n * acceptance link.\n /\n recipientEmailField: z.string().trim().min(1).optional(),\n});\n\n/* WEBSOCKET channel — pure WebSocket push (no frontend display) /\nexport const UserNotificationDefinition_WebSocketSchema = UserNotificationDefinition_BaseSchema.extend({\n channel: z.literal(CoreUserNotificationChannel.WEBSOCKET),\n});\n\n/\n FRONT_END_SUCCESS channel — frontend display with optional celebration + nextStep.\n \n `celebration`: Tells the frontend to render richer feedback than a simple toast.\n * `nextStep`: Suggested next action rendered as a CTA button in the toast or celebration overlay.\n \n Example usage in operation config:\n * ```\n * userNotifications: [{\n * identifier: 'first-document-created',\n * target: CoreUserNotificationTarget.USER_SELF,\n * channel: CoreUserNotificationChannel.FRONT_END_SUCCESS,\n * primaryScope: ResourcePrimaryScope.ORGANIZATIONS,\n * celebration: { mode: CelebrationDisplayMode.OVERLAY },\n * nextStep: { operationRef: 'DOCUMENTS.LIST.default', type: NotificationNextStepType.OPERATION },\n * }]\n * ```\n /\nexport const UserNotificationDefinition_FrontEndSuccessSchema = UserNotificationDefinition_BaseSchema.extend({\n channel: z.literal(CoreUserNotificationChannel.FRONT_END_SUCCESS),\n /* Celebration display hints — triggers richer frontend feedback (overlay/confetti/lottie) /\n celebration: FrontendDisplayHintsCelebrationSchema.optional(),\n /* Suggested next action after operation completes — rendered as CTA in toast or celebration /\n nextStep: FrontendDisplayHintsNextStepSchema.optional(),\n});\n\n/* SMS channel — not yet implemented, plain base /\nexport const UserNotificationDefinition_SMSSchema = UserNotificationDefinition_BaseSchema.extend({\n channel: z.literal(CoreUserNotificationChannel.SMS),\n});\n\n/* PUSH channel — not yet implemented, plain base /\nexport const UserNotificationDefinition_PushSchema = UserNotificationDefinition_BaseSchema.extend({\n channel: z.literal(CoreUserNotificationChannel.PUSH),\n});\n\n/* Catch-all for custom channels (any string not matching core channels) /\nexport const UserNotificationDefinition_CustomChannelSchema = UserNotificationDefinition_BaseSchema.extend({\n channel: z.string().min(1),\n});\n\n/\n Final union of all notification channel variants.\n * Uses z.union() (not z.discriminatedUnion) because the catch-all custom channel\n * uses z.string() which is not a literal discriminant.\n * Order matters: specific literals are tried before the catch-all string.\n /\nexport const UserNotificationDefinitionSchema = z.union([\n UserNotificationDefinition_EmailSchema,\n UserNotificationDefinition_WebSocketSchema,\n UserNotificationDefinition_FrontEndSuccessSchema,\n UserNotificationDefinition_SMSSchema,\n UserNotificationDefinition_PushSchema,\n UserNotificationDefinition_CustomChannelSchema,\n])\n /\n `userRoles` on a target that never reads it is a filter that silently does nothing (#495).\n \n Refined on the UNION rather than on the base object, deliberately: the base is `.extend()`ed by\n * six channel variants, and a refinement there would be dropped by every one of them — the shape of\n * bug this refinement exists to prevent.\n /\n .superRefine((notification, context) => {\n if (notification.userRoles !== undefined && !userNotificationTargetReadsUserRoles(notification.target)) {\n context.addIssue({\n code: 'custom',\n path: ['userRoles'],\n message: `userRoles is only read for a role-scoped target and would be inert on \"${notification.target}\". `\n + 'It selects WHICH roles a role-scoped target reaches; it does not filter the recipients of any other '\n + 'target. Remove it, or address the notification to a role-scoped target.',\n });\n }\n });\nexport type UserNotificationDefinition = z.infer<typeof UserNotificationDefinitionSchema>;\n/* @wildo_source:part:end saas.models.notifications.user-notification-definition /\n\n/\n M2M Notification Channels\n /\n\n\n\nexport enum M2MNotificationLevel {\n INFO = 'info',\n SUCCESS = 'success',\n ERROR = 'error',\n }\n\nexport enum CoreM2MNotificationChannel {\n WEBHOOK_ORGANIZATION = 'webhook_organization',\n WEBHOOK_APPLICATION = 'webhook_application',\n}\n\nexport const M2MNotificationChannelSchema = z.union([\n z.enum(CoreM2MNotificationChannel),\n z.string().min(1)\n]);\n\nexport const M2MNotificationDefinitionSchema = z.object({\n identifier: z.string().min(1),\n channel: z.string(),\n level: z.enum(M2MNotificationLevel).optional(),\n});\nexport type M2MNotificationDefinition = z.infer<typeof M2MNotificationDefinitionSchema>;\n\n/\n Inferred types (interfaces defined above for isolatedDeclarations compatibility)\n */\n\nexport type UserNotificationTarget = string;\nexport type NotificationChannel = string;\nexport type M2MNotificationChannel = string;\n"]}
1	+ {"version":3,"file":"notifications.shared.schemas.js","sourceRoot":"","sources":["../../../../src/notifications/notifications.shared.schemas.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AACxB,OAAO,EAAE,oBAAoB,EAAE,MAAM,uCAAuC,CAAC;AAG7E,MAAM,CAAN,IAAY,2BAMX;AAND,WAAY,2BAA2B;IACrC,8CAAe,CAAA;IACf,0CAAW,CAAA;IACX,4CAAa,CAAA;IACb,sDAAuB,CAAA;IACvB,sEAAuC,CAAA;AACzC,CAAC,EANW,2BAA2B,KAA3B,2BAA2B,QAMtC;AAED,MAAM,CAAN,IAAY,qBAKX;AALD,WAAY,qBAAqB;IAC/B,sCAAa,CAAA;IACb,4CAAmB,CAAA;IACnB,4CAAmB,CAAA;IACnB,wCAAe,CAAA;AACjB,CAAC,EALW,qBAAqB,KAArB,qBAAqB,QAKhC;AAED,MAAM,CAAC,MAAM,6BAA6B,GAAG,CAAC,CAAC,KAAK,CAAC;IACjD,CAAC,CAAC,IAAI,CAAC,2BAA2B,CAAC;IACnC,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC;CACpB,CAAC,CAAC;AAGH,iHAAiH;AACjH;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAiDG;AACH,MAAM,CAAN,IAAY,0BAiBX;AAjBD,WAAY,0BAA0B;IAClC,qFAAuD,CAAA;IACvD,yEAA2C,CAAA;IAC3C,yFAA2D,CAAA;IAC3D,2EAA6C,CAAA;IAC7C,yEAA2C,CAAA;IAC3C,qEAAuC,CAAA;IACvC,mFAAqD,CAAA;IACrD,2DAA6B,CAAA;IAC7B,uEAAyC,CAAA;IACzC,2EAA6C,CAAA;IAC7C,2FAA6D,CAAA;IAC7D,yFAA2D,CAAA;IAC3D,6EAA+C,CAAA;IAC/C,qDAAuB,CAAA;IACvB,2DAA6B,CAAA;IAC7B,iEAAmC,CAAA;AACvC,CAAC,EAjBW,0BAA0B,KAA1B,0BAA0B,QAiBrC;AAED;;;;;;;;;;;;;;;;;;;;;GAqBG;AACH,MAAM,UAAU,yDAAyD,CAAC,MAAc;IACtF,OAAO,MAAM,KAAK,0BAA0B,CAAC,SAAS;WACjD,MAAM,KAAK,0BAA0B,CAAC,YAAY,CAAC;AAC1D,CAAC;AAED;;;;;;;;;;;;;;;;GAgBG;AACH,MAAM,UAAU,oCAAoC,CAAC,MAAc;IACjE,OAAO,MAAM,KAAK,0BAA0B,CAAC,oBAAoB;WAC5D,MAAM,KAAK,0BAA0B,CAAC,4BAA4B;WAClE,MAAM,KAAK,0BAA0B,CAAC,2BAA2B;WACjE,MAAM,KAAK,0BAA0B,CAAC,qBAAqB;WAC3D,MAAM,KAAK,0BAA0B,CAAC,yBAAyB;WAC/D,MAAM,KAAK,0BAA0B,CAAC,mBAAmB;WACzD,MAAM,KAAK,0BAA0B,CAAC,2BAA2B;WACjE,MAAM,KAAK,0BAA0B,CAAC,oBAAoB;WAC1D,MAAM,KAAK,0BAA0B,CAAC,mBAAmB;WACzD,MAAM,KAAK,0BAA0B,CAAC,iBAAiB;WACvD,MAAM,KAAK,0BAA0B,CAAC,wBAAwB,CAAC;AACtE,CAAC;AACD,+DAA+D;AAE/D,MAAM,CAAC,MAAM,4BAA4B,GAAG,CAAC,CAAC,KAAK,CAAC;IAChD,CAAC,CAAC,IAAI,CAAC,0BAA0B,CAAC;IAClC,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC;CACpB,CAAC,CAAC;AAIH,wDAAwD;AACxD,2CAA2C;AAC3C,wDAAwD;AAExD,iEAAiE;AACjE;;;;;;;;;;;GAWG;AACH,MAAM,CAAN,IAAY,sBAIX;AAJD,WAAY,sBAAsB;IAChC,6CAAmB,CAAA;IACnB,+CAAqB,CAAA;IACrB,2CAAiB,CAAA;AACnB,CAAC,EAJW,sBAAsB,KAAtB,sBAAsB,QAIjC;AACD,+DAA+D;AAE/D;;;;GAIG;AACH,MAAM,CAAN,IAAY,wBAGX;AAHD,WAAY,wBAAwB;IAClC,mDAAuB,CAAA;IACvB,uCAAW,CAAA;AACb,CAAC,EAHW,wBAAwB,KAAxB,wBAAwB,QAGnC;AAED,wDAAwD;AACxD,2CAA2C;AAC3C,wDAAwD;AAExD,MAAM,CAAC,MAAM,qCAAqC,GAAG,CAAC,CAAC,MAAM,CAAC;IAC5D,IAAI,EAAE,CAAC,CAAC,IAAI,CAAC,sBAAsB,CAAC,CAAC,OAAO,CAAC,sBAAsB,CAAC,OAAO,CAAC;CAC7E,CAAC,CAAC;AAGH,MAAM,CAAC,MAAM,kCAAkC,GAAG,CAAC,CAAC,MAAM,CAAC;IACzD,2DAA2D;IAC3D,YAAY,EAAE,CAAC,CAAC,MAAM,EAAE;IACxB,IAAI,EAAE,CAAC,CAAC,IAAI,CAAC,wBAAwB,CAAC,CAAC,OAAO,CAAC,wBAAwB,CAAC,SAAS,CAAC;CACnF,CAAC,CAAC;AAGH,MAAM,CAAC,MAAM,0BAA0B,GAAG,CAAC,CAAC,MAAM,CAAC;IACjD,WAAW,EAAE,qCAAqC,CAAC,QAAQ,EAAE;IAC7D,QAAQ,EAAE,kCAAkC,CAAC,QAAQ,EAAE;CACxD,CAAC,CAAC;AAGH,wDAAwD;AACxD,gEAAgE;AAChE,wDAAwD;AAExD;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAwDG;AACH,MAAM,CAAC,MAAM,qCAAqC,GAAG,CAAC,CAAC,MAAM,CAAC;IAC1D,UAAU,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC;IAC7B,MAAM,EAAE,CAAC,CAAC,MAAM,EAAE;IAClB,KAAK,EAAE,CAAC,CAAC,IAAI,CAAC,qBAAqB,CAAC,CAAC,QAAQ,EAAE;IAC/C,YAAY,EAAE,CAAC,CAAC,IAAI,CAAC,oBAAoB,CAAC;IAC1C;;;OAGG;IACH,SAAS,EAAE,CAAC,CAAC,KAAK,CAAC,CAAC,CAAC,MAAM,EAAE,CAAC,CAAC,QAAQ,EAAE;IACzC,eAAe,EAAE,CAAC,CAAC,MAAM,CAOvB,CAAC,GAAG,EAAE,EAAE,CAAC,OAAO,GAAG,KAAK,UAAU,CAAC,CAAC,QAAQ,EAAE;IAChD;;;;;;;;;;;;;;;;;OAiBG;IACH,SAAS,EAAE,CAAC,CAAC,MAAM,CAOjB,CAAC,GAAG,EAAE,EAAE,CAAC,OAAO,GAAG,KAAK,UAAU,CAAC,CAAC,QAAQ,EAAE;IAChD;;;;;;;;;;;;OAYG;IACH,qBAAqB,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,QAAQ,EAAE;IACnD;;;;;;;;;;;;;;;OAeG;IACH,aAAa,EAAE,CAAC,CAAC,OAAO,EAAE,CAAC,QAAQ,EAAE;CACxC,CAAC,CAAC;AAEH,oCAAoC;AAEpC,2FAA2F;AAC3F,MAAM,CAAC,MAAM,sCAAsC,GAAG,qCAAqC,CAAC,MAAM,CAAC;IAC/F,OAAO,EAAE,CAAC,CAAC,OAAO,CAAC,2BAA2B,CAAC,KAAK,CAAC;IACrD;;;;;;;;;;;;;;;;;;;;;;;;OAwBG;IACH,mBAAmB,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,IAAI,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,QAAQ,EAAE;CAC3D,CAAC,CAAC;AAEH,oEAAoE;AACpE,MAAM,CAAC,MAAM,0CAA0C,GAAG,qCAAqC,CAAC,MAAM,CAAC;IACnG,OAAO,EAAE,CAAC,CAAC,OAAO,CAAC,2BAA2B,CAAC,SAAS,CAAC;CAC5D,CAAC,CAAC;AAEH;;;;;;;;;;;;;;;;;GAiBG;AACH,MAAM,CAAC,MAAM,gDAAgD,GAAG,qCAAqC,CAAC,MAAM,CAAC;IACzG,OAAO,EAAE,CAAC,CAAC,OAAO,CAAC,2BAA2B,CAAC,iBAAiB,CAAC;IACjE,8FAA8F;IAC9F,WAAW,EAAE,qCAAqC,CAAC,QAAQ,EAAE;IAC7D,gGAAgG;IAChG,QAAQ,EAAE,kCAAkC,CAAC,QAAQ,EAAE;CAC1D,CAAC,CAAC;AAEH,oDAAoD;AACpD,MAAM,CAAC,MAAM,oCAAoC,GAAG,qCAAqC,CAAC,MAAM,CAAC;IAC7F,OAAO,EAAE,CAAC,CAAC,OAAO,CAAC,2BAA2B,CAAC,GAAG,CAAC;CACtD,CAAC,CAAC;AAEH,qDAAqD;AACrD,MAAM,CAAC,MAAM,qCAAqC,GAAG,qCAAqC,CAAC,MAAM,CAAC;IAC9F,OAAO,EAAE,CAAC,CAAC,OAAO,CAAC,2BAA2B,CAAC,IAAI,CAAC;CACvD,CAAC,CAAC;AAEH,4EAA4E;AAC5E,MAAM,CAAC,MAAM,8CAA8C,GAAG,qCAAqC,CAAC,MAAM,CAAC;IACvG,OAAO,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC;CAC7B,CAAC,CAAC;AAEH;;;;;GAKG;AACH,MAAM,CAAC,MAAM,gCAAgC,GAAG,CAAC,CAAC,KAAK,CAAC;IACpD,sCAAsC;IACtC,0CAA0C;IAC1C,gDAAgD;IAChD,oCAAoC;IACpC,qCAAqC;IACrC,8CAA8C;CACjD,CAAC;IACA;;;;;;OAMG;KACF,WAAW,CAAC,CAAC,YAAY,EAAE,OAAO,EAAE,EAAE;IACrC,IAAI,YAAY,CAAC,SAAS,KAAK,SAAS,IAAI,CAAC,oCAAoC,CAAC,YAAY,CAAC,MAAM,CAAC,EAAE,CAAC;QACvG,OAAO,CAAC,QAAQ,CAAC;YACf,IAAI,EAAE,QAAQ;YACd,IAAI,EAAE,CAAC,WAAW,CAAC;YACnB,OAAO,EAAE,0EAA0E,YAAY,CAAC,MAAM,KAAK;kBACvG,sGAAsG;kBACtG,yEAAyE;SAC9E,CAAC,CAAC;IACL,CAAC;AACH,CAAC,CAAC,CAAC;AAEL,oFAAoF;AAEpF;;GAEG;AAIH,MAAM,CAAN,IAAY,oBAIT;AAJH,WAAY,oBAAoB;IAC5B,qCAAa,CAAA;IACb,2CAAmB,CAAA;IACnB,uCAAe,CAAA;AACjB,CAAC,EAJS,oBAAoB,KAApB,oBAAoB,QAI7B;AAEH,MAAM,CAAN,IAAY,0BAGX;AAHD,WAAY,0BAA0B;IAClC,2EAA6C,CAAA;IAC7C,yEAA2C,CAAA;AAC/C,CAAC,EAHW,0BAA0B,KAA1B,0BAA0B,QAGrC;AAED,MAAM,CAAC,MAAM,4BAA4B,GAAG,CAAC,CAAC,KAAK,CAAC;IAChD,CAAC,CAAC,IAAI,CAAC,0BAA0B,CAAC;IAClC,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC;CACpB,CAAC,CAAC;AAEH,MAAM,CAAC,MAAM,+BAA+B,GAAG,CAAC,CAAC,MAAM,CAAC;IACpD,UAAU,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC;IAC7B,OAAO,EAAE,CAAC,CAAC,MAAM,EAAE;IACnB,KAAK,EAAE,CAAC,CAAC,IAAI,CAAC,oBAAoB,CAAC,CAAC,QAAQ,EAAE;CACjD,CAAC,CAAC","sourcesContent":["import { z } from \"zod\";\nimport { ResourcePrimaryScope } from \"../resources/resources.shared.schemas\";\n\n\nexport enum CoreUserNotificationChannel {\n EMAIL = 'email',\n SMS = 'sms',\n PUSH = 'push',\n WEBSOCKET = 'websocket',\n FRONT_END_SUCCESS = 'front_end_success',\n}\n\nexport enum UserNotificationLevel {\n INFO = 'info',\n SUCCESS = 'success',\n WARNING = 'warning',\n ERROR = 'error',\n}\n\nexport const UserNotificationChannelSchema = z.union([\n z.enum(CoreUserNotificationChannel),\n z.string().min(1)\n]);\n\n\n/** @wildo_source:part:start saas.models.notifications.targets facet:layer:shared facet:audience:app-developer /\n/\n WHO a declared `userNotifications` entry reaches — and, on the EMAIL channel, whether the tenant\n * gets to redirect or silence it.\n \n Imported from `@wildo-ai/saas-models`. The target is the single most consequential field of a\n * notification declaration, because it decides three separate things at once:\n \n 1. the recipients — resolved per member below;\n * 2. whether the recipient's own channel preference can suppress it — only `USER_SELF` and\n * `USERS_CUSTOM` are suppressible, because only they reach a person about their own affairs. Every\n * other target reaches somebody because of a ROLE they hold, and a personal switch must not\n * silently disable a tenant's administrative monitoring. See\n * {@link userNotificationTargetIsSuppressibleByRecipientPreference};\n * 3. whether `userRoles` is read at all — see {@link userNotificationTargetReadsUserRoles}. On the\n * two tenant-wide targets the field is REFUSED rather than ignored, because \"everyone in the\n * tenant\" is not a set a role list may narrow.\n \n ## Who each target resolves to\n \n \| target \| recipients \|\n * \|---\|---\|\n * \| `USER_SELF` \| the initiator of the operation \|\n * \| `USERS_CUSTOM` \| whatever your `userIdsSelector` returns. Without that function the target resolves nobody \|\n * \| `ORGANIZATION`, `ORGANIZATION_USERS` \| every member of the initiator's tenant. `userRoles` is refused here \|\n * \| `ORGANIZATION_BILLING`, `ORGANIZATION_SECURITY`, `ORGANIZATION_USER_MANAGEMENT`, `ORGANIZATION_ADMINISTRATIVE` \| members of the tenant holding `ORG_OWNER` or `ORG_ADMIN`, unless `userRoles` names a different set \|\n * \| `APPLICATION_BILLING` \| holders of `APP_ADMIN_BILLING_MANAGER` or `APP_ADMIN_SUPER_ADMIN`, application-wide \|\n * \| `APPLICATION_ADMIN_VIEWER` \| holders of `APP_ADMIN_VIEWER` or `APP_ADMIN_SUPER_ADMIN` \|\n * \| every other `APPLICATION_` \| holders of `APP_ADMIN_SUPER_ADMIN` \|\n \| `INBOUND_CONTACT` \| nobody, deliberately. The recipient is not a user of your application, so this target is only usable with an EMAIL notification declaring `recipientEmailField` \|\n \n A target the dispatcher has no rule for resolves nobody and logs a warning — so a custom target\n * string (the schema accepts one) sends nothing on the email and websocket paths.\n \n ## The tenant can redirect or silence an ORGANIZATION-flavoured EMAIL, and you cannot override it\n \n Each tenant owns a notification-settings record with a per-category switch and a per-category\n * address, and the category is DERIVED from the target — `ORGANIZATION_BILLING` to `billing`,\n * `ORGANIZATION_SECURITY` to `security`, and so on. Two consequences to design around:\n \n - a configured address REPLACES the member fan-out, it does not add to it. A tenant routing\n * security mail to a monitoring address is saying where that mail goes, not asking for a copy;\n * - the category switch suppresses the notification entirely, whether or not an address is\n * configured. A tenant that turns billing notifications off means it for the members too.\n \n `ORGANIZATION` belongs to no category, so no category switch silences it; the tenant-wide\n * `defaultEmailAddress` can redirect it. `ORGANIZATION_USERS` always keeps its member fan-out:\n * neither a category switch nor the tenant-wide default address redirects or suppresses that target.\n \n This applies to EMAIL only. The websocket and in-product paths always fan out to the members.\n /\nexport enum CoreUserNotificationTarget {\n APPLICATION_ADMINISTRATOR = 'application_administrator',\n APPLICATION_BILLING = 'application_billing',\n APPLICATION_USER_MANAGEMENT = 'application_user_management',\n APPLICATION_SECURITY = 'application_security',\n APPLICATION_SUPPORT = 'application_support',\n APPLICATION_OTHER = 'application_other',\n APPLICATION_ADMIN_VIEWER = 'application_admin_viewer',\n ORGANIZATION = 'organization',\n ORGANIZATION_USERS = 'organization_users',\n ORGANIZATION_BILLING = 'organization_billing',\n ORGANIZATION_USER_MANAGEMENT = 'organization_user_management',\n ORGANIZATION_ADMINISTRATIVE = 'organization_administrative',\n ORGANIZATION_SECURITY = 'organization_security',\n USER_SELF = 'user_self',\n USERS_CUSTOM = 'users_custom',\n INBOUND_CONTACT = 'inbound_contact',\n}\n\n/\n Whether a notification aimed at this target may be SUPPRESSED by the recipient's own channel\n * preference (`UserPreferences.notifications.email` / `.sms` / `.push` / `.inApp`).\n \n DERIVED from the target rather than declared per notification, because the target already carries\n * the distinction and a second field would be one more thing to get wrong on 87 declarations.\n \n `USER_SELF` and `USERS_CUSTOM` reach a PERSON about their own affairs — those are the messages a\n * person is choosing about when they turn a channel off, and honouring that choice is the whole\n * point of the switch existing (#409).\n \n Every other target reaches somebody because of a ROLE they hold: an application administrator, an\n * organization's security or billing contact. A personal channel preference must not silently\n * disable a tenant's or an application's administrative monitoring — the recipient did not choose to\n * receive those as a person and cannot switch them off as one. A tenant that wants role mail\n * elsewhere routes it, which is what the organization notification-settings record is for.\n \n Nothing here reaches account RECOVERY. Password reset, magic link and email verification are sent\n * directly through the email service and never pass through the notification dispatcher, so no\n * channel preference can lock a person out of their own account. That measurement is what made\n * suppression safe to implement at all.\n /\nexport function userNotificationTargetIsSuppressibleByRecipientPreference(target: string): boolean {\n return target === CoreUserNotificationTarget.USER_SELF\n \|\| target === CoreUserNotificationTarget.USERS_CUSTOM;\n}\n\n/\n The targets on which `userRoles` MEANS anything (#495).\n \n `userRoles` is not a recipient FILTER, which is how its name reads and how it has been authored. It\n * is the role-SELECTION override for the eleven role-scoped targets: `mapOrganizationTargetToRoles`\n * and `mapApplicationTargetToRoles` take it in place of their per-target default, and nothing else\n * anywhere reads it.\n \n On every other target it is inert, and inert in three different ways that all looked the same to an\n * author: `USER_SELF` addresses the initiator, `USERS_CUSTOM` goes straight to `userIdsSelector`, and\n * `ORGANIZATION`/`ORGANIZATION_USERS` mean everyone in the tenant by definition. Declaring it there\n * is a filter that silently does nothing, which is what the refinement below now refuses.\n \n Scoped as a POSITIVE list of targets that read it rather than a rule about one target, because the\n * defect was never specific to `USERS_CUSTOM` — refusing it there alone would leave the other three\n * free to mislead the next author in exactly the same way.\n /\nexport function userNotificationTargetReadsUserRoles(target: string): boolean {\n return target === CoreUserNotificationTarget.ORGANIZATION_BILLING\n \|\| target === CoreUserNotificationTarget.ORGANIZATION_USER_MANAGEMENT\n \|\| target === CoreUserNotificationTarget.ORGANIZATION_ADMINISTRATIVE\n \|\| target === CoreUserNotificationTarget.ORGANIZATION_SECURITY\n \|\| target === CoreUserNotificationTarget.APPLICATION_ADMINISTRATOR\n \|\| target === CoreUserNotificationTarget.APPLICATION_BILLING\n \|\| target === CoreUserNotificationTarget.APPLICATION_USER_MANAGEMENT\n \|\| target === CoreUserNotificationTarget.APPLICATION_SECURITY\n \|\| target === CoreUserNotificationTarget.APPLICATION_SUPPORT\n \|\| target === CoreUserNotificationTarget.APPLICATION_OTHER\n \|\| target === CoreUserNotificationTarget.APPLICATION_ADMIN_VIEWER;\n}\n/* @wildo_source:part:end saas.models.notifications.targets /\n\nexport const UserNotificationTargetSchema = z.union([\n z.enum(CoreUserNotificationTarget),\n z.string().min(1)\n]);\n\n\n\n// =====================================================\n// Celebration & Next-Step Enums (Phase 1a)\n// =====================================================\n\n/* @wildo_source:part:start saas.models.milestone-celebration /\n/\n How the frontend renders a celebration after a successful operation — the value a milestone's\n * `celebrationMode` takes. Import from `@wildo-ai/saas-models`.\n * - CONFETTI: a lightweight, non-blocking confetti burst over the page. Decorative only: no message,\n * no next step, nothing to dismiss.\n * - OVERLAY: a dialog carrying the celebration animation, the milestone's title, the message, an\n * optional next-step action and a dismiss.\n * - LOTTIE: in the framework's DEFAULT celebration overlay, identical to OVERLAY — the same dialog\n * and the same animation. It is the mode to use when the application's OWN celebration-overlay\n * preset draws something distinct for it, such as a per-milestone animation chosen from the\n * notification identifier the preset receives.\n /\nexport enum CelebrationDisplayMode {\n OVERLAY = 'overlay',\n CONFETTI = 'confetti',\n LOTTIE = 'lottie',\n}\n/* @wildo_source:part:end saas.models.milestone-celebration /\n\n/\n Type of next-step suggestion attached to a notification.\n * - OPERATION: Navigate to and/or trigger a resource operation\n * - URL: Navigate to an arbitrary URL (internal or external)\n /\nexport enum NotificationNextStepType {\n OPERATION = 'operation',\n URL = 'url',\n}\n\n// =====================================================\n// Frontend Display Hints Schema (reusable)\n// =====================================================\n\nexport const FrontendDisplayHintsCelebrationSchema = z.object({\n mode: z.enum(CelebrationDisplayMode).default(CelebrationDisplayMode.OVERLAY),\n});\nexport type FrontendDisplayHintsCelebration = z.infer<typeof FrontendDisplayHintsCelebrationSchema>;\n\nexport const FrontendDisplayHintsNextStepSchema = z.object({\n /* Operation path (e.g., \"TASKS.CREATE.default\") or URL /\n operationRef: z.string(),\n type: z.enum(NotificationNextStepType).default(NotificationNextStepType.OPERATION),\n});\nexport type FrontendDisplayHintsNextStep = z.infer<typeof FrontendDisplayHintsNextStepSchema>;\n\nexport const FrontendDisplayHintsSchema = z.object({\n celebration: FrontendDisplayHintsCelebrationSchema.optional(),\n nextStep: FrontendDisplayHintsNextStepSchema.optional(),\n});\nexport type FrontendDisplayHints = z.infer<typeof FrontendDisplayHintsSchema>;\n\n// =====================================================\n// UserNotificationDefinition — Discriminated Union on `channel`\n// =====================================================\n\n/\n @wildo_source:part:start saas.models.notifications.user-notification-definition facet:layer:shared facet:audience:app-developer\n \n One notification an operation sends. Declared as `userNotifications` on a resource operation, in\n * the resource config — an array, so one operation may send several.\n \n ```ts\n * userNotifications: [\n * { target: CoreUserNotificationTarget.USER_SELF, channel: CoreUserNotificationChannel.EMAIL,\n * condition: ({ currentObject }) => currentObject.status === 'INVITED' },\n * { target: CoreUserNotificationTarget.ORGANIZATION_USERS, channel: CoreUserNotificationChannel.WEBSOCKET },\n * ]\n * ```\n \n ## What actually sends\n \n `EMAIL`, `WEBSOCKET` and `FRONT_END_SUCCESS` deliver. *`SMS` and `PUSH` are declaration vocabulary\n only** — the dispatcher's branch for them logs and returns without sending. The framework does have\n * an SMS transport (authentication's one-time codes use it) and this dispatcher is not wired to it,\n * so declaring an SMS notification is inert rather than pending.\n \n For an EMAIL, create the template directory the reference names. The startup validator resolves\n * every declared reference through the configured locale chain before the application takes traffic,\n * and prints the exact directory to create when one is missing.\n \n ## The recipient's preferences are honoured, and three things override them\n \n A recipient who has switched a channel off does not receive it. Three deliberate exceptions:\n \n - a ROLE-addressed target — the recipient did not choose to receive it as a person;\n * - `alwaysDeliver: true` — declare it on a security notice a compromised account's owner must still\n * receive;\n * - a recipient with NO preferences row at all, because preferences are created lazily and a missing\n * record must never read as \"everything off\".\n \n The `inApp` switch suppresses optional personal message presentation (toast, centre and celebration),\n * not the socket frame. Declarative frames carry target and alwaysDeliver to the frontend gate;\n * required and responsibility-addressed messages remain visible. Local operation feedback and\n * resource refresh events are independent of this personal-message preference.\n \n ## `condition` gates the notification, not the operation\n \n The predicate goes on the notification. It decides only whether this one message is sent; refusing\n * the CALL is a separate declaration on the operation variant, and the two are independent — a\n * variant can be enabled while its notification is gated off, and the reverse. The form deliberately\n * matches an operation variant's `enabledCondition` so both read the same way.\n \n ## Emailing somebody who is not a user\n \n `recipientEmailField` names a TOP-LEVEL field on the record holding the address. There is no\n * recipient, so there are no recipient preferences and no recipient language: the message goes out in\n * the application's default locale. A nested address cannot be named, nor a list — the path sends\n * exactly one message per notification. Pair it with a `condition` when the same operation also\n * serves rows whose address belongs to somebody who must not be written to.\n \n Base fields shared by all user notification channel variants.\n /\nexport const UserNotificationDefinition_BaseSchema = z.object({\n identifier: z.string().min(1),\n target: z.string(),\n level: z.enum(UserNotificationLevel).optional(),\n primaryScope: z.enum(ResourcePrimaryScope),\n /\n Role-SELECTION override for a role-scoped target — NOT a recipient filter. See\n * {@link userNotificationTargetReadsUserRoles}, which is also what refuses it elsewhere.\n /\n userRoles: z.array(z.string()).optional(),\n userIdsSelector: z.custom<\n (params: {\n currentObject: any;\n inputDto: any;\n objectContext: { parents: Record<string, any>; children: Record<string, any> };\n initiatorIds: { userId?: string; organizationId?: string; applicationId?: string };\n }) => string[]\n >((val) => typeof val === 'function').optional(),\n /\n Optional gate — dispatch this notification ONLY when the predicate returns truthy\n * against the post-operation context. Absent = always dispatches (backward compatible).\n * Evaluated per-notification BEFORE channel resolution, so it uniformly gates every\n * channel (email/websocket/front-end-success/…).\n \n The canonical use is a POLYMORPHIC operation whose notification must fire for only one\n * branch: the org-member CREATE op serves both INVITE (`status` INVITED — send the invite\n * email to `userEmail`) and DIRECT-ADD (`status` ACTIVE — founder / SSO-JIT / SCIM, whose\n * `userEmail` is the member's OWN address, so an \"you've been invited\" email is a\n * misdelivery). Keying on `currentObject.status === INVITED` fires the invite email for\n * invites only.\n \n Params mirror `userIdsSelector` (its sibling), so an author writes the same\n * `({ currentObject }) => …` form used by the operation-variant `enabledCondition`.\n \n @example `({ currentObject }) => currentObject.status === OrganizationMemberStatus.INVITED`\n /\n condition: z.custom<\n (params: {\n currentObject: any;\n inputDto: any;\n objectContext: { parents: Record<string, any>; children: Record<string, any> };\n initiatorIds: { userId?: string; organizationId?: string; applicationId?: string };\n }) => boolean\n >((val) => typeof val === 'function').optional(),\n /\n Custom notification reference for disambiguating multiple notifications of the same type.\n \n REQUIRED when:\n * - There are 2+ notifications with the same target in the same operation\n * - Example: 2+ USERS_CUSTOM notifications (one for creator, one for assignee)\n \n This allows distinguishing between multiple similar notifications\n * in the same operation (e.g., \"notify-creator\" vs \"notify-assignee\").\n \n Format: lowercase-kebab-case (e.g., \"notify-creator\", \"task-assigned\")\n * Will be appended to auto-generated identifier for notification/template lookup.\n /\n customNotificationRef: z.string().min(1).optional(),\n /\n Deliver this notification even when the recipient has switched its channel OFF.\n \n Only meaningful on a target that is suppressible in the first place — `USER_SELF` and\n * `USERS_CUSTOM` (see `userNotificationTargetIsSuppressibleByRecipientPreference`). On a\n * role-addressed target the preference never applied, so this flag changes nothing there.\n \n The narrow escape, for the case the target axis cannot express: a message that reaches a\n * person about their OWN affairs and is nevertheless a security notice they should not be able\n * to silence — a credential minted or destroyed on their account, an authentication factor\n * changed. Those are the alerts a person most needs when they did NOT perform the action.\n \n Author it with the reason at the site. It is deliberately not a default and deliberately not\n * derived: \"is this alert one a compromised account's owner must still receive?\" is a judgement\n * about the message, and inventing a rule for it would be a rule nobody could check.\n /\n alwaysDeliver: z.boolean().optional(),\n});\n\n// --- Channel-specific variants ---\n\n/* EMAIL channel — template-oriented (email-specific fields handled by email templates) /\nexport const UserNotificationDefinition_EmailSchema = UserNotificationDefinition_BaseSchema.extend({\n channel: z.literal(CoreUserNotificationChannel.EMAIL),\n /\n Deliver this email to a raw address read from the current object, rather than\n * to a resolved platform user.\n \n When set, the recipient is `currentObject[recipientEmailField]` (a top-level\n * string field — e.g. `'email'`). The dispatcher sends a single email directly to\n * that address using the application's default locale, BYPASSING the `userId`-based\n * `target` resolution entirely.\n \n This is the framework's mechanism for notifying a party who is *not (yet) a\n platform user** — an organization-invitation invitee, an inbound lead — for whom\n * no `userId` exists. Without it, the only email recipients the dispatcher can\n * resolve are members/initiators by id (`fetchUserContext(userId).email`).\n \n When this is set, `target` no longer selects the recipient; it is retained only\n * to (a) classify the notification, (b) drive the email `templateRef` derivation,\n * and (c) route the dashboard URL (admin app vs main app). Choose a `target` whose\n * dashboard-routing class matches the recipient (e.g. `USER_SELF` for a main-app\n * link).\n \n All other context is built identically to a user-targeted email (organization\n * name, initiator name, and the token `acceptUrl` enricher), so token-bearing\n * emails such as invitations still carry their `<frontendBase><emailLinkPath>?token=`\n * acceptance link.\n /\n recipientEmailField: z.string().trim().min(1).optional(),\n});\n\n/* WEBSOCKET channel — pure WebSocket push (no frontend display) /\nexport const UserNotificationDefinition_WebSocketSchema = UserNotificationDefinition_BaseSchema.extend({\n channel: z.literal(CoreUserNotificationChannel.WEBSOCKET),\n});\n\n/\n FRONT_END_SUCCESS channel — frontend display with optional celebration + nextStep.\n \n `celebration`: Tells the frontend to render richer feedback than a simple toast.\n * `nextStep`: Suggested next action rendered as a CTA button in the toast or celebration overlay.\n \n Example usage in operation config:\n * ```\n * userNotifications: [{\n * identifier: 'first-document-created',\n * target: CoreUserNotificationTarget.USER_SELF,\n * channel: CoreUserNotificationChannel.FRONT_END_SUCCESS,\n * primaryScope: ResourcePrimaryScope.ORGANIZATIONS,\n * celebration: { mode: CelebrationDisplayMode.OVERLAY },\n * nextStep: { operationRef: 'DOCUMENTS.LIST.default', type: NotificationNextStepType.OPERATION },\n * }]\n * ```\n /\nexport const UserNotificationDefinition_FrontEndSuccessSchema = UserNotificationDefinition_BaseSchema.extend({\n channel: z.literal(CoreUserNotificationChannel.FRONT_END_SUCCESS),\n /* Celebration display hints — triggers richer frontend feedback (overlay/confetti/lottie) /\n celebration: FrontendDisplayHintsCelebrationSchema.optional(),\n /* Suggested next action after operation completes — rendered as CTA in toast or celebration /\n nextStep: FrontendDisplayHintsNextStepSchema.optional(),\n});\n\n/* SMS channel — not yet implemented, plain base /\nexport const UserNotificationDefinition_SMSSchema = UserNotificationDefinition_BaseSchema.extend({\n channel: z.literal(CoreUserNotificationChannel.SMS),\n});\n\n/* PUSH channel — not yet implemented, plain base /\nexport const UserNotificationDefinition_PushSchema = UserNotificationDefinition_BaseSchema.extend({\n channel: z.literal(CoreUserNotificationChannel.PUSH),\n});\n\n/* Catch-all for custom channels (any string not matching core channels) /\nexport const UserNotificationDefinition_CustomChannelSchema = UserNotificationDefinition_BaseSchema.extend({\n channel: z.string().min(1),\n});\n\n/\n Final union of all notification channel variants.\n * Uses z.union() (not z.discriminatedUnion) because the catch-all custom channel\n * uses z.string() which is not a literal discriminant.\n * Order matters: specific literals are tried before the catch-all string.\n /\nexport const UserNotificationDefinitionSchema = z.union([\n UserNotificationDefinition_EmailSchema,\n UserNotificationDefinition_WebSocketSchema,\n UserNotificationDefinition_FrontEndSuccessSchema,\n UserNotificationDefinition_SMSSchema,\n UserNotificationDefinition_PushSchema,\n UserNotificationDefinition_CustomChannelSchema,\n])\n /\n `userRoles` on a target that never reads it is a filter that silently does nothing (#495).\n \n Refined on the UNION rather than on the base object, deliberately: the base is `.extend()`ed by\n * six channel variants, and a refinement there would be dropped by every one of them — the shape of\n * bug this refinement exists to prevent.\n /\n .superRefine((notification, context) => {\n if (notification.userRoles !== undefined && !userNotificationTargetReadsUserRoles(notification.target)) {\n context.addIssue({\n code: 'custom',\n path: ['userRoles'],\n message: `userRoles is only read for a role-scoped target and would be inert on \"${notification.target}\". `\n + 'It selects WHICH roles a role-scoped target reaches; it does not filter the recipients of any other '\n + 'target. Remove it, or address the notification to a role-scoped target.',\n });\n }\n });\nexport type UserNotificationDefinition = z.infer<typeof UserNotificationDefinitionSchema>;\n/* @wildo_source:part:end saas.models.notifications.user-notification-definition /\n\n/\n M2M Notification Channels\n /\n\n\n\nexport enum M2MNotificationLevel {\n INFO = 'info',\n SUCCESS = 'success',\n ERROR = 'error',\n }\n\nexport enum CoreM2MNotificationChannel {\n WEBHOOK_ORGANIZATION = 'webhook_organization',\n WEBHOOK_APPLICATION = 'webhook_application',\n}\n\nexport const M2MNotificationChannelSchema = z.union([\n z.enum(CoreM2MNotificationChannel),\n z.string().min(1)\n]);\n\nexport const M2MNotificationDefinitionSchema = z.object({\n identifier: z.string().min(1),\n channel: z.string(),\n level: z.enum(M2MNotificationLevel).optional(),\n});\nexport type M2MNotificationDefinition = z.infer<typeof M2MNotificationDefinitionSchema>;\n\n/\n Inferred types (interfaces defined above for isolatedDeclarations compatibility)\n */\n\nexport type UserNotificationTarget = string;\nexport type NotificationChannel = string;\nexport type M2MNotificationChannel = string;\n"]}

package/dist/esm/organizations/application-owner-organization.shared.schemas.d.ts ADDED Viewed

@@ -0,0 +1,145 @@
+/**
+ * The application-owner organization — refusal codes and the operator promotion contract (#1054).
+ *
+ * An application whose `organizationTypes` declare `ownsApplication` on one type has an OWNER
+ * ORGANIZATION: the single organization of that type, the one that operates the application. Its
+ * singularity is protected at three moments — it cannot be created through an ordinary door, it
+ * cannot be promoted into while one exists, and it cannot be deleted — and every refusal carries a
+ * stable, client-branchable code declared here.
+ *
+ * assurance-control: WILDO.ACCESS.ADMINISTRATIVE_CONTINUITY — the organization that operates the
+ * application is singular, and the doors that could create a second one, or destroy the only one,
+ * refuse rather than leave the application with no operator.
+ *
+ * ## Why these codes are a shared enum rather than a `reason` string
+ *
+ * The refusals are `ErrorType.CONFLICT`, and `sanitizeErrorForClient` keeps only an ALLOWLIST of
+ * context keys on a CONFLICT — `reason` is not on it. The backend-side `reason` stays (it is the log
+ * and audit identity, richer than the wire and free to stay so), but a CLIENT wanting to tell these
+ * apart from any other 409 has only the stable `code` key, sourced from an enum in
+ * `@wildo-ai/saas-models` so backend and frontend share one definition.
+ *
+ * This is the trap `organizationMembers.grantOwnership` fell into and the reason the allowlist's own
+ * documented rule exists: its two CONFLICTs carry only `reason`, so they are invisible to every
+ * client and a caller must regex-parse a message that is free to be reworded.
+ *
+ * @see AdministrativeContinuityErrorCode — the sibling enum for the two authority floors. Distinct
+ *   populations: those protect a scope's ADMINISTRATORS, these protect the identity of the
+ *   organization that owns the application itself.
+ */
+/** @wildo_source:part:start saas.models.organizations.application-owner-codes facet:layer:shared facet:audience:app-developer */
+/**
+ * Why a write against the application-owner organization was refused.
+ *
+ * Imported from `@wildo-ai/saas-models`. A closed vocabulary with one named runtime source: the
+ * refusals, the resource specification's error scenarios and any client branch all derive from this
+ * enum rather than re-typing the literals.
+ *
+ * ## Where you meet it
+ *
+ * Each refusal is HTTP **409 CONFLICT** and the value rides under the response's stable `code` key.
+ * Branch on `code`, never on the message — the message is a human remedy and is free to be reworded,
+ * and every other field a backend might have used to carry the reason is stripped from a CONFLICT
+ * before it reaches a client.
+ *
+ * `409` and not `403`/`400` in every case, deliberately: the caller IS authorised and the payload IS
+ * valid — the type named is declared, the organization addressed exists. What forbids the write is a
+ * fact about the APPLICATION: it is operated by exactly one organization, and that singularity is what
+ * each of these writes would break.
+ *
+ * `403` was the alternative for the creation refusal and is wrong twice over. It would say the caller
+ * lacks authority, which is false — a super-administrator is refused by the same rule as a registrant,
+ * because the door is the thing that is shut and not the principal. And `sanitizeErrorForClient`
+ * strips the whole context from an AUTHORIZATION error, so the `code` below would never reach a
+ * client and this enum would be decorative.
+ */
+export declare enum ApplicationOwnerOrganizationErrorCode {
+    /**
+     * The application already has an organization of the type that declares `ownsApplication`, and this
+     * write would produce a second one.
+     *
+     * An application is operated by ONE organization; two would make every question that resolves
+     * through the marker — whose rows these are, whose credentials were spent — a choice nobody
+     * declared. Remedy: use the existing owner organization. If the existing one is the wrong one, that
+     * is a data-repair question rather than a creation question, and there is no operation that
+     * demotes an owner.
+     */
+    APPLICATION_OWNER_ORGANIZATION_EXISTS = "APPLICATION_OWNER_ORGANIZATION_EXISTS",
+    /**
+     * The organization is the application's owner and may not be put on the deletion path.
+     *
+     * Refused for `requestDeletion` (both variants), for the purge `delete` (both variants), and by the
+     * purge batch. Everything the application owns as an operator — the rows its systems of record
+     * project, the pipelines that load them — belongs to this organization, so purging it strands them
+     * with no tenant and nothing that could re-create one: `Organization.type` is creation-time
+     * identity, and there is no door that mints a second owner.
+     *
+     * SUSPENSION is deliberately NOT refused. Halting the owner organization is incident response, and
+     * every read through it then refuses at the ordinary status gate — the same asymmetry the
+     * organization-owner floor is built on: a suspended tenant is recoverable, a purged one is not, so
+     * the refusal belongs on the irreversible act only.
+     *
+     * Remedy: if the application is genuinely being decommissioned, remove the `ownsApplication` marker
+     * from the declaration first — the refusal is about what the application currently says it needs.
+     */
+    OWNER_ORGANIZATION_CANNOT_BE_DELETED = "OWNER_ORGANIZATION_CANNOT_BE_DELETED",
+    /**
+     * An organization of the owner type cannot be created through this door.
+     *
+     * The refusal is by DOOR, not by count: **no** service-tier `CREATE` may produce the owner
+     * organization, whether or not one exists yet. Two doors make one — the platform's bootstrap, which
+     * seeds the first administrator's organization when the application is initialised, and
+     * `organizations.promoteToOwnerOrganization`, which re-types an existing organization under audit.
+     *
+     * Counting instead would have left a real hole: the marked type declares no `creationPolicy` (the
+     * configuration refuses one), the default `CREATE` variant is open to `APP_USER`, and the creation
+     * prefix restricts only types that HAVE a creation policy. So before the bootstrap ran, any
+     * registrant could have created the owner organization and become its founding owner.
+     *
+     * Remedy: create an ordinary organization of a non-owner type, or ask a super-administrator to
+     * promote an existing organization.
+     */
+    OWNER_ORGANIZATION_TYPE_NOT_CREATABLE = "OWNER_ORGANIZATION_TYPE_NOT_CREATABLE",
+    /**
+     * A promotion was asked for and the declaration does not name exactly ONE owner organization type, so
+     * there is nothing unambiguous to promote INTO.
+     *
+     * Its own code rather than a reuse of the three above, because the remedy is in a different place:
+     * those are about which ROWS exist, this is about what the DECLARATION says.
+     *
+     * ONE code, two opposite remedies, and the refusal message says which one you hit: either NO type
+     * carries `ownsApplication` (declare one) or SEVERAL do (remove the marker from all but one). They
+     * share a code because a client branches identically on both — the declaration is wrong and no
+     * promotion can proceed — while a human needs the distinction, which is what the message carries.
+     * Reporting the second as "no type declares it" would send an operator to add a third.
+     */
+    APPLICATION_DECLARES_NO_OWNER_ORGANIZATION_TYPE = "APPLICATION_DECLARES_NO_OWNER_ORGANIZATION_TYPE",
+    /**
+     * The organization cannot be promoted because the owner type would change what its members are or
+     * may hold — a dependent policy surface the promotion refuses rather than reconciles.
+     *
+     * Three mismatches carry this code, and the refusal names which one it hit and the exact values:
+     * the owner type grants fewer `userTypes` than the organization's current type (promoting would
+     * revoke a global grant from every member); a membership holds a role the owner type does not list
+     * in `availableOrgRoles`; or THIS organization is actively managed by a directory — the
+     * `DIRECTORY_PROVISIONING` feature is enabled for it and a live SCIM token exists — and the owner
+     * type does not declare `scimProvisioning`, so promoting would stop it being reconciled by its IdP.
+     *
+     * Note the third asks about the ORGANIZATION, not about the two type definitions.
+     * `scimProvisioning.enabled` on a type is only the application-wide MOUNT gate (the engine mounts the
+     * SCIM controllers when at least one declared type carries it) and says nothing about whether any one
+     * tenant is directory-managed — so comparing the two flags would refuse a promotion for every tenant
+     * with no directory wired at all, which is most of them.
+     *
+     * Why refuse rather than revoke-and-regrant: a promotion that changed what people can do while
+     * calling itself a re-typing is the kind of silent authority change an access review cannot see.
+     * The operation changes the tenant's identity and touches nobody's authority, and this refusal is
+     * what keeps that true.
+     *
+     * Remedy: widen the owner type in `organizationTypes` (add the user types, the roles, or the SCIM
+     * binding), run `wildo config reapply-declaration`, then retry.
+     */
+    OWNER_PROMOTION_INCOMPATIBLE_WITH_TARGET_TYPE = "OWNER_PROMOTION_INCOMPATIBLE_WITH_TARGET_TYPE"
+}
+/** @wildo_source:part:end saas.models.organizations.application-owner-codes */
+//# sourceMappingURL=application-owner-organization.shared.schemas.d.ts.map

package/dist/esm/organizations/application-owner-organization.shared.schemas.d.ts.map ADDED Viewed

@@ -0,0 +1 @@

+ {"version":3,"file":"application-owner-organization.shared.schemas.d.ts","sourceRoot":"","sources":["../../../../src/organizations/application-owner-organization.shared.schemas.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA4BG;AAEH,iIAAiI;AACjI;;;;;;;;;;;;;;;;;;;;;;;;GAwBG;AACH,oBAAY,qCAAqC;IAC/C;;;;;;;;;OASG;IACH,qCAAqC,0CAA0C;IAE/E;;;;;;;;;;;;;;;;OAgBG;IACH,oCAAoC,yCAAyC;IAE7E;;;;;;;;;;;;;;;OAeG;IACH,qCAAqC,0CAA0C;IAE/E;;;;;;;;;;;;OAYG;IACH,+CAA+C,oDAAoD;IAEnG;;;;;;;;;;;;;;;;;;;;;;;;OAwBG;IACH,6CAA6C,kDAAkD;CAChG;AACD,+EAA+E"}

package/dist/esm/organizations/application-owner-organization.shared.schemas.js ADDED Viewed

@@ -0,0 +1,146 @@
+/**
+ * The application-owner organization — refusal codes and the operator promotion contract (#1054).
+ *
+ * An application whose `organizationTypes` declare `ownsApplication` on one type has an OWNER
+ * ORGANIZATION: the single organization of that type, the one that operates the application. Its
+ * singularity is protected at three moments — it cannot be created through an ordinary door, it
+ * cannot be promoted into while one exists, and it cannot be deleted — and every refusal carries a
+ * stable, client-branchable code declared here.
+ *
+ * assurance-control: WILDO.ACCESS.ADMINISTRATIVE_CONTINUITY — the organization that operates the
+ * application is singular, and the doors that could create a second one, or destroy the only one,
+ * refuse rather than leave the application with no operator.
+ *
+ * ## Why these codes are a shared enum rather than a `reason` string
+ *
+ * The refusals are `ErrorType.CONFLICT`, and `sanitizeErrorForClient` keeps only an ALLOWLIST of
+ * context keys on a CONFLICT — `reason` is not on it. The backend-side `reason` stays (it is the log
+ * and audit identity, richer than the wire and free to stay so), but a CLIENT wanting to tell these
+ * apart from any other 409 has only the stable `code` key, sourced from an enum in
+ * `@wildo-ai/saas-models` so backend and frontend share one definition.
+ *
+ * This is the trap `organizationMembers.grantOwnership` fell into and the reason the allowlist's own
+ * documented rule exists: its two CONFLICTs carry only `reason`, so they are invisible to every
+ * client and a caller must regex-parse a message that is free to be reworded.
+ *
+ * @see AdministrativeContinuityErrorCode — the sibling enum for the two authority floors. Distinct
+ *   populations: those protect a scope's ADMINISTRATORS, these protect the identity of the
+ *   organization that owns the application itself.
+ */
+/** @wildo_source:part:start saas.models.organizations.application-owner-codes facet:layer:shared facet:audience:app-developer */
+/**
+ * Why a write against the application-owner organization was refused.
+ *
+ * Imported from `@wildo-ai/saas-models`. A closed vocabulary with one named runtime source: the
+ * refusals, the resource specification's error scenarios and any client branch all derive from this
+ * enum rather than re-typing the literals.
+ *
+ * ## Where you meet it
+ *
+ * Each refusal is HTTP **409 CONFLICT** and the value rides under the response's stable `code` key.
+ * Branch on `code`, never on the message — the message is a human remedy and is free to be reworded,
+ * and every other field a backend might have used to carry the reason is stripped from a CONFLICT
+ * before it reaches a client.
+ *
+ * `409` and not `403`/`400` in every case, deliberately: the caller IS authorised and the payload IS
+ * valid — the type named is declared, the organization addressed exists. What forbids the write is a
+ * fact about the APPLICATION: it is operated by exactly one organization, and that singularity is what
+ * each of these writes would break.
+ *
+ * `403` was the alternative for the creation refusal and is wrong twice over. It would say the caller
+ * lacks authority, which is false — a super-administrator is refused by the same rule as a registrant,
+ * because the door is the thing that is shut and not the principal. And `sanitizeErrorForClient`
+ * strips the whole context from an AUTHORIZATION error, so the `code` below would never reach a
+ * client and this enum would be decorative.
+ */
+export var ApplicationOwnerOrganizationErrorCode;
+(function (ApplicationOwnerOrganizationErrorCode) {
+    /**
+     * The application already has an organization of the type that declares `ownsApplication`, and this
+     * write would produce a second one.
+     *
+     * An application is operated by ONE organization; two would make every question that resolves
+     * through the marker — whose rows these are, whose credentials were spent — a choice nobody
+     * declared. Remedy: use the existing owner organization. If the existing one is the wrong one, that
+     * is a data-repair question rather than a creation question, and there is no operation that
+     * demotes an owner.
+     */
+    ApplicationOwnerOrganizationErrorCode["APPLICATION_OWNER_ORGANIZATION_EXISTS"] = "APPLICATION_OWNER_ORGANIZATION_EXISTS";
+    /**
+     * The organization is the application's owner and may not be put on the deletion path.
+     *
+     * Refused for `requestDeletion` (both variants), for the purge `delete` (both variants), and by the
+     * purge batch. Everything the application owns as an operator — the rows its systems of record
+     * project, the pipelines that load them — belongs to this organization, so purging it strands them
+     * with no tenant and nothing that could re-create one: `Organization.type` is creation-time
+     * identity, and there is no door that mints a second owner.
+     *
+     * SUSPENSION is deliberately NOT refused. Halting the owner organization is incident response, and
+     * every read through it then refuses at the ordinary status gate — the same asymmetry the
+     * organization-owner floor is built on: a suspended tenant is recoverable, a purged one is not, so
+     * the refusal belongs on the irreversible act only.
+     *
+     * Remedy: if the application is genuinely being decommissioned, remove the `ownsApplication` marker
+     * from the declaration first — the refusal is about what the application currently says it needs.
+     */
+    ApplicationOwnerOrganizationErrorCode["OWNER_ORGANIZATION_CANNOT_BE_DELETED"] = "OWNER_ORGANIZATION_CANNOT_BE_DELETED";
+    /**
+     * An organization of the owner type cannot be created through this door.
+     *
+     * The refusal is by DOOR, not by count: **no** service-tier `CREATE` may produce the owner
+     * organization, whether or not one exists yet. Two doors make one — the platform's bootstrap, which
+     * seeds the first administrator's organization when the application is initialised, and
+     * `organizations.promoteToOwnerOrganization`, which re-types an existing organization under audit.
+     *
+     * Counting instead would have left a real hole: the marked type declares no `creationPolicy` (the
+     * configuration refuses one), the default `CREATE` variant is open to `APP_USER`, and the creation
+     * prefix restricts only types that HAVE a creation policy. So before the bootstrap ran, any
+     * registrant could have created the owner organization and become its founding owner.
+     *
+     * Remedy: create an ordinary organization of a non-owner type, or ask a super-administrator to
+     * promote an existing organization.
+     */
+    ApplicationOwnerOrganizationErrorCode["OWNER_ORGANIZATION_TYPE_NOT_CREATABLE"] = "OWNER_ORGANIZATION_TYPE_NOT_CREATABLE";
+    /**
+     * A promotion was asked for and the declaration does not name exactly ONE owner organization type, so
+     * there is nothing unambiguous to promote INTO.
+     *
+     * Its own code rather than a reuse of the three above, because the remedy is in a different place:
+     * those are about which ROWS exist, this is about what the DECLARATION says.
+     *
+     * ONE code, two opposite remedies, and the refusal message says which one you hit: either NO type
+     * carries `ownsApplication` (declare one) or SEVERAL do (remove the marker from all but one). They
+     * share a code because a client branches identically on both — the declaration is wrong and no
+     * promotion can proceed — while a human needs the distinction, which is what the message carries.
+     * Reporting the second as "no type declares it" would send an operator to add a third.
+     */
+    ApplicationOwnerOrganizationErrorCode["APPLICATION_DECLARES_NO_OWNER_ORGANIZATION_TYPE"] = "APPLICATION_DECLARES_NO_OWNER_ORGANIZATION_TYPE";
+    /**
+     * The organization cannot be promoted because the owner type would change what its members are or
+     * may hold — a dependent policy surface the promotion refuses rather than reconciles.
+     *
+     * Three mismatches carry this code, and the refusal names which one it hit and the exact values:
+     * the owner type grants fewer `userTypes` than the organization's current type (promoting would
+     * revoke a global grant from every member); a membership holds a role the owner type does not list
+     * in `availableOrgRoles`; or THIS organization is actively managed by a directory — the
+     * `DIRECTORY_PROVISIONING` feature is enabled for it and a live SCIM token exists — and the owner
+     * type does not declare `scimProvisioning`, so promoting would stop it being reconciled by its IdP.
+     *
+     * Note the third asks about the ORGANIZATION, not about the two type definitions.
+     * `scimProvisioning.enabled` on a type is only the application-wide MOUNT gate (the engine mounts the
+     * SCIM controllers when at least one declared type carries it) and says nothing about whether any one
+     * tenant is directory-managed — so comparing the two flags would refuse a promotion for every tenant
+     * with no directory wired at all, which is most of them.
+     *
+     * Why refuse rather than revoke-and-regrant: a promotion that changed what people can do while
+     * calling itself a re-typing is the kind of silent authority change an access review cannot see.
+     * The operation changes the tenant's identity and touches nobody's authority, and this refusal is
+     * what keeps that true.
+     *
+     * Remedy: widen the owner type in `organizationTypes` (add the user types, the roles, or the SCIM
+     * binding), run `wildo config reapply-declaration`, then retry.
+     */
+    ApplicationOwnerOrganizationErrorCode["OWNER_PROMOTION_INCOMPATIBLE_WITH_TARGET_TYPE"] = "OWNER_PROMOTION_INCOMPATIBLE_WITH_TARGET_TYPE";
+})(ApplicationOwnerOrganizationErrorCode || (ApplicationOwnerOrganizationErrorCode = {}));
+/** @wildo_source:part:end saas.models.organizations.application-owner-codes */
+//# sourceMappingURL=application-owner-organization.shared.schemas.js.map

package/dist/esm/organizations/application-owner-organization.shared.schemas.js.map ADDED Viewed

@@ -0,0 +1 @@

+ {"version":3,"file":"application-owner-organization.shared.schemas.js","sourceRoot":"","sources":["../../../../src/organizations/application-owner-organization.shared.schemas.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA4BG;AAEH,iIAAiI;AACjI;;;;;;;;;;;;;;;;;;;;;;;;GAwBG;AACH,MAAM,CAAN,IAAY,qCA2FX;AA3FD,WAAY,qCAAqC;IAC/C;;;;;;;;;OASG;IACH,wHAA+E,CAAA;IAE/E;;;;;;;;;;;;;;;;OAgBG;IACH,sHAA6E,CAAA;IAE7E;;;;;;;;;;;;;;;OAeG;IACH,wHAA+E,CAAA;IAE/E;;;;;;;;;;;;OAYG;IACH,4IAAmG,CAAA;IAEnG;;;;;;;;;;;;;;;;;;;;;;;;OAwBG;IACH,wIAA+F,CAAA;AACjG,CAAC,EA3FW,qCAAqC,KAArC,qCAAqC,QA2FhD;AACD,+EAA+E","sourcesContent":["/**\n * The application-owner organization — refusal codes and the operator promotion contract (#1054).\n *\n * An application whose `organizationTypes` declare `ownsApplication` on one type has an OWNER\n * ORGANIZATION: the single organization of that type, the one that operates the application. Its\n * singularity is protected at three moments — it cannot be created through an ordinary door, it\n * cannot be promoted into while one exists, and it cannot be deleted — and every refusal carries a\n * stable, client-branchable code declared here.\n *\n * assurance-control: WILDO.ACCESS.ADMINISTRATIVE_CONTINUITY — the organization that operates the\n * application is singular, and the doors that could create a second one, or destroy the only one,\n * refuse rather than leave the application with no operator.\n *\n * ## Why these codes are a shared enum rather than a `reason` string\n *\n * The refusals are `ErrorType.CONFLICT`, and `sanitizeErrorForClient` keeps only an ALLOWLIST of\n * context keys on a CONFLICT — `reason` is not on it. The backend-side `reason` stays (it is the log\n * and audit identity, richer than the wire and free to stay so), but a CLIENT wanting to tell these\n * apart from any other 409 has only the stable `code` key, sourced from an enum in\n * `@wildo-ai/saas-models` so backend and frontend share one definition.\n *\n * This is the trap `organizationMembers.grantOwnership` fell into and the reason the allowlist's own\n * documented rule exists: its two CONFLICTs carry only `reason`, so they are invisible to every\n * client and a caller must regex-parse a message that is free to be reworded.\n *\n * @see AdministrativeContinuityErrorCode — the sibling enum for the two authority floors. Distinct\n * populations: those protect a scope's ADMINISTRATORS, these protect the identity of the\n * organization that owns the application itself.\n */\n\n/** @wildo_source:part:start saas.models.organizations.application-owner-codes facet:layer:shared facet:audience:app-developer */\n/**\n * Why a write against the application-owner organization was refused.\n *\n * Imported from `@wildo-ai/saas-models`. A closed vocabulary with one named runtime source: the\n * refusals, the resource specification's error scenarios and any client branch all derive from this\n * enum rather than re-typing the literals.\n *\n * ## Where you meet it\n *\n * Each refusal is HTTP **409 CONFLICT** and the value rides under the response's stable `code` key.\n * Branch on `code`, never on the message — the message is a human remedy and is free to be reworded,\n * and every other field a backend might have used to carry the reason is stripped from a CONFLICT\n * before it reaches a client.\n *\n * `409` and not `403`/`400` in every case, deliberately: the caller IS authorised and the payload IS\n * valid — the type named is declared, the organization addressed exists. What forbids the write is a\n * fact about the APPLICATION: it is operated by exactly one organization, and that singularity is what\n * each of these writes would break.\n *\n * `403` was the alternative for the creation refusal and is wrong twice over. It would say the caller\n * lacks authority, which is false — a super-administrator is refused by the same rule as a registrant,\n * because the door is the thing that is shut and not the principal. And `sanitizeErrorForClient`\n * strips the whole context from an AUTHORIZATION error, so the `code` below would never reach a\n * client and this enum would be decorative.\n */\nexport enum ApplicationOwnerOrganizationErrorCode {\n /**\n * The application already has an organization of the type that declares `ownsApplication`, and this\n * write would produce a second one.\n *\n * An application is operated by ONE organization; two would make every question that resolves\n * through the marker — whose rows these are, whose credentials were spent — a choice nobody\n * declared. Remedy: use the existing owner organization. If the existing one is the wrong one, that\n * is a data-repair question rather than a creation question, and there is no operation that\n * demotes an owner.\n */\n APPLICATION_OWNER_ORGANIZATION_EXISTS = 'APPLICATION_OWNER_ORGANIZATION_EXISTS',\n\n /**\n * The organization is the application's owner and may not be put on the deletion path.\n *\n * Refused for `requestDeletion` (both variants), for the purge `delete` (both variants), and by the\n * purge batch. Everything the application owns as an operator — the rows its systems of record\n * project, the pipelines that load them — belongs to this organization, so purging it strands them\n * with no tenant and nothing that could re-create one: `Organization.type` is creation-time\n * identity, and there is no door that mints a second owner.\n *\n * SUSPENSION is deliberately NOT refused. Halting the owner organization is incident response, and\n * every read through it then refuses at the ordinary status gate — the same asymmetry the\n * organization-owner floor is built on: a suspended tenant is recoverable, a purged one is not, so\n * the refusal belongs on the irreversible act only.\n *\n * Remedy: if the application is genuinely being decommissioned, remove the `ownsApplication` marker\n * from the declaration first — the refusal is about what the application currently says it needs.\n */\n OWNER_ORGANIZATION_CANNOT_BE_DELETED = 'OWNER_ORGANIZATION_CANNOT_BE_DELETED',\n\n /**\n * An organization of the owner type cannot be created through this door.\n *\n * The refusal is by DOOR, not by count: **no** service-tier `CREATE` may produce the owner\n * organization, whether or not one exists yet. Two doors make one — the platform's bootstrap, which\n * seeds the first administrator's organization when the application is initialised, and\n * `organizations.promoteToOwnerOrganization`, which re-types an existing organization under audit.\n *\n * Counting instead would have left a real hole: the marked type declares no `creationPolicy` (the\n * configuration refuses one), the default `CREATE` variant is open to `APP_USER`, and the creation\n * prefix restricts only types that HAVE a creation policy. So before the bootstrap ran, any\n * registrant could have created the owner organization and become its founding owner.\n *\n * Remedy: create an ordinary organization of a non-owner type, or ask a super-administrator to\n * promote an existing organization.\n */\n OWNER_ORGANIZATION_TYPE_NOT_CREATABLE = 'OWNER_ORGANIZATION_TYPE_NOT_CREATABLE',\n\n /**\n * A promotion was asked for and the declaration does not name exactly ONE owner organization type, so\n * there is nothing unambiguous to promote INTO.\n *\n * Its own code rather than a reuse of the three above, because the remedy is in a different place:\n * those are about which ROWS exist, this is about what the DECLARATION says.\n *\n * ONE code, two opposite remedies, and the refusal message says which one you hit: either NO type\n * carries `ownsApplication` (declare one) or SEVERAL do (remove the marker from all but one). They\n * share a code because a client branches identically on both — the declaration is wrong and no\n * promotion can proceed — while a human needs the distinction, which is what the message carries.\n * Reporting the second as \"no type declares it\" would send an operator to add a third.\n */\n APPLICATION_DECLARES_NO_OWNER_ORGANIZATION_TYPE = 'APPLICATION_DECLARES_NO_OWNER_ORGANIZATION_TYPE',\n\n /**\n * The organization cannot be promoted because the owner type would change what its members are or\n * may hold — a dependent policy surface the promotion refuses rather than reconciles.\n *\n * Three mismatches carry this code, and the refusal names which one it hit and the exact values:\n * the owner type grants fewer `userTypes` than the organization's current type (promoting would\n * revoke a global grant from every member); a membership holds a role the owner type does not list\n * in `availableOrgRoles`; or THIS organization is actively managed by a directory — the\n * `DIRECTORY_PROVISIONING` feature is enabled for it and a live SCIM token exists — and the owner\n * type does not declare `scimProvisioning`, so promoting would stop it being reconciled by its IdP.\n *\n * Note the third asks about the ORGANIZATION, not about the two type definitions.\n * `scimProvisioning.enabled` on a type is only the application-wide MOUNT gate (the engine mounts the\n * SCIM controllers when at least one declared type carries it) and says nothing about whether any one\n * tenant is directory-managed — so comparing the two flags would refuse a promotion for every tenant\n * with no directory wired at all, which is most of them.\n *\n * Why refuse rather than revoke-and-regrant: a promotion that changed what people can do while\n * calling itself a re-typing is the kind of silent authority change an access review cannot see.\n * The operation changes the tenant's identity and touches nobody's authority, and this refusal is\n * what keeps that true.\n *\n * Remedy: widen the owner type in `organizationTypes` (add the user types, the roles, or the SCIM\n * binding), run `wildo config reapply-declaration`, then retry.\n */\n OWNER_PROMOTION_INCOMPATIBLE_WITH_TARGET_TYPE = 'OWNER_PROMOTION_INCOMPATIBLE_WITH_TARGET_TYPE',\n}\n/** @wildo_source:part:end saas.models.organizations.application-owner-codes */\n"]}

package/dist/esm/organizations/organization-features.shared.resources-config.schemas.d.ts CHANGED Viewed

@@ -33,6 +33,8 @@ export declare const organizationFeaturesResourceConfiguration_InitializationFac
         removedFeatures: z.ZodDefault<z.ZodArray<z.ZodString>>;
         limitOverrides: z.ZodDefault<z.ZodRecord<z.ZodString, z.ZodNumber>>;
     }, z.core.$strip>>>;
+    _id: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodString>>;
+    organizationId: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodString>>>>>>;
 }, z.core.$strip>>;
 export {};
 //# sourceMappingURL=organization-features.shared.resources-config.schemas.d.ts.map

package/dist/esm/organizations/organization-features.shared.resources-config.schemas.d.ts.map CHANGED Viewed

	@@ -1 +1 @@
1	- {"version":3,"file":"organization-features.shared.resources-config.schemas.d.ts","sourceRoot":"","sources":["~~../../../~~src/organizations/organization-features.shared.resources-config.schemas.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AAEH,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AACxB,OAAO,EAAE,WAAW,EAAE,MAAM,wCAAwC,CAAC;AAGrE,OAAO,EAAE,qBAAqB,EAAE,MAAM,gDAAgD,CAAC;AACvF,OAAO,~~EAAoD~~,oBAAoB,EAAE,MAAM,uCAAuC,CAAC;~~AAU~~/H,oBAAY,+BAA+B;IACzC,cAAc,mBAAmB;IACjC,eAAe,oBAAoB;IACnC,cAAc,mBAAmB;CAClC;AAED,eAAO,MAAM,iDAAiD;;;iBAG5D,CAAC;AAEH,eAAO,MAAM,kDAAkD;;;iBAG7D,CAAC;AAEH,eAAO,MAAM,iDAAiD;;iBAE5D,CAAC;AAQH,KAAK,kCAAkC,GACnC,qBAAqB,CAAC,MAAM,GAC5B,qBAAqB,CAAC,IAAI,GAC1B,qBAAqB,CAAC,MAAM,GAC5B,qBAAqB,CAAC,MAAM,GAC5B,qBAAqB,CAAC,MAAM,CAAC;AAKjC,eAAO,MAAM,+DAA+D,GAAI,wBAAwB,oBAAoB,EAAE~~;;;;;;;;kBA0J5H~~,CAAC"}
1	+ {"version":3,"file":"organization-features.shared.resources-config.schemas.d.ts","sourceRoot":"","sources":["../../../../src/organizations/organization-features.shared.resources-config.schemas.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AAEH,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AACxB,OAAO,EAAE,WAAW,EAAE,MAAM,wCAAwC,CAAC;AAGrE,OAAO,EAAE,qBAAqB,EAAE,MAAM,gDAAgD,CAAC;AACvF,OAAO,EAAoF,oBAAoB,EAAE,MAAM,uCAAuC,CAAC;AAW/J,oBAAY,+BAA+B;IACzC,cAAc,mBAAmB;IACjC,eAAe,oBAAoB;IACnC,cAAc,mBAAmB;CAClC;AAED,eAAO,MAAM,iDAAiD;;;iBAG5D,CAAC;AAEH,eAAO,MAAM,kDAAkD;;;iBAG7D,CAAC;AAEH,eAAO,MAAM,iDAAiD;;iBAE5D,CAAC;AAQH,KAAK,kCAAkC,GACnC,qBAAqB,CAAC,MAAM,GAC5B,qBAAqB,CAAC,IAAI,GAC1B,qBAAqB,CAAC,MAAM,GAC5B,qBAAqB,CAAC,MAAM,GAC5B,qBAAqB,CAAC,MAAM,CAAC;AAKjC,eAAO,MAAM,+DAA+D,GAAI,wBAAwB,oBAAoB,EAAE;;;;;;;;;;kBAiL5H,CAAC"}

package/dist/esm/organizations/organization-features.shared.resources-config.schemas.js CHANGED Viewed

@@ -6,11 +6,12 @@
  */
 import { z } from 'zod';
 import { CoreFeature } from './organization-features.shared.schemas.js';
-import { ScopeFeaturesWithOverridesSchema } from '../features/scope-features.shared.schemas.js';
+import { OrganizationFeaturesSchema, ScopeFeaturesWithOverridesSchema } from '../features/scope-features.shared.schemas.js';
 import { CoreResourceOperation } from '../resources/resources.shared.core.definitions.js';
-import { ResourceOperationRiskLevel } from '../resources/resources.shared.schemas.js';
+import { ResourceOperationRiskLevel, ResourceOperationReversibility } from '../resources/resources.shared.schemas.js';
 import { CoreResourceType, coreResourceShared_FieldIdentifier } from '../resources/resources.shared.core.definitions.js';
 import { ResourceOperationVariantType } from '../resources/resources.shared.schemas.js';
+import { ResourceSystemAccessMode } from '../resources/resources-config.shared.schemas.js';
 import { createResourceConfiguration_Initialization } from '../resources/resources-config.shared.factory.js';
 import { CORE_APP_ROLES, CORE_ORG_ROLES } from '../security/authorizations/roles.shared.schemas.js';
 // Custom operations enum for organization features
@@ -39,11 +40,30 @@ const ORGANIZATION_FEATURES_FILTER_FIELDS = {
 Organization Features Resource Configuration Factory
 */
 export const organizationFeaturesResourceConfiguration_InitializationFactory = (resourcesRelationships) => createResourceConfiguration_Initialization({
-    mainSchema: ScopeFeaturesWithOverridesSchema,
+    mainSchema: OrganizationFeaturesSchema,
     resourceIdentifier: CoreResourceType.ORGANIZATION_FEATURES,
     resourceFieldIdentifier: coreResourceShared_FieldIdentifier[CoreResourceType.ORGANIZATION_FEATURES],
     resourceRelationships: resourcesRelationships,
     isSystemResource: true,
+    /*
+     * The framework may materialise this scope's row on a caller's behalf — the same opt-in, for the
+     * same reason, as the APPLICATION_FEATURES twin beside it.
+     *
+     * `systemAccessPolicy.create: ALLOWED` is what #1179's seam reads before materialising a
+     * context-addressed singleton the caller never named, so an administrator can START setting a
+     * tenant's entitlement overrides instead of being 404ed for the framework's own omission. The row
+     * written is the scope foreign key and nothing else; this resource's schema fills the rest.
+     *
+     * NOTE, measured 2026-09-19: this does NOT make a READ materialise. That seam is reached for
+     * UPDATE and DELETE only — extending it to READ was tried and reverted, because a probe of the
+     * running backend showed the read route never enters it. A tenant whose row is still absent
+     * therefore still 404s when the Entitlements pane reads it; making that row EXIST is a seeding
+     * question, not an access-policy one.
+     */
+    systemAccessPolicy: {
+        read: ResourceSystemAccessMode.ALLOWED,
+        create: ResourceSystemAccessMode.ALLOWED,
+    },
     coreOperations: [
         CoreResourceOperation.CREATE,
         CoreResourceOperation.READ,
@@ -171,6 +191,9 @@ export const organizationFeaturesResourceConfiguration_InitializationFactory = (
                     isDefault: true,
                     roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN], // Only super admins can reset features
                     riskLevel: ResourceOperationRiskLevel.CRITICAL,
+                    // IRREVERSIBLE: Clears every override on the organization. No backup of the list exists.
+                    // This is what admits it to the danger zone; risk alone no longer does.
+                    reversibility: ResourceOperationReversibility.IRREVERSIBLE,
                     resourceOperationLike: CoreResourceOperation.UPDATE_MANY,
                     requestDto: OrganizationFeaturesResetFeaturesRequestDtoSchema,
                     customResponseDto: ScopeFeaturesWithOverridesSchema,