Docs: session log Part E — planar Y-lock fix record

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Assets/_Project/Scripts/Simulation/Player/CharacterProcessor.cs

@@ -34,6 +34,7 @@ namespace ProjectM.Simulation
             ref CharacterComponent characterComponent = ref CharacterComponent.ValueRW;
             ref KinematicCharacterBody characterBody = ref CharacterDataAccess.CharacterBody.ValueRW;
             ref float3 characterPosition = ref CharacterDataAccess.LocalTransform.ValueRW.Position;
+            float planeY = characterPosition.y; // authored movement plane — restored after the update (see below)
 
             KinematicCharacterUtilities.Update_Initialize(
                 in this, ref context, ref baseContext,
@@ -100,6 +101,14 @@ namespace ProjectM.Simulation
             KinematicCharacterUtilities.Update_ProcessStatefulCharacterHits(
                 CharacterDataAccess.CharacterHitsBuffer,
                 CharacterDataAccess.StatefulHitsBuffer);
+
+            // Top-down planar lock: the world is one flat plane and gravity is zero, so any Y gained by
+            // step-handling/velocity-projection up a sloped collider (convex rock hulls etc.) would persist
+            // FOREVER — the character ends up floating and its shadow drifts away (07-09 field report).
+            // Restoring the pre-update Y forbids the CC update itself from ever changing the plane while
+            // spawn/teleport writes (made outside this update) stay honored. Deterministic + idempotent.
+            characterPosition.y = planeY;
+            characterBody.RelativeVelocity.y = 0f;
         }
 
         void HandleVelocityControl(ref CharacterUpdateContext context, ref KinematicCharacterUpdateContext baseContext)

Docs/Vault/07_Sessions/2026/2026-07-09_B4d_Tail_Collision_Grounding.md

@@ -130,6 +130,20 @@ climbable/hilly in a way that lets the player phase through. Commit after verifi
   parity 323, enemy smoke in the dense room (embedded-in-crater enemy depenetrated + re-engaged across ~12 u;
   4 others converged through ~40 obstacles), 466/466 EditMode, console clean.
 
+## Part E — field report: player climbs sloped colliders and floats (fixed `c58a17b8a`)
+
+Operator playtest: "player height gets messed with going on hilly things; the shadow keeps getting visually
+farther after going on top." Mechanism: the top-down CC has **zero gravity + SnapToGround off**, and the CC
+sequence runs step-handling + slope velocity-projection — walking into a SLOPED collider (the new convex rock
+hulls are ramps; boxes are safe) deflects the capsule UP, and the gained Y persists forever → floating
+character, receding blob shadow. **Fix = a planar Y-lock inside `CharacterProcessor.PhysicsUpdate`:** capture
+the pre-update Y, restore it + zero `RelativeVelocity.y` after the CC sequence. The character update can never
+change the movement plane; spawn/teleport writes (outside the update) stay honored. Deterministic + idempotent
+→ rollback-safe, identical server + predicted client. **Invariant for the vault: on this project the player's
+plane is Y=1 (GridOrigin capsule-center plane) and ONLY spawn/teleport code may set Y — collider shapes can be
+arbitrarily sloped now.** Verified live (guardian): player shoved into a cover-hull sloped edge decollided
+~1 u horizontally with Y bit-exact 1.0000 across 4.5 s; 466/466; console clean.
+
 ## Next-session intent
 
 Phase 1.5 continues: lighting/atmosphere pass → art-look decision gate (pixel filter ON/OFF side-by-sides).