@wildo-ai/saas-models 1.1.4 → 1.1.5

package/dist/esm/compliance/privacy/subject-erasure.shared.schemas.d.ts

@@ -1,5 +1,6 @@
 import { type ResourceRelationship } from '../../resources/resources.shared.schemas';
 import type { ResourceType } from '../../resources/resources.shared.core.definitions';
+import { ErasureRetentionMode } from './impersonalization.shared.schemas';
 /**
  * What a SUBJECT ERASURE does to one child-direction edge of the subject.
  *
@@ -18,11 +19,12 @@ import type { ResourceType } from '../../resources/resources.shared.core.definit
  * about is exactly where personal data survives an erasure unnoticed.
  *
  * Two members therefore have no runtime action and exist to make the erasure FAIL LOUD
- * ({@link UNCLASSIFIED}, {@link UNSUPPORTED_DEFERRED}), and two describe leaving a row alone for
- * two genuinely different reasons ({@link RETAINED_BY_DECLARATION} vs {@link NOT_OWNED}). Those two
- * are not merged despite sharing a no-op: a data-protection reviewer asking "why is this row still
- * here?" needs "because the author declared it retained" and "because it was never the subject's
- * row" to be different answers, and only the first one is a compliance claim someone made.
+ * ({@link UNCLASSIFIED}, {@link UNSUPPORTED_DEFERRED}), and three describe leaving a row alone for
+ * three genuinely different reasons ({@link RETAINED_BY_DECLARATION}, {@link RESTRICTED_BY_DECLARATION},
+ * {@link NOT_OWNED}). They are not merged despite sharing a no-op: a data-protection reviewer asking
+ * "why is this row still here?" needs "because the author declared it retained", "because its parent
+ * may not be deleted while it exists" and "because it was never the subject's row" to be different
+ * answers, and only the first one is a retention claim someone made.
  */
 export declare enum SubjectErasureDisposition {
     /**
@@ -48,6 +50,23 @@ export declare enum SubjectErasureDisposition {
      * rely on the erased subject row still resolving their foreign keys.
      */
     RETAINED_BY_DECLARATION = "retained_by_declaration",
+    /**
+     * LEAVE THE ROWS EXACTLY AS THEY ARE — a dependent whose edge declares the RESTRICT posture
+     * (`onParentDelete.strategy: REFUSE_WHILE_CHILDREN_EXIST`): the parent's delete is refused while
+     * these rows exist, and nothing about the parent's teardown removes them.
+     *
+     * An erasure scrubs its subject in place and never deletes it, so at the direct level the refusal is
+     * never met and the rows keep resolving their foreign key, as a retained row does. Below a dependent
+     * the erasure DELETES, the same edge holding rows refuses the erasure, as a delete cascade frame does,
+     * because deleting that parent would strand them. Kept apart from
+     * {@link RETAINED_BY_DECLARATION} because the claim differs: that one says "these rows must outlive
+     * their parent", this one says "their parent may not go while they exist". The second is about
+     * referential integrity (an org-unit subtree, the provider-customer mapping a billing account holds
+     * for its financial records), not a retention obligation.
+     *
+     * Like the other leave-alone dispositions, the erasure does not walk below these rows.
+     */
+    RESTRICTED_BY_DECLARATION = "restricted_by_declaration",
     /**
      * LEAVE THE ROWS ALONE — the edge is not an ownership edge at all
      * (`lifecycleModelMode` is `INDEPENDENT` or `LINK_ONLY`, or the relationship is disabled). The
@@ -83,6 +102,20 @@ export interface SubjectErasureEdgeClassification {
      */
     reason: string;
 }
+/**
+ * The only part of a child's `retentionPolicy` an erasure classification reads (#1279).
+ *
+ * Structural and minimal on purpose: the classifier needs the erasure TREATMENT and nothing else, and
+ * narrowing the parameter to this keeps every caller — the runtime orchestrator, the registry sweep and
+ * the boot-time guards, which each hold a differently-shaped configuration record — able to answer
+ * without first building a full `ResourceRetentionPolicy` it does not otherwise need.
+ *
+ * `mode` is optional because a caller may legitimately hold a resource entry with no retention opt-in;
+ * that is the same answer as passing `undefined` and means "this child declares no erasure treatment".
+ */
+export interface SubjectErasureChildRetentionDeclaration {
+    readonly mode?: ErasureRetentionMode;
+}
 /**
  * True when a disposition must stop the erasure before any write lands.
  *
@@ -106,28 +139,230 @@ export declare function isBlockingSubjectErasureDisposition(disposition: Subject
  *  2. **`childOperations.lifecycle.onParentDelete`** — for an owned dependent, what did the author
  *     declare happens when the parent stops owning it: hard-delete, scrub-and-retain, or nothing.
  *
- * ## The semantic caveat, stated plainly
+ *  3. **the child's own `retentionPolicy`** — the ONE declaration whose entire subject is this
+ *     question: *"`retentionPolicy.mode` on a resource says WHAT erasure does to a row"*
+ *     (`retention-schedule.shared.schemas.ts`). Supplied through `resolveChildRetentionPolicy` so this
+ *     function stays pure.
+ *
+ * ## The semantic caveat — CORRECTED 2026-09-17 (#1279), and the correction is the point
  *
  * `onParentDelete` literally answers "what happens when the parent row is DELETED", and an erasure
- * does NOT delete the subject — it scrubs and keeps it. v1 deliberately treats the two questions as
- * one because they have the same answer for every edge in the shipped registry, and because an
- * author who declared "this dependent dies with its parent" has already said the thing that
- * matters: the dependent's data has no life of its own once the subject's does not.
+ * does NOT delete the subject — it scrubs and keeps it. This function used to treat the two questions
+ * as one, on a stated premise: *"they have the same answer for every edge in the shipped registry"*.
+ *
+ * **That premise was false, and it had never been measured.** Measured across `engine/`, `platform/`
+ * and `examples/`: 28 edges reached a `DELETE` erasure disposition while the child resource declared
+ * `retentionPolicy` — i.e. an erasure deleting rows whose own resource says an erasure keeps them.
+ *
+ * What made it invisible was a SCHEMA DEFAULT. `strategy` carried
+ * `.default(ChildLifecycleStrategy.DELETE)`, so every parsed edge presented `strategy: 'delete'` as an
+ * own property whether or not a human had ever considered the question — and **28 of those 28 edges
+ * reached DELETE through that default. Not one author had written `strategy: DELETE` for a
+ * retain-declaring resource.** The default was removed (see `ChildLifecycleOnDeleteConfigSchema`), so
+ * absence now arrives here intact and this function can tell a decision from a silence.
+ *
+ * ## The precedence, which decides no legal question
+ *
+ * | child `retentionPolicy` | this edge's `strategy` | disposition |
+ * |---|---|---|
+ * | declared (retain) | **absent** | the retain treatment — the author answered the ERASURE question and nobody answered the teardown one. A default may not overrule a declaration |
+ * | declared (retain) | authored `DELETE` | `CONTRADICTED_BY_DECLARATIONS` — refused |
+ * | declared (retain) | authored `IMPERSONALIZE_AND_RETAIN` | they agree; the edge's arm below runs |
+ * | none | anything, including absent | unchanged — no erasure declaration exists to honour |
  *
- * They are NOT the same question though, and the day a resource needs to answer them differently
- * (retain a dependent on erasure that it hard-deletes on parent-delete, or the reverse) the
- * expressible extension is a sibling `onSubjectErasure` axis on the same edge, defaulting to this
- * derivation. Adding that axis speculatively now would give app authors a second knob with no
- * consumer and two ways to say the same thing.
+ * Note what is deliberately NOT done: "retain wins" is not made a blanket default over an AUTHORED
+ * `DELETE`. {@link findSubjectErasureRetainDeleteConflicts} rejects exactly that reasoning for the
+ * edge-vs-edge case — *it decides a legal question on the author's behalf; neither default is safe, so
+ * no default* — and that rejection stands here. Deleting data a retention obligation required keeping
+ * and stranding data an erasure claimed to have removed are both unsafe, and nothing in the
+ * configuration says which the author meant. The only thing that changed is that a SCHEMA DEFAULT may
+ * no longer impersonate an author's decision.
+ *
+ * A sibling `onSubjectErasure` axis on the edge was reconsidered and stays rejected: `retentionPolicy`
+ * already IS the erasure axis, and adding a second one would give app authors two ways to say the same
+ * thing — the objection the previous version of this note raised against it, which survives its own
+ * premise being wrong.
  *
  * Pure and side-effect free — no registry lookups, no I/O — so it is equally usable from a runtime
  * orchestrator and from a boot-time guard.
  */
-export declare function classifySubjectErasureDisposition(relationship: ResourceRelationship): SubjectErasureEdgeClassification;
+export declare function classifySubjectErasureDisposition(relationship: ResourceRelationship, resolveChildRetentionPolicy: (resourceType: ResourceType) => SubjectErasureChildRetentionDeclaration | undefined): SubjectErasureEdgeClassification;
+/**
+ * One DESCENDANT edge an erasure must account for — an edge below the subject's direct dependents,
+ * planned from configuration before anything runs (#976).
+ *
+ * `parentResourceType` is the resource whose rows the erasure tears down and that owns this edge;
+ * the classification is the same one a direct edge gets, from the same shared classifier, so a
+ * descendant and a direct edge can never disagree about what an identical declaration means.
+ */
+export interface SubjectErasureDescendantEdgePlan {
+    /** The edge itself, as the parent resource's configuration declares it. */
+    relationship: ResourceRelationship;
+    /** The resource that owns this edge — its rows are the ones being torn down above it. */
+    parentResourceType: ResourceType;
+    classification: SubjectErasureEdgeClassification;
+}
+/**
+ * Plan every DESCENDANT edge a subject erasure walks below ONE direct dependent (#976).
+ *
+ * ## What an erasure walks, and why exactly that
+ *
+ * - **Below a `DELETE` edge — everything, at every depth, regardless of `maxDepth`.** The rows are
+ *   gone, so whatever depended on them has lost its owner; an erasure that stops at a depth budget
+ *   leaves the subject's data one level down with nothing left to reach it. `maxDepth` is a
+ *   parent-DELETE performance budget and keeps meaning exactly that on the delete cascade.
+ * - **Below an `IMPERSONALIZE_AND_RETAIN` edge — nothing.** The retained row survives, scrubbed, so
+ *   its own dependents still have their owner and remain bound to THAT row's future lifecycle. The
+ *   retention obligation that keeps the row is the obligation that keeps what hangs off it; tearing
+ *   those down would destroy records a legal obligation required keeping, and scrubbing them would
+ *   need a declaration nobody made. This matches the cascade itself, whose retain arm never recurses.
+ * - **Below `RETAINED_BY_DECLARATION` / `NOT_OWNED` — nothing.** The rows are not touched.
+ *
+ * Every child-direction edge of every walked resource is returned — including the ones that do
+ * nothing — because the receipt is total over what the erasure walked, exactly as it is at the
+ * direct level. A blocking classification anywhere in the plan must refuse the erasure BEFORE its
+ * transaction opens; returning it (rather than throwing here) lets the caller name every one.
+ *
+ * ## Termination
+ *
+ * The walk is over RESOURCE TYPES, not rows, so each type's edges are planned once: a self-referential
+ * edge (a folder of folders) or a cycle between types terminates here, while the row-level cascade
+ * keeps its own visited-row guard.
+ *
+ * Pure: the caller supplies the lookup, so a boot-time guard can run the same planner the runtime
+ * does rather than re-deriving it.
+ *
+ * @param directChildResourceType - the far side of the subject's direct `DELETE` edge.
+ * @param resolveChildDirectionRelationships - the child-direction edges of a resource type, or
+ *   `undefined` when the type has no configuration in this process (nothing is planned below it; the
+ *   runtime cascade then declines that edge and reports it as not executed).
+ * @param resolveChildRetentionPolicy - a resource type's declared `retentionPolicy`, or `undefined`
+ *   when it declares none. Injected for the same reason as the lookup above: it keeps this planner
+ *   pure, so a boot-time guard classifies a descendant edge exactly as the runtime will (#1279).
+ */
+export declare function planSubjectErasureDescendantEdges(directChildResourceType: ResourceType, resolveChildDirectionRelationships: (resourceType: ResourceType) => ResourceRelationship[] | undefined, resolveChildRetentionPolicy: (resourceType: ResourceType) => SubjectErasureChildRetentionDeclaration | undefined): SubjectErasureDescendantEdgePlan[];
+/**
+ * One resource an erasure's plan reaches both to KEEP its rows and to DELETE them (#1017).
+ *
+ * `TEdge` is whatever the caller planned — a direct edge, a descendant edge, or its own record of either —
+ * so the orchestrator can name the edges the way its refusal already names unresolved ones.
+ */
+export interface SubjectErasureRetainDeleteConflict<TEdge> {
+    /** The resource on the far side of every edge below. */
+    resourceType: ResourceType;
+    /** Edges that scrub these rows and keep them (`IMPERSONALIZE_AND_RETAIN`), in plan order. */
+    retainingEdges: TEdge[];
+    /** Edges that hard-delete these rows (`DELETE`), in plan order. */
+    deletingEdges: TEdge[];
+}
+/**
+ * Find every resource a subject erasure's WHOLE plan reaches through both a retaining edge and a deleting
+ * edge (#1017). The erasure REFUSES before its transaction opens when this returns anything.
+ *
+ * ## The shape
+ *
+ * Each edge applies its own declared treatment to the rows it reaches: `DELETE` hard-deletes them,
+ * `IMPERSONALIZE_AND_RETAIN` scrubs them and keeps them. Two DIFFERENT paths can reach the same resource — a
+ * `people → records` retain edge beside `people → profiles → notes → records` delete, or two edges on one
+ * resource through two foreign keys — and nothing in either declaration says what happens to a row BOTH
+ * reach. Before this, the answer was the walk order: a row kept by the retain edge could still be deleted
+ * when the delete edge's cascade got there, and #976 could only make the receipt admit it (`executed: false`).
+ *
+ * ## Why REFUSE, and why at the level of resource types
+ *
+ * The two declarations contradict each other for the rows they share, and neither outranks the other in
+ * configuration. Refusing is the one answer that needs no new meaning: it surfaces the contradiction to the
+ * author, who owns both declarations and can make them agree — declare the delete edge
+ * `IMPERSONALIZE_AND_RETAIN` too, declare the retain edge `DELETE`, or disable one edge's teardown
+ * (`onParentDelete.enabled: false`) — on the ground the legal obligation actually gives.
+ *
+ * The check is over resource TYPES, not rows, on purpose. Whether two edges share a row is only knowable by
+ * reading rows, which the pre-flight must not do (every refusal here lands before the first read and write),
+ * and it changes as rows are written, so a row-level "no overlap today" would be a guess about the future.
+ * An edge pair that can never share a row in practice is still refused; the remedy is the same one-edge edit.
+ *
+ * ## Rejected: a precedence where retain wins
+ *
+ * "Keep a row whenever any edge retains it" was considered and rejected, for three reasons:
+ *
+ * - **It decides a legal question on the author's behalf.** A `DELETE` edge is a declaration too — that the
+ *   rows hold nothing worth keeping once their owner is gone. GDPR Art. 17(3) lists the grounds on which the
+ *   right to erasure does not apply (a legal obligation, the defence of legal claims, archiving, …), and
+ *   Art. 5(2) makes the controller "responsible for, and be able to demonstrate compliance with" the
+ *   principles. Keeping personal data an explicit declaration said to remove therefore needs a ground the
+ *   controller can name, and a framework default names none. "Delete wins" fails the other way, destroying
+ *   records a retention obligation required keeping. Neither default is safe, so no default.
+ *   spec-cite: Regulation (EU) 2016/679, Art. 5(2) (accountability) and Art. 17(3)(a)–(e) (exceptions to the right to erasure).
+ * - **Only its row-level form is faithful, and that form cannot be decided before the transaction.** A
+ *   TYPE-level "retain wins" could be decided pre-flight, but it would keep every row of the resource,
+ *   including rows only the delete edge reaches and the retain edge never touches — rows no retention
+ *   declaration covers. The faithful rule is ROW-level: the delete walk skips each row a retain edge kept and
+ *   prunes everything it planned below that row (a kept row still anchors its own dependents), per row,
+ *   mid-transaction. The pre-flight plan is over types and cannot express that, so the
+ *   refusal-before-any-write guarantee the rest of the erasure keeps would be lost.
+ * - **It adds a meaning with no vocabulary for its opposite.** Once precedence exists, an author who needs
+ *   the delete to win has no way to say so.
+ *
+ * ## What is NOT a conflict
+ *
+ * Only `DELETE` against `IMPERSONALIZE_AND_RETAIN` — the two treatments the erasure EXECUTES. Two deleting or
+ * two retaining edges agree. `NOT_OWNED` rows are not the subject's, and the erasure never discovers them.
+ * Two cases are deliberately NOT refused here. Each is an open decision, not an answer this rule gives:
+ *
+ * - **(a) A `RETAINED_BY_DECLARATION` dependent beside a `DELETE` path to the same resource (#1084).** The
+ *   erasure never discovers `enabled: false` rows, and a row with two parents that survives one teardown and
+ *   dies with the other is also what an ordinary parent delete does. **DECIDED 2026-09-17: this stays out.**
+ *   `enabled: false` executes nothing, so there are not two treatments to reconcile — and the refusal below
+ *   names `onParentDelete.enabled: false` as its own remedy, so counting it as a conflict would make that
+ *   remedy produce the next refusal. The full argument is at the classification site.
+ * - **(b) A delete closure that cycles back to the SUBJECT's own resource type while the subject row is
+ *   retained (#1085).** The subject's retention is the erasure's own final step (the scrub), not an edge, so
+ *   this detector — which reads only edges — cannot see it. **CLOSED 2026-09-17 by
+ *   {@link findSubjectErasureSubjectTypeDeleteEdges}**, a sibling that takes the subject's own type as an
+ *   argument precisely because it is not derivable from the edges.
+ *
+ * Pure, so a boot-time guard can run it over the same plan the runtime refuses on.
+ *
+ * @param plannedEdges - every edge of ONE erasure: the subject's direct edges AND every descendant edge
+ *   planned below its deleted dependents, each carrying its classification.
+ * @returns one entry per conflicting resource, in the order the resource is first reached.
+ */
+export declare function findSubjectErasureRetainDeleteConflicts<TEdge extends {
+    classification: SubjectErasureEdgeClassification;
+}>(plannedEdges: readonly TEdge[]): Array<SubjectErasureRetainDeleteConflict<TEdge>>;
+/**
+ * What happened on ONE descendant edge of an executed erasure (#976) — reported exactly like a direct
+ * edge: its disposition, the configuration that justified it, and whether its teardown ran.
+ */
+export interface SubjectErasureDescendantEdgeOutcome extends SubjectErasureEdgeClassification {
+    /** The resource that owns this edge. */
+    parentResourceType: ResourceType;
+    /**
+     * `true` when every teardown the erasure reached on this edge ran, `false` when any was declined, when
+     * this DELETE edge reached rows an earlier retain edge of the same walk scrubbed and KEPT (they are not
+     * gone, whatever this edge declares — unreachable since #1017, which refuses a plan that retains and deletes
+     * one resource before it runs, and kept as defence in depth), or when an edge ABOVE it was declined (its rows were then never
+     * walked, so nothing can be said about what they still hold). `false` on a non-executing disposition
+     * is expected, as on a direct edge.
+     *
+     * An executing edge the walk never had to dispatch — its parent resource had no rows of the subject's
+     * left to tear down — is `true`: that is a teardown with nothing to do, not a decline.
+     */
+    executed: boolean;
+}
 /** Per-edge outcome of an executed erasure — the classification plus what actually happened. */
 export interface SubjectErasureEdgeOutcome extends SubjectErasureEdgeClassification {
     /**
-     * `true` when the erasure ran a teardown for this edge.
+     * Every edge below this one that the erasure walked, flat and in plan order (#976). Empty for a
+     * non-executing disposition and for `IMPERSONALIZE_AND_RETAIN`, which retains its rows and therefore
+     * does not walk below them — see {@link planSubjectErasureDescendantEdges}.
+     */
+    descendantEdges: SubjectErasureDescendantEdgeOutcome[];
+    /**
+     * `true` when the erasure ran a teardown for this edge AND for every descendant edge below it whose
+     * disposition executes (#976). A declined descendant therefore makes its direct edge `false`: a
+     * reader who only counts direct edges must not read a subtree that still holds live data as erased.
+     * {@link descendantEdges} says which descendant it was.
      *
      * Reports that the teardown RAN, not that rows existed — discovery finding no dependents is a
      * teardown that ran with nothing to do, and is `true`.
@@ -137,9 +372,12 @@ export interface SubjectErasureEdgeOutcome extends SubjectErasureEdgeClassificat
      * - a NON-executing disposition (`RETAINED_BY_DECLARATION`, `NOT_OWNED`) ⇒ the erasure deliberately
      *   left the rows alone, and `false` is the expected, correct answer;
      * - an EXECUTING disposition (`DELETE`, `IMPERSONALIZE_AND_RETAIN`) ⇒ the cascade DECLINED the edge
-     *   (the child had no registered service or repository, or the depth budget was spent). The
-     *   subject's data is partly still live. This pairing should never appear in a healthy system; it is
-     *   logged at ERROR when it happens, with the missing registration named.
+     *   (the child had no registered service or repository), or an edge BELOW it did not tear its rows
+     *   down (see `descendantEdges`) — declined the same way, or a DELETE edge that reached rows an
+     *   earlier retain edge of the walk kept. An erasure never spends a depth budget — it walks every
+     *   descendant. The subject's data is partly still live. This pairing should never appear in a
+     *   healthy system; it is logged at ERROR when it happens, naming the missing registration or the
+     *   descendant edges concerned.
      *
      * ⚠️ This flag was set unconditionally until 2026-08-11 — it meant "the dispatcher returned without
      * throwing" and reported a skipped edge as torn down. Anything persisted before that date overstates
@@ -180,6 +418,12 @@ export declare enum SubjectErasureExternalEffectStatus {
      * looked and found nothing, this means nobody looked.
      */
     NOT_REGISTERED = "not-registered",
+    /**
+     * A bound external-effects port returned no usable report. The local erasure committed, but
+     * external outcomes are UNKNOWN: neither no work nor no change can be inferred. Incomplete;
+     * reconcile provider state before retrying work that may already have succeeded.
+     */
+    UNMEASURED = "unmeasured",
     /**
      * The external system's binding DECLARES its rows hold no personal/subject data
      * (`HttpApiErasureStance.NO_SUBJECT_DATA`, ETL D6 stance 6a) — nothing was erased because,
@@ -229,6 +473,12 @@ export interface SubjectErasureExternalEffectOutcome {
  * Returned to the caller (rather than only logged) so the flow that fronts the request can record
  * or surface it: every edge of the subject appears exactly once with the disposition applied and
  * the configuration that justified it, which is the evidence a data-protection response needs.
+ *
+ * assurance-control: WILDO.PRIVACY.ERASURE_PROPAGATION — an erasure accounts per store instead of
+ * one verdict: each direct dependent edge with whether its teardown ran, each descendant edge the
+ * erasure walked below it (nested in `descendantEdges`, folded into the direct edge's `executed`),
+ * each registered external effect with its own outcome. The engine returns this and persists none of
+ * it; retaining it is the calling application's job.
  */
 export interface SubjectErasureReport {
     /** The erased subject's resource type. */
@@ -243,21 +493,6 @@ export interface SubjectErasureReport {
      * returning a report.
      */
     subjectImpersonalized: boolean;
-    /**
-     * Outcomes of the external, non-transactional effects the erasure triggered — every SYSTEM WE
-     * DO NOT OWN that the subject's personal data reached: registered effect handlers (a billing
-     * provider), and each HTTP_API-bound resource linked to the subject (one entry per resource,
-     * `effectRef: 'http-api:<resourceType>'`, carrying its declared D6 erasure stance's outcome).
-     *
-     * Empty when no effect was registered for the subject's resource type. These run AFTER the local
-     * scrub has committed, so a failure here cannot roll the erasure back — the local data is
-     * already gone and re-running the whole erasure would be wrong. That asymmetry is precisely why
-     * the outcome is reported rather than thrown: the local part genuinely succeeded, and the caller
-     * needs to know that a third party still holds something.
-     *
-     * Check {@link isIncompleteSubjectErasureExternalEffect} over these before treating a report as a
-     * complete erasure.
-     */
     /**
      * Whose sessions this erasure ended, and whether resolving them failed.
      *
@@ -274,6 +509,104 @@ export interface SubjectErasureReport {
         principalUserIds: string[];
         lookupFailed: boolean;
     };
+    /**
+     * Outcomes of the external, non-transactional effects the erasure triggered — every SYSTEM WE
+     * DO NOT OWN that the subject's personal data reached: registered effect handlers (a billing
+     * provider), and each HTTP_API-bound resource linked to the subject (one entry per resource,
+     * `effectRef: 'http-api:<resourceType>'`, carrying its declared D6 erasure stance's outcome).
+     *
+     * A malformed response from a bound registry produces one aggregate UNMEASURED entry,
+     * identifying that boundary rather than inventing individual provider outcomes.
+     *
+     * Empty when no effect was registered for the subject's resource type. These run AFTER the local
+     * scrub has committed, so a failure here cannot roll the erasure back — the local data is
+     * already gone and re-running the whole erasure would be wrong. That asymmetry is precisely why
+     * the outcome is reported rather than thrown: the local part genuinely succeeded, and the caller
+     * needs to know that a third party still holds something.
+     *
+     * Check {@link isIncompleteSubjectErasureExternalEffect} over these before treating a report as a
+     * complete erasure.
+     */
     externalEffects: SubjectErasureExternalEffectOutcome[];
 }
+/**
+ * Edges whose DELETE would reach the SUBJECT'S OWN resource type (#1085).
+ *
+ * ## The hazard
+ *
+ * A subject erasure SCRUBS the subject row and keeps it — that is the erasure's contract with the data
+ * subject, and it is unconditional: `eraseSubjectInPlace` refuses outright when the subject resource
+ * declares no `retentionPolicy`. Since #976 the walk also descends below every dependent it deletes, so
+ * a DELETE closure that comes back round to the subject's own type would delete the very row the
+ * erasure promised to retain — and the receipt would still report it retained.
+ *
+ * That last part is why this refuses rather than skips. `SubjectErasureDescendantWalk`'s accounting is
+ * written so a receipt can never OVERSTATE an erasure; deleting the scrubbed subject would overstate in
+ * the one way nothing downstream can detect, because every edge reports exactly what it did.
+ *
+ * ## Why the sibling detector cannot do this
+ *
+ * {@link findSubjectErasureRetainDeleteConflicts} compares two EDGE dispositions. The subject's retention
+ * is not an edge — no relationship declares it — so the subject's type is passed in here rather than
+ * inferred. It is the whole reason this is a second function and not a case in the first.
+ *
+ * ## Measured 2026-09-17: the population is EMPTY, and that is the point
+ *
+ * In the engine's core graph `USERS` is never the CHILD of a composition. The one relationship naming it
+ * second — `ORGANIZATIONS → USERS` — is a `RelationshipNature.ASSOCIATION` through
+ * `ORGANIZATION_MEMBERS`, and an association carries no `onParentDelete` teardown, so no closure can
+ * reach it. A guard over an empty population costs nothing at runtime and is exactly the shape worth
+ * having: it cannot regress silently, and an application that later declares such an edge meets a
+ * refusal before any read or write instead of an erasure that quietly contradicts itself.
+ *
+ * Pure, so a boot-time guard can run it over the same plan the runtime refuses on.
+ *
+ * @param plannedEdges - every edge of ONE erasure, each carrying its classification.
+ * @param subjectResourceType - the resource being erased, whose row is retained.
+ * @returns the offending edges, in plan order. Empty is the healthy answer.
+ */
+/**
+ * Edges that DELETE a resource whose OWN `retentionPolicy` says an erasure keeps its rows (#1279).
+ *
+ * ## The contradiction
+ *
+ * A resource's `retentionPolicy` is the declaration whose entire subject is what an erasure does to
+ * its rows, and the config factory refuses it unless it is paired with a `dataSubjectPolicy` — so it
+ * is among the most deliberate statements an author makes. An edge that nevertheless AUTHORS
+ * `onParentDelete.strategy: DELETE` says the opposite about the same rows. Nothing in the
+ * configuration ranks the two, so an erasure must refuse rather than pick: deleting could destroy
+ * data a retention obligation required keeping, and retaining could strand personal data the erasure
+ * claimed to have removed. That is the same reasoning {@link findSubjectErasureRetainDeleteConflicts}
+ * gives for refusing rather than defaulting, applied one level down — there between two EDGES, here
+ * between an edge and the RESOURCE it points at.
+ *
+ * ## Why a DELETE disposition here is necessarily AUTHORED
+ *
+ * Since #1279 `classifySubjectErasureDisposition` applies the child's retention treatment whenever the
+ * edge is SILENT, so a `DELETE` disposition toward a retain-declaring child can only have come from an
+ * author writing `strategy: DELETE`. This filter therefore needs no second look at the declaration:
+ * the invariant is expressed once, in the classifier, and read here. Do NOT re-derive "was it
+ * authored?" from the relationship — that would be a second copy of the rule, free to drift.
+ *
+ * ## Measured population: ZERO, and that is the point
+ *
+ * Across `engine/`, `platform/` and `examples/` on 2026-09-17, 28 edges deleted a retain-declaring
+ * resource and **not one of them authored `DELETE`** — every one reached that outcome through the
+ * schema default this fix removed. So the shipped registry trips this detector nowhere, which is the
+ * shape worth having: it cannot regress silently, and an application that later authors the
+ * contradiction meets a refusal before any read or write rather than an erasure that quietly
+ * contradicts its own declarations.
+ *
+ * Pure, so a boot-time guard can run it over the same plan the runtime refuses on.
+ *
+ * @param plannedEdges - every edge of ONE erasure, each carrying its classification.
+ * @param resolveChildRetentionPolicy - a resource type's declared `retentionPolicy`, or `undefined`.
+ * @returns the offending edges, in plan order. Empty is the healthy answer.
+ */
+export declare function findSubjectErasureRetentionContradictedEdges<TEdge extends {
+    classification: SubjectErasureEdgeClassification;
+}>(plannedEdges: readonly TEdge[], resolveChildRetentionPolicy: (resourceType: ResourceType) => SubjectErasureChildRetentionDeclaration | undefined): TEdge[];
+export declare function findSubjectErasureSubjectTypeDeleteEdges<TEdge extends {
+    classification: SubjectErasureEdgeClassification;
+}>(plannedEdges: readonly TEdge[], subjectResourceType: string): TEdge[];
 //# sourceMappingURL=subject-erasure.shared.schemas.d.ts.map

package/dist/esm/compliance/privacy/subject-erasure.shared.schemas.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"subject-erasure.shared.schemas.d.ts","sourceRoot":"","sources":["../../../../src/compliance/privacy/subject-erasure.shared.schemas.ts"],"names":[],"mappings":"AAAA,OAAO,EAEL,KAAK,oBAAoB,EAC1B,MAAM,0CAA0C,CAAC;AAMlD,OAAO,KAAK,EAAE,YAAY,EAAE,MAAM,mDAAmD,CAAC;AAEtF;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AACH,oBAAY,yBAAyB;IACnC;;;;;OAKG;IACH,MAAM,WAAW;IAEjB;;;;OAIG;IACH,wBAAwB,6BAA6B;IAErD;;;;;;;;OAQG;IACH,uBAAuB,4BAA4B;IAEnD;;;;;OAKG;IACH,SAAS,cAAc;IAEvB;;;;;OAKG;IACH,YAAY,iBAAiB;IAE7B;;;;;OAKG;IACH,oBAAoB,yBAAyB;CAC9C;AAED,4EAA4E;AAC5E,MAAM,WAAW,gCAAgC;IAC/C,0DAA0D;IAC1D,iBAAiB,EAAE,YAAY,CAAC;IAChC,2DAA2D;IAC3D,WAAW,EAAE,yBAAyB,CAAC;IACvC;;;;OAIG;IACH,MAAM,EAAE,MAAM,CAAC;CAChB;AAQD;;;;;;GAMG;AACH,wBAAgB,mCAAmC,CACjD,WAAW,EAAE,yBAAyB,GACrC,OAAO,CAET;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA+BG;AACH,wBAAgB,iCAAiC,CAC/C,YAAY,EAAE,oBAAoB,GACjC,gCAAgC,CA0FlC;AAED,gGAAgG;AAChG,MAAM,WAAW,yBAA0B,SAAQ,gCAAgC;IACjF;;;;;;;;;;;;;;;;;;OAkBG;IACH,QAAQ,EAAE,OAAO,CAAC;CACnB;AAED;;;;;;;;;;GAUG;AACH,oBAAY,kCAAkC;IAC5C,sEAAsE;IACtE,SAAS,cAAc;IACvB;;;;OAIG;IACH,gBAAgB,qBAAqB;IACrC;;;;OAIG;IACH,OAAO,YAAY;IACnB,mGAAmG;IACnG,MAAM,WAAW;IACjB;;;OAGG;IACH,cAAc,mBAAmB;IAEjC;;;;;;;OAOG;IACH,wBAAwB,6BAA6B;IAErD;;;;;;;;;OASG;IACH,wBAAwB,6BAA6B;CACtD;AAED,gGAAgG;AAChG,wBAAgB,wCAAwC,CACtD,MAAM,EAAE,kCAAkC,GACzC,OAAO,CAOT;AAED,MAAM,WAAW,mCAAmC;IAClD,kEAAkE;IAClE,SAAS,EAAE,MAAM,CAAC;IAClB,MAAM,EAAE,kCAAkC,CAAC;IAC3C;;;OAGG;IACH,MAAM,EAAE,MAAM,CAAC;IACf;;;OAGG;IACH,KAAK,CAAC,EAAE,KAAK,CAAC;QAAE,IAAI,EAAE,MAAM,CAAC;QAAC,SAAS,CAAC,EAAE,MAAM,CAAC;QAAC,SAAS,EAAE,OAAO,CAAC;QAAC,KAAK,CAAC,EAAE,MAAM,CAAA;KAAE,CAAC,CAAC;CACzF;AAED;;;;;;GAMG;AACH,MAAM,WAAW,oBAAoB;IACnC,0CAA0C;IAC1C,mBAAmB,EAAE,YAAY,CAAC;IAClC,+BAA+B;IAC/B,UAAU,EAAE,MAAM,EAAE,CAAC;IACrB,gFAAgF;IAChF,KAAK,EAAE,yBAAyB,EAAE,CAAC;IACnC;;;;OAIG;IACH,qBAAqB,EAAE,OAAO,CAAC;IAC/B;;;;;;;;;;;;;;OAcG;IACH;;;;;;;;;;;OAWG;IACH,iBAAiB,CAAC,EAAE;QAClB,gBAAgB,EAAE,MAAM,EAAE,CAAC;QAC3B,YAAY,EAAE,OAAO,CAAC;KACvB,CAAC;IACF,eAAe,EAAE,mCAAmC,EAAE,CAAC;CACxD"}
+{"version":3,"file":"subject-erasure.shared.schemas.d.ts","sourceRoot":"","sources":["../../../../../src/compliance/privacy/subject-erasure.shared.schemas.ts"],"names":[],"mappings":"AAAA,OAAO,EAEL,KAAK,oBAAoB,EAC1B,MAAM,0CAA0C,CAAC;AAMlD,OAAO,KAAK,EAAE,YAAY,EAAE,MAAM,mDAAmD,CAAC;AACtF,OAAO,EAAE,oBAAoB,EAAE,MAAM,oCAAoC,CAAC;AAE1E;;;;;;;;;;;;;;;;;;;;;;;;GAwBG;AACH,oBAAY,yBAAyB;IACnC;;;;;OAKG;IACH,MAAM,WAAW;IAEjB;;;;OAIG;IACH,wBAAwB,6BAA6B;IAErD;;;;;;;;OAQG;IACH,uBAAuB,4BAA4B;IAEnD;;;;;;;;;;;;;;;OAeG;IACH,yBAAyB,8BAA8B;IAEvD;;;;;OAKG;IACH,SAAS,cAAc;IAEvB;;;;;OAKG;IACH,YAAY,iBAAiB;IAE7B;;;;;OAKG;IACH,oBAAoB,yBAAyB;CAC9C;AAED,4EAA4E;AAC5E,MAAM,WAAW,gCAAgC;IAC/C,0DAA0D;IAC1D,iBAAiB,EAAE,YAAY,CAAC;IAChC,2DAA2D;IAC3D,WAAW,EAAE,yBAAyB,CAAC;IACvC;;;;OAIG;IACH,MAAM,EAAE,MAAM,CAAC;CAChB;AAED;;;;;;;;;;GAUG;AACH,MAAM,WAAW,uCAAuC;IACtD,QAAQ,CAAC,IAAI,CAAC,EAAE,oBAAoB,CAAC;CACtC;AAQD;;;;;;GAMG;AACH,wBAAgB,mCAAmC,CACjD,WAAW,EAAE,yBAAyB,GACrC,OAAO,CAET;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA6DG;AACH,wBAAgB,iCAAiC,CAC/C,YAAY,EAAE,oBAAoB,EAClC,2BAA2B,EAAE,CAC3B,YAAY,EAAE,YAAY,KACvB,uCAAuC,GAAG,SAAS,GACvD,gCAAgC,CA4MlC;AAED;;;;;;;GAOG;AACH,MAAM,WAAW,gCAAgC;IAC/C,2EAA2E;IAC3E,YAAY,EAAE,oBAAoB,CAAC;IACnC,yFAAyF;IACzF,kBAAkB,EAAE,YAAY,CAAC;IACjC,cAAc,EAAE,gCAAgC,CAAC;CAClD;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAqCG;AACH,wBAAgB,iCAAiC,CAC/C,uBAAuB,EAAE,YAAY,EACrC,kCAAkC,EAAE,CAAC,YAAY,EAAE,YAAY,KAAK,oBAAoB,EAAE,GAAG,SAAS,EACtG,2BAA2B,EAAE,CAC3B,YAAY,EAAE,YAAY,KACvB,uCAAuC,GAAG,SAAS,GACvD,gCAAgC,EAAE,CAoBpC;AAED;;;;;GAKG;AACH,MAAM,WAAW,kCAAkC,CAAC,KAAK;IACvD,wDAAwD;IACxD,YAAY,EAAE,YAAY,CAAC;IAC3B,6FAA6F;IAC7F,cAAc,EAAE,KAAK,EAAE,CAAC;IACxB,mEAAmE;IACnE,aAAa,EAAE,KAAK,EAAE,CAAC;CACxB;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAuEG;AACH,wBAAgB,uCAAuC,CAAC,KAAK,SAAS;IAAE,cAAc,EAAE,gCAAgC,CAAA;CAAE,EACxH,YAAY,EAAE,SAAS,KAAK,EAAE,GAC7B,KAAK,CAAC,kCAAkC,CAAC,KAAK,CAAC,CAAC,CAclD;AAED;;;GAGG;AACH,MAAM,WAAW,mCAAoC,SAAQ,gCAAgC;IAC3F,wCAAwC;IACxC,kBAAkB,EAAE,YAAY,CAAC;IACjC;;;;;;;;;;OAUG;IACH,QAAQ,EAAE,OAAO,CAAC;CACnB;AAED,gGAAgG;AAChG,MAAM,WAAW,yBAA0B,SAAQ,gCAAgC;IACjF;;;;OAIG;IACH,eAAe,EAAE,mCAAmC,EAAE,CAAC;IACvD;;;;;;;;;;;;;;;;;;;;;;;;OAwBG;IACH,QAAQ,EAAE,OAAO,CAAC;CACnB;AAED;;;;;;;;;;GAUG;AACH,oBAAY,kCAAkC;IAC5C,sEAAsE;IACtE,SAAS,cAAc;IACvB;;;;OAIG;IACH,gBAAgB,qBAAqB;IACrC;;;;OAIG;IACH,OAAO,YAAY;IACnB,mGAAmG;IACnG,MAAM,WAAW;IACjB;;;OAGG;IACH,cAAc,mBAAmB;IAEjC;;;;OAIG;IACH,UAAU,eAAe;IAEzB;;;;;;;OAOG;IACH,wBAAwB,6BAA6B;IAErD;;;;;;;;;OASG;IACH,wBAAwB,6BAA6B;CACtD;AAED,gGAAgG;AAChG,wBAAgB,wCAAwC,CACtD,MAAM,EAAE,kCAAkC,GACzC,OAAO,CAQT;AAED,MAAM,WAAW,mCAAmC;IAClD,kEAAkE;IAClE,SAAS,EAAE,MAAM,CAAC;IAClB,MAAM,EAAE,kCAAkC,CAAC;IAC3C;;;OAGG;IACH,MAAM,EAAE,MAAM,CAAC;IACf;;;OAGG;IACH,KAAK,CAAC,EAAE,KAAK,CAAC;QAAE,IAAI,EAAE,MAAM,CAAC;QAAC,SAAS,CAAC,EAAE,MAAM,CAAC;QAAC,SAAS,EAAE,OAAO,CAAC;QAAC,KAAK,CAAC,EAAE,MAAM,CAAA;KAAE,CAAC,CAAC;CACzF;AAED;;;;;;;;;;;;GAYG;AACH,MAAM,WAAW,oBAAoB;IACnC,0CAA0C;IAC1C,mBAAmB,EAAE,YAAY,CAAC;IAClC,+BAA+B;IAC/B,UAAU,EAAE,MAAM,EAAE,CAAC;IACrB,gFAAgF;IAChF,KAAK,EAAE,yBAAyB,EAAE,CAAC;IACnC;;;;OAIG;IACH,qBAAqB,EAAE,OAAO,CAAC;IAC/B;;;;;;;;;;;OAWG;IACH,iBAAiB,CAAC,EAAE;QAClB,gBAAgB,EAAE,MAAM,EAAE,CAAC;QAC3B,YAAY,EAAE,OAAO,CAAC;KACvB,CAAC;IACF;;;;;;;;;;;;;;;;;OAiBG;IACH,eAAe,EAAE,mCAAmC,EAAE,CAAC;CACxD;AAGD;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAmCG;AACH;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAqCG;AACH,wBAAgB,4CAA4C,CAAC,KAAK,SAAS;IAAE,cAAc,EAAE,gCAAgC,CAAA;CAAE,EAC7H,YAAY,EAAE,SAAS,KAAK,EAAE,EAC9B,2BAA2B,EAAE,CAC3B,YAAY,EAAE,YAAY,KACvB,uCAAuC,GAAG,SAAS,GACvD,KAAK,EAAE,CAIT;AAED,wBAAgB,wCAAwC,CAAC,KAAK,SAAS;IAAE,cAAc,EAAE,gCAAgC,CAAA;CAAE,EACzH,YAAY,EAAE,SAAS,KAAK,EAAE,EAC9B,mBAAmB,EAAE,MAAM,GAC1B,KAAK,EAAE,CAIT"}