diff --git a/Docs/Vault/07_Sessions/2026/2026-06-10_MC4_Melee_Anim_VFX_Archetype.md b/Docs/Vault/07_Sessions/2026/2026-06-10_MC4_Melee_Anim_VFX_Archetype.md
index 150285760..9b620f56f 100644
--- a/Docs/Vault/07_Sessions/2026/2026-06-10_MC4_Melee_Anim_VFX_Archetype.md
+++ b/Docs/Vault/07_Sessions/2026/2026-06-10_MC4_Melee_Anim_VFX_Archetype.md
@@ -45,7 +45,7 @@ Built the thing DR-030 deferred — minimally + correctly per the MC-4 review's
 ## Follow-up fixes (operator review, same day)
 Operator: *"clicking melee makes half the player model sink into the floor — also happens with enemies. Fix it + prevent it in future. Also add the same clarity to enemy attacks (can't tell range/hitbox/when to dodge)."*
 
-1. **The attack-animation sink — ROOT CAUSE + fix (player AND enemy).** The procedural attack clips key ONLY the `Root` bone's rotation, but the Attack/MeleeSwing states had **`writeDefaultValues = true`**. The `Root` bone carries the rig's mesh-positioning offset (Player.prefab `Root` localPosition = `(0, -0.90, 0)`, identity rotation) and the `Hips`/`Spine` carry big authored orientations `(0,270,278)`/`(0,180,191)`. With WDV=true a **partial** (Root-only) clip resets EVERY un-keyed bone to Rukhanka's defaults (~identity) → the body collapses/folds into the floor; the locomotion clips never hit this because they key the full skeleton. **Fix: `writeDefaultValues = false` on the attack states** (a partial clip must leave un-keyed bones in their pose and only lean the `Root`). Patched both `AC_PlayerTopDown` (MeleeSwing) + `AC_EnemyTopDown` (Attack) AND both recipes (`PlayerRigTools`/`EnemyRigTools`) so a rebuild can't regress it. Play-verified: the forced MeleeSwing pose stands intact (no sink). **General rule for future procedural overlay clips: partial Root/bone-subset clips ⇒ `writeDefaultValues = false`.**
+1. **The attack-animation sink — ROOT CAUSE + fix (player AND enemy).** The procedural attack clips keyed ONLY the `Root` bone. In **Rukhanka, a partial clip (a subset of bones) forces every UN-KEYED bone to ~identity for the duration of the state** — so the `Hips`/`Spine`/legs (which carry big authored orientations `(0,270,278)`/`(0,180,191)`) collapse and the body folds halfway into the floor. The locomotion clips never hit this because they key the full skeleton. **`writeDefaultValues=false` does NOT fix it** — first wrong guess; it was *confirmed* wrong because even a pure-**yaw** clip (a vertical-axis, geometrically height-preserving rotation) STILL sank → the sink was never the Root rotation, it was the un-keyed-bone collapse. **Correct fix: build the attack clip FROM the full idle pose (copy every idle bone curve so nothing is un-keyed) + drive ONLY the `Root` with a yaw twist on top.** Applied to both runtime clips (`PlayerMeleeSwing`/`EnemyAttackWindup`) and both recipes (`PlayerRigTools`/`EnemyRigTools`). **Operator-verified** (left-click in Play — no sink). **General rule: a Rukhanka overlay/partial animation must key the full skeleton (base it on a full-body pose) — a bone-subset clip collapses the rest, regardless of `writeDefaultValues`.** *(Process note: my screenshots + `WorldRenderBounds`/bone measurements all read the static/bind AABB, NOT Rukhanka's GPU-deformed pose — they showed "upright" while the mesh was visibly sunk. For Rukhanka-deformed visual bugs, the operator's eyes are the oracle.)*
 2. **Enemy attack telegraph (the same clarity).** `CombatFeedbackSystem.UpdateEnemyDanger` paints a red ground **danger cone** at each enemy while its `AttackWindup` counts down — oriented along the enemy's facing, sized to `EnemyStats.AttackRange`, brightening + scaling as the strike nears (`intensity = 1 - ticksRemaining/22`) so the player reads WHERE + WHEN to dodge. Client-only observe-only, one pooled mesh/enemy keyed by Entity, pruned each frame (same idiom as the projectile trails + the player slash-arc). Play-verified: 14-enemy wave, 8 telegraphs rendering at once, zero console errors. Cone size/colour/intensity are tunable in the system.
 
 ## Links