@wildo-ai/saas-models 1.0.1 → 1.1.0

package/dist/esm/compliance/privacy/impersonalization-scrub.shared.utils.js

@@ -0,0 +1,98 @@
+import { getImpersonalizeMaskValue, getImpersonalizeTreatment, getMergedObjectOrUnionShape } from '@wildo-ai/zod-decorators';
+import { RedactionType } from './redaction.shared.schemas.js';
+import { FIELD_IDENTIFIER_TO_PRIMARY_SCOPE, ResourcePrimaryScope } from '../../resources/resources.shared.schemas.js';
+/**
+ * The DEFAULT mask applied for `RedactionType.MASK`.
+ *
+ * It is an UNCONSTRAINED string, so a field whose schema constrains its shape — `z.email()`,
+ * `z.uuid()`, `.min(n)` — cannot hold it. Such a field declares its own value via
+ * `.impersonalizeWith(MASK, { maskValue })`; see {@link resolveImpersonalizeMaskValue}.
+ */
+export const IMPERSONALIZE_MASK_CONSTANT = '••••••••';
+/**
+ * The value a `MASK` treatment actually writes for one field: the field's own override when it
+ * declares one, the framework constant otherwise.
+ *
+ * ONE authority, deliberately. The boot guard `safeParse`s exactly this value against the field's
+ * schema and the scrub writer `$set`s exactly this value — so a guard that passes at boot cannot be
+ * followed by a write the update DTO rejects inside the erasure transaction. Splitting the two
+ * would reintroduce precisely the failure mode the boot guard exists to eliminate.
+ */
+export function resolveImpersonalizeMaskValue(fieldSchema) {
+    return getImpersonalizeMaskValue(fieldSchema) ?? IMPERSONALIZE_MASK_CONSTANT;
+}
+/**
+ * The impersonalization NEVER-SCRUB FLOOR: the org/app SCOPE FKs + `createdByUserId`. Nulling these
+ * would orphan the retained row from its tenant (a cross-tenant / security regression) or lose its
+ * audit provenance, so they stay protected even if an author accidentally puts a treatment on them.
+ *
+ * The PERSON-LINK (`userId` / `anonymousUserId` — the USER_SELF / ANONYMOUS scopes) is DELIBERATELY NOT
+ * floor-protected: D1 allows SEVERING the person-link while keeping org/app scope (the mirror, opposite
+ * direction, of the anon→user transposition). So a `userId` that carries an explicit
+ * `.impersonalizeWith('remove')` IS severable — this is how "erase the subject's link, keep the scoped
+ * record" is expressed.
+ */
+export function isImpersonalizeNeverScrubFloorField(fieldName) {
+    if (fieldName === 'createdByUserId')
+        return true;
+    const scope = FIELD_IDENTIFIER_TO_PRIMARY_SCOPE[fieldName];
+    return scope === ResourcePrimaryScope.ORGANIZATIONS
+        || scope === ResourcePrimaryScope.APPLICATION;
+    // USER_SELF / ANONYMOUS (person-link) fall through → severable per D1.
+}
+/**
+ * Synthesize the field-scrub `$set` patch for an impersonalize-in-place write, from a resource's
+ * per-field `.impersonalizeWith()` treatments. Returns ONLY the scrubbed FIELDS — the impersonalize
+ * writer appends the `retentionStatus` / `impersonalizedAt` markers.
+ *
+ * M4 is the FIRST + ONLY exhaustive consumer of `RedactionType` (zero appliers existed before), so the
+ * `default` arm is load-bearing: it keeps the enum ADDITIVELY safe — a future member (e.g. a reserved
+ * `TOKENIZE`) fails LOUD here rather than being silently skipped.
+ *
+ * v1 scope: KEEP / REMOVE / MASK are expressible in a single STATIC `$set` (batch `updateManyAsSystem`).
+ * A per-field `maskValue` stays inside that scope — it changes WHICH constant a field is set to, not
+ * that the write is one static `$set` shared by every row in the batch.
+ *  - `HASH` is value-dependent (each row hashes its own value) → NOT expressible in a static `$set`; it
+ *    THROWS in v1 (add a per-doc / aggregation-pipeline scrub path later — additive).
+ *  - `ENCRYPT` is reversible → forbidden for impersonalization (D6: v1 impersonalization is IRREVERSIBLE);
+ *    `ENCRYPT` remains a flow-actors-only redaction option.
+ */
+export function buildImpersonalizeScrubPatch(mainSchema) {
+    // UNION-AWARE on purpose. `getZodObjectShape` returns `{}` for a discriminated union, which would
+    // make the scrub a SILENT NO-OP the day polymorphic resources become retention-governed (rows would
+    // flip to RETAINED with every personal field intact). This mirrors the union-aware shape read used
+    // by `deriveTrustedSystemWritePreservedFields`, so the two never disagree about what a resource's
+    // fields are.
+    const shape = getMergedObjectOrUnionShape(mainSchema);
+    const patch = {};
+    for (const [fieldName, fieldSchema] of Object.entries(shape)) {
+        const treatment = getImpersonalizeTreatment(fieldSchema);
+        if (treatment === undefined)
+            continue; // no `.impersonalizeWith()` → leave the field untouched
+        // Never-scrub floor: even an explicit treatment cannot null a scope FK / createdByUserId.
+        if (isImpersonalizeNeverScrubFloorField(fieldName))
+            continue;
+        switch (treatment) {
+            case RedactionType.KEEP:
+                continue; // explicit never-scrub
+            case RedactionType.REMOVE:
+                patch[fieldName] = null;
+                break;
+            case RedactionType.MASK:
+                patch[fieldName] = resolveImpersonalizeMaskValue(fieldSchema);
+                break;
+            case RedactionType.HASH:
+                throw new Error(`[impersonalize] HASH treatment on '${fieldName}' is value-dependent and not supported in v1 ` +
+                    `(a static $set cannot hash per-row) — use REMOVE/MASK/KEEP, or add the per-doc/pipeline scrub path.`);
+            case RedactionType.ENCRYPT:
+                throw new Error(`[impersonalize] ENCRYPT treatment on '${fieldName}' is reversible — forbidden for impersonalization ` +
+                    `(D6: v1 impersonalization is irreversible). ENCRYPT stays a flow-actors-only redaction option.`);
+            default:
+                // Exhaustive guard: an unknown / future RedactionType member MUST fail LOUD, never be silently
+                // skipped — this is exactly what keeps RedactionType additively safe (deep-review B-F2).
+                throw new Error(`[impersonalize] unsupported impersonalize treatment '${treatment}' on '${fieldName}'.`);
+        }
+    }
+    return patch;
+}
+//# sourceMappingURL=impersonalization-scrub.shared.utils.js.map

package/dist/esm/compliance/privacy/impersonalization-scrub.shared.utils.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"impersonalization-scrub.shared.utils.js","sourceRoot":"","sources":["../../../../../src/compliance/privacy/impersonalization-scrub.shared.utils.ts"],"names":[],"mappings":"AACA,OAAO,EAAE,yBAAyB,EAAE,yBAAyB,EAAE,2BAA2B,EAAE,MAAM,0BAA0B,CAAC;AAC7H,OAAO,EAAE,aAAa,EAAE,MAAM,4BAA4B,CAAC;AAC3D,OAAO,EAAE,iCAAiC,EAAE,oBAAoB,EAAE,MAAM,0CAA0C,CAAC;AAEnH;;;;;;GAMG;AACH,MAAM,CAAC,MAAM,2BAA2B,GAAG,UAAU,CAAC;AAEtD;;;;;;;;GAQG;AACH,MAAM,UAAU,6BAA6B,CAAC,WAAyB;IACrE,OAAO,yBAAyB,CAAC,WAAW,CAAC,IAAI,2BAA2B,CAAC;AAC/E,CAAC;AAED;;;;;;;;;;GAUG;AACH,MAAM,UAAU,mCAAmC,CAAC,SAAiB;IACnE,IAAI,SAAS,KAAK,iBAAiB;QAAE,OAAO,IAAI,CAAC;IACjD,MAAM,KAAK,GAAG,iCAAiC,CAAC,SAAS,CAAC,CAAC;IAC3D,OAAO,KAAK,KAAK,oBAAoB,CAAC,aAAa;WAC5C,KAAK,KAAK,oBAAoB,CAAC,WAAW,CAAC;IAClD,uEAAuE;AACzE,CAAC;AAED;;;;;;;;;;;;;;;;GAgBG;AACH,MAAM,UAAU,4BAA4B,CAAC,UAAwB;IACnE,kGAAkG;IAClG,oGAAoG;IACpG,mGAAmG;IACnG,kGAAkG;IAClG,cAAc;IACd,MAAM,KAAK,GAAG,2BAA2B,CAAC,UAAU,CAAC,CAAC;IACtD,MAAM,KAAK,GAA4B,EAAE,CAAC;IAE1C,KAAK,MAAM,CAAC,SAAS,EAAE,WAAW,CAAC,IAAI,MAAM,CAAC,OAAO,CAAC,KAAK,CAAC,EAAE,CAAC;QAC7D,MAAM,SAAS,GAAG,yBAAyB,CAAC,WAA2B,CAAC,CAAC;QACzE,IAAI,SAAS,KAAK,SAAS;YAAE,SAAS,CAAC,wDAAwD;QAE/F,0FAA0F;QAC1F,IAAI,mCAAmC,CAAC,SAAS,CAAC;YAAE,SAAS;QAE7D,QAAQ,SAA0B,EAAE,CAAC;YACnC,KAAK,aAAa,CAAC,IAAI;gBACrB,SAAS,CAAC,uBAAuB;YACnC,KAAK,aAAa,CAAC,MAAM;gBACvB,KAAK,CAAC,SAAS,CAAC,GAAG,IAAI,CAAC;gBACxB,MAAM;YACR,KAAK,aAAa,CAAC,IAAI;gBACrB,KAAK,CAAC,SAAS,CAAC,GAAG,6BAA6B,CAAC,WAA2B,CAAC,CAAC;gBAC9E,MAAM;YACR,KAAK,aAAa,CAAC,IAAI;gBACrB,MAAM,IAAI,KAAK,CACb,sCAAsC,SAAS,+CAA+C;oBAC9F,qGAAqG,CACtG,CAAC;YACJ,KAAK,aAAa,CAAC,OAAO;gBACxB,MAAM,IAAI,KAAK,CACb,yCAAyC,SAAS,oDAAoD;oBACtG,gGAAgG,CACjG,CAAC;YACJ;gBACE,+FAA+F;gBAC/F,yFAAyF;gBACzF,MAAM,IAAI,KAAK,CAAC,wDAAwD,SAAS,SAAS,SAAS,IAAI,CAAC,CAAC;QAC7G,CAAC;IACH,CAAC;IAED,OAAO,KAAK,CAAC;AACf,CAAC","sourcesContent":["import { z } from 'zod';\nimport { getImpersonalizeMaskValue, getImpersonalizeTreatment, getMergedObjectOrUnionShape } from '@wildo-ai/zod-decorators';\nimport { RedactionType } from './redaction.shared.schemas';\nimport { FIELD_IDENTIFIER_TO_PRIMARY_SCOPE, ResourcePrimaryScope } from '../../resources/resources.shared.schemas';\n\n/**\n * The DEFAULT mask applied for `RedactionType.MASK`.\n *\n * It is an UNCONSTRAINED string, so a field whose schema constrains its shape — `z.email()`,\n * `z.uuid()`, `.min(n)` — cannot hold it. Such a field declares its own value via\n * `.impersonalizeWith(MASK, { maskValue })`; see {@link resolveImpersonalizeMaskValue}.\n */\nexport const IMPERSONALIZE_MASK_CONSTANT = '••••••••';\n\n/**\n * The value a `MASK` treatment actually writes for one field: the field's own override when it\n * declares one, the framework constant otherwise.\n *\n * ONE authority, deliberately. The boot guard `safeParse`s exactly this value against the field's\n * schema and the scrub writer `$set`s exactly this value — so a guard that passes at boot cannot be\n * followed by a write the update DTO rejects inside the erasure transaction. Splitting the two\n * would reintroduce precisely the failure mode the boot guard exists to eliminate.\n */\nexport function resolveImpersonalizeMaskValue(fieldSchema: z.ZodTypeAny): string {\n  return getImpersonalizeMaskValue(fieldSchema) ?? IMPERSONALIZE_MASK_CONSTANT;\n}\n\n/**\n * The impersonalization NEVER-SCRUB FLOOR: the org/app SCOPE FKs + `createdByUserId`. Nulling these\n * would orphan the retained row from its tenant (a cross-tenant / security regression) or lose its\n * audit provenance, so they stay protected even if an author accidentally puts a treatment on them.\n *\n * The PERSON-LINK (`userId` / `anonymousUserId` — the USER_SELF / ANONYMOUS scopes) is DELIBERATELY NOT\n * floor-protected: D1 allows SEVERING the person-link while keeping org/app scope (the mirror, opposite\n * direction, of the anon→user transposition). So a `userId` that carries an explicit\n * `.impersonalizeWith('remove')` IS severable — this is how \"erase the subject's link, keep the scoped\n * record\" is expressed.\n */\nexport function isImpersonalizeNeverScrubFloorField(fieldName: string): boolean {\n  if (fieldName === 'createdByUserId') return true;\n  const scope = FIELD_IDENTIFIER_TO_PRIMARY_SCOPE[fieldName];\n  return scope === ResourcePrimaryScope.ORGANIZATIONS\n      || scope === ResourcePrimaryScope.APPLICATION;\n  // USER_SELF / ANONYMOUS (person-link) fall through → severable per D1.\n}\n\n/**\n * Synthesize the field-scrub `$set` patch for an impersonalize-in-place write, from a resource's\n * per-field `.impersonalizeWith()` treatments. Returns ONLY the scrubbed FIELDS — the impersonalize\n * writer appends the `retentionStatus` / `impersonalizedAt` markers.\n *\n * M4 is the FIRST + ONLY exhaustive consumer of `RedactionType` (zero appliers existed before), so the\n * `default` arm is load-bearing: it keeps the enum ADDITIVELY safe — a future member (e.g. a reserved\n * `TOKENIZE`) fails LOUD here rather than being silently skipped.\n *\n * v1 scope: KEEP / REMOVE / MASK are expressible in a single STATIC `$set` (batch `updateManyAsSystem`).\n * A per-field `maskValue` stays inside that scope — it changes WHICH constant a field is set to, not\n * that the write is one static `$set` shared by every row in the batch.\n *  - `HASH` is value-dependent (each row hashes its own value) → NOT expressible in a static `$set`; it\n *    THROWS in v1 (add a per-doc / aggregation-pipeline scrub path later — additive).\n *  - `ENCRYPT` is reversible → forbidden for impersonalization (D6: v1 impersonalization is IRREVERSIBLE);\n *    `ENCRYPT` remains a flow-actors-only redaction option.\n */\nexport function buildImpersonalizeScrubPatch(mainSchema: z.ZodTypeAny): Record<string, unknown> {\n  // UNION-AWARE on purpose. `getZodObjectShape` returns `{}` for a discriminated union, which would\n  // make the scrub a SILENT NO-OP the day polymorphic resources become retention-governed (rows would\n  // flip to RETAINED with every personal field intact). This mirrors the union-aware shape read used\n  // by `deriveTrustedSystemWritePreservedFields`, so the two never disagree about what a resource's\n  // fields are.\n  const shape = getMergedObjectOrUnionShape(mainSchema);\n  const patch: Record<string, unknown> = {};\n\n  for (const [fieldName, fieldSchema] of Object.entries(shape)) {\n    const treatment = getImpersonalizeTreatment(fieldSchema as z.ZodTypeAny);\n    if (treatment === undefined) continue; // no `.impersonalizeWith()` → leave the field untouched\n\n    // Never-scrub floor: even an explicit treatment cannot null a scope FK / createdByUserId.\n    if (isImpersonalizeNeverScrubFloorField(fieldName)) continue;\n\n    switch (treatment as RedactionType) {\n      case RedactionType.KEEP:\n        continue; // explicit never-scrub\n      case RedactionType.REMOVE:\n        patch[fieldName] = null;\n        break;\n      case RedactionType.MASK:\n        patch[fieldName] = resolveImpersonalizeMaskValue(fieldSchema as z.ZodTypeAny);\n        break;\n      case RedactionType.HASH:\n        throw new Error(\n          `[impersonalize] HASH treatment on '${fieldName}' is value-dependent and not supported in v1 ` +\n          `(a static $set cannot hash per-row) — use REMOVE/MASK/KEEP, or add the per-doc/pipeline scrub path.`,\n        );\n      case RedactionType.ENCRYPT:\n        throw new Error(\n          `[impersonalize] ENCRYPT treatment on '${fieldName}' is reversible — forbidden for impersonalization ` +\n          `(D6: v1 impersonalization is irreversible). ENCRYPT stays a flow-actors-only redaction option.`,\n        );\n      default:\n        // Exhaustive guard: an unknown / future RedactionType member MUST fail LOUD, never be silently\n        // skipped — this is exactly what keeps RedactionType additively safe (deep-review B-F2).\n        throw new Error(`[impersonalize] unsupported impersonalize treatment '${treatment}' on '${fieldName}'.`);\n    }\n  }\n\n  return patch;\n}\n"]}

package/dist/esm/compliance/privacy/impersonalization.shared.schemas.d.ts

@@ -0,0 +1,181 @@
+import { z } from 'zod';
+/**
+ * # Impersonalization — per-record retention lifecycle state
+ *
+ * `impersonalization` = scrubbing the personal data OUT of a stored record while
+ * KEEPING the row, so it can be retained for a legal/audit obligation (GDPR
+ * Art. 17(3)(b) legal-obligation carve-out; tax/SOX retention). This is the third
+ * erasure outcome alongside hard-delete and leave-as-is.
+ *
+ * ⚠️ **Not** the anonymous-user concept. `isAnonymizable` / `anonymousUserId` /
+ * anonymous-session ownership transposition is an unrelated, opposite-direction
+ * mechanism (carrying a pre-auth anonymous session's rows forward to a real user).
+ * Never conflate the two. See `.claude/plans/retention-impersonalization-architecture.md`.
+ *
+ * `RetentionStatus` is the per-record marker the resource factory injects (as the
+ * `retentionStatus` field) onto any resource that opts into `retentionPolicy`. The
+ * INTENDED contract for a `RETAINED` record is **hidden and immutable by default**
+ * (behave-as-deleted), reachable only through the audited `seeRetained` see-through path.
+ *
+ * **LIVE.** The factory injects the marker (defaulting to `ACTIVE`), the visibility/immutability
+ * enforcement and the audited see-through read primitive are all wired and runtime-proven. A
+ * `RETAINED` record is hidden from every ordinary read, list, count and chart aggregate, and is
+ * immutable to ordinary writes. (This block previously said the enforcement was "wired in a later
+ * phase"; that became false without being revisited.)
+ */
+export declare enum RetentionStatus {
+    /** Live record — normal visibility and mutability. */
+    ACTIVE = "active",
+    /**
+     * Impersonalized-and-retained — personal fields scrubbed in place, the row kept for a
+     * retention obligation. Intended semantics (enforcement wired in a later phase): hidden
+     * and immutable to normal callers; readable only via the audited see-through path;
+     * disposable only by a privileged system op.
+     */
+    RETAINED = "retained"
+}
+/**
+ * Zod schema for {@link RetentionStatus}. Explicitly annotated for the
+ * `isolatedDeclarations` emit constraint.
+ */
+export declare const RetentionStatusSchema: z.ZodEnum<typeof RetentionStatus>;
+/**
+ * # What erasure DOES to a retention-governed row
+ *
+ * Retention (the row survives, is marked `RETAINED`, becomes hidden + immutable) and
+ * impersonalization (its personal FIELDS are scrubbed) are ORTHOGONAL. A record can be legally
+ * retainable while holding no personal data of its own — a financial row that merely POINTS at a
+ * person is the canonical case: erasing the subject must not destroy the invoice, but there is
+ * nothing on the invoice to scrub, because the name and address live on the linked user.
+ *
+ * Fusing the two axes forced such a resource to either declare a fake scrub (shipping a record
+ * stamped "impersonalized" that never was) or forgo retention entirely (letting the cascade destroy a
+ * legally-required record). Naming the two outcomes separately removes that false choice AND makes
+ * the author's claim auditable: "this resource holds no personal data" becomes an explicit, reviewable
+ * declaration rather than something a compliance reviewer must infer from an absence of treatments.
+ */
+export declare enum ErasureRetentionMode {
+    /**
+     * Keep and FREEZE the row; scrub nothing — this resource holds no personal data of its own.
+     *
+     * Declaring a `.impersonalizeWith()` treatment under this mode is a contradiction and fails at
+     * config build: if a field does hold personal data, the resource wants
+     * {@link ErasureRetentionMode.RETAIN_AND_IMPERSONALIZE} instead.
+     */
+    RETAIN_ONLY = "retain_only",
+    /**
+     * Keep and freeze the row AND scrub the fields marked with `.impersonalizeWith()`.
+     *
+     * Requires at least one field that the writer would ACTUALLY scrub (a `KEEP` treatment, or one on a
+     * never-scrub floor field such as a scope FK, does not count) — otherwise the row would flip to
+     * `RETAINED` with every field intact while claiming to have been impersonalized.
+     */
+    RETAIN_AND_IMPERSONALIZE = "retain_and_impersonalize"
+}
+/**
+ * Zod schema for {@link ErasureRetentionMode}. Explicitly annotated for the
+ * `isolatedDeclarations` emit constraint.
+ */
+export declare const ErasureRetentionModeSchema: z.ZodEnum<typeof ErasureRetentionMode>;
+/**
+ * **WHOSE SESSION ENDS** when a row of this resource is erased. The second axis of the erasure
+ * contract, beside {@link ErasureRetentionMode} (which says what happens to the row).
+ *
+ * ## This axis is NOT "is this row about a person?" — read this before adding a member
+ *
+ * The two questions look like one and are not, and conflating them cost this vocabulary a member name
+ * for months (see the rename note below). Wildo answers them on SEPARATE axes:
+ *
+ * | question | the axis that answers it |
+ * |---|---|
+ * | Does this resource hold personal data? | {@link ErasureRetentionMode} — `RETAIN_AND_IMPERSONALIZE` requires at least one field that would actually be scrubbed; `RETAIN_ONLY` means *"holds no personal data of its own"*, and a scrub treatment under it fails at config build |
+ * | Can a subject-access or portability export answer for it? | `systemAccessPolicy.exportSubject` |
+ * | **Whose login session must be revoked?** | **this enum** |
+ *
+ * A CRM contact, a sales lead, a newsletter subscriber and a patient with no portal account are all
+ * **data subjects with no session**. They declare `RETAIN_AND_IMPERSONALIZE` (they hold personal data)
+ * and {@link ResourceDataSubjectKind.NO_PRINCIPAL} (there is no session to end) — two independent,
+ * truthful answers. Adding a fourth member here for them would make this enum a cross-product of two
+ * axes, which is two fields wearing one name.
+ *
+ * ## Why the third member is `NO_PRINCIPAL` and not `NOT_A_DATA_SUBJECT`
+ *
+ * It was `NOT_A_DATA_SUBJECT` until 2026-08-28, and the name was the defect. Operationally it always
+ * meant *"revoke nobody"* — which is exactly right for a CRM contact — while its NAME claimed the row
+ * was not about a person, which is false for one. Nothing misbehaved at runtime (the single consumer,
+ * `resolveScrubSessionPrincipals`, only ever asked the session question), so the cost landed entirely
+ * on readers: a human, and a compliance-document generator, both read the name and would have stated
+ * in a published privacy notice that the application holds no personal data in precisely the resource
+ * its customers care most about.
+ *
+ * The industry model this now matches is unambiguous — Intercom deletes "a user **or lead**", HubSpot
+ * GDPR-deletes a Contact by id or by email, Zendesk "forgets" an end-user: an account and a data
+ * subject are different objects, and the erasure verb applies to both. Wildo's `eraseSubjectAsSystem`
+ * already takes `(resourceType, rowIds)` with no principal, so the capability was never missing.
+ *
+ * ## Why this must be DECLARED and can never be inferred
+ *
+ * An erasure of a person must also end that person's session, or a "deleted" person keeps browsing on
+ * a live token until it expires. The tempting shortcut is to look for a `userId`-shaped foreign key on
+ * the erased row and revoke it. **That shortcut is a defect, not an optimisation.** On almost every
+ * resource a user foreign key names the OWNER or the ACTOR, not the subject: Wonder Todos' `TODOS` is
+ * retention-governed and carries `createdByUserId`, `assignedToUserId` and `escalationContactUserId`,
+ * so an inferring implementation would log out the author, the assignee and the escalation contact —
+ * three people, none of them the data subject — every time a todo was erased.
+ *
+ * So the linkage is authored, never guessed, and a resource that can be an erasure subject (i.e. one
+ * declaring a `retentionPolicy`) must say which of these it is. Undeclared is refused at config build:
+ * nobody has decided yet, and refusing is what forces the decision — the same doctrine the subject
+ * EXPORT model applies to an undeclared resource.
+ */
+export declare enum ResourceDataSubjectKind {
+    /**
+     * Erasing a row of this resource revokes **no session**, because no login is reachable from it.
+     *
+     * Two very different populations share this answer, and the enum is deliberately silent about which
+     * one a given resource is — {@link ErasureRetentionMode} says that:
+     *
+     * - **Not a person at all.** A todo, an invoice, a log line. Any user foreign keys it carries name
+     *   ACTORS — an author, an assignee, an owner, an escalation contact — and revoking their sessions
+     *   because a record was erased would log out three uninvolved people. Such a resource pairs this
+     *   with `RETAIN_ONLY`.
+     * - **A person with no account.** A CRM contact, a sales lead, a subscriber, a patient with no
+     *   portal login. Their rows ARE personal data and carry the full weight of Arts 15–17 and 20 —
+     *   there is simply no session to end. Such a resource pairs this with `RETAIN_AND_IMPERSONALIZE`
+     *   and per-field `.impersonalizeWith()` treatments, and its subject-rights path is the ordinary
+     *   administrative one: `eraseSubjectAsSystem(resourceType, rowIds)` and a subject export.
+     *
+     * The second population is the majority of what a B2B SaaS customer stores about third parties, and
+     * it is what most of a privacy notice describes. Do not read this member as "nothing to disclose".
+     */
+    NO_PRINCIPAL = "no_principal",
+    /**
+     * Rows of this resource ARE the person, and the row's own id IS the session principal: erasing row
+     * `X` ends the session of user `X`. This is `USERS` / `USER_SELF`.
+     *
+     * Note this makes EXPLICIT a revocation that is otherwise only incidental. Erasing a `USERS` row
+     * already logs the user out today — but only as a side effect of the retention row-hide (the auth
+     * fronts re-read the user, find the row hidden, and 401) plus the scrub write bumping
+     * `authorizationVersion`. Nothing on the erasure path ever WROTE a revocation, so the guarantee
+     * lived entirely in the behaviour of two unrelated mechanisms.
+     */
+    SELF_PRINCIPAL = "self_principal",
+    /**
+     * Rows of this resource are a person whose login lives in a DIFFERENT `USERS` row — a Patient, an
+     * Employee, a Member record that a human signs in as. `sessionPrincipalField` names the field
+     * holding that user's id.
+     *
+     * The named field must carry no `.impersonalizeWith()` treatment. Not because the revocation would
+     * break — the principal is resolved BEFORE the scrub, so a scrubbed field is still readable when it
+     * matters — but because declaring one field to be BOTH the link to a person and personal data to
+     * destroy is self-contradictory, and it leaves the retained row with no way to say whose session was
+     * ended. Enforced at config build.
+     */
+    LINKED_PRINCIPAL = "linked_principal"
+}
+/**
+ * Zod schema for {@link ResourceDataSubjectKind}. Explicitly annotated for the
+ * `isolatedDeclarations` emit constraint.
+ */
+export declare const ResourceDataSubjectKindSchema: z.ZodEnum<typeof ResourceDataSubjectKind>;
+//# sourceMappingURL=impersonalization.shared.schemas.d.ts.map

package/dist/esm/compliance/privacy/impersonalization.shared.schemas.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"impersonalization.shared.schemas.d.ts","sourceRoot":"","sources":["../../../../../src/compliance/privacy/impersonalization.shared.schemas.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AAExB;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AACH,oBAAY,eAAe;IACzB,sDAAsD;IACtD,MAAM,WAAW;IACjB;;;;;OAKG;IACH,QAAQ,aAAa;CACtB;AAED;;;GAGG;AACH,eAAO,MAAM,qBAAqB,EAAE,CAAC,CAAC,OAAO,CAAC,OAAO,eAAe,CAC3C,CAAC;AAE1B;;;;;;;;;;;;;;GAcG;AACH,oBAAY,oBAAoB;IAC9B;;;;;;OAMG;IACH,WAAW,gBAAgB;IAC3B;;;;;;OAMG;IACH,wBAAwB,6BAA6B;CACtD;AAED;;;GAGG;AACH,eAAO,MAAM,0BAA0B,EAAE,CAAC,CAAC,OAAO,CAAC,OAAO,oBAAoB,CAChD,CAAC;AAE/B;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAkDG;AACH,oBAAY,uBAAuB;IACjC;;;;;;;;;;;;;;;;;;OAkBG;IACH,YAAY,iBAAiB;IAC7B;;;;;;;;;OASG;IACH,cAAc,mBAAmB;IACjC;;;;;;;;;;OAUG;IACH,gBAAgB,qBAAqB;CACtC;AAED;;;GAGG;AACH,eAAO,MAAM,6BAA6B,EAAE,CAAC,CAAC,OAAO,CAAC,OAAO,uBAAuB,CACnD,CAAC"}

package/dist/esm/compliance/privacy/impersonalization.shared.schemas.js

@@ -0,0 +1,184 @@
+import { z } from 'zod';
+/**
+ * # Impersonalization — per-record retention lifecycle state
+ *
+ * `impersonalization` = scrubbing the personal data OUT of a stored record while
+ * KEEPING the row, so it can be retained for a legal/audit obligation (GDPR
+ * Art. 17(3)(b) legal-obligation carve-out; tax/SOX retention). This is the third
+ * erasure outcome alongside hard-delete and leave-as-is.
+ *
+ * ⚠️ **Not** the anonymous-user concept. `isAnonymizable` / `anonymousUserId` /
+ * anonymous-session ownership transposition is an unrelated, opposite-direction
+ * mechanism (carrying a pre-auth anonymous session's rows forward to a real user).
+ * Never conflate the two. See `.claude/plans/retention-impersonalization-architecture.md`.
+ *
+ * `RetentionStatus` is the per-record marker the resource factory injects (as the
+ * `retentionStatus` field) onto any resource that opts into `retentionPolicy`. The
+ * INTENDED contract for a `RETAINED` record is **hidden and immutable by default**
+ * (behave-as-deleted), reachable only through the audited `seeRetained` see-through path.
+ *
+ * **LIVE.** The factory injects the marker (defaulting to `ACTIVE`), the visibility/immutability
+ * enforcement and the audited see-through read primitive are all wired and runtime-proven. A
+ * `RETAINED` record is hidden from every ordinary read, list, count and chart aggregate, and is
+ * immutable to ordinary writes. (This block previously said the enforcement was "wired in a later
+ * phase"; that became false without being revisited.)
+ */
+export var RetentionStatus;
+(function (RetentionStatus) {
+    /** Live record — normal visibility and mutability. */
+    RetentionStatus["ACTIVE"] = "active";
+    /**
+     * Impersonalized-and-retained — personal fields scrubbed in place, the row kept for a
+     * retention obligation. Intended semantics (enforcement wired in a later phase): hidden
+     * and immutable to normal callers; readable only via the audited see-through path;
+     * disposable only by a privileged system op.
+     */
+    RetentionStatus["RETAINED"] = "retained";
+})(RetentionStatus || (RetentionStatus = {}));
+/**
+ * Zod schema for {@link RetentionStatus}. Explicitly annotated for the
+ * `isolatedDeclarations` emit constraint.
+ */
+export const RetentionStatusSchema = z.enum(RetentionStatus);
+/**
+ * # What erasure DOES to a retention-governed row
+ *
+ * Retention (the row survives, is marked `RETAINED`, becomes hidden + immutable) and
+ * impersonalization (its personal FIELDS are scrubbed) are ORTHOGONAL. A record can be legally
+ * retainable while holding no personal data of its own — a financial row that merely POINTS at a
+ * person is the canonical case: erasing the subject must not destroy the invoice, but there is
+ * nothing on the invoice to scrub, because the name and address live on the linked user.
+ *
+ * Fusing the two axes forced such a resource to either declare a fake scrub (shipping a record
+ * stamped "impersonalized" that never was) or forgo retention entirely (letting the cascade destroy a
+ * legally-required record). Naming the two outcomes separately removes that false choice AND makes
+ * the author's claim auditable: "this resource holds no personal data" becomes an explicit, reviewable
+ * declaration rather than something a compliance reviewer must infer from an absence of treatments.
+ */
+export var ErasureRetentionMode;
+(function (ErasureRetentionMode) {
+    /**
+     * Keep and FREEZE the row; scrub nothing — this resource holds no personal data of its own.
+     *
+     * Declaring a `.impersonalizeWith()` treatment under this mode is a contradiction and fails at
+     * config build: if a field does hold personal data, the resource wants
+     * {@link ErasureRetentionMode.RETAIN_AND_IMPERSONALIZE} instead.
+     */
+    ErasureRetentionMode["RETAIN_ONLY"] = "retain_only";
+    /**
+     * Keep and freeze the row AND scrub the fields marked with `.impersonalizeWith()`.
+     *
+     * Requires at least one field that the writer would ACTUALLY scrub (a `KEEP` treatment, or one on a
+     * never-scrub floor field such as a scope FK, does not count) — otherwise the row would flip to
+     * `RETAINED` with every field intact while claiming to have been impersonalized.
+     */
+    ErasureRetentionMode["RETAIN_AND_IMPERSONALIZE"] = "retain_and_impersonalize";
+})(ErasureRetentionMode || (ErasureRetentionMode = {}));
+/**
+ * Zod schema for {@link ErasureRetentionMode}. Explicitly annotated for the
+ * `isolatedDeclarations` emit constraint.
+ */
+export const ErasureRetentionModeSchema = z.enum(ErasureRetentionMode);
+/**
+ * **WHOSE SESSION ENDS** when a row of this resource is erased. The second axis of the erasure
+ * contract, beside {@link ErasureRetentionMode} (which says what happens to the row).
+ *
+ * ## This axis is NOT "is this row about a person?" — read this before adding a member
+ *
+ * The two questions look like one and are not, and conflating them cost this vocabulary a member name
+ * for months (see the rename note below). Wildo answers them on SEPARATE axes:
+ *
+ * | question | the axis that answers it |
+ * |---|---|
+ * | Does this resource hold personal data? | {@link ErasureRetentionMode} — `RETAIN_AND_IMPERSONALIZE` requires at least one field that would actually be scrubbed; `RETAIN_ONLY` means *"holds no personal data of its own"*, and a scrub treatment under it fails at config build |
+ * | Can a subject-access or portability export answer for it? | `systemAccessPolicy.exportSubject` |
+ * | **Whose login session must be revoked?** | **this enum** |
+ *
+ * A CRM contact, a sales lead, a newsletter subscriber and a patient with no portal account are all
+ * **data subjects with no session**. They declare `RETAIN_AND_IMPERSONALIZE` (they hold personal data)
+ * and {@link ResourceDataSubjectKind.NO_PRINCIPAL} (there is no session to end) — two independent,
+ * truthful answers. Adding a fourth member here for them would make this enum a cross-product of two
+ * axes, which is two fields wearing one name.
+ *
+ * ## Why the third member is `NO_PRINCIPAL` and not `NOT_A_DATA_SUBJECT`
+ *
+ * It was `NOT_A_DATA_SUBJECT` until 2026-08-28, and the name was the defect. Operationally it always
+ * meant *"revoke nobody"* — which is exactly right for a CRM contact — while its NAME claimed the row
+ * was not about a person, which is false for one. Nothing misbehaved at runtime (the single consumer,
+ * `resolveScrubSessionPrincipals`, only ever asked the session question), so the cost landed entirely
+ * on readers: a human, and a compliance-document generator, both read the name and would have stated
+ * in a published privacy notice that the application holds no personal data in precisely the resource
+ * its customers care most about.
+ *
+ * The industry model this now matches is unambiguous — Intercom deletes "a user **or lead**", HubSpot
+ * GDPR-deletes a Contact by id or by email, Zendesk "forgets" an end-user: an account and a data
+ * subject are different objects, and the erasure verb applies to both. Wildo's `eraseSubjectAsSystem`
+ * already takes `(resourceType, rowIds)` with no principal, so the capability was never missing.
+ *
+ * ## Why this must be DECLARED and can never be inferred
+ *
+ * An erasure of a person must also end that person's session, or a "deleted" person keeps browsing on
+ * a live token until it expires. The tempting shortcut is to look for a `userId`-shaped foreign key on
+ * the erased row and revoke it. **That shortcut is a defect, not an optimisation.** On almost every
+ * resource a user foreign key names the OWNER or the ACTOR, not the subject: Wonder Todos' `TODOS` is
+ * retention-governed and carries `createdByUserId`, `assignedToUserId` and `escalationContactUserId`,
+ * so an inferring implementation would log out the author, the assignee and the escalation contact —
+ * three people, none of them the data subject — every time a todo was erased.
+ *
+ * So the linkage is authored, never guessed, and a resource that can be an erasure subject (i.e. one
+ * declaring a `retentionPolicy`) must say which of these it is. Undeclared is refused at config build:
+ * nobody has decided yet, and refusing is what forces the decision — the same doctrine the subject
+ * EXPORT model applies to an undeclared resource.
+ */
+export var ResourceDataSubjectKind;
+(function (ResourceDataSubjectKind) {
+    /**
+     * Erasing a row of this resource revokes **no session**, because no login is reachable from it.
+     *
+     * Two very different populations share this answer, and the enum is deliberately silent about which
+     * one a given resource is — {@link ErasureRetentionMode} says that:
+     *
+     * - **Not a person at all.** A todo, an invoice, a log line. Any user foreign keys it carries name
+     *   ACTORS — an author, an assignee, an owner, an escalation contact — and revoking their sessions
+     *   because a record was erased would log out three uninvolved people. Such a resource pairs this
+     *   with `RETAIN_ONLY`.
+     * - **A person with no account.** A CRM contact, a sales lead, a subscriber, a patient with no
+     *   portal login. Their rows ARE personal data and carry the full weight of Arts 15–17 and 20 —
+     *   there is simply no session to end. Such a resource pairs this with `RETAIN_AND_IMPERSONALIZE`
+     *   and per-field `.impersonalizeWith()` treatments, and its subject-rights path is the ordinary
+     *   administrative one: `eraseSubjectAsSystem(resourceType, rowIds)` and a subject export.
+     *
+     * The second population is the majority of what a B2B SaaS customer stores about third parties, and
+     * it is what most of a privacy notice describes. Do not read this member as "nothing to disclose".
+     */
+    ResourceDataSubjectKind["NO_PRINCIPAL"] = "no_principal";
+    /**
+     * Rows of this resource ARE the person, and the row's own id IS the session principal: erasing row
+     * `X` ends the session of user `X`. This is `USERS` / `USER_SELF`.
+     *
+     * Note this makes EXPLICIT a revocation that is otherwise only incidental. Erasing a `USERS` row
+     * already logs the user out today — but only as a side effect of the retention row-hide (the auth
+     * fronts re-read the user, find the row hidden, and 401) plus the scrub write bumping
+     * `authorizationVersion`. Nothing on the erasure path ever WROTE a revocation, so the guarantee
+     * lived entirely in the behaviour of two unrelated mechanisms.
+     */
+    ResourceDataSubjectKind["SELF_PRINCIPAL"] = "self_principal";
+    /**
+     * Rows of this resource are a person whose login lives in a DIFFERENT `USERS` row — a Patient, an
+     * Employee, a Member record that a human signs in as. `sessionPrincipalField` names the field
+     * holding that user's id.
+     *
+     * The named field must carry no `.impersonalizeWith()` treatment. Not because the revocation would
+     * break — the principal is resolved BEFORE the scrub, so a scrubbed field is still readable when it
+     * matters — but because declaring one field to be BOTH the link to a person and personal data to
+     * destroy is self-contradictory, and it leaves the retained row with no way to say whose session was
+     * ended. Enforced at config build.
+     */
+    ResourceDataSubjectKind["LINKED_PRINCIPAL"] = "linked_principal";
+})(ResourceDataSubjectKind || (ResourceDataSubjectKind = {}));
+/**
+ * Zod schema for {@link ResourceDataSubjectKind}. Explicitly annotated for the
+ * `isolatedDeclarations` emit constraint.
+ */
+export const ResourceDataSubjectKindSchema = z.enum(ResourceDataSubjectKind);
+//# sourceMappingURL=impersonalization.shared.schemas.js.map

package/dist/esm/compliance/privacy/impersonalization.shared.schemas.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"impersonalization.shared.schemas.js","sourceRoot":"","sources":["../../../../../src/compliance/privacy/impersonalization.shared.schemas.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AAExB;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AACH,MAAM,CAAN,IAAY,eAUX;AAVD,WAAY,eAAe;IACzB,sDAAsD;IACtD,oCAAiB,CAAA;IACjB;;;;;OAKG;IACH,wCAAqB,CAAA;AACvB,CAAC,EAVW,eAAe,KAAf,eAAe,QAU1B;AAED;;;GAGG;AACH,MAAM,CAAC,MAAM,qBAAqB,GAChC,CAAC,CAAC,IAAI,CAAC,eAAe,CAAC,CAAC;AAE1B;;;;;;;;;;;;;;GAcG;AACH,MAAM,CAAN,IAAY,oBAiBX;AAjBD,WAAY,oBAAoB;IAC9B;;;;;;OAMG;IACH,mDAA2B,CAAA;IAC3B;;;;;;OAMG;IACH,6EAAqD,CAAA;AACvD,CAAC,EAjBW,oBAAoB,KAApB,oBAAoB,QAiB/B;AAED;;;GAGG;AACH,MAAM,CAAC,MAAM,0BAA0B,GACrC,CAAC,CAAC,IAAI,CAAC,oBAAoB,CAAC,CAAC;AAE/B;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAkDG;AACH,MAAM,CAAN,IAAY,uBA4CX;AA5CD,WAAY,uBAAuB;IACjC;;;;;;;;;;;;;;;;;;OAkBG;IACH,wDAA6B,CAAA;IAC7B;;;;;;;;;OASG;IACH,4DAAiC,CAAA;IACjC;;;;;;;;;;OAUG;IACH,gEAAqC,CAAA;AACvC,CAAC,EA5CW,uBAAuB,KAAvB,uBAAuB,QA4ClC;AAED;;;GAGG;AACH,MAAM,CAAC,MAAM,6BAA6B,GACxC,CAAC,CAAC,IAAI,CAAC,uBAAuB,CAAC,CAAC","sourcesContent":["import { z } from 'zod';\n\n/**\n * # Impersonalization — per-record retention lifecycle state\n *\n * `impersonalization` = scrubbing the personal data OUT of a stored record while\n * KEEPING the row, so it can be retained for a legal/audit obligation (GDPR\n * Art. 17(3)(b) legal-obligation carve-out; tax/SOX retention). This is the third\n * erasure outcome alongside hard-delete and leave-as-is.\n *\n * ⚠️ **Not** the anonymous-user concept. `isAnonymizable` / `anonymousUserId` /\n * anonymous-session ownership transposition is an unrelated, opposite-direction\n * mechanism (carrying a pre-auth anonymous session's rows forward to a real user).\n * Never conflate the two. See `.claude/plans/retention-impersonalization-architecture.md`.\n *\n * `RetentionStatus` is the per-record marker the resource factory injects (as the\n * `retentionStatus` field) onto any resource that opts into `retentionPolicy`. The\n * INTENDED contract for a `RETAINED` record is **hidden and immutable by default**\n * (behave-as-deleted), reachable only through the audited `seeRetained` see-through path.\n *\n * **LIVE.** The factory injects the marker (defaulting to `ACTIVE`), the visibility/immutability\n * enforcement and the audited see-through read primitive are all wired and runtime-proven. A\n * `RETAINED` record is hidden from every ordinary read, list, count and chart aggregate, and is\n * immutable to ordinary writes. (This block previously said the enforcement was \"wired in a later\n * phase\"; that became false without being revisited.)\n */\nexport enum RetentionStatus {\n  /** Live record — normal visibility and mutability. */\n  ACTIVE = 'active',\n  /**\n   * Impersonalized-and-retained — personal fields scrubbed in place, the row kept for a\n   * retention obligation. Intended semantics (enforcement wired in a later phase): hidden\n   * and immutable to normal callers; readable only via the audited see-through path;\n   * disposable only by a privileged system op.\n   */\n  RETAINED = 'retained',\n}\n\n/**\n * Zod schema for {@link RetentionStatus}. Explicitly annotated for the\n * `isolatedDeclarations` emit constraint.\n */\nexport const RetentionStatusSchema: z.ZodEnum<typeof RetentionStatus> =\n  z.enum(RetentionStatus);\n\n/**\n * # What erasure DOES to a retention-governed row\n *\n * Retention (the row survives, is marked `RETAINED`, becomes hidden + immutable) and\n * impersonalization (its personal FIELDS are scrubbed) are ORTHOGONAL. A record can be legally\n * retainable while holding no personal data of its own — a financial row that merely POINTS at a\n * person is the canonical case: erasing the subject must not destroy the invoice, but there is\n * nothing on the invoice to scrub, because the name and address live on the linked user.\n *\n * Fusing the two axes forced such a resource to either declare a fake scrub (shipping a record\n * stamped \"impersonalized\" that never was) or forgo retention entirely (letting the cascade destroy a\n * legally-required record). Naming the two outcomes separately removes that false choice AND makes\n * the author's claim auditable: \"this resource holds no personal data\" becomes an explicit, reviewable\n * declaration rather than something a compliance reviewer must infer from an absence of treatments.\n */\nexport enum ErasureRetentionMode {\n  /**\n   * Keep and FREEZE the row; scrub nothing — this resource holds no personal data of its own.\n   *\n   * Declaring a `.impersonalizeWith()` treatment under this mode is a contradiction and fails at\n   * config build: if a field does hold personal data, the resource wants\n   * {@link ErasureRetentionMode.RETAIN_AND_IMPERSONALIZE} instead.\n   */\n  RETAIN_ONLY = 'retain_only',\n  /**\n   * Keep and freeze the row AND scrub the fields marked with `.impersonalizeWith()`.\n   *\n   * Requires at least one field that the writer would ACTUALLY scrub (a `KEEP` treatment, or one on a\n   * never-scrub floor field such as a scope FK, does not count) — otherwise the row would flip to\n   * `RETAINED` with every field intact while claiming to have been impersonalized.\n   */\n  RETAIN_AND_IMPERSONALIZE = 'retain_and_impersonalize',\n}\n\n/**\n * Zod schema for {@link ErasureRetentionMode}. Explicitly annotated for the\n * `isolatedDeclarations` emit constraint.\n */\nexport const ErasureRetentionModeSchema: z.ZodEnum<typeof ErasureRetentionMode> =\n  z.enum(ErasureRetentionMode);\n\n/**\n * **WHOSE SESSION ENDS** when a row of this resource is erased. The second axis of the erasure\n * contract, beside {@link ErasureRetentionMode} (which says what happens to the row).\n *\n * ## This axis is NOT \"is this row about a person?\" — read this before adding a member\n *\n * The two questions look like one and are not, and conflating them cost this vocabulary a member name\n * for months (see the rename note below). Wildo answers them on SEPARATE axes:\n *\n * | question | the axis that answers it |\n * |---|---|\n * | Does this resource hold personal data? | {@link ErasureRetentionMode} — `RETAIN_AND_IMPERSONALIZE` requires at least one field that would actually be scrubbed; `RETAIN_ONLY` means *\"holds no personal data of its own\"*, and a scrub treatment under it fails at config build |\n * | Can a subject-access or portability export answer for it? | `systemAccessPolicy.exportSubject` |\n * | **Whose login session must be revoked?** | **this enum** |\n *\n * A CRM contact, a sales lead, a newsletter subscriber and a patient with no portal account are all\n * **data subjects with no session**. They declare `RETAIN_AND_IMPERSONALIZE` (they hold personal data)\n * and {@link ResourceDataSubjectKind.NO_PRINCIPAL} (there is no session to end) — two independent,\n * truthful answers. Adding a fourth member here for them would make this enum a cross-product of two\n * axes, which is two fields wearing one name.\n *\n * ## Why the third member is `NO_PRINCIPAL` and not `NOT_A_DATA_SUBJECT`\n *\n * It was `NOT_A_DATA_SUBJECT` until 2026-08-28, and the name was the defect. Operationally it always\n * meant *\"revoke nobody\"* — which is exactly right for a CRM contact — while its NAME claimed the row\n * was not about a person, which is false for one. Nothing misbehaved at runtime (the single consumer,\n * `resolveScrubSessionPrincipals`, only ever asked the session question), so the cost landed entirely\n * on readers: a human, and a compliance-document generator, both read the name and would have stated\n * in a published privacy notice that the application holds no personal data in precisely the resource\n * its customers care most about.\n *\n * The industry model this now matches is unambiguous — Intercom deletes \"a user **or lead**\", HubSpot\n * GDPR-deletes a Contact by id or by email, Zendesk \"forgets\" an end-user: an account and a data\n * subject are different objects, and the erasure verb applies to both. Wildo's `eraseSubjectAsSystem`\n * already takes `(resourceType, rowIds)` with no principal, so the capability was never missing.\n *\n * ## Why this must be DECLARED and can never be inferred\n *\n * An erasure of a person must also end that person's session, or a \"deleted\" person keeps browsing on\n * a live token until it expires. The tempting shortcut is to look for a `userId`-shaped foreign key on\n * the erased row and revoke it. **That shortcut is a defect, not an optimisation.** On almost every\n * resource a user foreign key names the OWNER or the ACTOR, not the subject: Wonder Todos' `TODOS` is\n * retention-governed and carries `createdByUserId`, `assignedToUserId` and `escalationContactUserId`,\n * so an inferring implementation would log out the author, the assignee and the escalation contact —\n * three people, none of them the data subject — every time a todo was erased.\n *\n * So the linkage is authored, never guessed, and a resource that can be an erasure subject (i.e. one\n * declaring a `retentionPolicy`) must say which of these it is. Undeclared is refused at config build:\n * nobody has decided yet, and refusing is what forces the decision — the same doctrine the subject\n * EXPORT model applies to an undeclared resource.\n */\nexport enum ResourceDataSubjectKind {\n  /**\n   * Erasing a row of this resource revokes **no session**, because no login is reachable from it.\n   *\n   * Two very different populations share this answer, and the enum is deliberately silent about which\n   * one a given resource is — {@link ErasureRetentionMode} says that:\n   *\n   * - **Not a person at all.** A todo, an invoice, a log line. Any user foreign keys it carries name\n   *   ACTORS — an author, an assignee, an owner, an escalation contact — and revoking their sessions\n   *   because a record was erased would log out three uninvolved people. Such a resource pairs this\n   *   with `RETAIN_ONLY`.\n   * - **A person with no account.** A CRM contact, a sales lead, a subscriber, a patient with no\n   *   portal login. Their rows ARE personal data and carry the full weight of Arts 15–17 and 20 —\n   *   there is simply no session to end. Such a resource pairs this with `RETAIN_AND_IMPERSONALIZE`\n   *   and per-field `.impersonalizeWith()` treatments, and its subject-rights path is the ordinary\n   *   administrative one: `eraseSubjectAsSystem(resourceType, rowIds)` and a subject export.\n   *\n   * The second population is the majority of what a B2B SaaS customer stores about third parties, and\n   * it is what most of a privacy notice describes. Do not read this member as \"nothing to disclose\".\n   */\n  NO_PRINCIPAL = 'no_principal',\n  /**\n   * Rows of this resource ARE the person, and the row's own id IS the session principal: erasing row\n   * `X` ends the session of user `X`. This is `USERS` / `USER_SELF`.\n   *\n   * Note this makes EXPLICIT a revocation that is otherwise only incidental. Erasing a `USERS` row\n   * already logs the user out today — but only as a side effect of the retention row-hide (the auth\n   * fronts re-read the user, find the row hidden, and 401) plus the scrub write bumping\n   * `authorizationVersion`. Nothing on the erasure path ever WROTE a revocation, so the guarantee\n   * lived entirely in the behaviour of two unrelated mechanisms.\n   */\n  SELF_PRINCIPAL = 'self_principal',\n  /**\n   * Rows of this resource are a person whose login lives in a DIFFERENT `USERS` row — a Patient, an\n   * Employee, a Member record that a human signs in as. `sessionPrincipalField` names the field\n   * holding that user's id.\n   *\n   * The named field must carry no `.impersonalizeWith()` treatment. Not because the revocation would\n   * break — the principal is resolved BEFORE the scrub, so a scrubbed field is still readable when it\n   * matters — but because declaring one field to be BOTH the link to a person and personal data to\n   * destroy is self-contradictory, and it leaves the retained row with no way to say whose session was\n   * ended. Enforced at config build.\n   */\n  LINKED_PRINCIPAL = 'linked_principal',\n}\n\n/**\n * Zod schema for {@link ResourceDataSubjectKind}. Explicitly annotated for the\n * `isolatedDeclarations` emit constraint.\n */\nexport const ResourceDataSubjectKindSchema: z.ZodEnum<typeof ResourceDataSubjectKind> =\n  z.enum(ResourceDataSubjectKind);\n"]}