@@ -9,6 +9,18 @@ this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.htm
 
 ### Fixed — parent-side `relationship.composition` reaches the child's FK (migrate-ts; ADR-0047)
 
+> **ADOPTER-VISIBLE MIGRATION — production delete semantics change.** After
+> upgrading, the first `meta migrate` against a live database emits a one-time
+> migration **adding `ON DELETE CASCADE` (or the relationship's declared/default
+> action) to FKs whose parent-side relationship was previously silently
+> ignored** — deleting a parent row then deletes its children instead of
+> failing. This is the documented semantic the metadata always declared, but it
+> was never enforced, so review that migration deliberately; pin
+> `@onDelete: "no-action"` on any relationship whose DB behavior you want kept.
+> The same applies to a child-side relationship authored with an FQN
+> `@objectRef`, which the old exact-string correlation silently missed.
+> Give this entry top billing at cut time.
+
 The authoring the docs and the `metaobjects-authoring` skill teach — declaring the
 relationship on the PARENT (`relationship.composition { @objectRef: "Post",
 @cardinality: "many" }` on `Author`, with the subtype implying the default action) —
@@ -18,14 +30,21 @@ relationships declared on the FK-owning child, so the documented "composition
 FK violation at runtime. The resolver now correlates the **reverse relationship on the
 target entity** as a third precedence tier (reference-level attr → child-side
 relationship → parent-side relationship; each relationship contributing its explicit
-action, else its subtype default). Guards, each failing closed: an M:N (`@through`)
-relationship never correlates with a direct FK; a reverse relationship contributes
-nothing when the child holds more than one enforced reference to the same target
-(it cannot say which FK carries the ownership edge); and an INFERRED set-null default
-(parent-side aggregation, no explicit `@onDelete`) on a NOT NULL FK contributes
-nothing rather than turning a previously-valid model into a hard
-`SetNullNotNullableError` (an explicit `set-null` still errors loudly). Models with no
-parent-side relationship are byte-identical. The Kotlin Exposed table generator's
+action, else its subtype default). Tier-2 correlation is now **package-aware**
+(`refMatchesObject` / ADR-0042) and excludes M:N `@through` relationships — an FQN
+child-side `@objectRef` previously missed the exact-string match and contributed
+nothing (post-fix it would otherwise have been OVERRIDDEN by the parent side), and a
+`@through` relationship wrongly armed cascade on a sibling direct FK to the same
+target. Guards on the new reverse tier, each failing closed: the M:N exclusion; a
+reverse relationship contributes nothing unless the child holds exactly one enforced
+reference to the target (it cannot say which FK carries the ownership edge); and an
+INFERRED set-null default (parent-side aggregation, no explicit `@onDelete`) on a NOT
+NULL FK drops its inferred contributions rather than turning a previously-valid model
+into a hard `SetNullNotNullableError` — while an explicitly authored `set-null` still
+errors loudly and an explicitly authored `@onUpdate` on that same relationship is
+still honored. Models whose FKs already resolved an action are byte-identical; the
+two intentional output changes both restore declared intent that was silently
+dropped. The Kotlin Exposed table generator's
 decorated `identity.reference` columns now resolve actions with the same precedence
 (they previously emitted raw relationship attrs only, and the canonical
 parent-relationship + child-reference shape lost the action entirely through the
 
@@ -117,14 +117,19 @@ action, highest first:
    relationship node) or on an **M:N junction's** FK sides (no relationship
    ever correlates with a junction FK).
 2. A relationship declared on the FK-owning (child) entity targeting the
-   referenced entity: its explicit action, else its subtype default.
+   referenced entity (matched package-aware, so bare and FQN spellings pair
+   correctly; an M:N `@through` relationship never correlates with a direct
+   FK): its explicit action, else its subtype default.
 3. A relationship declared on the **referenced (parent) entity** pointing back
    at the FK-owning entity — the canonical parent-side authoring above
    (`Author` declares `posts`): its explicit action, else its subtype default.
-   Guards: an M:N (`@through`) relationship never correlates with a direct FK,
-   and when the child holds more than one FK to the same parent the parent-side
-   relationship contributes to none of them (it cannot say which FK carries the
-   ownership edge).
+   Guards: the M:N exclusion again; when the child holds more than one FK to
+   the same parent the parent-side relationship contributes to none of them
+   (it cannot say which FK carries the ownership edge); and an inferred
+   set-null default (aggregation, no explicit `@onDelete`) on a NOT NULL FK
+   contributes nothing — SET NULL cannot fire there (an explicit `set-null`
+   instead fails migration generation loudly, telling you to make the FK
+   nullable).
 4. None of the above → the FK is emitted with no `ON DELETE` / `ON UPDATE`
    clause (SQL `NO ACTION`).
 
 
@@ -1382,39 +1382,53 @@ open class KotlinExposedTableGenerator : MultiFileDirectGeneratorBase<MetaObject
             rel.through == null && rel.objectRef != null &&
                 KotlinGenUtil.resolveObjectByShortOrFqn(loader, rel.objectRef) === target
         }
-        var rel = childSide ?: findReverseRelationship(loader, entity, target)
-
-        // Tier-3 satisfiability guard (mirrors TS resolveReferentialActions): an
-        // INFERRED set-null default (parent-side aggregation, no explicit @onDelete)
-        // is unsatisfiable on a NOT NULL FK column — the correlation contributes
-        // nothing rather than emitting a ReferenceOption the database would reject.
-        // An EXPLICIT set-null still flows through (the author asked for it).
-        if (childSide == null && rel != null && rel.onDeleteRaw == null &&
-            MetaRelationship.ON_DELETE_DEFAULT_BY_SUBTYPE[rel.subType] == MetaRelationship.ACTION_SET_NULL
-        ) {
-            val fkField = ref.fields.singleOrNull()?.let { fn ->
-                entity.metaFields.firstOrNull { it.name == fn }
+        var rel = childSide
+        // When the tier-3 satisfiability guard fires, the reverse relationship's
+        // AUTHORED @onUpdate still applies (only the inferred contributions drop).
+        var suppressedReverseOnUpdate: String? = null
+        if (rel == null) {
+            val reverse = findReverseRelationship(loader, entity, ref, target)
+            if (reverse != null) {
+                // Tier-3 satisfiability guard (mirrors TS resolveReferentialActions):
+                // an INFERRED set-null default (parent-side aggregation, no explicit
+                // @onDelete) is unsatisfiable on a NOT NULL FK column — the INFERRED
+                // contributions drop rather than emitting a ReferenceOption the
+                // database would reject, while anything explicitly authored survives
+                // (an explicit set-null flows through; an explicit @onUpdate is
+                // honored rather than silently discarded with the guard).
+                val fkField = ref.fields.singleOrNull()?.let { fn ->
+                    entity.metaFields.firstOrNull { it.name == fn }
+                }
+                val unsatisfiableInferredSetNull = reverse.onDeleteRaw == null &&
+                    MetaRelationship.ON_DELETE_DEFAULT_BY_SUBTYPE[reverse.subType] == MetaRelationship.ACTION_SET_NULL &&
+                    fkField != null && KotlinGenUtil.isRequiredField(fkField)
+                if (unsatisfiableInferredSetNull) {
+                    suppressedReverseOnUpdate = reverse.onUpdateRaw
+                } else {
+                    rel = reverse
+                }
             }
-            if (fkField != null && KotlinGenUtil.isRequiredField(fkField)) rel = null
         }
 
         val onDelete = refOnDelete
             ?: rel?.let { it.onDeleteRaw ?: MetaRelationship.ON_DELETE_DEFAULT_BY_SUBTYPE[it.subType] }
         val onUpdate = refOnUpdate
-            ?: rel?.let { it.onUpdateRaw ?: MetaRelationship.ON_UPDATE_DEFAULT }
+            ?: (rel?.let { it.onUpdateRaw ?: MetaRelationship.ON_UPDATE_DEFAULT } ?: suppressedReverseOnUpdate)
         return onDelete to onUpdate
     }
 
     /**
      * ADR-0047 tier-3 correlation — the relationship declared on the TARGET (parent)
      * entity pointing back at the FK-owning entity. Fails closed (null) when the
-     * relationship is M:N (`@through`), or when [entity] holds more than one enforced
-     * reference to [target] (the reverse relationship cannot say which FK carries the
-     * ownership edge). Mirrors the TS migrate engine's findReverseRelationship.
+     * relationship is M:N (`@through`), or when [entity] does not hold exactly one
+     * enforced reference to [target] that is [ref] itself (the reverse relationship
+     * cannot say which FK carries the ownership edge; a soft `@enforce: false` ref
+     * never correlates). Mirrors the TS migrate engine's findReverseRelationship.
      */
     private fun findReverseRelationship(
         loader: MetaDataLoader,
         entity: MetaObject,
+        ref: ReferenceIdentity,
         target: MetaObject,
     ): MetaRelationship? {
         // ADR-0039: identity.reference children are inheritable — RESOLVE via getIdentities(true).
@@ -1424,7 +1438,7 @@ open class KotlinExposedTableGenerator : MultiFileDirectGeneratorBase<MetaObject
                 r.isEnforced && r.targetEntity != null &&
                     KotlinGenUtil.resolveObjectByShortOrFqn(loader, r.targetEntity) === target
             }
-        if (enforcedRefsToTarget.size != 1) return null
+        if (enforcedRefsToTarget.singleOrNull() !== ref) return null
         return target.relationships.firstOrNull { rel ->
             rel.through == null && rel.objectRef != null &&
                 KotlinGenUtil.resolveObjectByShortOrFqn(loader, rel.objectRef) === entity
 
@@ -51,10 +51,12 @@ export function isRequired(field: MetaData): boolean {
  * Precedence (highest first):
  *   1. @onDelete / @onUpdate declared DIRECTLY on the identity.reference — the
  *      reference IS the FK, so the action may be declared right where the FK is.
- *   2. A correlated sibling relationship on the same entity (matched on
- *      target-entity name): its explicit @onDelete, else its subtype default
- *      (composition→cascade, aggregation→set-null, association→restrict);
- *      onUpdate defaults to "cascade".
+ *   2. A correlated sibling relationship on the same entity — matched
+ *      package-aware against the resolved @references target (refMatchesObject
+ *      / ADR-0042, so bare and FQN forms pair correctly); an M:N relationship
+ *      (@through) never correlates with a direct FK. Its explicit @onDelete,
+ *      else its subtype default (composition→cascade, aggregation→set-null,
+ *      association→restrict); onUpdate defaults to "cascade".
  *   3. A correlated REVERSE relationship on the TARGET entity — the documented
  *      parent-side authoring shape ("Program owns weeks": composition declared
  *      on the parent with @objectRef back at this FK-owning entity). Same
@@ -65,8 +67,9 @@ export function isRequired(field: MetaData): boolean {
  *      relationship contributes nothing (it cannot say which FK carries the
  *      ownership edge — arming all of them could cascade through an edge the
  *      author never designated; fail closed); and an INFERRED set-null default
- *      (parent-side aggregation, no explicit @onDelete) on a NOT NULL FK also
- *      contributes nothing (unsatisfiable — see the in-body guard comment).
+ *      (parent-side aggregation, no explicit @onDelete) on a NOT NULL FK drops
+ *      the INFERRED contributions only — an authored @onUpdate on that same
+ *      relationship still applies (see the in-body guard comment).
  *   4. None → undefined (no ON DELETE / ON UPDATE clause).
  *
  * - Resolved "no-action" → undefined: introspection in introspect/{postgres,sqlite}.ts
@@ -89,47 +92,69 @@ export function resolveReferentialActions(
   const target = ref.targetEntity;
   if (target === undefined) return { onDelete: undefined, onUpdate: undefined };
 
-  // Correlation is by exact-string match. Every fixture in the corpus uses
-  // bare entity names for @objectRef and @references (no `::`-FQN form), so
-  // bare-vs-bare matching is sufficient today. If a future author writes an
-  // FQN value on either side, this find returns undefined and both actions
-  // resolve to undefined (no clause emitted) — surfacing the mismatch as a
-  // silent loss of intent rather than a wrong action. Cross-language ports
-  // should match the same correlation rule.
   // (1) Actions declared directly on the FK-defining reference win.
   const refOnDelete = ref.onDelete;
   const refOnUpdate = ref.onUpdate;
 
+  // Resolve the reference's target ONCE, package-aware (ADR-0042: a bare
+  // @references resolves in the DECLARING owner's package). Both relationship
+  // tiers then correlate against the resolved node with refMatchesObject, so a
+  // bare @references pairs correctly with an FQN @objectRef (and vice versa) —
+  // an exact-string tier 2 used to miss the FQN form, letting the parent-side
+  // tier override a child-side declaration.
+  const root = entity.parent;
+  const refOwner = ref.parent ?? entity;
+  const refOwnerPkg = refOwner.package ?? refOwner.fileDefaultPackage ?? "";
+  const targetObj =
+    root !== undefined ? (resolveObjectRef(root, target, refOwnerPkg).node as MetaObject | undefined) : undefined;
+
   // (2) Otherwise correlate with a sibling relationship and use its action /
   //     subtype default. onUpdate's "cascade" default only applies when a
   //     relationship is present, so a reference-only FK with no explicit
-  //     @onUpdate emits no ON UPDATE clause.
+  //     @onUpdate emits no ON UPDATE clause. An M:N relationship (@through)
+  //     never correlates — it describes the junction path, not this direct FK.
+  //     When the target does not resolve (dangling @references — normally a
+  //     load error), fall back to the legacy exact-string match so behavior on
+  //     partially-valid trees is unchanged.
   // (3) Failing that, correlate the REVERSE relationship declared on the
   //     TARGET entity (the documented parent-side authoring shape).
-  let rel = entity.relationships().find((r) => r.objectRef === target);
-  if (rel === undefined) {
-    const reverse = findReverseRelationship(entity, ref, target);
+  let rel = entity.relationships().find((r) => {
+    if (r.through !== undefined) return false;
+    const objectRef = r.objectRef;
+    if (objectRef === undefined) return false;
+    if (targetObj === undefined) return objectRef === target;
+    const relOwner = r.parent ?? entity;
+    const relOwnerPkg = relOwner.package ?? relOwner.fileDefaultPackage ?? "";
+    return refMatchesObject(targetObj, objectRef, relOwnerPkg);
+  });
+  // When the tier-3 satisfiability guard fires, the reverse relationship's
+  // AUTHORED @onUpdate still applies (only the inferred contributions drop).
+  let suppressedReverseOnUpdate: string | undefined;
+  if (rel === undefined && targetObj !== undefined) {
+    const reverse = findReverseRelationship(entity, ref, targetObj);
     // Tier-3 satisfiability guard: an INFERRED set-null default (a parent-side
     // aggregation with no explicit @onDelete) is unsatisfiable when any FK
     // column is NOT NULL — SET NULL cannot fire there, and letting it through
     // would turn a previously-valid model into a hard SetNullNotNullableError
     // purely because the correlation got smarter. An inferred default never
-    // breaks a model: the correlation contributes nothing (today's bare FK).
-    // An EXPLICIT @onDelete: "set-null" on the reverse relationship still flows
-    // through and hits the loud validateSetNullNullability error — the author
-    // asked for it, so silently dropping it would be the original bug again.
-    if (
-      reverse !== undefined &&
-      !(
+    // breaks a model: the INFERRED contributions drop (today's bare FK), while
+    // anything the author explicitly wrote survives — an EXPLICIT @onDelete:
+    // "set-null" flows through and hits the loud validateSetNullNullability
+    // error (the author asked for it), and an EXPLICIT @onUpdate is honored
+    // (silently dropping it would be the original bug again).
+    if (reverse !== undefined) {
+      const unsatisfiableInferredSetNull =
         reverse.onDelete === undefined &&
         ON_DELETE_DEFAULT_BY_SUBTYPE[reverse.subType] === "set-null" &&
         readIdentityFields(ref).some((jsName) => {
           const field = findField(entity, jsName);
           return field !== undefined && isRequired(field);
-        })
-      )
-    ) {
-      rel = reverse;
+        });
+      if (unsatisfiableInferredSetNull) {
+        suppressedReverseOnUpdate = reverse.onUpdate;
+      } else {
+        rel = reverse;
+      }
     }
   }
 
@@ -138,7 +163,7 @@ export function resolveReferentialActions(
     (rel ? (rel.onDelete ?? ON_DELETE_DEFAULT_BY_SUBTYPE[rel.subType]) : undefined);
   const onUpdateRaw =
     refOnUpdate ??
-    (rel ? (rel.onUpdate ?? ON_UPDATE_DEFAULT) : undefined);
+    (rel ? (rel.onUpdate ?? ON_UPDATE_DEFAULT) : suppressedReverseOnUpdate);
 
   return {
     onDelete: normalize(onDeleteRaw),
@@ -153,12 +178,9 @@ export function resolveReferentialActions(
  * "Post", @cardinality: "many" }` on Author, while Post owns the FK).
  *
  * Guards (each fails closed to "no contribution"):
- * - The target entity must resolve from the root (package-aware via
- *   resolveObjectRef; the reference's declaring owner supplies the package
- *   context, mirroring the loader's ADR-0042 contract).
  * - An M:N relationship (`@through`) never correlates — it describes the
  *   junction path, not this direct FK (the junction's own FKs correlate via
- *   its own identity.reference children).
+ *   its own identity.reference children). The same guard applies at tier 2.
  * - When the FK-owning entity holds more than one enforced reference to the
  *   same target, the reverse relationship cannot say WHICH FK carries the
  *   ownership edge, so it contributes to none of them (arming every FK could
@@ -170,18 +192,11 @@ export function resolveReferentialActions(
 function findReverseRelationship(
   entity: MetaObject,
   ref: MetaReferenceIdentity,
-  target: string,
+  targetObj: MetaObject,
 ): MetaRelationship | undefined {
   const root = entity.parent;
   if (root === undefined) return undefined;
 
-  // ADR-0042: a bare @references resolves in the DECLARING owner's package (an
-  // inherited reference resolves in the package that declared it).
-  const refOwner = ref.parent ?? entity;
-  const refOwnerPkg = refOwner.package ?? refOwner.fileDefaultPackage ?? "";
-  const targetObj = resolveObjectRef(root, target, refOwnerPkg).node;
-  if (targetObj === undefined) return undefined;
-
   // Ambiguity guard: exactly one enforced reference from `entity` to this
   // target, and it must be `ref` itself.
   const refsToTarget = entity.referenceIdentities().filter((r) => {
@@ -196,7 +211,7 @@ function findReverseRelationship(
 
   // The reverse relationship's bare @objectRef resolves in ITS declaring
   // owner's package (normally the target entity's own package).
-  return (targetObj as MetaObject).relationships().find((r) => {
+  return targetObj.relationships().find((r) => {
     if (r.through !== undefined) return false; // M:N — junction path, not this FK
     const objectRef = r.objectRef;
     if (objectRef === undefined) return false;