@wildo-ai/saas-models 1.0.1 → 1.1.1

package/dist/esm/users/user-self.shared.resources-config.schemas.js

@@ -5,22 +5,106 @@
  * Handles profile management, preferences, and personal data operations.
  */
 import { z } from 'zod';
-import { UserSchema, UserProfileSchema, UserPreferencesSchema, UserStatus } from './users.shared.schemas.js';
+import { UserSchema, UserStatus } from './users.shared.schemas.js';
 import { CoreResourceOperation } from '../resources/resources.shared.core.definitions.js';
 import { ResourceOperationRiskLevel } from '../resources/resources.shared.schemas.js';
 import { CoreResourceType, coreResourceShared_FieldIdentifier } from '../resources/resources.shared.core.definitions.js';
 import { ResourceOperationVariantType } from '../resources/resources.shared.schemas.js';
 import { CoreUserNotificationTarget, CoreUserNotificationChannel } from '../notifications/notifications.shared.schemas.js';
 import { createResourceConfiguration_Initialization } from '../resources/resources-config.shared.factory.js';
+import { ErasureRetentionMode, ResourceDataSubjectKind } from '../compliance/privacy/impersonalization.shared.schemas.js';
 import { CORE_APP_ROLES } from '../security/authorizations/roles.shared.schemas.js';
+import { ResourceSystemAccessMode } from '../resources/resources-config.shared.schemas.js';
+import { DataPortabilityProvenance } from '../compliance/privacy/subject-export.shared.schemas.js';
 // Custom operations enum for user self management
+//
+// PASSWORD CHANGE IS NOT A RESOURCE OPERATION — IT IS AN AUTH ROUTE. `CHANGE_PASSWORD` was
+// declared here as an `APP_USER`-gated `riskLevel: HIGH` operation taking
+// `{ currentPassword, newPassword, confirmPassword }`, and was removed on 2026-08-01: it was
+// ROUTED but never implemented, so the request fell through to the generic core UPDATE, which
+// persists only fields the resource schema declares. A password verifier is not one of them
+// (credentials are a separate store), so every call answered **HTTP 200 having changed nothing**
+// — the caller is told their password rotated while the old one still works.
+//
+// The real implementation already exists and is the ONLY correct home for it:
+// `POST /auth/password/change` → `AuthMethodManagementBackendService.changePassword`, which
+// verifies the current-password proof, applies the per-user-type password policy, hashes,
+// invalidates every refresh token for the user, and writes a `USER_PASSWORD_CHANGED` audit
+// record. It is rate-limited (5/min/IP) and parses its body with `z.strictObject` so an
+// identity field smuggled into the payload is rejected loudly rather than silently ignored.
+// The frontend already calls exactly that route (`AppPage_SecuritySettings` →
+// `getManualCallsHttpClient().passwordChange(...)`).
+//
+// Do NOT re-declare this as a resource operation. Beyond duplicating a solved problem, it would
+// route a plaintext credential through the generic resource-write pipeline (DTO parse, repository
+// projection, notification fan-out) that the auth route deliberately bypasses.
+// See `.claude/plans/routed-unimplemented-operations-fail-closed.md`.
+//
+// NOR ARE PROFILE / PREFERENCES WRITES — THEY BELONG TO THEIR OWN RESOURCES. `UPDATE_PROFILE` and
+// `UPDATE_PREFERENCES` were removed on 2026-08-01. Both ran `resourceOperationLike: UPDATE` against
+// THIS resource — whose `mainSchema` is the USER — while declaring the request DTO of a DIFFERENT
+// resource (`UserProfileSchema.partial()` / `UserPreferencesSchema.partial()`). A core UPDATE writes
+// only its own resource's row, so every declared field was dropped; the single intersecting key was
+// `_id`, which `ResourceOperationsHelper.cleanInputData` force-deletes before validation. The write
+// was therefore empty and the route answered **HTTP 200 having persisted nothing**.
+//
+// The persisted documents already have dedicated self-scoped resources, and they are already the
+// wired path: `USER_SELF_PROFILES` exposes READ/CREATE/UPDATE over its own `mainSchema`, while
+// `USER_SELF_PREFERENCES` exposes READ/UPDATE plus its selective reset operation over the eagerly
+// seeded preferences row. Both are embedded as child resources of this one in the frontend preset,
+// carry their own resource specifications, and — for preferences — are the MCP-exposed read/update
+// tools.
+// This resource's own specification already directed engineers there for "the persisted documents".
+//
+// Do NOT re-declare either verb here. A single `user_self`-rooted write across child resources
+// cannot be a core UPDATE at all; it would need a custom multi-resource implementation declaring
+// `transactionParticipants` — new machinery duplicating a path that already exists. Route clients
+// to `userSelfProfiles` / `userSelfPreferences` instead.
+//
+// NOR IS SELF-SERVICE ACCOUNT DELETION — DATA-SUBJECT ERASURE IS A SYSTEM-LEVEL API WITH NO ROUTE.
+// `DELETE_ACCOUNT` was removed on 2026-08-01. It was an `APP_USER`-gated `riskLevel: CRITICAL`
+// operation taking `{ password, reason }` and declaring a scheduled-deletion
+// `customResponseDto: { scheduledDeletionDate, recoveryPeriodDays, dataExportUrl }`. It was broken
+// in four independent ways, each verified against the built configuration:
+//
+//   - **The password was never verified.** Neither declared field is a persisted `UserSchema` path
+//     and no custom implementation was bound to the operation path, so the built `repositoryDto`
+//     was EMPTY: the controller strict-parsed the body, the repository re-parsed it, and both
+//     fields were discarded. A UI collecting the password as a confirmation gate was providing
+//     false assurance.
+//   - **It could never answer successfully.** `transformOutput` skips default-envelope composition
+//     for an op declaring a `customResponseDto` and validates the raw service output against it.
+//     A core DELETE returns the deleted `_id` as a bare string, so every call threw
+//     `service_resource_transformation_failed` → HTTP 500. Retries too: a second call returns `''`,
+//     which is not `null`, so it fails the same parse.
+//   - **Its destructive effect was NONDETERMINISTIC.** `resourceOperationLike: DELETE` reaches
+//     `_doDelete` through the repository's operations map (which holds custom ops), bypassing the
+//     `coreOperations` gate this config never opened — and fires `onParentDelete`. Neither
+//     `USER_SELF_PROFILES` nor `USER_SELF_PREFERENCES` declares a DELETE, so a user WITH either row
+//     hit `ErrorType.CONFIGURATION` inside the delete transaction and was rolled back, while a user
+//     with NEITHER row was destroyed. Same 500, opposite persistence outcomes.
+//   - **It contradicted this resource's own retention contract.** `retentionPolicy` below declares
+//     `RETAIN_AND_IMPERSONALIZE`: user rows are RETAINED and scrubbed in place, never hard-deleted.
+//
+// The erasure capability already exists and is the only correct home: `eraseSubjectAsSystem` /
+// `eraseSubjectInPlace` walk every dependent edge, derive delete-vs-retain from each edge's own
+// `onParentDelete` declaration, fail closed on unclassified edges, and return a
+// `SubjectErasureReport`. Like the four export/portability verbs removed the same day, they
+// **deliberately ship with NO ROUTE** — data-subject rights are a system-level API, not a
+// self-service HTTP verb. `dataExportUrl` compounded this: it named the portability artifact that
+// removal established does not exist.
+//
+// Do NOT re-declare this as a resource operation. Voluntary self-service closure is
+// `DEACTIVATE_ACCOUNT` below; actual erasure runs through the compliance capability. If a product
+// ever needs a user-initiated erasure REQUEST, it is a scheduling verb over a persisted
+// request state (with its own cancel path and a batch that calls `eraseSubjectAsSystem`) — not a
+// routed DELETE, and not something the generic core delete can express.
+// See `.claude/plans/routed-unimplemented-operations-fail-closed.md`.
+//
+// assurance-control: WILDO.DATA.SECURE_LIFECYCLE — a destructive identity operation
+// must verify the principal and leave evidence; erasure must honour the declared retention mode.
 export var UserSelf_Operations;
 (function (UserSelf_Operations) {
-    UserSelf_Operations["UPDATE_PROFILE"] = "update_profile";
-    UserSelf_Operations["UPDATE_PREFERENCES"] = "update_preferences";
-    UserSelf_Operations["CHANGE_PASSWORD"] = "change_password";
-    UserSelf_Operations["DELETE_ACCOUNT"] = "delete_account";
-    UserSelf_Operations["EXPORT_DATA"] = "export_data";
     UserSelf_Operations["DEACTIVATE_ACCOUNT"] = "deactivate_account";
     UserSelf_Operations["REACTIVATE_ACCOUNT"] = "reactivate_account";
 })(UserSelf_Operations || (UserSelf_Operations = {}));
@@ -33,9 +117,61 @@ export const userSelfResourceConfiguration_InitializationFactory = (resourcesRel
     resourceFieldIdentifier: coreResourceShared_FieldIdentifier[CoreResourceType.USER_SELF],
     resourceRelationships: resourcesRelationships,
     isSystemResource: true, // Self-scoped
+    /**
+     * `/user-self/{userId}` names the CALLER. Declared EXPLICITLY even though `true` is the default,
+     * because the sibling `USERS` configuration — over the SAME collection, with the SAME
+     * `resourceFieldIdentifier` — declares `false`, and a reader comparing the two must be able to see
+     * that the difference is intentional rather than an omission.
+     *
+     * This is the value that keeps the horizontal-IDOR refusal alive: user A addressing user B's
+     * self row is refused `403 authorization_user_id_mismatch` by the identity-coherence guard. Pinned
+     * by `external-access-auth.e2e.ts` (M4) and `users-administration.e2e.ts` (U-11). Flipping this to
+     * `false` would open that hole silently — nothing downstream would catch it, because the addressed
+     * id still reaches the contextual filter and would scope the read to B.
+     */
+    primaryKeyIdentifiesInitiator: true,
+    /**
+     * ⚠️ MUST MIRROR `USERS`. This config and `USERS` are two doors onto the SAME rows: they share
+     * `UserSchema` above and, per `getCollectionNameForResource` in the zod→mongoose convertor,
+     * `USER_SELF` builds a SEPARATE Mongoose model over the `USERS` COLLECTION.
+     *
+     * Retention governance is per-resource-config, so a `USERS`-only opt-in would leave two holes on
+     * these shared rows:
+     *  - an ERASED user's row would stay READABLE and UPDATABLE through this door, whose READ/UPDATE
+     *    are open to `APP_USER` and would carry neither the retention hide filter nor the freeze;
+     *  - this model would emit a PLAIN unique index on `email` next to the `USERS` model's
+     *    retention-scoped one, so the SECOND erased user would collide (E11000) on the shared mask
+     *    address and abort the erasure.
+     *
+     * Declaring the same mode makes both models inject the same marker and emit the identical partial
+     * index, so the collection has one coherent retention contract. Change the two configs together.
+     * The scrub treatment needs no restating — it lives on the shared `UserSchema`.
+     */
+    retentionPolicy: {
+        mode: ErasureRetentionMode.RETAIN_AND_IMPERSONALIZE,
+    },
+    /**
+     * Same subject as `USERS` over the same collection — the self-service door onto the identity row.
+     * Mirrors that config's `SELF_PRINCIPAL` declaration; the two must be changed together.
+     */
+    dataSubjectPolicy: { kind: ResourceDataSubjectKind.SELF_PRINCIPAL },
+    /**
+     * Subject-export disclosure. The self-service export subject. The identity row is what the user signed up with.
+     */
+    systemAccessPolicy: { exportSubject: ResourceSystemAccessMode.ALLOWED },
+    /**
+     * Subject-export disclosure. The self-service export subject. The identity row is what the user signed up with.
+     */
+    portabilityPolicy: { defaultProvenance: DataPortabilityProvenance.SUBJECT_PROVIDED },
     coreOperations: [
         CoreResourceOperation.READ,
+        // LIST + UPDATE_MANY exist for the retention capability ONLY, as INTERNAL_CALL variants that
+        // register no route: `retentionPolicy` requires UPDATE_MANY (the in-place scrub via
+        // `updateManyAsSystem`) plus READ + LIST (the audited see-through read of retained rows). There
+        // is deliberately no HTTP "list my selves" — see the variants below.
+        CoreResourceOperation.LIST,
         CoreResourceOperation.UPDATE,
+        CoreResourceOperation.UPDATE_MANY,
     ],
     customOperation: UserSelf_Operations,
     operationsConfiguration: {
@@ -50,50 +186,64 @@ export const userSelfResourceConfiguration_InitializationFactory = (resourcesRel
                 }
             ]
         },
-        [CoreResourceOperation.UPDATE]: {
+        [CoreResourceOperation.LIST]: {
             variants: [
                 {
-                    variantType: ResourceOperationVariantType.API_CALL,
+                    // Retention capability only — INTERNAL_CALL registers NO HTTP route. A user-facing
+                    // "list my selves" would be meaningless (this resource is addressed as the caller's own
+                    // row); the op exists solely so `listRetainedAsSystem` has a read path through which a
+                    // compliance auditor can see-through to retained rows on this collection.
+                    //
+                    // ⚠️ INTERNAL_CALL, *not* REPOSITORY_ONLY — see the UPDATE_MANY note below for why the
+                    // distinction is load-bearing. `roles` is inert on a non-URL-bearing variant.
+                    variantType: ResourceOperationVariantType.INTERNAL_CALL,
                     isDefault: true,
-                    roles: [CORE_APP_ROLES.APP_USER], // v1: app-only, user modifying their data
-                    riskLevel: ResourceOperationRiskLevel.MEDIUM,
-                    // requestDto auto-derived from decorators
-                }
-            ],
-            userNotifications: [
-                {
-                    target: CoreUserNotificationTarget.USER_SELF,
-                    channel: CoreUserNotificationChannel.FRONT_END_SUCCESS,
-                }
-            ]
-        },
-        [UserSelf_Operations.UPDATE_PROFILE]: {
-            variants: [
-                {
-                    variantType: ResourceOperationVariantType.API_CALL,
-                    isDefault: true,
-                    roles: [CORE_APP_ROLES.APP_USER], // v1: app-only, low risk
+                    roles: [CORE_APP_ROLES.APP_USER],
                     riskLevel: ResourceOperationRiskLevel.LOW,
-                    resourceOperationLike: CoreResourceOperation.UPDATE,
-                    requestDto: UserProfileSchema.partial(),
-                }
-            ],
-            userNotifications: [
-                {
-                    target: CoreUserNotificationTarget.USER_SELF,
-                    channel: CoreUserNotificationChannel.FRONT_END_SUCCESS,
                 }
             ]
         },
-        [UserSelf_Operations.UPDATE_PREFERENCES]: {
+        [CoreResourceOperation.UPDATE]: {
             variants: [
                 {
-                    variantType: ResourceOperationVariantType.API_CALL,
+                    // ⚠️ INTERNAL_CALL — registers NO HTTP route. This was an `API_CALL` open to
+                    // `APP_USER` with an auto-derived request DTO, and on THIS resource the auto-derived
+                    // user update DTO is `{status, appRoles, userTypes}`: every writable field on the
+                    // `USER_SELF` row is server-owned. `email` is `.excludeFromUpdate()` and the editable
+                    // self data (names, avatar, bio, phone / notification + UI preferences) lives on the
+                    // `USER_SELF_PROFILES` and `USER_SELF_PREFERENCES` child resources, which is where the
+                    // UI actually writes it. So the route offered a self-service caller nothing legitimate
+                    // and three things it must never set:
+                    //
+                    //   - `appRoles`  — the app-level authorization axis. No ceiling gate exists on this
+                    //     path (`assertRequestedRolesWithinCallerCeiling` is wired into org-member CREATE,
+                    //     org-unit-members, oauth-clients and api-keys only, and no custom implementation is
+                    //     registered for `USERS` / `USER_SELF`), so a plain authenticated user could grant
+                    //     themselves any role, up to `APP_ADMIN_SUPER_ADMIN`.
+                    //   - `userTypes` — selects auth policy and registration context.
+                    //   - `status`    — the account lifecycle axis, which belongs to the dedicated
+                    //     DEACTIVATE_ACCOUNT / REACTIVATE_ACCOUNT transitions below (and to the admin
+                    //     SUSPEND_USER / UNSUSPEND_USER verbs on the `USERS` door). A self-service caller
+                    //     flipping it directly bypasses every state gate those verbs declare.
+                    //
+                    // Narrowing `requestDto` would have left the route in place answering an empty write;
+                    // removing the HTTP surface is the honest fix, because no caller wants it. Verified
+                    // before the change: the engine presets surface no `UPDATE` action for `USER_SELF`
+                    // (self edits go to the child resources), and no backend caller invokes `USER_SELF`
+                    // update — the trusted internal door for user rows is `USERS`.
+                    //
+                    // The operation itself is KEPT (not dropped from `coreOperations`) because the custom
+                    // self verbs borrow it through `resourceOperationLike: UPDATE`, and INTERNAL_CALL is
+                    // the resource's established idiom for a route-less operation — see `LIST` and
+                    // `UPDATE_MANY` above/below, and the note there on why INTERNAL_CALL rather than
+                    // REPOSITORY_ONLY. `roles` is inert on a non-URL-bearing variant.
+                    //
+                    // assurance-control: WILDO.ACCESS.LEAST_PRIVILEGE — a self-service surface
+                    // must not be a privilege-assignment or lifecycle-override surface.
+                    variantType: ResourceOperationVariantType.INTERNAL_CALL,
                     isDefault: true,
-                    roles: [CORE_APP_ROLES.APP_USER], // v1: app-only, low risk
-                    riskLevel: ResourceOperationRiskLevel.LOW,
-                    resourceOperationLike: CoreResourceOperation.UPDATE,
-                    requestDto: UserPreferencesSchema.partial(),
+                    roles: [CORE_APP_ROLES.APP_USER],
+                    riskLevel: ResourceOperationRiskLevel.MEDIUM,
                 }
             ],
             userNotifications: [
@@ -103,86 +253,34 @@ export const userSelfResourceConfiguration_InitializationFactory = (resourcesRel
                 }
             ]
         },
-        [UserSelf_Operations.CHANGE_PASSWORD]: {
+        [CoreResourceOperation.UPDATE_MANY]: {
             variants: [
                 {
-                    variantType: ResourceOperationVariantType.API_CALL,
+                    // Retention capability only — INTERNAL_CALL registers NO HTTP route. Required by
+                    // `retentionPolicy` because the impersonalize writer scrubs in place through
+                    // `updateManyAsSystem`. A user bulk-updating rows through the self door would be
+                    // nonsensical AND dangerous, so the only caller is the trusted system writer.
+                    //
+                    // ⚠️ INTERNAL_CALL, *not* REPOSITORY_ONLY. Both are route-less, but the three retention
+                    // primitives (`updateManyAsSystem`, `readRetainedAsSystem`, `listRetainedAsSystem`) resolve
+                    // through `getServiceOperationPathDefault`, which matches only INTERNAL_CALL / API_CALL /
+                    // API_CALL_WITH_CALLBACK — REPOSITORY_ONLY is excluded there and served by the separate
+                    // `getRepositoryOperationPathDefault` transport. A REPOSITORY_ONLY variant would satisfy the
+                    // factory's boot guard and then FAIL TO RESOLVE when an erasure actually runs. `roles` is inert
+                    // on a non-URL-bearing variant; the real gate is the derived `systemAccessPolicy` grant.
+                    variantType: ResourceOperationVariantType.INTERNAL_CALL,
                     isDefault: true,
-                    roles: [CORE_APP_ROLES.APP_USER], // v1: app-only, high risk - authentication change
-                    riskLevel: ResourceOperationRiskLevel.HIGH,
-                    resourceOperationLike: CoreResourceOperation.UPDATE,
-                    requestDto: z.object({
-                        currentPassword: z.string().min(1),
-                        newPassword: z.string().min(8),
-                        confirmPassword: z.string().min(1)
-                    }).refine((data) => data.newPassword === data.confirmPassword, {
-                        message: "Passwords don't match",
-                        path: ["confirmPassword"]
-                    }),
-                }
-            ],
-            userNotifications: [
-                {
-                    target: CoreUserNotificationTarget.USER_SELF,
-                    channel: CoreUserNotificationChannel.EMAIL,
-                }
-            ]
-        },
-        [UserSelf_Operations.DELETE_ACCOUNT]: {
-            variants: [
-                {
-                    variantType: ResourceOperationVariantType.API_CALL,
-                    isDefault: true,
-                    roles: [CORE_APP_ROLES.APP_USER], // v1: app-only, critical risk - permanent action
+                    roles: [CORE_APP_ROLES.APP_USER],
                     riskLevel: ResourceOperationRiskLevel.CRITICAL,
-                    resourceOperationLike: CoreResourceOperation.DELETE,
-                    requestDto: z.object({
-                        password: z.string().min(1),
-                        reason: z.string().max(500).optional()
-                    }),
-                    customResponseDto: z.object({
-                        scheduledDeletionDate: z.date(),
-                        recoveryPeriodDays: z.number(),
-                        dataExportUrl: z.url().optional()
-                    }),
-                }
-            ],
-            userNotifications: [
-                {
-                    target: CoreUserNotificationTarget.USER_SELF,
-                    channel: CoreUserNotificationChannel.EMAIL,
-                }
-            ]
-        },
-        [UserSelf_Operations.EXPORT_DATA]: {
-            variants: [
-                {
-                    variantType: ResourceOperationVariantType.API_CALL,
-                    isDefault: true,
-                    roles: [CORE_APP_ROLES.APP_USER], // v1: app-only, low risk
-                    riskLevel: ResourceOperationRiskLevel.LOW,
-                    resourceOperationLike: CoreResourceOperation.READ,
-                    requestDto: z.object({
-                        format: z.enum(['json', 'csv']).default('json'),
-                        includePersonalData: z.boolean().default(true),
-                        includeActivityData: z.boolean().default(true),
-                        includeOrganizationData: z.boolean().default(false)
-                    }),
-                    customResponseDto: z.object({
-                        downloadUrl: z.url(),
-                        expiresAt: z.date(),
-                        fileSize: z.number(),
-                        recordCount: z.number()
-                    }),
                 }
             ],
-            userNotifications: [
-                {
-                    target: CoreUserNotificationTarget.USER_SELF,
-                    channel: CoreUserNotificationChannel.EMAIL,
-                }
-            ]
         },
+        // Profile / preferences writes ride the dedicated `USER_SELF_PROFILES` and
+        // `USER_SELF_PREFERENCES` resources — the `UPDATE_PROFILE` / `UPDATE_PREFERENCES` verbs were
+        // removed on 2026-08-01 (they declared another resource's schema, so they answered 200 having
+        // persisted nothing). Self-service account DELETION was removed the same day: erasure is a
+        // system-level API with no route, and a hard delete contradicted the `retentionPolicy` above.
+        // Both removals are explained in the enum comment.
         [UserSelf_Operations.DEACTIVATE_ACCOUNT]: {
             variants: [
                 {
@@ -191,9 +289,35 @@ export const userSelfResourceConfiguration_InitializationFactory = (resourcesRel
                     roles: [CORE_APP_ROLES.APP_USER], // v1: app-only, high risk - affects access
                     riskLevel: ResourceOperationRiskLevel.HIGH,
                     resourceOperationLike: CoreResourceOperation.UPDATE,
+                    // Implemented by the shared status-transition factory (ACTIVE → INACTIVE). INACTIVE, not
+                    // SUSPENDED: the distinction is the point — SUSPENDED is imposed and only an admin lifts
+                    // it, while INACTIVE is chosen and the user lifts it themselves via REACTIVATE_ACCOUNT.
+                    // NO `reactivationDate`. It was declared here and persisted to
+                    // `User.scheduledReactivationAt`, but nothing could ever honour it: the reactivation sweep
+                    // dispatches each resource's own lifecycle verb, and the only verb that lifts `INACTIVE`
+                    // is REACTIVATE_ACCOUNT below — self-scoped and `APP_USER`-gated, so a system principal
+                    // cannot address another person's row through it.
+                    //
+                    // The two ways to make it work were both worse than the gap. Widening
+                    // `users | unsuspend_user` to accept `INACTIVE` merges an IMPOSED suspension with a CHOSEN
+                    // deactivation into one verb — two states whose whole distinction is who may lift them.
+                    // And `admitsCrossSubjectUserAdministration` (the framework's per-variant "this verb
+                    // administers another person" opt-in) relaxes WHOSE row may be addressed but never WHO may
+                    // call, so putting it on an `APP_USER` verb would let any authenticated user reactivate
+                    // anyone's account.
+                    //
+                    // Minting a new admin-tier reactivation verb purely to give the sweep a door would
+                    // manufacture a routed surface nobody asked for — the exact pattern this workstream
+                    // removed six times over. Voluntary deactivation is reversible by its subject at any time
+                    // through REACTIVATE_ACCOUNT, so a scheduled auto-return was a convenience, not a promise
+                    // the product makes anywhere else.
+                    //
+                    // Note the ADMIN time-boxing is unaffected and IS honoured: `users | suspend_user` takes
+                    // `suspensionDuration` and the hourly sweep lifts it, because `unsuspend_user` is a door a
+                    // system principal can dispatch. That is the case that actually matters — an operator who
+                    // said "seven days" must get seven days.
                     requestDto: z.object({
                         reason: z.string().max(500).optional(),
-                        reactivationDate: z.date().optional() // Auto-reactivate at specific date
                     }),
                     enabledCondition: ({ currentObject }) => {
                         return currentObject.status === UserStatus.ACTIVE;
@@ -215,6 +339,30 @@ export const userSelfResourceConfiguration_InitializationFactory = (resourcesRel
                     roles: [CORE_APP_ROLES.APP_USER], // v1: app-only, medium risk
                     riskLevel: ResourceOperationRiskLevel.MEDIUM,
                     resourceOperationLike: CoreResourceOperation.UPDATE,
+                    // Self-service reactivation FORCES the one transition it names. Omitting
+                    // `requestDto` would auto-derive the FULL user update DTO — which on this resource
+                    // is `{status, appRoles, userTypes}` — so an end-user-facing verb would accept its
+                    // own `appRoles` and `userTypes`, with no ceiling gate anywhere on the path
+                    // (`assertRequestedRolesWithinCallerCeiling` is not called here). Narrowing to an
+                    // empty contract removes the role surface entirely, which is why this needs no
+                    // ceiling call.
+                    // assurance-control: WILDO.ACCESS.LEAST_PRIVILEGE — a self-service verb must not be a
+                    // role-assignment surface.
+                    requestDto: z.object({}),
+                    // The transition itself is implemented by the SHARED status-transition factory, like its
+                    // inverse DEACTIVATE_ACCOUNT above — not by a `basicPrefixOperation` here.
+                    //
+                    // It used to be the hook, and the asymmetry cost three things: the pending
+                    // `scheduledReactivationAt` was never cleared (leaving a date on an ACTIVE row that no
+                    // longer described anything), no transition audit row was emitted (so the self-service
+                    // pair was half-trailed — the departure recorded, the return not), and the
+                    // administrative-continuity floors did not run. Harmless individually, but it made the
+                    // one lifecycle verb in the family that bypassed the shared authority the one nobody
+                    // would think to check.
+                    //
+                    // The factory's registration declares `authoritativeFields: ['status',
+                    // 'scheduledReactivationAt']`, which is what carries the patch past the repository's
+                    // strict re-parse — the protection the hook's own declaration used to provide.
                     enabledCondition: ({ currentObject }) => {
                         return currentObject.status === UserStatus.INACTIVE;
                     }
@@ -229,4 +377,4 @@ export const userSelfResourceConfiguration_InitializationFactory = (resourcesRel
         }
     },
 });
-//# sourceMappingURL=user-self.shared.resources-config.schemas.js.map
+//# sourceMappingURL=user-self.shared.resources-config.schemas.js.map

package/dist/esm/users/user-self.shared.resources-config.schemas.js.map

@@ -1 +1 @@
-{"version":3,"file":"user-self.shared.resources-config.schemas.js","sourceRoot":"","sources":["../../../src/users/user-self.shared.resources-config.schemas.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AAEH,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AACxB,OAAO,EACL,UAAU,EACV,iBAAiB,EACjB,qBAAqB,EACrB,UAAU,EAEX,MAAM,wBAAwB,CAAC;AAChC,OAAO,EAAE,qBAAqB,EAAE,MAAM,gDAAgD,CAAC;AACvF,OAAO,EAAE,0BAA0B,EAAwB,MAAM,uCAAuC,CAAC;AACzG,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;AAE1G,OAAO,EAAE,cAAc,EAAE,MAAM,iDAAiD,CAAC;AAEjF,kDAAkD;AAClD,MAAM,CAAN,IAAY,mBAQX;AARD,WAAY,mBAAmB;IAC7B,wDAAiC,CAAA;IACjC,gEAAyC,CAAA;IACzC,0DAAmC,CAAA;IACnC,wDAAiC,CAAA;IACjC,kDAA2B,CAAA;IAC3B,gEAAyC,CAAA;IACzC,gEAAyC,CAAA;AAC3C,CAAC,EARW,mBAAmB,KAAnB,mBAAmB,QAQ9B;AAMD;;EAEE;AACF,MAAM,CAAC,MAAM,mDAAmD,GAAG,CAAC,sBAA8C,EAAE,EAAE,CAAC,0CAA0C,CAI/J;IACA,UAAU,EAAE,UAAU;IACtB,kBAAkB,EAAE,gBAAgB,CAAC,SAAS;IAC9C,uBAAuB,EAAE,kCAAkC,CAAC,gBAAgB,CAAC,SAAS,CAAC;IACvF,qBAAqB,EAAE,sBAAsB;IAC7C,gBAAgB,EAAE,IAAI,EAAE,cAAc;IAEtC,cAAc,EAAE;QACd,qBAAqB,CAAC,IAAI;QAC1B,qBAAqB,CAAC,MAAM;KAC7B;IAED,eAAe,EAAE,mBAAmB;IAGpC,uBAAuB,EAAE;QACvB,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,QAAQ,CAAC,EAAE,4CAA4C;oBAC9E,SAAS,EAAE,0BAA0B,CAAC,GAAG;oBACzC,+CAA+C;iBAChD;aACF;SACF;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,QAAQ,CAAC,EAAE,0CAA0C;oBAC5E,SAAS,EAAE,0BAA0B,CAAC,MAAM;oBAC5C,0CAA0C;iBAC3C;aACF;YACD,iBAAiB,EAAE;gBACjB;oBACE,MAAM,EAAE,0BAA0B,CAAC,SAAS;oBAC5C,OAAO,EAAE,2BAA2B,CAAC,iBAAiB;iBACvD;aACF;SACF;QAED,CAAC,mBAAmB,CAAC,cAAc,CAAC,EAAE;YACpC,QAAQ,EAAE;gBACR;oBACE,WAAW,EAAE,4BAA4B,CAAC,QAAQ;oBAClD,SAAS,EAAE,IAAI;oBACf,KAAK,EAAE,CAAC,cAAc,CAAC,QAAQ,CAAC,EAAE,yBAAyB;oBAC3D,SAAS,EAAE,0BAA0B,CAAC,GAAG;oBACzC,qBAAqB,EAAE,qBAAqB,CAAC,MAAM;oBACnD,UAAU,EAAE,iBAAiB,CAAC,OAAO,EAAE;iBACxC;aACF;YACD,iBAAiB,EAAE;gBACjB;oBACE,MAAM,EAAE,0BAA0B,CAAC,SAAS;oBAC5C,OAAO,EAAE,2BAA2B,CAAC,iBAAiB;iBACvD;aACF;SACF;QAED,CAAC,mBAAmB,CAAC,kBAAkB,CAAC,EAAE;YACxC,QAAQ,EAAE;gBACR;oBACE,WAAW,EAAE,4BAA4B,CAAC,QAAQ;oBAClD,SAAS,EAAE,IAAI;oBACf,KAAK,EAAE,CAAC,cAAc,CAAC,QAAQ,CAAC,EAAE,yBAAyB;oBAC3D,SAAS,EAAE,0BAA0B,CAAC,GAAG;oBACzC,qBAAqB,EAAE,qBAAqB,CAAC,MAAM;oBACnD,UAAU,EAAE,qBAAqB,CAAC,OAAO,EAAE;iBAC5C;aACF;YACD,iBAAiB,EAAE;gBACjB;oBACE,MAAM,EAAE,0BAA0B,CAAC,SAAS;oBAC5C,OAAO,EAAE,2BAA2B,CAAC,iBAAiB;iBACvD;aACF;SACF;QAED,CAAC,mBAAmB,CAAC,eAAe,CAAC,EAAE;YACrC,QAAQ,EAAE;gBACR;oBACE,WAAW,EAAE,4BAA4B,CAAC,QAAQ;oBAClD,SAAS,EAAE,IAAI;oBACf,KAAK,EAAE,CAAC,cAAc,CAAC,QAAQ,CAAC,EAAE,kDAAkD;oBACpF,SAAS,EAAE,0BAA0B,CAAC,IAAI;oBAC1C,qBAAqB,EAAE,qBAAqB,CAAC,MAAM;oBACnD,UAAU,EAAE,CAAC,CAAC,MAAM,CAAC;wBACnB,eAAe,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC;wBAClC,WAAW,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC;wBAC9B,eAAe,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC;qBACnC,CAAC,CAAC,MAAM,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,IAAI,CAAC,WAAW,KAAK,IAAI,CAAC,eAAe,EAAE;wBAC7D,OAAO,EAAE,uBAAuB;wBAChC,IAAI,EAAE,CAAC,iBAAiB,CAAC;qBAC1B,CAAC;iBACH;aACF;YACD,iBAAiB,EAAE;gBACjB;oBACE,MAAM,EAAE,0BAA0B,CAAC,SAAS;oBAC5C,OAAO,EAAE,2BAA2B,CAAC,KAAK;iBAC3C;aACF;SACF;QAED,CAAC,mBAAmB,CAAC,cAAc,CAAC,EAAE;YACpC,QAAQ,EAAE;gBACR;oBACE,WAAW,EAAE,4BAA4B,CAAC,QAAQ;oBAClD,SAAS,EAAE,IAAI;oBACf,KAAK,EAAE,CAAC,cAAc,CAAC,QAAQ,CAAC,EAAE,iDAAiD;oBACnF,SAAS,EAAE,0BAA0B,CAAC,QAAQ;oBAC9C,qBAAqB,EAAE,qBAAqB,CAAC,MAAM;oBACnD,UAAU,EAAE,CAAC,CAAC,MAAM,CAAC;wBACnB,QAAQ,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC;wBAC3B,MAAM,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,GAAG,CAAC,CAAC,QAAQ,EAAE;qBACvC,CAAC;oBACF,iBAAiB,EAAE,CAAC,CAAC,MAAM,CAAC;wBAC1B,qBAAqB,EAAE,CAAC,CAAC,IAAI,EAAE;wBAC/B,kBAAkB,EAAE,CAAC,CAAC,MAAM,EAAE;wBAC9B,aAAa,EAAE,CAAC,CAAC,GAAG,EAAE,CAAC,QAAQ,EAAE;qBAClC,CAAC;iBACH;aACF;YACD,iBAAiB,EAAE;gBACjB;oBACE,MAAM,EAAE,0BAA0B,CAAC,SAAS;oBAC5C,OAAO,EAAE,2BAA2B,CAAC,KAAK;iBAC3C;aACF;SACF;QAED,CAAC,mBAAmB,CAAC,WAAW,CAAC,EAAE;YACjC,QAAQ,EAAE;gBACR;oBACE,WAAW,EAAE,4BAA4B,CAAC,QAAQ;oBAClD,SAAS,EAAE,IAAI;oBACf,KAAK,EAAE,CAAC,cAAc,CAAC,QAAQ,CAAC,EAAE,yBAAyB;oBAC3D,SAAS,EAAE,0BAA0B,CAAC,GAAG;oBACzC,qBAAqB,EAAE,qBAAqB,CAAC,IAAI;oBACjD,UAAU,EAAE,CAAC,CAAC,MAAM,CAAC;wBACnB,MAAM,EAAE,CAAC,CAAC,IAAI,CAAC,CAAC,MAAM,EAAE,KAAK,CAAC,CAAC,CAAC,OAAO,CAAC,MAAM,CAAC;wBAC/C,mBAAmB,EAAE,CAAC,CAAC,OAAO,EAAE,CAAC,OAAO,CAAC,IAAI,CAAC;wBAC9C,mBAAmB,EAAE,CAAC,CAAC,OAAO,EAAE,CAAC,OAAO,CAAC,IAAI,CAAC;wBAC9C,uBAAuB,EAAE,CAAC,CAAC,OAAO,EAAE,CAAC,OAAO,CAAC,KAAK,CAAC;qBACpD,CAAC;oBACF,iBAAiB,EAAE,CAAC,CAAC,MAAM,CAAC;wBAC1B,WAAW,EAAE,CAAC,CAAC,GAAG,EAAE;wBACpB,SAAS,EAAE,CAAC,CAAC,IAAI,EAAE;wBACnB,QAAQ,EAAE,CAAC,CAAC,MAAM,EAAE;wBACpB,WAAW,EAAE,CAAC,CAAC,MAAM,EAAE;qBACxB,CAAC;iBACH;aACF;YACD,iBAAiB,EAAE;gBACjB;oBACE,MAAM,EAAE,0BAA0B,CAAC,SAAS;oBAC5C,OAAO,EAAE,2BAA2B,CAAC,KAAK;iBAC3C;aACF;SACF;QAED,CAAC,mBAAmB,CAAC,kBAAkB,CAAC,EAAE;YACxC,QAAQ,EAAE;gBACR;oBACE,WAAW,EAAE,4BAA4B,CAAC,QAAQ;oBAClD,SAAS,EAAE,IAAI;oBACf,KAAK,EAAE,CAAC,cAAc,CAAC,QAAQ,CAAC,EAAE,2CAA2C;oBAC7E,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;wBACtC,gBAAgB,EAAE,CAAC,CAAC,IAAI,EAAE,CAAC,QAAQ,EAAE,CAAC,mCAAmC;qBAC1E,CAAC;oBACF,gBAAgB,EAAE,CAAC,EAAE,aAAa,EAAE,EAAE,EAAE;wBACtC,OAAO,aAAa,CAAC,MAAM,KAAK,UAAU,CAAC,MAAM,CAAC;oBACpD,CAAC;iBACF;aACF;YACD,iBAAiB,EAAE;gBACjB;oBACE,MAAM,EAAE,0BAA0B,CAAC,SAAS;oBAC5C,OAAO,EAAE,2BAA2B,CAAC,KAAK;iBAC3C;aACF;SACF;QAED,CAAC,mBAAmB,CAAC,kBAAkB,CAAC,EAAE;YACxC,QAAQ,EAAE;gBACR;oBACE,WAAW,EAAE,4BAA4B,CAAC,QAAQ;oBAClD,SAAS,EAAE,IAAI;oBACf,KAAK,EAAE,CAAC,cAAc,CAAC,QAAQ,CAAC,EAAE,4BAA4B;oBAC9D,SAAS,EAAE,0BAA0B,CAAC,MAAM;oBAC5C,qBAAqB,EAAE,qBAAqB,CAAC,MAAM;oBACnD,gBAAgB,EAAE,CAAC,EAAE,aAAa,EAAE,EAAE,EAAE;wBACtC,OAAO,aAAa,CAAC,MAAM,KAAK,UAAU,CAAC,QAAQ,CAAC;oBACtD,CAAC;iBACF;aACF;YACD,iBAAiB,EAAE;gBACjB;oBACE,MAAM,EAAE,0BAA0B,CAAC,SAAS;oBAC5C,OAAO,EAAE,2BAA2B,CAAC,KAAK;iBAC3C;aACF;SACF;KACF;CACF,CAAC,CAAC"}
+{"version":3,"file":"user-self.shared.resources-config.schemas.js","sourceRoot":"","sources":["../../../../src/users/user-self.shared.resources-config.schemas.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AAEH,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AACxB,OAAO,EAAE,UAAU,EAAE,UAAU,EAAE,MAAM,wBAAwB,CAAC;AAChE,OAAO,EAAE,qBAAqB,EAAE,MAAM,gDAAgD,CAAC;AACvF,OAAO,EAAE,0BAA0B,EAAwB,MAAM,uCAAuC,CAAC;AACzG,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,oBAAoB,EAAE,uBAAuB,EAAE,MAAM,wDAAwD,CAAC;AAEvH,OAAO,EAAE,cAAc,EAAE,MAAM,iDAAiD,CAAC;AACjF,OAAO,EAAE,wBAAwB,EAAE,MAAM,8CAA8C,CAAC;AACxF,OAAO,EAAE,yBAAyB,EAAE,MAAM,qDAAqD,CAAC;AAEhG,kDAAkD;AAClD,EAAE;AACF,2FAA2F;AAC3F,0EAA0E;AAC1E,6FAA6F;AAC7F,8FAA8F;AAC9F,4FAA4F;AAC5F,iGAAiG;AACjG,6EAA6E;AAC7E,EAAE;AACF,8EAA8E;AAC9E,4FAA4F;AAC5F,0FAA0F;AAC1F,2FAA2F;AAC3F,wFAAwF;AACxF,4FAA4F;AAC5F,8EAA8E;AAC9E,qDAAqD;AACrD,EAAE;AACF,gGAAgG;AAChG,kGAAkG;AAClG,+EAA+E;AAC/E,sEAAsE;AACtE,EAAE;AACF,kGAAkG;AAClG,oGAAoG;AACpG,kGAAkG;AAClG,qGAAqG;AACrG,oGAAoG;AACpG,oGAAoG;AACpG,oFAAoF;AACpF,EAAE;AACF,iGAAiG;AACjG,+FAA+F;AAC/F,kGAAkG;AAClG,mGAAmG;AACnG,mGAAmG;AACnG,SAAS;AACT,oGAAoG;AACpG,EAAE;AACF,+FAA+F;AAC/F,iGAAiG;AACjG,kGAAkG;AAClG,yDAAyD;AACzD,EAAE;AACF,mGAAmG;AACnG,+FAA+F;AAC/F,6EAA6E;AAC7E,mGAAmG;AACnG,2EAA2E;AAC3E,EAAE;AACF,mGAAmG;AACnG,iGAAiG;AACjG,8FAA8F;AAC9F,+FAA+F;AAC/F,uBAAuB;AACvB,mGAAmG;AACnG,iGAAiG;AACjG,oFAAoF;AACpF,oGAAoG;AACpG,uDAAuD;AACvD,+FAA+F;AAC/F,kGAAkG;AAClG,2FAA2F;AAC3F,oGAAoG;AACpG,oGAAoG;AACpG,+EAA+E;AAC/E,mGAAmG;AACnG,oGAAoG;AACpG,EAAE;AACF,+FAA+F;AAC/F,gGAAgG;AAChG,gFAAgF;AAChF,4FAA4F;AAC5F,0FAA0F;AAC1F,kGAAkG;AAClG,sCAAsC;AACtC,EAAE;AACF,oFAAoF;AACpF,kGAAkG;AAClG,wFAAwF;AACxF,iGAAiG;AACjG,wEAAwE;AACxE,sEAAsE;AACtE,EAAE;AACF,oFAAoF;AACpF,iGAAiG;AACjG,MAAM,CAAN,IAAY,mBAGX;AAHD,WAAY,mBAAmB;IAC7B,gEAAyC,CAAA;IACzC,gEAAyC,CAAA;AAC3C,CAAC,EAHW,mBAAmB,KAAnB,mBAAmB,QAG9B;AAQD;;EAEE;AACF,MAAM,CAAC,MAAM,mDAAmD,GAAG,CAAC,sBAA8C,EAAE,EAAE,CAAC,0CAA0C,CAI/J;IACA,UAAU,EAAE,UAAU;IACtB,kBAAkB,EAAE,gBAAgB,CAAC,SAAS;IAC9C,uBAAuB,EAAE,kCAAkC,CAAC,gBAAgB,CAAC,SAAS,CAAC;IACvF,qBAAqB,EAAE,sBAAsB;IAC7C,gBAAgB,EAAE,IAAI,EAAE,cAAc;IAEtC;;;;;;;;;;;OAWG;IACH,6BAA6B,EAAE,IAAI;IAEnC;;;;;;;;;;;;;;;;OAgBG;IACH,eAAe,EAAE;QACf,IAAI,EAAE,oBAAoB,CAAC,wBAAwB;KACpD;IAED;;;OAGG;IACH,iBAAiB,EAAE,EAAE,IAAI,EAAE,uBAAuB,CAAC,cAAc,EAAE;IAEnE;;OAEG;IACH,kBAAkB,EAAE,EAAE,aAAa,EAAE,wBAAwB,CAAC,OAAO,EAAE;IAEvE;;OAEG;IACH,iBAAiB,EAAE,EAAE,iBAAiB,EAAE,yBAAyB,CAAC,gBAAgB,EAAE;IAEpF,cAAc,EAAE;QACd,qBAAqB,CAAC,IAAI;QAC1B,6FAA6F;QAC7F,oFAAoF;QACpF,gGAAgG;QAChG,qEAAqE;QACrE,qBAAqB,CAAC,IAAI;QAC1B,qBAAqB,CAAC,MAAM;QAC5B,qBAAqB,CAAC,WAAW;KAClC;IAED,eAAe,EAAE,mBAAmB;IAGpC,uBAAuB,EAAE;QACvB,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,QAAQ,CAAC,EAAE,4CAA4C;oBAC9E,SAAS,EAAE,0BAA0B,CAAC,GAAG;oBACzC,+CAA+C;iBAChD;aACF;SACF;QAED,CAAC,qBAAqB,CAAC,IAAI,CAAC,EAAE;YAC5B,QAAQ,EAAE;gBACR;oBACE,mFAAmF;oBACnF,wFAAwF;oBACxF,uFAAuF;oBACvF,0EAA0E;oBAC1E,EAAE;oBACF,uFAAuF;oBACvF,8EAA8E;oBAC9E,WAAW,EAAE,4BAA4B,CAAC,aAAa;oBACvD,SAAS,EAAE,IAAI;oBACf,KAAK,EAAE,CAAC,cAAc,CAAC,QAAQ,CAAC;oBAChC,SAAS,EAAE,0BAA0B,CAAC,GAAG;iBAC1C;aACF;SACF;QAED,CAAC,qBAAqB,CAAC,MAAM,CAAC,EAAE;YAC9B,QAAQ,EAAE;gBACR;oBACE,6EAA6E;oBAC7E,qFAAqF;oBACrF,kFAAkF;oBAClF,sFAAsF;oBACtF,qFAAqF;oBACrF,uFAAuF;oBACvF,uFAAuF;oBACvF,sCAAsC;oBACtC,EAAE;oBACF,qFAAqF;oBACrF,uFAAuF;oBACvF,yFAAyF;oBACzF,uFAAuF;oBACvF,0DAA0D;oBAC1D,kEAAkE;oBAClE,+EAA+E;oBAC/E,kFAAkF;oBAClF,sFAAsF;oBACtF,0EAA0E;oBAC1E,EAAE;oBACF,sFAAsF;oBACtF,oFAAoF;oBACpF,mFAAmF;oBACnF,oFAAoF;oBACpF,+DAA+D;oBAC/D,EAAE;oBACF,sFAAsF;oBACtF,qFAAqF;oBACrF,+EAA+E;oBAC/E,iFAAiF;oBACjF,kEAAkE;oBAClE,EAAE;oBACF,2EAA2E;oBAC3E,oEAAoE;oBACpE,WAAW,EAAE,4BAA4B,CAAC,aAAa;oBACvD,SAAS,EAAE,IAAI;oBACf,KAAK,EAAE,CAAC,cAAc,CAAC,QAAQ,CAAC;oBAChC,SAAS,EAAE,0BAA0B,CAAC,MAAM;iBAC7C;aACF;YACD,iBAAiB,EAAE;gBACjB;oBACE,MAAM,EAAE,0BAA0B,CAAC,SAAS;oBAC5C,OAAO,EAAE,2BAA2B,CAAC,iBAAiB;iBACvD;aACF;SACF;QAED,CAAC,qBAAqB,CAAC,WAAW,CAAC,EAAE;YACnC,QAAQ,EAAE;gBACR;oBACE,iFAAiF;oBACjF,6EAA6E;oBAC7E,iFAAiF;oBACjF,8EAA8E;oBAC9E,EAAE;oBACF,wFAAwF;oBACxF,4FAA4F;oBAC5F,0FAA0F;oBAC1F,wFAAwF;oBACxF,6FAA6F;oBAC7F,gGAAgG;oBAChG,yFAAyF;oBACzF,WAAW,EAAE,4BAA4B,CAAC,aAAa;oBACvD,SAAS,EAAE,IAAI;oBACf,KAAK,EAAE,CAAC,cAAc,CAAC,QAAQ,CAAC;oBAChC,SAAS,EAAE,0BAA0B,CAAC,QAAQ;iBAC/C;aACF;SACF;QAED,2EAA2E;QAC3E,6FAA6F;QAC7F,8FAA8F;QAC9F,2FAA2F;QAC3F,8FAA8F;QAC9F,mDAAmD;QACnD,CAAC,mBAAmB,CAAC,kBAAkB,CAAC,EAAE;YACxC,QAAQ,EAAE;gBACR;oBACE,WAAW,EAAE,4BAA4B,CAAC,QAAQ;oBAClD,SAAS,EAAE,IAAI;oBACf,KAAK,EAAE,CAAC,cAAc,CAAC,QAAQ,CAAC,EAAE,2CAA2C;oBAC7E,SAAS,EAAE,0BAA0B,CAAC,IAAI;oBAC1C,qBAAqB,EAAE,qBAAqB,CAAC,MAAM;oBACnD,yFAAyF;oBACzF,yFAAyF;oBACzF,wFAAwF;oBACxF,+DAA+D;oBAC/D,2FAA2F;oBAC3F,yFAAyF;oBACzF,wFAAwF;oBACxF,kDAAkD;oBAClD,EAAE;oBACF,sEAAsE;oBACtE,2FAA2F;oBAC3F,wFAAwF;oBACxF,qFAAqF;oBACrF,2FAA2F;oBAC3F,wFAAwF;oBACxF,oBAAoB;oBACpB,EAAE;oBACF,mFAAmF;oBACnF,oFAAoF;oBACpF,0FAA0F;oBAC1F,0FAA0F;oBAC1F,mCAAmC;oBACnC,EAAE;oBACF,yFAAyF;oBACzF,2FAA2F;oBAC3F,0FAA0F;oBAC1F,yCAAyC;oBACzC,UAAU,EAAE,CAAC,CAAC,MAAM,CAAC;wBACnB,MAAM,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,GAAG,CAAC,CAAC,QAAQ,EAAE;qBACvC,CAAC;oBACF,gBAAgB,EAAE,CAAC,EAAE,aAAa,EAAE,EAAE,EAAE;wBACtC,OAAO,aAAa,CAAC,MAAM,KAAK,UAAU,CAAC,MAAM,CAAC;oBACpD,CAAC;iBACF;aACF;YACD,iBAAiB,EAAE;gBACjB;oBACE,MAAM,EAAE,0BAA0B,CAAC,SAAS;oBAC5C,OAAO,EAAE,2BAA2B,CAAC,KAAK;iBAC3C;aACF;SACF;QAED,CAAC,mBAAmB,CAAC,kBAAkB,CAAC,EAAE;YACxC,QAAQ,EAAE;gBACR;oBACE,WAAW,EAAE,4BAA4B,CAAC,QAAQ;oBAClD,SAAS,EAAE,IAAI;oBACf,KAAK,EAAE,CAAC,cAAc,CAAC,QAAQ,CAAC,EAAE,4BAA4B;oBAC9D,SAAS,EAAE,0BAA0B,CAAC,MAAM;oBAC5C,qBAAqB,EAAE,qBAAqB,CAAC,MAAM;oBACnD,yEAAyE;oBACzE,mFAAmF;oBACnF,mFAAmF;oBACnF,4EAA4E;oBAC5E,kFAAkF;oBAClF,+EAA+E;oBAC/E,gBAAgB;oBAChB,sFAAsF;oBACtF,2BAA2B;oBAC3B,UAAU,EAAE,CAAC,CAAC,MAAM,CAAC,EAAE,CAAC;oBACxB,yFAAyF;oBACzF,2EAA2E;oBAC3E,EAAE;oBACF,2EAA2E;oBAC3E,uFAAuF;oBACvF,uFAAuF;oBACvF,2EAA2E;oBAC3E,uFAAuF;oBACvF,qFAAqF;oBACrF,wBAAwB;oBACxB,EAAE;oBACF,uEAAuE;oBACvE,qFAAqF;oBACrF,+EAA+E;oBAC/E,gBAAgB,EAAE,CAAC,EAAE,aAAa,EAAE,EAAE,EAAE;wBACtC,OAAO,aAAa,CAAC,MAAM,KAAK,UAAU,CAAC,QAAQ,CAAC;oBACtD,CAAC;iBACF;aACF;YACD,iBAAiB,EAAE;gBACjB;oBACE,MAAM,EAAE,0BAA0B,CAAC,SAAS;oBAC5C,OAAO,EAAE,2BAA2B,CAAC,KAAK;iBAC3C;aACF;SACF;KACF;CACF,CAAC,CAAC","sourcesContent":["/**\n * User Self Shared Resource Configuration\n *\n * Resource configuration for user self-management operations.\n * Handles profile management, preferences, and personal data operations.\n */\n\nimport { z } from 'zod';\nimport { UserSchema, UserStatus } from './users.shared.schemas';\nimport { CoreResourceOperation } from '../resources/resources.shared.core.definitions';\nimport { ResourceOperationRiskLevel, 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 { ErasureRetentionMode, ResourceDataSubjectKind } from '../compliance/privacy/impersonalization.shared.schemas';\n\nimport { CORE_APP_ROLES } from '../security/authorizations/roles.shared.schemas';\nimport { ResourceSystemAccessMode } from '../resources/resources-config.shared.schemas';\nimport { DataPortabilityProvenance } from '../compliance/privacy/subject-export.shared.schemas';\n\n// Custom operations enum for user self management\n//\n// PASSWORD CHANGE IS NOT A RESOURCE OPERATION — IT IS AN AUTH ROUTE. `CHANGE_PASSWORD` was\n// declared here as an `APP_USER`-gated `riskLevel: HIGH` operation taking\n// `{ currentPassword, newPassword, confirmPassword }`, and was removed on 2026-08-01: it was\n// ROUTED but never implemented, so the request fell through to the generic core UPDATE, which\n// persists only fields the resource schema declares. A password verifier is not one of them\n// (credentials are a separate store), so every call answered **HTTP 200 having changed nothing**\n// — the caller is told their password rotated while the old one still works.\n//\n// The real implementation already exists and is the ONLY correct home for it:\n// `POST /auth/password/change` → `AuthMethodManagementBackendService.changePassword`, which\n// verifies the current-password proof, applies the per-user-type password policy, hashes,\n// invalidates every refresh token for the user, and writes a `USER_PASSWORD_CHANGED` audit\n// record. It is rate-limited (5/min/IP) and parses its body with `z.strictObject` so an\n// identity field smuggled into the payload is rejected loudly rather than silently ignored.\n// The frontend already calls exactly that route (`AppPage_SecuritySettings` →\n// `getManualCallsHttpClient().passwordChange(...)`).\n//\n// Do NOT re-declare this as a resource operation. Beyond duplicating a solved problem, it would\n// route a plaintext credential through the generic resource-write pipeline (DTO parse, repository\n// projection, notification fan-out) that the auth route deliberately bypasses.\n// See `.claude/plans/routed-unimplemented-operations-fail-closed.md`.\n//\n// NOR ARE PROFILE / PREFERENCES WRITES — THEY BELONG TO THEIR OWN RESOURCES. `UPDATE_PROFILE` and\n// `UPDATE_PREFERENCES` were removed on 2026-08-01. Both ran `resourceOperationLike: UPDATE` against\n// THIS resource — whose `mainSchema` is the USER — while declaring the request DTO of a DIFFERENT\n// resource (`UserProfileSchema.partial()` / `UserPreferencesSchema.partial()`). A core UPDATE writes\n// only its own resource's row, so every declared field was dropped; the single intersecting key was\n// `_id`, which `ResourceOperationsHelper.cleanInputData` force-deletes before validation. The write\n// was therefore empty and the route answered **HTTP 200 having persisted nothing**.\n//\n// The persisted documents already have dedicated self-scoped resources, and they are already the\n// wired path: `USER_SELF_PROFILES` exposes READ/CREATE/UPDATE over its own `mainSchema`, while\n// `USER_SELF_PREFERENCES` exposes READ/UPDATE plus its selective reset operation over the eagerly\n// seeded preferences row. Both are embedded as child resources of this one in the frontend preset,\n// carry their own resource specifications, and — for preferences — are the MCP-exposed read/update\n// tools.\n// This resource's own specification already directed engineers there for \"the persisted documents\".\n//\n// Do NOT re-declare either verb here. A single `user_self`-rooted write across child resources\n// cannot be a core UPDATE at all; it would need a custom multi-resource implementation declaring\n// `transactionParticipants` — new machinery duplicating a path that already exists. Route clients\n// to `userSelfProfiles` / `userSelfPreferences` instead.\n//\n// NOR IS SELF-SERVICE ACCOUNT DELETION — DATA-SUBJECT ERASURE IS A SYSTEM-LEVEL API WITH NO ROUTE.\n// `DELETE_ACCOUNT` was removed on 2026-08-01. It was an `APP_USER`-gated `riskLevel: CRITICAL`\n// operation taking `{ password, reason }` and declaring a scheduled-deletion\n// `customResponseDto: { scheduledDeletionDate, recoveryPeriodDays, dataExportUrl }`. It was broken\n// in four independent ways, each verified against the built configuration:\n//\n//   - **The password was never verified.** Neither declared field is a persisted `UserSchema` path\n//     and no custom implementation was bound to the operation path, so the built `repositoryDto`\n//     was EMPTY: the controller strict-parsed the body, the repository re-parsed it, and both\n//     fields were discarded. A UI collecting the password as a confirmation gate was providing\n//     false assurance.\n//   - **It could never answer successfully.** `transformOutput` skips default-envelope composition\n//     for an op declaring a `customResponseDto` and validates the raw service output against it.\n//     A core DELETE returns the deleted `_id` as a bare string, so every call threw\n//     `service_resource_transformation_failed` → HTTP 500. Retries too: a second call returns `''`,\n//     which is not `null`, so it fails the same parse.\n//   - **Its destructive effect was NONDETERMINISTIC.** `resourceOperationLike: DELETE` reaches\n//     `_doDelete` through the repository's operations map (which holds custom ops), bypassing the\n//     `coreOperations` gate this config never opened — and fires `onParentDelete`. Neither\n//     `USER_SELF_PROFILES` nor `USER_SELF_PREFERENCES` declares a DELETE, so a user WITH either row\n//     hit `ErrorType.CONFIGURATION` inside the delete transaction and was rolled back, while a user\n//     with NEITHER row was destroyed. Same 500, opposite persistence outcomes.\n//   - **It contradicted this resource's own retention contract.** `retentionPolicy` below declares\n//     `RETAIN_AND_IMPERSONALIZE`: user rows are RETAINED and scrubbed in place, never hard-deleted.\n//\n// The erasure capability already exists and is the only correct home: `eraseSubjectAsSystem` /\n// `eraseSubjectInPlace` walk every dependent edge, derive delete-vs-retain from each edge's own\n// `onParentDelete` declaration, fail closed on unclassified edges, and return a\n// `SubjectErasureReport`. Like the four export/portability verbs removed the same day, they\n// **deliberately ship with NO ROUTE** — data-subject rights are a system-level API, not a\n// self-service HTTP verb. `dataExportUrl` compounded this: it named the portability artifact that\n// removal established does not exist.\n//\n// Do NOT re-declare this as a resource operation. Voluntary self-service closure is\n// `DEACTIVATE_ACCOUNT` below; actual erasure runs through the compliance capability. If a product\n// ever needs a user-initiated erasure REQUEST, it is a scheduling verb over a persisted\n// request state (with its own cancel path and a batch that calls `eraseSubjectAsSystem`) — not a\n// routed DELETE, and not something the generic core delete can express.\n// See `.claude/plans/routed-unimplemented-operations-fail-closed.md`.\n//\n// assurance-control: WILDO.DATA.SECURE_LIFECYCLE — a destructive identity operation\n// must verify the principal and leave evidence; erasure must honour the declared retention mode.\nexport enum UserSelf_Operations {\n  DEACTIVATE_ACCOUNT = 'deactivate_account', // Temporarily deactivate account\n  REACTIVATE_ACCOUNT = 'reactivate_account', // Reactivate account\n}\n\ntype UserSelfCoreOperations =\n  | CoreResourceOperation.READ\n  | CoreResourceOperation.LIST\n  | CoreResourceOperation.UPDATE\n  | CoreResourceOperation.UPDATE_MANY;\n\n/*\nUser Self Resource Configuration Factory\n*/\nexport const userSelfResourceConfiguration_InitializationFactory = (resourcesRelationships: ResourceRelationship[]) => createResourceConfiguration_Initialization<\n  typeof UserSelf_Operations,\n  UserSelfCoreOperations,\n  typeof UserSchema\n>({\n  mainSchema: UserSchema,\n  resourceIdentifier: CoreResourceType.USER_SELF,\n  resourceFieldIdentifier: coreResourceShared_FieldIdentifier[CoreResourceType.USER_SELF],\n  resourceRelationships: resourcesRelationships,\n  isSystemResource: true, // Self-scoped\n\n  /**\n   * `/user-self/{userId}` names the CALLER. Declared EXPLICITLY even though `true` is the default,\n   * because the sibling `USERS` configuration — over the SAME collection, with the SAME\n   * `resourceFieldIdentifier` — declares `false`, and a reader comparing the two must be able to see\n   * that the difference is intentional rather than an omission.\n   *\n   * This is the value that keeps the horizontal-IDOR refusal alive: user A addressing user B's\n   * self row is refused `403 authorization_user_id_mismatch` by the identity-coherence guard. Pinned\n   * by `external-access-auth.e2e.ts` (M4) and `users-administration.e2e.ts` (U-11). Flipping this to\n   * `false` would open that hole silently — nothing downstream would catch it, because the addressed\n   * id still reaches the contextual filter and would scope the read to B.\n   */\n  primaryKeyIdentifiesInitiator: true,\n\n  /**\n   * ⚠️ MUST MIRROR `USERS`. This config and `USERS` are two doors onto the SAME rows: they share\n   * `UserSchema` above and, per `getCollectionNameForResource` in the zod→mongoose convertor,\n   * `USER_SELF` builds a SEPARATE Mongoose model over the `USERS` COLLECTION.\n   *\n   * Retention governance is per-resource-config, so a `USERS`-only opt-in would leave two holes on\n   * these shared rows:\n   *  - an ERASED user's row would stay READABLE and UPDATABLE through this door, whose READ/UPDATE\n   *    are open to `APP_USER` and would carry neither the retention hide filter nor the freeze;\n   *  - this model would emit a PLAIN unique index on `email` next to the `USERS` model's\n   *    retention-scoped one, so the SECOND erased user would collide (E11000) on the shared mask\n   *    address and abort the erasure.\n   *\n   * Declaring the same mode makes both models inject the same marker and emit the identical partial\n   * index, so the collection has one coherent retention contract. Change the two configs together.\n   * The scrub treatment needs no restating — it lives on the shared `UserSchema`.\n   */\n  retentionPolicy: {\n    mode: ErasureRetentionMode.RETAIN_AND_IMPERSONALIZE,\n  },\n\n  /**\n   * Same subject as `USERS` over the same collection — the self-service door onto the identity row.\n   * Mirrors that config's `SELF_PRINCIPAL` declaration; the two must be changed together.\n   */\n  dataSubjectPolicy: { kind: ResourceDataSubjectKind.SELF_PRINCIPAL },\n\n  /**\n   * Subject-export disclosure. The self-service export subject. The identity row is what the user signed up with.\n   */\n  systemAccessPolicy: { exportSubject: ResourceSystemAccessMode.ALLOWED },\n\n  /**\n   * Subject-export disclosure. The self-service export subject. The identity row is what the user signed up with.\n   */\n  portabilityPolicy: { defaultProvenance: DataPortabilityProvenance.SUBJECT_PROVIDED },\n\n  coreOperations: [\n    CoreResourceOperation.READ,\n    // LIST + UPDATE_MANY exist for the retention capability ONLY, as INTERNAL_CALL variants that\n    // register no route: `retentionPolicy` requires UPDATE_MANY (the in-place scrub via\n    // `updateManyAsSystem`) plus READ + LIST (the audited see-through read of retained rows). There\n    // is deliberately no HTTP \"list my selves\" — see the variants below.\n    CoreResourceOperation.LIST,\n    CoreResourceOperation.UPDATE,\n    CoreResourceOperation.UPDATE_MANY,\n  ],\n\n  customOperation: UserSelf_Operations,\n\n\n  operationsConfiguration: {\n    [CoreResourceOperation.READ]: {\n      variants: [\n        {\n          variantType: ResourceOperationVariantType.API_CALL,\n          isDefault: true,\n          roles: [CORE_APP_ROLES.APP_USER], // v1: app-only, user reading their own data\n          riskLevel: ResourceOperationRiskLevel.LOW,\n          // Default variant returns basic User data only\n        }\n      ]\n    },\n\n    [CoreResourceOperation.LIST]: {\n      variants: [\n        {\n          // Retention capability only — INTERNAL_CALL registers NO HTTP route. A user-facing\n          // \"list my selves\" would be meaningless (this resource is addressed as the caller's own\n          // row); the op exists solely so `listRetainedAsSystem` has a read path through which a\n          // compliance auditor can see-through to retained rows on this collection.\n          //\n          // ⚠️ INTERNAL_CALL, *not* REPOSITORY_ONLY — see the UPDATE_MANY note below for why the\n          // distinction is load-bearing. `roles` is inert on a non-URL-bearing variant.\n          variantType: ResourceOperationVariantType.INTERNAL_CALL,\n          isDefault: true,\n          roles: [CORE_APP_ROLES.APP_USER],\n          riskLevel: ResourceOperationRiskLevel.LOW,\n        }\n      ]\n    },\n\n    [CoreResourceOperation.UPDATE]: {\n      variants: [\n        {\n          // ⚠️ INTERNAL_CALL — registers NO HTTP route. This was an `API_CALL` open to\n          // `APP_USER` with an auto-derived request DTO, and on THIS resource the auto-derived\n          // user update DTO is `{status, appRoles, userTypes}`: every writable field on the\n          // `USER_SELF` row is server-owned. `email` is `.excludeFromUpdate()` and the editable\n          // self data (names, avatar, bio, phone / notification + UI preferences) lives on the\n          // `USER_SELF_PROFILES` and `USER_SELF_PREFERENCES` child resources, which is where the\n          // UI actually writes it. So the route offered a self-service caller nothing legitimate\n          // and three things it must never set:\n          //\n          //   - `appRoles`  — the app-level authorization axis. No ceiling gate exists on this\n          //     path (`assertRequestedRolesWithinCallerCeiling` is wired into org-member CREATE,\n          //     org-unit-members, oauth-clients and api-keys only, and no custom implementation is\n          //     registered for `USERS` / `USER_SELF`), so a plain authenticated user could grant\n          //     themselves any role, up to `APP_ADMIN_SUPER_ADMIN`.\n          //   - `userTypes` — selects auth policy and registration context.\n          //   - `status`    — the account lifecycle axis, which belongs to the dedicated\n          //     DEACTIVATE_ACCOUNT / REACTIVATE_ACCOUNT transitions below (and to the admin\n          //     SUSPEND_USER / UNSUSPEND_USER verbs on the `USERS` door). A self-service caller\n          //     flipping it directly bypasses every state gate those verbs declare.\n          //\n          // Narrowing `requestDto` would have left the route in place answering an empty write;\n          // removing the HTTP surface is the honest fix, because no caller wants it. Verified\n          // before the change: the engine presets surface no `UPDATE` action for `USER_SELF`\n          // (self edits go to the child resources), and no backend caller invokes `USER_SELF`\n          // update — the trusted internal door for user rows is `USERS`.\n          //\n          // The operation itself is KEPT (not dropped from `coreOperations`) because the custom\n          // self verbs borrow it through `resourceOperationLike: UPDATE`, and INTERNAL_CALL is\n          // the resource's established idiom for a route-less operation — see `LIST` and\n          // `UPDATE_MANY` above/below, and the note there on why INTERNAL_CALL rather than\n          // REPOSITORY_ONLY. `roles` is inert on a non-URL-bearing variant.\n          //\n          // assurance-control: WILDO.ACCESS.LEAST_PRIVILEGE — a self-service surface\n          // must not be a privilege-assignment or lifecycle-override surface.\n          variantType: ResourceOperationVariantType.INTERNAL_CALL,\n          isDefault: true,\n          roles: [CORE_APP_ROLES.APP_USER],\n          riskLevel: ResourceOperationRiskLevel.MEDIUM,\n        }\n      ],\n      userNotifications: [\n        {\n          target: CoreUserNotificationTarget.USER_SELF,\n          channel: CoreUserNotificationChannel.FRONT_END_SUCCESS,\n        }\n      ]\n    },\n\n    [CoreResourceOperation.UPDATE_MANY]: {\n      variants: [\n        {\n          // Retention capability only — INTERNAL_CALL registers NO HTTP route. Required by\n          // `retentionPolicy` because the impersonalize writer scrubs in place through\n          // `updateManyAsSystem`. A user bulk-updating rows through the self door would be\n          // nonsensical AND dangerous, so the only caller is the trusted system writer.\n          //\n          // ⚠️ INTERNAL_CALL, *not* REPOSITORY_ONLY. Both are route-less, but the three retention\n          // primitives (`updateManyAsSystem`, `readRetainedAsSystem`, `listRetainedAsSystem`) resolve\n          // through `getServiceOperationPathDefault`, which matches only INTERNAL_CALL / API_CALL /\n          // API_CALL_WITH_CALLBACK — REPOSITORY_ONLY is excluded there and served by the separate\n          // `getRepositoryOperationPathDefault` transport. A REPOSITORY_ONLY variant would satisfy the\n          // factory's boot guard and then FAIL TO RESOLVE when an erasure actually runs. `roles` is inert\n          // on a non-URL-bearing variant; the real gate is the derived `systemAccessPolicy` grant.\n          variantType: ResourceOperationVariantType.INTERNAL_CALL,\n          isDefault: true,\n          roles: [CORE_APP_ROLES.APP_USER],\n          riskLevel: ResourceOperationRiskLevel.CRITICAL,\n        }\n      ],\n    },\n\n    // Profile / preferences writes ride the dedicated `USER_SELF_PROFILES` and\n    // `USER_SELF_PREFERENCES` resources — the `UPDATE_PROFILE` / `UPDATE_PREFERENCES` verbs were\n    // removed on 2026-08-01 (they declared another resource's schema, so they answered 200 having\n    // persisted nothing). Self-service account DELETION was removed the same day: erasure is a\n    // system-level API with no route, and a hard delete contradicted the `retentionPolicy` above.\n    // Both removals are explained in the enum comment.\n    [UserSelf_Operations.DEACTIVATE_ACCOUNT]: {\n      variants: [\n        {\n          variantType: ResourceOperationVariantType.API_CALL,\n          isDefault: true,\n          roles: [CORE_APP_ROLES.APP_USER], // v1: app-only, high risk - affects access\n          riskLevel: ResourceOperationRiskLevel.HIGH,\n          resourceOperationLike: CoreResourceOperation.UPDATE,\n          // Implemented by the shared status-transition factory (ACTIVE → INACTIVE). INACTIVE, not\n          // SUSPENDED: the distinction is the point — SUSPENDED is imposed and only an admin lifts\n          // it, while INACTIVE is chosen and the user lifts it themselves via REACTIVATE_ACCOUNT.\n          // NO `reactivationDate`. It was declared here and persisted to\n          // `User.scheduledReactivationAt`, but nothing could ever honour it: the reactivation sweep\n          // dispatches each resource's own lifecycle verb, and the only verb that lifts `INACTIVE`\n          // is REACTIVATE_ACCOUNT below — self-scoped and `APP_USER`-gated, so a system principal\n          // cannot address another person's row through it.\n          //\n          // The two ways to make it work were both worse than the gap. Widening\n          // `users | unsuspend_user` to accept `INACTIVE` merges an IMPOSED suspension with a CHOSEN\n          // deactivation into one verb — two states whose whole distinction is who may lift them.\n          // And `admitsCrossSubjectUserAdministration` (the framework's per-variant \"this verb\n          // administers another person\" opt-in) relaxes WHOSE row may be addressed but never WHO may\n          // call, so putting it on an `APP_USER` verb would let any authenticated user reactivate\n          // anyone's account.\n          //\n          // Minting a new admin-tier reactivation verb purely to give the sweep a door would\n          // manufacture a routed surface nobody asked for — the exact pattern this workstream\n          // removed six times over. Voluntary deactivation is reversible by its subject at any time\n          // through REACTIVATE_ACCOUNT, so a scheduled auto-return was a convenience, not a promise\n          // the product makes anywhere else.\n          //\n          // Note the ADMIN time-boxing is unaffected and IS honoured: `users | suspend_user` takes\n          // `suspensionDuration` and the hourly sweep lifts it, because `unsuspend_user` is a door a\n          // system principal can dispatch. That is the case that actually matters — an operator who\n          // said \"seven days\" must get seven days.\n          requestDto: z.object({\n            reason: z.string().max(500).optional(),\n          }),\n          enabledCondition: ({ currentObject }) => {\n            return currentObject.status === UserStatus.ACTIVE;\n          }\n        }\n      ],\n      userNotifications: [\n        {\n          target: CoreUserNotificationTarget.USER_SELF,\n          channel: CoreUserNotificationChannel.EMAIL,\n        }\n      ]\n    },\n\n    [UserSelf_Operations.REACTIVATE_ACCOUNT]: {\n      variants: [\n        {\n          variantType: ResourceOperationVariantType.API_CALL,\n          isDefault: true,\n          roles: [CORE_APP_ROLES.APP_USER], // v1: app-only, medium risk\n          riskLevel: ResourceOperationRiskLevel.MEDIUM,\n          resourceOperationLike: CoreResourceOperation.UPDATE,\n          // Self-service reactivation FORCES the one transition it names. Omitting\n          // `requestDto` would auto-derive the FULL user update DTO — which on this resource\n          // is `{status, appRoles, userTypes}` — so an end-user-facing verb would accept its\n          // own `appRoles` and `userTypes`, with no ceiling gate anywhere on the path\n          // (`assertRequestedRolesWithinCallerCeiling` is not called here). Narrowing to an\n          // empty contract removes the role surface entirely, which is why this needs no\n          // ceiling call.\n          // assurance-control: WILDO.ACCESS.LEAST_PRIVILEGE — a self-service verb must not be a\n          // role-assignment surface.\n          requestDto: z.object({}),\n          // The transition itself is implemented by the SHARED status-transition factory, like its\n          // inverse DEACTIVATE_ACCOUNT above — not by a `basicPrefixOperation` here.\n          //\n          // It used to be the hook, and the asymmetry cost three things: the pending\n          // `scheduledReactivationAt` was never cleared (leaving a date on an ACTIVE row that no\n          // longer described anything), no transition audit row was emitted (so the self-service\n          // pair was half-trailed — the departure recorded, the return not), and the\n          // administrative-continuity floors did not run. Harmless individually, but it made the\n          // one lifecycle verb in the family that bypassed the shared authority the one nobody\n          // would think to check.\n          //\n          // The factory's registration declares `authoritativeFields: ['status',\n          // 'scheduledReactivationAt']`, which is what carries the patch past the repository's\n          // strict re-parse — the protection the hook's own declaration used to provide.\n          enabledCondition: ({ currentObject }) => {\n            return currentObject.status === UserStatus.INACTIVE;\n          }\n        }\n      ],\n      userNotifications: [\n        {\n          target: CoreUserNotificationTarget.USER_SELF,\n          channel: CoreUserNotificationChannel.EMAIL,\n        }\n      ]\n    }\n  },\n});\n"]}

package/dist/esm/users/users.shared.resources-config.schemas.d.ts

@@ -5,30 +5,27 @@
  * Handles user lifecycle, role management, and administrative actions.
  */
 import { z } from 'zod';
-import { UserStatus } from './users.shared.schemas.js';
-import { CoreResourceOperation } from '../resources/resources.shared.core.definitions.js';
-import { ResourceRelationship } from '../resources/resources.shared.schemas.js';
-import { CORE_APP_ROLES } from '../security/authorizations/roles.shared.schemas.js';
+import { UserStatus } from './users.shared.schemas';
+import { CoreResourceOperation } from '../resources/resources.shared.core.definitions';
+import { ResourceRelationship } from '../resources/resources.shared.schemas';
+import { CORE_APP_ROLES } from '../security/authorizations/roles.shared.schemas';
 export declare enum Users_Operations {
     ASSIGN_ROLES = "assign_roles",// Assign application roles
     REVOKE_ROLES = "revoke_roles",// Revoke application roles
     SUSPEND_USER = "suspend_user",// Suspend user account
     UNSUSPEND_USER = "unsuspend_user",// Unsuspend user account
-    FORCE_PASSWORD_RESET = "force_password_reset",// Force password reset
-    IMPERSONATE = "impersonate",// Impersonate user (admin)
-    MERGE_ACCOUNTS = "merge_accounts",// Merge duplicate accounts
-    EXPORT_USER_DATA = "export_user_data",// Export user data (admin)
-    SEND_INVITATION = "send_invitation"
+    FORCE_PASSWORD_RESET = "force_password_reset"
 }
-type UsersCoreOperations = CoreResourceOperation.READ | CoreResourceOperation.LIST | CoreResourceOperation.SEARCH | CoreResourceOperation.CREATE | CoreResourceOperation.UPDATE | CoreResourceOperation.DELETE;
-export declare const usersResourceConfiguration_InitializationFactory: (resourcesRelationships: ResourceRelationship[]) => import("../index.js").ResourceConfiguration<typeof Users_Operations, UsersCoreOperations, z.ZodObject<{
+type UsersCoreOperations = CoreResourceOperation.READ | CoreResourceOperation.LIST | CoreResourceOperation.SEARCH | CoreResourceOperation.CREATE | CoreResourceOperation.UPDATE | CoreResourceOperation.UPDATE_MANY | CoreResourceOperation.DELETE;
+export declare const usersResourceConfiguration_InitializationFactory: (resourcesRelationships: ResourceRelationship[]) => import("..").ResourceConfiguration<typeof Users_Operations, UsersCoreOperations, z.ZodObject<{
     _id: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodString>>;
-    email: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodEmail>>>;
-    status: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodDefault<z.ZodEnum<typeof UserStatus>>>>;
-    appRoles: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodDefault<z.ZodArray<z.ZodUnion<readonly [z.ZodEnum<typeof CORE_APP_ROLES>, z.ZodString]>>>>;
-    userTypes: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodDefault<z.ZodArray<z.ZodString>>>;
+    email: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodEmail>>>>;
+    status: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodDefault<z.ZodEnum<typeof UserStatus>>>>>>;
+    appRoles: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodDefault<z.ZodArray<z.ZodUnion<readonly [z.ZodEnum<typeof CORE_APP_ROLES>, z.ZodString]>>>>>;
+    userTypes: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodDefault<z.ZodArray<z.ZodString>>>>;
+    scheduledReactivationAt: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodOptional<z.ZodDate>>>>;
     createdAt: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodDefault<z.ZodDate>>>>>;
     updatedAt: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodDefault<z.ZodDate>>>>;
-}, z.core.$strip, core.$ZodObjectExtra>>;
+}, z.core.$strip>>;
 export {};
 //# sourceMappingURL=users.shared.resources-config.schemas.d.ts.map

package/dist/esm/users/users.shared.resources-config.schemas.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"users.shared.resources-config.schemas.d.ts","sourceRoot":"","sources":["../../../src/users/users.shared.resources-config.schemas.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AAEH,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AACxB,OAAO,EAEL,UAAU,EAEX,MAAM,wBAAwB,CAAC;AAEhC,OAAO,EAAE,qBAAqB,EAAE,MAAM,gDAAgD,CAAC;AACvF,OAAO,EAAoD,oBAAoB,EAAE,MAAM,uCAAuC,CAAC;AAO/H,OAAO,EAAE,cAAc,EAAE,MAAM,iDAAiD,CAAC;AAuBjF,oBAAY,gBAAgB;IAC1B,YAAY,iBAAiB,CAAE,2BAA2B;IAC1D,YAAY,iBAAiB,CAAE,2BAA2B;IAC1D,YAAY,iBAAiB,CAAE,uBAAuB;IACtD,cAAc,mBAAmB,CAAE,yBAAyB;IAC5D,oBAAoB,yBAAyB,CAAE,uBAAuB;IACtE,WAAW,gBAAgB,CAAE,2BAA2B;IACxD,cAAc,mBAAmB,CAAE,2BAA2B;IAC9D,gBAAgB,qBAAqB,CAAE,2BAA2B;IAClE,eAAe,oBAAoB;CACpC;AAED,KAAK,mBAAmB,GACpB,qBAAqB,CAAC,IAAI,GAC1B,qBAAqB,CAAC,IAAI,GAC1B,qBAAqB,CAAC,MAAM,GAC5B,qBAAqB,CAAC,MAAM,GAC5B,qBAAqB,CAAC,MAAM,GAC5B,qBAAqB,CAAC,MAAM,CAAC;AAKjC,eAAO,MAAM,gDAAgD,GAAI,wBAAwB,oBAAoB,EAAE;;;;;;;;wCAiY7G,CAAC"}
+{"version":3,"file":"users.shared.resources-config.schemas.d.ts","sourceRoot":"","sources":["../../../../src/users/users.shared.resources-config.schemas.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AAEH,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AACxB,OAAO,EAEL,UAAU,EAEX,MAAM,wBAAwB,CAAC;AAEhC,OAAO,EAAE,qBAAqB,EAAE,MAAM,gDAAgD,CAAC;AACvF,OAAO,EAAoD,oBAAoB,EAAE,MAAM,uCAAuC,CAAC;AAS/H,OAAO,EAAE,cAAc,EAAE,MAAM,iDAAiD,CAAC;AA2HjF,oBAAY,gBAAgB;IAC1B,YAAY,iBAAiB,CAAE,2BAA2B;IAC1D,YAAY,iBAAiB,CAAE,2BAA2B;IAC1D,YAAY,iBAAiB,CAAE,uBAAuB;IACtD,cAAc,mBAAmB,CAAE,yBAAyB;IAC5D,oBAAoB,yBAAyB;CAC9C;AAED,KAAK,mBAAmB,GACpB,qBAAqB,CAAC,IAAI,GAC1B,qBAAqB,CAAC,IAAI,GAC1B,qBAAqB,CAAC,MAAM,GAC5B,qBAAqB,CAAC,MAAM,GAC5B,qBAAqB,CAAC,MAAM,GAC5B,qBAAqB,CAAC,WAAW,GACjC,qBAAqB,CAAC,MAAM,CAAC;AAKjC,eAAO,MAAM,gDAAgD,GAAI,wBAAwB,oBAAoB,EAAE;;;;;;;;;kBA6gB7G,CAAC"}