@wildo-ai/saas-models 1.1.3 → 1.1.5

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

@@ -1 +1 @@
-{"version":3,"file":"subject-erasure.shared.schemas.js","sourceRoot":"","sources":["../../../../../src/compliance/privacy/subject-erasure.shared.schemas.ts"],"names":[],"mappings":"AAAA,OAAO,EACL,0BAA0B,GAE3B,MAAM,0CAA0C,CAAC;AAClD,OAAO,EAAE,qBAAqB,EAAE,MAAM,wCAAwC,CAAC;AAC/E,OAAO,EACL,kBAAkB,EAClB,sBAAsB,GACvB,MAAM,iDAAiD,CAAC;AAGzD;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AACH,MAAM,CAAN,IAAY,yBAkDX;AAlDD,WAAY,yBAAyB;IACnC;;;;;OAKG;IACH,8CAAiB,CAAA;IAEjB;;;;OAIG;IACH,kFAAqD,CAAA;IAErD;;;;;;;;OAQG;IACH,gFAAmD,CAAA;IAEnD;;;;;OAKG;IACH,oDAAuB,CAAA;IAEvB;;;;;OAKG;IACH,0DAA6B,CAAA;IAE7B;;;;;OAKG;IACH,0EAA6C,CAAA;AAC/C,CAAC,EAlDW,yBAAyB,KAAzB,yBAAyB,QAkDpC;AAgBD,oEAAoE;AACpE,MAAM,qBAAqB,GAA2C,IAAI,GAAG,CAAC;IAC5E,yBAAyB,CAAC,YAAY;IACtC,yBAAyB,CAAC,oBAAoB;CAC/C,CAAC,CAAC;AAEH;;;;;;GAMG;AACH,MAAM,UAAU,mCAAmC,CACjD,WAAsC;IAEtC,OAAO,qBAAqB,CAAC,GAAG,CAAC,WAAW,CAAC,CAAC;AAChD,CAAC;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA+BG;AACH,MAAM,UAAU,iCAAiC,CAC/C,YAAkC;IAElC,MAAM,iBAAiB,GAAG,YAAY,CAAC,aAA6B,CAAC;IACrE,MAAM,QAAQ,GAAG,CACf,WAAsC,EACtC,MAAc,EACoB,EAAE,CAAC,CAAC,EAAE,iBAAiB,EAAE,WAAW,EAAE,MAAM,EAAE,CAAC,CAAC;IAEpF,gGAAgG;IAChG,+FAA+F;IAC/F,uDAAuD;IACvD,IAAI,YAAY,CAAC,UAAU,KAAK,IAAI,EAAE,CAAC;QACrC,OAAO,QAAQ,CACb,yBAAyB,CAAC,SAAS,EACnC,sFAAsF,CACvF,CAAC;IACJ,CAAC;IAED,MAAM,SAAS,GAAG,qBAAqB,CAAC,oCAAoC,CAAC,YAAY,CAAC,CAAC;IAC3F,MAAM,cAAc,GAAG,SAAS,CAAC,QAAQ,CAAC,kBAAkB,CAAC;IAE7D,IAAI,cAAc,KAAK,0BAA0B,CAAC,SAAS,EAAE,CAAC;QAC5D,OAAO,QAAQ,CACb,yBAAyB,CAAC,SAAS,EACnC,0BAA0B,cAAc,2CAA2C;YACjF,mFAAmF,CACtF,CAAC;IACJ,CAAC;IAED,gGAAgG;IAChG,oBAAoB;IACpB,MAAM,cAAc,GAAG,qBAAqB,CAAC,gDAAgD,CAC3F,YAAY,CACb,CAAC;IAEF,IAAI,CAAC,cAAc,EAAE,CAAC;QACpB,OAAO,QAAQ,CACb,yBAAyB,CAAC,YAAY,EACtC,2FAA2F;YACzF,oFAAoF;YACpF,0FAA0F;YAC1F,oFAAoF;YACpF,+DAA+D,CAClE,CAAC;IACJ,CAAC;IAED,IAAI,cAAc,CAAC,OAAO,KAAK,IAAI,EAAE,CAAC;QACpC,OAAO,QAAQ,CACb,yBAAyB,CAAC,uBAAuB,EACjD,0FAA0F;YACxF,6CAA6C,CAChD,CAAC;IACJ,CAAC;IAED,MAAM,IAAI,GAAG,cAAc,CAAC,IAAI,IAAI,kBAAkB,CAAC,SAAS,CAAC;IACjE,IAAI,IAAI,KAAK,kBAAkB,CAAC,SAAS,EAAE,CAAC;QAC1C,OAAO,QAAQ,CACb,yBAAyB,CAAC,oBAAoB,EAC9C,2BAA2B,IAAI,6DAA6D;YAC1F,yFAAyF;YACzF,sDAAsD,CACzD,CAAC;IACJ,CAAC;IAED,MAAM,QAAQ,GAAG,cAAc,CAAC,QAAQ,IAAI,sBAAsB,CAAC,MAAM,CAAC;IAC1E,QAAQ,QAAQ,EAAE,CAAC;QACjB,KAAK,sBAAsB,CAAC,MAAM;YAChC,OAAO,QAAQ,CACb,yBAAyB,CAAC,MAAM,EAChC,0FAA0F;gBACxF,4CAA4C,CAC/C,CAAC;QAEJ,KAAK,sBAAsB,CAAC,wBAAwB;YAClD,OAAO,QAAQ,CACb,yBAAyB,CAAC,wBAAwB,EAClD,0FAA0F;gBACxF,6EAA6E,CAChF,CAAC;QAEJ,OAAO,CAAC,CAAC,CAAC;YACR,6FAA6F;YAC7F,mFAAmF;YACnF,MAAM,wBAAwB,GAAU,QAAQ,CAAC;YACjD,OAAO,QAAQ,CACb,yBAAyB,CAAC,YAAY,EACtC,uDAAuD;gBACrD,IAAI,MAAM,CAAC,wBAAwB,CAAC,uCAAuC,CAC9E,CAAC;QACJ,CAAC;IACH,CAAC;AACH,CAAC;AA0BD;;;;;;;;;;GAUG;AACH,MAAM,CAAN,IAAY,kCA4CX;AA5CD,WAAY,kCAAkC;IAC5C,sEAAsE;IACtE,6DAAuB,CAAA;IACvB;;;;OAIG;IACH,2EAAqC,CAAA;IACrC;;;;OAIG;IACH,yDAAmB,CAAA;IACnB,mGAAmG;IACnG,uDAAiB,CAAA;IACjB;;;OAGG;IACH,uEAAiC,CAAA;IAEjC;;;;;;;OAOG;IACH,2FAAqD,CAAA;IAErD;;;;;;;;;OASG;IACH,2FAAqD,CAAA;AACvD,CAAC,EA5CW,kCAAkC,KAAlC,kCAAkC,QA4C7C;AAED,gGAAgG;AAChG,MAAM,UAAU,wCAAwC,CACtD,MAA0C;IAE1C,OAAO,MAAM,KAAK,kCAAkC,CAAC,OAAO;WACvD,MAAM,KAAK,kCAAkC,CAAC,MAAM;WACpD,MAAM,KAAK,kCAAkC,CAAC,cAAc;QAC/D,4FAA4F;QAC5F,kFAAkF;WAC/E,MAAM,KAAK,kCAAkC,CAAC,wBAAwB,CAAC;AAC9E,CAAC","sourcesContent":["import {\n  RelationshipLifecycleModel,\n  type ResourceRelationship,\n} from '../../resources/resources.shared.schemas';\nimport { Resources_SharedUtils } from '../../resources/resources.shared.utils';\nimport {\n  ChildLifecycleMode,\n  ChildLifecycleStrategy,\n} from '../../resources/child-operations.shared.schemas';\nimport type { ResourceType } from '../../resources/resources.shared.core.definitions';\n\n/**\n * What a SUBJECT ERASURE does to one child-direction edge of the subject.\n *\n * ## Why this vocabulary exists at all\n *\n * \"Erase this subject\" (a `delete my account` request) is not \"delete this row\". The subject row\n * SURVIVES — scrubbed and marked `RETAINED` — so that foreign keys from legally-retained financial\n * rows keep resolving to an anonymized person. But the subject's OWN dependents must each be\n * disposed of, and the disposition differs per edge: a profile holding a name and an avatar has to\n * go, an invoice has to stay, an audit log was never the subject's to begin with.\n *\n * This enum is the closed set of answers, and it is deliberately WIDER than the two teardown\n * strategies of {@link ChildLifecycleStrategy}: the delete cascade only ever asks about edges that\n * opted IN (`onParentDelete.enabled === true`) and silently ignores the rest, whereas an erasure\n * must account for EVERY edge — including the ones nobody opted in — because an edge nobody thought\n * about is exactly where personal data survives an erasure unnoticed.\n *\n * Two members therefore have no runtime action and exist to make the erasure FAIL LOUD\n * ({@link UNCLASSIFIED}, {@link UNSUPPORTED_DEFERRED}), and two describe leaving a row alone for\n * two genuinely different reasons ({@link RETAINED_BY_DECLARATION} vs {@link NOT_OWNED}). Those two\n * are not merged despite sharing a no-op: a data-protection reviewer asking \"why is this row still\n * here?\" needs \"because the author declared it retained\" and \"because it was never the subject's\n * row\" to be different answers, and only the first one is a compliance claim someone made.\n */\nexport enum SubjectErasureDisposition {\n  /**\n   * Hard-delete the child rows. The author declared this dependent's data dies with the parent's\n   * ownership (`onParentDelete.enabled`, `strategy: DELETE`) — on an erasure the ownership ends in\n   * the only way that matters for personal data, so the rows go. This is the `USER_PROFILES` case:\n   * there is no legal obligation to retain a name, a bio or an avatar.\n   */\n  DELETE = 'delete',\n\n  /**\n   * Scrub the child rows' personal fields in place and KEEP them, flipping `retentionStatus` to\n   * `RETAINED` (`onParentDelete.strategy = IMPERSONALIZE_AND_RETAIN`). For a dependent that must\n   * survive for a legal/audit obligation while holding personal data of its own.\n   */\n  IMPERSONALIZE_AND_RETAIN = 'impersonalize_and_retain',\n\n  /**\n   * LEAVE THE ROWS EXACTLY AS THEY ARE — a dependent whose cascade the author explicitly DISABLED\n   * (`onParentDelete.enabled: false`). That declaration says \"this row survives its parent's\n   * teardown\", which is a positive compliance claim, not an omission.\n   *\n   * This is how the retained billing rows are expressed: subscriptions, invoice refs, usage records\n   * and credit pools each disable the cascade, keep their financial audit trail fully VISIBLE, and\n   * rely on the erased subject row still resolving their foreign keys.\n   */\n  RETAINED_BY_DECLARATION = 'retained_by_declaration',\n\n  /**\n   * LEAVE THE ROWS ALONE — the edge is not an ownership edge at all\n   * (`lifecycleModelMode` is `INDEPENDENT` or `LINK_ONLY`, or the relationship is disabled). The\n   * related rows live independently of the subject, so their disposition is not the subject's\n   * erasure to decide (audit logs, job executions, membership links).\n   */\n  NOT_OWNED = 'not_owned',\n\n  /**\n   * ⛔ NO ANSWER — a DEPENDENT child with NO `onParentDelete` declaration whatsoever. The author\n   * owns this dependent's lifecycle but never said what happens to it, and an erasure must not\n   * guess: deleting could destroy data a retention obligation required keeping, and leaving could\n   * strand personal data that the erasure claimed to have removed. The orchestrator throws.\n   */\n  UNCLASSIFIED = 'unclassified',\n\n  /**\n   * ⛔ DECLARED BUT NOT EXECUTABLE AS PART OF AN ERASURE — the edge opted in with\n   * `mode: LAZY` (queue the teardown for later). Deferring is a legitimate performance choice for a\n   * parent delete, but it would let an erasure report success while the subject's personal data is\n   * still live in a queue nobody is watching. The orchestrator throws.\n   */\n  UNSUPPORTED_DEFERRED = 'unsupported_deferred',\n}\n\n/** The classification of ONE child-direction edge of an erasure subject. */\nexport interface SubjectErasureEdgeClassification {\n  /** The dependent resource on the far side of the edge. */\n  childResourceType: ResourceType;\n  /** What the erasure will do with that dependent's rows. */\n  disposition: SubjectErasureDisposition;\n  /**\n   * Human-readable justification, quoting the configuration that produced it. Surfaced in the\n   * erasure report and in the fail-loud error, so an operator never has to re-derive WHY a row was\n   * deleted, retained, or refused.\n   */\n  reason: string;\n}\n\n/** Dispositions that ABORT the erasure rather than executing it. */\nconst BLOCKING_DISPOSITIONS: ReadonlySet<SubjectErasureDisposition> = new Set([\n  SubjectErasureDisposition.UNCLASSIFIED,\n  SubjectErasureDisposition.UNSUPPORTED_DEFERRED,\n]);\n\n/**\n * True when a disposition must stop the erasure before any write lands.\n *\n * Exported (rather than inlined at the one call site) so a future boot-time guard — the erasure\n * analogue of `validateCompositionCascadeDeletability` — reports exactly the edges the runtime\n * would refuse, instead of re-deriving the rule and drifting from it.\n */\nexport function isBlockingSubjectErasureDisposition(\n  disposition: SubjectErasureDisposition,\n): boolean {\n  return BLOCKING_DISPOSITIONS.has(disposition);\n}\n\n/**\n * Classify what a subject erasure must do with ONE child-direction edge — the delete-vs-retain\n * decision, DERIVED FROM CONFIGURATION rather than from a hardcoded list of resource types.\n *\n * ## Where the answer comes from\n *\n * Two declarations the author already makes, read through the SAME shared authority the runtime\n * delete cascade reads (`resolveRelationshipLifecycleOnParentDeleteConfig`), so the erasure and the\n * cascade can never disagree about what an edge says:\n *\n *  1. **`handling.lifecycleModelMode`** — does the subject own this dependent's lifecycle at all?\n *     `INDEPENDENT` / `LINK_ONLY` answers \"no\", and the erasure leaves those rows alone.\n *  2. **`childOperations.lifecycle.onParentDelete`** — for an owned dependent, what did the author\n *     declare happens when the parent stops owning it: hard-delete, scrub-and-retain, or nothing.\n *\n * ## The semantic caveat, stated plainly\n *\n * `onParentDelete` literally answers \"what happens when the parent row is DELETED\", and an erasure\n * does NOT delete the subject — it scrubs and keeps it. v1 deliberately treats the two questions as\n * one because they have the same answer for every edge in the shipped registry, and because an\n * author who declared \"this dependent dies with its parent\" has already said the thing that\n * matters: the dependent's data has no life of its own once the subject's does not.\n *\n * They are NOT the same question though, and the day a resource needs to answer them differently\n * (retain a dependent on erasure that it hard-deletes on parent-delete, or the reverse) the\n * expressible extension is a sibling `onSubjectErasure` axis on the same edge, defaulting to this\n * derivation. Adding that axis speculatively now would give app authors a second knob with no\n * consumer and two ways to say the same thing.\n *\n * Pure and side-effect free — no registry lookups, no I/O — so it is equally usable from a runtime\n * orchestrator and from a boot-time guard.\n */\nexport function classifySubjectErasureDisposition(\n  relationship: ResourceRelationship,\n): SubjectErasureEdgeClassification {\n  const childResourceType = relationship.resourceType2 as ResourceType;\n  const classify = (\n    disposition: SubjectErasureDisposition,\n    reason: string,\n  ): SubjectErasureEdgeClassification => ({ childResourceType, disposition, reason });\n\n  // A disabled relationship is not part of the live graph — the runtime never traverses it, so an\n  // erasure must not refuse to run because of it (the alternative would be a permanently blocked\n  // erasure on a resource carrying a switched-off edge).\n  if (relationship.isDisabled === true) {\n    return classify(\n      SubjectErasureDisposition.NOT_OWNED,\n      'the relationship is disabled (isDisabled: true), so it is not part of the live graph',\n    );\n  }\n\n  const semantics = Resources_SharedUtils.requireResolvedRelationshipSemantics(relationship);\n  const lifecycleModel = semantics.handling.lifecycleModelMode;\n\n  if (lifecycleModel !== RelationshipLifecycleModel.DEPENDENT) {\n    return classify(\n      SubjectErasureDisposition.NOT_OWNED,\n      `lifecycleModelMode is '${lifecycleModel}' (not DEPENDENT): the related rows live ` +\n        `independently of the subject, so their disposition is not this erasure's decision`,\n    );\n  }\n\n  // DEPENDENT from here on: the subject owns this dependent's lifecycle, so the erasure MUST have\n  // an answer for it.\n  const onParentDelete = Resources_SharedUtils.resolveRelationshipLifecycleOnParentDeleteConfig(\n    relationship,\n  );\n\n  if (!onParentDelete) {\n    return classify(\n      SubjectErasureDisposition.UNCLASSIFIED,\n      `the subject owns this dependent (lifecycleModelMode: DEPENDENT) but the edge declares no ` +\n        `onParentDelete lifecycle, so nobody has said whether its rows survive an erasure. ` +\n        `Declare onParentDelete on the edge: 'enabled: true' with strategy DELETE (the rows hold ` +\n        `no retainable value) or IMPERSONALIZE_AND_RETAIN (they must survive scrubbed), or ` +\n        `'enabled: false' to state explicitly that they survive intact`,\n    );\n  }\n\n  if (onParentDelete.enabled !== true) {\n    return classify(\n      SubjectErasureDisposition.RETAINED_BY_DECLARATION,\n      'onParentDelete.enabled is false: the author declared these rows survive their parent\\'s ' +\n        'teardown, so the erasure leaves them intact',\n    );\n  }\n\n  const mode = onParentDelete.mode ?? ChildLifecycleMode.IMMEDIATE;\n  if (mode !== ChildLifecycleMode.IMMEDIATE) {\n    return classify(\n      SubjectErasureDisposition.UNSUPPORTED_DEFERRED,\n      `onParentDelete.mode is '${mode}': deferring the teardown to a queue would let the erasure ` +\n        `report success while the subject's personal data is still live. Set mode: IMMEDIATE on ` +\n        `this edge for it to participate in a subject erasure`,\n    );\n  }\n\n  const strategy = onParentDelete.strategy ?? ChildLifecycleStrategy.DELETE;\n  switch (strategy) {\n    case ChildLifecycleStrategy.DELETE:\n      return classify(\n        SubjectErasureDisposition.DELETE,\n        'onParentDelete declares strategy DELETE: the dependent\\'s data dies with the subject\\'s ' +\n          'ownership, so the erasure removes the rows',\n      );\n\n    case ChildLifecycleStrategy.IMPERSONALIZE_AND_RETAIN:\n      return classify(\n        SubjectErasureDisposition.IMPERSONALIZE_AND_RETAIN,\n        'onParentDelete declares strategy IMPERSONALIZE_AND_RETAIN: the rows survive the erasure ' +\n          'with their personal fields scrubbed and retentionStatus flipped to RETAINED',\n      );\n\n    default: {\n      // Compile-time exhaustiveness: a new ChildLifecycleStrategy member without an erasure arm is\n      // a TYPE error here, not a silent runtime discovery on someone's deletion request.\n      const _exhaustiveStrategyCheck: never = strategy;\n      return classify(\n        SubjectErasureDisposition.UNCLASSIFIED,\n        `onParentDelete declares an unknown teardown strategy ` +\n          `'${String(_exhaustiveStrategyCheck)}' that subject erasure has no arm for`,\n      );\n    }\n  }\n}\n\n/** Per-edge outcome of an executed erasure — the classification plus what actually happened. */\nexport interface SubjectErasureEdgeOutcome extends SubjectErasureEdgeClassification {\n  /**\n   * `true` when the erasure ran a teardown for this edge.\n   *\n   * Reports that the teardown RAN, not that rows existed — discovery finding no dependents is a\n   * teardown that ran with nothing to do, and is `true`.\n   *\n   * **Read it together with `disposition`, because `false` has two very different meanings:**\n   *\n   * - a NON-executing disposition (`RETAINED_BY_DECLARATION`, `NOT_OWNED`) ⇒ the erasure deliberately\n   *   left the rows alone, and `false` is the expected, correct answer;\n   * - an EXECUTING disposition (`DELETE`, `IMPERSONALIZE_AND_RETAIN`) ⇒ the cascade DECLINED the edge\n   *   (the child had no registered service or repository, or the depth budget was spent). The\n   *   subject's data is partly still live. This pairing should never appear in a healthy system; it is\n   *   logged at ERROR when it happens, with the missing registration named.\n   *\n   * ⚠️ This flag was set unconditionally until 2026-08-11 — it meant \"the dispatcher returned without\n   * throwing\" and reported a skipped edge as torn down. Anything persisted before that date overstates\n   * what was erased. Treat this field as evidence only for reports produced after the fix.\n   */\n  executed: boolean;\n}\n\n/**\n * Outcome of one EXTERNAL, non-transactional erasure effect (a third-party provider the subject's\n * personal data also reached — a billing provider customer, say).\n *\n * A separate vocabulary from {@link SubjectErasureDisposition} on purpose. An edge disposition\n * describes a decision derived from configuration BEFORE anything ran, and its teardown is part of\n * the database transaction. An external effect is the opposite on both counts: it is discovered by\n * calling out to a system Wildo does not own, and it CANNOT join the transaction. Collapsing the\n * two would let a caller read \"the erasure succeeded\" from a value that only ever described the\n * local rows.\n */\nexport enum SubjectErasureExternalEffectStatus {\n  /** Every step of the effect completed against the external system. */\n  COMPLETED = 'completed',\n  /**\n   * The subject had nothing at this external system — no provider customer, no linked record. A\n   * legitimate success, kept DISTINCT from `COMPLETED` so \"there was nothing to erase\" can never be\n   * mistaken for \"we erased it\", which is exactly the confusion a regulator would probe.\n   */\n  NOTHING_TO_ERASE = 'nothing-to-erase',\n  /**\n   * The effect ran and some steps succeeded while others failed — personal data may still be live\n   * at the external system. The loudest state in this enum: it demands follow-up, and it is why the\n   * status is not a boolean.\n   */\n  PARTIAL = 'partial',\n  /** The effect could not run at all (provider unreachable, not configured). Nothing was changed. */\n  FAILED = 'failed',\n  /**\n   * No handler was registered for this effect. Distinct from `NOTHING_TO_ERASE`: that means we\n   * looked and found nothing, this means nobody looked.\n   */\n  NOT_REGISTERED = 'not-registered',\n\n  /**\n   * The external system's binding DECLARES its rows hold no personal/subject data\n   * (`HttpApiErasureStance.NO_SUBJECT_DATA`, ETL D6 stance 6a) — nothing was erased because,\n   * by declaration, there is nothing an erasure could apply to. Distinct from\n   * {@link NOTHING_TO_ERASE}: that means we LOOKED and found no linked rows; this means the\n   * declaration made looking unnecessary. A complete outcome — the declaration's coherence is\n   * validated at boot (a 6a resource cannot participate in subject export).\n   */\n  DECLARED_NO_SUBJECT_DATA = 'declared-no-subject-data',\n\n  /**\n   * The rows live in an external system the platform cannot erase, and the CONTROLLER explicitly\n   * acknowledged completing the erasure anyway (`HttpApiErasureStance.\n   * CONTROLLER_ACKNOWLEDGED_NON_ERASURE`, ETL D6 stance 6c — the per-request\n   * `acknowledgeHttpApiNonErasure` option). Deliberately INCOMPLETE in\n   * {@link isIncompleteSubjectErasureExternalEffect}: the subject's data is still live at the\n   * third party, and a compliance artifact must say so however deliberate the decision was. The\n   * acknowledgement itself is additionally recorded as a CRITICAL audit event — the record is\n   * the control (`administrative-continuity-floors.md`).\n   */\n  ACKNOWLEDGED_NON_ERASURE = 'acknowledged-non-erasure',\n}\n\n/** Whether an external-effect status leaves personal data potentially live at a third party. */\nexport function isIncompleteSubjectErasureExternalEffect(\n  status: SubjectErasureExternalEffectStatus,\n): boolean {\n  return status === SubjectErasureExternalEffectStatus.PARTIAL\n    || status === SubjectErasureExternalEffectStatus.FAILED\n    || status === SubjectErasureExternalEffectStatus.NOT_REGISTERED\n    // An acknowledged non-erasure is a DELIBERATE hole, and still a hole: personal data remains\n    // live at the third party, so \"is this erasure actually complete\" must answer no.\n    || status === SubjectErasureExternalEffectStatus.ACKNOWLEDGED_NON_ERASURE;\n}\n\nexport interface SubjectErasureExternalEffectOutcome {\n  /** Stable identifier of the effect, e.g. `'billing-provider'`. */\n  effectRef: string;\n  status: SubjectErasureExternalEffectStatus;\n  /**\n   * Human-readable account of what ran, for the compliance artifact. On `PARTIAL` / `FAILED` this\n   * must name what did NOT happen — the report is the only place that survives the request.\n   */\n  detail: string;\n  /**\n   * Per-step results, so a partial outcome is actionable rather than merely alarming (which step\n   * against which external id). Never carries personal data — ids and step names only.\n   */\n  steps?: Array<{ step: string; targetRef?: string; succeeded: boolean; error?: string }>;\n}\n\n/**\n * What one subject erasure did — the compliance artifact of a \"delete my account\" request.\n *\n * Returned to the caller (rather than only logged) so the flow that fronts the request can record\n * or surface it: every edge of the subject appears exactly once with the disposition applied and\n * the configuration that justified it, which is the evidence a data-protection response needs.\n */\nexport interface SubjectErasureReport {\n  /** The erased subject's resource type. */\n  subjectResourceType: ResourceType;\n  /** The erased subject rows. */\n  subjectIds: string[];\n  /** Every child-direction edge of the subject, classified, in registry order. */\n  edges: SubjectErasureEdgeOutcome[];\n  /**\n   * `true` once the subject rows themselves were scrubbed and flipped to `RETAINED`. Always `true`\n   * on a successful erasure — an erasure that could not retain its subject throws rather than\n   * returning a report.\n   */\n  subjectImpersonalized: boolean;\n  /**\n   * Outcomes of the external, non-transactional effects the erasure triggered — every SYSTEM WE\n   * DO NOT OWN that the subject's personal data reached: registered effect handlers (a billing\n   * provider), and each HTTP_API-bound resource linked to the subject (one entry per resource,\n   * `effectRef: 'http-api:<resourceType>'`, carrying its declared D6 erasure stance's outcome).\n   *\n   * Empty when no effect was registered for the subject's resource type. These run AFTER the local\n   * scrub has committed, so a failure here cannot roll the erasure back — the local data is\n   * already gone and re-running the whole erasure would be wrong. That asymmetry is precisely why\n   * the outcome is reported rather than thrown: the local part genuinely succeeded, and the caller\n   * needs to know that a third party still holds something.\n   *\n   * Check {@link isIncompleteSubjectErasureExternalEffect} over these before treating a report as a\n   * complete erasure.\n   */\n  /**\n   * Whose sessions this erasure ended, and whether resolving them failed.\n   *\n   * A LOCAL fact, not an external effect: the revocation is a write to our own session fence, applied\n   * at the scrub chokepoint so it covers every path that scrubs a person's row. It is recorded here\n   * because \"the erased person can no longer be logged in\" is exactly what a data-protection response\n   * has to be able to evidence.\n   *\n   * `lookupFailed` is kept distinct from an empty `principalUserIds`: no principals is a legitimate\n   * outcome (the resource declared `NO_PRINCIPAL`), whereas a failed lookup means the person may\n   * still hold a live session — and the two must never look alike in a compliance artifact.\n   */\n  sessionRevocation?: {\n    principalUserIds: string[];\n    lookupFailed: boolean;\n  };\n  externalEffects: SubjectErasureExternalEffectOutcome[];\n}\n"]}
+{"version":3,"file":"subject-erasure.shared.schemas.js","sourceRoot":"","sources":["../../../../../src/compliance/privacy/subject-erasure.shared.schemas.ts"],"names":[],"mappings":"AAAA,OAAO,EACL,0BAA0B,GAE3B,MAAM,0CAA0C,CAAC;AAClD,OAAO,EAAE,qBAAqB,EAAE,MAAM,wCAAwC,CAAC;AAC/E,OAAO,EACL,kBAAkB,EAClB,sBAAsB,GACvB,MAAM,iDAAiD,CAAC;AAEzD,OAAO,EAAE,oBAAoB,EAAE,MAAM,oCAAoC,CAAC;AAE1E;;;;;;;;;;;;;;;;;;;;;;;;GAwBG;AACH,MAAM,CAAN,IAAY,yBAoEX;AApED,WAAY,yBAAyB;IACnC;;;;;OAKG;IACH,8CAAiB,CAAA;IAEjB;;;;OAIG;IACH,kFAAqD,CAAA;IAErD;;;;;;;;OAQG;IACH,gFAAmD,CAAA;IAEnD;;;;;;;;;;;;;;;OAeG;IACH,oFAAuD,CAAA;IAEvD;;;;;OAKG;IACH,oDAAuB,CAAA;IAEvB;;;;;OAKG;IACH,0DAA6B,CAAA;IAE7B;;;;;OAKG;IACH,0EAA6C,CAAA;AAC/C,CAAC,EApEW,yBAAyB,KAAzB,yBAAyB,QAoEpC;AA+BD,oEAAoE;AACpE,MAAM,qBAAqB,GAA2C,IAAI,GAAG,CAAC;IAC5E,yBAAyB,CAAC,YAAY;IACtC,yBAAyB,CAAC,oBAAoB;CAC/C,CAAC,CAAC;AAEH;;;;;;GAMG;AACH,MAAM,UAAU,mCAAmC,CACjD,WAAsC;IAEtC,OAAO,qBAAqB,CAAC,GAAG,CAAC,WAAW,CAAC,CAAC;AAChD,CAAC;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA6DG;AACH,MAAM,UAAU,iCAAiC,CAC/C,YAAkC,EAClC,2BAEwD;IAExD,MAAM,iBAAiB,GAAG,YAAY,CAAC,aAA6B,CAAC;IACrE,MAAM,QAAQ,GAAG,CACf,WAAsC,EACtC,MAAc,EACoB,EAAE,CAAC,CAAC,EAAE,iBAAiB,EAAE,WAAW,EAAE,MAAM,EAAE,CAAC,CAAC;IAEpF,gGAAgG;IAChG,+FAA+F;IAC/F,uDAAuD;IACvD,IAAI,YAAY,CAAC,UAAU,KAAK,IAAI,EAAE,CAAC;QACrC,OAAO,QAAQ,CACb,yBAAyB,CAAC,SAAS,EACnC,sFAAsF,CACvF,CAAC;IACJ,CAAC;IAED,MAAM,SAAS,GAAG,qBAAqB,CAAC,oCAAoC,CAAC,YAAY,CAAC,CAAC;IAC3F,MAAM,cAAc,GAAG,SAAS,CAAC,QAAQ,CAAC,kBAAkB,CAAC;IAE7D,IAAI,cAAc,KAAK,0BAA0B,CAAC,SAAS,EAAE,CAAC;QAC5D,OAAO,QAAQ,CACb,yBAAyB,CAAC,SAAS,EACnC,0BAA0B,cAAc,2CAA2C;YACjF,mFAAmF,CACtF,CAAC;IACJ,CAAC;IAED,gGAAgG;IAChG,oBAAoB;IACpB,MAAM,cAAc,GAAG,qBAAqB,CAAC,gDAAgD,CAC3F,YAAY,CACb,CAAC;IAEF,IAAI,CAAC,cAAc,EAAE,CAAC;QACpB,OAAO,QAAQ,CACb,yBAAyB,CAAC,YAAY,EACtC,2FAA2F;YACzF,oFAAoF;YACpF,0FAA0F;YAC1F,oFAAoF;YACpF,+DAA+D,CAClE,CAAC;IACJ,CAAC;IAED;;;;;;;;;;;;;;;;;;;;;OAqBG;IACH,IAAI,cAAc,CAAC,OAAO,KAAK,IAAI,EAAE,CAAC;QACpC,OAAO,QAAQ,CACb,yBAAyB,CAAC,uBAAuB,EACjD,0FAA0F;YACxF,6CAA6C,CAChD,CAAC;IACJ,CAAC;IAED,kGAAkG;IAClG,oGAAoG;IACpG,iGAAiG;IACjG,wEAAwE;IACxE,IAAI,cAAc,CAAC,QAAQ,KAAK,sBAAsB,CAAC,2BAA2B,EAAE,CAAC;QACnF,OAAO,QAAQ,CACb,yBAAyB,CAAC,yBAAyB,EACnD,gGAAgG;YAC9F,iGAAiG;YACjG,oCAAoC,CACvC,CAAC;IACJ,CAAC;IAED,MAAM,IAAI,GAAG,cAAc,CAAC,IAAI,IAAI,kBAAkB,CAAC,SAAS,CAAC;IACjE,IAAI,IAAI,KAAK,kBAAkB,CAAC,SAAS,EAAE,CAAC;QAC1C,OAAO,QAAQ,CACb,yBAAyB,CAAC,oBAAoB,EAC9C,2BAA2B,IAAI,6DAA6D;YAC1F,yFAAyF;YACzF,sDAAsD,CACzD,CAAC;IACJ,CAAC;IAED;;;;;;;;;;;;;;;;;;;;OAoBG;IACH,MAAM,gBAAgB,GAAG,cAAc,CAAC,QAAQ,CAAC;IACjD,MAAM,oBAAoB,GAAG,2BAA2B,CAAC,iBAAiB,CAAC,CAAC;IAE5E,IAAI,oBAAoB,EAAE,IAAI,KAAK,SAAS,EAAE,CAAC;QAC7C,MAAM,aAAa,GAAG,oBAAoB,CAAC,IAAI,CAAC;QAChD,MAAM,iBAAiB,GACrB,aAAa,KAAK,oBAAoB,CAAC,wBAAwB;YAC7D,CAAC,CAAC,yBAAyB,CAAC,wBAAwB;YACpD,CAAC,CAAC,yBAAyB,CAAC,uBAAuB,CAAC;QAExD,IAAI,gBAAgB,KAAK,SAAS,EAAE,CAAC;YACnC,OAAO,QAAQ,CACb,iBAAiB,EACjB,qDAAqD,aAAa,2BAA2B;gBAC3F,8FAA8F;gBAC9F,8FAA8F;gBAC9F,sFAAsF,CACzF,CAAC;QACJ,CAAC;QAED;;;;;;;;;;;;;;;;WAgBG;IACL,CAAC;IAED;;;;;;;;;;;;;;;;;;OAkBG;IACH,MAAM,QAAQ,GAAG,gBAAgB,IAAI,sBAAsB,CAAC,MAAM,CAAC;IACnE,QAAQ,QAAQ,EAAE,CAAC;QACjB,KAAK,sBAAsB,CAAC,MAAM;YAChC,OAAO,QAAQ,CACb,yBAAyB,CAAC,MAAM,EAChC,0FAA0F;gBACxF,4CAA4C,CAC/C,CAAC;QAEJ,KAAK,sBAAsB,CAAC,wBAAwB;YAClD,OAAO,QAAQ,CACb,yBAAyB,CAAC,wBAAwB,EAClD,0FAA0F;gBACxF,6EAA6E,CAChF,CAAC;QAEJ,OAAO,CAAC,CAAC,CAAC;YACR,6FAA6F;YAC7F,mFAAmF;YACnF,MAAM,wBAAwB,GAAU,QAAQ,CAAC;YACjD,OAAO,QAAQ,CACb,yBAAyB,CAAC,YAAY,EACtC,uDAAuD;gBACrD,IAAI,MAAM,CAAC,wBAAwB,CAAC,uCAAuC,CAC9E,CAAC;QACJ,CAAC;IACH,CAAC;AACH,CAAC;AAkBD;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAqCG;AACH,MAAM,UAAU,iCAAiC,CAC/C,uBAAqC,EACrC,kCAAsG,EACtG,2BAEwD;IAExD,MAAM,OAAO,GAAuC,EAAE,CAAC;IACvD,MAAM,MAAM,GAAG,IAAI,GAAG,EAAU,CAAC;IACjC,MAAM,OAAO,GAAmB,CAAC,uBAAuB,CAAC,CAAC;IAE1D,OAAO,OAAO,CAAC,MAAM,GAAG,CAAC,EAAE,CAAC;QAC1B,MAAM,kBAAkB,GAAG,OAAO,CAAC,KAAK,EAAG,CAAC;QAC5C,IAAI,MAAM,CAAC,GAAG,CAAC,MAAM,CAAC,kBAAkB,CAAC,CAAC;YAAE,SAAS;QACrD,MAAM,CAAC,GAAG,CAAC,MAAM,CAAC,kBAAkB,CAAC,CAAC,CAAC;QAEvC,KAAK,MAAM,YAAY,IAAI,kCAAkC,CAAC,kBAAkB,CAAC,IAAI,EAAE,EAAE,CAAC;YACxF,MAAM,cAAc,GAAG,iCAAiC,CAAC,YAAY,EAAE,2BAA2B,CAAC,CAAC;YACpG,OAAO,CAAC,IAAI,CAAC,EAAE,YAAY,EAAE,kBAAkB,EAAE,cAAc,EAAE,CAAC,CAAC;YACnE,IAAI,cAAc,CAAC,WAAW,KAAK,yBAAyB,CAAC,MAAM,EAAE,CAAC;gBACpE,OAAO,CAAC,IAAI,CAAC,cAAc,CAAC,iBAAiB,CAAC,CAAC;YACjD,CAAC;QACH,CAAC;IACH,CAAC;IAED,OAAO,OAAO,CAAC;AACjB,CAAC;AAiBD;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAuEG;AACH,MAAM,UAAU,uCAAuC,CACrD,YAA8B;IAE9B,MAAM,cAAc,GAAG,IAAI,GAAG,EAAqD,CAAC;IACpF,KAAK,MAAM,IAAI,IAAI,YAAY,EAAE,CAAC;QAChC,MAAM,EAAE,WAAW,EAAE,iBAAiB,EAAE,GAAG,IAAI,CAAC,cAAc,CAAC;QAC/D,IAAI,WAAW,KAAK,yBAAyB,CAAC,MAAM,IAAI,WAAW,KAAK,yBAAyB,CAAC,wBAAwB,EAAE,CAAC;YAC3H,SAAS;QACX,CAAC;QACD,MAAM,GAAG,GAAG,MAAM,CAAC,iBAAiB,CAAC,CAAC;QACtC,MAAM,KAAK,GAAG,cAAc,CAAC,GAAG,CAAC,GAAG,CAAC,IAAI,EAAE,YAAY,EAAE,iBAAiB,EAAE,cAAc,EAAE,EAAE,EAAE,aAAa,EAAE,EAAE,EAAE,CAAC;QACpH,cAAc,CAAC,GAAG,CAAC,GAAG,EAAE,KAAK,CAAC,CAAC;QAC/B,IAAI,WAAW,KAAK,yBAAyB,CAAC,MAAM;YAAE,KAAK,CAAC,aAAa,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;;YAChF,KAAK,CAAC,cAAc,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;IACvC,CAAC;IACD,OAAO,CAAC,GAAG,cAAc,CAAC,MAAM,EAAE,CAAC,CAAC,MAAM,CAAC,CAAC,KAAK,EAAE,EAAE,CAAC,KAAK,CAAC,cAAc,CAAC,MAAM,GAAG,CAAC,IAAI,KAAK,CAAC,aAAa,CAAC,MAAM,GAAG,CAAC,CAAC,CAAC;AAC3H,CAAC;AA2DD;;;;;;;;;;GAUG;AACH,MAAM,CAAN,IAAY,kCAmDX;AAnDD,WAAY,kCAAkC;IAC5C,sEAAsE;IACtE,6DAAuB,CAAA;IACvB;;;;OAIG;IACH,2EAAqC,CAAA;IACrC;;;;OAIG;IACH,yDAAmB,CAAA;IACnB,mGAAmG;IACnG,uDAAiB,CAAA;IACjB;;;OAGG;IACH,uEAAiC,CAAA;IAEjC;;;;OAIG;IACH,+DAAyB,CAAA;IAEzB;;;;;;;OAOG;IACH,2FAAqD,CAAA;IAErD;;;;;;;;;OASG;IACH,2FAAqD,CAAA;AACvD,CAAC,EAnDW,kCAAkC,KAAlC,kCAAkC,QAmD7C;AAED,gGAAgG;AAChG,MAAM,UAAU,wCAAwC,CACtD,MAA0C;IAE1C,OAAO,MAAM,KAAK,kCAAkC,CAAC,OAAO;WACvD,MAAM,KAAK,kCAAkC,CAAC,MAAM;WACpD,MAAM,KAAK,kCAAkC,CAAC,cAAc;WAC5D,MAAM,KAAK,kCAAkC,CAAC,UAAU;QAC3D,4FAA4F;QAC5F,kFAAkF;WAC/E,MAAM,KAAK,kCAAkC,CAAC,wBAAwB,CAAC;AAC9E,CAAC;AAkFD;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAmCG;AACH;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAqCG;AACH,MAAM,UAAU,4CAA4C,CAC1D,YAA8B,EAC9B,2BAEwD;IAExD,OAAO,YAAY,CAAC,MAAM,CAAC,CAAC,IAAI,EAAE,EAAE,CAClC,IAAI,CAAC,cAAc,CAAC,WAAW,KAAK,yBAAyB,CAAC,MAAM;WACjE,2BAA2B,CAAC,IAAI,CAAC,cAAc,CAAC,iBAAiB,CAAC,EAAE,IAAI,KAAK,SAAS,CAAC,CAAC;AAC/F,CAAC;AAED,MAAM,UAAU,wCAAwC,CACtD,YAA8B,EAC9B,mBAA2B;IAE3B,OAAO,YAAY,CAAC,MAAM,CAAC,CAAC,IAAI,EAAE,EAAE,CAClC,IAAI,CAAC,cAAc,CAAC,WAAW,KAAK,yBAAyB,CAAC,MAAM;WACjE,MAAM,CAAC,IAAI,CAAC,cAAc,CAAC,iBAAiB,CAAC,KAAK,MAAM,CAAC,mBAAmB,CAAC,CAAC,CAAC;AACtF,CAAC","sourcesContent":["import {\n  RelationshipLifecycleModel,\n  type ResourceRelationship,\n} from '../../resources/resources.shared.schemas';\nimport { Resources_SharedUtils } from '../../resources/resources.shared.utils';\nimport {\n  ChildLifecycleMode,\n  ChildLifecycleStrategy,\n} from '../../resources/child-operations.shared.schemas';\nimport type { ResourceType } from '../../resources/resources.shared.core.definitions';\nimport { ErasureRetentionMode } from './impersonalization.shared.schemas';\n\n/**\n * What a SUBJECT ERASURE does to one child-direction edge of the subject.\n *\n * ## Why this vocabulary exists at all\n *\n * \"Erase this subject\" (a `delete my account` request) is not \"delete this row\". The subject row\n * SURVIVES — scrubbed and marked `RETAINED` — so that foreign keys from legally-retained financial\n * rows keep resolving to an anonymized person. But the subject's OWN dependents must each be\n * disposed of, and the disposition differs per edge: a profile holding a name and an avatar has to\n * go, an invoice has to stay, an audit log was never the subject's to begin with.\n *\n * This enum is the closed set of answers, and it is deliberately WIDER than the two teardown\n * strategies of {@link ChildLifecycleStrategy}: the delete cascade only ever asks about edges that\n * opted IN (`onParentDelete.enabled === true`) and silently ignores the rest, whereas an erasure\n * must account for EVERY edge — including the ones nobody opted in — because an edge nobody thought\n * about is exactly where personal data survives an erasure unnoticed.\n *\n * Two members therefore have no runtime action and exist to make the erasure FAIL LOUD\n * ({@link UNCLASSIFIED}, {@link UNSUPPORTED_DEFERRED}), and three describe leaving a row alone for\n * three genuinely different reasons ({@link RETAINED_BY_DECLARATION}, {@link RESTRICTED_BY_DECLARATION},\n * {@link NOT_OWNED}). They are not merged despite sharing a no-op: a data-protection reviewer asking\n * \"why is this row still here?\" needs \"because the author declared it retained\", \"because its parent\n * may not be deleted while it exists\" and \"because it was never the subject's row\" to be different\n * answers, and only the first one is a retention claim someone made.\n */\nexport enum SubjectErasureDisposition {\n  /**\n   * Hard-delete the child rows. The author declared this dependent's data dies with the parent's\n   * ownership (`onParentDelete.enabled`, `strategy: DELETE`) — on an erasure the ownership ends in\n   * the only way that matters for personal data, so the rows go. This is the `USER_PROFILES` case:\n   * there is no legal obligation to retain a name, a bio or an avatar.\n   */\n  DELETE = 'delete',\n\n  /**\n   * Scrub the child rows' personal fields in place and KEEP them, flipping `retentionStatus` to\n   * `RETAINED` (`onParentDelete.strategy = IMPERSONALIZE_AND_RETAIN`). For a dependent that must\n   * survive for a legal/audit obligation while holding personal data of its own.\n   */\n  IMPERSONALIZE_AND_RETAIN = 'impersonalize_and_retain',\n\n  /**\n   * LEAVE THE ROWS EXACTLY AS THEY ARE — a dependent whose cascade the author explicitly DISABLED\n   * (`onParentDelete.enabled: false`). That declaration says \"this row survives its parent's\n   * teardown\", which is a positive compliance claim, not an omission.\n   *\n   * This is how the retained billing rows are expressed: subscriptions, invoice refs, usage records\n   * and credit pools each disable the cascade, keep their financial audit trail fully VISIBLE, and\n   * rely on the erased subject row still resolving their foreign keys.\n   */\n  RETAINED_BY_DECLARATION = 'retained_by_declaration',\n\n  /**\n   * LEAVE THE ROWS EXACTLY AS THEY ARE — a dependent whose edge declares the RESTRICT posture\n   * (`onParentDelete.strategy: REFUSE_WHILE_CHILDREN_EXIST`): the parent's delete is refused while\n   * these rows exist, and nothing about the parent's teardown removes them.\n   *\n   * An erasure scrubs its subject in place and never deletes it, so at the direct level the refusal is\n   * never met and the rows keep resolving their foreign key, as a retained row does. Below a dependent\n   * the erasure DELETES, the same edge holding rows refuses the erasure, as a delete cascade frame does,\n   * because deleting that parent would strand them. Kept apart from\n   * {@link RETAINED_BY_DECLARATION} because the claim differs: that one says \"these rows must outlive\n   * their parent\", this one says \"their parent may not go while they exist\". The second is about\n   * referential integrity (an org-unit subtree, the provider-customer mapping a billing account holds\n   * for its financial records), not a retention obligation.\n   *\n   * Like the other leave-alone dispositions, the erasure does not walk below these rows.\n   */\n  RESTRICTED_BY_DECLARATION = 'restricted_by_declaration',\n\n  /**\n   * LEAVE THE ROWS ALONE — the edge is not an ownership edge at all\n   * (`lifecycleModelMode` is `INDEPENDENT` or `LINK_ONLY`, or the relationship is disabled). The\n   * related rows live independently of the subject, so their disposition is not the subject's\n   * erasure to decide (audit logs, job executions, membership links).\n   */\n  NOT_OWNED = 'not_owned',\n\n  /**\n   * ⛔ NO ANSWER — a DEPENDENT child with NO `onParentDelete` declaration whatsoever. The author\n   * owns this dependent's lifecycle but never said what happens to it, and an erasure must not\n   * guess: deleting could destroy data a retention obligation required keeping, and leaving could\n   * strand personal data that the erasure claimed to have removed. The orchestrator throws.\n   */\n  UNCLASSIFIED = 'unclassified',\n\n  /**\n   * ⛔ DECLARED BUT NOT EXECUTABLE AS PART OF AN ERASURE — the edge opted in with\n   * `mode: LAZY` (queue the teardown for later). Deferring is a legitimate performance choice for a\n   * parent delete, but it would let an erasure report success while the subject's personal data is\n   * still live in a queue nobody is watching. The orchestrator throws.\n   */\n  UNSUPPORTED_DEFERRED = 'unsupported_deferred',\n}\n\n/** The classification of ONE child-direction edge of an erasure subject. */\nexport interface SubjectErasureEdgeClassification {\n  /** The dependent resource on the far side of the edge. */\n  childResourceType: ResourceType;\n  /** What the erasure will do with that dependent's rows. */\n  disposition: SubjectErasureDisposition;\n  /**\n   * Human-readable justification, quoting the configuration that produced it. Surfaced in the\n   * erasure report and in the fail-loud error, so an operator never has to re-derive WHY a row was\n   * deleted, retained, or refused.\n   */\n  reason: string;\n}\n\n/**\n * The only part of a child's `retentionPolicy` an erasure classification reads (#1279).\n *\n * Structural and minimal on purpose: the classifier needs the erasure TREATMENT and nothing else, and\n * narrowing the parameter to this keeps every caller — the runtime orchestrator, the registry sweep and\n * the boot-time guards, which each hold a differently-shaped configuration record — able to answer\n * without first building a full `ResourceRetentionPolicy` it does not otherwise need.\n *\n * `mode` is optional because a caller may legitimately hold a resource entry with no retention opt-in;\n * that is the same answer as passing `undefined` and means \"this child declares no erasure treatment\".\n */\nexport interface SubjectErasureChildRetentionDeclaration {\n  readonly mode?: ErasureRetentionMode;\n}\n\n/** Dispositions that ABORT the erasure rather than executing it. */\nconst BLOCKING_DISPOSITIONS: ReadonlySet<SubjectErasureDisposition> = new Set([\n  SubjectErasureDisposition.UNCLASSIFIED,\n  SubjectErasureDisposition.UNSUPPORTED_DEFERRED,\n]);\n\n/**\n * True when a disposition must stop the erasure before any write lands.\n *\n * Exported (rather than inlined at the one call site) so a future boot-time guard — the erasure\n * analogue of `validateCompositionCascadeDeletability` — reports exactly the edges the runtime\n * would refuse, instead of re-deriving the rule and drifting from it.\n */\nexport function isBlockingSubjectErasureDisposition(\n  disposition: SubjectErasureDisposition,\n): boolean {\n  return BLOCKING_DISPOSITIONS.has(disposition);\n}\n\n/**\n * Classify what a subject erasure must do with ONE child-direction edge — the delete-vs-retain\n * decision, DERIVED FROM CONFIGURATION rather than from a hardcoded list of resource types.\n *\n * ## Where the answer comes from\n *\n * Two declarations the author already makes, read through the SAME shared authority the runtime\n * delete cascade reads (`resolveRelationshipLifecycleOnParentDeleteConfig`), so the erasure and the\n * cascade can never disagree about what an edge says:\n *\n *  1. **`handling.lifecycleModelMode`** — does the subject own this dependent's lifecycle at all?\n *     `INDEPENDENT` / `LINK_ONLY` answers \"no\", and the erasure leaves those rows alone.\n *  2. **`childOperations.lifecycle.onParentDelete`** — for an owned dependent, what did the author\n *     declare happens when the parent stops owning it: hard-delete, scrub-and-retain, or nothing.\n *\n *  3. **the child's own `retentionPolicy`** — the ONE declaration whose entire subject is this\n *     question: *\"`retentionPolicy.mode` on a resource says WHAT erasure does to a row\"*\n *     (`retention-schedule.shared.schemas.ts`). Supplied through `resolveChildRetentionPolicy` so this\n *     function stays pure.\n *\n * ## The semantic caveat — CORRECTED 2026-09-17 (#1279), and the correction is the point\n *\n * `onParentDelete` literally answers \"what happens when the parent row is DELETED\", and an erasure\n * does NOT delete the subject — it scrubs and keeps it. This function used to treat the two questions\n * as one, on a stated premise: *\"they have the same answer for every edge in the shipped registry\"*.\n *\n * **That premise was false, and it had never been measured.** Measured across `engine/`, `platform/`\n * and `examples/`: 28 edges reached a `DELETE` erasure disposition while the child resource declared\n * `retentionPolicy` — i.e. an erasure deleting rows whose own resource says an erasure keeps them.\n *\n * What made it invisible was a SCHEMA DEFAULT. `strategy` carried\n * `.default(ChildLifecycleStrategy.DELETE)`, so every parsed edge presented `strategy: 'delete'` as an\n * own property whether or not a human had ever considered the question — and **28 of those 28 edges\n * reached DELETE through that default. Not one author had written `strategy: DELETE` for a\n * retain-declaring resource.** The default was removed (see `ChildLifecycleOnDeleteConfigSchema`), so\n * absence now arrives here intact and this function can tell a decision from a silence.\n *\n * ## The precedence, which decides no legal question\n *\n * | child `retentionPolicy` | this edge's `strategy` | disposition |\n * |---|---|---|\n * | 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 |\n * | declared (retain) | authored `DELETE` | `CONTRADICTED_BY_DECLARATIONS` — refused |\n * | declared (retain) | authored `IMPERSONALIZE_AND_RETAIN` | they agree; the edge's arm below runs |\n * | none | anything, including absent | unchanged — no erasure declaration exists to honour |\n *\n * Note what is deliberately NOT done: \"retain wins\" is not made a blanket default over an AUTHORED\n * `DELETE`. {@link findSubjectErasureRetainDeleteConflicts} rejects exactly that reasoning for the\n * edge-vs-edge case — *it decides a legal question on the author's behalf; neither default is safe, so\n * no default* — and that rejection stands here. Deleting data a retention obligation required keeping\n * and stranding data an erasure claimed to have removed are both unsafe, and nothing in the\n * configuration says which the author meant. The only thing that changed is that a SCHEMA DEFAULT may\n * no longer impersonate an author's decision.\n *\n * A sibling `onSubjectErasure` axis on the edge was reconsidered and stays rejected: `retentionPolicy`\n * already IS the erasure axis, and adding a second one would give app authors two ways to say the same\n * thing — the objection the previous version of this note raised against it, which survives its own\n * premise being wrong.\n *\n * Pure and side-effect free — no registry lookups, no I/O — so it is equally usable from a runtime\n * orchestrator and from a boot-time guard.\n */\nexport function classifySubjectErasureDisposition(\n  relationship: ResourceRelationship,\n  resolveChildRetentionPolicy: (\n    resourceType: ResourceType,\n  ) => SubjectErasureChildRetentionDeclaration | undefined,\n): SubjectErasureEdgeClassification {\n  const childResourceType = relationship.resourceType2 as ResourceType;\n  const classify = (\n    disposition: SubjectErasureDisposition,\n    reason: string,\n  ): SubjectErasureEdgeClassification => ({ childResourceType, disposition, reason });\n\n  // A disabled relationship is not part of the live graph — the runtime never traverses it, so an\n  // erasure must not refuse to run because of it (the alternative would be a permanently blocked\n  // erasure on a resource carrying a switched-off edge).\n  if (relationship.isDisabled === true) {\n    return classify(\n      SubjectErasureDisposition.NOT_OWNED,\n      'the relationship is disabled (isDisabled: true), so it is not part of the live graph',\n    );\n  }\n\n  const semantics = Resources_SharedUtils.requireResolvedRelationshipSemantics(relationship);\n  const lifecycleModel = semantics.handling.lifecycleModelMode;\n\n  if (lifecycleModel !== RelationshipLifecycleModel.DEPENDENT) {\n    return classify(\n      SubjectErasureDisposition.NOT_OWNED,\n      `lifecycleModelMode is '${lifecycleModel}' (not DEPENDENT): the related rows live ` +\n        `independently of the subject, so their disposition is not this erasure's decision`,\n    );\n  }\n\n  // DEPENDENT from here on: the subject owns this dependent's lifecycle, so the erasure MUST have\n  // an answer for it.\n  const onParentDelete = Resources_SharedUtils.resolveRelationshipLifecycleOnParentDeleteConfig(\n    relationship,\n  );\n\n  if (!onParentDelete) {\n    return classify(\n      SubjectErasureDisposition.UNCLASSIFIED,\n      `the subject owns this dependent (lifecycleModelMode: DEPENDENT) but the edge declares no ` +\n        `onParentDelete lifecycle, so nobody has said whether its rows survive an erasure. ` +\n        `Declare onParentDelete on the edge: 'enabled: true' with strategy DELETE (the rows hold ` +\n        `no retainable value) or IMPERSONALIZE_AND_RETAIN (they must survive scrubbed), or ` +\n        `'enabled: false' to state explicitly that they survive intact`,\n    );\n  }\n\n  /*\n   * ## DECIDED 2026-09-17 (#1084): this is NOT reconciled against a DELETE path, and that is correct\n   *\n   * The question was whether a resource reached BOTH by this disposition and by a DELETE edge should\n   * be refused the way #1017 refuses `IMPERSONALIZE_AND_RETAIN` against `DELETE`. It should not, and\n   * the reason is that the two cases are not alike.\n   *\n   * #1017 refuses because TWO EXECUTED TREATMENTS disagree about the same row: one scrubs it and keeps\n   * it, the other removes it, and nothing says which wins. `enabled: false` executes nothing. The\n   * erasure never traverses this edge and never discovers these rows, so there is no competing\n   * treatment to reconcile — only one edge that acts and one that says nothing. A row with two parents\n   * that survives one teardown and dies with the other is also exactly what an ordinary parent delete\n   * does, so refusing here would make an erasure stricter than the lifecycle it is built on.\n   *\n   * Refusing was the filed recommendation and is rejected for a further reason: the #1017 refusal's own\n   * remedy tells an operator to \"disable one edge's teardown (onParentDelete.enabled: false)\". Treating\n   * the result as a new conflict would make the documented remedy produce the next refusal.\n   *\n   * What this disposition means is therefore narrower than its name suggests, and worth saying plainly:\n   * it records that THIS EDGE does not cascade, not that the rows are guaranteed to survive the\n   * erasure. Another path may still delete them, and that path's declaration is the one that decides.\n   */\n  if (onParentDelete.enabled !== true) {\n    return classify(\n      SubjectErasureDisposition.RETAINED_BY_DECLARATION,\n      'onParentDelete.enabled is false: the author declared these rows survive their parent\\'s ' +\n        'teardown, so the erasure leaves them intact',\n    );\n  }\n\n  // The RESTRICT posture is read BEFORE the mode: it tears nothing down, so there is no teardown to\n  // defer, and a `mode: LAZY` written beside it must not turn a leave-alone edge into a blocking one.\n  // After this return TypeScript narrows `strategy` below to the teardown members, so the switch's\n  // exhaustiveness check still turns any FUTURE member into a type error.\n  if (onParentDelete.strategy === ChildLifecycleStrategy.REFUSE_WHILE_CHILDREN_EXIST) {\n    return classify(\n      SubjectErasureDisposition.RESTRICTED_BY_DECLARATION,\n      'onParentDelete declares strategy REFUSE_WHILE_CHILDREN_EXIST: the parent\\'s delete is refused ' +\n        'while these rows exist, and an erasure scrubs the subject in place rather than deleting it, so ' +\n        'the erasure leaves the rows intact',\n    );\n  }\n\n  const mode = onParentDelete.mode ?? ChildLifecycleMode.IMMEDIATE;\n  if (mode !== ChildLifecycleMode.IMMEDIATE) {\n    return classify(\n      SubjectErasureDisposition.UNSUPPORTED_DEFERRED,\n      `onParentDelete.mode is '${mode}': deferring the teardown to a queue would let the erasure ` +\n        `report success while the subject's personal data is still live. Set mode: IMMEDIATE on ` +\n        `this edge for it to participate in a subject erasure`,\n    );\n  }\n\n  /*\n   * #1279 — the child's OWN erasure declaration is consulted BEFORE the edge's teardown strategy.\n   *\n   * ## Why this sits AFTER the deferral check, deliberately\n   *\n   * `mode: LAZY` is read above and refuses first, so a deferred edge never reaches the retention\n   * question. The alternative — letting a retain policy rescue a LAZY edge, the way the RESTRICT\n   * posture is read before `mode` — was considered and REJECTED: RESTRICT tears nothing down, so\n   * there is genuinely no teardown to defer, while `RETAIN_AND_IMPERSONALIZE` is an ACTION (the\n   * in-place scrub), and an erasure that defers its own scrub reports success while personal data is\n   * still live. Refusing is the fail-closed answer and the one an operator can act on.\n   *\n   * Measured 2026-09-17: the shipped registry declares ZERO `mode: LAZY` edges, so this ordering is\n   * currently unobservable. It is written down rather than left to be re-derived by whoever declares\n   * the first one.\n   *\n   * `strategy` is read RAW here, never through `resolveChildLifecycleTeardownStrategy`. That helper\n   * resolves absence to DELETE for the CASCADE, where the premise \"the parent row is gone\" makes it\n   * correct. An erasure keeps the parent row, so the premise is false and the resolution would be a\n   * manufactured answer — which is precisely the defect this replaces.\n   */\n  const authoredStrategy = onParentDelete.strategy;\n  const childRetentionPolicy = resolveChildRetentionPolicy(childResourceType);\n\n  if (childRetentionPolicy?.mode !== undefined) {\n    const retentionMode = childRetentionPolicy.mode;\n    const retainDisposition =\n      retentionMode === ErasureRetentionMode.RETAIN_AND_IMPERSONALIZE\n        ? SubjectErasureDisposition.IMPERSONALIZE_AND_RETAIN\n        : SubjectErasureDisposition.RETAINED_BY_DECLARATION;\n\n    if (authoredStrategy === undefined) {\n      return classify(\n        retainDisposition,\n        `the child resource declares retentionPolicy.mode '${retentionMode}' — the declaration that ` +\n          `states what an erasure does to its rows — and this edge authors no onParentDelete.strategy, ` +\n          `so nothing contradicts it. The erasure applies the declared retention treatment rather than ` +\n          `the teardown the delete cascade would apply, because an erasure keeps the parent row`,\n      );\n    }\n\n    /*\n     * An AUTHORED strategy is left to the switch below, deliberately — including an authored DELETE,\n     * which CONTRADICTS this retention policy.\n     *\n     * Refusing it here as a per-edge disposition was implemented first and REVERTED, because a\n     * blocking disposition is refused by the orchestrator BEFORE the plan-level detectors run: it\n     * shadowed {@link findSubjectErasureRetainDeleteConflicts} (#1017) and\n     * {@link findSubjectErasureSubjectTypeDeleteEdges} (#1085), whose refusals name both offending\n     * edges and the resource, with a generic \"no executable disposition\" message. Two purpose-built,\n     * mutation-proven refusals became unreachable for their whole population — every shape they\n     * detect requires the child to declare a `retentionPolicy`, so every one of them is also this\n     * contradiction.\n     *\n     * A contradiction is a relation between TWO declarations, which is what a plan-level detector\n     * models and what a single edge's disposition cannot. It therefore lives beside its siblings, as\n     * {@link findSubjectErasureRetentionContradictedEdges}.\n     */\n  }\n\n  /*\n   * The residual, named rather than left to look like an inconsistency with everything above.\n   *\n   * A child that declares NO `retentionPolicy` and sits on a SILENT edge has had nothing said about it\n   * in either field, and here absence still resolves to DELETE — the reading the engine has always\n   * had, that a dependent's data has no life of its own once the subject's ownership does not. 33\n   * children are in that position (measured 2026-09-17), and the alternative was to refuse all 33 as\n   * UNCLASSIFIED until someone authored a declaration for each.\n   *\n   * That was rejected for the reason `application-creation-directive.md` gives: the remedy would be\n   * \"an author decides something\", which makes an erasure impossible to run until a large authoring\n   * backlog is cleared, and #1279 was about an erasure doing the WRONG thing, not about it being\n   * under-declared. The narrow fix is the one that keeps the correction checkable.\n   *\n   * What changed is precise and worth stating: silence no longer overrules a DECLARATION. It still\n   * carries the historical default where there is no declaration to overrule. If this project later\n   * wants that last case explicit too, the place for it is a per-edge `onSubjectErasure` axis, and\n   * the argument against adding one speculatively is in this function's header.\n   */\n  const strategy = authoredStrategy ?? ChildLifecycleStrategy.DELETE;\n  switch (strategy) {\n    case ChildLifecycleStrategy.DELETE:\n      return classify(\n        SubjectErasureDisposition.DELETE,\n        'onParentDelete declares strategy DELETE: the dependent\\'s data dies with the subject\\'s ' +\n          'ownership, so the erasure removes the rows',\n      );\n\n    case ChildLifecycleStrategy.IMPERSONALIZE_AND_RETAIN:\n      return classify(\n        SubjectErasureDisposition.IMPERSONALIZE_AND_RETAIN,\n        'onParentDelete declares strategy IMPERSONALIZE_AND_RETAIN: the rows survive the erasure ' +\n          'with their personal fields scrubbed and retentionStatus flipped to RETAINED',\n      );\n\n    default: {\n      // Compile-time exhaustiveness: a new ChildLifecycleStrategy member without an erasure arm is\n      // a TYPE error here, not a silent runtime discovery on someone's deletion request.\n      const _exhaustiveStrategyCheck: never = strategy;\n      return classify(\n        SubjectErasureDisposition.UNCLASSIFIED,\n        `onParentDelete declares an unknown teardown strategy ` +\n          `'${String(_exhaustiveStrategyCheck)}' that subject erasure has no arm for`,\n      );\n    }\n  }\n}\n\n/**\n * One DESCENDANT edge an erasure must account for — an edge below the subject's direct dependents,\n * planned from configuration before anything runs (#976).\n *\n * `parentResourceType` is the resource whose rows the erasure tears down and that owns this edge;\n * the classification is the same one a direct edge gets, from the same shared classifier, so a\n * descendant and a direct edge can never disagree about what an identical declaration means.\n */\nexport interface SubjectErasureDescendantEdgePlan {\n  /** The edge itself, as the parent resource's configuration declares it. */\n  relationship: ResourceRelationship;\n  /** The resource that owns this edge — its rows are the ones being torn down above it. */\n  parentResourceType: ResourceType;\n  classification: SubjectErasureEdgeClassification;\n}\n\n/**\n * Plan every DESCENDANT edge a subject erasure walks below ONE direct dependent (#976).\n *\n * ## What an erasure walks, and why exactly that\n *\n * - **Below a `DELETE` edge — everything, at every depth, regardless of `maxDepth`.** The rows are\n *   gone, so whatever depended on them has lost its owner; an erasure that stops at a depth budget\n *   leaves the subject's data one level down with nothing left to reach it. `maxDepth` is a\n *   parent-DELETE performance budget and keeps meaning exactly that on the delete cascade.\n * - **Below an `IMPERSONALIZE_AND_RETAIN` edge — nothing.** The retained row survives, scrubbed, so\n *   its own dependents still have their owner and remain bound to THAT row's future lifecycle. The\n *   retention obligation that keeps the row is the obligation that keeps what hangs off it; tearing\n *   those down would destroy records a legal obligation required keeping, and scrubbing them would\n *   need a declaration nobody made. This matches the cascade itself, whose retain arm never recurses.\n * - **Below `RETAINED_BY_DECLARATION` / `NOT_OWNED` — nothing.** The rows are not touched.\n *\n * Every child-direction edge of every walked resource is returned — including the ones that do\n * nothing — because the receipt is total over what the erasure walked, exactly as it is at the\n * direct level. A blocking classification anywhere in the plan must refuse the erasure BEFORE its\n * transaction opens; returning it (rather than throwing here) lets the caller name every one.\n *\n * ## Termination\n *\n * The walk is over RESOURCE TYPES, not rows, so each type's edges are planned once: a self-referential\n * edge (a folder of folders) or a cycle between types terminates here, while the row-level cascade\n * keeps its own visited-row guard.\n *\n * Pure: the caller supplies the lookup, so a boot-time guard can run the same planner the runtime\n * does rather than re-deriving it.\n *\n * @param directChildResourceType - the far side of the subject's direct `DELETE` edge.\n * @param resolveChildDirectionRelationships - the child-direction edges of a resource type, or\n *   `undefined` when the type has no configuration in this process (nothing is planned below it; the\n *   runtime cascade then declines that edge and reports it as not executed).\n * @param resolveChildRetentionPolicy - a resource type's declared `retentionPolicy`, or `undefined`\n *   when it declares none. Injected for the same reason as the lookup above: it keeps this planner\n *   pure, so a boot-time guard classifies a descendant edge exactly as the runtime will (#1279).\n */\nexport function planSubjectErasureDescendantEdges(\n  directChildResourceType: ResourceType,\n  resolveChildDirectionRelationships: (resourceType: ResourceType) => ResourceRelationship[] | undefined,\n  resolveChildRetentionPolicy: (\n    resourceType: ResourceType,\n  ) => SubjectErasureChildRetentionDeclaration | undefined,\n): SubjectErasureDescendantEdgePlan[] {\n  const planned: SubjectErasureDescendantEdgePlan[] = [];\n  const walked = new Set<string>();\n  const pending: ResourceType[] = [directChildResourceType];\n\n  while (pending.length > 0) {\n    const parentResourceType = pending.shift()!;\n    if (walked.has(String(parentResourceType))) continue;\n    walked.add(String(parentResourceType));\n\n    for (const relationship of resolveChildDirectionRelationships(parentResourceType) ?? []) {\n      const classification = classifySubjectErasureDisposition(relationship, resolveChildRetentionPolicy);\n      planned.push({ relationship, parentResourceType, classification });\n      if (classification.disposition === SubjectErasureDisposition.DELETE) {\n        pending.push(classification.childResourceType);\n      }\n    }\n  }\n\n  return planned;\n}\n\n/**\n * One resource an erasure's plan reaches both to KEEP its rows and to DELETE them (#1017).\n *\n * `TEdge` is whatever the caller planned — a direct edge, a descendant edge, or its own record of either —\n * so the orchestrator can name the edges the way its refusal already names unresolved ones.\n */\nexport interface SubjectErasureRetainDeleteConflict<TEdge> {\n  /** The resource on the far side of every edge below. */\n  resourceType: ResourceType;\n  /** Edges that scrub these rows and keep them (`IMPERSONALIZE_AND_RETAIN`), in plan order. */\n  retainingEdges: TEdge[];\n  /** Edges that hard-delete these rows (`DELETE`), in plan order. */\n  deletingEdges: TEdge[];\n}\n\n/**\n * Find every resource a subject erasure's WHOLE plan reaches through both a retaining edge and a deleting\n * edge (#1017). The erasure REFUSES before its transaction opens when this returns anything.\n *\n * ## The shape\n *\n * Each edge applies its own declared treatment to the rows it reaches: `DELETE` hard-deletes them,\n * `IMPERSONALIZE_AND_RETAIN` scrubs them and keeps them. Two DIFFERENT paths can reach the same resource — a\n * `people → records` retain edge beside `people → profiles → notes → records` delete, or two edges on one\n * resource through two foreign keys — and nothing in either declaration says what happens to a row BOTH\n * reach. Before this, the answer was the walk order: a row kept by the retain edge could still be deleted\n * when the delete edge's cascade got there, and #976 could only make the receipt admit it (`executed: false`).\n *\n * ## Why REFUSE, and why at the level of resource types\n *\n * The two declarations contradict each other for the rows they share, and neither outranks the other in\n * configuration. Refusing is the one answer that needs no new meaning: it surfaces the contradiction to the\n * author, who owns both declarations and can make them agree — declare the delete edge\n * `IMPERSONALIZE_AND_RETAIN` too, declare the retain edge `DELETE`, or disable one edge's teardown\n * (`onParentDelete.enabled: false`) — on the ground the legal obligation actually gives.\n *\n * The check is over resource TYPES, not rows, on purpose. Whether two edges share a row is only knowable by\n * reading rows, which the pre-flight must not do (every refusal here lands before the first read and write),\n * and it changes as rows are written, so a row-level \"no overlap today\" would be a guess about the future.\n * An edge pair that can never share a row in practice is still refused; the remedy is the same one-edge edit.\n *\n * ## Rejected: a precedence where retain wins\n *\n * \"Keep a row whenever any edge retains it\" was considered and rejected, for three reasons:\n *\n * - **It decides a legal question on the author's behalf.** A `DELETE` edge is a declaration too — that the\n *   rows hold nothing worth keeping once their owner is gone. GDPR Art. 17(3) lists the grounds on which the\n *   right to erasure does not apply (a legal obligation, the defence of legal claims, archiving, …), and\n *   Art. 5(2) makes the controller \"responsible for, and be able to demonstrate compliance with\" the\n *   principles. Keeping personal data an explicit declaration said to remove therefore needs a ground the\n *   controller can name, and a framework default names none. \"Delete wins\" fails the other way, destroying\n *   records a retention obligation required keeping. Neither default is safe, so no default.\n *   spec-cite: Regulation (EU) 2016/679, Art. 5(2) (accountability) and Art. 17(3)(a)–(e) (exceptions to the right to erasure).\n * - **Only its row-level form is faithful, and that form cannot be decided before the transaction.** A\n *   TYPE-level \"retain wins\" could be decided pre-flight, but it would keep every row of the resource,\n *   including rows only the delete edge reaches and the retain edge never touches — rows no retention\n *   declaration covers. The faithful rule is ROW-level: the delete walk skips each row a retain edge kept and\n *   prunes everything it planned below that row (a kept row still anchors its own dependents), per row,\n *   mid-transaction. The pre-flight plan is over types and cannot express that, so the\n *   refusal-before-any-write guarantee the rest of the erasure keeps would be lost.\n * - **It adds a meaning with no vocabulary for its opposite.** Once precedence exists, an author who needs\n *   the delete to win has no way to say so.\n *\n * ## What is NOT a conflict\n *\n * Only `DELETE` against `IMPERSONALIZE_AND_RETAIN` — the two treatments the erasure EXECUTES. Two deleting or\n * two retaining edges agree. `NOT_OWNED` rows are not the subject's, and the erasure never discovers them.\n * Two cases are deliberately NOT refused here. Each is an open decision, not an answer this rule gives:\n *\n * - **(a) A `RETAINED_BY_DECLARATION` dependent beside a `DELETE` path to the same resource (#1084).** The\n *   erasure never discovers `enabled: false` rows, and a row with two parents that survives one teardown and\n *   dies with the other is also what an ordinary parent delete does. **DECIDED 2026-09-17: this stays out.**\n *   `enabled: false` executes nothing, so there are not two treatments to reconcile — and the refusal below\n *   names `onParentDelete.enabled: false` as its own remedy, so counting it as a conflict would make that\n *   remedy produce the next refusal. The full argument is at the classification site.\n * - **(b) A delete closure that cycles back to the SUBJECT's own resource type while the subject row is\n *   retained (#1085).** The subject's retention is the erasure's own final step (the scrub), not an edge, so\n *   this detector — which reads only edges — cannot see it. **CLOSED 2026-09-17 by\n *   {@link findSubjectErasureSubjectTypeDeleteEdges}**, a sibling that takes the subject's own type as an\n *   argument precisely because it is not derivable from the edges.\n *\n * Pure, so a boot-time guard can run it over the same plan the runtime refuses on.\n *\n * @param plannedEdges - every edge of ONE erasure: the subject's direct edges AND every descendant edge\n *   planned below its deleted dependents, each carrying its classification.\n * @returns one entry per conflicting resource, in the order the resource is first reached.\n */\nexport function findSubjectErasureRetainDeleteConflicts<TEdge extends { classification: SubjectErasureEdgeClassification }>(\n  plannedEdges: readonly TEdge[],\n): Array<SubjectErasureRetainDeleteConflict<TEdge>> {\n  const byResourceType = new Map<string, SubjectErasureRetainDeleteConflict<TEdge>>();\n  for (const edge of plannedEdges) {\n    const { disposition, childResourceType } = edge.classification;\n    if (disposition !== SubjectErasureDisposition.DELETE && disposition !== SubjectErasureDisposition.IMPERSONALIZE_AND_RETAIN) {\n      continue;\n    }\n    const key = String(childResourceType);\n    const entry = byResourceType.get(key) ?? { resourceType: childResourceType, retainingEdges: [], deletingEdges: [] };\n    byResourceType.set(key, entry);\n    if (disposition === SubjectErasureDisposition.DELETE) entry.deletingEdges.push(edge);\n    else entry.retainingEdges.push(edge);\n  }\n  return [...byResourceType.values()].filter((entry) => entry.retainingEdges.length > 0 && entry.deletingEdges.length > 0);\n}\n\n/**\n * What happened on ONE descendant edge of an executed erasure (#976) — reported exactly like a direct\n * edge: its disposition, the configuration that justified it, and whether its teardown ran.\n */\nexport interface SubjectErasureDescendantEdgeOutcome extends SubjectErasureEdgeClassification {\n  /** The resource that owns this edge. */\n  parentResourceType: ResourceType;\n  /**\n   * `true` when every teardown the erasure reached on this edge ran, `false` when any was declined, when\n   * this DELETE edge reached rows an earlier retain edge of the same walk scrubbed and KEPT (they are not\n   * gone, whatever this edge declares — unreachable since #1017, which refuses a plan that retains and deletes\n   * one resource before it runs, and kept as defence in depth), or when an edge ABOVE it was declined (its rows were then never\n   * walked, so nothing can be said about what they still hold). `false` on a non-executing disposition\n   * is expected, as on a direct edge.\n   *\n   * An executing edge the walk never had to dispatch — its parent resource had no rows of the subject's\n   * left to tear down — is `true`: that is a teardown with nothing to do, not a decline.\n   */\n  executed: boolean;\n}\n\n/** Per-edge outcome of an executed erasure — the classification plus what actually happened. */\nexport interface SubjectErasureEdgeOutcome extends SubjectErasureEdgeClassification {\n  /**\n   * Every edge below this one that the erasure walked, flat and in plan order (#976). Empty for a\n   * non-executing disposition and for `IMPERSONALIZE_AND_RETAIN`, which retains its rows and therefore\n   * does not walk below them — see {@link planSubjectErasureDescendantEdges}.\n   */\n  descendantEdges: SubjectErasureDescendantEdgeOutcome[];\n  /**\n   * `true` when the erasure ran a teardown for this edge AND for every descendant edge below it whose\n   * disposition executes (#976). A declined descendant therefore makes its direct edge `false`: a\n   * reader who only counts direct edges must not read a subtree that still holds live data as erased.\n   * {@link descendantEdges} says which descendant it was.\n   *\n   * Reports that the teardown RAN, not that rows existed — discovery finding no dependents is a\n   * teardown that ran with nothing to do, and is `true`.\n   *\n   * **Read it together with `disposition`, because `false` has two very different meanings:**\n   *\n   * - a NON-executing disposition (`RETAINED_BY_DECLARATION`, `NOT_OWNED`) ⇒ the erasure deliberately\n   *   left the rows alone, and `false` is the expected, correct answer;\n   * - an EXECUTING disposition (`DELETE`, `IMPERSONALIZE_AND_RETAIN`) ⇒ the cascade DECLINED the edge\n   *   (the child had no registered service or repository), or an edge BELOW it did not tear its rows\n   *   down (see `descendantEdges`) — declined the same way, or a DELETE edge that reached rows an\n   *   earlier retain edge of the walk kept. An erasure never spends a depth budget — it walks every\n   *   descendant. The subject's data is partly still live. This pairing should never appear in a\n   *   healthy system; it is logged at ERROR when it happens, naming the missing registration or the\n   *   descendant edges concerned.\n   *\n   * ⚠️ This flag was set unconditionally until 2026-08-11 — it meant \"the dispatcher returned without\n   * throwing\" and reported a skipped edge as torn down. Anything persisted before that date overstates\n   * what was erased. Treat this field as evidence only for reports produced after the fix.\n   */\n  executed: boolean;\n}\n\n/**\n * Outcome of one EXTERNAL, non-transactional erasure effect (a third-party provider the subject's\n * personal data also reached — a billing provider customer, say).\n *\n * A separate vocabulary from {@link SubjectErasureDisposition} on purpose. An edge disposition\n * describes a decision derived from configuration BEFORE anything ran, and its teardown is part of\n * the database transaction. An external effect is the opposite on both counts: it is discovered by\n * calling out to a system Wildo does not own, and it CANNOT join the transaction. Collapsing the\n * two would let a caller read \"the erasure succeeded\" from a value that only ever described the\n * local rows.\n */\nexport enum SubjectErasureExternalEffectStatus {\n  /** Every step of the effect completed against the external system. */\n  COMPLETED = 'completed',\n  /**\n   * The subject had nothing at this external system — no provider customer, no linked record. A\n   * legitimate success, kept DISTINCT from `COMPLETED` so \"there was nothing to erase\" can never be\n   * mistaken for \"we erased it\", which is exactly the confusion a regulator would probe.\n   */\n  NOTHING_TO_ERASE = 'nothing-to-erase',\n  /**\n   * The effect ran and some steps succeeded while others failed — personal data may still be live\n   * at the external system. The loudest state in this enum: it demands follow-up, and it is why the\n   * status is not a boolean.\n   */\n  PARTIAL = 'partial',\n  /** The effect could not run at all (provider unreachable, not configured). Nothing was changed. */\n  FAILED = 'failed',\n  /**\n   * No handler was registered for this effect. Distinct from `NOTHING_TO_ERASE`: that means we\n   * looked and found nothing, this means nobody looked.\n   */\n  NOT_REGISTERED = 'not-registered',\n\n  /**\n   * A bound external-effects port returned no usable report. The local erasure committed, but\n   * external outcomes are UNKNOWN: neither no work nor no change can be inferred. Incomplete;\n   * reconcile provider state before retrying work that may already have succeeded.\n   */\n  UNMEASURED = 'unmeasured',\n\n  /**\n   * The external system's binding DECLARES its rows hold no personal/subject data\n   * (`HttpApiErasureStance.NO_SUBJECT_DATA`, ETL D6 stance 6a) — nothing was erased because,\n   * by declaration, there is nothing an erasure could apply to. Distinct from\n   * {@link NOTHING_TO_ERASE}: that means we LOOKED and found no linked rows; this means the\n   * declaration made looking unnecessary. A complete outcome — the declaration's coherence is\n   * validated at boot (a 6a resource cannot participate in subject export).\n   */\n  DECLARED_NO_SUBJECT_DATA = 'declared-no-subject-data',\n\n  /**\n   * The rows live in an external system the platform cannot erase, and the CONTROLLER explicitly\n   * acknowledged completing the erasure anyway (`HttpApiErasureStance.\n   * CONTROLLER_ACKNOWLEDGED_NON_ERASURE`, ETL D6 stance 6c — the per-request\n   * `acknowledgeHttpApiNonErasure` option). Deliberately INCOMPLETE in\n   * {@link isIncompleteSubjectErasureExternalEffect}: the subject's data is still live at the\n   * third party, and a compliance artifact must say so however deliberate the decision was. The\n   * acknowledgement itself is additionally recorded as a CRITICAL audit event — the record is\n   * the control (`administrative-continuity-floors.md`).\n   */\n  ACKNOWLEDGED_NON_ERASURE = 'acknowledged-non-erasure',\n}\n\n/** Whether an external-effect status leaves personal data potentially live at a third party. */\nexport function isIncompleteSubjectErasureExternalEffect(\n  status: SubjectErasureExternalEffectStatus,\n): boolean {\n  return status === SubjectErasureExternalEffectStatus.PARTIAL\n    || status === SubjectErasureExternalEffectStatus.FAILED\n    || status === SubjectErasureExternalEffectStatus.NOT_REGISTERED\n    || status === SubjectErasureExternalEffectStatus.UNMEASURED\n    // An acknowledged non-erasure is a DELIBERATE hole, and still a hole: personal data remains\n    // live at the third party, so \"is this erasure actually complete\" must answer no.\n    || status === SubjectErasureExternalEffectStatus.ACKNOWLEDGED_NON_ERASURE;\n}\n\nexport interface SubjectErasureExternalEffectOutcome {\n  /** Stable identifier of the effect, e.g. `'billing-provider'`. */\n  effectRef: string;\n  status: SubjectErasureExternalEffectStatus;\n  /**\n   * Human-readable account of what ran, for the compliance artifact. On `PARTIAL` / `FAILED` this\n   * must name what did NOT happen — the report is the only place that survives the request.\n   */\n  detail: string;\n  /**\n   * Per-step results, so a partial outcome is actionable rather than merely alarming (which step\n   * against which external id). Never carries personal data — ids and step names only.\n   */\n  steps?: Array<{ step: string; targetRef?: string; succeeded: boolean; error?: string }>;\n}\n\n/**\n * What one subject erasure did — the compliance artifact of a \"delete my account\" request.\n *\n * Returned to the caller (rather than only logged) so the flow that fronts the request can record\n * or surface it: every edge of the subject appears exactly once with the disposition applied and\n * the configuration that justified it, which is the evidence a data-protection response needs.\n *\n * assurance-control: WILDO.PRIVACY.ERASURE_PROPAGATION — an erasure accounts per store instead of\n * one verdict: each direct dependent edge with whether its teardown ran, each descendant edge the\n * erasure walked below it (nested in `descendantEdges`, folded into the direct edge's `executed`),\n * each registered external effect with its own outcome. The engine returns this and persists none of\n * it; retaining it is the calling application's job.\n */\nexport interface SubjectErasureReport {\n  /** The erased subject's resource type. */\n  subjectResourceType: ResourceType;\n  /** The erased subject rows. */\n  subjectIds: string[];\n  /** Every child-direction edge of the subject, classified, in registry order. */\n  edges: SubjectErasureEdgeOutcome[];\n  /**\n   * `true` once the subject rows themselves were scrubbed and flipped to `RETAINED`. Always `true`\n   * on a successful erasure — an erasure that could not retain its subject throws rather than\n   * returning a report.\n   */\n  subjectImpersonalized: boolean;\n  /**\n   * Whose sessions this erasure ended, and whether resolving them failed.\n   *\n   * A LOCAL fact, not an external effect: the revocation is a write to our own session fence, applied\n   * at the scrub chokepoint so it covers every path that scrubs a person's row. It is recorded here\n   * because \"the erased person can no longer be logged in\" is exactly what a data-protection response\n   * has to be able to evidence.\n   *\n   * `lookupFailed` is kept distinct from an empty `principalUserIds`: no principals is a legitimate\n   * outcome (the resource declared `NO_PRINCIPAL`), whereas a failed lookup means the person may\n   * still hold a live session — and the two must never look alike in a compliance artifact.\n   */\n  sessionRevocation?: {\n    principalUserIds: string[];\n    lookupFailed: boolean;\n  };\n  /**\n   * Outcomes of the external, non-transactional effects the erasure triggered — every SYSTEM WE\n   * DO NOT OWN that the subject's personal data reached: registered effect handlers (a billing\n   * provider), and each HTTP_API-bound resource linked to the subject (one entry per resource,\n   * `effectRef: 'http-api:<resourceType>'`, carrying its declared D6 erasure stance's outcome).\n   *\n   * A malformed response from a bound registry produces one aggregate UNMEASURED entry,\n   * identifying that boundary rather than inventing individual provider outcomes.\n   *\n   * Empty when no effect was registered for the subject's resource type. These run AFTER the local\n   * scrub has committed, so a failure here cannot roll the erasure back — the local data is\n   * already gone and re-running the whole erasure would be wrong. That asymmetry is precisely why\n   * the outcome is reported rather than thrown: the local part genuinely succeeded, and the caller\n   * needs to know that a third party still holds something.\n   *\n   * Check {@link isIncompleteSubjectErasureExternalEffect} over these before treating a report as a\n   * complete erasure.\n   */\n  externalEffects: SubjectErasureExternalEffectOutcome[];\n}\n\n\n/**\n * Edges whose DELETE would reach the SUBJECT'S OWN resource type (#1085).\n *\n * ## The hazard\n *\n * A subject erasure SCRUBS the subject row and keeps it — that is the erasure's contract with the data\n * subject, and it is unconditional: `eraseSubjectInPlace` refuses outright when the subject resource\n * declares no `retentionPolicy`. Since #976 the walk also descends below every dependent it deletes, so\n * a DELETE closure that comes back round to the subject's own type would delete the very row the\n * erasure promised to retain — and the receipt would still report it retained.\n *\n * That last part is why this refuses rather than skips. `SubjectErasureDescendantWalk`'s accounting is\n * written so a receipt can never OVERSTATE an erasure; deleting the scrubbed subject would overstate in\n * the one way nothing downstream can detect, because every edge reports exactly what it did.\n *\n * ## Why the sibling detector cannot do this\n *\n * {@link findSubjectErasureRetainDeleteConflicts} compares two EDGE dispositions. The subject's retention\n * is not an edge — no relationship declares it — so the subject's type is passed in here rather than\n * inferred. It is the whole reason this is a second function and not a case in the first.\n *\n * ## Measured 2026-09-17: the population is EMPTY, and that is the point\n *\n * In the engine's core graph `USERS` is never the CHILD of a composition. The one relationship naming it\n * second — `ORGANIZATIONS → USERS` — is a `RelationshipNature.ASSOCIATION` through\n * `ORGANIZATION_MEMBERS`, and an association carries no `onParentDelete` teardown, so no closure can\n * reach it. A guard over an empty population costs nothing at runtime and is exactly the shape worth\n * having: it cannot regress silently, and an application that later declares such an edge meets a\n * refusal before any read or write instead of an erasure that quietly contradicts itself.\n *\n * Pure, so a boot-time guard can run it over the same plan the runtime refuses on.\n *\n * @param plannedEdges - every edge of ONE erasure, each carrying its classification.\n * @param subjectResourceType - the resource being erased, whose row is retained.\n * @returns the offending edges, in plan order. Empty is the healthy answer.\n */\n/**\n * Edges that DELETE a resource whose OWN `retentionPolicy` says an erasure keeps its rows (#1279).\n *\n * ## The contradiction\n *\n * A resource's `retentionPolicy` is the declaration whose entire subject is what an erasure does to\n * its rows, and the config factory refuses it unless it is paired with a `dataSubjectPolicy` — so it\n * is among the most deliberate statements an author makes. An edge that nevertheless AUTHORS\n * `onParentDelete.strategy: DELETE` says the opposite about the same rows. Nothing in the\n * configuration ranks the two, so an erasure must refuse rather than pick: deleting could destroy\n * data a retention obligation required keeping, and retaining could strand personal data the erasure\n * claimed to have removed. That is the same reasoning {@link findSubjectErasureRetainDeleteConflicts}\n * gives for refusing rather than defaulting, applied one level down — there between two EDGES, here\n * between an edge and the RESOURCE it points at.\n *\n * ## Why a DELETE disposition here is necessarily AUTHORED\n *\n * Since #1279 `classifySubjectErasureDisposition` applies the child's retention treatment whenever the\n * edge is SILENT, so a `DELETE` disposition toward a retain-declaring child can only have come from an\n * author writing `strategy: DELETE`. This filter therefore needs no second look at the declaration:\n * the invariant is expressed once, in the classifier, and read here. Do NOT re-derive \"was it\n * authored?\" from the relationship — that would be a second copy of the rule, free to drift.\n *\n * ## Measured population: ZERO, and that is the point\n *\n * Across `engine/`, `platform/` and `examples/` on 2026-09-17, 28 edges deleted a retain-declaring\n * resource and **not one of them authored `DELETE`** — every one reached that outcome through the\n * schema default this fix removed. So the shipped registry trips this detector nowhere, which is the\n * shape worth having: it cannot regress silently, and an application that later authors the\n * contradiction meets a refusal before any read or write rather than an erasure that quietly\n * contradicts its own declarations.\n *\n * Pure, so a boot-time guard can run it over the same plan the runtime refuses on.\n *\n * @param plannedEdges - every edge of ONE erasure, each carrying its classification.\n * @param resolveChildRetentionPolicy - a resource type's declared `retentionPolicy`, or `undefined`.\n * @returns the offending edges, in plan order. Empty is the healthy answer.\n */\nexport function findSubjectErasureRetentionContradictedEdges<TEdge extends { classification: SubjectErasureEdgeClassification }>(\n  plannedEdges: readonly TEdge[],\n  resolveChildRetentionPolicy: (\n    resourceType: ResourceType,\n  ) => SubjectErasureChildRetentionDeclaration | undefined,\n): TEdge[] {\n  return plannedEdges.filter((edge) =>\n    edge.classification.disposition === SubjectErasureDisposition.DELETE\n    && resolveChildRetentionPolicy(edge.classification.childResourceType)?.mode !== undefined);\n}\n\nexport function findSubjectErasureSubjectTypeDeleteEdges<TEdge extends { classification: SubjectErasureEdgeClassification }>(\n  plannedEdges: readonly TEdge[],\n  subjectResourceType: string,\n): TEdge[] {\n  return plannedEdges.filter((edge) =>\n    edge.classification.disposition === SubjectErasureDisposition.DELETE\n    && String(edge.classification.childResourceType) === String(subjectResourceType));\n}\n"]}

package/dist/esm/compliance/review-cadence.shared.schemas.d.ts

@@ -0,0 +1,56 @@
+/**
+ * How often something is re-reviewed, and the date that cadence schedules.
+ *
+ * ## Why it lives HERE
+ *
+ * Moved from `@wildo-ai/saas-specifications` `_core/market/market-authored-metadata.schemas` on
+ * 2026-09-11, and re-exported from there so its six existing importers are untouched. It had to move
+ * because it gained a consumer on the other side of a package boundary: an application declares
+ * `assuranceReviewCadence` in `wildo.saas.config.ts`, which is validated by
+ * `@wildo-ai/platform-config-lib` — a contracts-only package that does not depend on
+ * `saas-specifications` and should not start depending on it for one enum. `saas-models` is where the
+ * application-declared compliance vocabularies already live (`DataRetentionClass`, `LawfulBasis`,
+ * `PersonalDataCategory`, `OperatorProcessingRole`), and both packages already depend on it.
+ *
+ * The alternative — a second, purpose-named cadence enum beside this one — was rejected. It would
+ * have carried four identical members and differed only by excluding `AS_NEEDED`, which is a
+ * CONSUMER's constraint rather than a different vocabulary. CLAUDE.md: a closed vocabulary has one
+ * named runtime source.
+ */
+export declare enum ReviewCadence {
+    WEEKLY = "WEEKLY",
+    MONTHLY = "MONTHLY",
+    QUARTERLY = "QUARTERLY",
+    YEARLY = "YEARLY",
+    /** A real answer meaning "no schedule" — never a default, and never a date. See {@link deriveNextReviewOn}. */
+    AS_NEEDED = "AS_NEEDED"
+}
+/**
+ * How many days one {@link ReviewCadence} member means.
+ *
+ * ONE home, promoted 2026-09-11 from two byte-identical module-local copies —
+ * `roadmap-snapshot-validation.ts` and `brand-snapshot-validation.ts`, the second of which said so in
+ * its own comment: *"module-local there too — a shared promotion is part of the deferred
+ * authored-metadata generalization"*. A third consumer is what made the deferral stop paying.
+ *
+ * `Record<ReviewCadence, number>` and not a partial: a member added to the enum is a compile error
+ * here rather than a silent `undefined` that reads as "no cadence" at every call site.
+ *
+ * `AS_NEEDED` is `POSITIVE_INFINITY` deliberately, so every consumer must decide what "no schedule"
+ * means for it rather than receiving a number that quietly schedules something. `Number.isFinite` is
+ * the guard each one uses.
+ */
+export declare const REVIEW_CADENCE_TO_DAYS: Record<ReviewCadence, number>;
+/**
+ * The next review date a cadence schedules from a given instant, or `undefined` when it schedules none.
+ *
+ * `undefined` for `AS_NEEDED` is the whole contract. A caller that needs a DATE must treat the absence
+ * as the answer — "this application has not committed to a review schedule" — and say so, rather than
+ * inventing one. Returning a far-future date instead would turn "no commitment" into a commitment
+ * nobody made, which is exactly the shape `.claude/rules/derive-before-you-ask.md` describes when a
+ * date stands in for a decision.
+ *
+ * Returns a plain ISO date (`YYYY-MM-DD`): a review is scheduled on a day, not at an instant.
+ */
+export declare function deriveNextReviewOn(fromInstant: string, cadence: ReviewCadence): string | undefined;
+//# sourceMappingURL=review-cadence.shared.schemas.d.ts.map

package/dist/esm/compliance/review-cadence.shared.schemas.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"review-cadence.shared.schemas.d.ts","sourceRoot":"","sources":["../../../../src/compliance/review-cadence.shared.schemas.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;GAkBG;AACH,oBAAY,aAAa;IACvB,MAAM,WAAW;IACjB,OAAO,YAAY;IACnB,SAAS,cAAc;IACvB,MAAM,WAAW;IACjB,+GAA+G;IAC/G,SAAS,cAAc;CACxB;AAED;;;;;;;;;;;;;;GAcG;AACH,eAAO,MAAM,sBAAsB,EAAE,MAAM,CAAC,aAAa,EAAE,MAAM,CAMhE,CAAC;AAEF;;;;;;;;;;GAUG;AACH,wBAAgB,kBAAkB,CAAC,WAAW,EAAE,MAAM,EAAE,OAAO,EAAE,aAAa,GAAG,MAAM,GAAG,SAAS,CAMlG"}

package/dist/esm/compliance/review-cadence.shared.schemas.js

@@ -0,0 +1,71 @@
+/**
+ * How often something is re-reviewed, and the date that cadence schedules.
+ *
+ * ## Why it lives HERE
+ *
+ * Moved from `@wildo-ai/saas-specifications` `_core/market/market-authored-metadata.schemas` on
+ * 2026-09-11, and re-exported from there so its six existing importers are untouched. It had to move
+ * because it gained a consumer on the other side of a package boundary: an application declares
+ * `assuranceReviewCadence` in `wildo.saas.config.ts`, which is validated by
+ * `@wildo-ai/platform-config-lib` — a contracts-only package that does not depend on
+ * `saas-specifications` and should not start depending on it for one enum. `saas-models` is where the
+ * application-declared compliance vocabularies already live (`DataRetentionClass`, `LawfulBasis`,
+ * `PersonalDataCategory`, `OperatorProcessingRole`), and both packages already depend on it.
+ *
+ * The alternative — a second, purpose-named cadence enum beside this one — was rejected. It would
+ * have carried four identical members and differed only by excluding `AS_NEEDED`, which is a
+ * CONSUMER's constraint rather than a different vocabulary. CLAUDE.md: a closed vocabulary has one
+ * named runtime source.
+ */
+export var ReviewCadence;
+(function (ReviewCadence) {
+    ReviewCadence["WEEKLY"] = "WEEKLY";
+    ReviewCadence["MONTHLY"] = "MONTHLY";
+    ReviewCadence["QUARTERLY"] = "QUARTERLY";
+    ReviewCadence["YEARLY"] = "YEARLY";
+    /** A real answer meaning "no schedule" — never a default, and never a date. See {@link deriveNextReviewOn}. */
+    ReviewCadence["AS_NEEDED"] = "AS_NEEDED";
+})(ReviewCadence || (ReviewCadence = {}));
+/**
+ * How many days one {@link ReviewCadence} member means.
+ *
+ * ONE home, promoted 2026-09-11 from two byte-identical module-local copies —
+ * `roadmap-snapshot-validation.ts` and `brand-snapshot-validation.ts`, the second of which said so in
+ * its own comment: *"module-local there too — a shared promotion is part of the deferred
+ * authored-metadata generalization"*. A third consumer is what made the deferral stop paying.
+ *
+ * `Record<ReviewCadence, number>` and not a partial: a member added to the enum is a compile error
+ * here rather than a silent `undefined` that reads as "no cadence" at every call site.
+ *
+ * `AS_NEEDED` is `POSITIVE_INFINITY` deliberately, so every consumer must decide what "no schedule"
+ * means for it rather than receiving a number that quietly schedules something. `Number.isFinite` is
+ * the guard each one uses.
+ */
+export const REVIEW_CADENCE_TO_DAYS = {
+    [ReviewCadence.WEEKLY]: 7,
+    [ReviewCadence.MONTHLY]: 31,
+    [ReviewCadence.QUARTERLY]: 92,
+    [ReviewCadence.YEARLY]: 366,
+    [ReviewCadence.AS_NEEDED]: Number.POSITIVE_INFINITY,
+};
+/**
+ * The next review date a cadence schedules from a given instant, or `undefined` when it schedules none.
+ *
+ * `undefined` for `AS_NEEDED` is the whole contract. A caller that needs a DATE must treat the absence
+ * as the answer — "this application has not committed to a review schedule" — and say so, rather than
+ * inventing one. Returning a far-future date instead would turn "no commitment" into a commitment
+ * nobody made, which is exactly the shape `.claude/rules/derive-before-you-ask.md` describes when a
+ * date stands in for a decision.
+ *
+ * Returns a plain ISO date (`YYYY-MM-DD`): a review is scheduled on a day, not at an instant.
+ */
+export function deriveNextReviewOn(fromInstant, cadence) {
+    const days = REVIEW_CADENCE_TO_DAYS[cadence];
+    if (!Number.isFinite(days))
+        return undefined;
+    const from = new Date(fromInstant);
+    if (Number.isNaN(from.getTime()))
+        return undefined;
+    return new Date(from.getTime() + days * 24 * 60 * 60 * 1000).toISOString().slice(0, 10);
+}
+//# sourceMappingURL=review-cadence.shared.schemas.js.map

package/dist/esm/compliance/review-cadence.shared.schemas.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"review-cadence.shared.schemas.js","sourceRoot":"","sources":["../../../../src/compliance/review-cadence.shared.schemas.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;GAkBG;AACH,MAAM,CAAN,IAAY,aAOX;AAPD,WAAY,aAAa;IACvB,kCAAiB,CAAA;IACjB,oCAAmB,CAAA;IACnB,wCAAuB,CAAA;IACvB,kCAAiB,CAAA;IACjB,+GAA+G;IAC/G,wCAAuB,CAAA;AACzB,CAAC,EAPW,aAAa,KAAb,aAAa,QAOxB;AAED;;;;;;;;;;;;;;GAcG;AACH,MAAM,CAAC,MAAM,sBAAsB,GAAkC;IACnE,CAAC,aAAa,CAAC,MAAM,CAAC,EAAE,CAAC;IACzB,CAAC,aAAa,CAAC,OAAO,CAAC,EAAE,EAAE;IAC3B,CAAC,aAAa,CAAC,SAAS,CAAC,EAAE,EAAE;IAC7B,CAAC,aAAa,CAAC,MAAM,CAAC,EAAE,GAAG;IAC3B,CAAC,aAAa,CAAC,SAAS,CAAC,EAAE,MAAM,CAAC,iBAAiB;CACpD,CAAC;AAEF;;;;;;;;;;GAUG;AACH,MAAM,UAAU,kBAAkB,CAAC,WAAmB,EAAE,OAAsB;IAC5E,MAAM,IAAI,GAAG,sBAAsB,CAAC,OAAO,CAAC,CAAC;IAC7C,IAAI,CAAC,MAAM,CAAC,QAAQ,CAAC,IAAI,CAAC;QAAE,OAAO,SAAS,CAAC;IAC7C,MAAM,IAAI,GAAG,IAAI,IAAI,CAAC,WAAW,CAAC,CAAC;IACnC,IAAI,MAAM,CAAC,KAAK,CAAC,IAAI,CAAC,OAAO,EAAE,CAAC;QAAE,OAAO,SAAS,CAAC;IACnD,OAAO,IAAI,IAAI,CAAC,IAAI,CAAC,OAAO,EAAE,GAAG,IAAI,GAAG,EAAE,GAAG,EAAE,GAAG,EAAE,GAAG,IAAI,CAAC,CAAC,WAAW,EAAE,CAAC,KAAK,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC;AAC1F,CAAC","sourcesContent":["/**\n * How often something is re-reviewed, and the date that cadence schedules.\n *\n * ## Why it lives HERE\n *\n * Moved from `@wildo-ai/saas-specifications` `_core/market/market-authored-metadata.schemas` on\n * 2026-09-11, and re-exported from there so its six existing importers are untouched. It had to move\n * because it gained a consumer on the other side of a package boundary: an application declares\n * `assuranceReviewCadence` in `wildo.saas.config.ts`, which is validated by\n * `@wildo-ai/platform-config-lib` — a contracts-only package that does not depend on\n * `saas-specifications` and should not start depending on it for one enum. `saas-models` is where the\n * application-declared compliance vocabularies already live (`DataRetentionClass`, `LawfulBasis`,\n * `PersonalDataCategory`, `OperatorProcessingRole`), and both packages already depend on it.\n *\n * The alternative — a second, purpose-named cadence enum beside this one — was rejected. It would\n * have carried four identical members and differed only by excluding `AS_NEEDED`, which is a\n * CONSUMER's constraint rather than a different vocabulary. CLAUDE.md: a closed vocabulary has one\n * named runtime source.\n */\nexport enum ReviewCadence {\n  WEEKLY = 'WEEKLY',\n  MONTHLY = 'MONTHLY',\n  QUARTERLY = 'QUARTERLY',\n  YEARLY = 'YEARLY',\n  /** A real answer meaning \"no schedule\" — never a default, and never a date. See {@link deriveNextReviewOn}. */\n  AS_NEEDED = 'AS_NEEDED',\n}\n\n/**\n * How many days one {@link ReviewCadence} member means.\n *\n * ONE home, promoted 2026-09-11 from two byte-identical module-local copies —\n * `roadmap-snapshot-validation.ts` and `brand-snapshot-validation.ts`, the second of which said so in\n * its own comment: *\"module-local there too — a shared promotion is part of the deferred\n * authored-metadata generalization\"*. A third consumer is what made the deferral stop paying.\n *\n * `Record<ReviewCadence, number>` and not a partial: a member added to the enum is a compile error\n * here rather than a silent `undefined` that reads as \"no cadence\" at every call site.\n *\n * `AS_NEEDED` is `POSITIVE_INFINITY` deliberately, so every consumer must decide what \"no schedule\"\n * means for it rather than receiving a number that quietly schedules something. `Number.isFinite` is\n * the guard each one uses.\n */\nexport const REVIEW_CADENCE_TO_DAYS: Record<ReviewCadence, number> = {\n  [ReviewCadence.WEEKLY]: 7,\n  [ReviewCadence.MONTHLY]: 31,\n  [ReviewCadence.QUARTERLY]: 92,\n  [ReviewCadence.YEARLY]: 366,\n  [ReviewCadence.AS_NEEDED]: Number.POSITIVE_INFINITY,\n};\n\n/**\n * The next review date a cadence schedules from a given instant, or `undefined` when it schedules none.\n *\n * `undefined` for `AS_NEEDED` is the whole contract. A caller that needs a DATE must treat the absence\n * as the answer — \"this application has not committed to a review schedule\" — and say so, rather than\n * inventing one. Returning a far-future date instead would turn \"no commitment\" into a commitment\n * nobody made, which is exactly the shape `.claude/rules/derive-before-you-ask.md` describes when a\n * date stands in for a decision.\n *\n * Returns a plain ISO date (`YYYY-MM-DD`): a review is scheduled on a day, not at an instant.\n */\nexport function deriveNextReviewOn(fromInstant: string, cadence: ReviewCadence): string | undefined {\n  const days = REVIEW_CADENCE_TO_DAYS[cadence];\n  if (!Number.isFinite(days)) return undefined;\n  const from = new Date(fromInstant);\n  if (Number.isNaN(from.getTime())) return undefined;\n  return new Date(from.getTime() + days * 24 * 60 * 60 * 1000).toISOString().slice(0, 10);\n}\n"]}

package/dist/esm/compliance/risk-posture.shared.schemas.d.ts

@@ -0,0 +1,161 @@
+import { z } from 'zod';
+/**
+ * The risk signals an APPLICATION may take a posture on (#300 Layer 2).
+ *
+ * ## Why only the application-evaluation signals
+ *
+ * `report-risk-signals.mjs` derives signals in two homes, and the split is load-bearing rather than
+ * organisational. FRAMEWORK_BUILD_TIME signals — marker density across the objective catalogue,
+ * objectives with no marker, objectives marked only outside production — are facts about the ENGINE
+ * and are identical for every application. An application cannot change them and does not choose
+ * them, so a declared posture about one would be an operator accepting somebody else's exposure.
+ * They inform; they are not accepted.
+ *
+ * APPLICATION_EVALUATION_TIME signals are facts about one application's own declarations, and every
+ * one of them is downstream of a choice its operator made. Those are the ones a posture is about.
+ *
+ * ## This enum is the SOURCE, and the derivation is held to it
+ *
+ * The refs were string literals inside the report. A second list here, free to drift from the one the
+ * script emits, is exactly the transcription defect the assurance anchoring rule exists to stop — so
+ * the report now parses this enum and refuses when the set it emits and the set declared here
+ * disagree, in EITHER direction. A signal added to the report with no member here fails; a member
+ * here that no signal emits fails too, because an application could otherwise declare a posture
+ * about an exposure nothing measures.
+ */
+export declare enum ApplicationRiskSignalRef {
+    /** Which engine capabilities are enabled, and therefore which exposures are structurally absent. */
+    CAPABILITY_SURFACE = "application:capability-surface",
+    /** Whether every retention class the vocabulary carries has a declared period. */
+    RETENTION_DECLARATION = "application:retention-declaration",
+    /** How many configured providers are vendor-hosted, each a third-party processor. */
+    PROVIDER_HOSTING = "application:provider-hosting",
+    /** Which personal-data categories this application's own resources declare, and whether any is special category. */
+    PERSONAL_DATA_INVENTORY = "application:personal-data-inventory",
+    /** Resources that have not answered the personal-data question at all. */
+    PERSONAL_DATA_DECLARATION_GAP = "application:personal-data-declaration-gap",
+    /** Operations reachable by an external agent over MCP. */
+    EXTERNAL_EXPOSURE_MCP = "application:external-exposure-mcp"
+}
+/**
+ * What an operator has DECIDED to do about an exposure.
+ *
+ * NIST SP 800-39 names the risk responses as accepting, avoiding, mitigating, sharing or
+ * transferring risk, and that set is what this enum takes — the options, not the spelling.
+ * spec-cite: NIST SP 800-39 / CSRC glossary, "risk response" — paraphrased from the published
+ * definition, not quoted.
+ *
+ * ## Only NIST is NAMED here, and that is a licensing line rather than a preference
+ *
+ * Other risk-management standards describe the same options and are LICENSED documents. Naming one
+ * in engine source would put a paid standard's identity into shipped code, which is why this
+ * repository's boundary rule keeps external framework names to rights-classified mapping and report
+ * surfaces. NIST publications are US government works, so citing one here costs nothing — and the
+ * practice is already settled: NIST is named in 34 engine and platform files.
+ *
+ * The options are borrowed either way. Being INSPIRED by a standard and NAMING it are different
+ * acts, and only the second carries a licence.
+ *
+ * ## No band, no score, no number — and that is inherited rather than chosen here
+ *
+ * Layer 1 emits signals carrying NO score, weight, level or severity, and asserts that prohibition
+ * structurally. A posture that arrived as a 1–5 appetite rating would put a number underneath a layer
+ * that refuses to produce one, and the number is what a reader trusts without checking. What an
+ * operator can honestly say about an exposure is which of these four they chose and why, so that is
+ * what the declaration carries.
+ *
+ * assurance-control: WILDO.RISK.TREATMENT_DECLARED — an operator's chosen treatment per exposure,
+ * with the reasoning, in a form a measurement can contradict.
+ *
+ * ## `AVOIDED` is the member that makes this layer worth having
+ *
+ * The other three are consistent with any measurement: an application that REDUCED, SHARED or
+ * ACCEPTED an exposure still has it, so the signal and the posture agree whatever the signal says.
+ * `AVOIDED` claims the exposure is not taken at all, which a Layer 1 signal can CONTRADICT — declare
+ * that vendor-hosted processing is avoided while two of three configured providers are vendor-hosted,
+ * and the two statements cannot both be true.
+ *
+ * That is the difference between this and a questionnaire answer. A free-text "describe your risk
+ * appetite" is unfalsifiable by construction; a typed posture beside a derived signal is a claim the
+ * product itself can disagree with.
+ */
+export declare enum RiskTreatmentPosture {
+    /**
+     * The application does not take this exposure at all.
+     *
+     * The only FALSIFIABLE posture — a signal reporting the exposure present contradicts it directly.
+     */
+    AVOIDED = "AVOIDED",
+    /** Taken, with controls that lower its likelihood or its consequence. */
+    REDUCED = "REDUCED",
+    /**
+     * Taken, with the consequence placed on another party by CONTRACT — an Art. 28 processor agreement
+     * being the case this framework can actually evidence.
+     *
+     * Narrower than "share or transfer" on purpose. Insurance-style transfer is a legitimate treatment
+     * and nothing in the product can attest it, so modelling it here would add a member no derivation
+     * could ever check. Naming the contractual case precisely is a smaller claim and a true one.
+     */
+    SHARED_BY_CONTRACT = "SHARED_BY_CONTRACT",
+    /** Taken, and the exposure retained knowingly. */
+    ACCEPTED = "ACCEPTED"
+}
+/**
+ * One signal's posture, and why.
+ *
+ * `rationale` is REQUIRED, for the same reason `dataRetention` requires one: a posture with no reason
+ * is a token, and the thing a reviewer needs is the sentence, not the enum member. "We accept it" is
+ * what the member already says.
+ *
+ * ## What is deliberately NOT here
+ *
+ * **No `decidedBy` and no `decidedAt`.** Acceptance is a COMMIT — `one-source-of-truth.md` rule 7 and
+ * D5 — so the author and the instant are already recorded, mergeably and by a history everyone
+ * audits. Fields restating them would be a second authority that can disagree with git, and they are
+ * exactly the shape that made an earlier compliance record unproducible without forging an identity.
+ *
+ * **No review date.** `derive-before-you-ask.md` settles this: a date is a PROXY for "an input may
+ * have changed", every input is in git and enumerable, so the trigger is computable and the date is
+ * an output rather than something to type.
+ */
+export declare const ApplicationRiskPostureEntrySchema: z.ZodObject<{
+    posture: z.ZodEnum<typeof RiskTreatmentPosture>;
+    rationale: z.ZodString;
+}, z.core.$strict>;
+export type ApplicationRiskPostureEntry = z.infer<typeof ApplicationRiskPostureEntrySchema>;
+/**
+ * An application's declared posture per risk signal — PARTIAL by construction.
+ *
+ * Every entry is optional and the whole declaration may be omitted. That is not laxity: a compliance
+ * workflow may never stand in front of the mechanism (`application-creation-directive.md`), and a
+ * required posture would make an application UNBUILDABLE until somebody decided something about
+ * every signal the framework happens to derive. The undeclared set is REPORTED instead, by
+ * {@link undeclaredRiskSignals}, which is the "mark it, do not block" shape that rule asks for.
+ *
+ * So absence is representable and means one thing — nobody has decided yet — and it is
+ * distinguishable from `ACCEPTED`, which means somebody decided to live with it. Collapsing those two
+ * is the failure this layer exists to avoid: silence is not acceptance.
+ */
+export declare const ApplicationRiskPostureSchema: z.ZodRecord<z.ZodEnum<typeof ApplicationRiskSignalRef>, z.ZodObject<{
+    posture: z.ZodEnum<typeof RiskTreatmentPosture>;
+    rationale: z.ZodString;
+}, z.core.$strict>>;
+export type ApplicationRiskPosture = z.infer<typeof ApplicationRiskPostureSchema>;
+/**
+ * The signals an application has declared NO posture for — what a register must mark as owed.
+ *
+ * Derived rather than stored, and total over the enum, so a signal added to the vocabulary tomorrow
+ * is reported as undeclared by every existing application rather than silently omitted from the
+ * answer. Deliberately the same shape as `undeclaredRetentionClasses`, because it is the same
+ * question one layer over.
+ */
+export declare function undeclaredRiskSignals(posture: ApplicationRiskPosture | undefined): readonly ApplicationRiskSignalRef[];
+/**
+ * Postures that CLAIM AN EXPOSURE IS NOT TAKEN — the ones a measurement can contradict.
+ *
+ * Exported rather than inlined at the one call site, so the report and any later consumer ask the
+ * same question. Today it is `AVOIDED` alone; if a future member is also falsifiable it joins here
+ * and every consumer follows, which is the whole reason this is a function and not a comparison.
+ */
+export declare function riskPostureClaimsExposureAbsent(entry: ApplicationRiskPostureEntry | undefined): boolean;
+//# sourceMappingURL=risk-posture.shared.schemas.d.ts.map

package/dist/esm/compliance/risk-posture.shared.schemas.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"risk-posture.shared.schemas.d.ts","sourceRoot":"","sources":["../../../../src/compliance/risk-posture.shared.schemas.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AAExB;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AACH,oBAAY,wBAAwB;IAClC,oGAAoG;IACpG,kBAAkB,mCAAmC;IACrD,kFAAkF;IAClF,qBAAqB,sCAAsC;IAC3D,qFAAqF;IACrF,gBAAgB,iCAAiC;IACjD,oHAAoH;IACpH,uBAAuB,wCAAwC;IAC/D,0EAA0E;IAC1E,6BAA6B,8CAA8C;IAC3E,0DAA0D;IAC1D,qBAAqB,sCAAsC;CAC5D;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAyCG;AACH,oBAAY,oBAAoB;IAC9B;;;;OAIG;IACH,OAAO,YAAY;IACnB,yEAAyE;IACzE,OAAO,YAAY;IACnB;;;;;;;OAOG;IACH,kBAAkB,uBAAuB;IACzC,kDAAkD;IAClD,QAAQ,aAAa;CACtB;AAED;;;;;;;;;;;;;;;;;GAiBG;AACH,eAAO,MAAM,iCAAiC;;;kBAO5C,CAAC;AAEH,MAAM,MAAM,2BAA2B,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,iCAAiC,CAAC,CAAC;AAE5F;;;;;;;;;;;;GAYG;AACH,eAAO,MAAM,4BAA4B;;;mBAGxC,CAAC;AAEF,MAAM,MAAM,sBAAsB,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,4BAA4B,CAAC,CAAC;AAElF;;;;;;;GAOG;AACH,wBAAgB,qBAAqB,CACnC,OAAO,EAAE,sBAAsB,GAAG,SAAS,GAC1C,SAAS,wBAAwB,EAAE,CAErC;AAED;;;;;;GAMG;AACH,wBAAgB,+BAA+B,CAAC,KAAK,EAAE,2BAA2B,GAAG,SAAS,GAAG,OAAO,CAEvG"}