@wildo-ai/saas-models 1.1.1 → 1.1.3

package/dist/esm/security/connected-accounts/provider-credentials-user.shared.resources-config.schemas.js

@@ -0,0 +1,191 @@
+/**
+ * User Provider Credentials — resource configuration.
+ *
+ * A PERSON's own credential toward a third party. See `provider-credentials.shared.schemas.ts` for
+ * what the resource is, why it is separate from the organization-owned sibling, and why it is not a
+ * delegated OAuth grant.
+ */
+import { z } from 'zod';
+import { ProviderCredentialValidationState, UserProviderCredentialSchema, } from './provider-credentials.shared.schemas.js';
+import { ErasureRetentionMode, ResourceDataSubjectKind } from '../../compliance/privacy/impersonalization.shared.schemas.js';
+import { createResourceConfiguration_Initialization } from '../../resources/resources-config.shared.factory.js';
+import { ResourceSystemAccessMode } from '../../resources/resources-config.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 { CORE_APP_ROLES } from '../authorizations/roles.shared.schemas.js';
+const USER_PROVIDER_CREDENTIALS_SORT_FIELDS = ['createdAt', 'updatedAt', 'providerRef', 'lastUsedAt'];
+const USER_PROVIDER_CREDENTIALS_FILTER_FIELDS = {
+    providerRef: z.string(),
+    secretSlug: z.string(),
+    enabled: z.boolean(),
+    validationState: z.enum(ProviderCredentialValidationState),
+};
+export const userProviderCredentialsResourceConfiguration_InitializationFactory = (resourcesRelationships) => createResourceConfiguration_Initialization({
+    mainSchema: UserProviderCredentialSchema,
+    resourceIdentifier: CoreResourceType.USER_PROVIDER_CREDENTIALS,
+    resourceFieldIdentifier: coreResourceShared_FieldIdentifier[CoreResourceType.USER_PROVIDER_CREDENTIALS],
+    resourceRelationships: resourcesRelationships,
+    isSystemResource: true,
+    /**
+     * The same four system doors as the organization-owned sibling, for the same reasons: a provider
+     * call runs on whatever execution context the caller holds, so the resolver reads through
+     * `readAsSystem`, and writes back `lastUsedAt` / `validationState` through `updateAsSystem` because
+     * those fields are `.excludeFromUpdate()` and a holder must not be able to declare their own
+     * credential VALID.
+     *
+     * ## `create` was shut, and the sentence that shut it stopped being true
+     *
+     * It read: "a credential exists only because a person supplied one." That is exactly right for a
+     * credential somebody PASTES, and false for one a vendor MINTS. An OAuth2 grant exists because a
+     * person authorized it on the vendor's own consent screen and came back through a redirect;
+     * nobody ever types it, so there is no HTTP write that could carry it. Leaving the door shut would
+     * mean the authorization exchange completes, the vendor records the grant, and this application
+     * has nowhere to put it.
+     *
+     * What keeps that narrow is the door itself rather than a second check: `createAsSystem` is
+     * reachable only from engine code — never an HTTP payload — its re-attach allowlist is DERIVED
+     * from the schema rather than caller-supplied, and the row identity the seal binds to comes from
+     * the scope map, so a caller cannot name whose credential it is writing.
+     *
+     * ## `exportSubject: FORBIDDEN` matters MORE here than on the sibling, and the difference is real
+     *
+     * The organization-owned row is unreachable on the subject-export graph anyway, because no `USERS`
+     * relationship is registered for its `setByUserId` — the export walk simply never arrives. This row
+     * IS reachable: `userId` is a registered `USERS` composition, which is what gives the resource its
+     * USER_SELF scope in the first place. So the export walk arrives here BY CONSTRUCTION, and this
+     * refusal is the only thing standing between a subject-access request and a working third-party
+     * credential in the response.
+     */
+    systemAccessPolicy: {
+        exportSubject: ResourceSystemAccessMode.FORBIDDEN,
+        read: ResourceSystemAccessMode.ALLOWED,
+        list: ResourceSystemAccessMode.ALLOWED,
+        update: ResourceSystemAccessMode.ALLOWED,
+        create: ResourceSystemAccessMode.ALLOWED,
+    },
+    /**
+     * `RETAIN_ONLY`, and the row still does not survive its owner — the CASCADE removes it.
+     *
+     * These are two different mechanisms and reading them as one produces the wrong answer in both
+     * directions. The retention policy governs what the erasure WALK does to a row it retains: here,
+     * nothing, because a secret is not personal data to be pseudonymised. You do not scrub a
+     * credential, you destroy it. The `USERS → USER_PROVIDER_CREDENTIALS` composition is what destroys
+     * it, dispatching this resource's DELETE when the person is removed.
+     *
+     * So a person who exercises erasure does not leave a live credential behind, and the mechanism that
+     * guarantees it is the relationship rather than the policy. Declaring `RETAIN_AND_IMPERSONALIZE`
+     * instead would be actively wrong: it would keep the row and replace its fields, leaving a sealed
+     * envelope whose key material still opens against a subject who asked to be forgotten.
+     */
+    retentionPolicy: {
+        mode: ErasureRetentionMode.RETAIN_ONLY,
+    },
+    /**
+     * `NO_PRINCIPAL` on the axis this enum actually decides: erasing a credential revokes no session,
+     * because no login is reachable from it. `userId` names the OWNER, not a login this row confers.
+     */
+    dataSubjectPolicy: { kind: ResourceDataSubjectKind.NO_PRINCIPAL },
+    coreOperations: [
+        CoreResourceOperation.READ,
+        CoreResourceOperation.LIST,
+        CoreResourceOperation.CREATE,
+        CoreResourceOperation.UPDATE,
+        // Required by the USERS cascade — `onParentDelete` dispatches this DELETE — and it is also the
+        // holder's own "remove this credential" door.
+        CoreResourceOperation.DELETE,
+        // Route-less; `retentionPolicy` requires READ + LIST + UPDATE_MANY.
+        CoreResourceOperation.UPDATE_MANY,
+    ],
+    operationsConfiguration: {
+        /*
+         * `APP_USER` everywhere, and NO administrative variant anywhere — a stronger refusal than the
+         * organization-owned sibling's, which refuses only the PLATFORM operator.
+         *
+         * Here an organization administrator is refused too. The row is a key its holder authored against
+         * their own account with a vendor; consent to store it is not consent for somebody else to spend
+         * it, and the vendor would record the act as the holder's own. There is no support story that
+         * makes that reversible, and the USER_SELF primary-scope filter is what enforces it structurally
+         * rather than by a role list somebody could widen.
+         *
+         * The cost is that a personal credential cannot be repaired by anyone but its owner, which is the
+         * correct outcome: if the person is gone, the credential should be too, and the cascade sees to it.
+         */
+        [CoreResourceOperation.READ]: {
+            variants: [
+                {
+                    variantType: ResourceOperationVariantType.API_CALL,
+                    isDefault: true,
+                    roles: [CORE_APP_ROLES.APP_USER],
+                    // LOW because the value never leaves: `.isWriteOnlySecret()` redacts it at the client
+                    // boundary, so a READ returns metadata and a placeholder.
+                    riskLevel: ResourceOperationRiskLevel.LOW,
+                },
+            ],
+        },
+        [CoreResourceOperation.LIST]: {
+            variants: [
+                {
+                    variantType: ResourceOperationVariantType.API_CALL,
+                    isDefault: true,
+                    roles: [CORE_APP_ROLES.APP_USER],
+                    riskLevel: ResourceOperationRiskLevel.LOW,
+                    filterFields: USER_PROVIDER_CREDENTIALS_FILTER_FIELDS,
+                    sortFields: USER_PROVIDER_CREDENTIALS_SORT_FIELDS,
+                    maxPaginatedResultPerPageLimit: 100,
+                },
+            ],
+        },
+        [CoreResourceOperation.CREATE]: {
+            variants: [
+                {
+                    variantType: ResourceOperationVariantType.API_CALL,
+                    isDefault: true,
+                    roles: [CORE_APP_ROLES.APP_USER],
+                    // CRITICAL: the act of granting this application authority to act as the person toward a
+                    // third party. That it is the person's own decision makes it consented, not low-risk.
+                    riskLevel: ResourceOperationRiskLevel.CRITICAL,
+                },
+            ],
+        },
+        [CoreResourceOperation.UPDATE]: {
+            variants: [
+                {
+                    variantType: ResourceOperationVariantType.API_CALL,
+                    isDefault: true,
+                    roles: [CORE_APP_ROLES.APP_USER],
+                    riskLevel: ResourceOperationRiskLevel.CRITICAL,
+                },
+            ],
+        },
+        [CoreResourceOperation.DELETE]: {
+            variants: [
+                {
+                    variantType: ResourceOperationVariantType.API_CALL,
+                    isDefault: true,
+                    roles: [CORE_APP_ROLES.APP_USER],
+                    // Revoking one's own credential is the safe direction and must never be harder than
+                    // granting it.
+                    riskLevel: ResourceOperationRiskLevel.LOW,
+                },
+            ],
+        },
+        /**
+         * Route-less and INTERNAL_CALL only — the retention machinery's own door, never a client's.
+         *
+         * `retentionPolicy` requires READ + LIST + UPDATE_MANY to exist, and a bulk update reachable over
+         * HTTP on this resource would be a way to change many credentials at once, which no holder needs
+         * and no administrator may have.
+         */
+        [CoreResourceOperation.UPDATE_MANY]: {
+            variants: [
+                {
+                    variantType: ResourceOperationVariantType.INTERNAL_CALL,
+                    isDefault: true,
+                    roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],
+                    riskLevel: ResourceOperationRiskLevel.CRITICAL,
+                },
+            ],
+        },
+    },
+});
+//# sourceMappingURL=provider-credentials-user.shared.resources-config.schemas.js.map

package/dist/esm/security/connected-accounts/provider-credentials-user.shared.resources-config.schemas.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"provider-credentials-user.shared.resources-config.schemas.js","sourceRoot":"","sources":["../../../../../src/security/connected-accounts/provider-credentials-user.shared.resources-config.schemas.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;AAEH,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AAExB,OAAO,EACL,iCAAiC,EACjC,4BAA4B,GAC7B,MAAM,uCAAuC,CAAC;AAE/C,OAAO,EAAE,oBAAoB,EAAE,uBAAuB,EAAE,MAAM,2DAA2D,CAAC;AAC1H,OAAO,EAAE,0CAA0C,EAAE,MAAM,iDAAiD,CAAC;AAC7G,OAAO,EAAE,wBAAwB,EAAE,MAAM,iDAAiD,CAAC;AAC3F,OAAO,EAAE,qBAAqB,EAAE,gBAAgB,EAAE,kCAAkC,EAAE,MAAM,mDAAmD,CAAC;AAChJ,OAAO,EAAE,0BAA0B,EAAE,4BAA4B,EAAwB,MAAM,0CAA0C,CAAC;AAC1I,OAAO,EAAE,cAAc,EAAE,MAAM,wCAAwC,CAAC;AAExE,MAAM,qCAAqC,GAAG,CAAC,WAAW,EAAE,WAAW,EAAE,aAAa,EAAE,YAAY,CAAU,CAAC;AAE/G,MAAM,uCAAuC,GAAG;IAC9C,WAAW,EAAE,CAAC,CAAC,MAAM,EAAE;IACvB,UAAU,EAAE,CAAC,CAAC,MAAM,EAAE;IACtB,OAAO,EAAE,CAAC,CAAC,OAAO,EAAE;IACpB,eAAe,EAAE,CAAC,CAAC,IAAI,CAAC,iCAAiC,CAAC;CAC3D,CAAC;AAUF,MAAM,CAAC,MAAM,kEAAkE,GAAG,CAChF,sBAA8C,EAC9C,EAAE,CAAC,0CAA0C,CAI7C;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;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OA6BG;IACH,kBAAkB,EAAE;QAClB,aAAa,EAAE,wBAAwB,CAAC,SAAS;QACjD,IAAI,EAAE,wBAAwB,CAAC,OAAO;QACtC,IAAI,EAAE,wBAAwB,CAAC,OAAO;QACtC,MAAM,EAAE,wBAAwB,CAAC,OAAO;QACxC,MAAM,EAAE,wBAAwB,CAAC,OAAO;KACzC;IAED;;;;;;;;;;;;;OAaG;IACH,eAAe,EAAE;QACf,IAAI,EAAE,oBAAoB,CAAC,WAAW;KACvC;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,MAAM;QAC5B,qBAAqB,CAAC,MAAM;QAC5B,+FAA+F;QAC/F,8CAA8C;QAC9C,qBAAqB,CAAC,MAAM;QAC5B,oEAAoE;QACpE,qBAAqB,CAAC,WAAW;KAClC;IAED,uBAAuB,EAAE;QACvB;;;;;;;;;;;;WAYG;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,QAAQ,CAAC;oBAChC,sFAAsF;oBACtF,0DAA0D;oBAC1D,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,QAAQ,CAAC;oBAChC,SAAS,EAAE,0BAA0B,CAAC,GAAG;oBACzC,YAAY,EAAE,uCAAuC;oBACrD,UAAU,EAAE,qCAAqC;oBACjD,8BAA8B,EAAE,GAAG;iBACpC;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;oBAChC,yFAAyF;oBACzF,sFAAsF;oBACtF,SAAS,EAAE,0BAA0B,CAAC,QAAQ;iBAC/C;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;oBAChC,SAAS,EAAE,0BAA0B,CAAC,QAAQ;iBAC/C;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;oBAChC,oFAAoF;oBACpF,eAAe;oBACf,SAAS,EAAE,0BAA0B,CAAC,GAAG;iBAC1C;aACF;SACF;QAED;;;;;;WAMG;QACH,CAAC,qBAAqB,CAAC,WAAW,CAAC,EAAE;YACnC,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,QAAQ;iBAC/C;aACF;SACF;KACF;CACF,CAAC,CAAC","sourcesContent":["/**\n * User Provider Credentials — resource configuration.\n *\n * A PERSON's own credential toward a third party. See `provider-credentials.shared.schemas.ts` for\n * what the resource is, why it is separate from the organization-owned sibling, and why it is not a\n * delegated OAuth grant.\n */\n\nimport { z } from 'zod';\n\nimport {\n  ProviderCredentialValidationState,\n  UserProviderCredentialSchema,\n} from './provider-credentials.shared.schemas';\n\nimport { ErasureRetentionMode, ResourceDataSubjectKind } from '../../compliance/privacy/impersonalization.shared.schemas';\nimport { createResourceConfiguration_Initialization } from '../../resources/resources-config.shared.factory';\nimport { ResourceSystemAccessMode } from '../../resources/resources-config.shared.schemas';\nimport { CoreResourceOperation, CoreResourceType, coreResourceShared_FieldIdentifier } from '../../resources/resources.shared.core.definitions';\nimport { ResourceOperationRiskLevel, ResourceOperationVariantType, ResourceRelationship } from '../../resources/resources.shared.schemas';\nimport { CORE_APP_ROLES } from '../authorizations/roles.shared.schemas';\n\nconst USER_PROVIDER_CREDENTIALS_SORT_FIELDS = ['createdAt', 'updatedAt', 'providerRef', 'lastUsedAt'] as const;\n\nconst USER_PROVIDER_CREDENTIALS_FILTER_FIELDS = {\n  providerRef: z.string(),\n  secretSlug: z.string(),\n  enabled: z.boolean(),\n  validationState: z.enum(ProviderCredentialValidationState),\n};\n\ntype UserProviderCredentialsCoreOperations =\n  | CoreResourceOperation.READ\n  | CoreResourceOperation.LIST\n  | CoreResourceOperation.CREATE\n  | CoreResourceOperation.UPDATE\n  | CoreResourceOperation.DELETE\n  | CoreResourceOperation.UPDATE_MANY;\n\nexport const userProviderCredentialsResourceConfiguration_InitializationFactory = (\n  resourcesRelationships: ResourceRelationship[],\n) => createResourceConfiguration_Initialization<\n  undefined,\n  UserProviderCredentialsCoreOperations,\n  typeof UserProviderCredentialSchema\n>({\n  mainSchema: UserProviderCredentialSchema,\n  resourceIdentifier: CoreResourceType.USER_PROVIDER_CREDENTIALS,\n  resourceFieldIdentifier: coreResourceShared_FieldIdentifier[CoreResourceType.USER_PROVIDER_CREDENTIALS],\n  resourceRelationships: resourcesRelationships,\n  isSystemResource: true,\n\n  /**\n   * The same four system doors as the organization-owned sibling, for the same reasons: a provider\n   * call runs on whatever execution context the caller holds, so the resolver reads through\n   * `readAsSystem`, and writes back `lastUsedAt` / `validationState` through `updateAsSystem` because\n   * those fields are `.excludeFromUpdate()` and a holder must not be able to declare their own\n   * credential VALID.\n   *\n   * ## `create` was shut, and the sentence that shut it stopped being true\n   *\n   * It read: \"a credential exists only because a person supplied one.\" That is exactly right for a\n   * credential somebody PASTES, and false for one a vendor MINTS. An OAuth2 grant exists because a\n   * person authorized it on the vendor's own consent screen and came back through a redirect;\n   * nobody ever types it, so there is no HTTP write that could carry it. Leaving the door shut would\n   * mean the authorization exchange completes, the vendor records the grant, and this application\n   * has nowhere to put it.\n   *\n   * What keeps that narrow is the door itself rather than a second check: `createAsSystem` is\n   * reachable only from engine code — never an HTTP payload — its re-attach allowlist is DERIVED\n   * from the schema rather than caller-supplied, and the row identity the seal binds to comes from\n   * the scope map, so a caller cannot name whose credential it is writing.\n   *\n   * ## `exportSubject: FORBIDDEN` matters MORE here than on the sibling, and the difference is real\n   *\n   * The organization-owned row is unreachable on the subject-export graph anyway, because no `USERS`\n   * relationship is registered for its `setByUserId` — the export walk simply never arrives. This row\n   * IS reachable: `userId` is a registered `USERS` composition, which is what gives the resource its\n   * USER_SELF scope in the first place. So the export walk arrives here BY CONSTRUCTION, and this\n   * refusal is the only thing standing between a subject-access request and a working third-party\n   * credential in the response.\n   */\n  systemAccessPolicy: {\n    exportSubject: ResourceSystemAccessMode.FORBIDDEN,\n    read: ResourceSystemAccessMode.ALLOWED,\n    list: ResourceSystemAccessMode.ALLOWED,\n    update: ResourceSystemAccessMode.ALLOWED,\n    create: ResourceSystemAccessMode.ALLOWED,\n  },\n\n  /**\n   * `RETAIN_ONLY`, and the row still does not survive its owner — the CASCADE removes it.\n   *\n   * These are two different mechanisms and reading them as one produces the wrong answer in both\n   * directions. The retention policy governs what the erasure WALK does to a row it retains: here,\n   * nothing, because a secret is not personal data to be pseudonymised. You do not scrub a\n   * credential, you destroy it. The `USERS → USER_PROVIDER_CREDENTIALS` composition is what destroys\n   * it, dispatching this resource's DELETE when the person is removed.\n   *\n   * So a person who exercises erasure does not leave a live credential behind, and the mechanism that\n   * guarantees it is the relationship rather than the policy. Declaring `RETAIN_AND_IMPERSONALIZE`\n   * instead would be actively wrong: it would keep the row and replace its fields, leaving a sealed\n   * envelope whose key material still opens against a subject who asked to be forgotten.\n   */\n  retentionPolicy: {\n    mode: ErasureRetentionMode.RETAIN_ONLY,\n  },\n\n  /**\n   * `NO_PRINCIPAL` on the axis this enum actually decides: erasing a credential revokes no session,\n   * because no login is reachable from it. `userId` names the OWNER, not a login this row confers.\n   */\n  dataSubjectPolicy: { kind: ResourceDataSubjectKind.NO_PRINCIPAL },\n\n  coreOperations: [\n    CoreResourceOperation.READ,\n    CoreResourceOperation.LIST,\n    CoreResourceOperation.CREATE,\n    CoreResourceOperation.UPDATE,\n    // Required by the USERS cascade — `onParentDelete` dispatches this DELETE — and it is also the\n    // holder's own \"remove this credential\" door.\n    CoreResourceOperation.DELETE,\n    // Route-less; `retentionPolicy` requires READ + LIST + UPDATE_MANY.\n    CoreResourceOperation.UPDATE_MANY,\n  ],\n\n  operationsConfiguration: {\n    /*\n     * `APP_USER` everywhere, and NO administrative variant anywhere — a stronger refusal than the\n     * organization-owned sibling's, which refuses only the PLATFORM operator.\n     *\n     * Here an organization administrator is refused too. The row is a key its holder authored against\n     * their own account with a vendor; consent to store it is not consent for somebody else to spend\n     * it, and the vendor would record the act as the holder's own. There is no support story that\n     * makes that reversible, and the USER_SELF primary-scope filter is what enforces it structurally\n     * rather than by a role list somebody could widen.\n     *\n     * The cost is that a personal credential cannot be repaired by anyone but its owner, which is the\n     * correct outcome: if the person is gone, the credential should be too, and the cascade sees to it.\n     */\n    [CoreResourceOperation.READ]: {\n      variants: [\n        {\n          variantType: ResourceOperationVariantType.API_CALL,\n          isDefault: true,\n          roles: [CORE_APP_ROLES.APP_USER],\n          // LOW because the value never leaves: `.isWriteOnlySecret()` redacts it at the client\n          // boundary, so a READ returns metadata and a placeholder.\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_USER],\n          riskLevel: ResourceOperationRiskLevel.LOW,\n          filterFields: USER_PROVIDER_CREDENTIALS_FILTER_FIELDS,\n          sortFields: USER_PROVIDER_CREDENTIALS_SORT_FIELDS,\n          maxPaginatedResultPerPageLimit: 100,\n        },\n      ],\n    },\n\n    [CoreResourceOperation.CREATE]: {\n      variants: [\n        {\n          variantType: ResourceOperationVariantType.API_CALL,\n          isDefault: true,\n          roles: [CORE_APP_ROLES.APP_USER],\n          // CRITICAL: the act of granting this application authority to act as the person toward a\n          // third party. That it is the person's own decision makes it consented, not low-risk.\n          riskLevel: ResourceOperationRiskLevel.CRITICAL,\n        },\n      ],\n    },\n\n    [CoreResourceOperation.UPDATE]: {\n      variants: [\n        {\n          variantType: ResourceOperationVariantType.API_CALL,\n          isDefault: true,\n          roles: [CORE_APP_ROLES.APP_USER],\n          riskLevel: ResourceOperationRiskLevel.CRITICAL,\n        },\n      ],\n    },\n\n    [CoreResourceOperation.DELETE]: {\n      variants: [\n        {\n          variantType: ResourceOperationVariantType.API_CALL,\n          isDefault: true,\n          roles: [CORE_APP_ROLES.APP_USER],\n          // Revoking one's own credential is the safe direction and must never be harder than\n          // granting it.\n          riskLevel: ResourceOperationRiskLevel.LOW,\n        },\n      ],\n    },\n\n    /**\n     * Route-less and INTERNAL_CALL only — the retention machinery's own door, never a client's.\n     *\n     * `retentionPolicy` requires READ + LIST + UPDATE_MANY to exist, and a bulk update reachable over\n     * HTTP on this resource would be a way to change many credentials at once, which no holder needs\n     * and no administrator may have.\n     */\n    [CoreResourceOperation.UPDATE_MANY]: {\n      variants: [\n        {\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});\n"]}

package/dist/esm/security/connected-accounts/provider-credentials.shared.schemas.d.ts

@@ -0,0 +1,250 @@
+/**
+ * Organization Provider Credentials — shared schemas.
+ *
+ * ## What this resource is, and what it is NOT
+ *
+ * It is an ORGANIZATION's OWN credential toward a third party: the Slack workspace token, the CRM
+ * API key, the SMTP password that belongs to THAT tenant. The organization is the third-party
+ * principal, and the credential is a service credential the tenant's administrator supplies.
+ *
+ * It is NOT a user's delegated OAuth grant. A delegated grant is a different object with a
+ * different lifetime (a refresh loop, a revocation the USER can perform, a consent record) and it
+ * lands as `connected accounts` beside this file — see issue #333. Merging the two would give one
+ * row two owners and two revocation semantics.
+ *
+ * ## Why it has to exist
+ *
+ * Before this resource, every provider secret resolved from `process.env` through the
+ * `SecretsContract`, so a credential was per-PROCESS and per-DEPLOYMENT. One application serving
+ * many organizations therefore had ONE Slack token for all of them, and the failure was silent in
+ * the worst direction: an operator sets one key and every tenant thereafter acts as the SAME
+ * third-party principal, with nothing anywhere saying so.
+ *
+ * ## The value is sealed, and this file is where that is stated
+ *
+ * `secretValue` holds an AES-256-GCM envelope, never the plaintext an operator typed. The seal is
+ * applied on the way in and opened only by the resolver — see
+ * `provider-credential-envelope.backend.utils.ts` for the envelope and its key derivation. The
+ * schema cannot enforce that (a string is a string), so the write path is what guarantees it and
+ * the pins are what keep it guaranteed.
+ */
+import { z } from 'zod';
+/**
+ * Whether the stored credential has been shown to work against the provider.
+ *
+ * A closed vocabulary rather than a boolean because "we have never tried" and "we tried and it
+ * failed" are different states with different operator actions, and a boolean would merge them
+ * into the same falsy answer. `UNVALIDATED` is the honest default: storing a credential proves
+ * only that somebody typed one.
+ */
+export declare enum ProviderCredentialValidationState {
+    /** Stored, never exercised against the provider. The state every credential starts in. */
+    UNVALIDATED = "unvalidated",
+    /** The provider accepted it on its last use. */
+    VALID = "valid",
+    /** The provider rejected it on its last use — the operator must rotate it. */
+    INVALID = "invalid"
+}
+/**
+ * The organization's credential for one (provider, secret slug) pair.
+ *
+ * ## The scope identifier is TOP-LEVEL and stays that way
+ *
+ * `organizationId` is the only `organizationId`-named path in this schema, and nothing nested may
+ * ever be named `organizationId` or `userId`. `buildContextualFilter` injects the scope FK by
+ * matching that field name at EVERY schema path, so a nested key of the same name adds a phantom
+ * exact-subdocument clause and the scoped read silently matches zero rows — a credential that
+ * exists and cannot be resolved, which reads exactly like a credential that was never set.
+ * `setByUserId` is deliberately spelled so it cannot be caught by that matcher.
+ */
+/**
+ * WHERE a resolved provider secret came from.
+ *
+ * The whole point of this slice is that the answer used to be unanswerable: every secret came from
+ * `process.env`, so "which principal did this tenant act as?" had one answer for every tenant and
+ * nothing recorded it. Making the source an explicit, closed value means an audit reader can see a
+ * tenant falling back to the shared deployment credential — the exact condition the resource exists
+ * to make visible — instead of having to infer it from an absence.
+ */
+export declare enum ProviderCredentialResolutionSource {
+    /** The organization's own credential row. The tenant acted as itself. */
+    ORGANIZATION_CREDENTIAL = "organization_credential",
+    /**
+     * The deployment's env-projected `SecretsContract`. Legitimate — a single-tenant deployment, or a
+     * provider the operator intends every tenant to share — but never silent.
+     */
+    DEPLOYMENT_ENVIRONMENT = "deployment_environment",
+    /**
+     * A PERSON's own credential row. The application acted as that individual.
+     *
+     * This member has no sibling fallback, and that asymmetry is deliberate rather than an omission.
+     * An organization with no credential of its own may legitimately fall through to the deployment's
+     * — an operator can intend every tenant to share one integration. A person cannot: the vendor
+     * attributes the act to whoever's token was spent, so acting for someone under the deployment's
+     * principal would put the wrong name on the record that outlives us. A person who has connected
+     * nothing gets a refusal, not a substitute.
+     */
+    USER_CREDENTIAL = "user_credential"
+}
+/** Why a credential row stopped existing. */
+export declare enum ProviderCredentialDeletionReason {
+    /** An administrator of the owning tenant removed it. */
+    ADMINISTRATOR_REVOKED = "administrator_revoked",
+    /** The owning organization was purged and the composition cascade removed it with the tenant. */
+    ORGANIZATION_PURGED = "organization_purged",
+    /** The person whose credential it was removed it themselves. */
+    OWNER_REVOKED = "owner_revoked",
+    /**
+     * The owning user was erased and the composition cascade destroyed it with them.
+     *
+     * Distinct from `ORGANIZATION_PURGED` because this one is EVIDENCE: it is what an operator points
+     * at when asked whether a subject-erasure request reached the person's third-party credentials.
+     * Collapsing the two into a generic "cascade" would make that question unanswerable from the trail.
+     */
+    USER_ERASED = "user_erased"
+}
+/**
+ * The fields that IDENTIFY a credential within its tenant.
+ *
+ * One tenant holds at most one credential per (provider, slug). Exported rather than repeated so
+ * the uniqueness contract, the resolver's lookup and the tests cannot drift apart — three copies
+ * of a compound key is how two of them come to disagree about what identity means.
+ */
+export declare const ORGANIZATION_PROVIDER_CREDENTIAL_IDENTITY_FIELDS: readonly ["organizationId", "providerRef", "secretSlug"];
+export declare const OrganizationProviderCredentialSchema: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodObject<{
+    _id: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodString>>;
+    organizationId: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodString>>>>;
+    providerRef: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodString>>>;
+    secretSlug: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodString>>>;
+    secretValue: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodString>;
+    enabled: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodDefault<z.ZodBoolean>>>;
+    validationState: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodDefault<z.ZodEnum<typeof ProviderCredentialValidationState>>>>;
+    validationError: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodOptional<z.ZodString>>>;
+    lastValidatedAt: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodOptional<z.ZodDate>>>;
+    lastUsedAt: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodOptional<z.ZodDate>>>>;
+    setByUserId: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodOptional<z.ZodString>>>>;
+    secretSetAt: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodOptional<z.ZodDate>>>;
+    connectionParameters: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodString>>>;
+    description: z.ZodOptional<z.ZodString>;
+    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>>;
+export type OrganizationProviderCredential = z.infer<typeof OrganizationProviderCredentialSchema>;
+/**
+ * The fields that IDENTIFY a credential within its OWNER.
+ *
+ * Exported per owner rather than shared, because the compound key differs in its first component and
+ * a single constant would have to be assembled by each side — which is how two copies of a key come
+ * to disagree about what identity means.
+ */
+export declare const USER_PROVIDER_CREDENTIAL_IDENTITY_FIELDS: readonly ["userId", "providerRef", "secretSlug"];
+/**
+ * A PERSON's own credential toward a third party — the key they authored for themselves.
+ *
+ * ## Why this is a separate resource and not a nullable column beside the organization's
+ *
+ * Wildo's tenancy is STRUCTURAL: the contextual filter injects the scope FK by matching a field name
+ * at every schema path, so a resource belongs to exactly one primary scope. One table holding both a
+ * nullable `organizationId` and a nullable `userId` would turn that structural guarantee into a
+ * filter somebody has to remember to write, on the one resource where forgetting it discloses a
+ * credential. Two resources, each scoped by construction, is the framework working as designed
+ * rather than a duplication.
+ *
+ * ## Not a delegated OAuth grant, and the difference is not subtle
+ *
+ * This is a key the user PASTED: they hold an account with the vendor and chose to let this
+ * application spend it. A delegated grant is the vendor minting a token because the user approved a
+ * consent screen, and it carries a refresh loop, an expiry and a revocation the vendor also honours.
+ * Merging them would give one row two lifecycles and two revocation semantics — see #333, which owns
+ * the second.
+ *
+ * ## Only the holder may spend it
+ *
+ * Not an administrator of their organization, and not a platform operator. Consent to STORE a
+ * personal key is not consent for somebody else to use it, and the vendor would record the act as
+ * the holder's own. The authorization side of that is
+ * `InitiatorMembershipConnectionTargetAuthorization`; this schema is what makes the row reachable
+ * only through the owner's own scope.
+ */
+export declare const UserProviderCredentialSchema: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodObject<{
+    _id: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodString>>;
+    userId: 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>>>>;
+    providerRef: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodString>>>;
+    secretSlug: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodString>>>;
+    secretValue: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodString>;
+    enabled: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodDefault<z.ZodBoolean>>>;
+    validationState: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodDefault<z.ZodEnum<typeof ProviderCredentialValidationState>>>>;
+    validationError: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodOptional<z.ZodString>>>;
+    lastValidatedAt: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodOptional<z.ZodDate>>>;
+    lastUsedAt: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodOptional<z.ZodDate>>>>;
+    secretSetAt: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodOptional<z.ZodDate>>>;
+    connectionParameters: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodString>>>;
+    description: z.ZodOptional<z.ZodString>;
+    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>>;
+export type UserProviderCredential = z.infer<typeof UserProviderCredentialSchema>;
+/**
+ * What an authorization exchange gives back, as it is stored.
+ *
+ * Sealed as JSON into `secretValue`, so `.isWriteOnlySecret()` keeps masking it at the client
+ * boundary and the envelope keeps binding it to its row — both mechanisms work on a string and
+ * neither needs to know the string is structured.
+ */
+/**
+ * What SHAPE a sealed credential holds, once opened.
+ *
+ * One member today and a named vocabulary anyway, because the day a second sealed payload exists —
+ * a service-account key, a signed JWT assertion — the discriminant is what tells them apart, and a
+ * bare literal is where per-member explanation cannot live. It is also the value a reader needs to
+ * understand `PROVIDER_OAUTH2_GRANT_PREFIX`: the prefix is how the shape is recognised WITHOUT
+ * parsing, and this is what it recognises.
+ */
+export declare enum ProviderStoredCredentialKind {
+    /** An OAuth2 grant: an access token, and what is needed to renew it. */
+    OAUTH2_GRANT = "oauth2-grant"
+}
+export declare const ProviderOAuth2GrantSchema: z.ZodObject<{
+    kind: z.ZodLiteral<ProviderStoredCredentialKind>;
+    accessToken: z.ZodString;
+    refreshToken: z.ZodOptional<z.ZodString>;
+    expiresAt: z.ZodOptional<z.ZodISODateTime>;
+    grantedScopes: z.ZodOptional<z.ZodArray<z.ZodString>>;
+    accountRef: z.ZodOptional<z.ZodString>;
+}, z.core.$strip>;
+export type ProviderOAuth2Grant = z.infer<typeof ProviderOAuth2GrantSchema>;
+/**
+ * The marker that opens the sealed plaintext of a grant rather than a pasted credential.
+ *
+ * A prefix on the JSON rather than a field inside it, so the decision can be made without parsing —
+ * the same reason the envelope carries a prefix. Parsing first would mean feeding an arbitrary
+ * pasted credential to `JSON.parse` on every resolution.
+ */
+export declare const PROVIDER_OAUTH2_GRANT_PREFIX = "wildo-oauth2-grant:";
+/** Whether an OPENED credential is a grant. Cheap, and does not parse. */
+export declare function isProviderOAuth2GrantPlaintext(plaintext: string): boolean;
+/** Render a grant for sealing. The inverse of {@link parseProviderOAuth2Grant}. */
+export declare function serializeProviderOAuth2Grant(grant: ProviderOAuth2Grant): string;
+/**
+ * Read a grant back, or `undefined` when the plaintext is an ordinary pasted credential.
+ *
+ * THROWS when the value announces itself as a grant and then does not parse or does not validate.
+ * That is the same posture the envelope takes toward a value the write path could not have
+ * produced: a credential which claims a shape it does not have is a fault worth failing on, never
+ * one worth falling back from — falling back would put a JSON blob on the wire as a bearer token.
+ */
+export declare function parseProviderOAuth2Grant(plaintext: string): ProviderOAuth2Grant | undefined;
+/**
+ * Whether a grant should be refreshed BEFORE it is spent.
+ *
+ * The skew is what makes this useful rather than decorative: a token that expires in two seconds is
+ * still "valid" and will have expired by the time the request reaches the vendor, so refreshing only
+ * on expiry guarantees a population of calls that fail for a reason nothing recorded. Sixty seconds
+ * is the industry's common floor and comfortably exceeds any plausible clock skew plus flight time.
+ *
+ * Returns false when there is no expiry — a non-expiring token is refreshed reactively, after the
+ * vendor rejects it, because there is no deadline to act ahead of.
+ */
+export declare const PROVIDER_OAUTH2_REFRESH_SKEW_SECONDS = 60;
+export declare function providerOAuth2GrantNeedsRefresh(grant: ProviderOAuth2Grant, now?: Date): boolean;
+//# sourceMappingURL=provider-credentials.shared.schemas.d.ts.map

package/dist/esm/security/connected-accounts/provider-credentials.shared.schemas.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"provider-credentials.shared.schemas.d.ts","sourceRoot":"","sources":["../../../../../src/security/connected-accounts/provider-credentials.shared.schemas.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA6BG;AAEH,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AAExB;;;;;;;GAOG;AACH,oBAAY,iCAAiC;IAC3C,0FAA0F;IAC1F,WAAW,gBAAgB;IAC3B,gDAAgD;IAChD,KAAK,UAAU;IACf,8EAA8E;IAC9E,OAAO,YAAY;CACpB;AAED;;;;;;;;;;;GAWG;AACH;;;;;;;;GAQG;AACH,oBAAY,kCAAkC;IAC5C,yEAAyE;IACzE,uBAAuB,4BAA4B;IACnD;;;OAGG;IACH,sBAAsB,2BAA2B;IACjD;;;;;;;;;OASG;IACH,eAAe,oBAAoB;CACpC;AAED,6CAA6C;AAC7C,oBAAY,gCAAgC;IAC1C,wDAAwD;IACxD,qBAAqB,0BAA0B;IAC/C,iGAAiG;IACjG,mBAAmB,wBAAwB;IAC3C,gEAAgE;IAChE,aAAa,kBAAkB;IAC/B;;;;;;OAMG;IACH,WAAW,gBAAgB;CAC5B;AAED;;;;;;GAMG;AACH,eAAO,MAAM,gDAAgD,0DAInD,CAAC;AAEX,eAAO,MAAM,oCAAoC;;;;;;;;;;;;;;;;;kBAwHuB,CAAC;AAEzE,MAAM,MAAM,8BAA8B,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,oCAAoC,CAAC,CAAC;AAQlG;;;;;;GAMG;AACH,eAAO,MAAM,wCAAwC,kDAI3C,CAAC;AAEX;;;;;;;;;;;;;;;;;;;;;;;;;;;GA2BG;AACH,eAAO,MAAM,4BAA4B;;;;;;;;;;;;;;;;kBAgFuB,CAAC;AAEjE,MAAM,MAAM,sBAAsB,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,4BAA4B,CAAC,CAAC;AAsBlF;;;;;;GAMG;AACH;;;;;;;;GAQG;AACH,oBAAY,4BAA4B;IACtC,wEAAwE;IACxE,YAAY,iBAAiB;CAC9B;AAED,eAAO,MAAM,yBAAyB;;;;;;;iBAgDpC,CAAC;AAEH,MAAM,MAAM,mBAAmB,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,yBAAyB,CAAC,CAAC;AAE5E;;;;;;GAMG;AACH,eAAO,MAAM,4BAA4B,wBAAwB,CAAC;AAElE,0EAA0E;AAC1E,wBAAgB,8BAA8B,CAAC,SAAS,EAAE,MAAM,GAAG,OAAO,CAEzE;AAED,mFAAmF;AACnF,wBAAgB,4BAA4B,CAAC,KAAK,EAAE,mBAAmB,GAAG,MAAM,CAE/E;AAED;;;;;;;GAOG;AACH,wBAAgB,wBAAwB,CAAC,SAAS,EAAE,MAAM,GAAG,mBAAmB,GAAG,SAAS,CAqB3F;AAED;;;;;;;;;;GAUG;AACH,eAAO,MAAM,oCAAoC,KAAK,CAAC;AAEvD,wBAAgB,+BAA+B,CAAC,KAAK,EAAE,mBAAmB,EAAE,GAAG,GAAE,IAAiB,GAAG,OAAO,CAK3G"}