@wildo-ai/saas-models 1.1.4 → 1.1.6

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,KAAK,wBAAwB,EAAE,MAAM,oCAAoC,CAAC;AACzG,OAAO,KAAK,EACV,4BAA4B,EAC5B,kBAAkB,EAClB,wBAAwB,EACxB,mBAAmB,EACpB,MAAM,qCAAqC,CAAC;AAE7C,OAAO,KAAK,EAAE,gCAAgC,EAAE,MAAM,8BAA8B,CAAC;AACrF,OAAO,KAAK,EAAE,8BAA8B,EAAE,8BAA8B,EAAE,MAAM,0CAA0C,CAAC;AAE/H;;;;;;;;;;;;;;;;;;;;;;;;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;;;;;;;;;;;;;;;;;;;;OAoBG;IACH,oCAAoC,yCAAyC;IAE7E;;;;;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;IACrC;;;;OAIG;IACH,QAAQ,CAAC,kBAAkB,CAAC,EAAE;QAAE,QAAQ,CAAC,MAAM,EAAE,wBAAwB,CAAA;KAAE,CAAC;CAC7E;AAuBD;;;;GAIG;AACH,wBAAgB,oCAAoC,CAClD,WAAW,EAAE,yBAAyB,GACrC,OAAO,CAET;AAWD;;;;;;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,CAqOlC;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;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAsCG;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;;;OAGG;IACH,cAAc,EAAE,KAAK,EAAE,CAAC;IACxB,mEAAmE;IACnE,aAAa,EAAE,KAAK,EAAE,CAAC;CACxB;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAwEG;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;;;;;OAKG;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;IACvD;;;;;;;;;OASG;IACH,iCAAiC,EAAE,kCAAkC,EAAE,CAAC;IACxE;;;;;;;;;OASG;IACH,wBAAwB,EAAE,sCAAsC,EAAE,CAAC;IACnE;;;;;;OAMG;IACH,eAAe,EAAE,gCAAgC,EAAE,CAAC;IACpD;;;;;;;;;OASG;IACH,UAAU,EAAE;QACV,SAAS,EAAE,8BAA8B,CAAC;QAC1C,QAAQ,EAAE,8BAA8B,EAAE,CAAC;KAC5C,CAAC;CACH;AAED,gGAAgG;AAChG,MAAM,WAAW,kCAAkC;IACjD,YAAY,EAAE,YAAY,CAAC;IAC3B,KAAK,EAAE,MAAM,CAAC;IACd,2DAA2D;IAC3D,MAAM,EAAE,wBAAwB,CAAC;IACjC,6GAA6G;IAC7G,cAAc,EAAE,kBAAkB,CAAC;IACnC,sGAAsG;IACtG,mBAAmB,EAAE,mBAAmB,CAAC;IACzC;;;;;;OAMG;IACH,aAAa,EAAE,IAAI,GAAG,IAAI,CAAC;CAC5B;AAED,yFAAyF;AACzF,MAAM,WAAW,sCAAsC;IACrD,YAAY,EAAE,YAAY,CAAC;IAC3B,KAAK,EAAE,MAAM,CAAC;IACd,yEAAyE;IACzE,gBAAgB,EAAE,IAAI,CAAC;CACxB;AAED;;;;;;;;;;;;GAYG;AACH,wBAAgB,+BAA+B,CAAC,KAAK,EAAE;IACrD,YAAY,EAAE,YAAY,CAAC;IAC3B,IAAI,EAAE,SAAS,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,EAAE,CAAC;IACzC,OAAO,EAAE,wBAAwB,CAAC;IAClC,MAAM,EAAE,wBAAwB,CAAC;IACjC,QAAQ,EAAE,4BAA4B,GAAG,SAAS,CAAC;IACnD,GAAG,EAAE,IAAI,CAAC;CACX,GAAG;IAAE,UAAU,EAAE,kCAAkC,EAAE,CAAC;IAAC,QAAQ,EAAE,sCAAsC,EAAE,CAAA;CAAE,CAsB3G;AAGD;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;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;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAmCG;AACH,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"}

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

@@ -1,6 +1,8 @@
 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';
+import { resolveRetentionExpiresAt } from './retention-binding.shared.utils.js';
 /**
  * What a SUBJECT ERASURE does to one child-direction edge of the subject.
  *
@@ -19,11 +21,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 +53,45 @@ 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";
+    /**
+     * KEEP THE ROWS, RESTRICTED, UNTIL THE LAW LETS THEM GO (#1635) — the child resource declares
+     * `retentionPolicy.statutoryRetention`: its rows are business records a statute requires kept, bound to
+     * `DataRetentionClass.BUSINESS_RECORDS`.
+     *
+     * GDPR Art. 17(3)(b) exempts them from erasure while the statutory period runs, and the erasure applies
+     * the Art. 18(2) restriction instead: each row takes the resource's declared `retentionPolicy.mode`
+     * treatment (scrubbed where the mode says so) and is flipped to `RETAINED`, which the retention
+     * row-hide chokepoints exclude from every ordinary read and write. The rows are LISTED in
+     * `SubjectErasureReport.restrictedUnderStatutoryRetention` with their ground and the instant their period
+     * ends, and the retention-class sweep deletes them then. Every other edge of the request is erased as
+     * usual — a statutory row never refuses the erasure.
+     *
+     * An EXECUTING disposition, like {@link IMPERSONALIZE_AND_RETAIN}, whose treatment it shares. Kept apart
+     * from it, and from {@link RETAINED_BY_DECLARATION}, because the CLAIM differs: those say the author chose
+     * to keep the rows; this says the law requires it, names the ground, and has an end. A reviewer asking
+     * "why is this row still here, and until when?" needs that difference in the receipt, not inferred.
+     *
+     * Like the other retain dispositions, the erasure does not walk below these rows: a kept row still
+     * anchors its own dependents.
+     */
+    SubjectErasureDisposition["RESTRICTED_UNDER_STATUTORY_RETENTION"] = "restricted_under_statutory_retention";
     /**
      * 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
@@ -77,6 +119,36 @@ const BLOCKING_DISPOSITIONS = new Set([
     SubjectErasureDisposition.UNCLASSIFIED,
     SubjectErasureDisposition.UNSUPPORTED_DEFERRED,
 ]);
+/**
+ * Dispositions whose edge the erasure DISPATCHES a teardown for — the ones whose `executed: false` means the
+ * subject's data is partly still live, rather than that the rows were deliberately left alone (#1635).
+ *
+ * THE one list. It was re-derived by hand at four sites (the descendant walk's accounting, the executor's
+ * decline log, the HTTP_API erasure-coherence check in the resources registry, and Wonder Todos'
+ * COMPLETED/FAILED predicate), which is exactly how a new executing member would have been read as
+ * "left alone" by the one site nobody updated.
+ */
+const EXECUTING_DISPOSITIONS = new Set([
+    SubjectErasureDisposition.DELETE,
+    SubjectErasureDisposition.IMPERSONALIZE_AND_RETAIN,
+    SubjectErasureDisposition.RESTRICTED_UNDER_STATUTORY_RETENTION,
+]);
+/**
+ * True when the erasure runs a teardown for an edge of this disposition, so `executed: false` on it is a
+ * DECLINE — personal data possibly still live — and never an expected leave-alone. Read an edge's
+ * `executed` through this, never through a hand-written list of members.
+ */
+export function isExecutingSubjectErasureDisposition(disposition) {
+    return EXECUTING_DISPOSITIONS.has(disposition);
+}
+/**
+ * Dispositions that KEEP the rows they reach while running a treatment on them — the retaining side of
+ * {@link findSubjectErasureRetainDeleteConflicts}.
+ */
+function isRetainingExecutedDisposition(disposition) {
+    return disposition === SubjectErasureDisposition.IMPERSONALIZE_AND_RETAIN
+        || disposition === SubjectErasureDisposition.RESTRICTED_UNDER_STATUTORY_RETENTION;
+}
 /**
  * True when a disposition must stop the erasure before any write lands.
  *
@@ -102,24 +174,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 +246,137 @@ 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;
+        /*
+         * #1635 — a STATUTORY ground outranks the author's own retain choice, and agrees with an authored
+         * IMPERSONALIZE_AND_RETAIN: both keep the rows; the ground adds WHY and UNTIL WHEN. The treatment the
+         * executor runs is the same retain-and-scrub core, and under `RETAIN_ONLY` it scrubs nothing and still
+         * flips the row to RETAINED — which RETAINED_BY_DECLARATION would not do: that disposition leaves rows
+         * exactly as they are, VISIBLE, and a statutory row must be restricted, not merely left.
+         *
+         * An authored DELETE is NOT absorbed here: it falls through to the switch and is refused by
+         * `findSubjectErasureRetentionContradictedEdges`, for the reason on that function — two declarations
+         * disagree about the same rows and nothing ranks them.
+         */
+        if (childRetentionPolicy.statutoryRetention !== undefined
+            && (authoredStrategy === undefined || authoredStrategy === ChildLifecycleStrategy.IMPERSONALIZE_AND_RETAIN)) {
+            return classify(SubjectErasureDisposition.RESTRICTED_UNDER_STATUTORY_RETENTION, `the child resource declares retentionPolicy.statutoryRetention (ground '${childRetentionPolicy.statutoryRetention.ground}'): ` +
+                `its rows are business records a statute requires kept, so the erasure keeps each row inside its ` +
+                `statutory period RESTRICTED (retained, hidden from ordinary processing) and lists it with the ` +
+                `instant its period ends; the retention-class sweep deletes it then`);
+        }
+        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 +393,154 @@ 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` or `RESTRICTED_UNDER_STATUTORY_RETENTION` edge — nothing.**
+ *   The retained row survives, scrubbed where its mode says so, 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 a retaining treatment the erasure EXECUTES — `IMPERSONALIZE_AND_RETAIN`, and
+ * `RESTRICTED_UNDER_STATUTORY_RETENTION` (#1635), which keeps its rows by the same treatment. 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 && !isRetainingExecutedDisposition(disposition)) {
+            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 +575,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 +607,128 @@ 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;
 }
+/**
+ * Split the rows a statutory edge reached into those still under the statute and those already released
+ * (#1635). Pure: the executor passes the discovered rows, the resource's binding and ground, the schedule it
+ * read, and the erasure instant.
+ *
+ * The rule, and its one boundary: a row is released only when `retainedUntil < now` — exactly the rows the
+ * retention-class sweep's strict `start < now − days` (`resolveBoundRetentionCutoff`) selects, because
+ * `start + days < now` is the same inequality. A row whose period ends AT this instant is still under the
+ * statute and the sweep keeps it, so it is listed as restricted. Everything else is restricted too,
+ * including a row whose instant is unknown (`null`): an unknown end is never an ended one.
+ *
+ * A row without an id is skipped rather than listed: an entry the operator cannot find is not evidence.
+ */
+export function partitionStatutoryRetentionRows(input) {
+    const restricted = [];
+    const released = [];
+    for (const row of input.rows) {
+        const rawId = row._id ?? row.id;
+        const rowId = rawId === undefined || rawId === null ? undefined : String(rawId);
+        if (!rowId)
+            continue;
+        const expiresAt = resolveRetentionExpiresAt(row, input.binding, input.schedule);
+        if (expiresAt !== undefined && expiresAt.getTime() < input.now.getTime()) {
+            released.push({ resourceType: input.resourceType, rowId, retentionEndedAt: expiresAt });
+            continue;
+        }
+        restricted.push({
+            resourceType: input.resourceType,
+            rowId,
+            ground: input.ground,
+            retentionClass: input.binding.retentionClass,
+            retentionStartPoint: input.binding.startPoint,
+            retainedUntil: expiresAt ?? null,
+        });
+    }
+    return { restricted, released };
+}
+/**
+ * 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);
+}
+/**
+ * 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.
+ */
+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