@wildo-ai/saas-models 1.1.4 → 1.1.5

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

@@ -1,6 +1,7 @@
 import { RelationshipLifecycleModel, } from '../../resources/resources.shared.schemas.js';
 import { Resources_SharedUtils } from '../../resources/resources.shared.utils.js';
 import { ChildLifecycleMode, ChildLifecycleStrategy, } from '../../resources/child-operations.shared.schemas.js';
+import { ErasureRetentionMode } from './impersonalization.shared.schemas.js';
 /**
  * What a SUBJECT ERASURE does to one child-direction edge of the subject.
  *
@@ -19,11 +20,12 @@ import { ChildLifecycleMode, ChildLifecycleStrategy, } from '../../resources/chi
  * 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 var SubjectErasureDisposition;
 (function (SubjectErasureDisposition) {
@@ -50,6 +52,23 @@ export var SubjectErasureDisposition;
      * rely on the erased subject row still resolving their foreign keys.
      */
     SubjectErasureDisposition["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.
+     */
+    SubjectErasureDisposition["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
@@ -102,24 +121,54 @@ export function isBlockingSubjectErasureDisposition(disposition) {
  *  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.
  *
- * 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.
+ * 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 |
+ *
+ * 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 function classifySubjectErasureDisposition(relationship) {
+export function classifySubjectErasureDisposition(relationship, resolveChildRetentionPolicy) {
     const childResourceType = relationship.resourceType2;
     const classify = (disposition, reason) => ({ childResourceType, disposition, reason });
     // A disabled relationship is not part of the live graph — the runtime never traverses it, so an
@@ -144,17 +193,119 @@ export function classifySubjectErasureDisposition(relationship) {
             `no retainable value) or IMPERSONALIZE_AND_RETAIN (they must survive scrubbed), or ` +
             `'enabled: false' to state explicitly that they survive intact`);
     }
+    /*
+     * ## DECIDED 2026-09-17 (#1084): this is NOT reconciled against a DELETE path, and that is correct
+     *
+     * The question was whether a resource reached BOTH by this disposition and by a DELETE edge should
+     * be refused the way #1017 refuses `IMPERSONALIZE_AND_RETAIN` against `DELETE`. It should not, and
+     * the reason is that the two cases are not alike.
+     *
+     * #1017 refuses because TWO EXECUTED TREATMENTS disagree about the same row: one scrubs it and keeps
+     * it, the other removes it, and nothing says which wins. `enabled: false` executes nothing. The
+     * erasure never traverses this edge and never discovers these rows, so there is no competing
+     * treatment to reconcile — only one edge that acts and one that says nothing. A row with two parents
+     * that survives one teardown and dies with the other is also exactly what an ordinary parent delete
+     * does, so refusing here would make an erasure stricter than the lifecycle it is built on.
+     *
+     * Refusing was the filed recommendation and is rejected for a further reason: the #1017 refusal's own
+     * remedy tells an operator to "disable one edge's teardown (onParentDelete.enabled: false)". Treating
+     * the result as a new conflict would make the documented remedy produce the next refusal.
+     *
+     * What this disposition means is therefore narrower than its name suggests, and worth saying plainly:
+     * it records that THIS EDGE does not cascade, not that the rows are guaranteed to survive the
+     * erasure. Another path may still delete them, and that path's declaration is the one that decides.
+     */
     if (onParentDelete.enabled !== true) {
         return classify(SubjectErasureDisposition.RETAINED_BY_DECLARATION, 'onParentDelete.enabled is false: the author declared these rows survive their parent\'s ' +
             'teardown, so the erasure leaves them intact');
     }
+    // The RESTRICT posture is read BEFORE the mode: it tears nothing down, so there is no teardown to
+    // defer, and a `mode: LAZY` written beside it must not turn a leave-alone edge into a blocking one.
+    // After this return TypeScript narrows `strategy` below to the teardown members, so the switch's
+    // exhaustiveness check still turns any FUTURE member into a type error.
+    if (onParentDelete.strategy === ChildLifecycleStrategy.REFUSE_WHILE_CHILDREN_EXIST) {
+        return classify(SubjectErasureDisposition.RESTRICTED_BY_DECLARATION, 'onParentDelete declares strategy REFUSE_WHILE_CHILDREN_EXIST: the parent\'s delete is refused ' +
+            'while these rows exist, and an erasure scrubs the subject in place rather than deleting it, so ' +
+            'the erasure leaves the rows intact');
+    }
     const mode = onParentDelete.mode ?? ChildLifecycleMode.IMMEDIATE;
     if (mode !== ChildLifecycleMode.IMMEDIATE) {
         return classify(SubjectErasureDisposition.UNSUPPORTED_DEFERRED, `onParentDelete.mode is '${mode}': deferring the teardown to a queue would let the erasure ` +
             `report success while the subject's personal data is still live. Set mode: IMMEDIATE on ` +
             `this edge for it to participate in a subject erasure`);
     }
-    const strategy = onParentDelete.strategy ?? ChildLifecycleStrategy.DELETE;
+    /*
+     * #1279 — the child's OWN erasure declaration is consulted BEFORE the edge's teardown strategy.
+     *
+     * ## Why this sits AFTER the deferral check, deliberately
+     *
+     * `mode: LAZY` is read above and refuses first, so a deferred edge never reaches the retention
+     * question. The alternative — letting a retain policy rescue a LAZY edge, the way the RESTRICT
+     * posture is read before `mode` — was considered and REJECTED: RESTRICT tears nothing down, so
+     * there is genuinely no teardown to defer, while `RETAIN_AND_IMPERSONALIZE` is an ACTION (the
+     * in-place scrub), and an erasure that defers its own scrub reports success while personal data is
+     * still live. Refusing is the fail-closed answer and the one an operator can act on.
+     *
+     * Measured 2026-09-17: the shipped registry declares ZERO `mode: LAZY` edges, so this ordering is
+     * currently unobservable. It is written down rather than left to be re-derived by whoever declares
+     * the first one.
+     *
+     * `strategy` is read RAW here, never through `resolveChildLifecycleTeardownStrategy`. That helper
+     * resolves absence to DELETE for the CASCADE, where the premise "the parent row is gone" makes it
+     * correct. An erasure keeps the parent row, so the premise is false and the resolution would be a
+     * manufactured answer — which is precisely the defect this replaces.
+     */
+    const authoredStrategy = onParentDelete.strategy;
+    const childRetentionPolicy = resolveChildRetentionPolicy(childResourceType);
+    if (childRetentionPolicy?.mode !== undefined) {
+        const retentionMode = childRetentionPolicy.mode;
+        const retainDisposition = retentionMode === ErasureRetentionMode.RETAIN_AND_IMPERSONALIZE
+            ? SubjectErasureDisposition.IMPERSONALIZE_AND_RETAIN
+            : SubjectErasureDisposition.RETAINED_BY_DECLARATION;
+        if (authoredStrategy === undefined) {
+            return classify(retainDisposition, `the child resource declares retentionPolicy.mode '${retentionMode}' — the declaration that ` +
+                `states what an erasure does to its rows — and this edge authors no onParentDelete.strategy, ` +
+                `so nothing contradicts it. The erasure applies the declared retention treatment rather than ` +
+                `the teardown the delete cascade would apply, because an erasure keeps the parent row`);
+        }
+        /*
+         * An AUTHORED strategy is left to the switch below, deliberately — including an authored DELETE,
+         * which CONTRADICTS this retention policy.
+         *
+         * Refusing it here as a per-edge disposition was implemented first and REVERTED, because a
+         * blocking disposition is refused by the orchestrator BEFORE the plan-level detectors run: it
+         * shadowed {@link findSubjectErasureRetainDeleteConflicts} (#1017) and
+         * {@link findSubjectErasureSubjectTypeDeleteEdges} (#1085), whose refusals name both offending
+         * edges and the resource, with a generic "no executable disposition" message. Two purpose-built,
+         * mutation-proven refusals became unreachable for their whole population — every shape they
+         * detect requires the child to declare a `retentionPolicy`, so every one of them is also this
+         * contradiction.
+         *
+         * A contradiction is a relation between TWO declarations, which is what a plan-level detector
+         * models and what a single edge's disposition cannot. It therefore lives beside its siblings, as
+         * {@link findSubjectErasureRetentionContradictedEdges}.
+         */
+    }
+    /*
+     * The residual, named rather than left to look like an inconsistency with everything above.
+     *
+     * A child that declares NO `retentionPolicy` and sits on a SILENT edge has had nothing said about it
+     * in either field, and here absence still resolves to DELETE — the reading the engine has always
+     * had, that a dependent's data has no life of its own once the subject's ownership does not. 33
+     * children are in that position (measured 2026-09-17), and the alternative was to refuse all 33 as
+     * UNCLASSIFIED until someone authored a declaration for each.
+     *
+     * That was rejected for the reason `application-creation-directive.md` gives: the remedy would be
+     * "an author decides something", which makes an erasure impossible to run until a large authoring
+     * backlog is cleared, and #1279 was about an erasure doing the WRONG thing, not about it being
+     * under-declared. The narrow fix is the one that keeps the correction checkable.
+     *
+     * What changed is precise and worth stating: silence no longer overrules a DECLARATION. It still
+     * carries the historical default where there is no declaration to overrule. If this project later
+     * wants that last case explicit too, the place for it is a per-edge `onSubjectErasure` axis, and
+     * the argument against adding one speculatively is in this function's header.
+     */
+    const strategy = authoredStrategy ?? ChildLifecycleStrategy.DELETE;
     switch (strategy) {
         case ChildLifecycleStrategy.DELETE:
             return classify(SubjectErasureDisposition.DELETE, 'onParentDelete declares strategy DELETE: the dependent\'s data dies with the subject\'s ' +
@@ -171,6 +322,152 @@ export function classifySubjectErasureDisposition(relationship) {
         }
     }
 }
+/**
+ * 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 function planSubjectErasureDescendantEdges(directChildResourceType, resolveChildDirectionRelationships, resolveChildRetentionPolicy) {
+    const planned = [];
+    const walked = new Set();
+    const pending = [directChildResourceType];
+    while (pending.length > 0) {
+        const parentResourceType = pending.shift();
+        if (walked.has(String(parentResourceType)))
+            continue;
+        walked.add(String(parentResourceType));
+        for (const relationship of resolveChildDirectionRelationships(parentResourceType) ?? []) {
+            const classification = classifySubjectErasureDisposition(relationship, resolveChildRetentionPolicy);
+            planned.push({ relationship, parentResourceType, classification });
+            if (classification.disposition === SubjectErasureDisposition.DELETE) {
+                pending.push(classification.childResourceType);
+            }
+        }
+    }
+    return planned;
+}
+/**
+ * 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 function findSubjectErasureRetainDeleteConflicts(plannedEdges) {
+    const byResourceType = new Map();
+    for (const edge of plannedEdges) {
+        const { disposition, childResourceType } = edge.classification;
+        if (disposition !== SubjectErasureDisposition.DELETE && disposition !== SubjectErasureDisposition.IMPERSONALIZE_AND_RETAIN) {
+            continue;
+        }
+        const key = String(childResourceType);
+        const entry = byResourceType.get(key) ?? { resourceType: childResourceType, retainingEdges: [], deletingEdges: [] };
+        byResourceType.set(key, entry);
+        if (disposition === SubjectErasureDisposition.DELETE)
+            entry.deletingEdges.push(edge);
+        else
+            entry.retainingEdges.push(edge);
+    }
+    return [...byResourceType.values()].filter((entry) => entry.retainingEdges.length > 0 && entry.deletingEdges.length > 0);
+}
 /**
  * Outcome of one EXTERNAL, non-transactional erasure effect (a third-party provider the subject's
  * personal data also reached — a billing provider customer, say).
@@ -205,6 +502,12 @@ export var SubjectErasureExternalEffectStatus;
      * looked and found nothing, this means nobody looked.
      */
     SubjectErasureExternalEffectStatus["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.
+     */
+    SubjectErasureExternalEffectStatus["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,
@@ -231,8 +534,91 @@ export function isIncompleteSubjectErasureExternalEffect(status) {
     return status === SubjectErasureExternalEffectStatus.PARTIAL
         || status === SubjectErasureExternalEffectStatus.FAILED
         || status === SubjectErasureExternalEffectStatus.NOT_REGISTERED
+        || status === SubjectErasureExternalEffectStatus.UNMEASURED
         // An acknowledged non-erasure is a DELIBERATE hole, and still a hole: personal data remains
         // live at the third party, so "is this erasure actually complete" must answer no.
         || status === SubjectErasureExternalEffectStatus.ACKNOWLEDGED_NON_ERASURE;
 }
+/**
+ * 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 function findSubjectErasureRetentionContradictedEdges(plannedEdges, resolveChildRetentionPolicy) {
+    return plannedEdges.filter((edge) => edge.classification.disposition === SubjectErasureDisposition.DELETE
+        && resolveChildRetentionPolicy(edge.classification.childResourceType)?.mode !== undefined);
+}
+export function findSubjectErasureSubjectTypeDeleteEdges(plannedEdges, subjectResourceType) {
+    return plannedEdges.filter((edge) => edge.classification.disposition === SubjectErasureDisposition.DELETE
+        && String(edge.classification.childResourceType) === String(subjectResourceType));
+}
 //# sourceMappingURL=subject-erasure.shared.schemas.js.map