@wildo-ai/saas-models 1.1.3 → 1.1.5

package/dist/esm/security/authorizations/application-access-grants.shared.resources-config.schemas.js

@@ -0,0 +1,265 @@
+/**
+ * Application Access Grants — resource configuration.
+ *
+ * The operation set mirrors `platformAccessGrants` verb for verb, and the ONE difference is the whole
+ * feature: `approve` is gated on the PLATFORM's own administrators rather than a tenant's, and refuses
+ * the requester. On the tenant resource the ABSENCE of `admitsCrossTenantPlatformAdministration` on
+ * `approve` is what stops an operator approving their own request; here every verb is platform-tier by
+ * construction, so that absence buys nothing and the refusal has to be a MEASUREMENT the
+ * implementation makes — `applicationAccessGrantApproverIsDistinct`.
+ *
+ * See `application-access-grants.shared.schemas.ts` for why the resource exists and why it is a
+ * sibling type rather than a field, and `.claude/rules/administrative-continuity-floors.md` for the
+ * ladder it sits on.
+ */
+import { z } from 'zod';
+import { ExecutionContext_MachineCredentialSchema } from '../../runtime/execution-context.shared.schemas.js';
+import { ApplicationAccessGrantSchema, ApplicationAccessGrants_Operations, applicationAccessGrantApproverIsDistinct, } from './application-access-grants.shared.schemas.js';
+import { PlatformAccessGrantStatus } from './platform-access-grants.shared.schemas.js';
+import { CoreResourceOperation, CoreResourceType, coreResourceShared_FieldIdentifier } from '../../resources/resources.shared.core.definitions.js';
+import { ResourceOperationRiskLevel, ResourceOperationVariantType, } from '../../resources/resources.shared.schemas.js';
+import { createResourceConfiguration_Initialization } from '../../resources/resources-config.shared.factory.js';
+import { ResourceSystemAccessMode } from '../../resources/resources-config.shared.schemas.js';
+import { CORE_APP_ROLES } from './roles.shared.schemas.js';
+import { ErasureRetentionMode, ResourceDataSubjectKind } from '../../compliance/privacy/impersonalization.shared.schemas.js';
+export const applicationAccessGrantsResourceConfiguration_InitializationFactory = (resourcesRelationships) => createResourceConfiguration_Initialization({
+    mainSchema: ApplicationAccessGrantSchema,
+    resourceIdentifier: CoreResourceType.APPLICATION_ACCESS_GRANTS,
+    resourceFieldIdentifier: coreResourceShared_FieldIdentifier[CoreResourceType.APPLICATION_ACCESS_GRANTS],
+    resourceRelationships: resourcesRelationships,
+    isSystemResource: true,
+    /**
+     * `read`/`list` ALLOWED for the trusted path, and for exactly the reason the tenant resource
+     * allows them: the authorization layer itself resolves a caller's usable grant on a system
+     * context, before the caller's own authority has been established for the read it is gating.
+     *
+     * No trusted `create`/`update`: every transition belongs to a custom implementation that applies
+     * the two-person measurement. A system door around those would be a second way to mint an
+     * application-wide elevation, which is the one thing this resource exists to prevent.
+     *
+     * `exportSubject: FORBIDDEN`, mirrored from the tenant resource. `operatorUserId` and
+     * `approvedByUserId` are foreign keys back to USERS, so these rows sit on a user's Art. 15 graph
+     * as `INCLUDED_REFERENCES_SUBJECT`; an included resource carrying NO declaration REFUSES the whole
+     * export, so omitting this would trade a boot failure for a broken disclosure right. FORBIDDEN
+     * because this is a security-monitoring record and handing the monitoring trail to the person it
+     * monitors is self-defeating — and because it names ANOTHER data subject's decision (the second
+     * administrator), which Art. 15(4) protects.
+     */
+    systemAccessPolicy: {
+        read: ResourceSystemAccessMode.ALLOWED,
+        list: ResourceSystemAccessMode.ALLOWED,
+        exportSubject: ResourceSystemAccessMode.FORBIDDEN,
+    },
+    /**
+     * Subject erasure RETAINS this row and scrubs its free text — mirrored from the tenant resource
+     * because it is the same kind of record. What survives is WHO reached application-wide, WHEN, and
+     * who signed for it; what does not is `justification` and `decisionReason`, the operator- and
+     * approver-written prose most likely to name a third party in passing.
+     */
+    retentionPolicy: {
+        mode: ErasureRetentionMode.RETAIN_AND_IMPERSONALIZE,
+    },
+    /**
+     * Erasing one of these revokes NO session: the grant is a record ABOUT an operator's access, not
+     * the operator. Their session ends through the `USERS` row, which is `SELF_PRINCIPAL`.
+     */
+    dataSubjectPolicy: { kind: ResourceDataSubjectKind.NO_PRINCIPAL },
+    coreOperations: [
+        CoreResourceOperation.READ,
+        CoreResourceOperation.LIST,
+        CoreResourceOperation.COUNT,
+        // Route-less; `retentionPolicy` requires READ + LIST + UPDATE_MANY.
+        CoreResourceOperation.UPDATE_MANY,
+    ],
+    operationsConfiguration: {
+        /*
+         * Route-less retention plumbing — INTERNAL_CALL registers no route and must not be
+         * REPOSITORY_ONLY: the retention primitives resolve through `getServiceOperationPathDefault`,
+         * which matches only INTERNAL_CALL / API_CALL. CRITICAL — it is the verb the impersonalize
+         * writer uses to stamp markers.
+         */
+        [CoreResourceOperation.UPDATE_MANY]: {
+            variants: [{
+                    variantType: ResourceOperationVariantType.INTERNAL_CALL,
+                    isDefault: true,
+                    roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],
+                    riskLevel: ResourceOperationRiskLevel.CRITICAL,
+                }],
+        },
+        /**
+         * The pending queue a second administrator works from, and the record of what was granted.
+         *
+         * `APP_ADMIN_SUPER_ADMIN` on every read: the rows name operator reach across every tenant, and
+         * there is no tenant-side reader here as there is on the platform resource — an application-wide
+         * grant has no customer to show it to. That absence is precisely why the approval had to become
+         * a second signature.
+         */
+        [CoreResourceOperation.READ]: {
+            variants: [
+                {
+                    variantType: ResourceOperationVariantType.API_CALL,
+                    isDefault: true,
+                    roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],
+                    riskLevel: ResourceOperationRiskLevel.LOW,
+                },
+            ],
+        },
+        [CoreResourceOperation.LIST]: {
+            variants: [
+                {
+                    variantType: ResourceOperationVariantType.API_CALL,
+                    isDefault: true,
+                    roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],
+                    riskLevel: ResourceOperationRiskLevel.LOW,
+                },
+            ],
+        },
+        [CoreResourceOperation.COUNT]: {
+            variants: [
+                {
+                    variantType: ResourceOperationVariantType.API_CALL,
+                    isDefault: true,
+                    roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],
+                    riskLevel: ResourceOperationRiskLevel.LOW,
+                },
+            ],
+        },
+        /**
+         * The bootstrap verb.
+         *
+         * Note what it deliberately does NOT declare: `admitsCrossTenantPlatformAdministration`. On the
+         * tenant resource that flag is what lets a non-member operator write a row inside someone else's
+         * tenant, and `requestAccess` there is exempted from the grant requirement it bootstraps. Here
+         * the resource is APPLICATION-scoped — there is no tenant boundary to cross — so the flag would
+         * be meaningless and the exemption has a different shape: the ADMISSION gate exempts this
+         * resource entirely, because an operator would otherwise need an application-wide grant in order
+         * to ask for one.
+         *
+         * What keeps that safe is the same argument the tenant resource makes: requesting is not
+         * accessing. This writes one PENDING row and reads nothing. The blast radius of an abused
+         * request is an entry in a queue that another administrator must sign.
+         *
+         * assurance-control: WILDO.ACCESS.CROSS_TENANT_ADMINISTRATION — application-wide reach is
+         * requested, never assumed.
+         * assurance-control: WILDO.ACCESS.PRIVILEGE_EVIDENCE
+         */
+        [ApplicationAccessGrants_Operations.REQUEST_ACCESS]: {
+            variants: [
+                {
+                    variantType: ResourceOperationVariantType.API_CALL,
+                    isDefault: true,
+                    roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],
+                    riskLevel: ResourceOperationRiskLevel.CRITICAL,
+                    resourceOperationLike: CoreResourceOperation.CREATE,
+                    requestDto: z.object({
+                        justification: z.string().min(1).max(1000),
+                        /** Minutes. Clamped server-side to the 1h ceiling; a longer ask is not refused. */
+                        requestedDurationMinutes: z.number().int().positive().optional(),
+                        /**
+                         * Ask for the elevation ON BEHALF OF one machine credential of this application — an API key or an
+                         * OAuth client, e.g. an assurance collector's (#297). The credential must exist, belong to this
+                         * application, be active and unexpired, or the request is refused. Once signed, the grant admits that
+                         * credential and NOT the requester.
+                         */
+                        grantedMachineCredential: ExecutionContext_MachineCredentialSchema.optional(),
+                    }),
+                },
+            ],
+        },
+        /**
+         * The SECOND SIGNATURE.
+         *
+         * `enabledCondition` refuses a self-approval here as well as in the implementation, and the
+         * duplication is deliberate rather than redundant — they are two different guarantees. This one
+         * makes the affordance DISAPPEAR for the requester, so a platform console never renders an
+         * Approve button on one's own request; the implementation's `assert…` is the fail-closed half,
+         * because `enabledCondition` is evaluated against the row the framework fetched and a future
+         * variant authored without one would otherwise transition silently.
+         *
+         * Neutering either alone must not admit a self-approval. That is what the two pins assert.
+         *
+         * assurance-control: WILDO.ACCESS.SEGREGATION_OF_DUTIES — the widest operator elevation requires
+         * a second, distinct platform administrator's signature.
+         */
+        [ApplicationAccessGrants_Operations.APPROVE]: {
+            variants: [
+                {
+                    variantType: ResourceOperationVariantType.API_CALL,
+                    isDefault: true,
+                    roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],
+                    riskLevel: ResourceOperationRiskLevel.CRITICAL,
+                    resourceOperationLike: CoreResourceOperation.UPDATE,
+                    requestDto: z.object({
+                        decisionReason: z.string().max(1000).optional(),
+                    }),
+                    enabledCondition: ({ currentObject, initiatorIds }) => currentObject.status === PlatformAccessGrantStatus.PENDING_APPROVAL
+                        && applicationAccessGrantApproverIsDistinct({
+                            operatorUserId: currentObject.operatorUserId,
+                            approverUserId: initiatorIds?.userId,
+                        }),
+                },
+            ],
+        },
+        /**
+         * Refusing a request. NOT gated on being a different person: an operator who thinks better of
+         * their own request should be able to withdraw it, and a denial only ever removes authority.
+         * The two-person rule constrains what an operator can GRANT themselves, never what they can
+         * refuse themselves.
+         */
+        [ApplicationAccessGrants_Operations.DENY]: {
+            variants: [
+                {
+                    variantType: ResourceOperationVariantType.API_CALL,
+                    isDefault: true,
+                    roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],
+                    riskLevel: ResourceOperationRiskLevel.MEDIUM,
+                    resourceOperationLike: CoreResourceOperation.UPDATE,
+                    requestDto: z.object({
+                        decisionReason: z.string().max(1000).optional(),
+                    }),
+                    enabledCondition: ({ currentObject }) => currentObject.status === PlatformAccessGrantStatus.PENDING_APPROVAL,
+                },
+            ],
+        },
+        /** Ending an elevation early. Monotonic — it only ever removes authority — so it is unrestricted among platform administrators. */
+        [ApplicationAccessGrants_Operations.REVOKE]: {
+            variants: [
+                {
+                    variantType: ResourceOperationVariantType.API_CALL,
+                    isDefault: true,
+                    roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],
+                    riskLevel: ResourceOperationRiskLevel.MEDIUM,
+                    resourceOperationLike: CoreResourceOperation.UPDATE,
+                    requestDto: z.object({
+                        decisionReason: z.string().max(1000).optional(),
+                    }),
+                    enabledCondition: ({ currentObject }) => currentObject.status === PlatformAccessGrantStatus.PENDING_APPROVAL
+                        || currentObject.status === PlatformAccessGrantStatus.ACTIVE,
+                },
+            ],
+        },
+        /**
+         * ACTIVE → EXPIRED once the window has elapsed, dispatched by the credential-expiry sweep and by
+         * nothing else. INTERNAL_CALL: no route, no affordance.
+         *
+         * `requestDto: z.object({})` is EMPTY BY CONTRACT, not by omission — an operation without a
+         * `requestDto` inherits the resource's entire update contract, which would let a verb that
+         * accepts nothing advertise every field, `status` included.
+         */
+        [ApplicationAccessGrants_Operations.EXPIRE]: {
+            variants: [
+                {
+                    variantType: ResourceOperationVariantType.INTERNAL_CALL,
+                    isDefault: true,
+                    roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],
+                    riskLevel: ResourceOperationRiskLevel.LOW,
+                    resourceOperationLike: CoreResourceOperation.UPDATE,
+                    requestDto: z.object({}),
+                },
+            ],
+        },
+    },
+    // NOTE: the APPLICATION primary scope is NOT declared here. It is derived from the registry
+    // relationship carrying `isPrimaryScope: true` (APPLICATION → APPLICATION_ACCESS_GRANTS).
+});
+//# sourceMappingURL=application-access-grants.shared.resources-config.schemas.js.map

package/dist/esm/security/authorizations/application-access-grants.shared.resources-config.schemas.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"application-access-grants.shared.resources-config.schemas.js","sourceRoot":"","sources":["../../../../../src/security/authorizations/application-access-grants.shared.resources-config.schemas.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;GAaG;AAEH,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AACxB,OAAO,EAAE,wCAAwC,EAAE,MAAM,gDAAgD,CAAC;AAC1G,OAAO,EACL,4BAA4B,EAC5B,kCAAkC,EAClC,wCAAwC,GACzC,MAAM,4CAA4C,CAAC;AACpD,OAAO,EAAE,yBAAyB,EAAE,MAAM,yCAAyC,CAAC;AACpF,OAAO,EAAE,qBAAqB,EAAE,gBAAgB,EAAE,kCAAkC,EAAE,MAAM,mDAAmD,CAAC;AAChJ,OAAO,EACL,0BAA0B,EAC1B,4BAA4B,GAE7B,MAAM,0CAA0C,CAAC;AAClD,OAAO,EAAE,0CAA0C,EAAE,MAAM,iDAAiD,CAAC;AAC7G,OAAO,EAAE,wBAAwB,EAAE,MAAM,iDAAiD,CAAC;AAC3F,OAAO,EAAE,cAAc,EAAE,MAAM,wBAAwB,CAAC;AACxD,OAAO,EAAE,oBAAoB,EAAE,uBAAuB,EAAE,MAAM,2DAA2D,CAAC;AAS1H,MAAM,CAAC,MAAM,kEAAkE,GAAG,CAAC,sBAA8C,EAAE,EAAE,CACnI,0CAA0C,CAIxC;IACA,UAAU,EAAE,4BAA4B;IACxC,kBAAkB,EAAE,gBAAgB,CAAC,yBAAyB;IAC9D,uBAAuB,EAAE,kCAAkC,CAAC,gBAAgB,CAAC,yBAAyB,CAAC;IACvG,qBAAqB,EAAE,sBAAsB;IAC7C,gBAAgB,EAAE,IAAI;IAEtB;;;;;;;;;;;;;;;;OAgBG;IACH,kBAAkB,EAAE;QAClB,IAAI,EAAE,wBAAwB,CAAC,OAAO;QACtC,IAAI,EAAE,wBAAwB,CAAC,OAAO;QACtC,aAAa,EAAE,wBAAwB,CAAC,SAAS;KAClD;IAED;;;;;OAKG;IACH,eAAe,EAAE;QACf,IAAI,EAAE,oBAAoB,CAAC,wBAAwB;KACpD;IAED;;;OAGG;IACH,iBAAiB,EAAE,EAAE,IAAI,EAAE,uBAAuB,CAAC,YAAY,EAAE;IAEjE,cAAc,EAAE;QACd,qBAAqB,CAAC,IAAI;QAC1B,qBAAqB,CAAC,IAAI;QAC1B,qBAAqB,CAAC,KAAK;QAC3B,oEAAoE;QACpE,qBAAqB,CAAC,WAAW;KAClC;IAED,uBAAuB,EAAE;QAEvB;;;;;WAKG;QACH,CAAC,qBAAqB,CAAC,WAAW,CAAC,EAAE;YACnC,QAAQ,EAAE,CAAC;oBACT,WAAW,EAAE,4BAA4B,CAAC,aAAa;oBACvD,SAAS,EAAE,IAAI;oBACf,KAAK,EAAE,CAAC,cAAc,CAAC,qBAAqB,CAAC;oBAC7C,SAAS,EAAE,0BAA0B,CAAC,QAAQ;iBAC/C,CAAC;SACH;QAED;;;;;;;WAOG;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;oBAC7C,SAAS,EAAE,0BAA0B,CAAC,GAAG;iBAC1C;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,qBAAqB,CAAC;oBAC7C,SAAS,EAAE,0BAA0B,CAAC,GAAG;iBAC1C;aACF;SACF;QAED,CAAC,qBAAqB,CAAC,KAAK,CAAC,EAAE;YAC7B,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,GAAG;iBAC1C;aACF;SACF;QAED;;;;;;;;;;;;;;;;;;WAkBG;QACH,CAAC,kCAAkC,CAAC,cAAc,CAAC,EAAE;YACnD,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,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;wBAC1C,mFAAmF;wBACnF,wBAAwB,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,EAAE,CAAC,QAAQ,EAAE,CAAC,QAAQ,EAAE;wBAChE;;;;;2BAKG;wBACH,wBAAwB,EAAE,wCAAwC,CAAC,QAAQ,EAAE;qBAC9E,CAAC;iBACH;aACF;SACF;QAED;;;;;;;;;;;;;;WAcG;QACH,CAAC,kCAAkC,CAAC,OAAO,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,QAAQ;oBAC9C,qBAAqB,EAAE,qBAAqB,CAAC,MAAM;oBACnD,UAAU,EAAE,CAAC,CAAC,MAAM,CAAC;wBACnB,cAAc,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,IAAI,CAAC,CAAC,QAAQ,EAAE;qBAChD,CAAC;oBACF,gBAAgB,EAAE,CAAC,EAAE,aAAa,EAAE,YAAY,EAAE,EAAE,EAAE,CACpD,aAAa,CAAC,MAAM,KAAK,yBAAyB,CAAC,gBAAgB;2BAChE,wCAAwC,CAAC;4BAC1C,cAAc,EAAE,aAAa,CAAC,cAAc;4BAC5C,cAAc,EAAE,YAAY,EAAE,MAAM;yBACrC,CAAC;iBACL;aACF;SACF;QAED;;;;;WAKG;QACH,CAAC,kCAAkC,CAAC,IAAI,CAAC,EAAE;YACzC,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,UAAU,EAAE,CAAC,CAAC,MAAM,CAAC;wBACnB,cAAc,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,IAAI,CAAC,CAAC,QAAQ,EAAE;qBAChD,CAAC;oBACF,gBAAgB,EAAE,CAAC,EAAE,aAAa,EAAE,EAAE,EAAE,CAAC,aAAa,CAAC,MAAM,KAAK,yBAAyB,CAAC,gBAAgB;iBAC7G;aACF;SACF;QAED,mIAAmI;QACnI,CAAC,kCAAkC,CAAC,MAAM,CAAC,EAAE;YAC3C,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,UAAU,EAAE,CAAC,CAAC,MAAM,CAAC;wBACnB,cAAc,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,IAAI,CAAC,CAAC,QAAQ,EAAE;qBAChD,CAAC;oBACF,gBAAgB,EAAE,CAAC,EAAE,aAAa,EAAE,EAAE,EAAE,CACtC,aAAa,CAAC,MAAM,KAAK,yBAAyB,CAAC,gBAAgB;2BAChE,aAAa,CAAC,MAAM,KAAK,yBAAyB,CAAC,MAAM;iBAC/D;aACF;SACF;QAED;;;;;;;WAOG;QACH,CAAC,kCAAkC,CAAC,MAAM,CAAC,EAAE;YAC3C,QAAQ,EAAE;gBACR;oBACE,WAAW,EAAE,4BAA4B,CAAC,aAAa;oBACvD,SAAS,EAAE,IAAI;oBACf,KAAK,EAAE,CAAC,cAAc,CAAC,qBAAqB,CAAC;oBAC7C,SAAS,EAAE,0BAA0B,CAAC,GAAG;oBACzC,qBAAqB,EAAE,qBAAqB,CAAC,MAAM;oBACnD,UAAU,EAAE,CAAC,CAAC,MAAM,CAAC,EAAE,CAAC;iBACzB;aACF;SACF;KACF;IACD,4FAA4F;IAC5F,0FAA0F;CAC3F,CAAC,CAAC","sourcesContent":["/**\n * Application Access Grants — resource configuration.\n *\n * The operation set mirrors `platformAccessGrants` verb for verb, and the ONE difference is the whole\n * feature: `approve` is gated on the PLATFORM's own administrators rather than a tenant's, and refuses\n * the requester. On the tenant resource the ABSENCE of `admitsCrossTenantPlatformAdministration` on\n * `approve` is what stops an operator approving their own request; here every verb is platform-tier by\n * construction, so that absence buys nothing and the refusal has to be a MEASUREMENT the\n * implementation makes — `applicationAccessGrantApproverIsDistinct`.\n *\n * See `application-access-grants.shared.schemas.ts` for why the resource exists and why it is a\n * sibling type rather than a field, and `.claude/rules/administrative-continuity-floors.md` for the\n * ladder it sits on.\n */\n\nimport { z } from 'zod';\nimport { ExecutionContext_MachineCredentialSchema } from '../../runtime/execution-context.shared.schemas';\nimport {\n  ApplicationAccessGrantSchema,\n  ApplicationAccessGrants_Operations,\n  applicationAccessGrantApproverIsDistinct,\n} from './application-access-grants.shared.schemas';\nimport { PlatformAccessGrantStatus } from './platform-access-grants.shared.schemas';\nimport { CoreResourceOperation, CoreResourceType, coreResourceShared_FieldIdentifier } from '../../resources/resources.shared.core.definitions';\nimport {\n  ResourceOperationRiskLevel,\n  ResourceOperationVariantType,\n  type ResourceRelationship,\n} from '../../resources/resources.shared.schemas';\nimport { createResourceConfiguration_Initialization } from '../../resources/resources-config.shared.factory';\nimport { ResourceSystemAccessMode } from '../../resources/resources-config.shared.schemas';\nimport { CORE_APP_ROLES } from './roles.shared.schemas';\nimport { ErasureRetentionMode, ResourceDataSubjectKind } from '../../compliance/privacy/impersonalization.shared.schemas';\n\ntype ApplicationAccessGrantsCoreOperations =\n  | CoreResourceOperation.READ\n  | CoreResourceOperation.LIST\n  | CoreResourceOperation.COUNT\n  // Route-less; `retentionPolicy` requires READ + LIST + UPDATE_MANY.\n  | CoreResourceOperation.UPDATE_MANY;\n\nexport const applicationAccessGrantsResourceConfiguration_InitializationFactory = (resourcesRelationships: ResourceRelationship[]) =>\n  createResourceConfiguration_Initialization<\n    typeof ApplicationAccessGrants_Operations,\n    ApplicationAccessGrantsCoreOperations,\n    typeof ApplicationAccessGrantSchema\n  >({\n    mainSchema: ApplicationAccessGrantSchema,\n    resourceIdentifier: CoreResourceType.APPLICATION_ACCESS_GRANTS,\n    resourceFieldIdentifier: coreResourceShared_FieldIdentifier[CoreResourceType.APPLICATION_ACCESS_GRANTS],\n    resourceRelationships: resourcesRelationships,\n    isSystemResource: true,\n\n    /**\n     * `read`/`list` ALLOWED for the trusted path, and for exactly the reason the tenant resource\n     * allows them: the authorization layer itself resolves a caller's usable grant on a system\n     * context, before the caller's own authority has been established for the read it is gating.\n     *\n     * No trusted `create`/`update`: every transition belongs to a custom implementation that applies\n     * the two-person measurement. A system door around those would be a second way to mint an\n     * application-wide elevation, which is the one thing this resource exists to prevent.\n     *\n     * `exportSubject: FORBIDDEN`, mirrored from the tenant resource. `operatorUserId` and\n     * `approvedByUserId` are foreign keys back to USERS, so these rows sit on a user's Art. 15 graph\n     * as `INCLUDED_REFERENCES_SUBJECT`; an included resource carrying NO declaration REFUSES the whole\n     * export, so omitting this would trade a boot failure for a broken disclosure right. FORBIDDEN\n     * because this is a security-monitoring record and handing the monitoring trail to the person it\n     * monitors is self-defeating — and because it names ANOTHER data subject's decision (the second\n     * administrator), which Art. 15(4) protects.\n     */\n    systemAccessPolicy: {\n      read: ResourceSystemAccessMode.ALLOWED,\n      list: ResourceSystemAccessMode.ALLOWED,\n      exportSubject: ResourceSystemAccessMode.FORBIDDEN,\n    },\n\n    /**\n     * Subject erasure RETAINS this row and scrubs its free text — mirrored from the tenant resource\n     * because it is the same kind of record. What survives is WHO reached application-wide, WHEN, and\n     * who signed for it; what does not is `justification` and `decisionReason`, the operator- and\n     * approver-written prose most likely to name a third party in passing.\n     */\n    retentionPolicy: {\n      mode: ErasureRetentionMode.RETAIN_AND_IMPERSONALIZE,\n    },\n\n    /**\n     * Erasing one of these revokes NO session: the grant is a record ABOUT an operator's access, not\n     * the operator. Their session ends through the `USERS` row, which is `SELF_PRINCIPAL`.\n     */\n    dataSubjectPolicy: { kind: ResourceDataSubjectKind.NO_PRINCIPAL },\n\n    coreOperations: [\n      CoreResourceOperation.READ,\n      CoreResourceOperation.LIST,\n      CoreResourceOperation.COUNT,\n      // Route-less; `retentionPolicy` requires READ + LIST + UPDATE_MANY.\n      CoreResourceOperation.UPDATE_MANY,\n    ],\n\n    operationsConfiguration: {\n\n      /*\n       * Route-less retention plumbing — INTERNAL_CALL registers no route and must not be\n       * REPOSITORY_ONLY: the retention primitives resolve through `getServiceOperationPathDefault`,\n       * which matches only INTERNAL_CALL / API_CALL. CRITICAL — it is the verb the impersonalize\n       * writer uses to stamp markers.\n       */\n      [CoreResourceOperation.UPDATE_MANY]: {\n        variants: [{\n          variantType: ResourceOperationVariantType.INTERNAL_CALL,\n          isDefault: true,\n          roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],\n          riskLevel: ResourceOperationRiskLevel.CRITICAL,\n        }],\n      },\n\n      /**\n       * The pending queue a second administrator works from, and the record of what was granted.\n       *\n       * `APP_ADMIN_SUPER_ADMIN` on every read: the rows name operator reach across every tenant, and\n       * there is no tenant-side reader here as there is on the platform resource — an application-wide\n       * grant has no customer to show it to. That absence is precisely why the approval had to become\n       * a second signature.\n       */\n      [CoreResourceOperation.READ]: {\n        variants: [\n          {\n            variantType: ResourceOperationVariantType.API_CALL,\n            isDefault: true,\n            roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],\n            riskLevel: ResourceOperationRiskLevel.LOW,\n          },\n        ],\n      },\n\n      [CoreResourceOperation.LIST]: {\n        variants: [\n          {\n            variantType: ResourceOperationVariantType.API_CALL,\n            isDefault: true,\n            roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],\n            riskLevel: ResourceOperationRiskLevel.LOW,\n          },\n        ],\n      },\n\n      [CoreResourceOperation.COUNT]: {\n        variants: [\n          {\n            variantType: ResourceOperationVariantType.API_CALL,\n            isDefault: true,\n            roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],\n            riskLevel: ResourceOperationRiskLevel.LOW,\n          },\n        ],\n      },\n\n      /**\n       * The bootstrap verb.\n       *\n       * Note what it deliberately does NOT declare: `admitsCrossTenantPlatformAdministration`. On the\n       * tenant resource that flag is what lets a non-member operator write a row inside someone else's\n       * tenant, and `requestAccess` there is exempted from the grant requirement it bootstraps. Here\n       * the resource is APPLICATION-scoped — there is no tenant boundary to cross — so the flag would\n       * be meaningless and the exemption has a different shape: the ADMISSION gate exempts this\n       * resource entirely, because an operator would otherwise need an application-wide grant in order\n       * to ask for one.\n       *\n       * What keeps that safe is the same argument the tenant resource makes: requesting is not\n       * accessing. This writes one PENDING row and reads nothing. The blast radius of an abused\n       * request is an entry in a queue that another administrator must sign.\n       *\n       * assurance-control: WILDO.ACCESS.CROSS_TENANT_ADMINISTRATION — application-wide reach is\n       * requested, never assumed.\n       * assurance-control: WILDO.ACCESS.PRIVILEGE_EVIDENCE\n       */\n      [ApplicationAccessGrants_Operations.REQUEST_ACCESS]: {\n        variants: [\n          {\n            variantType: ResourceOperationVariantType.API_CALL,\n            isDefault: true,\n            roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],\n            riskLevel: ResourceOperationRiskLevel.CRITICAL,\n            resourceOperationLike: CoreResourceOperation.CREATE,\n            requestDto: z.object({\n              justification: z.string().min(1).max(1000),\n              /** Minutes. Clamped server-side to the 1h ceiling; a longer ask is not refused. */\n              requestedDurationMinutes: z.number().int().positive().optional(),\n              /**\n               * Ask for the elevation ON BEHALF OF one machine credential of this application — an API key or an\n               * OAuth client, e.g. an assurance collector's (#297). The credential must exist, belong to this\n               * application, be active and unexpired, or the request is refused. Once signed, the grant admits that\n               * credential and NOT the requester.\n               */\n              grantedMachineCredential: ExecutionContext_MachineCredentialSchema.optional(),\n            }),\n          },\n        ],\n      },\n\n      /**\n       * The SECOND SIGNATURE.\n       *\n       * `enabledCondition` refuses a self-approval here as well as in the implementation, and the\n       * duplication is deliberate rather than redundant — they are two different guarantees. This one\n       * makes the affordance DISAPPEAR for the requester, so a platform console never renders an\n       * Approve button on one's own request; the implementation's `assert…` is the fail-closed half,\n       * because `enabledCondition` is evaluated against the row the framework fetched and a future\n       * variant authored without one would otherwise transition silently.\n       *\n       * Neutering either alone must not admit a self-approval. That is what the two pins assert.\n       *\n       * assurance-control: WILDO.ACCESS.SEGREGATION_OF_DUTIES — the widest operator elevation requires\n       * a second, distinct platform administrator's signature.\n       */\n      [ApplicationAccessGrants_Operations.APPROVE]: {\n        variants: [\n          {\n            variantType: ResourceOperationVariantType.API_CALL,\n            isDefault: true,\n            roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],\n            riskLevel: ResourceOperationRiskLevel.CRITICAL,\n            resourceOperationLike: CoreResourceOperation.UPDATE,\n            requestDto: z.object({\n              decisionReason: z.string().max(1000).optional(),\n            }),\n            enabledCondition: ({ currentObject, initiatorIds }) =>\n              currentObject.status === PlatformAccessGrantStatus.PENDING_APPROVAL\n              && applicationAccessGrantApproverIsDistinct({\n                operatorUserId: currentObject.operatorUserId,\n                approverUserId: initiatorIds?.userId,\n              }),\n          },\n        ],\n      },\n\n      /**\n       * Refusing a request. NOT gated on being a different person: an operator who thinks better of\n       * their own request should be able to withdraw it, and a denial only ever removes authority.\n       * The two-person rule constrains what an operator can GRANT themselves, never what they can\n       * refuse themselves.\n       */\n      [ApplicationAccessGrants_Operations.DENY]: {\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            requestDto: z.object({\n              decisionReason: z.string().max(1000).optional(),\n            }),\n            enabledCondition: ({ currentObject }) => currentObject.status === PlatformAccessGrantStatus.PENDING_APPROVAL,\n          },\n        ],\n      },\n\n      /** Ending an elevation early. Monotonic — it only ever removes authority — so it is unrestricted among platform administrators. */\n      [ApplicationAccessGrants_Operations.REVOKE]: {\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            requestDto: z.object({\n              decisionReason: z.string().max(1000).optional(),\n            }),\n            enabledCondition: ({ currentObject }) =>\n              currentObject.status === PlatformAccessGrantStatus.PENDING_APPROVAL\n              || currentObject.status === PlatformAccessGrantStatus.ACTIVE,\n          },\n        ],\n      },\n\n      /**\n       * ACTIVE → EXPIRED once the window has elapsed, dispatched by the credential-expiry sweep and by\n       * nothing else. INTERNAL_CALL: no route, no affordance.\n       *\n       * `requestDto: z.object({})` is EMPTY BY CONTRACT, not by omission — an operation without a\n       * `requestDto` inherits the resource's entire update contract, which would let a verb that\n       * accepts nothing advertise every field, `status` included.\n       */\n      [ApplicationAccessGrants_Operations.EXPIRE]: {\n        variants: [\n          {\n            variantType: ResourceOperationVariantType.INTERNAL_CALL,\n            isDefault: true,\n            roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],\n            riskLevel: ResourceOperationRiskLevel.LOW,\n            resourceOperationLike: CoreResourceOperation.UPDATE,\n            requestDto: z.object({}),\n          },\n        ],\n      },\n    },\n    // NOTE: the APPLICATION primary scope is NOT declared here. It is derived from the registry\n    // relationship carrying `isPrimaryScope: true` (APPLICATION → APPLICATION_ACCESS_GRANTS).\n  });\n"]}

package/dist/esm/security/authorizations/application-access-grants.shared.schemas.d.ts

@@ -0,0 +1,187 @@
+/**
+ * Application Access Grants — time-bound, justified, TWO-PERSON-APPROVED elevation for an operator
+ * act that names no single tenant.
+ *
+ * ## Which reads use this grant
+ *
+ * Actual application-wide grants always require a different administrator's approval. The general
+ * directory and other application-wide read gates retain that requirement. The application audit
+ * viewer instead defaults to its administrator-role gate, in production and development alike;
+ * `auditTrail.applicationReadAccess = AuditApplicationReadAccess.INDEPENDENT_APPROVAL` explicitly
+ * enrolls that viewer in this grant requirement. Role-based audit reads remain observed and do not
+ * invent a grant id. The historical diagnosis below explains the general elevation mechanism, not
+ * an assertion that every cross-tenant audit read must use it.
+ *
+ * ## The asymmetry this closes
+ *
+ * `platformAccessGrants` governs the NARROW act: one operator, one named tenant, one window. It is
+ * the door `.claude/rules/administrative-continuity-floors.md` calls rungs 4–5 of the ladder, and it
+ * works.
+ *
+ * The WIDE act was ungoverned. Measured 2026-09-09 and recorded on
+ * `ScopeRootConfinementDisposition.UNCONFINED_APPLICATION_TIER_DIRECTORY`:
+ *
+ * | | per-row crossing | application-wide read |
+ * |---|---|---|
+ * | elevation required | a usable `platformAccessGrants` row | **none** |
+ * | role tier | `APP_ADMIN_SUPER_ADMIN` | `APP_ADMIN_VIEWER` / `ORG_MEMBER` |
+ * | evidence | `CROSS_TENANT_ADMINISTRATIVE_ACCESS`, naming the grant | an observation naming no elevation |
+ *
+ * So the narrow act carried elevation and expiry and the widest read did not — and the wide one sat
+ * at a strictly LOWER role tier. That is worse than "not symmetric"; it is the control inverted.
+ *
+ * ## Why a SEPARATE resource and not a `scope` field on the tenant grant
+ *
+ * Structural, not stylistic. A `platformAccessGrants` row is ORGANIZATIONS-scoped: its primary-scope
+ * relationship carries `isPrimaryScope: true` on `organizationId`, every route is
+ * `/organizations/{organizationId}/platform-access-grants/…`, and the tenant's ability to SEE and
+ * REVOKE the row is exactly what that scope buys. An application-wide elevation names no tenant, so
+ * the route has nothing to carry and the scope has nobody to serve. Adding a nullable
+ * `organizationId` to make one row shape serve both would weaken the field whose presence IS the
+ * tenant grant's control — which the finding explicitly refuses ("do not weaken the per-row model to
+ * make the two symmetric").
+ *
+ * The engine's own precedent for a second scope over one lifecycle is `applicationAuditLogs` beside
+ * `auditLogs`: a sibling resource type carrying ONE application parent, taking the route it needs and
+ * leaving the existing door byte-identical.
+ *
+ * ## Why TWO-PERSON, and what was rejected
+ *
+ * Tenant approval is the industry ceiling (Microsoft Customer Lockbox, Google Access Approval) and it
+ * is structurally unavailable here: there is no single customer to ask. `administrative-continuity-floors.md`
+ * names the next-strongest control in as many words — *"a second factor authenticates a session; only
+ * a second signature constrains an authenticated operator"* — and asks for a two-person rule on the
+ * widest acts.
+ *
+ * Auto-approval was rejected: it is the tenant grant's default posture precisely BECAUSE a tenant can
+ * opt in above it, and there is no such party here, so an auto-approved application-wide grant would
+ * be a standing privilege with a request form in front of it.
+ *
+ * Confining the read to tenants the caller holds a grant for was rejected on MEASUREMENT rather than
+ * cost: `users` rows carry no tenant column at all, so there is nothing for a tenant predicate to
+ * bind to, and any junction-based confinement would also remove the tenant-less user — the person who
+ * has just signed up and belongs to nobody — from the only surface that can find them.
+ */
+import { z } from 'zod';
+import { PlatformAccessGrantStatus } from './platform-access-grants.shared.schemas';
+/**
+ * The default life of an application-wide grant whose request names no duration.
+ *
+ * THIRTY minutes — half the tenant grant's default, and the halving is the point rather than a round
+ * number. A tenant grant reaches ONE customer and the customer can see and revoke it; this one
+ * reaches every customer at once and no customer can see it. The window is the only thing that ends
+ * it early, so the unconsidered case gets the narrowest window a support interaction can still use.
+ */
+export declare const APPLICATION_ACCESS_GRANT_DEFAULT_DURATION_MINUTES = 30;
+/**
+ * The maximum life of an application-wide grant, whatever a request asks for.
+ *
+ * ONE HOUR against the tenant grant's four. A four-hour window is defended there as "a working
+ * session, not a working week" for an elevation into one tenant; the same reasoning gives a shorter
+ * answer for an elevation into all of them. An operator who genuinely needs longer re-requests, and
+ * a second administrator signs again — which is the record we want, and the reason a shorter ceiling
+ * here costs no security and buys a second signature per hour of the widest access the system grants.
+ */
+export declare const APPLICATION_ACCESS_GRANT_MAXIMUM_DURATION_MINUTES = 60;
+/**
+ * Custom verbs. Mirrors `PlatformAccessGrants_Operations` deliberately — the same lifecycle,
+ * so the same verbs, so a reader who knows one knows the other.
+ *
+ * There is no ordinary CREATE/UPDATE for the same reason: they would be a second, ungated path to the
+ * server-authored fields whose server authorship IS the control.
+ */
+export declare enum ApplicationAccessGrants_Operations {
+    /**
+     * The bootstrap verb. Writes one row in `PENDING_APPROVAL` and NEVER in `ACTIVE` — see
+     * the `status` field below for why auto-approval has no member here.
+     */
+    REQUEST_ACCESS = "requestAccess",
+    /** The SECOND administrator's signature. Refuses the requester — {@link applicationAccessGrantApproverIsDistinct}. */
+    APPROVE = "approve",
+    DENY = "deny",
+    REVOKE = "revoke",
+    /** ACTIVE → EXPIRED, dispatched by the credential-expiry sweep and by nothing else. */
+    EXPIRE = "expire"
+}
+export declare const ApplicationAccessGrantSchema: z.ZodObject<{
+    _id: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodString>>;
+    applicationId: 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.ZodOptional<z.ZodString>>>>>;
+    operatorUserId: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodString>>>>>>;
+    justification: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodString>>;
+    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<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodDefault<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodEnum<typeof PlatformAccessGrantStatus>>>>>>>>;
+    expiresAt: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodDate>>>>>;
+    approvedByUserId: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodOptional<z.ZodString>>>>>>;
+    approvedAt: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodOptional<z.ZodDate>>>;
+    grantedMachineCredential: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodOptional<z.ZodObject<{
+        authMethod: z.ZodEnum<typeof import("../..").MachineAuthMethod>;
+        credentialId: z.ZodString;
+    }, z.core.$strip>>>>;
+    decisionReason: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodOptional<z.ZodString>>>>;
+    createdAt: z.ZodOptional<z.ZodDate>;
+    updatedAt: z.ZodOptional<z.ZodDate>;
+}, z.core.$strip>;
+export type ApplicationAccessGrant = z.infer<typeof ApplicationAccessGrantSchema>;
+/**
+ * Clamp a requested duration to the application-wide ceiling.
+ *
+ * A deliberate near-copy of `resolvePlatformAccessGrantExpiry` rather than a shared function taking
+ * two constants: the two ceilings are two DECISIONS about two different acts, and a shared helper
+ * invites the next author to pass whichever constant is in scope. The behaviour that matters is
+ * identical and stated in both places — a longer ask is CLAMPED, never refused, because being told
+ * "ask again with a smaller number" during an incident is friction with no security benefit.
+ */
+export declare function resolveApplicationAccessGrantExpiry(requestedDurationMinutes: number | undefined, now: Date): Date;
+/**
+ * Does this grant admit this principal?
+ *
+ * **The one decision about WHO a grant is for**, because two principals now hold grants and each reading of the
+ * row must agree:
+ *
+ *  - a grant bound to a machine credential admits exactly that credential (same method, same id) and nobody else —
+ *    not its requester, not another credential, not a human carrying no credential;
+ *  - an unbound grant admits exactly its requester, as a HUMAN: a machine principal carrying the requester's user
+ *    id is not a thing the request pipeline builds, and admitting one would be a second way for a person to lend
+ *    their elevation to a credential without a second signature naming it.
+ *
+ * Fails closed on every missing input. Usability of the WINDOW is a separate question (`isPlatformAccessGrantUsable`).
+ */
+export declare function applicationAccessGrantAdmits(params: {
+    readonly grant: {
+        readonly operatorUserId?: string | null;
+        readonly grantedMachineCredential?: {
+            readonly authMethod: string;
+            readonly credentialId: string;
+        } | null;
+    };
+    readonly principal: {
+        readonly userId?: string | null;
+        readonly machineCredential?: {
+            readonly authMethod: string;
+            readonly credentialId: string;
+        } | null;
+    };
+}): boolean;
+/**
+ * Is this approver a DIFFERENT person from the operator who asked?
+ *
+ * **This predicate is the two-person rule.** Everything else about an application-wide grant — the
+ * request, the window, the justification, the audit row — exists in the tenant grant too. What is new
+ * here is exactly this comparison, so it is named, exported, and asked in ONE place.
+ *
+ * ## Why it is a predicate and not an inline `!==`
+ *
+ * Three call sites would otherwise each write their own comparison, and two of the three ways to
+ * write it are wrong in the same direction:
+ *
+ *  - an approver id that is ABSENT must NOT pass. An unauthenticated or system-context approval has
+ *    no second person behind it, and `undefined !== 'operator'` is `true` — the inline form fails
+ *    OPEN on precisely the input a broken context supplies;
+ *  - an operator id that is absent must not pass either, for the mirror reason.
+ *
+ * So the predicate requires BOTH ids to be present and different. Fails closed on everything else.
+ */
+export declare function applicationAccessGrantApproverIsDistinct(params: {
+    readonly operatorUserId: string | undefined | null;
+    readonly approverUserId: string | undefined | null;
+}): boolean;
+//# sourceMappingURL=application-access-grants.shared.schemas.d.ts.map

package/dist/esm/security/authorizations/application-access-grants.shared.schemas.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"application-access-grants.shared.schemas.d.ts","sourceRoot":"","sources":["../../../../../src/security/authorizations/application-access-grants.shared.schemas.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA+DG;AAEH,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AAKxB,OAAO,EAAE,yBAAyB,EAAE,MAAM,yCAAyC,CAAC;AAKpF;;;;;;;GAOG;AACH,eAAO,MAAM,iDAAiD,KAAK,CAAC;AAEpE;;;;;;;;GAQG;AACH,eAAO,MAAM,iDAAiD,KAAK,CAAC;AAEpE;;;;;;GAMG;AACH,oBAAY,kCAAkC;IAC5C;;;OAGG;IACH,cAAc,kBAAkB;IAChC,sHAAsH;IACtH,OAAO,YAAY;IACnB,IAAI,SAAS;IACb,MAAM,WAAW;IACjB,uFAAuF;IACvF,MAAM,WAAW;CAClB;AAED,eAAO,MAAM,4BAA4B;;;;;;;;;;;;;;;;iBA0GvC,CAAC;AAEH,MAAM,MAAM,sBAAsB,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,4BAA4B,CAAC,CAAC;AAElF;;;;;;;;GAQG;AACH,wBAAgB,mCAAmC,CAAC,wBAAwB,EAAE,MAAM,GAAG,SAAS,EAAE,GAAG,EAAE,IAAI,GAAG,IAAI,CAMjH;AAED;;;;;;;;;;;;;GAaG;AACH,wBAAgB,4BAA4B,CAAC,MAAM,EAAE;IACnD,QAAQ,CAAC,KAAK,EAAE;QACd,QAAQ,CAAC,cAAc,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;QACxC,QAAQ,CAAC,wBAAwB,CAAC,EAAE;YAAE,QAAQ,CAAC,UAAU,EAAE,MAAM,CAAC;YAAC,QAAQ,CAAC,YAAY,EAAE,MAAM,CAAA;SAAE,GAAG,IAAI,CAAC;KAC3G,CAAC;IACF,QAAQ,CAAC,SAAS,EAAE;QAClB,QAAQ,CAAC,MAAM,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;QAChC,QAAQ,CAAC,iBAAiB,CAAC,EAAE;YAAE,QAAQ,CAAC,UAAU,EAAE,MAAM,CAAC;YAAC,QAAQ,CAAC,YAAY,EAAE,MAAM,CAAA;SAAE,GAAG,IAAI,CAAC;KACpG,CAAC;CACH,GAAG,OAAO,CASV;AAED;;;;;;;;;;;;;;;;;;GAkBG;AACH,wBAAgB,wCAAwC,CAAC,MAAM,EAAE;IAC/D,QAAQ,CAAC,cAAc,EAAE,MAAM,GAAG,SAAS,GAAG,IAAI,CAAC;IACnD,QAAQ,CAAC,cAAc,EAAE,MAAM,GAAG,SAAS,GAAG,IAAI,CAAC;CACpD,GAAG,OAAO,CAKV"}