@wildo-ai/saas-models 1.1.3 → 1.1.5

package/dist/esm/organizations/organizations.shared.resources-config.schemas.js

@@ -15,24 +15,68 @@ import { createResourceConfiguration_Initialization } from '../resources/resourc
 import { ResourceSystemAccessMode } from '../resources/resources-config.shared.schemas.js';
 import { CORE_APP_ROLES, CORE_ORG_ROLES } from '../security/authorizations/roles.shared.schemas.js';
 /**
- * Tenant LIFECYCLE transitions — the operations that own `Organization.status`.
+ * Tenant LIFECYCLE transitions — the guarded transitions of a tenant's state and identity.
  *
  * Renamed from `Organization_AppAdmin_Operations` on 2026-08-01. The old name described the
  * AUDIENCE of the two members it happened to hold (`ACTIVATE`/`SUSPEND` are super-admin-only) and
  * stopped being true the moment an ORG_ADMIN-facing member joined it. The members share a
  * *concern*, not an audience: each is a guarded transition of the tenant state machine, declared
- * `resourceOperationLike: UPDATE`, gated by an `enabledCondition` on the current status, and the
- * sole authority for the `status` field that generic UPDATE may not write. The frontend already
+ * `resourceOperationLike: UPDATE`, gated by an `enabledCondition` on the tenant's current state, and
+ * the sole authority for a field that generic UPDATE may not write. The frontend already
  * called this concept by its right name — `organizationLifecycleOpViews` in the presets.
  *
- * `status` is `.excludeFromUpdate()`, so every transition here declares `authoritativeFields`
- * naming the fields its prefix owns; without that the repository's strict re-parse silently strips
- * the write and the operation answers success having changed nothing.
+ * Every member's field is `.excludeFromUpdate()`, so each declares `authoritativeFields` naming the
+ * fields its prefix owns; without that the repository's strict re-parse silently strips the write and
+ * the operation answers success having changed nothing.
+ *
+ * ## Which field each member owns
+ *
+ * Four members own `status`. {@link PROMOTE_TO_OWNER_ORGANIZATION} owns `type`, and it is why this
+ * doc no longer says "the operations that own `Organization.status`" (it did until #1054, when the
+ * first non-`status` member arrived). The generalisation is not a convenience: the paragraph above
+ * already described the shared concern without naming `status` once, and every clause of it holds of
+ * a type transition — guarded, `UPDATE`-like, conditioned on the tenant's current state, and the sole
+ * authority for an `.excludeFromUpdate()` field.
+ *
+ * A second enum was the alternative and is not available: `customOperation` on a resource
+ * configuration takes ONE `EnumLikeType`, so two enums would mean two resources.
  */
 export var Organization_Lifecycle_Operations;
 (function (Organization_Lifecycle_Operations) {
     Organization_Lifecycle_Operations["ACTIVATE"] = "activate";
     Organization_Lifecycle_Operations["SUSPEND"] = "suspend";
+    /**
+     * Re-type an existing organization as the one that OWNS the application — the paired mutation path
+     * for the otherwise-immutable `Organization.type` (#1054).
+     *
+     * ## Why it has to exist at all
+     *
+     * `type` is creation-time identity, so an application that adds `ownsApplication` to its declaration
+     * AFTER it has been running has no way to say which of its existing organizations is the owner: the
+     * bootstrap that would have typed one has already run, and nothing else may write `type`. Without
+     * this door the marker would only ever work on applications created after it — the immutability
+     * construct shipped with no way past it that `.claude/rules/design-philosophy.md` names.
+     *
+     * ## Why it is NOT cross-tenant
+     *
+     * The promoter must be a MEMBER of the target organization holding `APP_ADMIN_SUPER_ADMIN`, which
+     * the bootstrap administrator is. The crossing rule on this resource is "cross the boundary for
+     * actions a later action can undo", and promotion has no inverse: there is no demotion door, and
+     * building one would mean an application could be left with no owner organization at all. A crossed
+     * version would need that inverse, or a two-person rule, and neither is built.
+     *
+     * ## What it refuses, and why each refusal rather than a reconciliation
+     *
+     * The target type's `userTypes` must COVER the source type's, every existing membership role must be
+     * in the target type's `availableOrgRoles`, and a SCIM binding may not be lost. Those are the
+     * dependent policy surfaces a type carries — `userTypes` are granted on join and revoked on leave,
+     * and suspend/activate/restore re-derive them across three resources — so a promotion that changed
+     * any of them would owe a revoke-and-regrant reconciliation across every member, in one transaction,
+     * on a door used once in an application's life. Refusing instead keeps the operation honest about
+     * what it does: it changes the tenant's IDENTITY and touches nobody's authority. The refusal names
+     * the first mismatch, so the remedy is to widen the target type rather than to guess.
+     */
+    Organization_Lifecycle_Operations["PROMOTE_TO_OWNER_ORGANIZATION"] = "promoteToOwnerOrganization";
     /**
      * Mark the tenant for deletion — the SOFT-DELETE half of tenant teardown.
      *
@@ -106,6 +150,7 @@ export const organizationResourceConfiguration_InitializationFactory = (resource
      * | `activate` | ✅ | `SUSPENDED` confers no authority and is the only state ACTIVATE runs from. Recuperative. |
      * | `requestDeletion: admin` | ✅ | The operator takedown path — but the REVERSIBLE one: mark + notify + window, undone by `restore`. |
      * | `delete: admin` | ❌ | Irreversible, whole-tenant, cascading, skips the window. See its own block for the full decision. |
+     * | `promoteToOwnerOrganization` | ❌ | Irreversible by construction — there is no demotion door, and building one would let an application be left with no owner organization. The promoter is a super-administrator who is a MEMBER of the target, which the bootstrap administrator is. |
      * | everything else | ❌ | No demonstrated operator need. Absence of a use case is a reason to stay shut. |
      *
      * The organising principle: **cross the boundary for actions a later action can undo.** Every
@@ -702,7 +747,106 @@ export const organizationResourceConfiguration_InitializationFactory = (resource
                     channel: CoreUserNotificationChannel.EMAIL,
                 }
             ]
-        }
+        },
+        /**
+         * Promote this organization to the one that OWNS the application (#1054).
+         *
+         * The paired mutation path for `Organization.type`, which is creation-time identity. The field's
+         * own JSDoc has reserved exactly this since it was written: *"a future type transition must be a
+         * dedicated migration operation that reconciles every dependent member and policy surface"*. This
+         * is that operation, narrowed to the one transition the framework needs and refusing rather than
+         * reconciling — see the enum member's JSDoc for why refusing is the honest shape here.
+         *
+         * ## ⚠️ NOT cross-tenant, and this is the one place on this resource where that is a DESIGN
+         * decision rather than an omission
+         *
+         * The banner at the top of this configuration records the rule: **cross the boundary for actions a
+         * later action can undo.** `restore`, `activate` and `requestDeletion: admin` are crossed because
+         * each is reversible. Promotion is not: there is no demotion operation, deliberately, because an
+         * application whose owner organization can be un-typed is one that can be left with no owner at
+         * all — and `type` being immutable means nothing could then repair it.
+         *
+         * So the promoter is a super-administrator who is a MEMBER of the target organization. On the
+         * application this exists for, that is exactly who is available: the bootstrap administrator is a
+         * member of the organization the platform seeded for them, and that organization is the one being
+         * promoted. Opening the crossing would need a `demote` door or a two-person rule first.
+         *
+         * ## Why a `justification` is required
+         *
+         * It is the whole control on an irreversible act, in the same shape as
+         * `organizationMembers.grantOwnership`. It is RECORDED — on the `ORGANIZATION_TYPE_ASSIGNED` event
+         * this operation emits, beside the type it replaced — because a required request field that
+         * nothing stores is a promise nobody keeps (#593, where `grantOwnership`'s justification was
+         * validated and then dropped for months).
+         *
+         * ## Why no `enabledCondition` on "no owner exists yet"
+         *
+         * `enabledCondition` receives the CURRENT OBJECT — this organization — and the question "does the
+         * application already have an owner organization?" is about a different row. The refusal therefore
+         * lives in the custom implementation, which answers `409 APPLICATION_OWNER_ORGANIZATION_EXISTS`.
+         * The condition here covers what the current object CAN answer: only an ACTIVE tenant may be
+         * promoted, because a suspended or marked one confers no authority and promoting it would make the
+         * organization that operates the application one nobody can act through.
+         *
+         * assurance-control: WILDO.ACCESS.ADMINISTRATIVE_CONTINUITY — names the organization that operates
+         * the application, under justification and audit, on a door that cannot be reached from outside
+         * the tenant.
+         * assurance-control: WILDO.AUDIT.SECURITY_EVENT — an authentication-relevant tenant attribute
+         * changes, and the record names who changed it and why.
+         */
+        [Organization_Lifecycle_Operations.PROMOTE_TO_OWNER_ORGANIZATION]: {
+            variants: [
+                {
+                    variantType: ResourceOperationVariantType.API_CALL,
+                    isDefault: true,
+                    // Platform tier, and UNCROSSED — no `admitsCrossTenantPlatformAdministration`. The caller
+                    // must hold this key AND be a member of the target organization, which is what the two
+                    // tenant gates (`validateParentScopeAccess`, `authorizeOrganizations`) enforce on this
+                    // resource independently of the role table. See the JSDoc above for why the crossing stays
+                    // shut.
+                    roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],
+                    riskLevel: ResourceOperationRiskLevel.CRITICAL,
+                    resourceOperationLike: CoreResourceOperation.UPDATE,
+                    requestDto: z.object({
+                        justification: z.string().min(1).max(1000),
+                    }),
+                    // Irreversible and it re-points everything the application owns as an operator. A hijacked
+                    // session must not reach it on the strength of a login that happened at some earlier point.
+                    //
+                    // assurance-control: WILDO.IDENTITY.STEP_UP_AUTHENTICATION — re-authentication before a
+                    // high-impact action.
+                    requiresStepUpAuthentication: true,
+                    // Only an ACTIVE tenant. Every other status either confers no authority
+                    // (`ORGANIZATION_STATUSES_WITHOUT_AUTHORITY`) or is terminal, and an owner organization
+                    // nobody can act through is not an owner. Enforced on the frontend (the action renders
+                    // disabled) AND the backend (`services-registry-handler` throws
+                    // `SERVICE_RESOURCE_OPERATION_DISABLED` → 403). Keep in sync with the resource spec's
+                    // PROMOTE_TO_OWNER_ORGANIZATION error scenarios.
+                    enabledCondition: ({ currentObject }) => currentObject.status === OrganizationStatus.ACTIVE,
+                    // NO `haveBulkOperation` — same reasoning as every other member here, and stronger: at most
+                    // one organization may ever be promoted, so a multi-row selector is meaningless.
+                }
+            ],
+            /*
+             * NO `userNotifications`, and the reason is the UNCROSSED design rather than an omission.
+             *
+             * A first draft declared an email to `ORGANIZATION_ADMINISTRATIVE`, reasoning that the tenant
+             * should learn it now operates the application. Running it proved that wrong twice over.
+             *
+             * Mechanically: the declaration named a template nobody had authored, and the engine's lifecycle
+             * check said so at every boot — *"the operation still succeeds, but its notification is silently
+             * never delivered"*. A declared notification with no template is worse than none; it is a promise
+             * the running system reports as unkept.
+             *
+             * And on the merits, the audience is wrong. `organizationMembers.grantOwnership` notifies because
+             * it CROSSES: an operator outside the tenant changes who owns it, and the difference between a
+             * legitimate repair and a quiet self-grant is only visible to the tenant if it is told. Promotion
+             * is deliberately uncrossed — the caller is a super-administrator who is a MEMBER of the very
+             * organization being promoted — so there is no outsider to disclose and nobody the email would
+             * inform who was not already the actor. The audit row, which names the actor and their
+             * justification, is the record this act owes.
+             */
+        },
     },
 });
 //# sourceMappingURL=organizations.shared.resources-config.schemas.js.map

package/dist/esm/organizations/organizations.shared.resources-config.schemas.js.map

@@ -1 +1 @@
-{"version":3,"file":"organizations.shared.resources-config.schemas.js","sourceRoot":"","sources":["../../../../src/organizations/organizations.shared.resources-config.schemas.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AAEH,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AACxB,OAAO,EACL,kBAAkB,EAClB,kBAAkB,GACnB,MAAM,gCAAgC,CAAC;AACxC,OAAO,EAAE,qBAAqB,EAAE,MAAM,gDAAgD,CAAC;AACvF,OAAO,EAAE,0BAA0B,EAA8C,MAAM,uCAAuC,CAAC;AAC/H,OAAO,EAAE,gBAAgB,EAAE,kCAAkC,EAAE,MAAM,gDAAgD,CAAC;AACtH,OAAO,EAAE,4BAA4B,EAAE,MAAM,uCAAuC,CAAC;AACrF,OAAO,EAAE,0BAA0B,EAAE,2BAA2B,EAAE,MAAM,+CAA+C,CAAC;AAExH,OAAO,EAAE,0CAA0C,EAAE,MAAM,8CAA8C,CAAC;AAC1G,OAAO,EAAE,wBAAwB,EAAE,MAAM,8CAA8C,CAAC;AAExF,OAAO,EAAE,cAAc,EAAE,cAAc,EAAE,MAAM,iDAAiD,CAAC;AAGjG;;;;;;;;;;;;;;GAcG;AACH,MAAM,CAAN,IAAY,iCAoBX;AApBD,WAAY,iCAAiC;IAC3C,0DAAqB,CAAA;IACrB,wDAAmB,CAAA;IACnB;;;;;;;OAOG;IACH,0EAAqC,CAAA;IACrC;;;;;;OAMG;IACH,wDAAmB,CAAA;AACrB,CAAC,EApBW,iCAAiC,KAAjC,iCAAiC,QAoB5C;AAED,MAAM,8BAA8B,GAAG,CAAC,QAAQ,CAAC,CAAC;AAElD,MAAM,gCAAgC,GAAG;IACvC,MAAM,EAAE,CAAC,CAAC,IAAI,CAAC,kBAAkB,CAAC;CACnC,CAAC;AAUF;;EAEE;AACF,MAAM,CAAC,MAAM,uDAAuD,GAAG,CAAC,sBAA8C,EAAE,EAAE,CAAC,0CAA0C,CAInK;IACA,UAAU,EAAE,kBAAkB;IAC9B,kBAAkB,EAAE,gBAAgB,CAAC,aAAa;IAClD,uBAAuB,EAAE,kCAAkC,CAAC,gBAAgB,CAAC,aAAa,CAAC;IAC3F,qBAAqB,EAAE,sBAAsB;IAC7C,gBAAgB,EAAE,IAAI,EAAE,2CAA2C;IACnE,4EAA4E;IAC5E,8EAA8E;IAC9E,+EAA+E;IAC/E,uDAAuD;IACvD,kBAAkB,EAAE,EAAE,IAAI,EAAE,wBAAwB,CAAC,OAAO,EAAE;IAE9D,cAAc,EAAE;QACd,qBAAqB,CAAC,IAAI;QAC1B,qBAAqB,CAAC,IAAI;QAC1B,qBAAqB,CAAC,MAAM;QAC5B,qBAAqB,CAAC,MAAM;QAC5B,qBAAqB,CAAC,MAAM;QAC5B,qBAAqB,CAAC,MAAM;KAC7B;IAED,eAAe,EAAE,iCAAiC;IAElD;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OAsCG;IACH,uBAAuB,EAAE;QACvB,CAAC,qBAAqB,CAAC,MAAM,CAAC,EAAE;YAC9B,QAAQ,EAAE;gBACR;oBACE,wEAAwE;oBACxE,yEAAyE;oBACzE,yEAAyE;oBACzE,yEAAyE;oBACzE,sEAAsE;oBACtE,0DAA0D;oBAC1D,WAAW,EAAE,4BAA4B,CAAC,aAAa;oBACvD,SAAS,EAAE,IAAI;oBACf,KAAK,EAAE,EAAE;oBACT,SAAS,EAAE,0BAA0B,CAAC,MAAM;iBAC7C;gBACD;oBACE,WAAW,EAAE,4BAA4B,CAAC,QAAQ;oBAClD,SAAS,EAAE,IAAI;oBACf;;;;;;;;uBAQG;oBACH,KAAK,EAAE,CAAC,cAAc,CAAC,QAAQ,CAAC;oBAChC,SAAS,EAAE,0BAA0B,CAAC,MAAM;oBAC5C,qFAAqF;oBACrF,qFAAqF;oBACrF,uFAAuF;oBACvF,gEAAgE;iBACjE;gBACD;oBACE,WAAW,EAAE,4BAA4B,CAAC,QAAQ;oBAClD,SAAS,EAAE,KAAK;oBAChB,UAAU,EAAE,OAAO;oBACnB,KAAK,EAAE,CAAC,cAAc,CAAC,qBAAqB,CAAC,EAAE,oFAAoF;oBACnI,SAAS,EAAE,0BAA0B,CAAC,GAAG;oBACzC,qFAAqF;iBACtF;aACF;YACD,iBAAiB,EAAE;gBACjB;oBACE,MAAM,EAAE,0BAA0B,CAAC,SAAS;oBAC5C,OAAO,EAAE,2BAA2B,CAAC,KAAK;iBAC3C;gBACD;oBACE,MAAM,EAAE,0BAA0B,CAAC,SAAS;oBAC5C,OAAO,EAAE,2BAA2B,CAAC,iBAAiB;iBACvD;aACF;SACF;QAED,CAAC,qBAAqB,CAAC,IAAI,CAAC,EAAE;YAC5B,QAAQ,EAAE;gBACR;oBACE,WAAW,EAAE,4BAA4B,CAAC,QAAQ;oBAClD,SAAS,EAAE,IAAI;oBACf,KAAK,EAAE,CAAC,cAAc,CAAC,UAAU,CAAC,EAAE,0CAA0C;oBAC9E,SAAS,EAAE,0BAA0B,CAAC,GAAG;iBAC1C;gBACD;oBACE,WAAW,EAAE,4BAA4B,CAAC,QAAQ;oBAClD,SAAS,EAAE,KAAK;oBAChB,UAAU,EAAE,OAAO;oBACnB,KAAK,EAAE,CAAC,cAAc,CAAC,qBAAqB,CAAC,EAAE,2FAA2F;oBAC1I,SAAS,EAAE,0BAA0B,CAAC,GAAG;iBAC1C;aACF;SACF;QAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;WAiDG;QACH,CAAC,qBAAqB,CAAC,IAAI,CAAC,EAAE;YAC5B,QAAQ,EAAE;gBACR;oBACE,WAAW,EAAE,4BAA4B,CAAC,QAAQ;oBAClD,SAAS,EAAE,IAAI;oBACf,KAAK,EAAE,CAAC,cAAc,CAAC,qBAAqB,CAAC,EAAE,6GAA6G;oBAC5J,SAAS,EAAE,0BAA0B,CAAC,GAAG;oBACzC,YAAY,EAAE,gCAAgC;oBAC9C,UAAU,EAAE,8BAA8B;iBAC3C;aACF;SACF;QAED,CAAC,qBAAqB,CAAC,MAAM,CAAC,EAAE;YAC9B,QAAQ,EAAE,CAAC;oBACT,WAAW,EAAE,4BAA4B,CAAC,QAAQ;oBAClD,SAAS,EAAE,IAAI;oBACf,KAAK,EAAE,CAAC,cAAc,CAAC,qBAAqB,CAAC,EAAE,yCAAyC;oBACxF,SAAS,EAAE,0BAA0B,CAAC,GAAG;oBACzC,YAAY,EAAE,IAAI;oBAClB,gBAAgB,EAAE,CAAC,MAAM,EAAE,MAAM,EAAE,OAAO,CAAC;oBAC3C,iBAAiB,EAAE,EAAE,aAAa,EAAE,KAAK,EAAE,aAAa,EAAE,KAAK,EAAE;oBACjE,YAAY,EAAE,gCAAgC;oBAC9C,UAAU,EAAE,8BAA8B;oBAC1C,8BAA8B,EAAE,GAAG;iBACpC,CAAC;SACH;QAED,CAAC,qBAAqB,CAAC,MAAM,CAAC,EAAE;YAC9B,QAAQ,EAAE;gBACR;oBACE,WAAW,EAAE,4BAA4B,CAAC,QAAQ;oBAClD,SAAS,EAAE,IAAI;oBACf,KAAK,EAAE,CAAC,cAAc,CAAC,SAAS,CAAC,EAAE,2CAA2C;oBAC9E,SAAS,EAAE,0BAA0B,CAAC,MAAM;oBAC5C,qEAAqE;oBACrE,6EAA6E;oBAC7E,4EAA4E;oBAC5E,gFAAgF;oBAChF,6DAA6D;iBAC9D;gBACD;oBACE,WAAW,EAAE,4BAA4B,CAAC,QAAQ;oBAClD,SAAS,EAAE,KAAK;oBAChB,UAAU,EAAE,OAAO;oBACnB,KAAK,EAAE,CAAC,cAAc,CAAC,qBAAqB,CAAC,EAAE,qCAAqC;oBACpF,SAAS,EAAE,0BAA0B,CAAC,GAAG;oBACzC,qEAAqE;oBACrE,qEAAqE;oBACrE,kCAAkC;iBACnC;aACF;YACD,iBAAiB,EAAE;gBACjB;oBACE,MAAM,EAAE,0BAA0B,CAAC,2BAA2B;oBAC9D,OAAO,EAAE,2BAA2B,CAAC,KAAK;iBAC3C;aACF;SACF;QAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;WAwCG;QACH,CAAC,qBAAqB,CAAC,MAAM,CAAC,EAAE;YAC9B,QAAQ,EAAE;gBACR;oBACE,WAAW,EAAE,4BAA4B,CAAC,aAAa;oBACvD,SAAS,EAAE,IAAI;oBACf,KAAK,EAAE,EAAE;oBACT,SAAS,EAAE,0BAA0B,CAAC,QAAQ;iBAC/C;gBACD;oBACE,WAAW,EAAE,4BAA4B,CAAC,QAAQ;oBAClD,SAAS,EAAE,KAAK;oBAChB,UAAU,EAAE,OAAO;oBACnB,KAAK,EAAE,CAAC,cAAc,CAAC,qBAAqB,CAAC;oBAC7C,SAAS,EAAE,0BAA0B,CAAC,IAAI;oBAC1C,EAAE;oBACF,0FAA0F;oBAC1F,wDAAwD;oBACxD,wFAAwF;oBACxF,EAAE;oBACF,2FAA2F;oBAC3F,qFAAqF;oBACrF,2FAA2F;oBAC3F,8CAA8C;oBAC9C,EAAE;oBACF,mFAAmF;oBACnF,qFAAqF;oBACrF,0FAA0F;oBAC1F,2FAA2F;oBAC3F,oFAAoF;oBACpF,EAAE;oBACF,wFAAwF;oBACxF,yFAAyF;oBACzF,0FAA0F;oBAC1F,2FAA2F;oBAC3F,uEAAuE;oBACvE,EAAE;oBACF,2FAA2F;oBAC3F,iFAAiF;oBACjF,yFAAyF;oBACzF,2FAA2F;oBAC3F,uFAAuF;oBACvF,4CAA4C;oBAC5C,EAAE;oBACF,yFAAyF;oBACzF,0FAA0F;oBAC1F,kFAAkF;oBAClF,0FAA0F;oBAC1F,yFAAyF;oBACzF,wFAAwF;oBACxF,mFAAmF;oBACnF,EAAE;oBACF,sFAAsF;oBACtF,kEAAkE;oBAClE,EAAE;oBACF,EAAE;oBACF,2FAA2F;oBAC3F,qFAAqF;oBACrF,sFAAsF;oBACtF,2EAA2E;oBAC3E,EAAE;oBACF,4GAA4G;oBAC5G,4BAA4B,EAAE,IAAI;iBACnC;aACF;SACF;QAED,CAAC,iCAAiC,CAAC,QAAQ,CAAC,EAAE;YAC5C,QAAQ,EAAE;gBACR;oBACE,WAAW,EAAE,4BAA4B,CAAC,QAAQ;oBAClD,SAAS,EAAE,IAAI;oBACf,KAAK,EAAE,CAAC,cAAc,CAAC,qBAAqB,CAAC;oBAC7C,SAAS,EAAE,0BAA0B,CAAC,MAAM;oBAC5C,qBAAqB,EAAE,qBAAqB,CAAC,MAAM;oBACnD,0FAA0F;oBAC1F,wFAAwF;oBACxF,0FAA0F;oBAC1F,0FAA0F;oBAC1F,2FAA2F;oBAC3F,0FAA0F;oBAC1F,6DAA6D;oBAC7D,uCAAuC,EAAE,IAAI;oBAC7C,UAAU,EAAE,CAAC,CAAC,MAAM,CAAC;wBACnB,MAAM,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,GAAG,CAAC,CAAC,QAAQ,EAAE;qBACvC,CAAC;oBACF,uEAAuE;oBACvE,sEAAsE;oBACtE,+DAA+D;oBAC/D,kEAAkE;oBAClE,qEAAqE;oBACrE,kDAAkD;oBAClD,wEAAwE;oBACxE,uEAAuE;oBACvE,mCAAmC;oBACnC,gBAAgB,EAAE,CAAC,EAAE,aAAa,EAAE,EAAE,EAAE;wBACtC,OAAO,CACL,aAAa,CAAC,MAAM,KAAK,kBAAkB,CAAC,SAAS;4BACrD,aAAa,CAAC,MAAM,KAAK,kBAAkB,CAAC,aAAa,CAC1D,CAAC;oBACJ,CAAC;oBACD,yFAAyF;oBACzF,oFAAoF;oBACpF,sFAAsF;oBACtF,yFAAyF;oBACzF,qFAAqF;oBACrF,wFAAwF;oBACxF,wFAAwF;oBACxF,6EAA6E;oBAC7E,uFAAuF;oBACvF,sFAAsF;iBACvF;aACF;YACD,iBAAiB,EAAE;gBACjB;oBACE,MAAM,EAAE,0BAA0B,CAAC,2BAA2B;oBAC9D,OAAO,EAAE,2BAA2B,CAAC,KAAK;iBAC3C;aACF;SACF;QAED,CAAC,iCAAiC,CAAC,OAAO,CAAC,EAAE;YAC3C,QAAQ,EAAE;gBACR;oBACE,WAAW,EAAE,4BAA4B,CAAC,QAAQ;oBAClD,SAAS,EAAE,IAAI;oBACf,KAAK,EAAE,CAAC,cAAc,CAAC,qBAAqB,CAAC,EAAE,8CAA8C;oBAC7F,SAAS,EAAE,0BAA0B,CAAC,QAAQ;oBAC9C,qBAAqB,EAAE,qBAAqB,CAAC,MAAM;oBACnD,UAAU,EAAE,CAAC,CAAC,MAAM,CAAC;wBACnB,gBAAgB,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,GAAG,CAAC,GAAG,CAAC;wBAC5C,aAAa,EAAE,CAAC,CAAC,OAAO,EAAE,CAAC,OAAO,CAAC,IAAI,CAAC;qBACzC,CAAC;oBACF,uEAAuE;oBACvE,qEAAqE;oBACrE,wEAAwE;oBACxE,uEAAuE;oBACvE,kDAAkD;oBAClD,oEAAoE;oBACpE,wEAAwE;oBACxE,2CAA2C;oBAC3C,gBAAgB,EAAE,CAAC,EAAE,aAAa,EAAE,EAAE,EAAE;wBACtC,OAAO,CACL,aAAa,CAAC,MAAM,KAAK,kBAAkB,CAAC,MAAM;4BAClD,aAAa,CAAC,MAAM,KAAK,kBAAkB,CAAC,KAAK,CAClD,CAAC;oBACJ,CAAC;oBACD,wFAAwF;oBACxF,qFAAqF;iBACtF;aACF;YACD,iBAAiB,EAAE;gBACjB;oBACE,MAAM,EAAE,0BAA0B,CAAC,kBAAkB;oBACrD,OAAO,EAAE,2BAA2B,CAAC,KAAK;oBAC1C,+EAA+E;oBAC/E,EAAE;oBACF,oFAAoF;oBACpF,0FAA0F;oBAC1F,qFAAqF;oBACrF,yFAAyF;oBACzF,kEAAkE;oBAClE,EAAE;oBACF,mFAAmF;oBACnF,mCAAmC;oBACnC,SAAS,EAAE,CAAC,EAAE,QAAQ,EAAE,EAAE,EAAE,CAAE,QAAoD,EAAE,aAAa,KAAK,KAAK;iBAC5G;aACF;SACF;QAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;WA6CG;QACH,CAAC,iCAAiC,CAAC,gBAAgB,CAAC,EAAE;YACpD,QAAQ,EAAE;gBACR;oBACE,WAAW,EAAE,4BAA4B,CAAC,QAAQ;oBAClD,SAAS,EAAE,IAAI;oBACf,KAAK,EAAE,CAAC,cAAc,CAAC,SAAS,CAAC,EAAE,4DAA4D;oBAC/F,SAAS,EAAE,0BAA0B,CAAC,QAAQ;oBAC9C,qBAAqB,EAAE,qBAAqB,CAAC,MAAM;oBACnD,UAAU,EAAE,CAAC,CAAC,MAAM,CAAC;wBACnB,MAAM,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,GAAG,CAAC,CAAC,QAAQ,EAAE;qBACvC,CAAC;oBACF,4BAA4B,EAAE,IAAI;oBAClC,sFAAsF;oBACtF,oFAAoF;oBACpF,yEAAyE;oBACzE,yFAAyF;oBACzF,sFAAsF;oBACtF,kEAAkE;oBAClE,EAAE;oBACF,oFAAoF;oBACpF,kEAAkE;oBAClE,8EAA8E;oBAC9E,iFAAiF;oBACjF,uFAAuF;oBACvF,4EAA4E;oBAC5E,gBAAgB,EAAE,CAAC,EAAE,aAAa,EAAE,EAAE,EAAE;wBACtC,OAAO,CACL,aAAa,CAAC,MAAM,KAAK,kBAAkB,CAAC,MAAM;4BAClD,aAAa,CAAC,MAAM,KAAK,kBAAkB,CAAC,KAAK;4BACjD,aAAa,CAAC,MAAM,KAAK,kBAAkB,CAAC,aAAa;4BACzD,aAAa,CAAC,MAAM,KAAK,kBAAkB,CAAC,SAAS,CACtD,CAAC;oBACJ,CAAC;oBACD,sFAAsF;oBACtF,uFAAuF;oBACvF,gFAAgF;iBACjF;gBACD;oBACE,WAAW,EAAE,4BAA4B,CAAC,QAAQ;oBAClD,SAAS,EAAE,KAAK;oBAChB,UAAU,EAAE,OAAO;oBACnB,KAAK,EAAE,CAAC,cAAc,CAAC,qBAAqB,CAAC;oBAC7C,uFAAuF;oBACvF,2FAA2F;oBAC3F,wFAAwF;oBACxF,6DAA6D;oBAC7D,EAAE;oBACF,uFAAuF;oBACvF,wFAAwF;oBACxF,4EAA4E;oBAC5E,EAAE;oBACF,uFAAuF;oBACvF,yFAAyF;oBACzF,0FAA0F;oBAC1F,wBAAwB;oBACxB,uCAAuC,EAAE,IAAI;oBAC7C,SAAS,EAAE,0BAA0B,CAAC,IAAI;oBAC1C,qBAAqB,EAAE,qBAAqB,CAAC,MAAM;oBACnD,UAAU,EAAE,CAAC,CAAC,MAAM,CAAC;wBACnB,MAAM,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,GAAG,CAAC,CAAC,QAAQ,EAAE;qBACvC,CAAC;oBACF,yFAAyF;oBACzF,2EAA2E;oBAC3E,4BAA4B,EAAE,IAAI;oBAClC,gBAAgB,EAAE,CAAC,EAAE,aAAa,EAAE,EAAE,EAAE;wBACtC,OAAO,CACL,aAAa,CAAC,MAAM,KAAK,kBAAkB,CAAC,MAAM;4BAClD,aAAa,CAAC,MAAM,KAAK,kBAAkB,CAAC,KAAK;4BACjD,aAAa,CAAC,MAAM,KAAK,kBAAkB,CAAC,aAAa;4BACzD,aAAa,CAAC,MAAM,KAAK,kBAAkB,CAAC,SAAS,CACtD,CAAC;oBACJ,CAAC;iBACF;aACF;YACD,iBAAiB,EAAE;gBACjB;oBACE,gFAAgF;oBAChF,sFAAsF;oBACtF,wFAAwF;oBACxF,MAAM,EAAE,0BAA0B,CAAC,kBAAkB;oBACrD,OAAO,EAAE,2BAA2B,CAAC,KAAK;iBAC3C;aACF;SACF;QAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;WA0CG;QACH,CAAC,iCAAiC,CAAC,OAAO,CAAC,EAAE;YAC3C,QAAQ,EAAE;gBACR;oBACE,WAAW,EAAE,4BAA4B,CAAC,QAAQ;oBAClD,SAAS,EAAE,IAAI;oBACf,KAAK,EAAE,CAAC,cAAc,CAAC,qBAAqB,CAAC,EAAE,8DAA8D;oBAC7G,SAAS,EAAE,0BAA0B,CAAC,IAAI;oBAC1C,2FAA2F;oBAC3F,2FAA2F;oBAC3F,uFAAuF;oBACvF,uFAAuF;oBACvF,wFAAwF;oBACxF,qFAAqF;oBACrF,EAAE;oBACF,2FAA2F;oBAC3F,0FAA0F;oBAC1F,sDAAsD;oBACtD,uCAAuC,EAAE,IAAI;oBAC7C,qBAAqB,EAAE,qBAAqB,CAAC,MAAM;oBACnD,UAAU,EAAE,CAAC,CAAC,MAAM,CAAC;wBACnB,MAAM,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,GAAG,CAAC,CAAC,QAAQ,EAAE;qBACvC,CAAC;oBACF,sFAAsF;oBACtF,4DAA4D;oBAC5D,gBAAgB,EAAE,CAAC,EAAE,aAAa,EAAE,EAAE,EAAE;wBACtC,OAAO,aAAa,CAAC,MAAM,KAAK,kBAAkB,CAAC,OAAO,CAAC;oBAC7D,CAAC;iBACF;aACF;YACD,iBAAiB,EAAE;gBACjB;oBACE,MAAM,EAAE,0BAA0B,CAAC,kBAAkB;oBACrD,OAAO,EAAE,2BAA2B,CAAC,KAAK;iBAC3C;aACF;SACF;KACF;CAEF,CAAC,CAAC","sourcesContent":["/**\n * Organization Shared DTO Schemas\n *\n * Operation schemas for organization management.\n * Separated into App Admin concerns and Organization self-management.\n */\n\nimport { z } from 'zod';\nimport {\n  OrganizationSchema,\n  OrganizationStatus,\n} from './organizations.shared.schemas';\nimport { CoreResourceOperation } from '../resources/resources.shared.core.definitions';\nimport { ResourceOperationRiskLevel, ResourcePrimaryScope, ResourceRelationship } from '../resources/resources.shared.schemas';\nimport { CoreResourceType, coreResourceShared_FieldIdentifier } from '../resources/resources.shared.core.definitions';\nimport { ResourceOperationVariantType } from '../resources/resources.shared.schemas';\nimport { CoreUserNotificationTarget, CoreUserNotificationChannel } from '../notifications/notifications.shared.schemas';\n\nimport { createResourceConfiguration_Initialization } from '../resources/resources-config.shared.factory';\nimport { ResourceSystemAccessMode } from '../resources/resources-config.shared.schemas';\n\nimport { CORE_APP_ROLES, CORE_ORG_ROLES } from '../security/authorizations/roles.shared.schemas';\n\n\n/**\n * Tenant LIFECYCLE transitions — the operations that own `Organization.status`.\n *\n * Renamed from `Organization_AppAdmin_Operations` on 2026-08-01. The old name described the\n * AUDIENCE of the two members it happened to hold (`ACTIVATE`/`SUSPEND` are super-admin-only) and\n * stopped being true the moment an ORG_ADMIN-facing member joined it. The members share a\n * *concern*, not an audience: each is a guarded transition of the tenant state machine, declared\n * `resourceOperationLike: UPDATE`, gated by an `enabledCondition` on the current status, and the\n * sole authority for the `status` field that generic UPDATE may not write. The frontend already\n * called this concept by its right name — `organizationLifecycleOpViews` in the presets.\n *\n * `status` is `.excludeFromUpdate()`, so every transition here declares `authoritativeFields`\n * naming the fields its prefix owns; without that the repository's strict re-parse silently strips\n * the write and the operation answers success having changed nothing.\n */\nexport enum Organization_Lifecycle_Operations {\n  ACTIVATE = 'activate',\n  SUSPEND = 'suspend',\n  /**\n   * Mark the tenant for deletion — the SOFT-DELETE half of tenant teardown.\n   *\n   * Replaces the tenant-facing `DELETE` door, which now belongs to the purge batch. Writes\n   * `status: DELETED` + `deletionRequestedAt` + `purgeScheduledAt`, reconciles every affected user's global\n   * `userTypes`, and invalidates their tokens — so the tenant is authorization-dead immediately\n   * while remaining fully data-alive and restorable until the window elapses.\n   */\n  REQUEST_DELETION = 'request_deletion',\n  /**\n   * Cancel a pending deletion inside the retention window.\n   *\n   * The inverse of {@link REQUEST_DELETION}. Nothing needs re-creating: authority is re-derived\n   * from the membership rows the window deliberately preserved, which is exactly why those rows\n   * are not touched at mark time.\n   */\n  RESTORE = 'restore',\n}\n\nconst ORGANIZATION_ADMIN_SORT_FIELDS = ['status'];\n\nconst ORGANIZATION_ADMIN_FILTER_FIELDS = {\n  status: z.enum(OrganizationStatus),\n};\n\ntype OrganizationCoreOperations =\n  | CoreResourceOperation.READ\n  | CoreResourceOperation.LIST\n  | CoreResourceOperation.SEARCH\n  | CoreResourceOperation.CREATE\n  | CoreResourceOperation.UPDATE\n  | CoreResourceOperation.DELETE;\n\n/*\nOrganizations Resource Configuration Factory\n*/\nexport const organizationResourceConfiguration_InitializationFactory = (resourcesRelationships: ResourceRelationship[]) => createResourceConfiguration_Initialization<\n  typeof Organization_Lifecycle_Operations,\n  OrganizationCoreOperations,\n  typeof OrganizationSchema\n>({\n  mainSchema: OrganizationSchema,\n  resourceIdentifier: CoreResourceType.ORGANIZATIONS,\n  resourceFieldIdentifier: coreResourceShared_FieldIdentifier[CoreResourceType.ORGANIZATIONS],\n  resourceRelationships: resourcesRelationships,\n  isSystemResource: true, // Organizations are a core system resource\n  // The invitation-accept auth flow reads the inviting org's display name via\n  // `readAsSystem` to render the invite email — the invitee is not yet a member\n  // and cannot satisfy the org READ ACL. READ-only; the request is authorized by\n  // the consumable invitation token, not org membership.\n  systemAccessPolicy: { read: ResourceSystemAccessMode.ALLOWED },\n\n  coreOperations: [\n    CoreResourceOperation.READ,\n    CoreResourceOperation.LIST,\n    CoreResourceOperation.SEARCH,\n    CoreResourceOperation.CREATE,\n    CoreResourceOperation.UPDATE,\n    CoreResourceOperation.DELETE\n  ],\n\n  customOperation: Organization_Lifecycle_Operations,\n\n  /**\n   * ⚠️ WHAT `APP_ADMIN_SUPER_ADMIN` ACTUALLY BUYS ON THIS RESOURCE (measured 2026-08-05, not inferred)\n   *\n   * Every super-admin-gated variant below reads as cross-tenant (\"any organization\"). **It is not.**\n   * A probe against the real authorization service with real Mongo denied ALL 12 of them to a\n   * platform super-administrator who is not scoped to the target tenant; the same 12 allow once the\n   * caller's execution context carries `initiatorIds.organizationId` equal to that tenant.\n   *\n   * The reason is that tenant isolation is enforced at two gates the role table does not reach:\n   * `validateParentScopeAccess` (collection calls) and `authorizeOrganizations` (per-instance\n   * calls). Both compare the request against the CALLER'S OWN organization. A role key, however\n   * privileged, does not supply one.\n   *\n   * So these variants mean \"a super-admin acting INSIDE an organization\", not \"a super-admin acting\n   * on any organization\". Read every `// Super admins can … any organization` comment below with\n   * that correction applied — they were written from the role gate alone.\n   *\n   * Making one genuinely cross-tenant is a deliberate, per-variant act: declare\n   * `admitsCrossTenantPlatformAdministration` on it, which admits the crossing at BOTH gates.\n   *\n   * ## Which variants are crossed, and why the line falls there (decided 2026-08-05)\n   *\n   * | Variant | Crossed | Reason |\n   * |---|---|---|\n   * | `restore` | ✅ | A MARKED tenant is `DELETED`, which confers no authority, so NOBODY could restore one. Recuperative. |\n   * | `activate` | ✅ | `SUSPENDED` confers no authority and is the only state ACTIVATE runs from. Recuperative. |\n   * | `requestDeletion: admin` | ✅ | The operator takedown path — but the REVERSIBLE one: mark + notify + window, undone by `restore`. |\n   * | `delete: admin` | ❌ | Irreversible, whole-tenant, cascading, skips the window. See its own block for the full decision. |\n   * | everything else | ❌ | No demonstrated operator need. Absence of a use case is a reason to stay shut. |\n   *\n   * The organising principle: **cross the boundary for actions a later action can undo.** Every\n   * crossing above is recoverable, which is what lets the crossing be justified on operator need\n   * alone. `delete: admin` is the inverse and is therefore held to a higher bar it does not yet\n   * meet. `organizationMembers.grantOwnership` (the owner-floor repair door) follows the same rule\n   * on the membership resource.\n   *\n   * See `.claude/rules/administrative-continuity-floors.md` and\n   * `cross-tenant-super-admin-reach.mongo.integration.test.ts`.\n   */\n  operationsConfiguration: {\n    [CoreResourceOperation.CREATE]: {\n      variants: [\n        {\n          // Registration and registration-onboarding create organizations through\n          // `ServicesRegistryHandlerBackendService.create()`. INTERNAL_CALL is the\n          // service layer's native, route-less transport, so it gives that trusted\n          // workflow a distinct operation identity instead of making it masquerade\n          // as the public self-service endpoint. The organization CREATE prefix\n          // allows creation-policy-managed types only on this path.\n          variantType: ResourceOperationVariantType.INTERNAL_CALL,\n          isDefault: true,\n          roles: [],\n          riskLevel: ResourceOperationRiskLevel.MEDIUM,\n        },\n        {\n          variantType: ResourceOperationVariantType.API_CALL,\n          isDefault: true,\n          /*\n           * Any authenticated user may create their own organization, and OWNERSHIP IS ESTABLISHED\n           * BY THE CREATE FLOW rather than by a role — which was aspirational until 2026-09-08\n           * (#436) and is now true: this variant's postfix writes the founding owner membership for\n           * the creator, so a self-service create can no longer produce a tenant with no members.\n           * The `admin` variant below deliberately does NOT, because a platform operator must not\n           * become a member of a customer tenant; that tenant's first owner is named through the\n           * audited `organizationMembers.grantOwnership` door.\n           */\n          roles: [CORE_APP_ROLES.APP_USER],\n          riskLevel: ResourceOperationRiskLevel.MEDIUM,\n          // DTOs auto-derived from decorators (excludeFromCreate on _id, createdAt, updatedAt)\n          // `status` IS accepted on CREATE (it carries `.default(ACTIVE)`, so an omitted value\n          // lands ACTIVE). Only UPDATE excludes it — see the field's JSDoc for why a tenant must\n          // not be able to re-set its own lifecycle state after the fact.\n        },\n        {\n          variantType: ResourceOperationVariantType.API_CALL,\n          isDefault: false,\n          variantKey: \"admin\",\n          roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN], // Not crossed — see the banner table; creation has no existing tenant to cross into\n          riskLevel: ResourceOperationRiskLevel.LOW,\n          // DTOs auto-derived from decorators (excludeFromCreate on _id, createdAt, updatedAt)\n        }\n      ],\n      userNotifications: [\n        {\n          target: CoreUserNotificationTarget.USER_SELF,\n          channel: CoreUserNotificationChannel.EMAIL,\n        },\n        {\n          target: CoreUserNotificationTarget.USER_SELF,\n          channel: CoreUserNotificationChannel.FRONT_END_SUCCESS,\n        }\n      ]\n    },\n\n    [CoreResourceOperation.READ]: {\n      variants: [\n        {\n          variantType: ResourceOperationVariantType.API_CALL,\n          isDefault: true,\n          roles: [CORE_ORG_ROLES.ORG_MEMBER], // Org members can view their organization\n          riskLevel: ResourceOperationRiskLevel.LOW,\n        },\n        {\n          variantType: ResourceOperationVariantType.API_CALL,\n          isDefault: false,\n          variantKey: \"admin\",\n          roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN], // Not crossed — see the banner table; a super-admin reads organizations they are scoped to\n          riskLevel: ResourceOperationRiskLevel.LOW,\n        }\n      ]\n    },\n\n    /**\n     * ⚠️ THE SCOPE-ROOT COLLECTION OPERATIONS — read this before changing LIST, SEARCH, CREATE or\n     * the roles any of them declares.\n     *\n     * THREE verbs, not two. The banner named only the two reads until 2026-09-08 (#436), and the\n     * omission read as a decision: a reviewer asking \"does CREATE take this branch?\" found a\n     * document that answered for LIST and SEARCH and said nothing about the third. It does — the\n     * branch keys on the RESOURCE being its own scope root, never on the operation — and\n     * `scope-root-collection-gate.test.ts` pins CREATE for `APP_USER` alongside the two reads.\n     *\n     * `organizations` is the ONLY resource that is both ORGANIZATIONS-scoped and its own scope ROOT,\n     * and that makes both of its collection reads special in a way no other resource's are.\n     *\n     * **Their roles resolve against the APPLICATION table, not the organization one.** There is no\n     * `:organizationId` segment on `/organizations`, so `validateParentScopeAccess` cannot ask \"what\n     * are your roles inside THIS tenant\" — it takes the scope-root branch and validates the declared\n     * roles against the caller's APPLICATION-scope entries. Declaring an ORGANIZATION role on either\n     * of these would therefore be unsatisfiable, not merely unusual.\n     *\n     * **Row confinement is NOT free here, and until 2026-08-11 it did not exist.** Every other\n     * org-scoped resource is confined on its `organizationId` COLUMN; the tenant row has no such\n     * column, so both persistence adapters lost the axis and a scope-root LIST compiled to the EMPTY\n     * filter. The comment that used to sit on this line asserted the opposite — \"still filtered to\n     * the caller's own organization\" — and was the reason the gate looked like the only thing\n     * broken. Confinement now comes from `assignScopeRootCollectionConfinementToFilter`, which\n     * restricts these reads to the tenants the caller holds an organization-WIDE role entry for.\n     *\n     * So a platform super-administrator sees THEIR OWN organizations here, not every tenant — which\n     * is the same correction the banner above records for the other eleven super-admin variants. A\n     * genuine cross-tenant directory is NOT available by declaring\n     * `admitsCrossTenantPlatformAdministration`: that admission requires a usable platform-access\n     * grant for a TARGET tenant, and a collection call has no target. See\n     * `.claude/plans/organizations-scope-root-collection-gate-analysis.md`.\n     *\n     * ## ⚠️ If you are here because an operator \"cannot find the tenant id\", STOP\n     *\n     * That is the known and DELIBERATE consequence of the confinement, not a bug in it. An operator\n     * needs an `organizationId` to request a platform-access grant, and no in-product surface yields\n     * the id of a tenant they are not a member of.\n     *\n     * Widening this operation is the obvious fix and the wrong one: it re-opens the cross-tenant\n     * disclosure the confinement closed, and hands the full customer list to every platform\n     * administrator as a standing privilege — exactly what the grant mechanism was built to remove.\n     *\n     * The intended flow is that the id arrives from OUTSIDE the product, with the customer's support\n     * ticket (Microsoft Customer Lockbox and Google Access Approval both work this way). The full\n     * reasoning, and what a legitimate directory operation would look like instead, is on\n     * `platformAccessGrants | requestAccess`'s `organizationId` field and in SEC-SCOPEROOT-5\n     * (`.claude/plans/DEFERRED.md`).\n     */\n    [CoreResourceOperation.LIST]: {\n      variants: [\n        {\n          variantType: ResourceOperationVariantType.API_CALL,\n          isDefault: true,\n          roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN], // Not crossed — resolved against the APPLICATION role table; rows confined to the caller's own organizations\n          riskLevel: ResourceOperationRiskLevel.LOW,\n          filterFields: ORGANIZATION_ADMIN_FILTER_FIELDS,\n          sortFields: ORGANIZATION_ADMIN_SORT_FIELDS,\n        }\n      ]\n    },\n\n    [CoreResourceOperation.SEARCH]: {\n      variants: [{\n        variantType: ResourceOperationVariantType.API_CALL,\n        isDefault: true,\n        roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN], // Same scope-root contract as LIST above\n        riskLevel: ResourceOperationRiskLevel.LOW,\n        isSearchable: true,\n        searchableFields: ['name', 'slug', 'email'],\n        searchableOptions: { caseSensitive: false, fullMatchOnly: false },\n        filterFields: ORGANIZATION_ADMIN_FILTER_FIELDS,\n        sortFields: ORGANIZATION_ADMIN_SORT_FIELDS,\n        maxPaginatedResultPerPageLimit: 100,\n      }],\n    },\n\n    [CoreResourceOperation.UPDATE]: {\n      variants: [\n        {\n          variantType: ResourceOperationVariantType.API_CALL,\n          isDefault: true,\n          roles: [CORE_ORG_ROLES.ORG_ADMIN], // Org admins can update their organization\n          riskLevel: ResourceOperationRiskLevel.MEDIUM,\n          // DTOs auto-derived from decorators (excludeFromUpdate on _id, type,\n          // slug, status, createdAt, updatedAt). Organization-type transitions require\n          // a dedicated dependent-policy migration, not a generic patch, and `status`\n          // belongs to the SUSPEND / ACTIVATE verbs — this variant is ORG_ADMIN-gated, so\n          // accepting it here let a suspended tenant reinstate itself.\n        },\n        {\n          variantType: ResourceOperationVariantType.API_CALL,\n          isDefault: false,\n          variantKey: \"admin\",\n          roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN], // Not crossed — see the banner table\n          riskLevel: ResourceOperationRiskLevel.LOW,\n          // DTOs auto-derived from decorators (excludeFromUpdate on _id, type,\n          // slug, createdAt, updatedAt). Super-admin scope does not make a raw\n          // type rewrite semantically safe.\n        }\n      ],\n      userNotifications: [\n        {\n          target: CoreUserNotificationTarget.ORGANIZATION_ADMINISTRATIVE,\n          channel: CoreUserNotificationChannel.EMAIL,\n        }\n      ]\n    },\n\n    /**\n     * DELETE is the PURGE — the irreversible half of tenant teardown, reached at the END of the\n     * retention window and no longer the tenant-facing door.\n     *\n     * ## Why the tenant-facing variant is gone\n     *\n     * Deleting a tenant used to be synchronous and immediate: one `DELETE /organizations/{id}` by\n     * an ORG_ADMIN destroyed the tenant and everything the cascade reached. Tenant offboarding is\n     * a job-shaped problem, not a request-shaped one, so it is now two phases —\n     * {@link Organization_Lifecycle_Operations.REQUEST_DELETION} marks the tenant (and kills its\n     * authority immediately), and this operation destroys it once\n     * `Organization.purgeScheduledAt` has elapsed. Leaving an ORG_ADMIN-reachable synchronous\n     * DELETE in place would have made the retention window optional for exactly the caller it\n     * protects, which is the same as not having one.\n     *\n     * ## The two remaining doors\n     *\n     * - **INTERNAL_CALL (default)** — the route-less service transport the `organization-purge`\n     *   batch dispatches through. Route-less is the point: a window that any client can skip is\n     *   decorative. This mirrors CREATE on this same resource, whose default is likewise an\n     *   INTERNAL_CALL owned by a trusted workflow.\n     * - **API_CALL `admin`** — the super-administrator's deliberate purge-now escape hatch, for a\n     *   legal-order or abuse takedown that cannot wait out the window. Kept because operators\n     *   genuinely need it and because forcing them to a database console would be strictly worse\n     *   for auditability: this door is role-gated, step-up-gated, and emits `ORGANIZATION_DELETED`\n     *   like any other purge. It SKIPS the retention window by design.\n     *\n     * ⚠️ Custom implementations resolve by an exact operation-path key that embeds `variantType`.\n     * The default door changing from API_CALL to INTERNAL_CALL therefore MOVES the key that\n     * `organization-deletion-audit.custom-impl.backend.service.ts` registers on — that file was\n     * updated in the same pass. A hook left on the old key silently never runs.\n     *\n     * Cascading delete is handled via `childOperations.lifecycle.onParentDelete` on relationships.\n     *\n     * ⚠️ NO `userNotifications` here any more. They moved to `REQUEST_DELETION`, which is where\n     * they can still reach anyone: telling an organization's users that it has been deleted, in\n     * the same transaction that deletes those users' memberships, is a notification with no\n     * audience — and the batch that triggers a purge has no initiating user context to render it\n     * from. The members are told when the tenant is MARKED, which is also the only moment the\n     * warning is actionable (it can still be restored).\n     */\n    [CoreResourceOperation.DELETE]: {\n      variants: [\n        {\n          variantType: ResourceOperationVariantType.INTERNAL_CALL,\n          isDefault: true,\n          roles: [],\n          riskLevel: ResourceOperationRiskLevel.CRITICAL,\n        },\n        {\n          variantType: ResourceOperationVariantType.API_CALL,\n          isDefault: false,\n          variantKey: \"admin\",\n          roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],\n          riskLevel: ResourceOperationRiskLevel.HIGH,\n          //\n          // ⚠️ DELIBERATELY NOT CROSS-TENANT — the one super-admin door on this resource left shut,\n          // decided 2026-08-05. Do not \"finish the job\" by adding\n          // `admitsCrossTenantPlatformAdministration` here without re-opening the decision below.\n          //\n          // The tension is real and worth stating rather than hiding: the JSDoc above says this door\n          // is kept because operators genuinely need it and because pushing them to a database\n          // console would be strictly worse for auditability. Both halves argue for opening it. What\n          // outweighs them is asymmetry of consequence.\n          //\n          // Every other crossing on this resource is recoverable. ACTIVATE un-halts, RESTORE\n          // un-marks, REQUEST_DELETION marks-with-a-window. `grantOwnership` on the membership\n          // resource is additive and idempotent. Their safety argument is \"one narrow effect that a\n          // later action can undo\". This operation is the exact inverse: irreversible, whole-tenant,\n          // cascading, and it SKIPS the window on purpose. There is no RESTORE after a purge.\n          //\n          // The security cost is a change of KIND, not degree. Today a compromised platform-admin\n          // credential can destroy only tenants that principal is already scoped into — accidental\n          // containment, but real containment. Crossing this one converts that same compromise into\n          // \"any tenant, immediately\". `requiresStepUpAuthentication` answers a hijacked session; it\n          // does not answer phished credentials with the second factor supplied.\n          //\n          // And the operational pressure that makes opening it feel urgent is mostly relieved by the\n          // three doors that DID open: a legal-order or abuse takedown can now be executed\n          // cross-tenant through REQUEST_DELETION (mark + notify + window), with RESTORE available\n          // if the order is stayed or the abuse call was wrong. That covers the cited use cases with\n          // a recovery path. What remains uncovered is only \"destroy within hours, irreversibly,\n          // against a tenant the operator is not in\".\n          //\n          // If that residue must be covered, the answer is NOT this flag alone. Require, together:\n          // a mandatory `justification` on the request DTO (as `organizationMembers.grantOwnership`\n          // has), a distinct high-severity audit event separable from routine purges, and a\n          // two-person rule. Instant irreversible cross-tenant destruction is the one capability in\n          // this product that deserves a second SIGNATURE, not merely a second factor. Until those\n          // exist, the honest operator answer is the window — or a database console with a change\n          // ticket, which at least leaves a human trail outside the system it is destroying.\n          //\n          // assurance-control: WILDO.ACCESS.CROSS_TENANT_ADMINISTRATION — deliberate non-grant;\n          // the blast radius of this verb is not admitted to platform tier.\n          //\n          //\n          // Irreversible destruction of a whole tenant, and it cascades. A hijacked session must not\n          // be able to do this on the strength of a login that happened at some earlier point:\n          // `riskLevel` is UI-only, and the per-user-type `stepUpAuth` policy is opt-in, off by\n          // default, and satisfied by any authentication newer than `maxAgeSeconds`.\n          //\n          // assurance-control: WILDO.IDENTITY.STEP_UP_AUTHENTICATION — re-authentication before a high-impact action.\n          requiresStepUpAuthentication: true,\n        }\n      ],\n    },\n\n    [Organization_Lifecycle_Operations.ACTIVATE]: {\n      variants: [\n        {\n          variantType: ResourceOperationVariantType.API_CALL,\n          isDefault: true,\n          roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],\n          riskLevel: ResourceOperationRiskLevel.MEDIUM,\n          resourceOperationLike: CoreResourceOperation.UPDATE,\n          // Cross-tenant, because otherwise this door cannot be opened by anyone. `SUSPENDED` is in\n          // `ORGANIZATION_STATUSES_WITHOUT_AUTHORITY`, so a suspended tenant's own admins hold no\n          // authority — and ACTIVATE is reachable only FROM `SUSPENDED` or `TRIAL_EXPIRED`. Without\n          // the crossing, the only principal who could un-suspend a tenant is a super-administrator\n          // who happens to already be a member of it, which is an accident of staffing rather than a\n          // control. Purely recuperative: it moves a halted tenant back to operational and destroys\n          // nothing, so admitting the crossing costs no reversibility.\n          admitsCrossTenantPlatformAdministration: true,\n          requestDto: z.object({\n            reason: z.string().max(500).optional()\n          }),\n          // Conditional availability by org status. ACTIVATE re-enables a halted\n          // or inactive organization, so it is available only from SUSPENDED or\n          // TRIAL_EXPIRED — never from ACTIVE (a no-op) nor the terminal\n          // CANCELLED / DELETED states. Evaluated on BOTH the frontend (the\n          // action renders disabled otherwise, via `useOperationsEnabled`) AND\n          // the backend (`services-registry-handler` throws\n          // `SERVICE_RESOURCE_OPERATION_DISABLED` → 403 when false), so the guard\n          // holds even if the client is bypassed. Keep in sync with the resource\n          // spec's ACTIVATE error scenarios.\n          enabledCondition: ({ currentObject }) => {\n            return (\n              currentObject.status === OrganizationStatus.SUSPENDED ||\n              currentObject.status === OrganizationStatus.TRIAL_EXPIRED\n            );\n          },\n          // NO `haveBulkOperation`. The generated bulk variant was removed on 2026-08-01: it could\n          // never do bulk work. `assertBulkHookObjectContextAvailability` fails a bulk UPDATE\n          // closed whenever its `enabledCondition` needs object context and no single persisted\n          // `currentObject` is available — and the condition above reads `currentObject.status` by\n          // construction, because the whole point is that ACTIVATE is only legal from specific\n          // states. So a multi-org selector was refused (403) BY DESIGN and the variant only ever\n          // worked with a one-element `_ids` array: a more expensive spelling of this variant, at\n          // the cost of a second route and a second custom-implementation registration\n          // (`isBulkOperation` is part of the operation-path key). Bulk suspension would require\n          // abandoning the per-row state gate, which is not a trade this operation should make.\n        }\n      ],\n      userNotifications: [\n        {\n          target: CoreUserNotificationTarget.ORGANIZATION_ADMINISTRATIVE,\n          channel: CoreUserNotificationChannel.EMAIL,\n        }\n      ]\n    },\n\n    [Organization_Lifecycle_Operations.SUSPEND]: {\n      variants: [\n        {\n          variantType: ResourceOperationVariantType.API_CALL,\n          isDefault: true,\n          roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN], // Only super admins can suspend organizations\n          riskLevel: ResourceOperationRiskLevel.CRITICAL,\n          resourceOperationLike: CoreResourceOperation.UPDATE,\n          requestDto: z.object({\n            suspensionReason: z.string().min(1).max(500),\n            notifyMembers: z.boolean().default(true)\n          }),\n          // Conditional availability by org status. SUSPEND halts an operational\n          // organization, so it is available only from ACTIVE or TRIAL — never\n          // from SUSPENDED (a no-op) nor the terminal CANCELLED / DELETED states.\n          // Enforced on the frontend (the action renders disabled otherwise) AND\n          // the backend (`services-registry-handler` throws\n          // `SERVICE_RESOURCE_OPERATION_DISABLED` → 403), so re-suspending an\n          // already-suspended org fails closed server-side. Keep in sync with the\n          // resource spec's SUSPEND error scenarios.\n          enabledCondition: ({ currentObject }) => {\n            return (\n              currentObject.status === OrganizationStatus.ACTIVE ||\n              currentObject.status === OrganizationStatus.TRIAL\n            );\n          },\n          // NO `haveBulkOperation` — same reasoning as ACTIVATE above. Suspending many tenants in\n          // one request is exactly the operation whose per-row state gate must not be dropped.\n        }\n      ],\n      userNotifications: [\n        {\n          target: CoreUserNotificationTarget.ORGANIZATION_USERS,\n          channel: CoreUserNotificationChannel.EMAIL,\n          // Honours the `notifyMembers` flag the request contract has always advertised.\n          //\n          // Until this operation was implemented the flag was inert in the worst way: the DTO\n          // accepted it, the caller could set it to `false`, and the declarative notification fired\n          // regardless — a silent contract lie on an operation that emails an entire tenant. A\n          // suspension is sometimes deliberately quiet (a fraud hold the operator does not want to\n          // tip off), so this is a real capability rather than a formality.\n          //\n          // `!== false` rather than a truthy test: the field carries `.default(true)`, so an\n          // omitted value must still notify.\n          condition: ({ inputDto }) => (inputDto as { notifyMembers?: boolean } | undefined)?.notifyMembers !== false,\n        }\n      ]\n    },\n\n    /**\n     * Mark the tenant for deletion — the SOFT-DELETE phase, and the door that replaced the\n     * tenant-facing `DELETE`.\n     *\n     * ## What fires here, and what deliberately does not\n     *\n     * Authorization consequences fire NOW; data removal waits for the purge. The split is the\n     * load-bearing part of the design:\n     *\n     * - **now** — `status: DELETED` + `deletionRequestedAt` + `purgeScheduledAt`; every affected user's\n     *   GLOBAL `user.userTypes` reconciled; their tokens invalidated. A global grant that exists\n     *   only because of this tenant must not outlive it by the length of the retention window —\n     *   that grant outliving its justification is the original defect this whole workstream\n     *   exists to fix, and deferring it to the purge would ship that defect with a longer fuse.\n     * - **later (purge)** — membership rows, unit assignments and every other org child.\n     *\n     * The rule that decides which side a concern lands on: remove at mark time only what is\n     * RE-DERIVABLE on restore. Org-scoped roles are re-derivable from the membership rows, so the\n     * rows stay and the authority is recomputed per request from `status` (see\n     * `isAuthorityConferringOrganizationStatus`). Global `userTypes` are NOT re-derivable that\n     * way — they are a denormalized grant on the user row — so they are reconciled here, and\n     * `restore` re-grants them.\n     *\n     * ## Audience limitation inherited from the DELETE door this replaces — now CLOSED\n     *\n     * This used to read: re-authentication proves identity by PASSWORD only, the framework DESTROYS\n     * `passwordHash` + passkeys for directory-managed (SCIM) users as a compliance control\n     * (`_reconcileLocalCredentialsForDirectoryManaged`), so an ORG_ADMIN of a directory-managed\n     * organization could not satisfy the step-up gate and was refused — and it named the fix as\n     * future work, routing such a tenant through the `admin` variant below.\n     *\n     * That fix SHIPPED. `AuthMethodManagementBackendService.reAuthenticate` accepts PASSWORD, TOTP\n     * and PASSKEY. `AuthMethod.TOTP` means \"an enrolled second factor\" — a TOTP code or a backup\n     * code — verified through `AuthMfaBackendService.verifyEnrolledSecondFactor`, the same single\n     * authority the login second-factor step uses, anti-replay included. It was chosen precisely\n     * because the SCIM reconciliation PRESERVES it: a second factor sitting on top of the IdP first\n     * factor survives deprovisioning by design.\n     *\n     * So a directory-managed ORG_ADMIN can satisfy this gate itself, and does NOT need the `admin`\n     * variant to start a teardown. That variant remains for platform-operator use, not as the\n     * workaround for a limitation that no longer exists.\n     *\n     * assurance-control: WILDO.IDENTITY.STEP_UP_AUTHENTICATION — re-authentication before a high-impact\n     * action; the tenant loses its access rights at the moment of the decision, not at the moment\n     * its data is destroyed.\n     */\n    [Organization_Lifecycle_Operations.REQUEST_DELETION]: {\n      variants: [\n        {\n          variantType: ResourceOperationVariantType.API_CALL,\n          isDefault: true,\n          roles: [CORE_ORG_ROLES.ORG_ADMIN], // Org admins can schedule their own organization's deletion\n          riskLevel: ResourceOperationRiskLevel.CRITICAL,\n          resourceOperationLike: CoreResourceOperation.UPDATE,\n          requestDto: z.object({\n            reason: z.string().max(500).optional()\n          }),\n          requiresStepUpAuthentication: true,\n          // Available only from a state the tenant can still be marked FROM. Never from DELETED\n          // (already marked — restore or wait for the purge) nor from the terminal CANCELLED.\n          // Enforced on the frontend (the action renders disabled) AND the backend\n          // (`services-registry-handler` throws `SERVICE_RESOURCE_OPERATION_DISABLED` → 403), so a\n          // double-mark fails closed server-side and cannot silently re-arm the window. Keep in\n          // sync with the resource spec's REQUEST_DELETION error scenarios.\n          //\n          // The condition is shared with the `admin` variant below, and the ROLE gate is what\n          // makes them differ in practice: `SUSPENDED` confers no authority\n          // (`ORGANIZATION_STATUSES_WITHOUT_AUTHORITY`), so on THIS variant that arm is\n          // unreachable — an org admin cannot mark a tenant the platform has halted. It is\n          // reachable on the `admin` variant, which is the intended shape: a suspended tenant is\n          // under platform control, and the platform can still schedule its deletion.\n          enabledCondition: ({ currentObject }) => {\n            return (\n              currentObject.status === OrganizationStatus.ACTIVE ||\n              currentObject.status === OrganizationStatus.TRIAL ||\n              currentObject.status === OrganizationStatus.TRIAL_EXPIRED ||\n              currentObject.status === OrganizationStatus.SUSPENDED\n            );\n          },\n          // NO `haveBulkOperation` — same reasoning as SUSPEND/ACTIVATE: the per-row state gate\n          // above reads `currentObject.status`, and a bulk UPDATE whose `enabledCondition` needs\n          // object context is failed closed by `assertBulkHookObjectContextAvailability`.\n        },\n        {\n          variantType: ResourceOperationVariantType.API_CALL,\n          isDefault: false,\n          variantKey: \"admin\",\n          roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],\n          // Cross-tenant: this is the operator's takedown path, and it is the REVERSIBLE one. It\n          // MARKS the tenant, notifies its users, and starts the retention window — every effect can\n          // be undone by RESTORE (also crossed, immediately above; crossing one without the other\n          // would hand operators a one-way door and call it a window).\n          //\n          // The JSDoc on the sibling org-admin variant already asserts this shape — \"a suspended\n          // tenant is under platform control, and the platform can still schedule its deletion\" —\n          // which was true of the role gate and false of the runtime until this flag.\n          //\n          // Deliberately the FIRST destructive door opened, and deliberately not the last one: a\n          // legal-order or abuse takedown routed through MARK + window keeps a recovery path open,\n          // which is what makes leaving instant purge closed (see DELETE `admin`) affordable rather\n          // than merely cautious.\n          admitsCrossTenantPlatformAdministration: true,\n          riskLevel: ResourceOperationRiskLevel.HIGH,\n          resourceOperationLike: CoreResourceOperation.UPDATE,\n          requestDto: z.object({\n            reason: z.string().max(500).optional()\n          }),\n          // The flag is per-VARIANT — nothing is inherited from the variant above. Marking someone\n          // else's tenant for destruction is not a lesser act than marking your own.\n          requiresStepUpAuthentication: true,\n          enabledCondition: ({ currentObject }) => {\n            return (\n              currentObject.status === OrganizationStatus.ACTIVE ||\n              currentObject.status === OrganizationStatus.TRIAL ||\n              currentObject.status === OrganizationStatus.TRIAL_EXPIRED ||\n              currentObject.status === OrganizationStatus.SUSPENDED\n            );\n          },\n        }\n      ],\n      userNotifications: [\n        {\n          // The members ARE the audience here, and this is the only moment the warning is\n          // actionable — the tenant can still be restored. This notification moved from DELETE,\n          // where by the time it fired its recipients were being deleted in the same transaction.\n          target: CoreUserNotificationTarget.ORGANIZATION_USERS,\n          channel: CoreUserNotificationChannel.EMAIL,\n        }\n      ]\n    },\n\n    /**\n     * Cancel a pending deletion — the inverse of\n     * {@link Organization_Lifecycle_Operations.REQUEST_DELETION}, available for the whole\n     * retention window.\n     *\n     * Restoring needs no data re-creation, and that is a property of the phase split rather than a\n     * happy accident: the mark deliberately removed only what is re-derivable. Membership rows,\n     * unit assignments and every other child were never touched, so clearing `status` re-arms\n     * org-scoped authority on the next request for free. The one thing that WAS removed — each\n     * affected user's global `userTypes` — is re-granted here from the same configuration that\n     * granted it originally.\n     *\n     * ## Why the window is not re-checked here\n     *\n     * There is no \"too late to restore\" branch. If the purge has run, the row is gone and the\n     * operation 404s at addressing; if the row is present, it is restorable. Encoding a second\n     * time-based rule would create a state where a row exists but claims to be unrecoverable —\n     * an unrecoverable row that still holds every one of its members' data is the worst of both\n     * phases.\n     *\n     * Deliberately NOT step-up gated: restoring is the SAFE direction. Every other lifecycle verb\n     * here reduces access or destroys data; this one returns a tenant to the state it was already\n     * in. Gating recovery behind the same friction as destruction discourages the correct\n     * response to a mistaken deletion.\n     *\n     * ## ⚠️ Why this is SUPER-ADMIN ONLY — a tenant cannot un-mark itself\n     *\n     * Not a policy preference: an ORG-scoped variant here would be UNSATISFIABLE. A `DELETED`\n     * organization confers no authority at all\n     * (`ORGANIZATION_STATUSES_WITHOUT_AUTHORITY`), so its ORG_ADMIN no longer holds `ORG_ADMIN`\n     * anywhere and would be refused by the role gate before `enabledCondition` was ever consulted.\n     * Declaring the variant anyway would ship a door that renders in the UI, is documented in the\n     * spec, and answers 403 forever.\n     *\n     * That is also the correct product shape, and it is what every comparable system does —\n     * Microsoft 365, Google Workspace, Salesforce and AWS all recover a deleted tenant through the\n     * PROVIDER's administrator or support, never through the deleted tenant's own credentials.\n     * The tenant-facing safety net is the retention window itself; the recovery action is an\n     * operator's.\n     *\n     * assurance-control: WILDO.DATA.SECURE_LIFECYCLE — a reversible deletion decision, with the\n     * reversal itself audited and performed by a separately-privileged party.\n     */\n    [Organization_Lifecycle_Operations.RESTORE]: {\n      variants: [\n        {\n          variantType: ResourceOperationVariantType.API_CALL,\n          isDefault: true,\n          roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN], // See the JSDoc: an org-scoped variant would be unsatisfiable\n          riskLevel: ResourceOperationRiskLevel.HIGH,\n          // Cross-tenant, and this variant is WHY the gap was worth finding. The JSDoc above rejects\n          // an org-scoped variant precisely because it \"would ship a door that renders in the UI, is\n          // documented in the spec, and answers 403 forever\" — and then shipped exactly that one\n          // tier up: a MARKED tenant is `DELETED`, which confers no authority, so its own admins\n          // cannot restore it; and a platform administrator could not reach the row. Nobody could\n          // restore a marked tenant, and the purge batch collected it when the window expired.\n          //\n          // That makes the retention window the load-bearing casualty: a window whose release nobody\n          // can pull is not a safety net, it is a delay. Restoring it here is what lets the rest of\n          // the teardown lifecycle keep claiming reversibility.\n          admitsCrossTenantPlatformAdministration: true,\n          resourceOperationLike: CoreResourceOperation.UPDATE,\n          requestDto: z.object({\n            reason: z.string().max(500).optional()\n          }),\n          // Only a MARKED tenant can be restored. From any live state this is a no-op, and from\n          // the terminal CANCELLED it is not a deletion being undone.\n          enabledCondition: ({ currentObject }) => {\n            return currentObject.status === OrganizationStatus.DELETED;\n          },\n        }\n      ],\n      userNotifications: [\n        {\n          target: CoreUserNotificationTarget.ORGANIZATION_USERS,\n          channel: CoreUserNotificationChannel.EMAIL,\n        }\n      ]\n    }\n  },\n\n});\n\n"]}
+{"version":3,"file":"organizations.shared.resources-config.schemas.js","sourceRoot":"","sources":["../../../../src/organizations/organizations.shared.resources-config.schemas.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AAEH,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AACxB,OAAO,EACL,kBAAkB,EAClB,kBAAkB,GACnB,MAAM,gCAAgC,CAAC;AACxC,OAAO,EAAE,qBAAqB,EAAE,MAAM,gDAAgD,CAAC;AACvF,OAAO,EAAE,0BAA0B,EAA8C,MAAM,uCAAuC,CAAC;AAC/H,OAAO,EAAE,gBAAgB,EAAE,kCAAkC,EAAE,MAAM,gDAAgD,CAAC;AACtH,OAAO,EAAE,4BAA4B,EAAE,MAAM,uCAAuC,CAAC;AACrF,OAAO,EAAE,0BAA0B,EAAE,2BAA2B,EAAE,MAAM,+CAA+C,CAAC;AAExH,OAAO,EAAE,0CAA0C,EAAE,MAAM,8CAA8C,CAAC;AAC1G,OAAO,EAAE,wBAAwB,EAAE,MAAM,8CAA8C,CAAC;AAExF,OAAO,EAAE,cAAc,EAAE,cAAc,EAAE,MAAM,iDAAiD,CAAC;AAGjG;;;;;;;;;;;;;;;;;;;;;;;;;;GA0BG;AACH,MAAM,CAAN,IAAY,iCAoDX;AApDD,WAAY,iCAAiC;IAC3C,0DAAqB,CAAA;IACrB,wDAAmB,CAAA;IACnB;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OA8BG;IACH,iGAA4D,CAAA;IAC5D;;;;;;;OAOG;IACH,0EAAqC,CAAA;IACrC;;;;;;OAMG;IACH,wDAAmB,CAAA;AACrB,CAAC,EApDW,iCAAiC,KAAjC,iCAAiC,QAoD5C;AAED,MAAM,8BAA8B,GAAG,CAAC,QAAQ,CAAC,CAAC;AAElD,MAAM,gCAAgC,GAAG;IACvC,MAAM,EAAE,CAAC,CAAC,IAAI,CAAC,kBAAkB,CAAC;CACnC,CAAC;AAUF;;EAEE;AACF,MAAM,CAAC,MAAM,uDAAuD,GAAG,CAAC,sBAA8C,EAAE,EAAE,CAAC,0CAA0C,CAInK;IACA,UAAU,EAAE,kBAAkB;IAC9B,kBAAkB,EAAE,gBAAgB,CAAC,aAAa;IAClD,uBAAuB,EAAE,kCAAkC,CAAC,gBAAgB,CAAC,aAAa,CAAC;IAC3F,qBAAqB,EAAE,sBAAsB;IAC7C,gBAAgB,EAAE,IAAI,EAAE,2CAA2C;IACnE,4EAA4E;IAC5E,8EAA8E;IAC9E,+EAA+E;IAC/E,uDAAuD;IACvD,kBAAkB,EAAE,EAAE,IAAI,EAAE,wBAAwB,CAAC,OAAO,EAAE;IAE9D,cAAc,EAAE;QACd,qBAAqB,CAAC,IAAI;QAC1B,qBAAqB,CAAC,IAAI;QAC1B,qBAAqB,CAAC,MAAM;QAC5B,qBAAqB,CAAC,MAAM;QAC5B,qBAAqB,CAAC,MAAM;QAC5B,qBAAqB,CAAC,MAAM;KAC7B;IAED,eAAe,EAAE,iCAAiC;IAElD;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OAuCG;IACH,uBAAuB,EAAE;QACvB,CAAC,qBAAqB,CAAC,MAAM,CAAC,EAAE;YAC9B,QAAQ,EAAE;gBACR;oBACE,wEAAwE;oBACxE,yEAAyE;oBACzE,yEAAyE;oBACzE,yEAAyE;oBACzE,sEAAsE;oBACtE,0DAA0D;oBAC1D,WAAW,EAAE,4BAA4B,CAAC,aAAa;oBACvD,SAAS,EAAE,IAAI;oBACf,KAAK,EAAE,EAAE;oBACT,SAAS,EAAE,0BAA0B,CAAC,MAAM;iBAC7C;gBACD;oBACE,WAAW,EAAE,4BAA4B,CAAC,QAAQ;oBAClD,SAAS,EAAE,IAAI;oBACf;;;;;;;;uBAQG;oBACH,KAAK,EAAE,CAAC,cAAc,CAAC,QAAQ,CAAC;oBAChC,SAAS,EAAE,0BAA0B,CAAC,MAAM;oBAC5C,qFAAqF;oBACrF,qFAAqF;oBACrF,uFAAuF;oBACvF,gEAAgE;iBACjE;gBACD;oBACE,WAAW,EAAE,4BAA4B,CAAC,QAAQ;oBAClD,SAAS,EAAE,KAAK;oBAChB,UAAU,EAAE,OAAO;oBACnB,KAAK,EAAE,CAAC,cAAc,CAAC,qBAAqB,CAAC,EAAE,oFAAoF;oBACnI,SAAS,EAAE,0BAA0B,CAAC,GAAG;oBACzC,qFAAqF;iBACtF;aACF;YACD,iBAAiB,EAAE;gBACjB;oBACE,MAAM,EAAE,0BAA0B,CAAC,SAAS;oBAC5C,OAAO,EAAE,2BAA2B,CAAC,KAAK;iBAC3C;gBACD;oBACE,MAAM,EAAE,0BAA0B,CAAC,SAAS;oBAC5C,OAAO,EAAE,2BAA2B,CAAC,iBAAiB;iBACvD;aACF;SACF;QAED,CAAC,qBAAqB,CAAC,IAAI,CAAC,EAAE;YAC5B,QAAQ,EAAE;gBACR;oBACE,WAAW,EAAE,4BAA4B,CAAC,QAAQ;oBAClD,SAAS,EAAE,IAAI;oBACf,KAAK,EAAE,CAAC,cAAc,CAAC,UAAU,CAAC,EAAE,0CAA0C;oBAC9E,SAAS,EAAE,0BAA0B,CAAC,GAAG;iBAC1C;gBACD;oBACE,WAAW,EAAE,4BAA4B,CAAC,QAAQ;oBAClD,SAAS,EAAE,KAAK;oBAChB,UAAU,EAAE,OAAO;oBACnB,KAAK,EAAE,CAAC,cAAc,CAAC,qBAAqB,CAAC,EAAE,2FAA2F;oBAC1I,SAAS,EAAE,0BAA0B,CAAC,GAAG;iBAC1C;aACF;SACF;QAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;WAiDG;QACH,CAAC,qBAAqB,CAAC,IAAI,CAAC,EAAE;YAC5B,QAAQ,EAAE;gBACR;oBACE,WAAW,EAAE,4BAA4B,CAAC,QAAQ;oBAClD,SAAS,EAAE,IAAI;oBACf,KAAK,EAAE,CAAC,cAAc,CAAC,qBAAqB,CAAC,EAAE,6GAA6G;oBAC5J,SAAS,EAAE,0BAA0B,CAAC,GAAG;oBACzC,YAAY,EAAE,gCAAgC;oBAC9C,UAAU,EAAE,8BAA8B;iBAC3C;aACF;SACF;QAED,CAAC,qBAAqB,CAAC,MAAM,CAAC,EAAE;YAC9B,QAAQ,EAAE,CAAC;oBACT,WAAW,EAAE,4BAA4B,CAAC,QAAQ;oBAClD,SAAS,EAAE,IAAI;oBACf,KAAK,EAAE,CAAC,cAAc,CAAC,qBAAqB,CAAC,EAAE,yCAAyC;oBACxF,SAAS,EAAE,0BAA0B,CAAC,GAAG;oBACzC,YAAY,EAAE,IAAI;oBAClB,gBAAgB,EAAE,CAAC,MAAM,EAAE,MAAM,EAAE,OAAO,CAAC;oBAC3C,iBAAiB,EAAE,EAAE,aAAa,EAAE,KAAK,EAAE,aAAa,EAAE,KAAK,EAAE;oBACjE,YAAY,EAAE,gCAAgC;oBAC9C,UAAU,EAAE,8BAA8B;oBAC1C,8BAA8B,EAAE,GAAG;iBACpC,CAAC;SACH;QAED,CAAC,qBAAqB,CAAC,MAAM,CAAC,EAAE;YAC9B,QAAQ,EAAE;gBACR;oBACE,WAAW,EAAE,4BAA4B,CAAC,QAAQ;oBAClD,SAAS,EAAE,IAAI;oBACf,KAAK,EAAE,CAAC,cAAc,CAAC,SAAS,CAAC,EAAE,2CAA2C;oBAC9E,SAAS,EAAE,0BAA0B,CAAC,MAAM;oBAC5C,qEAAqE;oBACrE,6EAA6E;oBAC7E,4EAA4E;oBAC5E,gFAAgF;oBAChF,6DAA6D;iBAC9D;gBACD;oBACE,WAAW,EAAE,4BAA4B,CAAC,QAAQ;oBAClD,SAAS,EAAE,KAAK;oBAChB,UAAU,EAAE,OAAO;oBACnB,KAAK,EAAE,CAAC,cAAc,CAAC,qBAAqB,CAAC,EAAE,qCAAqC;oBACpF,SAAS,EAAE,0BAA0B,CAAC,GAAG;oBACzC,qEAAqE;oBACrE,qEAAqE;oBACrE,kCAAkC;iBACnC;aACF;YACD,iBAAiB,EAAE;gBACjB;oBACE,MAAM,EAAE,0BAA0B,CAAC,2BAA2B;oBAC9D,OAAO,EAAE,2BAA2B,CAAC,KAAK;iBAC3C;aACF;SACF;QAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;WAwCG;QACH,CAAC,qBAAqB,CAAC,MAAM,CAAC,EAAE;YAC9B,QAAQ,EAAE;gBACR;oBACE,WAAW,EAAE,4BAA4B,CAAC,aAAa;oBACvD,SAAS,EAAE,IAAI;oBACf,KAAK,EAAE,EAAE;oBACT,SAAS,EAAE,0BAA0B,CAAC,QAAQ;iBAC/C;gBACD;oBACE,WAAW,EAAE,4BAA4B,CAAC,QAAQ;oBAClD,SAAS,EAAE,KAAK;oBAChB,UAAU,EAAE,OAAO;oBACnB,KAAK,EAAE,CAAC,cAAc,CAAC,qBAAqB,CAAC;oBAC7C,SAAS,EAAE,0BAA0B,CAAC,IAAI;oBAC1C,EAAE;oBACF,0FAA0F;oBAC1F,wDAAwD;oBACxD,wFAAwF;oBACxF,EAAE;oBACF,2FAA2F;oBAC3F,qFAAqF;oBACrF,2FAA2F;oBAC3F,8CAA8C;oBAC9C,EAAE;oBACF,mFAAmF;oBACnF,qFAAqF;oBACrF,0FAA0F;oBAC1F,2FAA2F;oBAC3F,oFAAoF;oBACpF,EAAE;oBACF,wFAAwF;oBACxF,yFAAyF;oBACzF,0FAA0F;oBAC1F,2FAA2F;oBAC3F,uEAAuE;oBACvE,EAAE;oBACF,2FAA2F;oBAC3F,iFAAiF;oBACjF,yFAAyF;oBACzF,2FAA2F;oBAC3F,uFAAuF;oBACvF,4CAA4C;oBAC5C,EAAE;oBACF,yFAAyF;oBACzF,0FAA0F;oBAC1F,kFAAkF;oBAClF,0FAA0F;oBAC1F,yFAAyF;oBACzF,wFAAwF;oBACxF,mFAAmF;oBACnF,EAAE;oBACF,sFAAsF;oBACtF,kEAAkE;oBAClE,EAAE;oBACF,EAAE;oBACF,2FAA2F;oBAC3F,qFAAqF;oBACrF,sFAAsF;oBACtF,2EAA2E;oBAC3E,EAAE;oBACF,4GAA4G;oBAC5G,4BAA4B,EAAE,IAAI;iBACnC;aACF;SACF;QAED,CAAC,iCAAiC,CAAC,QAAQ,CAAC,EAAE;YAC5C,QAAQ,EAAE;gBACR;oBACE,WAAW,EAAE,4BAA4B,CAAC,QAAQ;oBAClD,SAAS,EAAE,IAAI;oBACf,KAAK,EAAE,CAAC,cAAc,CAAC,qBAAqB,CAAC;oBAC7C,SAAS,EAAE,0BAA0B,CAAC,MAAM;oBAC5C,qBAAqB,EAAE,qBAAqB,CAAC,MAAM;oBACnD,0FAA0F;oBAC1F,wFAAwF;oBACxF,0FAA0F;oBAC1F,0FAA0F;oBAC1F,2FAA2F;oBAC3F,0FAA0F;oBAC1F,6DAA6D;oBAC7D,uCAAuC,EAAE,IAAI;oBAC7C,UAAU,EAAE,CAAC,CAAC,MAAM,CAAC;wBACnB,MAAM,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,GAAG,CAAC,CAAC,QAAQ,EAAE;qBACvC,CAAC;oBACF,uEAAuE;oBACvE,sEAAsE;oBACtE,+DAA+D;oBAC/D,kEAAkE;oBAClE,qEAAqE;oBACrE,kDAAkD;oBAClD,wEAAwE;oBACxE,uEAAuE;oBACvE,mCAAmC;oBACnC,gBAAgB,EAAE,CAAC,EAAE,aAAa,EAAE,EAAE,EAAE;wBACtC,OAAO,CACL,aAAa,CAAC,MAAM,KAAK,kBAAkB,CAAC,SAAS;4BACrD,aAAa,CAAC,MAAM,KAAK,kBAAkB,CAAC,aAAa,CAC1D,CAAC;oBACJ,CAAC;oBACD,yFAAyF;oBACzF,oFAAoF;oBACpF,sFAAsF;oBACtF,yFAAyF;oBACzF,qFAAqF;oBACrF,wFAAwF;oBACxF,wFAAwF;oBACxF,6EAA6E;oBAC7E,uFAAuF;oBACvF,sFAAsF;iBACvF;aACF;YACD,iBAAiB,EAAE;gBACjB;oBACE,MAAM,EAAE,0BAA0B,CAAC,2BAA2B;oBAC9D,OAAO,EAAE,2BAA2B,CAAC,KAAK;iBAC3C;aACF;SACF;QAED,CAAC,iCAAiC,CAAC,OAAO,CAAC,EAAE;YAC3C,QAAQ,EAAE;gBACR;oBACE,WAAW,EAAE,4BAA4B,CAAC,QAAQ;oBAClD,SAAS,EAAE,IAAI;oBACf,KAAK,EAAE,CAAC,cAAc,CAAC,qBAAqB,CAAC,EAAE,8CAA8C;oBAC7F,SAAS,EAAE,0BAA0B,CAAC,QAAQ;oBAC9C,qBAAqB,EAAE,qBAAqB,CAAC,MAAM;oBACnD,UAAU,EAAE,CAAC,CAAC,MAAM,CAAC;wBACnB,gBAAgB,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,GAAG,CAAC,GAAG,CAAC;wBAC5C,aAAa,EAAE,CAAC,CAAC,OAAO,EAAE,CAAC,OAAO,CAAC,IAAI,CAAC;qBACzC,CAAC;oBACF,uEAAuE;oBACvE,qEAAqE;oBACrE,wEAAwE;oBACxE,uEAAuE;oBACvE,kDAAkD;oBAClD,oEAAoE;oBACpE,wEAAwE;oBACxE,2CAA2C;oBAC3C,gBAAgB,EAAE,CAAC,EAAE,aAAa,EAAE,EAAE,EAAE;wBACtC,OAAO,CACL,aAAa,CAAC,MAAM,KAAK,kBAAkB,CAAC,MAAM;4BAClD,aAAa,CAAC,MAAM,KAAK,kBAAkB,CAAC,KAAK,CAClD,CAAC;oBACJ,CAAC;oBACD,wFAAwF;oBACxF,qFAAqF;iBACtF;aACF;YACD,iBAAiB,EAAE;gBACjB;oBACE,MAAM,EAAE,0BAA0B,CAAC,kBAAkB;oBACrD,OAAO,EAAE,2BAA2B,CAAC,KAAK;oBAC1C,+EAA+E;oBAC/E,EAAE;oBACF,oFAAoF;oBACpF,0FAA0F;oBAC1F,qFAAqF;oBACrF,yFAAyF;oBACzF,kEAAkE;oBAClE,EAAE;oBACF,mFAAmF;oBACnF,mCAAmC;oBACnC,SAAS,EAAE,CAAC,EAAE,QAAQ,EAAE,EAAE,EAAE,CAAE,QAAoD,EAAE,aAAa,KAAK,KAAK;iBAC5G;aACF;SACF;QAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;WA6CG;QACH,CAAC,iCAAiC,CAAC,gBAAgB,CAAC,EAAE;YACpD,QAAQ,EAAE;gBACR;oBACE,WAAW,EAAE,4BAA4B,CAAC,QAAQ;oBAClD,SAAS,EAAE,IAAI;oBACf,KAAK,EAAE,CAAC,cAAc,CAAC,SAAS,CAAC,EAAE,4DAA4D;oBAC/F,SAAS,EAAE,0BAA0B,CAAC,QAAQ;oBAC9C,qBAAqB,EAAE,qBAAqB,CAAC,MAAM;oBACnD,UAAU,EAAE,CAAC,CAAC,MAAM,CAAC;wBACnB,MAAM,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,GAAG,CAAC,CAAC,QAAQ,EAAE;qBACvC,CAAC;oBACF,4BAA4B,EAAE,IAAI;oBAClC,sFAAsF;oBACtF,oFAAoF;oBACpF,yEAAyE;oBACzE,yFAAyF;oBACzF,sFAAsF;oBACtF,kEAAkE;oBAClE,EAAE;oBACF,oFAAoF;oBACpF,kEAAkE;oBAClE,8EAA8E;oBAC9E,iFAAiF;oBACjF,uFAAuF;oBACvF,4EAA4E;oBAC5E,gBAAgB,EAAE,CAAC,EAAE,aAAa,EAAE,EAAE,EAAE;wBACtC,OAAO,CACL,aAAa,CAAC,MAAM,KAAK,kBAAkB,CAAC,MAAM;4BAClD,aAAa,CAAC,MAAM,KAAK,kBAAkB,CAAC,KAAK;4BACjD,aAAa,CAAC,MAAM,KAAK,kBAAkB,CAAC,aAAa;4BACzD,aAAa,CAAC,MAAM,KAAK,kBAAkB,CAAC,SAAS,CACtD,CAAC;oBACJ,CAAC;oBACD,sFAAsF;oBACtF,uFAAuF;oBACvF,gFAAgF;iBACjF;gBACD;oBACE,WAAW,EAAE,4BAA4B,CAAC,QAAQ;oBAClD,SAAS,EAAE,KAAK;oBAChB,UAAU,EAAE,OAAO;oBACnB,KAAK,EAAE,CAAC,cAAc,CAAC,qBAAqB,CAAC;oBAC7C,uFAAuF;oBACvF,2FAA2F;oBAC3F,wFAAwF;oBACxF,6DAA6D;oBAC7D,EAAE;oBACF,uFAAuF;oBACvF,wFAAwF;oBACxF,4EAA4E;oBAC5E,EAAE;oBACF,uFAAuF;oBACvF,yFAAyF;oBACzF,0FAA0F;oBAC1F,wBAAwB;oBACxB,uCAAuC,EAAE,IAAI;oBAC7C,SAAS,EAAE,0BAA0B,CAAC,IAAI;oBAC1C,qBAAqB,EAAE,qBAAqB,CAAC,MAAM;oBACnD,UAAU,EAAE,CAAC,CAAC,MAAM,CAAC;wBACnB,MAAM,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,GAAG,CAAC,CAAC,QAAQ,EAAE;qBACvC,CAAC;oBACF,yFAAyF;oBACzF,2EAA2E;oBAC3E,4BAA4B,EAAE,IAAI;oBAClC,gBAAgB,EAAE,CAAC,EAAE,aAAa,EAAE,EAAE,EAAE;wBACtC,OAAO,CACL,aAAa,CAAC,MAAM,KAAK,kBAAkB,CAAC,MAAM;4BAClD,aAAa,CAAC,MAAM,KAAK,kBAAkB,CAAC,KAAK;4BACjD,aAAa,CAAC,MAAM,KAAK,kBAAkB,CAAC,aAAa;4BACzD,aAAa,CAAC,MAAM,KAAK,kBAAkB,CAAC,SAAS,CACtD,CAAC;oBACJ,CAAC;iBACF;aACF;YACD,iBAAiB,EAAE;gBACjB;oBACE,gFAAgF;oBAChF,sFAAsF;oBACtF,wFAAwF;oBACxF,MAAM,EAAE,0BAA0B,CAAC,kBAAkB;oBACrD,OAAO,EAAE,2BAA2B,CAAC,KAAK;iBAC3C;aACF;SACF;QAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;WA0CG;QACH,CAAC,iCAAiC,CAAC,OAAO,CAAC,EAAE;YAC3C,QAAQ,EAAE;gBACR;oBACE,WAAW,EAAE,4BAA4B,CAAC,QAAQ;oBAClD,SAAS,EAAE,IAAI;oBACf,KAAK,EAAE,CAAC,cAAc,CAAC,qBAAqB,CAAC,EAAE,8DAA8D;oBAC7G,SAAS,EAAE,0BAA0B,CAAC,IAAI;oBAC1C,2FAA2F;oBAC3F,2FAA2F;oBAC3F,uFAAuF;oBACvF,uFAAuF;oBACvF,wFAAwF;oBACxF,qFAAqF;oBACrF,EAAE;oBACF,2FAA2F;oBAC3F,0FAA0F;oBAC1F,sDAAsD;oBACtD,uCAAuC,EAAE,IAAI;oBAC7C,qBAAqB,EAAE,qBAAqB,CAAC,MAAM;oBACnD,UAAU,EAAE,CAAC,CAAC,MAAM,CAAC;wBACnB,MAAM,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,GAAG,CAAC,CAAC,QAAQ,EAAE;qBACvC,CAAC;oBACF,sFAAsF;oBACtF,4DAA4D;oBAC5D,gBAAgB,EAAE,CAAC,EAAE,aAAa,EAAE,EAAE,EAAE;wBACtC,OAAO,aAAa,CAAC,MAAM,KAAK,kBAAkB,CAAC,OAAO,CAAC;oBAC7D,CAAC;iBACF;aACF;YACD,iBAAiB,EAAE;gBACjB;oBACE,MAAM,EAAE,0BAA0B,CAAC,kBAAkB;oBACrD,OAAO,EAAE,2BAA2B,CAAC,KAAK;iBAC3C;aACF;SACF;QAGD;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;WA6CG;QACH,CAAC,iCAAiC,CAAC,6BAA6B,CAAC,EAAE;YACjE,QAAQ,EAAE;gBACR;oBACE,WAAW,EAAE,4BAA4B,CAAC,QAAQ;oBAClD,SAAS,EAAE,IAAI;oBACf,0FAA0F;oBAC1F,uFAAuF;oBACvF,uFAAuF;oBACvF,2FAA2F;oBAC3F,QAAQ;oBACR,KAAK,EAAE,CAAC,cAAc,CAAC,qBAAqB,CAAC;oBAC7C,SAAS,EAAE,0BAA0B,CAAC,QAAQ;oBAC9C,qBAAqB,EAAE,qBAAqB,CAAC,MAAM;oBACnD,UAAU,EAAE,CAAC,CAAC,MAAM,CAAC;wBACnB,aAAa,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,GAAG,CAAC,IAAI,CAAC;qBAC3C,CAAC;oBACF,2FAA2F;oBAC3F,4FAA4F;oBAC5F,EAAE;oBACF,wFAAwF;oBACxF,sBAAsB;oBACtB,4BAA4B,EAAE,IAAI;oBAClC,wEAAwE;oBACxE,wFAAwF;oBACxF,uFAAuF;oBACvF,gEAAgE;oBAChE,sFAAsF;oBACtF,iDAAiD;oBACjD,gBAAgB,EAAE,CAAC,EAAE,aAAa,EAAE,EAAE,EAAE,CAAC,aAAa,CAAC,MAAM,KAAK,kBAAkB,CAAC,MAAM;oBAC3F,4FAA4F;oBAC5F,iFAAiF;iBAClF;aACF;YACD;;;;;;;;;;;;;;;;;;eAkBG;SACJ;KACF;CAEF,CAAC,CAAC","sourcesContent":["/**\n * Organization Shared DTO Schemas\n *\n * Operation schemas for organization management.\n * Separated into App Admin concerns and Organization self-management.\n */\n\nimport { z } from 'zod';\nimport {\n  OrganizationSchema,\n  OrganizationStatus,\n} from './organizations.shared.schemas';\nimport { CoreResourceOperation } from '../resources/resources.shared.core.definitions';\nimport { ResourceOperationRiskLevel, ResourcePrimaryScope, ResourceRelationship } from '../resources/resources.shared.schemas';\nimport { CoreResourceType, coreResourceShared_FieldIdentifier } from '../resources/resources.shared.core.definitions';\nimport { ResourceOperationVariantType } from '../resources/resources.shared.schemas';\nimport { CoreUserNotificationTarget, CoreUserNotificationChannel } from '../notifications/notifications.shared.schemas';\n\nimport { createResourceConfiguration_Initialization } from '../resources/resources-config.shared.factory';\nimport { ResourceSystemAccessMode } from '../resources/resources-config.shared.schemas';\n\nimport { CORE_APP_ROLES, CORE_ORG_ROLES } from '../security/authorizations/roles.shared.schemas';\n\n\n/**\n * Tenant LIFECYCLE transitions — the guarded transitions of a tenant's state and identity.\n *\n * Renamed from `Organization_AppAdmin_Operations` on 2026-08-01. The old name described the\n * AUDIENCE of the two members it happened to hold (`ACTIVATE`/`SUSPEND` are super-admin-only) and\n * stopped being true the moment an ORG_ADMIN-facing member joined it. The members share a\n * *concern*, not an audience: each is a guarded transition of the tenant state machine, declared\n * `resourceOperationLike: UPDATE`, gated by an `enabledCondition` on the tenant's current state, and\n * the sole authority for a field that generic UPDATE may not write. The frontend already\n * called this concept by its right name — `organizationLifecycleOpViews` in the presets.\n *\n * Every member's field is `.excludeFromUpdate()`, so each declares `authoritativeFields` naming the\n * fields its prefix owns; without that the repository's strict re-parse silently strips the write and\n * the operation answers success having changed nothing.\n *\n * ## Which field each member owns\n *\n * Four members own `status`. {@link PROMOTE_TO_OWNER_ORGANIZATION} owns `type`, and it is why this\n * doc no longer says \"the operations that own `Organization.status`\" (it did until #1054, when the\n * first non-`status` member arrived). The generalisation is not a convenience: the paragraph above\n * already described the shared concern without naming `status` once, and every clause of it holds of\n * a type transition — guarded, `UPDATE`-like, conditioned on the tenant's current state, and the sole\n * authority for an `.excludeFromUpdate()` field.\n *\n * A second enum was the alternative and is not available: `customOperation` on a resource\n * configuration takes ONE `EnumLikeType`, so two enums would mean two resources.\n */\nexport enum Organization_Lifecycle_Operations {\n  ACTIVATE = 'activate',\n  SUSPEND = 'suspend',\n  /**\n   * Re-type an existing organization as the one that OWNS the application — the paired mutation path\n   * for the otherwise-immutable `Organization.type` (#1054).\n   *\n   * ## Why it has to exist at all\n   *\n   * `type` is creation-time identity, so an application that adds `ownsApplication` to its declaration\n   * AFTER it has been running has no way to say which of its existing organizations is the owner: the\n   * bootstrap that would have typed one has already run, and nothing else may write `type`. Without\n   * this door the marker would only ever work on applications created after it — the immutability\n   * construct shipped with no way past it that `.claude/rules/design-philosophy.md` names.\n   *\n   * ## Why it is NOT cross-tenant\n   *\n   * The promoter must be a MEMBER of the target organization holding `APP_ADMIN_SUPER_ADMIN`, which\n   * the bootstrap administrator is. The crossing rule on this resource is \"cross the boundary for\n   * actions a later action can undo\", and promotion has no inverse: there is no demotion door, and\n   * building one would mean an application could be left with no owner organization at all. A crossed\n   * version would need that inverse, or a two-person rule, and neither is built.\n   *\n   * ## What it refuses, and why each refusal rather than a reconciliation\n   *\n   * The target type's `userTypes` must COVER the source type's, every existing membership role must be\n   * in the target type's `availableOrgRoles`, and a SCIM binding may not be lost. Those are the\n   * dependent policy surfaces a type carries — `userTypes` are granted on join and revoked on leave,\n   * and suspend/activate/restore re-derive them across three resources — so a promotion that changed\n   * any of them would owe a revoke-and-regrant reconciliation across every member, in one transaction,\n   * on a door used once in an application's life. Refusing instead keeps the operation honest about\n   * what it does: it changes the tenant's IDENTITY and touches nobody's authority. The refusal names\n   * the first mismatch, so the remedy is to widen the target type rather than to guess.\n   */\n  PROMOTE_TO_OWNER_ORGANIZATION = 'promoteToOwnerOrganization',\n  /**\n   * Mark the tenant for deletion — the SOFT-DELETE half of tenant teardown.\n   *\n   * Replaces the tenant-facing `DELETE` door, which now belongs to the purge batch. Writes\n   * `status: DELETED` + `deletionRequestedAt` + `purgeScheduledAt`, reconciles every affected user's global\n   * `userTypes`, and invalidates their tokens — so the tenant is authorization-dead immediately\n   * while remaining fully data-alive and restorable until the window elapses.\n   */\n  REQUEST_DELETION = 'request_deletion',\n  /**\n   * Cancel a pending deletion inside the retention window.\n   *\n   * The inverse of {@link REQUEST_DELETION}. Nothing needs re-creating: authority is re-derived\n   * from the membership rows the window deliberately preserved, which is exactly why those rows\n   * are not touched at mark time.\n   */\n  RESTORE = 'restore',\n}\n\nconst ORGANIZATION_ADMIN_SORT_FIELDS = ['status'];\n\nconst ORGANIZATION_ADMIN_FILTER_FIELDS = {\n  status: z.enum(OrganizationStatus),\n};\n\ntype OrganizationCoreOperations =\n  | CoreResourceOperation.READ\n  | CoreResourceOperation.LIST\n  | CoreResourceOperation.SEARCH\n  | CoreResourceOperation.CREATE\n  | CoreResourceOperation.UPDATE\n  | CoreResourceOperation.DELETE;\n\n/*\nOrganizations Resource Configuration Factory\n*/\nexport const organizationResourceConfiguration_InitializationFactory = (resourcesRelationships: ResourceRelationship[]) => createResourceConfiguration_Initialization<\n  typeof Organization_Lifecycle_Operations,\n  OrganizationCoreOperations,\n  typeof OrganizationSchema\n>({\n  mainSchema: OrganizationSchema,\n  resourceIdentifier: CoreResourceType.ORGANIZATIONS,\n  resourceFieldIdentifier: coreResourceShared_FieldIdentifier[CoreResourceType.ORGANIZATIONS],\n  resourceRelationships: resourcesRelationships,\n  isSystemResource: true, // Organizations are a core system resource\n  // The invitation-accept auth flow reads the inviting org's display name via\n  // `readAsSystem` to render the invite email — the invitee is not yet a member\n  // and cannot satisfy the org READ ACL. READ-only; the request is authorized by\n  // the consumable invitation token, not org membership.\n  systemAccessPolicy: { read: ResourceSystemAccessMode.ALLOWED },\n\n  coreOperations: [\n    CoreResourceOperation.READ,\n    CoreResourceOperation.LIST,\n    CoreResourceOperation.SEARCH,\n    CoreResourceOperation.CREATE,\n    CoreResourceOperation.UPDATE,\n    CoreResourceOperation.DELETE\n  ],\n\n  customOperation: Organization_Lifecycle_Operations,\n\n  /**\n   * ⚠️ WHAT `APP_ADMIN_SUPER_ADMIN` ACTUALLY BUYS ON THIS RESOURCE (measured 2026-08-05, not inferred)\n   *\n   * Every super-admin-gated variant below reads as cross-tenant (\"any organization\"). **It is not.**\n   * A probe against the real authorization service with real Mongo denied ALL 12 of them to a\n   * platform super-administrator who is not scoped to the target tenant; the same 12 allow once the\n   * caller's execution context carries `initiatorIds.organizationId` equal to that tenant.\n   *\n   * The reason is that tenant isolation is enforced at two gates the role table does not reach:\n   * `validateParentScopeAccess` (collection calls) and `authorizeOrganizations` (per-instance\n   * calls). Both compare the request against the CALLER'S OWN organization. A role key, however\n   * privileged, does not supply one.\n   *\n   * So these variants mean \"a super-admin acting INSIDE an organization\", not \"a super-admin acting\n   * on any organization\". Read every `// Super admins can … any organization` comment below with\n   * that correction applied — they were written from the role gate alone.\n   *\n   * Making one genuinely cross-tenant is a deliberate, per-variant act: declare\n   * `admitsCrossTenantPlatformAdministration` on it, which admits the crossing at BOTH gates.\n   *\n   * ## Which variants are crossed, and why the line falls there (decided 2026-08-05)\n   *\n   * | Variant | Crossed | Reason |\n   * |---|---|---|\n   * | `restore` | ✅ | A MARKED tenant is `DELETED`, which confers no authority, so NOBODY could restore one. Recuperative. |\n   * | `activate` | ✅ | `SUSPENDED` confers no authority and is the only state ACTIVATE runs from. Recuperative. |\n   * | `requestDeletion: admin` | ✅ | The operator takedown path — but the REVERSIBLE one: mark + notify + window, undone by `restore`. |\n   * | `delete: admin` | ❌ | Irreversible, whole-tenant, cascading, skips the window. See its own block for the full decision. |\n   * | `promoteToOwnerOrganization` | ❌ | Irreversible by construction — there is no demotion door, and building one would let an application be left with no owner organization. The promoter is a super-administrator who is a MEMBER of the target, which the bootstrap administrator is. |\n   * | everything else | ❌ | No demonstrated operator need. Absence of a use case is a reason to stay shut. |\n   *\n   * The organising principle: **cross the boundary for actions a later action can undo.** Every\n   * crossing above is recoverable, which is what lets the crossing be justified on operator need\n   * alone. `delete: admin` is the inverse and is therefore held to a higher bar it does not yet\n   * meet. `organizationMembers.grantOwnership` (the owner-floor repair door) follows the same rule\n   * on the membership resource.\n   *\n   * See `.claude/rules/administrative-continuity-floors.md` and\n   * `cross-tenant-super-admin-reach.mongo.integration.test.ts`.\n   */\n  operationsConfiguration: {\n    [CoreResourceOperation.CREATE]: {\n      variants: [\n        {\n          // Registration and registration-onboarding create organizations through\n          // `ServicesRegistryHandlerBackendService.create()`. INTERNAL_CALL is the\n          // service layer's native, route-less transport, so it gives that trusted\n          // workflow a distinct operation identity instead of making it masquerade\n          // as the public self-service endpoint. The organization CREATE prefix\n          // allows creation-policy-managed types only on this path.\n          variantType: ResourceOperationVariantType.INTERNAL_CALL,\n          isDefault: true,\n          roles: [],\n          riskLevel: ResourceOperationRiskLevel.MEDIUM,\n        },\n        {\n          variantType: ResourceOperationVariantType.API_CALL,\n          isDefault: true,\n          /*\n           * Any authenticated user may create their own organization, and OWNERSHIP IS ESTABLISHED\n           * BY THE CREATE FLOW rather than by a role — which was aspirational until 2026-09-08\n           * (#436) and is now true: this variant's postfix writes the founding owner membership for\n           * the creator, so a self-service create can no longer produce a tenant with no members.\n           * The `admin` variant below deliberately does NOT, because a platform operator must not\n           * become a member of a customer tenant; that tenant's first owner is named through the\n           * audited `organizationMembers.grantOwnership` door.\n           */\n          roles: [CORE_APP_ROLES.APP_USER],\n          riskLevel: ResourceOperationRiskLevel.MEDIUM,\n          // DTOs auto-derived from decorators (excludeFromCreate on _id, createdAt, updatedAt)\n          // `status` IS accepted on CREATE (it carries `.default(ACTIVE)`, so an omitted value\n          // lands ACTIVE). Only UPDATE excludes it — see the field's JSDoc for why a tenant must\n          // not be able to re-set its own lifecycle state after the fact.\n        },\n        {\n          variantType: ResourceOperationVariantType.API_CALL,\n          isDefault: false,\n          variantKey: \"admin\",\n          roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN], // Not crossed — see the banner table; creation has no existing tenant to cross into\n          riskLevel: ResourceOperationRiskLevel.LOW,\n          // DTOs auto-derived from decorators (excludeFromCreate on _id, createdAt, updatedAt)\n        }\n      ],\n      userNotifications: [\n        {\n          target: CoreUserNotificationTarget.USER_SELF,\n          channel: CoreUserNotificationChannel.EMAIL,\n        },\n        {\n          target: CoreUserNotificationTarget.USER_SELF,\n          channel: CoreUserNotificationChannel.FRONT_END_SUCCESS,\n        }\n      ]\n    },\n\n    [CoreResourceOperation.READ]: {\n      variants: [\n        {\n          variantType: ResourceOperationVariantType.API_CALL,\n          isDefault: true,\n          roles: [CORE_ORG_ROLES.ORG_MEMBER], // Org members can view their organization\n          riskLevel: ResourceOperationRiskLevel.LOW,\n        },\n        {\n          variantType: ResourceOperationVariantType.API_CALL,\n          isDefault: false,\n          variantKey: \"admin\",\n          roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN], // Not crossed — see the banner table; a super-admin reads organizations they are scoped to\n          riskLevel: ResourceOperationRiskLevel.LOW,\n        }\n      ]\n    },\n\n    /**\n     * ⚠️ THE SCOPE-ROOT COLLECTION OPERATIONS — read this before changing LIST, SEARCH, CREATE or\n     * the roles any of them declares.\n     *\n     * THREE verbs, not two. The banner named only the two reads until 2026-09-08 (#436), and the\n     * omission read as a decision: a reviewer asking \"does CREATE take this branch?\" found a\n     * document that answered for LIST and SEARCH and said nothing about the third. It does — the\n     * branch keys on the RESOURCE being its own scope root, never on the operation — and\n     * `scope-root-collection-gate.test.ts` pins CREATE for `APP_USER` alongside the two reads.\n     *\n     * `organizations` is the ONLY resource that is both ORGANIZATIONS-scoped and its own scope ROOT,\n     * and that makes both of its collection reads special in a way no other resource's are.\n     *\n     * **Their roles resolve against the APPLICATION table, not the organization one.** There is no\n     * `:organizationId` segment on `/organizations`, so `validateParentScopeAccess` cannot ask \"what\n     * are your roles inside THIS tenant\" — it takes the scope-root branch and validates the declared\n     * roles against the caller's APPLICATION-scope entries. Declaring an ORGANIZATION role on either\n     * of these would therefore be unsatisfiable, not merely unusual.\n     *\n     * **Row confinement is NOT free here, and until 2026-08-11 it did not exist.** Every other\n     * org-scoped resource is confined on its `organizationId` COLUMN; the tenant row has no such\n     * column, so both persistence adapters lost the axis and a scope-root LIST compiled to the EMPTY\n     * filter. The comment that used to sit on this line asserted the opposite — \"still filtered to\n     * the caller's own organization\" — and was the reason the gate looked like the only thing\n     * broken. Confinement now comes from `assignScopeRootCollectionConfinementToFilter`, which\n     * restricts these reads to the tenants the caller holds an organization-WIDE role entry for.\n     *\n     * So a platform super-administrator sees THEIR OWN organizations here, not every tenant — which\n     * is the same correction the banner above records for the other eleven super-admin variants. A\n     * genuine cross-tenant directory is NOT available by declaring\n     * `admitsCrossTenantPlatformAdministration`: that admission requires a usable platform-access\n     * grant for a TARGET tenant, and a collection call has no target. See\n     * `.claude/plans/organizations-scope-root-collection-gate-analysis.md`.\n     *\n     * ## ⚠️ If you are here because an operator \"cannot find the tenant id\", STOP\n     *\n     * That is the known and DELIBERATE consequence of the confinement, not a bug in it. An operator\n     * needs an `organizationId` to request a platform-access grant, and no in-product surface yields\n     * the id of a tenant they are not a member of.\n     *\n     * Widening this operation is the obvious fix and the wrong one: it re-opens the cross-tenant\n     * disclosure the confinement closed, and hands the full customer list to every platform\n     * administrator as a standing privilege — exactly what the grant mechanism was built to remove.\n     *\n     * The intended flow is that the id arrives from OUTSIDE the product, with the customer's support\n     * ticket (Microsoft Customer Lockbox and Google Access Approval both work this way). The full\n     * reasoning, and what a legitimate directory operation would look like instead, is on\n     * `platformAccessGrants | requestAccess`'s `organizationId` field and in SEC-SCOPEROOT-5\n     * (`.claude/plans/DEFERRED.md`).\n     */\n    [CoreResourceOperation.LIST]: {\n      variants: [\n        {\n          variantType: ResourceOperationVariantType.API_CALL,\n          isDefault: true,\n          roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN], // Not crossed — resolved against the APPLICATION role table; rows confined to the caller's own organizations\n          riskLevel: ResourceOperationRiskLevel.LOW,\n          filterFields: ORGANIZATION_ADMIN_FILTER_FIELDS,\n          sortFields: ORGANIZATION_ADMIN_SORT_FIELDS,\n        }\n      ]\n    },\n\n    [CoreResourceOperation.SEARCH]: {\n      variants: [{\n        variantType: ResourceOperationVariantType.API_CALL,\n        isDefault: true,\n        roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN], // Same scope-root contract as LIST above\n        riskLevel: ResourceOperationRiskLevel.LOW,\n        isSearchable: true,\n        searchableFields: ['name', 'slug', 'email'],\n        searchableOptions: { caseSensitive: false, fullMatchOnly: false },\n        filterFields: ORGANIZATION_ADMIN_FILTER_FIELDS,\n        sortFields: ORGANIZATION_ADMIN_SORT_FIELDS,\n        maxPaginatedResultPerPageLimit: 100,\n      }],\n    },\n\n    [CoreResourceOperation.UPDATE]: {\n      variants: [\n        {\n          variantType: ResourceOperationVariantType.API_CALL,\n          isDefault: true,\n          roles: [CORE_ORG_ROLES.ORG_ADMIN], // Org admins can update their organization\n          riskLevel: ResourceOperationRiskLevel.MEDIUM,\n          // DTOs auto-derived from decorators (excludeFromUpdate on _id, type,\n          // slug, status, createdAt, updatedAt). Organization-type transitions require\n          // a dedicated dependent-policy migration, not a generic patch, and `status`\n          // belongs to the SUSPEND / ACTIVATE verbs — this variant is ORG_ADMIN-gated, so\n          // accepting it here let a suspended tenant reinstate itself.\n        },\n        {\n          variantType: ResourceOperationVariantType.API_CALL,\n          isDefault: false,\n          variantKey: \"admin\",\n          roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN], // Not crossed — see the banner table\n          riskLevel: ResourceOperationRiskLevel.LOW,\n          // DTOs auto-derived from decorators (excludeFromUpdate on _id, type,\n          // slug, createdAt, updatedAt). Super-admin scope does not make a raw\n          // type rewrite semantically safe.\n        }\n      ],\n      userNotifications: [\n        {\n          target: CoreUserNotificationTarget.ORGANIZATION_ADMINISTRATIVE,\n          channel: CoreUserNotificationChannel.EMAIL,\n        }\n      ]\n    },\n\n    /**\n     * DELETE is the PURGE — the irreversible half of tenant teardown, reached at the END of the\n     * retention window and no longer the tenant-facing door.\n     *\n     * ## Why the tenant-facing variant is gone\n     *\n     * Deleting a tenant used to be synchronous and immediate: one `DELETE /organizations/{id}` by\n     * an ORG_ADMIN destroyed the tenant and everything the cascade reached. Tenant offboarding is\n     * a job-shaped problem, not a request-shaped one, so it is now two phases —\n     * {@link Organization_Lifecycle_Operations.REQUEST_DELETION} marks the tenant (and kills its\n     * authority immediately), and this operation destroys it once\n     * `Organization.purgeScheduledAt` has elapsed. Leaving an ORG_ADMIN-reachable synchronous\n     * DELETE in place would have made the retention window optional for exactly the caller it\n     * protects, which is the same as not having one.\n     *\n     * ## The two remaining doors\n     *\n     * - **INTERNAL_CALL (default)** — the route-less service transport the `organization-purge`\n     *   batch dispatches through. Route-less is the point: a window that any client can skip is\n     *   decorative. This mirrors CREATE on this same resource, whose default is likewise an\n     *   INTERNAL_CALL owned by a trusted workflow.\n     * - **API_CALL `admin`** — the super-administrator's deliberate purge-now escape hatch, for a\n     *   legal-order or abuse takedown that cannot wait out the window. Kept because operators\n     *   genuinely need it and because forcing them to a database console would be strictly worse\n     *   for auditability: this door is role-gated, step-up-gated, and emits `ORGANIZATION_DELETED`\n     *   like any other purge. It SKIPS the retention window by design.\n     *\n     * ⚠️ Custom implementations resolve by an exact operation-path key that embeds `variantType`.\n     * The default door changing from API_CALL to INTERNAL_CALL therefore MOVES the key that\n     * `organization-deletion-audit.custom-impl.backend.service.ts` registers on — that file was\n     * updated in the same pass. A hook left on the old key silently never runs.\n     *\n     * Cascading delete is handled via `childOperations.lifecycle.onParentDelete` on relationships.\n     *\n     * ⚠️ NO `userNotifications` here any more. They moved to `REQUEST_DELETION`, which is where\n     * they can still reach anyone: telling an organization's users that it has been deleted, in\n     * the same transaction that deletes those users' memberships, is a notification with no\n     * audience — and the batch that triggers a purge has no initiating user context to render it\n     * from. The members are told when the tenant is MARKED, which is also the only moment the\n     * warning is actionable (it can still be restored).\n     */\n    [CoreResourceOperation.DELETE]: {\n      variants: [\n        {\n          variantType: ResourceOperationVariantType.INTERNAL_CALL,\n          isDefault: true,\n          roles: [],\n          riskLevel: ResourceOperationRiskLevel.CRITICAL,\n        },\n        {\n          variantType: ResourceOperationVariantType.API_CALL,\n          isDefault: false,\n          variantKey: \"admin\",\n          roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],\n          riskLevel: ResourceOperationRiskLevel.HIGH,\n          //\n          // ⚠️ DELIBERATELY NOT CROSS-TENANT — the one super-admin door on this resource left shut,\n          // decided 2026-08-05. Do not \"finish the job\" by adding\n          // `admitsCrossTenantPlatformAdministration` here without re-opening the decision below.\n          //\n          // The tension is real and worth stating rather than hiding: the JSDoc above says this door\n          // is kept because operators genuinely need it and because pushing them to a database\n          // console would be strictly worse for auditability. Both halves argue for opening it. What\n          // outweighs them is asymmetry of consequence.\n          //\n          // Every other crossing on this resource is recoverable. ACTIVATE un-halts, RESTORE\n          // un-marks, REQUEST_DELETION marks-with-a-window. `grantOwnership` on the membership\n          // resource is additive and idempotent. Their safety argument is \"one narrow effect that a\n          // later action can undo\". This operation is the exact inverse: irreversible, whole-tenant,\n          // cascading, and it SKIPS the window on purpose. There is no RESTORE after a purge.\n          //\n          // The security cost is a change of KIND, not degree. Today a compromised platform-admin\n          // credential can destroy only tenants that principal is already scoped into — accidental\n          // containment, but real containment. Crossing this one converts that same compromise into\n          // \"any tenant, immediately\". `requiresStepUpAuthentication` answers a hijacked session; it\n          // does not answer phished credentials with the second factor supplied.\n          //\n          // And the operational pressure that makes opening it feel urgent is mostly relieved by the\n          // three doors that DID open: a legal-order or abuse takedown can now be executed\n          // cross-tenant through REQUEST_DELETION (mark + notify + window), with RESTORE available\n          // if the order is stayed or the abuse call was wrong. That covers the cited use cases with\n          // a recovery path. What remains uncovered is only \"destroy within hours, irreversibly,\n          // against a tenant the operator is not in\".\n          //\n          // If that residue must be covered, the answer is NOT this flag alone. Require, together:\n          // a mandatory `justification` on the request DTO (as `organizationMembers.grantOwnership`\n          // has), a distinct high-severity audit event separable from routine purges, and a\n          // two-person rule. Instant irreversible cross-tenant destruction is the one capability in\n          // this product that deserves a second SIGNATURE, not merely a second factor. Until those\n          // exist, the honest operator answer is the window — or a database console with a change\n          // ticket, which at least leaves a human trail outside the system it is destroying.\n          //\n          // assurance-control: WILDO.ACCESS.CROSS_TENANT_ADMINISTRATION — deliberate non-grant;\n          // the blast radius of this verb is not admitted to platform tier.\n          //\n          //\n          // Irreversible destruction of a whole tenant, and it cascades. A hijacked session must not\n          // be able to do this on the strength of a login that happened at some earlier point:\n          // `riskLevel` is UI-only, and the per-user-type `stepUpAuth` policy is opt-in, off by\n          // default, and satisfied by any authentication newer than `maxAgeSeconds`.\n          //\n          // assurance-control: WILDO.IDENTITY.STEP_UP_AUTHENTICATION — re-authentication before a high-impact action.\n          requiresStepUpAuthentication: true,\n        }\n      ],\n    },\n\n    [Organization_Lifecycle_Operations.ACTIVATE]: {\n      variants: [\n        {\n          variantType: ResourceOperationVariantType.API_CALL,\n          isDefault: true,\n          roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],\n          riskLevel: ResourceOperationRiskLevel.MEDIUM,\n          resourceOperationLike: CoreResourceOperation.UPDATE,\n          // Cross-tenant, because otherwise this door cannot be opened by anyone. `SUSPENDED` is in\n          // `ORGANIZATION_STATUSES_WITHOUT_AUTHORITY`, so a suspended tenant's own admins hold no\n          // authority — and ACTIVATE is reachable only FROM `SUSPENDED` or `TRIAL_EXPIRED`. Without\n          // the crossing, the only principal who could un-suspend a tenant is a super-administrator\n          // who happens to already be a member of it, which is an accident of staffing rather than a\n          // control. Purely recuperative: it moves a halted tenant back to operational and destroys\n          // nothing, so admitting the crossing costs no reversibility.\n          admitsCrossTenantPlatformAdministration: true,\n          requestDto: z.object({\n            reason: z.string().max(500).optional()\n          }),\n          // Conditional availability by org status. ACTIVATE re-enables a halted\n          // or inactive organization, so it is available only from SUSPENDED or\n          // TRIAL_EXPIRED — never from ACTIVE (a no-op) nor the terminal\n          // CANCELLED / DELETED states. Evaluated on BOTH the frontend (the\n          // action renders disabled otherwise, via `useOperationsEnabled`) AND\n          // the backend (`services-registry-handler` throws\n          // `SERVICE_RESOURCE_OPERATION_DISABLED` → 403 when false), so the guard\n          // holds even if the client is bypassed. Keep in sync with the resource\n          // spec's ACTIVATE error scenarios.\n          enabledCondition: ({ currentObject }) => {\n            return (\n              currentObject.status === OrganizationStatus.SUSPENDED ||\n              currentObject.status === OrganizationStatus.TRIAL_EXPIRED\n            );\n          },\n          // NO `haveBulkOperation`. The generated bulk variant was removed on 2026-08-01: it could\n          // never do bulk work. `assertBulkHookObjectContextAvailability` fails a bulk UPDATE\n          // closed whenever its `enabledCondition` needs object context and no single persisted\n          // `currentObject` is available — and the condition above reads `currentObject.status` by\n          // construction, because the whole point is that ACTIVATE is only legal from specific\n          // states. So a multi-org selector was refused (403) BY DESIGN and the variant only ever\n          // worked with a one-element `_ids` array: a more expensive spelling of this variant, at\n          // the cost of a second route and a second custom-implementation registration\n          // (`isBulkOperation` is part of the operation-path key). Bulk suspension would require\n          // abandoning the per-row state gate, which is not a trade this operation should make.\n        }\n      ],\n      userNotifications: [\n        {\n          target: CoreUserNotificationTarget.ORGANIZATION_ADMINISTRATIVE,\n          channel: CoreUserNotificationChannel.EMAIL,\n        }\n      ]\n    },\n\n    [Organization_Lifecycle_Operations.SUSPEND]: {\n      variants: [\n        {\n          variantType: ResourceOperationVariantType.API_CALL,\n          isDefault: true,\n          roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN], // Only super admins can suspend organizations\n          riskLevel: ResourceOperationRiskLevel.CRITICAL,\n          resourceOperationLike: CoreResourceOperation.UPDATE,\n          requestDto: z.object({\n            suspensionReason: z.string().min(1).max(500),\n            notifyMembers: z.boolean().default(true)\n          }),\n          // Conditional availability by org status. SUSPEND halts an operational\n          // organization, so it is available only from ACTIVE or TRIAL — never\n          // from SUSPENDED (a no-op) nor the terminal CANCELLED / DELETED states.\n          // Enforced on the frontend (the action renders disabled otherwise) AND\n          // the backend (`services-registry-handler` throws\n          // `SERVICE_RESOURCE_OPERATION_DISABLED` → 403), so re-suspending an\n          // already-suspended org fails closed server-side. Keep in sync with the\n          // resource spec's SUSPEND error scenarios.\n          enabledCondition: ({ currentObject }) => {\n            return (\n              currentObject.status === OrganizationStatus.ACTIVE ||\n              currentObject.status === OrganizationStatus.TRIAL\n            );\n          },\n          // NO `haveBulkOperation` — same reasoning as ACTIVATE above. Suspending many tenants in\n          // one request is exactly the operation whose per-row state gate must not be dropped.\n        }\n      ],\n      userNotifications: [\n        {\n          target: CoreUserNotificationTarget.ORGANIZATION_USERS,\n          channel: CoreUserNotificationChannel.EMAIL,\n          // Honours the `notifyMembers` flag the request contract has always advertised.\n          //\n          // Until this operation was implemented the flag was inert in the worst way: the DTO\n          // accepted it, the caller could set it to `false`, and the declarative notification fired\n          // regardless — a silent contract lie on an operation that emails an entire tenant. A\n          // suspension is sometimes deliberately quiet (a fraud hold the operator does not want to\n          // tip off), so this is a real capability rather than a formality.\n          //\n          // `!== false` rather than a truthy test: the field carries `.default(true)`, so an\n          // omitted value must still notify.\n          condition: ({ inputDto }) => (inputDto as { notifyMembers?: boolean } | undefined)?.notifyMembers !== false,\n        }\n      ]\n    },\n\n    /**\n     * Mark the tenant for deletion — the SOFT-DELETE phase, and the door that replaced the\n     * tenant-facing `DELETE`.\n     *\n     * ## What fires here, and what deliberately does not\n     *\n     * Authorization consequences fire NOW; data removal waits for the purge. The split is the\n     * load-bearing part of the design:\n     *\n     * - **now** — `status: DELETED` + `deletionRequestedAt` + `purgeScheduledAt`; every affected user's\n     *   GLOBAL `user.userTypes` reconciled; their tokens invalidated. A global grant that exists\n     *   only because of this tenant must not outlive it by the length of the retention window —\n     *   that grant outliving its justification is the original defect this whole workstream\n     *   exists to fix, and deferring it to the purge would ship that defect with a longer fuse.\n     * - **later (purge)** — membership rows, unit assignments and every other org child.\n     *\n     * The rule that decides which side a concern lands on: remove at mark time only what is\n     * RE-DERIVABLE on restore. Org-scoped roles are re-derivable from the membership rows, so the\n     * rows stay and the authority is recomputed per request from `status` (see\n     * `isAuthorityConferringOrganizationStatus`). Global `userTypes` are NOT re-derivable that\n     * way — they are a denormalized grant on the user row — so they are reconciled here, and\n     * `restore` re-grants them.\n     *\n     * ## Audience limitation inherited from the DELETE door this replaces — now CLOSED\n     *\n     * This used to read: re-authentication proves identity by PASSWORD only, the framework DESTROYS\n     * `passwordHash` + passkeys for directory-managed (SCIM) users as a compliance control\n     * (`_reconcileLocalCredentialsForDirectoryManaged`), so an ORG_ADMIN of a directory-managed\n     * organization could not satisfy the step-up gate and was refused — and it named the fix as\n     * future work, routing such a tenant through the `admin` variant below.\n     *\n     * That fix SHIPPED. `AuthMethodManagementBackendService.reAuthenticate` accepts PASSWORD, TOTP\n     * and PASSKEY. `AuthMethod.TOTP` means \"an enrolled second factor\" — a TOTP code or a backup\n     * code — verified through `AuthMfaBackendService.verifyEnrolledSecondFactor`, the same single\n     * authority the login second-factor step uses, anti-replay included. It was chosen precisely\n     * because the SCIM reconciliation PRESERVES it: a second factor sitting on top of the IdP first\n     * factor survives deprovisioning by design.\n     *\n     * So a directory-managed ORG_ADMIN can satisfy this gate itself, and does NOT need the `admin`\n     * variant to start a teardown. That variant remains for platform-operator use, not as the\n     * workaround for a limitation that no longer exists.\n     *\n     * assurance-control: WILDO.IDENTITY.STEP_UP_AUTHENTICATION — re-authentication before a high-impact\n     * action; the tenant loses its access rights at the moment of the decision, not at the moment\n     * its data is destroyed.\n     */\n    [Organization_Lifecycle_Operations.REQUEST_DELETION]: {\n      variants: [\n        {\n          variantType: ResourceOperationVariantType.API_CALL,\n          isDefault: true,\n          roles: [CORE_ORG_ROLES.ORG_ADMIN], // Org admins can schedule their own organization's deletion\n          riskLevel: ResourceOperationRiskLevel.CRITICAL,\n          resourceOperationLike: CoreResourceOperation.UPDATE,\n          requestDto: z.object({\n            reason: z.string().max(500).optional()\n          }),\n          requiresStepUpAuthentication: true,\n          // Available only from a state the tenant can still be marked FROM. Never from DELETED\n          // (already marked — restore or wait for the purge) nor from the terminal CANCELLED.\n          // Enforced on the frontend (the action renders disabled) AND the backend\n          // (`services-registry-handler` throws `SERVICE_RESOURCE_OPERATION_DISABLED` → 403), so a\n          // double-mark fails closed server-side and cannot silently re-arm the window. Keep in\n          // sync with the resource spec's REQUEST_DELETION error scenarios.\n          //\n          // The condition is shared with the `admin` variant below, and the ROLE gate is what\n          // makes them differ in practice: `SUSPENDED` confers no authority\n          // (`ORGANIZATION_STATUSES_WITHOUT_AUTHORITY`), so on THIS variant that arm is\n          // unreachable — an org admin cannot mark a tenant the platform has halted. It is\n          // reachable on the `admin` variant, which is the intended shape: a suspended tenant is\n          // under platform control, and the platform can still schedule its deletion.\n          enabledCondition: ({ currentObject }) => {\n            return (\n              currentObject.status === OrganizationStatus.ACTIVE ||\n              currentObject.status === OrganizationStatus.TRIAL ||\n              currentObject.status === OrganizationStatus.TRIAL_EXPIRED ||\n              currentObject.status === OrganizationStatus.SUSPENDED\n            );\n          },\n          // NO `haveBulkOperation` — same reasoning as SUSPEND/ACTIVATE: the per-row state gate\n          // above reads `currentObject.status`, and a bulk UPDATE whose `enabledCondition` needs\n          // object context is failed closed by `assertBulkHookObjectContextAvailability`.\n        },\n        {\n          variantType: ResourceOperationVariantType.API_CALL,\n          isDefault: false,\n          variantKey: \"admin\",\n          roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],\n          // Cross-tenant: this is the operator's takedown path, and it is the REVERSIBLE one. It\n          // MARKS the tenant, notifies its users, and starts the retention window — every effect can\n          // be undone by RESTORE (also crossed, immediately above; crossing one without the other\n          // would hand operators a one-way door and call it a window).\n          //\n          // The JSDoc on the sibling org-admin variant already asserts this shape — \"a suspended\n          // tenant is under platform control, and the platform can still schedule its deletion\" —\n          // which was true of the role gate and false of the runtime until this flag.\n          //\n          // Deliberately the FIRST destructive door opened, and deliberately not the last one: a\n          // legal-order or abuse takedown routed through MARK + window keeps a recovery path open,\n          // which is what makes leaving instant purge closed (see DELETE `admin`) affordable rather\n          // than merely cautious.\n          admitsCrossTenantPlatformAdministration: true,\n          riskLevel: ResourceOperationRiskLevel.HIGH,\n          resourceOperationLike: CoreResourceOperation.UPDATE,\n          requestDto: z.object({\n            reason: z.string().max(500).optional()\n          }),\n          // The flag is per-VARIANT — nothing is inherited from the variant above. Marking someone\n          // else's tenant for destruction is not a lesser act than marking your own.\n          requiresStepUpAuthentication: true,\n          enabledCondition: ({ currentObject }) => {\n            return (\n              currentObject.status === OrganizationStatus.ACTIVE ||\n              currentObject.status === OrganizationStatus.TRIAL ||\n              currentObject.status === OrganizationStatus.TRIAL_EXPIRED ||\n              currentObject.status === OrganizationStatus.SUSPENDED\n            );\n          },\n        }\n      ],\n      userNotifications: [\n        {\n          // The members ARE the audience here, and this is the only moment the warning is\n          // actionable — the tenant can still be restored. This notification moved from DELETE,\n          // where by the time it fired its recipients were being deleted in the same transaction.\n          target: CoreUserNotificationTarget.ORGANIZATION_USERS,\n          channel: CoreUserNotificationChannel.EMAIL,\n        }\n      ]\n    },\n\n    /**\n     * Cancel a pending deletion — the inverse of\n     * {@link Organization_Lifecycle_Operations.REQUEST_DELETION}, available for the whole\n     * retention window.\n     *\n     * Restoring needs no data re-creation, and that is a property of the phase split rather than a\n     * happy accident: the mark deliberately removed only what is re-derivable. Membership rows,\n     * unit assignments and every other child were never touched, so clearing `status` re-arms\n     * org-scoped authority on the next request for free. The one thing that WAS removed — each\n     * affected user's global `userTypes` — is re-granted here from the same configuration that\n     * granted it originally.\n     *\n     * ## Why the window is not re-checked here\n     *\n     * There is no \"too late to restore\" branch. If the purge has run, the row is gone and the\n     * operation 404s at addressing; if the row is present, it is restorable. Encoding a second\n     * time-based rule would create a state where a row exists but claims to be unrecoverable —\n     * an unrecoverable row that still holds every one of its members' data is the worst of both\n     * phases.\n     *\n     * Deliberately NOT step-up gated: restoring is the SAFE direction. Every other lifecycle verb\n     * here reduces access or destroys data; this one returns a tenant to the state it was already\n     * in. Gating recovery behind the same friction as destruction discourages the correct\n     * response to a mistaken deletion.\n     *\n     * ## ⚠️ Why this is SUPER-ADMIN ONLY — a tenant cannot un-mark itself\n     *\n     * Not a policy preference: an ORG-scoped variant here would be UNSATISFIABLE. A `DELETED`\n     * organization confers no authority at all\n     * (`ORGANIZATION_STATUSES_WITHOUT_AUTHORITY`), so its ORG_ADMIN no longer holds `ORG_ADMIN`\n     * anywhere and would be refused by the role gate before `enabledCondition` was ever consulted.\n     * Declaring the variant anyway would ship a door that renders in the UI, is documented in the\n     * spec, and answers 403 forever.\n     *\n     * That is also the correct product shape, and it is what every comparable system does —\n     * Microsoft 365, Google Workspace, Salesforce and AWS all recover a deleted tenant through the\n     * PROVIDER's administrator or support, never through the deleted tenant's own credentials.\n     * The tenant-facing safety net is the retention window itself; the recovery action is an\n     * operator's.\n     *\n     * assurance-control: WILDO.DATA.SECURE_LIFECYCLE — a reversible deletion decision, with the\n     * reversal itself audited and performed by a separately-privileged party.\n     */\n    [Organization_Lifecycle_Operations.RESTORE]: {\n      variants: [\n        {\n          variantType: ResourceOperationVariantType.API_CALL,\n          isDefault: true,\n          roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN], // See the JSDoc: an org-scoped variant would be unsatisfiable\n          riskLevel: ResourceOperationRiskLevel.HIGH,\n          // Cross-tenant, and this variant is WHY the gap was worth finding. The JSDoc above rejects\n          // an org-scoped variant precisely because it \"would ship a door that renders in the UI, is\n          // documented in the spec, and answers 403 forever\" — and then shipped exactly that one\n          // tier up: a MARKED tenant is `DELETED`, which confers no authority, so its own admins\n          // cannot restore it; and a platform administrator could not reach the row. Nobody could\n          // restore a marked tenant, and the purge batch collected it when the window expired.\n          //\n          // That makes the retention window the load-bearing casualty: a window whose release nobody\n          // can pull is not a safety net, it is a delay. Restoring it here is what lets the rest of\n          // the teardown lifecycle keep claiming reversibility.\n          admitsCrossTenantPlatformAdministration: true,\n          resourceOperationLike: CoreResourceOperation.UPDATE,\n          requestDto: z.object({\n            reason: z.string().max(500).optional()\n          }),\n          // Only a MARKED tenant can be restored. From any live state this is a no-op, and from\n          // the terminal CANCELLED it is not a deletion being undone.\n          enabledCondition: ({ currentObject }) => {\n            return currentObject.status === OrganizationStatus.DELETED;\n          },\n        }\n      ],\n      userNotifications: [\n        {\n          target: CoreUserNotificationTarget.ORGANIZATION_USERS,\n          channel: CoreUserNotificationChannel.EMAIL,\n        }\n      ]\n    }\n,\n\n    /**\n     * Promote this organization to the one that OWNS the application (#1054).\n     *\n     * The paired mutation path for `Organization.type`, which is creation-time identity. The field's\n     * own JSDoc has reserved exactly this since it was written: *\"a future type transition must be a\n     * dedicated migration operation that reconciles every dependent member and policy surface\"*. This\n     * is that operation, narrowed to the one transition the framework needs and refusing rather than\n     * reconciling — see the enum member's JSDoc for why refusing is the honest shape here.\n     *\n     * ## ⚠️ NOT cross-tenant, and this is the one place on this resource where that is a DESIGN\n     * decision rather than an omission\n     *\n     * The banner at the top of this configuration records the rule: **cross the boundary for actions a\n     * later action can undo.** `restore`, `activate` and `requestDeletion: admin` are crossed because\n     * each is reversible. Promotion is not: there is no demotion operation, deliberately, because an\n     * application whose owner organization can be un-typed is one that can be left with no owner at\n     * all — and `type` being immutable means nothing could then repair it.\n     *\n     * So the promoter is a super-administrator who is a MEMBER of the target organization. On the\n     * application this exists for, that is exactly who is available: the bootstrap administrator is a\n     * member of the organization the platform seeded for them, and that organization is the one being\n     * promoted. Opening the crossing would need a `demote` door or a two-person rule first.\n     *\n     * ## Why a `justification` is required\n     *\n     * It is the whole control on an irreversible act, in the same shape as\n     * `organizationMembers.grantOwnership`. It is RECORDED — on the `ORGANIZATION_TYPE_ASSIGNED` event\n     * this operation emits, beside the type it replaced — because a required request field that\n     * nothing stores is a promise nobody keeps (#593, where `grantOwnership`'s justification was\n     * validated and then dropped for months).\n     *\n     * ## Why no `enabledCondition` on \"no owner exists yet\"\n     *\n     * `enabledCondition` receives the CURRENT OBJECT — this organization — and the question \"does the\n     * application already have an owner organization?\" is about a different row. The refusal therefore\n     * lives in the custom implementation, which answers `409 APPLICATION_OWNER_ORGANIZATION_EXISTS`.\n     * The condition here covers what the current object CAN answer: only an ACTIVE tenant may be\n     * promoted, because a suspended or marked one confers no authority and promoting it would make the\n     * organization that operates the application one nobody can act through.\n     *\n     * assurance-control: WILDO.ACCESS.ADMINISTRATIVE_CONTINUITY — names the organization that operates\n     * the application, under justification and audit, on a door that cannot be reached from outside\n     * the tenant.\n     * assurance-control: WILDO.AUDIT.SECURITY_EVENT — an authentication-relevant tenant attribute\n     * changes, and the record names who changed it and why.\n     */\n    [Organization_Lifecycle_Operations.PROMOTE_TO_OWNER_ORGANIZATION]: {\n      variants: [\n        {\n          variantType: ResourceOperationVariantType.API_CALL,\n          isDefault: true,\n          // Platform tier, and UNCROSSED — no `admitsCrossTenantPlatformAdministration`. The caller\n          // must hold this key AND be a member of the target organization, which is what the two\n          // tenant gates (`validateParentScopeAccess`, `authorizeOrganizations`) enforce on this\n          // resource independently of the role table. See the JSDoc above for why the crossing stays\n          // shut.\n          roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],\n          riskLevel: ResourceOperationRiskLevel.CRITICAL,\n          resourceOperationLike: CoreResourceOperation.UPDATE,\n          requestDto: z.object({\n            justification: z.string().min(1).max(1000),\n          }),\n          // Irreversible and it re-points everything the application owns as an operator. A hijacked\n          // session must not reach it on the strength of a login that happened at some earlier point.\n          //\n          // assurance-control: WILDO.IDENTITY.STEP_UP_AUTHENTICATION — re-authentication before a\n          // high-impact action.\n          requiresStepUpAuthentication: true,\n          // Only an ACTIVE tenant. Every other status either confers no authority\n          // (`ORGANIZATION_STATUSES_WITHOUT_AUTHORITY`) or is terminal, and an owner organization\n          // nobody can act through is not an owner. Enforced on the frontend (the action renders\n          // disabled) AND the backend (`services-registry-handler` throws\n          // `SERVICE_RESOURCE_OPERATION_DISABLED` → 403). Keep in sync with the resource spec's\n          // PROMOTE_TO_OWNER_ORGANIZATION error scenarios.\n          enabledCondition: ({ currentObject }) => currentObject.status === OrganizationStatus.ACTIVE,\n          // NO `haveBulkOperation` — same reasoning as every other member here, and stronger: at most\n          // one organization may ever be promoted, so a multi-row selector is meaningless.\n        }\n      ],\n      /*\n       * NO `userNotifications`, and the reason is the UNCROSSED design rather than an omission.\n       *\n       * A first draft declared an email to `ORGANIZATION_ADMINISTRATIVE`, reasoning that the tenant\n       * should learn it now operates the application. Running it proved that wrong twice over.\n       *\n       * Mechanically: the declaration named a template nobody had authored, and the engine's lifecycle\n       * check said so at every boot — *\"the operation still succeeds, but its notification is silently\n       * never delivered\"*. A declared notification with no template is worse than none; it is a promise\n       * the running system reports as unkept.\n       *\n       * And on the merits, the audience is wrong. `organizationMembers.grantOwnership` notifies because\n       * it CROSSES: an operator outside the tenant changes who owns it, and the difference between a\n       * legitimate repair and a quiet self-grant is only visible to the tenant if it is told. Promotion\n       * is deliberately uncrossed — the caller is a super-administrator who is a MEMBER of the very\n       * organization being promoted — so there is no outsider to disclose and nobody the email would\n       * inform who was not already the actor. The audit row, which names the actor and their\n       * justification, is the record this act owes.\n       */\n    },\n  },\n\n});\n\n"]}