@wildo-ai/saas-models 1.1.3 → 1.1.5

package/dist/esm/security/authentications/siem/siem-delivery-outbox.shared.resources-config.schemas.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"siem-delivery-outbox.shared.resources-config.schemas.js","sourceRoot":"","sources":["../../../../../../src/security/authentications/siem/siem-delivery-outbox.shared.resources-config.schemas.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AAEH,OAAO,EAAE,qBAAqB,EAAE,gBAAgB,EAAE,MAAM,sDAAsD,CAAC;AAC/G,OAAO,EACL,0BAA0B,EAC1B,4BAA4B,GAC7B,MAAM,6CAA6C,CAAC;AACrD,OAAO,EAAE,uCAAuC,EAAE,MAAM,wDAAwD,CAAC;AACjH,OAAO,EAAE,cAAc,EAAE,cAAc,EAAE,MAAM,2CAA2C,CAAC;AAC3F,OAAO,EAAE,wCAAwC,EAAE,MAAM,uCAAuC,CAAC;AAEjG;;;;;;GAMG;AACH,MAAM,0BAA0B,GAA6B;IAC3D,CAAC,gBAAgB,CAAC,aAAa,CAAC,EAAE,CAAC,cAAc,CAAC,SAAS,CAAC;IAC5D,CAAC,gBAAgB,CAAC,WAAW,CAAC,EAAE,CAAC,cAAc,CAAC,qBAAqB,CAAC;CACvE,CAAC;AAEF,MAAM,CAAC,MAAM,sCAAsC,GAAG,uCAAuC,CAC3F,wCAAwC,EACxC;IACE,gBAAgB,EAAE,IAAI;IACtB,cAAc,EAAE;QACd,iCAAiC;QACjC,qBAAqB,CAAC,MAAM;QAC5B,wDAAwD;QACxD,qBAAqB,CAAC,IAAI;QAC1B,gGAAgG;QAChG,qBAAqB,CAAC,IAAI;QAC1B,iFAAiF;QACjF,qBAAqB,CAAC,MAAM;QAC5B,yFAAyF;QACzF,0EAA0E;QAC1E,qBAAqB,CAAC,MAAM;QAC5B,sFAAsF;QACtF,qBAAqB,CAAC,WAAW;KAClC;IACD,uBAAuB,EAAE;QACvB,CAAC,qBAAqB,CAAC,MAAM,CAAC,EAAE;YAC9B,QAAQ,EAAE,CAAC;oBACT,WAAW,EAAE,4BAA4B,CAAC,eAAe;oBACzD,SAAS,EAAE,IAAI;oBACf,eAAe,EAAE,0BAA0B;oBAC3C,SAAS,EAAE,0BAA0B,CAAC,GAAG;iBAC1C,CAAC;SACH;QACD,CAAC,qBAAqB,CAAC,IAAI,CAAC,EAAE;YAC5B,QAAQ,EAAE,CAAC;oBACT,WAAW,EAAE,4BAA4B,CAAC,eAAe;oBACzD,SAAS,EAAE,IAAI;oBACf,eAAe,EAAE,0BAA0B;oBAC3C,SAAS,EAAE,0BAA0B,CAAC,GAAG;iBAC1C,CAAC;SACH;QACD,CAAC,qBAAqB,CAAC,IAAI,CAAC,EAAE;YAC5B,QAAQ,EAAE,CAAC;oBACT,WAAW,EAAE,4BAA4B,CAAC,eAAe;oBACzD,SAAS,EAAE,IAAI;oBACf,eAAe,EAAE,0BAA0B;oBAC3C,SAAS,EAAE,0BAA0B,CAAC,GAAG;iBAC1C,CAAC;SACH;QACD,CAAC,qBAAqB,CAAC,MAAM,CAAC,EAAE;YAC9B,QAAQ,EAAE,CAAC;oBACT,WAAW,EAAE,4BAA4B,CAAC,eAAe;oBACzD,SAAS,EAAE,IAAI;oBACf,eAAe,EAAE,0BAA0B;oBAC3C,SAAS,EAAE,0BAA0B,CAAC,GAAG;iBAC1C,CAAC;SACH;QACD,CAAC,qBAAqB,CAAC,MAAM,CAAC,EAAE;YAC9B,QAAQ,EAAE,CAAC;oBACT,WAAW,EAAE,4BAA4B,CAAC,eAAe;oBACzD,SAAS,EAAE,IAAI;oBACf,eAAe,EAAE,0BAA0B;oBAC3C,SAAS,EAAE,0BAA0B,CAAC,MAAM;iBAC7C,CAAC;SACH;QACD,CAAC,qBAAqB,CAAC,WAAW,CAAC,EAAE;YACnC,QAAQ,EAAE,CAAC;oBACT,WAAW,EAAE,4BAA4B,CAAC,eAAe;oBACzD,SAAS,EAAE,IAAI;oBACf,eAAe,EAAE,0BAA0B;oBAC3C,SAAS,EAAE,0BAA0B,CAAC,MAAM;iBAC7C,CAAC;SACH;KACF;CACF,CACF,CAAC","sourcesContent":["/**\n * SIEM Delivery Outbox Resource Configuration — Polymorphic\n *\n * Produces 2 factory functions (ORG + APP) via the polymorphic factory.\n * Spread into the registry factory map:\n *   ...siemDeliveryOutboxPolymorphicFactories\n *\n * ## Every operation is REPOSITORY_ONLY, and that is the whole configuration\n *\n * This resource has no HTTP surface at all — no `API_CALL` variant, no custom operation, nothing an\n * operator can address. It differs from its DLQ sibling in exactly that way, and deliberately: the\n * DLQ is a triage surface a human works (retry this, purge those), while the outbox is machinery\n * mid-flight. A row here is owned by the collector between the moment an event is accepted and the\n * moment a collector takes it, which is ordinarily under a minute.\n *\n * Exposing it would create an operator affordance over rows that a concurrent flush may be claiming\n * — a delete racing a claim, a \"retry\" on something already in flight — for no question a human\n * actually has. The question an operator DOES have (\"what failed to reach my SIEM?\") is the DLQ's,\n * and it is already answered there.\n *\n * So the roles below gate repository-tier resolution only; they are not a permission an HTTP request\n * can ever exercise. They mirror the DLQ's rather than inventing a second answer, because a scope\n * that may read its dead letters is the same scope that would own its pending ones.\n */\n\nimport { CoreResourceOperation, CoreResourceType } from '../../../resources/resources.shared.core.definitions';\nimport {\n  ResourceOperationRiskLevel,\n  ResourceOperationVariantType,\n} from '../../../resources/resources.shared.schemas';\nimport { createPolymorphicResourceConfigurations } from '../../../resources/utils/resource-polymorphism.factory';\nimport { CORE_ORG_ROLES, CORE_APP_ROLES } from '../../authorizations/roles.shared.schemas';\nimport { siemDeliveryOutboxPolymorphicDeclaration } from './siem-delivery-outbox.shared.schemas';\n\n/**\n * The polymorphic role map every operation here carries — one object rather than six copies.\n *\n * The DLQ declares its identical map inline at each of its six operations, which is how a role set\n * comes to disagree with itself one operation at a time. There is nothing per-operation to vary:\n * the answer is \"the scope's administrator\", for all of them.\n */\nconst SIEM_DELIVERY_OUTBOX_ROLES: Record<string, string[]> = {\n  [CoreResourceType.ORGANIZATIONS]: [CORE_ORG_ROLES.ORG_ADMIN],\n  [CoreResourceType.APPLICATION]: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],\n};\n\nexport const siemDeliveryOutboxPolymorphicFactories = createPolymorphicResourceConfigurations(\n  siemDeliveryOutboxPolymorphicDeclaration,\n  {\n    isSystemResource: true,\n    coreOperations: [\n      // The append, on the audit path.\n      CoreResourceOperation.CREATE,\n      // The claim reads a row back after its compare-and-set.\n      CoreResourceOperation.READ,\n      // Pending-set queries: by destination, oldest first, and the count that fires the size trigger.\n      CoreResourceOperation.LIST,\n      // The claim itself — `atomicConditionalSet` resolves a DEFAULT UPDATE operation.\n      CoreResourceOperation.UPDATE,\n      // A delivered row is gone; there is no terminal state to keep. The DLQ is where a FAILED\n      // delivery is retained, and a row that succeeded has nothing left to say.\n      CoreResourceOperation.DELETE,\n      // Bulk twin of DELETE: one flush retires its whole claimed set in a single statement.\n      CoreResourceOperation.DELETE_MANY,\n    ],\n    operationsConfiguration: {\n      [CoreResourceOperation.CREATE]: {\n        variants: [{\n          variantType: ResourceOperationVariantType.REPOSITORY_ONLY,\n          isDefault: true,\n          polymorphicRole: SIEM_DELIVERY_OUTBOX_ROLES,\n          riskLevel: ResourceOperationRiskLevel.LOW,\n        }],\n      },\n      [CoreResourceOperation.READ]: {\n        variants: [{\n          variantType: ResourceOperationVariantType.REPOSITORY_ONLY,\n          isDefault: true,\n          polymorphicRole: SIEM_DELIVERY_OUTBOX_ROLES,\n          riskLevel: ResourceOperationRiskLevel.LOW,\n        }],\n      },\n      [CoreResourceOperation.LIST]: {\n        variants: [{\n          variantType: ResourceOperationVariantType.REPOSITORY_ONLY,\n          isDefault: true,\n          polymorphicRole: SIEM_DELIVERY_OUTBOX_ROLES,\n          riskLevel: ResourceOperationRiskLevel.LOW,\n        }],\n      },\n      [CoreResourceOperation.UPDATE]: {\n        variants: [{\n          variantType: ResourceOperationVariantType.REPOSITORY_ONLY,\n          isDefault: true,\n          polymorphicRole: SIEM_DELIVERY_OUTBOX_ROLES,\n          riskLevel: ResourceOperationRiskLevel.LOW,\n        }],\n      },\n      [CoreResourceOperation.DELETE]: {\n        variants: [{\n          variantType: ResourceOperationVariantType.REPOSITORY_ONLY,\n          isDefault: true,\n          polymorphicRole: SIEM_DELIVERY_OUTBOX_ROLES,\n          riskLevel: ResourceOperationRiskLevel.MEDIUM,\n        }],\n      },\n      [CoreResourceOperation.DELETE_MANY]: {\n        variants: [{\n          variantType: ResourceOperationVariantType.REPOSITORY_ONLY,\n          isDefault: true,\n          polymorphicRole: SIEM_DELIVERY_OUTBOX_ROLES,\n          riskLevel: ResourceOperationRiskLevel.MEDIUM,\n        }],\n      },\n    },\n  },\n);\n"]}

package/dist/esm/security/authentications/siem/siem-delivery-outbox.shared.schemas.d.ts

@@ -0,0 +1,66 @@
+/**
+ * SIEM Delivery Outbox Schema (Shared) — Polymorphic
+ *
+ * One row per security audit event that is WAITING to be delivered, so that several events can leave
+ * as ONE HTTP request. The sibling of `siem-delivery-dlq.shared.schemas.ts` one step earlier in the
+ * lane: the DLQ holds what FAILED, this holds what has not been sent yet.
+ *
+ * ## Why a durable row rather than an in-memory buffer (#1379)
+ *
+ * The delivery worker posts one event per request because the job is created PER EVENT at enqueue —
+ * `processDelivery` is handed one payload and no parameter it receives could ever batch. Grouping
+ * therefore has to happen before the queue, and the group has to survive a restart: an event that is
+ * already durable on the broker today must not become an event held in a process's heap. So the
+ * pending set is a resource, written before the event's job is acknowledged and deleted only once the
+ * collector has taken it.
+ *
+ * An in-memory accumulator was rejected for exactly that reason, and a second candidate — holding the
+ * events as UNACKED broker deliveries — was rejected on a measurement: `consume()` runs on the single
+ * primary channel and `channel.prefetch(1)` is set on it, so at most ONE delivery is ever in flight
+ * per process and no accumulation is possible without a second channel. Keeping the durable half of
+ * this lane in one place (the broker for transport, this table for grouping) is the simpler story.
+ *
+ * ## The two columns that carry the design
+ *
+ * `destinationKey` is what makes a batch legitimate: a request carries one URL, one auth method and
+ * one credential, so rows may only travel together when those agree. It is a FINGERPRINT of the
+ * transport configuration rather than the configuration itself, so a config change mid-window simply
+ * starts a new key — the rows enqueued under the old one flush under the configuration they were
+ * authored against, which is the only honest reading of "this event was exported to that destination".
+ *
+ * `claimId` is what makes concurrent collectors safe. Two replicas may flush the same destination at
+ * the same instant; each stamps the rows it intends to send with its own id under a compare-and-set,
+ * so a row belongs to exactly one request and the two batches are disjoint rather than duplicated.
+ *
+ * ── ORG variant is live; the APPLICATION variant is RESERVED / DORMANT ─────────────
+ * Declared over `AUTH_SCOPE_VARIANTS` like every other SIEM resource, and populated only for the
+ * ORGANIZATION scope for the same reason: the sole delivery producer is org-scoped. See
+ * `AuditEventDispatcherBackendService.dispatchToOrganizationAuditSinks`.
+ */
+import { z } from 'zod';
+export declare const SiemDeliveryOutboxBaseSchema: z.ZodObject<{
+    _id: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodString>>;
+    eventId: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodString>>;
+    destinationKey: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodString>>;
+    deliveryPayload: z.ZodUnknown;
+    deliveryAttempt: z.ZodDefault<z.ZodNumber>;
+    claimId: z.ZodOptional<z.ZodString>;
+    claimedAt: z.ZodOptional<z.ZodDate>;
+    nextAttemptAt: z.ZodOptional<z.ZodDate>;
+    createdAt: 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<z.ZodDefault<z.ZodDate>>>;
+}, z.core.$strip>;
+export type SiemDeliveryOutboxBase = z.infer<typeof SiemDeliveryOutboxBaseSchema>;
+export declare const siemDeliveryOutboxPolymorphicDeclaration: import("../../..").PolymorphicSchemaDeclaration<z.ZodObject<{
+    _id: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodString>>;
+    eventId: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodString>>;
+    destinationKey: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodString>>;
+    deliveryPayload: z.ZodUnknown;
+    deliveryAttempt: z.ZodDefault<z.ZodNumber>;
+    claimId: z.ZodOptional<z.ZodString>;
+    claimedAt: z.ZodOptional<z.ZodDate>;
+    nextAttemptAt: z.ZodOptional<z.ZodDate>;
+    createdAt: 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<z.ZodDefault<z.ZodDate>>>;
+}, z.core.$strip>>;
+//# sourceMappingURL=siem-delivery-outbox.shared.schemas.d.ts.map

package/dist/esm/security/authentications/siem/siem-delivery-outbox.shared.schemas.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"siem-delivery-outbox.shared.schemas.d.ts","sourceRoot":"","sources":["../../../../../../src/security/authentications/siem/siem-delivery-outbox.shared.schemas.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAsCG;AAEH,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AAMxB,eAAO,MAAM,4BAA4B;;;;;;;;;;;iBA2DvC,CAAC;AAEH,MAAM,MAAM,sBAAsB,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,4BAA4B,CAAC,CAAC;AAElF,eAAO,MAAM,wCAAwC;;;;;;;;;;;kBAQnD,CAAC"}

package/dist/esm/security/authentications/siem/siem-delivery-outbox.shared.schemas.js

@@ -0,0 +1,107 @@
+/**
+ * SIEM Delivery Outbox Schema (Shared) — Polymorphic
+ *
+ * One row per security audit event that is WAITING to be delivered, so that several events can leave
+ * as ONE HTTP request. The sibling of `siem-delivery-dlq.shared.schemas.ts` one step earlier in the
+ * lane: the DLQ holds what FAILED, this holds what has not been sent yet.
+ *
+ * ## Why a durable row rather than an in-memory buffer (#1379)
+ *
+ * The delivery worker posts one event per request because the job is created PER EVENT at enqueue —
+ * `processDelivery` is handed one payload and no parameter it receives could ever batch. Grouping
+ * therefore has to happen before the queue, and the group has to survive a restart: an event that is
+ * already durable on the broker today must not become an event held in a process's heap. So the
+ * pending set is a resource, written before the event's job is acknowledged and deleted only once the
+ * collector has taken it.
+ *
+ * An in-memory accumulator was rejected for exactly that reason, and a second candidate — holding the
+ * events as UNACKED broker deliveries — was rejected on a measurement: `consume()` runs on the single
+ * primary channel and `channel.prefetch(1)` is set on it, so at most ONE delivery is ever in flight
+ * per process and no accumulation is possible without a second channel. Keeping the durable half of
+ * this lane in one place (the broker for transport, this table for grouping) is the simpler story.
+ *
+ * ## The two columns that carry the design
+ *
+ * `destinationKey` is what makes a batch legitimate: a request carries one URL, one auth method and
+ * one credential, so rows may only travel together when those agree. It is a FINGERPRINT of the
+ * transport configuration rather than the configuration itself, so a config change mid-window simply
+ * starts a new key — the rows enqueued under the old one flush under the configuration they were
+ * authored against, which is the only honest reading of "this event was exported to that destination".
+ *
+ * `claimId` is what makes concurrent collectors safe. Two replicas may flush the same destination at
+ * the same instant; each stamps the rows it intends to send with its own id under a compare-and-set,
+ * so a row belongs to exactly one request and the two batches are disjoint rather than duplicated.
+ *
+ * ── ORG variant is live; the APPLICATION variant is RESERVED / DORMANT ─────────────
+ * Declared over `AUTH_SCOPE_VARIANTS` like every other SIEM resource, and populated only for the
+ * ORGANIZATION scope for the same reason: the sole delivery producer is org-scoped. See
+ * `AuditEventDispatcherBackendService.dispatchToOrganizationAuditSinks`.
+ */
+import { z } from 'zod';
+import { PersonalDataCategory } from '../../../compliance/privacy/personal-data-category.shared.schemas.js';
+import { addDataCategories } from '@wildo-ai/zod-decorators';
+import { AUTH_SCOPE_VARIANTS } from '../authentication.shared.schemas.js';
+import { declarePolymorphicSchemas, optOutPolymorphicAutoBusinessKey } from '../../../resources/utils/resource-polymorphism.schemas.js';
+export const SiemDeliveryOutboxBaseSchema = z.object({
+    _id: z.string().min(1).isPrimaryKey().isSummaryField(),
+    /**
+     * The envelope's own event id. Also the idempotency key for the append: the event's job may be
+     * redelivered by the broker after a crash between the append and the acknowledgement, and appending
+     * twice would put the same event in the batch twice.
+     */
+    eventId: z.string().min(1).isDBIndexed().isSummaryField(),
+    /**
+     * Fingerprint of the transport configuration this event is bound for — see the header. Indexed
+     * because every collector query filters on it: it is the unit a batch is assembled over.
+     */
+    destinationKey: z.string().min(1).isDBIndexed().isSummaryField(),
+    /**
+     * The delivery job payload as the dispatcher built it: the envelope, its F6 HMAC, the attempt
+     * number and the projected transport config.
+     *
+     * Stored WHOLE rather than decomposed so the collector sends exactly what the one-event path would
+     * have sent. The alternative — rebuilding a payload at flush time from parts — is the shape that
+     * lets a batched delivery drift from an unbatched one, and the enqueue seam exists precisely to
+     * stop two producers building different payloads for the same event.
+     *
+     * USAGE — this is a security audit event awaiting export, so it carries the same personal data the
+     * audit row does, for as long as it waits. `addDataCategories` because `z.unknown()` carries no
+     * prototype-installed decorators.
+     */
+    deliveryPayload: addDataCategories(z.unknown(), PersonalDataCategory.USAGE),
+    /**
+     * Which delivery attempt this event is on, carried across flushes.
+     *
+     * The per-event retry ceiling is unchanged by batching: a rejected event advances its own counter
+     * and dead-letters at `retryAttempts` exactly as it does today, whether it was rejected alone or as
+     * one of fifty. Holding the counter per ROW is what keeps that true — a counter held per BATCH
+     * would make one event's failure spend another's budget.
+     */
+    deliveryAttempt: z.number().int().min(0).default(0),
+    /**
+     * The collector run that owns this row, or absent while it is unclaimed.
+     *
+     * A compare-and-set on this field is the whole concurrency story: a flush claims only rows where it
+     * is absent, so two simultaneous flushes of one destination partition the pending set instead of
+     * both sending it.
+     */
+    claimId: z.string().optional(),
+    claimedAt: z.date().optional(),
+    /**
+     * When this event may next be attempted — set when a flush defers it under backpressure or after a
+     * failed attempt's backoff. Absent means "eligible now".
+     */
+    nextAttemptAt: z.date().optional(),
+    createdAt: z.date().default(() => new Date()).isSummaryField().excludeFromCreate().excludeFromUpdate(),
+    updatedAt: z.date().default(() => new Date()).excludeFromCreate().excludeFromUpdate(),
+});
+export const siemDeliveryOutboxPolymorphicDeclaration = declarePolymorphicSchemas({
+    baseResourceType: 'siemDeliveryOutbox',
+    baseFieldIdentifier: 'siemDeliveryOutboxId',
+    baseEnumKey: 'SIEM_DELIVERY_OUTBOX',
+    baseSchema: SiemDeliveryOutboxBaseSchema,
+    // Many pending rows per scope — opt out of the polymorphism engine's singleton-per-scope
+    // auto-business-key, exactly as the DLQ sibling does.
+    variants: AUTH_SCOPE_VARIANTS.map(optOutPolymorphicAutoBusinessKey),
+});
+//# sourceMappingURL=siem-delivery-outbox.shared.schemas.js.map

package/dist/esm/security/authentications/siem/siem-delivery-outbox.shared.schemas.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"siem-delivery-outbox.shared.schemas.js","sourceRoot":"","sources":["../../../../../../src/security/authentications/siem/siem-delivery-outbox.shared.schemas.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAsCG;AAEH,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AACxB,OAAO,EAAE,oBAAoB,EAAE,MAAM,mEAAmE,CAAC;AACzG,OAAO,EAAE,iBAAiB,EAAE,MAAM,0BAA0B,CAAC;AAC7D,OAAO,EAAE,mBAAmB,EAAE,MAAM,kCAAkC,CAAC;AACvE,OAAO,EAAE,yBAAyB,EAAE,gCAAgC,EAAE,MAAM,wDAAwD,CAAC;AAErI,MAAM,CAAC,MAAM,4BAA4B,GAAG,CAAC,CAAC,MAAM,CAAC;IACnD,GAAG,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,YAAY,EAAE,CAAC,cAAc,EAAE;IAEtD;;;;OAIG;IACH,OAAO,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,WAAW,EAAE,CAAC,cAAc,EAAE;IAEzD;;;OAGG;IACH,cAAc,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,WAAW,EAAE,CAAC,cAAc,EAAE;IAEhE;;;;;;;;;;;;OAYG;IACH,eAAe,EAAE,iBAAiB,CAAC,CAAC,CAAC,OAAO,EAAE,EAAE,oBAAoB,CAAC,KAAK,CAAC;IAE3E;;;;;;;OAOG;IACH,eAAe,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,OAAO,CAAC,CAAC,CAAC;IAEnD;;;;;;OAMG;IACH,OAAO,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;IAC9B,SAAS,EAAE,CAAC,CAAC,IAAI,EAAE,CAAC,QAAQ,EAAE;IAE9B;;;OAGG;IACH,aAAa,EAAE,CAAC,CAAC,IAAI,EAAE,CAAC,QAAQ,EAAE;IAElC,SAAS,EAAE,CAAC,CAAC,IAAI,EAAE,CAAC,OAAO,CAAC,GAAG,EAAE,CAAC,IAAI,IAAI,EAAE,CAAC,CAAC,cAAc,EAAE,CAAC,iBAAiB,EAAE,CAAC,iBAAiB,EAAE;IACtG,SAAS,EAAE,CAAC,CAAC,IAAI,EAAE,CAAC,OAAO,CAAC,GAAG,EAAE,CAAC,IAAI,IAAI,EAAE,CAAC,CAAC,iBAAiB,EAAE,CAAC,iBAAiB,EAAE;CACtF,CAAC,CAAC;AAIH,MAAM,CAAC,MAAM,wCAAwC,GAAG,yBAAyB,CAAC;IAChF,gBAAgB,EAAE,oBAAoB;IACtC,mBAAmB,EAAE,sBAAsB;IAC3C,WAAW,EAAE,sBAAsB;IACnC,UAAU,EAAE,4BAA4B;IACxC,yFAAyF;IACzF,sDAAsD;IACtD,QAAQ,EAAE,mBAAmB,CAAC,GAAG,CAAC,gCAAgC,CAAC;CACpE,CAAC,CAAC","sourcesContent":["/**\n * SIEM Delivery Outbox Schema (Shared) — Polymorphic\n *\n * One row per security audit event that is WAITING to be delivered, so that several events can leave\n * as ONE HTTP request. The sibling of `siem-delivery-dlq.shared.schemas.ts` one step earlier in the\n * lane: the DLQ holds what FAILED, this holds what has not been sent yet.\n *\n * ## Why a durable row rather than an in-memory buffer (#1379)\n *\n * The delivery worker posts one event per request because the job is created PER EVENT at enqueue —\n * `processDelivery` is handed one payload and no parameter it receives could ever batch. Grouping\n * therefore has to happen before the queue, and the group has to survive a restart: an event that is\n * already durable on the broker today must not become an event held in a process's heap. So the\n * pending set is a resource, written before the event's job is acknowledged and deleted only once the\n * collector has taken it.\n *\n * An in-memory accumulator was rejected for exactly that reason, and a second candidate — holding the\n * events as UNACKED broker deliveries — was rejected on a measurement: `consume()` runs on the single\n * primary channel and `channel.prefetch(1)` is set on it, so at most ONE delivery is ever in flight\n * per process and no accumulation is possible without a second channel. Keeping the durable half of\n * this lane in one place (the broker for transport, this table for grouping) is the simpler story.\n *\n * ## The two columns that carry the design\n *\n * `destinationKey` is what makes a batch legitimate: a request carries one URL, one auth method and\n * one credential, so rows may only travel together when those agree. It is a FINGERPRINT of the\n * transport configuration rather than the configuration itself, so a config change mid-window simply\n * starts a new key — the rows enqueued under the old one flush under the configuration they were\n * authored against, which is the only honest reading of \"this event was exported to that destination\".\n *\n * `claimId` is what makes concurrent collectors safe. Two replicas may flush the same destination at\n * the same instant; each stamps the rows it intends to send with its own id under a compare-and-set,\n * so a row belongs to exactly one request and the two batches are disjoint rather than duplicated.\n *\n * ── ORG variant is live; the APPLICATION variant is RESERVED / DORMANT ─────────────\n * Declared over `AUTH_SCOPE_VARIANTS` like every other SIEM resource, and populated only for the\n * ORGANIZATION scope for the same reason: the sole delivery producer is org-scoped. See\n * `AuditEventDispatcherBackendService.dispatchToOrganizationAuditSinks`.\n */\n\nimport { z } from 'zod';\nimport { PersonalDataCategory } from '../../../compliance/privacy/personal-data-category.shared.schemas';\nimport { addDataCategories } from '@wildo-ai/zod-decorators';\nimport { AUTH_SCOPE_VARIANTS } from '../authentication.shared.schemas';\nimport { declarePolymorphicSchemas, optOutPolymorphicAutoBusinessKey } from '../../../resources/utils/resource-polymorphism.schemas';\n\nexport const SiemDeliveryOutboxBaseSchema = z.object({\n  _id: z.string().min(1).isPrimaryKey().isSummaryField(),\n\n  /**\n   * The envelope's own event id. Also the idempotency key for the append: the event's job may be\n   * redelivered by the broker after a crash between the append and the acknowledgement, and appending\n   * twice would put the same event in the batch twice.\n   */\n  eventId: z.string().min(1).isDBIndexed().isSummaryField(),\n\n  /**\n   * Fingerprint of the transport configuration this event is bound for — see the header. Indexed\n   * because every collector query filters on it: it is the unit a batch is assembled over.\n   */\n  destinationKey: z.string().min(1).isDBIndexed().isSummaryField(),\n\n  /**\n   * The delivery job payload as the dispatcher built it: the envelope, its F6 HMAC, the attempt\n   * number and the projected transport config.\n   *\n   * Stored WHOLE rather than decomposed so the collector sends exactly what the one-event path would\n   * have sent. The alternative — rebuilding a payload at flush time from parts — is the shape that\n   * lets a batched delivery drift from an unbatched one, and the enqueue seam exists precisely to\n   * stop two producers building different payloads for the same event.\n   *\n   * USAGE — this is a security audit event awaiting export, so it carries the same personal data the\n   * audit row does, for as long as it waits. `addDataCategories` because `z.unknown()` carries no\n   * prototype-installed decorators.\n   */\n  deliveryPayload: addDataCategories(z.unknown(), PersonalDataCategory.USAGE),\n\n  /**\n   * Which delivery attempt this event is on, carried across flushes.\n   *\n   * The per-event retry ceiling is unchanged by batching: a rejected event advances its own counter\n   * and dead-letters at `retryAttempts` exactly as it does today, whether it was rejected alone or as\n   * one of fifty. Holding the counter per ROW is what keeps that true — a counter held per BATCH\n   * would make one event's failure spend another's budget.\n   */\n  deliveryAttempt: z.number().int().min(0).default(0),\n\n  /**\n   * The collector run that owns this row, or absent while it is unclaimed.\n   *\n   * A compare-and-set on this field is the whole concurrency story: a flush claims only rows where it\n   * is absent, so two simultaneous flushes of one destination partition the pending set instead of\n   * both sending it.\n   */\n  claimId: z.string().optional(),\n  claimedAt: z.date().optional(),\n\n  /**\n   * When this event may next be attempted — set when a flush defers it under backpressure or after a\n   * failed attempt's backoff. Absent means \"eligible now\".\n   */\n  nextAttemptAt: z.date().optional(),\n\n  createdAt: z.date().default(() => new Date()).isSummaryField().excludeFromCreate().excludeFromUpdate(),\n  updatedAt: z.date().default(() => new Date()).excludeFromCreate().excludeFromUpdate(),\n});\n\nexport type SiemDeliveryOutboxBase = z.infer<typeof SiemDeliveryOutboxBaseSchema>;\n\nexport const siemDeliveryOutboxPolymorphicDeclaration = declarePolymorphicSchemas({\n  baseResourceType: 'siemDeliveryOutbox',\n  baseFieldIdentifier: 'siemDeliveryOutboxId',\n  baseEnumKey: 'SIEM_DELIVERY_OUTBOX',\n  baseSchema: SiemDeliveryOutboxBaseSchema,\n  // Many pending rows per scope — opt out of the polymorphism engine's singleton-per-scope\n  // auto-business-key, exactly as the DLQ sibling does.\n  variants: AUTH_SCOPE_VARIANTS.map(optOutPolymorphicAutoBusinessKey),\n});\n"]}

package/dist/esm/security/authentications/siem/siem-export-config.shared.resources-config.schemas.d.ts

@@ -6,5 +6,24 @@
  *   ...siemExportConfigPolymorphicFactories
  */
 import { CoreResourceOperation } from '../../../resources/resources.shared.core.definitions';
+import { ResourceOperationVariantType } from '../../../resources/resources.shared.schemas';
+/**
+ * The variant type each SIEM-export-config WRITE runs on — the one named source both this configuration
+ * and the backend hooks registered on these writes read (credential sealing, cache invalidation, change
+ * audit).
+ *
+ * A custom implementation is keyed by `(resource, operation, variantType)`. Until #953 each hook
+ * restated `INTERNAL_CALL` by hand, so moving UPDATE onto its API_CALL door meant editing four files
+ * in lockstep, and the first one missed would silently stop sealing credentials. Startup validation
+ * would refuse the mismatch, but only once the process was already starting.
+ *
+ * - `CREATE` stays `INTERNAL_CALL`: the row is seeded, or lazily materialised on the userless login
+ *   path, and never created self-serve.
+ * - `UPDATE` is `API_CALL`: the admin's edit door.
+ */
+export declare const SIEM_EXPORT_CONFIG_WRITE_VARIANT_TYPE: Readonly<{
+    [CoreResourceOperation.CREATE]: ResourceOperationVariantType.INTERNAL_CALL;
+    [CoreResourceOperation.UPDATE]: ResourceOperationVariantType.API_CALL;
+}>;
 export declare const siemExportConfigPolymorphicFactories: Record<string, import("../../..").ResourceConfiguration_InitializationFactory<undefined, CoreResourceOperation.READ | CoreResourceOperation.UPDATE | CoreResourceOperation.DELETE | CoreResourceOperation.CREATE, any>>;
 //# sourceMappingURL=siem-export-config.shared.resources-config.schemas.d.ts.map

package/dist/esm/security/authentications/siem/siem-export-config.shared.resources-config.schemas.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"siem-export-config.shared.resources-config.schemas.d.ts","sourceRoot":"","sources":["../../../../../../src/security/authentications/siem/siem-export-config.shared.resources-config.schemas.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;AAEH,OAAO,EAAE,qBAAqB,EAAoB,MAAM,sDAAsD,CAAC;AAY/G,eAAO,MAAM,oCAAoC,yNA0FhD,CAAC"}
+{"version":3,"file":"siem-export-config.shared.resources-config.schemas.d.ts","sourceRoot":"","sources":["../../../../../../src/security/authentications/siem/siem-export-config.shared.resources-config.schemas.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;AAEH,OAAO,EAAE,qBAAqB,EAAoB,MAAM,sDAAsD,CAAC;AAC/G,OAAO,EAEL,4BAA4B,EAC7B,MAAM,6CAA6C,CAAC;AAQrD;;;;;;;;;;;;;GAaG;AACH,eAAO,MAAM,qCAAqC,EAAE,QAAQ,CAAC;IAG3D,CAAC,qBAAqB,CAAC,MAAM,CAAC,EAAE,4BAA4B,CAAC,aAAa,CAAC;IAC3E,CAAC,qBAAqB,CAAC,MAAM,CAAC,EAAE,4BAA4B,CAAC,QAAQ,CAAC;CACvE,CAGA,CAAC;AAIF,eAAO,MAAM,oCAAoC,yNA4GhD,CAAC"}

package/dist/esm/security/authentications/siem/siem-export-config.shared.resources-config.schemas.js

@@ -11,6 +11,25 @@ import { createPolymorphicResourceConfigurations } from '../../../resources/util
 import { ResourceSystemAccessMode } from '../../../resources/resources-config.shared.schemas.js';
 import { CORE_ORG_ROLES, CORE_APP_ROLES } from '../../authorizations/roles.shared.schemas.js';
 import { siemExportConfigPolymorphicDeclaration } from './siem-export-config.shared.schemas.js';
+// ── Write variants ───────────────────────────────────────────────────
+/**
+ * The variant type each SIEM-export-config WRITE runs on — the one named source both this configuration
+ * and the backend hooks registered on these writes read (credential sealing, cache invalidation, change
+ * audit).
+ *
+ * A custom implementation is keyed by `(resource, operation, variantType)`. Until #953 each hook
+ * restated `INTERNAL_CALL` by hand, so moving UPDATE onto its API_CALL door meant editing four files
+ * in lockstep, and the first one missed would silently stop sealing credentials. Startup validation
+ * would refuse the mismatch, but only once the process was already starting.
+ *
+ * - `CREATE` stays `INTERNAL_CALL`: the row is seeded, or lazily materialised on the userless login
+ *   path, and never created self-serve.
+ * - `UPDATE` is `API_CALL`: the admin's edit door.
+ */
+export const SIEM_EXPORT_CONFIG_WRITE_VARIANT_TYPE = {
+    [CoreResourceOperation.CREATE]: ResourceOperationVariantType.INTERNAL_CALL,
+    [CoreResourceOperation.UPDATE]: ResourceOperationVariantType.API_CALL,
+};
 // ── Polymorphic Factory ──────────────────────────────────────────────
 export const siemExportConfigPolymorphicFactories = createPolymorphicResourceConfigurations(siemExportConfigPolymorphicDeclaration, {
     isSystemResource: true,
@@ -52,7 +71,7 @@ export const siemExportConfigPolymorphicFactories = createPolymorphicResourceCon
         // self-serve). Same fix as the SCIM-tokens READ/UPDATE. Admin tier / MEDIUM.
         [CoreResourceOperation.CREATE]: {
             variants: [{
-                    variantType: ResourceOperationVariantType.INTERNAL_CALL,
+                    variantType: SIEM_EXPORT_CONFIG_WRITE_VARIANT_TYPE[CoreResourceOperation.CREATE],
                     isDefault: true,
                     polymorphicRole: {
                         [CoreResourceType.ORGANIZATIONS]: [CORE_ORG_ROLES.ORG_ADMIN],
@@ -61,25 +80,43 @@ export const siemExportConfigPolymorphicFactories = createPolymorphicResourceCon
                     riskLevel: ResourceOperationRiskLevel.MEDIUM,
                 }],
         },
-        // Internal-only (INTERNAL_CALL, NO HTTP route): SIEM config edits reach this through
-        // the config service path — `AuthOrganizationConfigurationService.saveSiemExportConfig`
-        // dispatches the write via `ServicesRegistryHandler.update` with the ADMIN's EC. Must
-        // NOT be REPOSITORY_ONLY: `.update()` resolves the op via `getServiceOperationPathDefault`,
-        // which honours INTERNAL_CALL / API_CALL but NOT REPOSITORY_ONLY — a repository-only
-        // UPDATE throws `RESOURCES_REGISTRY_OPERATION_PATH_NOT_FOUND` (INTERNAL / critical)
-        // whenever the save method runs. (`authCredential` masking is framework-driven via
-        // `.isWriteOnlySecret()`, so — unlike SSO's `socialCredentialOverrides` — there is no
-        // UPDATE custom-impl to keep in lockstep here.) No public HTTP update surface. Same fix
-        // as the CREATE above + the SCIM-tokens READ/UPDATE. Admin tier / MEDIUM.
+        // THE WRITE DOOR (API_CALL, #953). Until 2026-09-13 this was INTERNAL_CALL with the comment "SIEM
+        // config edits reach this through `AuthOrganizationConfigurationService.saveSiemExportConfig`" —
+        // and nothing in production called that method. The engine preset rendered an edit form, the
+        // customer documentation told an operator which values to enter, and the only rows that ever
+        // carried a destination were written straight into the database by the e2e harness.
+        //
+        // A plain UPDATE, not a named domain operation: this is an edit of the scope's one config row
+        // over the fields the form already renders, with no step-specific transition to model (the SSO
+        // domain claim/verify/revoke operations are named because each IS such a transition).
+        // `saveSiemExportConfig` still resolves this same default variant, so there is one write path.
+        //
+        // Both scope variants get the door, because a polymorphic declaration cannot give them different
+        // variant types. The APPLICATION variant is settable and INERT — no producer delivers
+        // application-scoped events (see `AuditEventDispatcherBackendService.dispatchToOrganizationAuditSinks`)
+        // — decided deliberately on 2026-09-13 rather than refused at the door.
+        //
+        // HIGH, not MEDIUM: HIGH is inside `AUTOMATIC_AUDIT_RISK_FLOOR`, so EVERY edit on EITHER scope leaves
+        // a `RESOURCE_OPERATION_PERFORMED` row. The organization variant additionally emits the typed
+        // `ORGANIZATION_SIEM_EXPORT_CONFIGURED`; the application variant has no typed event (its schema
+        // names an organization), so at MEDIUM an application-scope destination change recorded nothing.
+        // The change is high-consequence either way: it decides where a tenant's security events go,
+        // whether they go at all, and with which credential.
+        //
+        // ⚠️ `authCredential` IS SEALED BY A CUSTOM IMPLEMENTATION ON THIS PATH (#951). `.isWriteOnlySecret()`
+        // governs how a value is PRESENTED, never how it is STORED. This variant and the sealing,
+        // cache-invalidation and change-audit hooks in saas-backend-lib all read
+        // `SIEM_EXPORT_CONFIG_WRITE_VARIANT_TYPE`, so they move together. Hard-code a variant type here instead
+        // and all three hooks are orphaned, which startup validation refuses by name.
         [CoreResourceOperation.UPDATE]: {
             variants: [{
-                    variantType: ResourceOperationVariantType.INTERNAL_CALL,
+                    variantType: SIEM_EXPORT_CONFIG_WRITE_VARIANT_TYPE[CoreResourceOperation.UPDATE],
                     isDefault: true,
                     polymorphicRole: {
                         [CoreResourceType.ORGANIZATIONS]: [CORE_ORG_ROLES.ORG_ADMIN],
                         [CoreResourceType.APPLICATION]: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],
                     },
-                    riskLevel: ResourceOperationRiskLevel.MEDIUM,
+                    riskLevel: ResourceOperationRiskLevel.HIGH,
                 }],
         },
         // Internal-only (REPOSITORY_ONLY, no HTTP route): powers the composition

package/dist/esm/security/authentications/siem/siem-export-config.shared.resources-config.schemas.js.map

@@ -1 +1 @@
-{"version":3,"file":"siem-export-config.shared.resources-config.schemas.js","sourceRoot":"","sources":["../../../../../../src/security/authentications/siem/siem-export-config.shared.resources-config.schemas.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;AAEH,OAAO,EAAE,qBAAqB,EAAE,gBAAgB,EAAE,MAAM,sDAAsD,CAAC;AAC/G,OAAO,EACL,0BAA0B,EAC1B,4BAA4B,GAC7B,MAAM,6CAA6C,CAAC;AACrD,OAAO,EAAE,uCAAuC,EAAE,MAAM,wDAAwD,CAAC;AACjH,OAAO,EAAE,wBAAwB,EAAE,MAAM,oDAAoD,CAAC;AAC9F,OAAO,EAAE,cAAc,EAAE,cAAc,EAAE,MAAM,2CAA2C,CAAC;AAC3F,OAAO,EAAE,sCAAsC,EAAE,MAAM,qCAAqC,CAAC;AAE7F,wEAAwE;AAExE,MAAM,CAAC,MAAM,oCAAoC,GAAG,uCAAuC,CACzF,sCAAsC,EACtC;IACE,gBAAgB,EAAE,IAAI;IACtB,2EAA2E;IAC3E,2EAA2E;IAC3E,qEAAqE;IACrE,oEAAoE;IACpE,2EAA2E;IAC3E,wEAAwE;IACxE,2EAA2E;IAC3E,mCAAmC;IACnC,kBAAkB,EAAE;QAClB,IAAI,EAAE,wBAAwB,CAAC,OAAO;QACtC,MAAM,EAAE,wBAAwB,CAAC,OAAO;KACzC;IACD,cAAc,EAAE,CAAC,qBAAqB,CAAC,IAAI,EAAE,qBAAqB,CAAC,MAAM,EAAE,qBAAqB,CAAC,MAAM,EAAE,qBAAqB,CAAC,MAAM,CAAC;IACtI,uBAAuB,EAAE;QACvB,CAAC,qBAAqB,CAAC,IAAI,CAAC,EAAE;YAC5B,QAAQ,EAAE,CAAC;oBACT,WAAW,EAAE,4BAA4B,CAAC,QAAQ;oBAClD,SAAS,EAAE,IAAI;oBACf,eAAe,EAAE;wBACf,CAAC,gBAAgB,CAAC,aAAa,CAAC,EAAE,CAAC,cAAc,CAAC,SAAS,CAAC;wBAC5D,CAAC,gBAAgB,CAAC,WAAW,CAAC,EAAE,CAAC,cAAc,CAAC,qBAAqB,CAAC;qBACvE;oBACD,SAAS,EAAE,0BAA0B,CAAC,GAAG;iBAC1C,CAAC;SACH;QACD,4EAA4E;QAC5E,8EAA8E;QAC9E,uEAAuE;QACvE,6EAA6E;QAC7E,4EAA4E;QAC5E,+EAA+E;QAC/E,wDAAwD;QACxD,0EAA0E;QAC1E,4EAA4E;QAC5E,sEAAsE;QACtE,6EAA6E;QAC7E,CAAC,qBAAqB,CAAC,MAAM,CAAC,EAAE;YAC9B,QAAQ,EAAE,CAAC;oBACT,WAAW,EAAE,4BAA4B,CAAC,aAAa;oBACvD,SAAS,EAAE,IAAI;oBACf,eAAe,EAAE;wBACf,CAAC,gBAAgB,CAAC,aAAa,CAAC,EAAE,CAAC,cAAc,CAAC,SAAS,CAAC;wBAC5D,CAAC,gBAAgB,CAAC,WAAW,CAAC,EAAE,CAAC,cAAc,CAAC,qBAAqB,CAAC;qBACvE;oBACD,SAAS,EAAE,0BAA0B,CAAC,MAAM;iBAC7C,CAAC;SACH;QACD,qFAAqF;QACrF,wFAAwF;QACxF,sFAAsF;QACtF,4FAA4F;QAC5F,qFAAqF;QACrF,oFAAoF;QACpF,mFAAmF;QACnF,sFAAsF;QACtF,wFAAwF;QACxF,0EAA0E;QAC1E,CAAC,qBAAqB,CAAC,MAAM,CAAC,EAAE;YAC9B,QAAQ,EAAE,CAAC;oBACT,WAAW,EAAE,4BAA4B,CAAC,aAAa;oBACvD,SAAS,EAAE,IAAI;oBACf,eAAe,EAAE;wBACf,CAAC,gBAAgB,CAAC,aAAa,CAAC,EAAE,CAAC,cAAc,CAAC,SAAS,CAAC;wBAC5D,CAAC,gBAAgB,CAAC,WAAW,CAAC,EAAE,CAAC,cAAc,CAAC,qBAAqB,CAAC;qBACvE;oBACD,SAAS,EAAE,0BAA0B,CAAC,MAAM;iBAC7C,CAAC;SACH;QACD,yEAAyE;QACzE,oFAAoF;QACpF,8EAA8E;QAC9E,+EAA+E;QAC/E,+DAA+D;QAC/D,CAAC,qBAAqB,CAAC,MAAM,CAAC,EAAE;YAC9B,QAAQ,EAAE,CAAC;oBACT,WAAW,EAAE,4BAA4B,CAAC,eAAe;oBACzD,SAAS,EAAE,IAAI;oBACf,eAAe,EAAE;wBACf,CAAC,gBAAgB,CAAC,aAAa,CAAC,EAAE,CAAC,cAAc,CAAC,SAAS,CAAC;wBAC5D,CAAC,gBAAgB,CAAC,WAAW,CAAC,EAAE,CAAC,cAAc,CAAC,qBAAqB,CAAC;qBACvE;oBACD,SAAS,EAAE,0BAA0B,CAAC,IAAI;iBAC3C,CAAC;SACH;KACF;CACF,CACF,CAAC","sourcesContent":["/**\n * SIEM Export Config Resource Configuration — Polymorphic\n *\n * Produces 2 factory functions (ORG + APP) via the polymorphic factory.\n * Spread into the registry factory map:\n *   ...siemExportConfigPolymorphicFactories\n */\n\nimport { CoreResourceOperation, CoreResourceType } from '../../../resources/resources.shared.core.definitions';\nimport {\n  ResourceOperationRiskLevel,\n  ResourceOperationVariantType,\n} from '../../../resources/resources.shared.schemas';\nimport { createPolymorphicResourceConfigurations } from '../../../resources/utils/resource-polymorphism.factory';\nimport { ResourceSystemAccessMode } from '../../../resources/resources-config.shared.schemas';\nimport { CORE_ORG_ROLES, CORE_APP_ROLES } from '../../authorizations/roles.shared.schemas';\nimport { siemExportConfigPolymorphicDeclaration } from './siem-export-config.shared.schemas';\n\n// ── Polymorphic Factory ──────────────────────────────────────────────\n\nexport const siemExportConfigPolymorphicFactories = createPolymorphicResourceConfigurations(\n  siemExportConfigPolymorphicDeclaration,\n  {\n    isSystemResource: true,\n    // Audit/SIEM dispatch loads the export config via `readAsSystem` to decide\n    // where to deliver events, independent of any user (READ). When the row is\n    // absent — a provisioned / migrated / pre-seed org that bypassed the\n    // `afterCreate` default-seed — that same userless login path lazily\n    // materialises the disabled-default row via `createAsSystem` (CREATE); see\n    // `AuthOrganizationConfigurationService.loadSiemExportConfig`. Both are\n    // system-context (the logging-in user is not the config's admin owner), so\n    // the resource opts BOTH verbs in.\n    systemAccessPolicy: {\n      read: ResourceSystemAccessMode.ALLOWED,\n      create: ResourceSystemAccessMode.ALLOWED,\n    },\n    coreOperations: [CoreResourceOperation.READ, CoreResourceOperation.CREATE, CoreResourceOperation.UPDATE, CoreResourceOperation.DELETE],\n    operationsConfiguration: {\n      [CoreResourceOperation.READ]: {\n        variants: [{\n          variantType: ResourceOperationVariantType.API_CALL,\n          isDefault: true,\n          polymorphicRole: {\n            [CoreResourceType.ORGANIZATIONS]: [CORE_ORG_ROLES.ORG_ADMIN],\n            [CoreResourceType.APPLICATION]: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],\n          },\n          riskLevel: ResourceOperationRiskLevel.LOW,\n        }],\n      },\n      // Internal-only (INTERNAL_CALL, NO HTTP route): the per-scope config row is\n      // materialised by the framework default-seed (repository tier) OR — when that\n      // was bypassed (provisioned / migrated / pre-seed org) — lazily by the\n      // userless login path via `createAsSystem` (`systemAccessPolicy.create` opts\n      // it in). Must NOT be REPOSITORY_ONLY: `createAsSystem` resolves CREATE via\n      // `getServiceOperationPathDefault`, which honours INTERNAL_CALL / API_CALL but\n      // NOT REPOSITORY_ONLY — a repository-only CREATE throws\n      // `RESOURCES_REGISTRY_OPERATION_PATH_NOT_FOUND` (INTERNAL / critical, and\n      // self-alerting on mere construction) on every login for a config-less org.\n      // No public HTTP create surface (config is seeded/bootstrapped, never\n      // self-serve). Same fix as the SCIM-tokens READ/UPDATE. Admin tier / MEDIUM.\n      [CoreResourceOperation.CREATE]: {\n        variants: [{\n          variantType: ResourceOperationVariantType.INTERNAL_CALL,\n          isDefault: true,\n          polymorphicRole: {\n            [CoreResourceType.ORGANIZATIONS]: [CORE_ORG_ROLES.ORG_ADMIN],\n            [CoreResourceType.APPLICATION]: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],\n          },\n          riskLevel: ResourceOperationRiskLevel.MEDIUM,\n        }],\n      },\n      // Internal-only (INTERNAL_CALL, NO HTTP route): SIEM config edits reach this through\n      // the config service path — `AuthOrganizationConfigurationService.saveSiemExportConfig`\n      // dispatches the write via `ServicesRegistryHandler.update` with the ADMIN's EC. Must\n      // NOT be REPOSITORY_ONLY: `.update()` resolves the op via `getServiceOperationPathDefault`,\n      // which honours INTERNAL_CALL / API_CALL but NOT REPOSITORY_ONLY — a repository-only\n      // UPDATE throws `RESOURCES_REGISTRY_OPERATION_PATH_NOT_FOUND` (INTERNAL / critical)\n      // whenever the save method runs. (`authCredential` masking is framework-driven via\n      // `.isWriteOnlySecret()`, so — unlike SSO's `socialCredentialOverrides` — there is no\n      // UPDATE custom-impl to keep in lockstep here.) No public HTTP update surface. Same fix\n      // as the CREATE above + the SCIM-tokens READ/UPDATE. Admin tier / MEDIUM.\n      [CoreResourceOperation.UPDATE]: {\n        variants: [{\n          variantType: ResourceOperationVariantType.INTERNAL_CALL,\n          isDefault: true,\n          polymorphicRole: {\n            [CoreResourceType.ORGANIZATIONS]: [CORE_ORG_ROLES.ORG_ADMIN],\n            [CoreResourceType.APPLICATION]: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],\n          },\n          riskLevel: ResourceOperationRiskLevel.MEDIUM,\n        }],\n      },\n      // Internal-only (REPOSITORY_ONLY, no HTTP route): powers the composition\n      // onParentDelete cascade so this one-per-scope SIEM-export-config row is physically\n      // removed when its owning org/app is deleted. Without a DELETE op the cascade\n      // (deleteChildrenImmediate) throws ErrorType.CONFIGURATION on any scope with a\n      // config row. Admin tier (ORG_ADMIN / APP super-admin) / HIGH.\n      [CoreResourceOperation.DELETE]: {\n        variants: [{\n          variantType: ResourceOperationVariantType.REPOSITORY_ONLY,\n          isDefault: true,\n          polymorphicRole: {\n            [CoreResourceType.ORGANIZATIONS]: [CORE_ORG_ROLES.ORG_ADMIN],\n            [CoreResourceType.APPLICATION]: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],\n          },\n          riskLevel: ResourceOperationRiskLevel.HIGH,\n        }],\n      },\n    },\n  },\n);\n"]}
+{"version":3,"file":"siem-export-config.shared.resources-config.schemas.js","sourceRoot":"","sources":["../../../../../../src/security/authentications/siem/siem-export-config.shared.resources-config.schemas.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;AAEH,OAAO,EAAE,qBAAqB,EAAE,gBAAgB,EAAE,MAAM,sDAAsD,CAAC;AAC/G,OAAO,EACL,0BAA0B,EAC1B,4BAA4B,GAC7B,MAAM,6CAA6C,CAAC;AACrD,OAAO,EAAE,uCAAuC,EAAE,MAAM,wDAAwD,CAAC;AACjH,OAAO,EAAE,wBAAwB,EAAE,MAAM,oDAAoD,CAAC;AAC9F,OAAO,EAAE,cAAc,EAAE,cAAc,EAAE,MAAM,2CAA2C,CAAC;AAC3F,OAAO,EAAE,sCAAsC,EAAE,MAAM,qCAAqC,CAAC;AAE7F,wEAAwE;AAExE;;;;;;;;;;;;;GAaG;AACH,MAAM,CAAC,MAAM,qCAAqC,GAK7C;IACH,CAAC,qBAAqB,CAAC,MAAM,CAAC,EAAE,4BAA4B,CAAC,aAAa;IAC1E,CAAC,qBAAqB,CAAC,MAAM,CAAC,EAAE,4BAA4B,CAAC,QAAQ;CACtE,CAAC;AAEF,wEAAwE;AAExE,MAAM,CAAC,MAAM,oCAAoC,GAAG,uCAAuC,CACzF,sCAAsC,EACtC;IACE,gBAAgB,EAAE,IAAI;IACtB,2EAA2E;IAC3E,2EAA2E;IAC3E,qEAAqE;IACrE,oEAAoE;IACpE,2EAA2E;IAC3E,wEAAwE;IACxE,2EAA2E;IAC3E,mCAAmC;IACnC,kBAAkB,EAAE;QAClB,IAAI,EAAE,wBAAwB,CAAC,OAAO;QACtC,MAAM,EAAE,wBAAwB,CAAC,OAAO;KACzC;IACD,cAAc,EAAE,CAAC,qBAAqB,CAAC,IAAI,EAAE,qBAAqB,CAAC,MAAM,EAAE,qBAAqB,CAAC,MAAM,EAAE,qBAAqB,CAAC,MAAM,CAAC;IACtI,uBAAuB,EAAE;QACvB,CAAC,qBAAqB,CAAC,IAAI,CAAC,EAAE;YAC5B,QAAQ,EAAE,CAAC;oBACT,WAAW,EAAE,4BAA4B,CAAC,QAAQ;oBAClD,SAAS,EAAE,IAAI;oBACf,eAAe,EAAE;wBACf,CAAC,gBAAgB,CAAC,aAAa,CAAC,EAAE,CAAC,cAAc,CAAC,SAAS,CAAC;wBAC5D,CAAC,gBAAgB,CAAC,WAAW,CAAC,EAAE,CAAC,cAAc,CAAC,qBAAqB,CAAC;qBACvE;oBACD,SAAS,EAAE,0BAA0B,CAAC,GAAG;iBAC1C,CAAC;SACH;QACD,4EAA4E;QAC5E,8EAA8E;QAC9E,uEAAuE;QACvE,6EAA6E;QAC7E,4EAA4E;QAC5E,+EAA+E;QAC/E,wDAAwD;QACxD,0EAA0E;QAC1E,4EAA4E;QAC5E,sEAAsE;QACtE,6EAA6E;QAC7E,CAAC,qBAAqB,CAAC,MAAM,CAAC,EAAE;YAC9B,QAAQ,EAAE,CAAC;oBACT,WAAW,EAAE,qCAAqC,CAAC,qBAAqB,CAAC,MAAM,CAAC;oBAChF,SAAS,EAAE,IAAI;oBACf,eAAe,EAAE;wBACf,CAAC,gBAAgB,CAAC,aAAa,CAAC,EAAE,CAAC,cAAc,CAAC,SAAS,CAAC;wBAC5D,CAAC,gBAAgB,CAAC,WAAW,CAAC,EAAE,CAAC,cAAc,CAAC,qBAAqB,CAAC;qBACvE;oBACD,SAAS,EAAE,0BAA0B,CAAC,MAAM;iBAC7C,CAAC;SACH;QACD,kGAAkG;QAClG,iGAAiG;QACjG,6FAA6F;QAC7F,6FAA6F;QAC7F,oFAAoF;QACpF,EAAE;QACF,8FAA8F;QAC9F,+FAA+F;QAC/F,sFAAsF;QACtF,+FAA+F;QAC/F,EAAE;QACF,iGAAiG;QACjG,sFAAsF;QACtF,wGAAwG;QACxG,wEAAwE;QACxE,EAAE;QACF,sGAAsG;QACtG,8FAA8F;QAC9F,gGAAgG;QAChG,iGAAiG;QACjG,6FAA6F;QAC7F,qDAAqD;QACrD,EAAE;QACF,uGAAuG;QACvG,0FAA0F;QAC1F,yEAAyE;QACzE,wGAAwG;QACxG,8EAA8E;QAC9E,CAAC,qBAAqB,CAAC,MAAM,CAAC,EAAE;YAC9B,QAAQ,EAAE,CAAC;oBACT,WAAW,EAAE,qCAAqC,CAAC,qBAAqB,CAAC,MAAM,CAAC;oBAChF,SAAS,EAAE,IAAI;oBACf,eAAe,EAAE;wBACf,CAAC,gBAAgB,CAAC,aAAa,CAAC,EAAE,CAAC,cAAc,CAAC,SAAS,CAAC;wBAC5D,CAAC,gBAAgB,CAAC,WAAW,CAAC,EAAE,CAAC,cAAc,CAAC,qBAAqB,CAAC;qBACvE;oBACD,SAAS,EAAE,0BAA0B,CAAC,IAAI;iBAC3C,CAAC;SACH;QACD,yEAAyE;QACzE,oFAAoF;QACpF,8EAA8E;QAC9E,+EAA+E;QAC/E,+DAA+D;QAC/D,CAAC,qBAAqB,CAAC,MAAM,CAAC,EAAE;YAC9B,QAAQ,EAAE,CAAC;oBACT,WAAW,EAAE,4BAA4B,CAAC,eAAe;oBACzD,SAAS,EAAE,IAAI;oBACf,eAAe,EAAE;wBACf,CAAC,gBAAgB,CAAC,aAAa,CAAC,EAAE,CAAC,cAAc,CAAC,SAAS,CAAC;wBAC5D,CAAC,gBAAgB,CAAC,WAAW,CAAC,EAAE,CAAC,cAAc,CAAC,qBAAqB,CAAC;qBACvE;oBACD,SAAS,EAAE,0BAA0B,CAAC,IAAI;iBAC3C,CAAC;SACH;KACF;CACF,CACF,CAAC","sourcesContent":["/**\n * SIEM Export Config Resource Configuration — Polymorphic\n *\n * Produces 2 factory functions (ORG + APP) via the polymorphic factory.\n * Spread into the registry factory map:\n *   ...siemExportConfigPolymorphicFactories\n */\n\nimport { CoreResourceOperation, CoreResourceType } from '../../../resources/resources.shared.core.definitions';\nimport {\n  ResourceOperationRiskLevel,\n  ResourceOperationVariantType,\n} from '../../../resources/resources.shared.schemas';\nimport { createPolymorphicResourceConfigurations } from '../../../resources/utils/resource-polymorphism.factory';\nimport { ResourceSystemAccessMode } from '../../../resources/resources-config.shared.schemas';\nimport { CORE_ORG_ROLES, CORE_APP_ROLES } from '../../authorizations/roles.shared.schemas';\nimport { siemExportConfigPolymorphicDeclaration } from './siem-export-config.shared.schemas';\n\n// ── Write variants ───────────────────────────────────────────────────\n\n/**\n * The variant type each SIEM-export-config WRITE runs on — the one named source both this configuration\n * and the backend hooks registered on these writes read (credential sealing, cache invalidation, change\n * audit).\n *\n * A custom implementation is keyed by `(resource, operation, variantType)`. Until #953 each hook\n * restated `INTERNAL_CALL` by hand, so moving UPDATE onto its API_CALL door meant editing four files\n * in lockstep, and the first one missed would silently stop sealing credentials. Startup validation\n * would refuse the mismatch, but only once the process was already starting.\n *\n * - `CREATE` stays `INTERNAL_CALL`: the row is seeded, or lazily materialised on the userless login\n *   path, and never created self-serve.\n * - `UPDATE` is `API_CALL`: the admin's edit door.\n */\nexport const SIEM_EXPORT_CONFIG_WRITE_VARIANT_TYPE: Readonly<{\n  // Exact members, not the enum: a variant is a union DISCRIMINATED by `variantType`, so a value typed\n  // as the whole enum matches no member of it.\n  [CoreResourceOperation.CREATE]: ResourceOperationVariantType.INTERNAL_CALL;\n  [CoreResourceOperation.UPDATE]: ResourceOperationVariantType.API_CALL;\n}> = {\n  [CoreResourceOperation.CREATE]: ResourceOperationVariantType.INTERNAL_CALL,\n  [CoreResourceOperation.UPDATE]: ResourceOperationVariantType.API_CALL,\n};\n\n// ── Polymorphic Factory ──────────────────────────────────────────────\n\nexport const siemExportConfigPolymorphicFactories = createPolymorphicResourceConfigurations(\n  siemExportConfigPolymorphicDeclaration,\n  {\n    isSystemResource: true,\n    // Audit/SIEM dispatch loads the export config via `readAsSystem` to decide\n    // where to deliver events, independent of any user (READ). When the row is\n    // absent — a provisioned / migrated / pre-seed org that bypassed the\n    // `afterCreate` default-seed — that same userless login path lazily\n    // materialises the disabled-default row via `createAsSystem` (CREATE); see\n    // `AuthOrganizationConfigurationService.loadSiemExportConfig`. Both are\n    // system-context (the logging-in user is not the config's admin owner), so\n    // the resource opts BOTH verbs in.\n    systemAccessPolicy: {\n      read: ResourceSystemAccessMode.ALLOWED,\n      create: ResourceSystemAccessMode.ALLOWED,\n    },\n    coreOperations: [CoreResourceOperation.READ, CoreResourceOperation.CREATE, CoreResourceOperation.UPDATE, CoreResourceOperation.DELETE],\n    operationsConfiguration: {\n      [CoreResourceOperation.READ]: {\n        variants: [{\n          variantType: ResourceOperationVariantType.API_CALL,\n          isDefault: true,\n          polymorphicRole: {\n            [CoreResourceType.ORGANIZATIONS]: [CORE_ORG_ROLES.ORG_ADMIN],\n            [CoreResourceType.APPLICATION]: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],\n          },\n          riskLevel: ResourceOperationRiskLevel.LOW,\n        }],\n      },\n      // Internal-only (INTERNAL_CALL, NO HTTP route): the per-scope config row is\n      // materialised by the framework default-seed (repository tier) OR — when that\n      // was bypassed (provisioned / migrated / pre-seed org) — lazily by the\n      // userless login path via `createAsSystem` (`systemAccessPolicy.create` opts\n      // it in). Must NOT be REPOSITORY_ONLY: `createAsSystem` resolves CREATE via\n      // `getServiceOperationPathDefault`, which honours INTERNAL_CALL / API_CALL but\n      // NOT REPOSITORY_ONLY — a repository-only CREATE throws\n      // `RESOURCES_REGISTRY_OPERATION_PATH_NOT_FOUND` (INTERNAL / critical, and\n      // self-alerting on mere construction) on every login for a config-less org.\n      // No public HTTP create surface (config is seeded/bootstrapped, never\n      // self-serve). Same fix as the SCIM-tokens READ/UPDATE. Admin tier / MEDIUM.\n      [CoreResourceOperation.CREATE]: {\n        variants: [{\n          variantType: SIEM_EXPORT_CONFIG_WRITE_VARIANT_TYPE[CoreResourceOperation.CREATE],\n          isDefault: true,\n          polymorphicRole: {\n            [CoreResourceType.ORGANIZATIONS]: [CORE_ORG_ROLES.ORG_ADMIN],\n            [CoreResourceType.APPLICATION]: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],\n          },\n          riskLevel: ResourceOperationRiskLevel.MEDIUM,\n        }],\n      },\n      // THE WRITE DOOR (API_CALL, #953). Until 2026-09-13 this was INTERNAL_CALL with the comment \"SIEM\n      // config edits reach this through `AuthOrganizationConfigurationService.saveSiemExportConfig`\" —\n      // and nothing in production called that method. The engine preset rendered an edit form, the\n      // customer documentation told an operator which values to enter, and the only rows that ever\n      // carried a destination were written straight into the database by the e2e harness.\n      //\n      // A plain UPDATE, not a named domain operation: this is an edit of the scope's one config row\n      // over the fields the form already renders, with no step-specific transition to model (the SSO\n      // domain claim/verify/revoke operations are named because each IS such a transition).\n      // `saveSiemExportConfig` still resolves this same default variant, so there is one write path.\n      //\n      // Both scope variants get the door, because a polymorphic declaration cannot give them different\n      // variant types. The APPLICATION variant is settable and INERT — no producer delivers\n      // application-scoped events (see `AuditEventDispatcherBackendService.dispatchToOrganizationAuditSinks`)\n      // — decided deliberately on 2026-09-13 rather than refused at the door.\n      //\n      // HIGH, not MEDIUM: HIGH is inside `AUTOMATIC_AUDIT_RISK_FLOOR`, so EVERY edit on EITHER scope leaves\n      // a `RESOURCE_OPERATION_PERFORMED` row. The organization variant additionally emits the typed\n      // `ORGANIZATION_SIEM_EXPORT_CONFIGURED`; the application variant has no typed event (its schema\n      // names an organization), so at MEDIUM an application-scope destination change recorded nothing.\n      // The change is high-consequence either way: it decides where a tenant's security events go,\n      // whether they go at all, and with which credential.\n      //\n      // ⚠️ `authCredential` IS SEALED BY A CUSTOM IMPLEMENTATION ON THIS PATH (#951). `.isWriteOnlySecret()`\n      // governs how a value is PRESENTED, never how it is STORED. This variant and the sealing,\n      // cache-invalidation and change-audit hooks in saas-backend-lib all read\n      // `SIEM_EXPORT_CONFIG_WRITE_VARIANT_TYPE`, so they move together. Hard-code a variant type here instead\n      // and all three hooks are orphaned, which startup validation refuses by name.\n      [CoreResourceOperation.UPDATE]: {\n        variants: [{\n          variantType: SIEM_EXPORT_CONFIG_WRITE_VARIANT_TYPE[CoreResourceOperation.UPDATE],\n          isDefault: true,\n          polymorphicRole: {\n            [CoreResourceType.ORGANIZATIONS]: [CORE_ORG_ROLES.ORG_ADMIN],\n            [CoreResourceType.APPLICATION]: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],\n          },\n          riskLevel: ResourceOperationRiskLevel.HIGH,\n        }],\n      },\n      // Internal-only (REPOSITORY_ONLY, no HTTP route): powers the composition\n      // onParentDelete cascade so this one-per-scope SIEM-export-config row is physically\n      // removed when its owning org/app is deleted. Without a DELETE op the cascade\n      // (deleteChildrenImmediate) throws ErrorType.CONFIGURATION on any scope with a\n      // config row. Admin tier (ORG_ADMIN / APP super-admin) / HIGH.\n      [CoreResourceOperation.DELETE]: {\n        variants: [{\n          variantType: ResourceOperationVariantType.REPOSITORY_ONLY,\n          isDefault: true,\n          polymorphicRole: {\n            [CoreResourceType.ORGANIZATIONS]: [CORE_ORG_ROLES.ORG_ADMIN],\n            [CoreResourceType.APPLICATION]: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],\n          },\n          riskLevel: ResourceOperationRiskLevel.HIGH,\n        }],\n      },\n    },\n  },\n);\n"]}

package/dist/esm/security/authentications/siem/siem-export-config.shared.schemas.d.ts

@@ -89,14 +89,20 @@ export declare const SiemExportConfigBaseSchema: z.ZodObject<{
     }, z.core.$strip>;
     delivery: z.ZodObject<{
         batchSize: z.ZodDefault<z.ZodNumber>;
-        batchWindowSeconds: z.ZodDefault<z.ZodNumber>;
+        batchWindowSeconds: z.ZodPipe<z.ZodTransform<unknown, unknown>, z.ZodDefault<z.ZodNumber>>;
         retryAttempts: z.ZodDefault<z.ZodNumber>;
         retryBackoffSeconds: z.ZodDefault<z.ZodNumber>;
         timeoutSeconds: z.ZodDefault<z.ZodNumber>;
     }, z.core.$strip>;
     customHeaders: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodString>>;
-    includeRawEventData: z.ZodDefault<z.ZodBoolean>;
-    includeDeviceContext: z.ZodDefault<z.ZodBoolean>;
+    exportProjection: z.ZodOptional<z.ZodObject<{
+        disclosedTiers: z.ZodDefault<z.ZodArray<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodEnum<{
+            readonly CONTEXT: import("../../..").AuditExportDisclosureTier.CONTEXT;
+            readonly ATTRIBUTION: import("../../..").AuditExportDisclosureTier.ATTRIBUTION;
+            readonly DETAIL: import("../../..").AuditExportDisclosureTier.DETAIL;
+        }>>>>;
+        disclosedEventDataClasses: z.ZodDefault<z.ZodArray<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodEnum<typeof import("../../..").AuditExportEventDataDisclosure>>>>;
+    }, z.core.$strip>>;
     createdAt: 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<z.ZodDefault<z.ZodDate>>>;
 }, z.core.$strip>;
@@ -136,14 +142,20 @@ export declare const siemExportConfigPolymorphicDeclaration: import("../../..").
     }, z.core.$strip>;
     delivery: z.ZodObject<{
         batchSize: z.ZodDefault<z.ZodNumber>;
-        batchWindowSeconds: z.ZodDefault<z.ZodNumber>;
+        batchWindowSeconds: z.ZodPipe<z.ZodTransform<unknown, unknown>, z.ZodDefault<z.ZodNumber>>;
         retryAttempts: z.ZodDefault<z.ZodNumber>;
         retryBackoffSeconds: z.ZodDefault<z.ZodNumber>;
         timeoutSeconds: z.ZodDefault<z.ZodNumber>;
     }, z.core.$strip>;
     customHeaders: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodString>>;
-    includeRawEventData: z.ZodDefault<z.ZodBoolean>;
-    includeDeviceContext: z.ZodDefault<z.ZodBoolean>;
+    exportProjection: z.ZodOptional<z.ZodObject<{
+        disclosedTiers: z.ZodDefault<z.ZodArray<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodEnum<{
+            readonly CONTEXT: import("../../..").AuditExportDisclosureTier.CONTEXT;
+            readonly ATTRIBUTION: import("../../..").AuditExportDisclosureTier.ATTRIBUTION;
+            readonly DETAIL: import("../../..").AuditExportDisclosureTier.DETAIL;
+        }>>>>;
+        disclosedEventDataClasses: z.ZodDefault<z.ZodArray<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<z.ZodEnum<typeof import("../../..").AuditExportEventDataDisclosure>>>>;
+    }, z.core.$strip>>;
     createdAt: 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<z.ZodDefault<z.ZodDate>>>;
 }, z.core.$strip>>;

package/dist/esm/security/authentications/siem/siem-export-config.shared.schemas.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"siem-export-config.shared.schemas.d.ts","sourceRoot":"","sources":["../../../../../../src/security/authentications/siem/siem-export-config.shared.schemas.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;GAqBG;AAEH,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AAKxB,eAAO,MAAM,cAAc;;;;;CAKjB,CAAC;AAEX;;;;;;;;GAQG;AACH,eAAO,MAAM,eAAe;;;;;CAKlB,CAAC;AAEX,eAAO,MAAM,iBAAiB;;;;;;CAMpB,CAAC;AAEX,eAAO,MAAM,kBAAkB;;;;CAIrB,CAAC;AAEX,eAAO,MAAM,0BAA0B;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;iBA4DrC,CAAC;AAEH,MAAM,MAAM,oBAAoB,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,0BAA0B,CAAC,CAAC;AAE9E,eAAO,MAAM,sCAAsC;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;kBAMjD,CAAC"}
+{"version":3,"file":"siem-export-config.shared.schemas.d.ts","sourceRoot":"","sources":["../../../../../../src/security/authentications/siem/siem-export-config.shared.schemas.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;GAqBG;AAEH,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AAMxB,eAAO,MAAM,cAAc;;;;;CAKjB,CAAC;AAEX;;;;;;;;GAQG;AACH,eAAO,MAAM,eAAe;;;;;CAKlB,CAAC;AAEX,eAAO,MAAM,iBAAiB;;;;;;CAMpB,CAAC;AAEX,eAAO,MAAM,kBAAkB;;;;CAIrB,CAAC;AAEX,eAAO,MAAM,0BAA0B;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;iBAgMrC,CAAC;AAEH,MAAM,MAAM,oBAAoB,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,0BAA0B,CAAC,CAAC;AAE9E,eAAO,MAAM,sCAAsC;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;kBAMjD,CAAC"}

package/dist/esm/security/authentications/siem/siem-export-config.shared.schemas.js

@@ -21,6 +21,7 @@
  * @see auth-data-model-audit.md §2D
  */
 import { z } from 'zod';
+import { SiemExportProjectionDeclarationSchema } from '../../../compliance/audit-trails/audit-export-projection.shared.schemas.js';
 import { WildoHeaderKeys } from '../../../requests/header-keys.shared.js';
 import { AUTH_SCOPE_VARIANTS } from '../authentication.shared.schemas.js';
 import { declarePolymorphicSchemas } from '../../../resources/utils/resource-polymorphism.schemas.js';
@@ -97,16 +98,144 @@ export const SiemExportConfigBaseSchema = z.object({
         severityMinimum: z.enum(SIEMFilterSeverity).default(SIEMFilterSeverity.INFO),
         specificEventTypes: z.array(z.string()).optional(),
     }),
+    /*
+     * Three knobs, and the two that were removed are the reason to read this.
+     *
+     * `retryAttempts`, `retryBackoffSeconds` and `timeoutSeconds` are honoured — the delivery worker
+     * reads all three (`siem-webhook-delivery.backend.service`, at the retry ceiling, the exponential
+     * backoff and the request deadline).
+     *
+     * `batchSize` and `batchWindowSeconds` are honoured TOO, as of #1379 — but they were not always,
+     * and the history is the reason to read this rather than trivia. They spent months appearing in
+     * the delivery service only as fields of its parameter TYPE: declared, passed, never consulted.
+     * That is the shape which makes an inert knob hardest to see, because it has a "reader" that
+     * decides nothing. The worker posted ONE event per HTTP request whatever they said, and the
+     * customer documentation warned an operator not to size a receiver or a billing estimate on
+     * either — a warning being what you write when the control is missing.
+     *
+     * They were deleted in `be001548` rather than kept as a disclosed "reserved" knob, on the
+     * principle that a receiver sized on `batchSize: 100` is sized wrong and a documented warning is
+     * not a control. They are back now because the control exists: a durable collector groups pending
+     * events per destination and sends them as one request, so the two numbers decide how many events
+     * a request may carry and how long a partly-filled one waits.
+     *
+     * The pairing that matters: `batchSize: 1` — the DEFAULT — means no batching at all, the window is
+     * never consulted, and the wire is byte-for-byte what it was before any of this existed.
+     */
     delivery: z.object({
-        batchSize: z.number().min(1).max(100).default(1),
-        batchWindowSeconds: z.number().min(0).max(60).default(0),
+        /**
+         * The MOST events one HTTP request may carry. `1` — the default — is one request per event,
+         * which is what this destination gets until its operator asks for anything else.
+         *
+         * The number means what it says: the collector claims at most this many pending events for one
+         * request and sends no more, so a receiver sized on `batchSize: 50` receives at most fifty. A
+         * burst larger than this becomes several requests of this size rather than one oversized body.
+         *
+         * Capped at 100 because the body is the sum of its events and collector endpoints commonly
+         * refuse a payload around a megabyte: a hundred CEF lines sits comfortably under that, where a
+         * thousand would not. Raising the cap is a decision about the receiver, not about this engine.
+         *
+         * At `1` the delivery path is byte-for-byte what it was before batching existed — the event is
+         * sent alone, framed as itself, and {@link batchWindowSeconds} is never consulted.
+         */
+        batchSize: z.number().int().min(1).max(100).default(1),
+        /**
+         * How long a partly-filled batch waits for company before it is sent anyway.
+         *
+         * ONLY consulted when {@link batchSize} is greater than 1 — at the default of 1 there is no
+         * batch to fill, so a lone event is never held. That is the pairing to know: this field cannot
+         * delay anything on a destination that has not opted into batching.
+         *
+         * It bounds how stale an exported security event may be, which is why the ceiling is a minute
+         * rather than the five that the retry backoff allows. A SOC's detection latency is the thing
+         * being spent here.
+         */
+        batchWindowSeconds: z.preprocess(
+        /*
+         * A stored value BELOW the floor is LEGACY, and is normalised to the default rather than
+         * refused. Measured 2026-09-21 on the dogfood application: 17 of 17 rows carry
+         * `batchWindowSeconds: 0`, and so do wonder-crm's and the platform's.
+         *
+         * They were written by the seed's `delivery: {}` under the PRE-`be001548` schema, whose
+         * default for this field was 0 — back when nothing read it. Re-adding the field in #1379 with
+         * a floor of 1 made every one of those rows unreadable: `transformOutput` re-validates stored
+         * data against the CURRENT schema, so every read of every organization's SIEM export config
+         * threw, which is `loadSiemExportConfig` — the per-organization audit routing lookup.
+         *
+         * **The floor cannot simply be widened to 0, and the reason is in the collector**: "A window
+         * of 0 would make the flush job race the append's own transaction; the window is floored at 1
+         * second by the schema". `.min(1)` is load-bearing, so 0 is not a value this contract may
+         * hold — which is exactly why coercing it is honest rather than lax. It cannot be WRITTEN
+         * either: a create or update carrying 0 still fails the inner schema, because preprocess only
+         * substitutes the value that reaches it and the floor below still judges everything else.
+         *
+         * Neither of the framework's two repair mechanisms can reach these rows, which is why the
+         * normalisation lives here. A seed version bump does not: `AFTER_CREATE` "fires once and
+         * cannot reach backwards", and the lazy backfill is "first access creates the row, never
+         * re-applied". A SQL data migration would cover the three PostgreSQL surfaces and leave every
+         * Mongo-backed application broken.
+         *
+         * Matched on EXACTLY 0, never `< 1`. The first version of this coercion took anything below
+         * the floor, and a probe immediately showed it accepting `-3` as 5 — a coercion that had
+         * quietly become permission, which is the shape this repository forbids under "never present
+         * suppression as repair". A negative, a fraction and anything above the ceiling are still
+         * refused outright; 0 alone is the value the old schema actually wrote.
+         *
+         * The residual, stated rather than hidden: read and write share this schema, so an operator
+         * who TYPES 0 gets 5 instead of a validation error. That is the cost of the trade, and it is
+         * the right way round against every read of every organization's export config throwing.
+         *
+         * Mapped to `undefined` rather than to a literal so `.default(5)` stays the single source of
+         * the value. Removable once no deployment can hold a pre-#1379 row.
+         */
+        (value) => (value === 0 ? undefined : value), z.number().int().min(1).max(60).default(5)),
         retryAttempts: z.number().min(0).max(5).default(3),
         retryBackoffSeconds: z.number().min(1).max(300).default(30),
         timeoutSeconds: z.number().min(1).max(60).default(10),
     }),
     customHeaders: z.record(z.string(), z.string()).optional(),
-    includeRawEventData: z.boolean().default(true),
-    includeDeviceContext: z.boolean().default(true),
+    /**
+     * What this destination may RECEIVE — the per-destination half of the audit-export projection
+     * (#1380). The vocabulary, the floor and the resolution live in
+     * `compliance/audit-trails/audit-export-projection.shared.schemas`; this field is only where a
+     * tenant declares its own narrowing.
+     *
+     * **`.optional()` on purpose, and the absent case is FULL disclosure.** Two destinations on one
+     * tenant can hold different agreements, so the declaration belongs here rather than on the
+     * application — but every row that exists today has none, and reading an absent declaration as
+     * "disclose nothing" would silently strip live feeds down to the floor. An operator narrows
+     * deliberately; the framework does not narrow on their behalf. See `FULL_AUDIT_EXPORT_PROJECTION`
+     * for why that fail-OPEN is right in this one place.
+     *
+     * This is NOT the revival of `includeRawEventData` / `includeDeviceContext` below. Those were two
+     * booleans beside the retry policy that nothing read; this resolves against a contract that is
+     * total over the envelope AND total over the event vocabulary, is applied once at the ENQUEUE
+     * SEAM — before the event is signed and queued, so all four wire formats carry it identically and
+     * no producer can reach the queue around it — and cannot trim the floor.
+     */
+    exportProjection: SiemExportProjectionDeclarationSchema.optional(),
+    /*
+     * `includeRawEventData` and `includeDeviceContext` were REMOVED here, and neither was ever read.
+     *
+     * Both defaulted `true`, both rendered as switches on the SIEM pane with a description underneath,
+     * and the complete set of mentions was: this declaration, the display and edit templates, the
+     * specification, the customer documentation, the i18n labels — and FOUR test files, where each
+     * appears as a field of a config FIXTURE rather than as a behaviour under assertion. The envelope
+     * builders in `compliance/audit-trails` contain no `includeRaw`, no `rawEvent` and no
+     * `deviceContext` at all: what an exported event carries is decided by the projection contract,
+     * the same shape for every sink.
+     *
+     * They are worth naming apart from the other dead switches on these panes, because these two had
+     * `booleanUI({ showDescription: true })` — so an operator got a switch, a label AND a sentence
+     * explaining what it did, for a flag that did nothing. Being the best-presented control on the
+     * page is not evidence of being one.
+     *
+     * Removing them is not a loss of the capability they named. Choosing what an export carries is a
+     * real feature with a design — a projection the application declares — and it would be built on
+     * the envelope contract, not on two booleans beside the retry policy.
+     *
+     * Absence is pinned in `authentication-knobs-have-readers.test.ts`.
+     */
     createdAt: z.date().default(() => new Date()).excludeFromCreate().excludeFromUpdate(),
     updatedAt: z.date().default(() => new Date()).excludeFromCreate().excludeFromUpdate(),
 });