acdream/docs/research/2026-08-06-32-local-edge-slide-research.md

Issue #32 (local half) — the player runs off cliff edges instead of stopping or sliding

OUTCOME 2026-08-07 — Section 6's capture landed in decision-table ROW 1 verbatim (six branch2/steep-cliffslide events at Rithwic, every one curN == lastN == (-0.954, 0.000, 0.301), angle=0.0000, apply=False, outcome degenerate-cross/last-known), the Section 7 fix shipped at 332045c7, and the user passed it live: "Yes works now." One caveat for the record: the first live "test" of the fix ran a stale checkout's binary and produced a void failure verdict — see the #32 entries in docs/ISSUES.md for that detour and the assembly-identity rule it produced. Section 3.5's cell-id note is now register row AD-67; its blast-radius items are carried as watch items on Campaign S slice S4.

Date: 2026-08-06 Mode: research / report-only. No production or test code was written or changed. Worktree: .claude/worktrees/peaceful-visvesvaraya-e0a196, branch claude/acdream-physics-divergence-5aa784.

---

0. Git state caveat (read first)

git fetch github succeeded; git merge --ff-only github/main was refused — this branch is diverged (1 ahead / 5 behind: it carries local commit 5c93c2c5, which is not in github/main). Per instruction nothing else was done to git.

That matters only if the five missing commits touch what this report analyses. They do not. git diff --name-only HEAD github/main over the analysed sources returns no hits for TransitionTypes.cs, PhysicsEngine.cs, FlatBspQuery.cs, BSPQuery.cs, PlayerMovementController.cs, or RetailEdgeResponseOrderingTests.cs. The only doc deltas are new rows for #333/#334 and AP-152/AP-156/AP-158; #32's own text is byte-identical between HEAD and github/main. Every source claim below therefore holds at github/main.

Retail binary verified before any disassembly:

py tools/pdb-extract/check_exe_pdb.py "C:/Users/erikn/Downloads/acclient.exe"
  GUID = {9e847e2f-777c-4bd9-886c-22256bb87f32}
  === MATCH: this exe pairs with our acclient.pdb ===

Every address cited below was resolved back to a name in docs/research/named-retail/symbols.json before being used, and every function body was bounded by finding its own ret before the next symbol. Address / symbol pairs confirmed this way:

Address	PDB symbol
0x00509d80	COLLISIONINFO::set_contact_plane
0x0050a6d0	CTransition::cliff_slide
0x0050a880	SPHEREPATH::save_check_pos
0x0050b100	SPHEREPATH::restore_check_pos
0x0050b2a0	CTransition::step_down
0x0050b3d0	CTransition::edge_slide
0x0050b6f0	CTransition::transitional_insert
0x0050aa70	CTransition::validate_transition
0x0050cc80	SPHEREPATH::precipice_slide
0x0050cf20	OBJECTINFO::get_walkable_z
0x0050e850	CTransition::init_contact_plane
0x0050e8e0	CTransition::init_last_known_contact_plane
0x00511cc0	CPhysicsObj::get_object_info

---

1. Executive answer

The digest does not already carry #32's local half. claude-memory/project_physics_collision_digest.md mentions PrecipiceSlide three times, all in other sagas (#185's DO-NOT-RETRY, #116's residual, the step-down/step-up seam notes). There is no recorded characterisation of the local-player cliff case. This is not a #331-style rediscovery.

What retail does at a walkable edge is a four-stage chain inside one CTransition::transitional_insert attempt: probe down → if the probe finds no walkable support, run edge_slide → edge_slide picks exactly one of four responses in a fixed order → the winning response either laterally displaces the candidate (you glide along the rim) or refuses it outright (you stop). Section 2 decodes it, disassembly-verified.

acdream implements every stage of that chain, for the local player, with the correct branch order and the correct retail flags. The mover-flag theory is dead: PlayerMovementController passes ObjectInfoState.IsPlayer | EdgeSlide | OwnPvpFlags (src/AcDream.Runtime/Gameplay/PlayerMovementController.cs:2661) and PhysicsEngine.ResolveWithTransition sets ObjectInfo.StepDown = true unconditionally (src/AcDream.Core/Physics/PhysicsEngine.cs:1919).

The one divergence I found is real, is disassembly-proven, and sits exactly on the branch that produces "slide along the cliff edge". CollisionInfo.SetContactPlane (TransitionTypes.cs:446-480) latches the last-known contact plane on every write. Retail's COLLISIONINFO::set_contact_plane (0x00509d80) does not touch last-known at all. The consequence is that by the time CliffSlide reads LastKnownContactPlane.Normal as its reference vector, that vector has already been overwritten with the same steep normal it is being crossed against — so the cross product is exactly zero, CliffSlide takes its degenerate OK return, edge_slide reports "did not stop", and the outer retry loop accepts the candidate that hangs over the drop. That is a literal mechanism for "runs off the edge".

It is not a remote-vs-local asymmetry. Section 4 shows why 204d0ae0 could not have covered this: that commit deleted four remote-only forgeries layered on top of the shared engine. It never touched Transition, CliffSlide, or last-known-plane maintenance. The local player never had those forgeries, so there was nothing there for the remote fix to also fix.

Confidence, stated honestly. The divergence is proven (Section 3). Its causal link to the user's specific cliff is a hypothesis — it requires edge_slide to take branch 2 (steep contact plane) rather than branch 3/5 (walkable-polygon precipice) in that geometry, and which branch fires depends on what the step-down probe actually finds under the user's cliff. One live run of the probe that already exists settles it (Section 6). Do not write the fix before that run.

---

2. What retail does at a walkable edge

2.1 Entry gate — CTransition::transitional_insert 0x0050b812

Disassembly:

0050b812  cmp  [esi+0x288], ebp     ; collision_info.contact_plane_valid
0050b818  jne  0x50ba30             ; valid contact -> return 1 (OK), no step-down
0050b81e  mov  eax, [esi+4]         ; object_info.state
0050b821  test al, 1                ; CONTACT
0050b823  je   0x50ba30
0050b829  cmp  [esi+0x178], ebp     ; sphere_path.step_down  (must be 0)
0050b82f  jne  0x50ba30
0050b835  cmp  [esi+0x128], ebp     ; sphere_path.check_cell (must be non-null)
0050b83b  je   0x50ba30
0050b841  cmp  [esi+0x18], ebp      ; object_info.step_down   (must be set)
0050b844  je   0x50ba30

acdream, TransitionTypes.cs:2176-2181:

if (ci.ContactPlaneValid) return TransitionState.OK;
...
if (oi.Contact && !sp.StepDown && sp.CheckCellId != 0 && oi.StepDown)

Exact match, term for term, including the "a valid contact plane short-circuits the whole step-down tail" rule.

2.2 Thresholds — 0x0050b84a

0050b84a  test al, 2                       ; ON_WALKABLE
0050b84c  mov  ecx, [0x7c6870]             ; = 0.0871557f  (cos 85 deg)
0050b852  mov  [esp+0x14], 0x3d23d70a      ; step_down_height default = 0.04 m
0050b85a  mov  [esp+0x18], ecx             ; walkable allowance default
0050b85e  je   0x50b872
0050b860  call 0x50cf20                    ; OBJECTINFO::get_walkable_z
0050b867  fstp [esp+0x18]                  ; allowance = get_walkable_z()  (FloorZ)
0050b86b  mov  edx, [esi+0x10]             ; object_info.step_down_height
0050b86e  mov  [esp+0x14], edx

In plain language: a mover standing on walkable ground probes down by its own authored step-down height (about 40 cm for a human) and demands a surface no steeper than FloorZ = 0.6642 — that is a surface tilted at most ~48.4 degrees from flat. A mover not on walkable ground gets 4 cm and the far more permissive ~85-degree allowance. acdream: oi.GetWalkableZ() / oi.StepDownHeight at TransitionTypes.cs:2192-2194, FloorZ = 0.6642f at TransitionTypes.cs:1255.

2.3 Probe schedule — 0x0050b886

0050b886  cmp  [edi], 2             ; sphere_path.num_sphere
0050b889  jae  0x50b8ab
0050b88e  fld  [ecx+0xc]            ; global_sphere[0].radius
0050b891  fadd st(0), st(0)         ; 2*radius
0050b893  fcomp [esp+0x14]          ; vs step_down_height
0050b899  test ah, 5
0050b89c  jp   0x50b8ab             ; taken when 2r >= h  -> keep h
0050b89e  fld  [ecx+0xc]
0050b8a1  fmul [0x7928b8]           ; = 0.5f
0050b8a7  fstp [esp+0x14]           ; h = radius * 0.5
...
0050b8b5  fadd st(0), st(0)         ; 2*radius again
0050b8ba  fcomp [esp+0x18]          ; (after `push edi`) == the step_down_height slot
0050b8c3  jp   0x50b8ff             ; 2r >= h  -> ONE probe of h
                                    ; else     -> TWO probes of h*0.5

Note Binary Ninja mislabels that second comparand as the walkable allowance, because it does not account for the push edi at 0x0050b8b9 shifting the frame by 4. The disassembly settles it: both comparisons are against step_down_height.

acdream's GetStepDownProbePlan (TransitionTypes.cs:1893-1908) reproduces this, with one boundary difference: retail branches on strict 2r < h, acdream on diameter <= probeHeight / diameter > probeHeight. At exact float equality acdream clamps and splits where retail does not. Real, citable, and almost certainly inert (it needs 2*radius to equal the authored step-down height bit for bit). For the human player it is unreachable anyway: num_sphere == 2, radius 0.48 so 2r = 0.96 >= 0.4, hence one full-height probe.

Whatever height was actually used is then passed to edge_slide — 0x0050b921 edge_slide(this, &state, step_down_height_used, allowance).

2.4 The response chooser — CTransition::edge_slide 0x0050b3d0

0050b3d8  mov  eax, [esi+4]        ; object_info.state
0050b3db  test al, 2               ; ON_WALKABLE (0x0002)
0050b3de  je   0x50b59b            ; -> restore, OK, stop
0050b3e4  test ah, 2               ; EDGE_SLIDE  (0x0200)
0050b3e7  je   0x50b59b            ; -> restore, OK, stop
0050b3ed  mov  ecx, [esi+0x288]    ; contact_plane_valid
0050b3f7  je   0x50b444            ; invalid -> skip cliff branch
0050b3f9  fld  [esi+0x294]         ; contact_plane.N.z
0050b3ff  fcomp [esp+0x70]         ; vs arg4 (the walkable allowance)
0050b405  test ah, 5
0050b408  jp   0x50b444            ; N.z >= allowance -> skip cliff branch
0050b40a  ...  walkable = 0 ; restore_check_pos ; cliff_slide(&contact_plane)
0050b43b  xor  eax, eax            ; return FALSE  (caller keeps retrying)
0050b444  cmp  [esi+0x1f4], ebp    ; sphere_path.walkable
0050b44a  jne  0x50b563            ; non-null -> precipice branch
0050b450  cmp  ecx, ebx            ; contact_plane_valid -> restore + OK + stop

test ah, 5 after fnstsw tests C0 (less-than) and C2 (unordered); with an ordered compare the parity of that pair is even exactly when C0 is clear, so jp is taken on >=. The cliff branch is therefore entered on contact_plane.N.z < allowance — a contact plane too steep to stand on.

The five responses, in retail's order, are:

1. !ON_WALKABLE || !EDGE_SLIDE → restore the saved candidate, OK_TS, stop.
2. valid contact plane steeper than the allowance → restore, cliff_slide, return false so the insert keeps retrying against the displaced candidate.
3. a stored walkable polygon → restore, precipice_slide against it.
4. valid contact plane, no walkable polygon → restore, OK_TS, stop.
5. otherwise → back-probe from the current sphere centre to rediscover the polygon just left, restore, precipice_slide against that.

acdream's EdgeSlideAfterStepDownFailed (TransitionTypes.cs:2420-2537) reproduces all five in that order. Verified branch by branch against the disassembly above; no divergence found in the ordering or the gates.

2.5 The two responses

SPHEREPATH::precipice_slide 0x0050cc80: if CPolygon::find_crossed_edge returns 0 (the candidate never left the polygon), it clears walkable and returns COLLIDED_TS — the move is refused, you stop. Otherwise it slides the sphere along the crossed edge. acdream SpherePath.PrecipiceSlide (TransitionTypes.cs:1073-1099) matches, including the Collided return.

CTransition::cliff_slide 0x0050a6d0:

cross( arg2->N , collision_info.last_known_contact_plane.N )   with Z forced to 0
normalize_check_small(...) != 0  ->  return 1   (OK_TS, no displacement at all)
otherwise                        ->  add_offset_to_check_pos(dir * ±dot)
                                     set_collision_normal(dir)
                                     return 3   (ADJUSTED_TS)

acclient.h:6100-6108 gives INVALID=0, OK=1, COLLIDED=2, ADJUSTED=3, SLID=4; acdream's enum (TransitionTypes.cs:9-16) is identical, and Transition.CliffSlide returns OK on degeneracy and Adjusted otherwise. Match.

So retail's "slide along the cliff edge" is cliff_slide, and its entire direction comes from crossing the steep plane you are refusing against the last-known contact plane — the surface you were standing on a moment ago. Kill the second vector and the slide becomes a no-op.

---

3. What acdream does — the divergence

3.1 Retail's last-known contact plane has exactly four writers

Grepping every assignment in the named decomp:

Address	Function	Effect
0x00509d62	COLLISIONINFO::init	clear
0x00509de6	CTransition::init	clear
0x0050a9b8	inside validate_transition	clear
0x0050ad07-0x0050ad47	validate_transition tail	lkcp_valid = contact_plane_valid; copy plane only when valid
0x0050b9d7	transitional_insert phase-3 reset	clear
0x0050e85d	CTransition::init_contact_plane	set both current and last-known
0x0050e8e6	CTransition::init_last_known_contact_plane	set last-known only

init_contact_plane and init_last_known_contact_plane are the per-transition seeds, called once from CPhysicsObj::get_object_info 0x00511cc0 depending on whether check_contact succeeded. validate_transition's tail is the end of the transition. Nothing in between writes last-known.

And critically, the per-substep writer does not:

00509d80  COLLISIONINFO::set_contact_plane
00509d86  mov [ecx+0x18], 1        ; contact_plane_valid
00509d8e  lea eax, [ecx+0x1c]      ; contact_plane.N.x/y/z, .d  (4 dwords)
00509db1  mov [ecx+0x34], eax      ; contact_plane_is_water
00509db5  ret 8

Twenty-two bytes of body. It does not touch +0x00/+0x04 (last-known valid / plane), and it does not touch +0x2c (contact_plane_cell_id) either.

Compare init_contact_plane 0x0050e850, which writes [ecx+0x270], [ecx+0x274..0x280], [ecx+0x284], [ecx+0x2a0] (all last-known) and [ecx+0x288], [ecx+0x28c..], [ecx+0x2a4], [ecx+0x29c] (all current). The two functions are deliberately different, and retail calls the narrow one from every collision-response site.

3.2 acdream's SetContactPlane does both

src/AcDream.Core/Physics/TransitionTypes.cs:446-480:

public void SetContactPlane(Plane plane, uint cellId, bool isWater = false)
{
    ... no-op-if-unchanged guard ...
    ContactPlaneValid = true;
    ContactPlane = plane;
    ContactPlaneCellId = cellId;
    ContactPlaneIsWater = isWater;

    LastKnownContactPlaneValid = true;      // <-- retail does not do this
    LastKnownContactPlane = plane;          // <-- nor this
    LastKnownContactPlaneCellId = cellId;   // <-- nor this
    LastKnownContactPlaneIsWater = isWater; // <-- nor this
}

There are 13 call sites in the tree:

BSPQuery.cs:1297, 2035
FlatBspQuery.cs:1393, 1921        <- production-authoritative since I6/I7
PhysicsEngine.cs:1987             <- the per-transition seed (retail init_contact_plane: correct)
TransitionTypes.cs:3613, 3636     <- ValidateWalkable, both resting and below branches
TransitionTypes.cs:4409, 4562, 4732, 4874   <- water paths
TransitionTypes.cs:5756           <- validate_transition recovery (restores FROM lkcp: self-write, harmless)
TransitionTypes.cs:5835

Only PhysicsEngine.cs:1987 legitimately corresponds to retail's init_contact_plane. The other twelve correspond to retail's set_contact_plane, and every one of them clobbers the last-known plane that retail deliberately preserves across the whole transition.

git log -S dates the latch to 9ea8ae51, 2026-04-13, "feat(physics): Transition system data structures" — the very first commit that introduced the type. It has never been retail-verified, and it matches the user's report that the symptom is pre-existing rather than a regression.

3.3 The causal chain to "runs off the cliff"

Walking a grounded local player at a drop, in one ResolveWithTransition → TransitionalInsert attempt:

1. PhysicsEngine seeds the transition from the body's committed contact plane (ResolveWithTransition, the check_contact success branch, PhysicsEngine.cs:1978-1993). Both current and last-known now hold the ground you are standing on. This part is retail-correct.
2. The forward candidate hangs over the drop. The primary insert finds no support and returns OK with no contact plane, so the step-down block is entered (Section 2.1).
3. DoStepDown offsets down and re-inserts. It finds the steep cliff face, and ValidateWalkable (TransitionTypes.cs:3613/3636) calls ci.SetContactPlane(steepPlane, ...). → Last-known is now also the steep plane. The ground reference is gone.
4. DoStepDown rejects the candidate because ContactPlane.Normal.Z < FloorZ (TransitionTypes.cs:5405-5407), and — matching retail step_down — leaves the steep plane in place on the way out.
5. EdgeSlideAfterStepDownFailed takes branch 2: ContactPlaneValid && Normal.Z < zVal → CliffSlide(steepPlane).
6. CliffSlide computes Vector3.Cross(contactPlane.Normal, ci.LastKnownContactPlane.Normal) (TransitionTypes.cs:2550-2552). Both operands are now the same vector. Cross product = zero → the degenerate guard at :2559 fires → returns TransitionState.OK with no displacement.
7. EdgeSlideAfterStepDownFailed returns false (stop = false) with edgeState == OK, so TransitionalInsert does transitState = edgeState; continue; (TransitionTypes.cs:2255-2262).
8. The retry re-inserts at the same restored candidate, fails the same way, and when the attempt budget runs out TransitionalInsert returns OK. ValidateTransition commits it. The body is now over the void, gravity takes it, and the player falls off the edge.

In retail the same eight steps run, but at step 6 last-known still holds the cliff-top plane, the cross product is non-zero, cliff_slide returns ADJUSTED_TS after laterally displacing the candidate, and the player glides along the rim.

3.4 The divergence is already pinned by a test — as correct

tests/AcDream.Core.Tests/Physics/RetailEdgeResponseOrderingTests.cs:188-230, TransitionalInsert_DegenerateCliffSlideOk_ContinuesOuterRetry, added by c559c48d (2026-07-31, "restore retail edge-response ordering"). Its own comment reads:

// The nested downward probe finds a steep contact. It is
// rejected as walkable, and because SetContactPlane also
// latches the same last-known plane, CliffSlide's cross is
// parallel/degenerate and writes OK_TS with stop=false.

and it then asserts TransitionState.OK, two outer object passes, and a committed contact plane. The test observes acdream's behaviour and pins it; it does not compare against retail. Given 0x00509d80, retail could not reach that configuration at all. This is the shape the C4 closeout named as its most expensive process finding — a contract asserting a mechanism that does not exist — and the fix will have to rewrite this test, not merely satisfy it.

3.5 Second-order effects of the same latch (blast radius, not new bugs)

• ValidateTransition's non-OK recovery (TransitionTypes.cs:5745-5762) calls oi.StopVelocity() and restores contact from last-known. Retail gates the same recovery on last_known_contact_plane_valid. Because acdream's last-known is valid far more often than retail's, kill_velocity can fire where retail's would not — which is the exact opposite of the L.4/L.5 finding recorded in #32 itself ("Retail trace: 0 kill_velocity hits across 40,960 update_object calls"). Worth checking against #269's slope-slide residual after any fix.
• transitional_insert's phase-3 reset reads LastKnownContactPlaneValid (TransitionTypes.cs:2072) to choose between StopVelocity and SetCollisionNormal(StepUpNormal). Same over-validity concern.
• TransitionTypes.cs:5089-5090 falls back to last-known when current is invalid.
• Minor, same site: acdream's SetContactPlane also writes ContactPlaneCellId, which retail's set_contact_plane does not (retail writes the cell id only in init_contact_plane, 0x0050e8ca). Note it; do not necessarily change it, since acdream's callers rely on the cell id being current.

---

4. Why the remote fix at 204d0ae0 could not cover the local player

204d0ae0 ("remote bodies slide on steep faces instead of freezing (#32)") changed six production files:

src/AcDream.App/Physics/LiveEntityNetworkUpdateController.cs
src/AcDream.Core/Physics/InterpolationManager.cs
src/AcDream.Core/Physics/Motion/MotionTableDispatchSink.cs
src/AcDream.Core/Physics/PhysicsDiagnostics.cs            (probe family)
src/AcDream.Runtime/Physics/RuntimeRemotePhysicsUpdater.cs
src/AcDream.Runtime/Physics/RuntimeRemoteSteadyStatePosition.cs

Not in the list: TransitionTypes.cs, PhysicsEngine.cs, BSPQuery.cs, FlatBspQuery.cs, PlayerMovementController.cs. The commit did not touch the sweep, the edge family, CliffSlide, or contact-plane maintenance at all.

What it did do, per its own message and the #32 row, was delete four remote-only overrides layered on top of the shared engine:

1. a per-tick TransientState |= Contact | OnWalkable forge,
2. a per-tick Body.Velocity zero,
3. a PhysicsStateFlags.Gravity clear at the landing edge,
4. a landing edge tested on IsOnGround (inContact || ...) instead of the sweep's own OnWalkable,

and route the remote tick through PhysicsObjUpdate.CommitSetPositionTransition — which its message describes as "the same SetPositionInternal commit TickHidden and the local player" already used.

That is the whole answer to "what structurally excludes the local player". Nothing excludes it. The local player never had those four forgeries — it has been running the full check_contact seed, the full sweep, and the full SetPositionInternal commit since the #265/#166 landing-bounce work (PlayerMovementController.cs:2632-2760). The remote bug was a remote-only layer suppressing a shared mechanism; removing it restored the remote to parity with the local player. It could not fix a defect that lives inside the shared mechanism, and #32's own note — "Local-player edge-slide is unchanged by this work" — is literally accurate rather than an admission of a missing per-mover-class feature.

Corollary worth stating: the divergence in Section 3 affects remotes too. The user's accepted remote gate was a steep-roof slide-down under gravity, driven by adjust_offset's per-substep plane projection — a path that never reaches edge_slide. A remote walked at a cliff rim by the server should exhibit the same run-off, and would not have been caught by that gate.

---

5. Is #134 the same defect?

#134 — "Player 'lags downward' instead of gliding along a dungeon ramp edge", docs/ISSUES.md:13692 — is the same family and plausibly the same mechanism, and its DONE status is not supported by evidence.

Three observations:

1. Its closure is a triage inference, not a verification. The row reads: "Status: DONE (2026-07-09, user-confirmed via memory during an issues-triage pass — not independently re-verified this session)", and attributes the fix to "the later CSphere/CCylSphere collision-family ports (#172, #182) and the general slide-response work tracked under #32/#116". None of those touched CliffSlide or last-known-plane maintenance. It is a "probably fixed by adjacent work" closure.
2. The symptom is the branch-2 signature indoors. "Gliding along the slope tangent" is cliff_slide's lateral displacement; "lagging downward" is what you get when that displacement is zero and gravity is the only thing left acting on the candidate. A dungeon ramp edge presents exactly the branch-2 input: the step-down probe finds the ramp's steep side face, Normal.Z < FloorZ, contact plane valid.
3. The indoor path clobbers last-known identically. FlatBspQuery.cs:1393 and :1921 (production-authoritative since the I6/I7 flat cutover) call the same SetContactPlane. There is no outdoor/indoor difference in the mechanism.

I cannot prove they are one defect without a measurement — a ramp edge could instead route through branch 3/5 (a BSP polygon is small enough for find_crossed_edge to fire, unlike a 24 m terrain triangle, so indoors the precipice branch is genuinely reachable where outdoors it usually is not).

Recommendation: treat #134 as an unverified closure and re-open it as a confirmation item on the same probe run, not as a separate investigation. If the probe shows branch=branch2/steep-cliffslide with a degenerate cross at a dungeon ramp edge, #134 and #32's local half are one fix.

---

6. Do we need a live measurement? Yes — and the probe already exists

The divergence in Section 3 is proven; its reachability in the user's scenario is not. The specific unknown is which of edge_slide's five branches fires at the user's cliff. Only branches 2 and (indirectly) 4 involve last-known; branches 3 and 5 route to PrecipiceSlide, where the LKCP latch is irrelevant and the run-off would have a different cause.

There is a real reason to distrust source-only reasoning here. Outdoor terrain in acdream is a continuous heightfield whose walkable polygon is half of a 24 m landcell (TerrainSurface.CellSize = 24f, SampleTerrainWalkableInCell → TerrainTriangleVertices). A candidate 10 cm past a cliff lip is still deep inside that triangle, so FindCrossedEdge cannot fire and branch 3/5 should degenerate to Collided (= stop). That reasoning predicts a stop, not a fall — which is the opposite of what the user observes — and I would rather name the contradiction than paper over it. It is resolved if branch 2 wins the race (Section 3.3 step 5), but "which branch wins" is a fact about the DAT geometry under the user's feet, not about the code, and it is precisely the kind of thing a DAT sweep would happily "confirm" either way.

The probe

No new instrumentation is needed. ACDREAM_DUMP_EDGE_SLIDE=1 (TransitionTypes.cs:1302-1303) already emits, at exactly the right site:

• DumpEdgeSlideStepDownFailed (:2584) — one edge-slide: stepdown-failed line carrying edgeFlag, contactFlag, onWalkable, contactPlane, lastPlane, walkableValid, walkablePoly, lastWalkablePoly, stepDown, zVal.
• DumpEdgeSlideBranch (:2626) — one edge-slide: branch= line naming the branch taken, plus contactN.Z, lastN.Z, walkPolyN.Z, onWalk, edgeFlag, zVal.
• DumpCliffSlide (:2558/:2567) — degenerate-cross/last-known versus ok/last-known.

Volume is low: it only fires on a failed step-down.

Run it

$env:ACDREAM_DAT_DIR   = "$env:USERPROFILE\Documents\Asheron's Call"
$env:ACDREAM_LIVE      = "1"
$env:ACDREAM_TEST_HOST = "127.0.0.1"; $env:ACDREAM_TEST_PORT = "9000"
$env:ACDREAM_TEST_USER = "testaccount"; $env:ACDREAM_TEST_PASS = "testpassword"
$env:ACDREAM_DUMP_EDGE_SLIDE = "1"
dotnet run --project src\AcDream.App\AcDream.App.csproj --no-build -c Release 2>&1 |
    Tee-Object -FilePath "edge-slide.log"

Walk the local player at the cliff the user reproduced on, then close the window gracefully (CloseMainWindow, not Stop-Process).

Decision table

branch= in the log	lastN.Z vs contactN.Z	Verdict
branch2/steep-cliffslide + degenerate-cross/last-known	equal	Section 3 confirmed. Root cause is the SetContactPlane LKCP latch. Ship the Section 7 fix.
branch2/steep-cliffslide + ok/last-known	differ	Cliff slide is running and producing a real displacement. The run-off is downstream of edge_slide — look at ValidateTransition / the retry budget instead.
branch3/precipice-slide or the back-probe branch	—	The LKCP latch is not on this path. Root cause is in FindCrossedEdge / walkable-polygon granularity; a 24 m terrain triangle cannot produce a rim slide and the mechanism itself would then be missing outdoors. Different, larger fix.
branch1/!onwalkable-or-!edgeslide	—	The mover lost OnWalkable before the edge. Root cause is upstream in contact classification, not in the edge family.
branch4/contact-no-walkable	—	Retail-correct stop; the run-off is happening somewhere else entirely and this whole line of inquiry is wrong.
no edge-slide: line at all	—	The step-down block is never reached — check the four gates in Section 2.1 (most likely oi.Contact failing check_contact, or a valid contact plane short-circuiting at :2176).

If nothing prints, that is itself the most informative outcome and redirects the whole investigation. Do not write any code before this run.

---

7. What the fix would be, and how big

Only if the probe lands in row 1. Do not pre-emptively implement it.

Shape — split the setter the way retail splits it.

1. In CollisionInfo (src/AcDream.Core/Physics/TransitionTypes.cs:446-480), reduce SetContactPlane to retail's COLLISIONINFO::set_contact_plane 0x00509d80: write ContactPlaneValid, ContactPlane, ContactPlaneIsWater (keep ContactPlaneCellId — see Section 3.5 — and file it as a one-line register row if kept). Delete the four last-known writes.
2. Add InitContactPlane(plane, cellId, isWater) mirroring CTransition::init_contact_plane 0x0050e850: write both groups.
3. Point PhysicsEngine.ResolveWithTransition's check_contact success branch (PhysicsEngine.cs:1987) at InitContactPlane. Leave the failure branch alone — it already mirrors init_last_known_contact_plane.
4. Leave the other eleven call sites on the narrowed SetContactPlane.
5. ValidateTransition's existing tail (TransitionTypes.cs:5779-5783) already is retail's 0x0050ad07 end-of-transition latch. No change.

Size. Two production files, roughly 20-25 lines changed, one of them a pure deletion. This is genuinely small — the whole edge family is already ported; the fix restores one field's write discipline.

Not a workaround. This is porting the retail mechanism, not suppressing a symptom. CLAUDE.md's no-workarounds rule is satisfied: no guard, no grace period, no flag. If the probe instead lands in row 3, the honest answer is different and larger — retail's rim-slide behaviour would be absent outdoors and would have to be ported properly, and I would say so plainly rather than reach for the closest available approximation.

Test cost — larger than the production cost.

• RetailEdgeResponseOrderingTests.TransitionalInsert_DegenerateCliffSlideOk_ContinuesOuterRetry must be rewritten. It currently asserts the divergence as correct (Section 3.4). Its replacement should set the seed plane and the probe plane independently and assert Adjusted + a lateral displacement.
• CliffSlide_InvalidDefaultLastKnownPlane_TakesDegenerateOkReturn (:132) stays valid — retail does return OK_TS when last-known really is absent.
• The other nine files touching LastKnownContactPlane (BSPStepUpTests, IndoorContactPlaneRetentionTests, RetailStepDownPlacementTests, FindEnvCollisionsMultiCellTests, PhysicsSetPositionTests, RuntimeRemoteSteepContactSlideTests, ...) must be re-run and inspected — any that pass because an intra-transition write kept last-known valid will change.
• Gates: full Core + Runtime + App suites, plus the connected nine-stop route, because of the kill_velocity-frequency blast radius in Section 3.5 and its overlap with #269.
• Register: the fix retires nothing currently filed (there is no row for this — it is an unfiled divergence, "a bug twice over" by the register's own rule). If ContactPlaneCellId is kept, that gets a new row in the same commit.

---

8. Stale claims in #32's own text (filed 2026-04-29)

Checked against HEAD; each verified individually.

Claim in #32	Status
"acdream does not yet preserve the full walkable polygon context from terrain/BSP step-down, so this is still the conservative stop-at-edge fallback" (mirrored in the code comment at TransitionTypes.cs:2223-2232)	STALE. Walkable context is preserved for both terrain (CacheWalkableContext, :3660-3671) and BSP (SetWalkableTransformed), and the full five-branch chain plus the back-probe is implemented. TS-1 was retired 2026-07-30 as "the row was stale, not the code". The in-code comment is stale too and should be corrected with the fix.
"Pragmatic ship-state: BSPQuery Path 6 keeps the L.4 slide-tangent deviation (project-along-steep-face-and-return-Slid)"	STALE. Production is FlatBspQuery since the I6/I7 flat cutover; its Path 6 (FlatBspQuery.cs:2011-2042) is the retail set_collide + WalkableAllowance = LandingZ + Adjusted shape. There is no slide-tangent return.
"Remaining gaps: ... NegPolyHit dispatch"	STALE. Neg-poly dispatch shipped A6.P4 (2026-05-25) and is live at TransitionTypes.cs:2110-2170 (slide_sphere / step_up → step_up_slide).
"the AP-140 follow-up (point the two routing gates at Body.InContact) [remains open]" — in the status header	STALE. The register records AP-140 as "filed AND RETIRED 2026-08-04", same day.
"We ported this gate as L.5 in PlayerMovementController via _physicsAccum"	STALE. _physicsAccum does not exist anywhere in the tree; the 30 Hz gate is RetailObjectQuantumClock since R6.
"Files: TransitionTypes.cs, BSPQuery.cs, tests/"	STALE/INCOMPLETE. BSPQuery is no longer the production collision path (FlatBspQuery is). The file list should name FlatBspQuery.cs and PhysicsEngine.cs.
"AD-10's terrain-only slope projection still cannot see building geometry"	Already self-corrected in the body (superseded 2026-08-06, AD-10 retired by deletion) but the status header still lists it as a dependency. Header and body disagree.
"Local/remote movement passes the retail-default EdgeSlide flag"	ACCURATE. Verified at PlayerMovementController.cs:2170/:2661 and RuntimeRemotePhysicsUpdater.cs:442/:998. Retail's source is CPhysicsObj::get_object_info 0x00511cd1: state & 0x400000 -> result 0x200, and PhysicsBody.cs:79 has EdgeSlide = 0x00400000.
"Our Phase 3 reset path now matches retail's gate (only kills when valid)"	ACCURATE at TransitionTypes.cs:2072. (But see Section 3.5 — the gate matches while the validity is over-set.)
"A LeaveGround-count bound is the missing test"	ACCURATE, still open. No LeaveGround count assertion exists anywhere in tests/.
"#173's visual gate is still unrun"	Not independently checkable this session; left as-is.

---

9. Summary for the caller

• Retail refuses a step-down onto anything steeper than ~48.4 degrees, then runs CTransition::edge_slide, which picks one of five responses in a fixed order. The "slide along a cliff edge" response is cliff_slide, and its direction is cross(steep plane normal, last-known contact plane normal) — it needs the surface you were standing on a moment ago as its second vector.
• acdream implements all five branches in the correct order with the correct flags, for the local player, verified against disassembly. But CollisionInfo.SetContactPlane latches the last-known contact plane on every write, where retail's COLLISIONINFO::set_contact_plane (0x00509d80, 22 bytes) never touches it. The step-down probe's own steep plane therefore overwrites the reference vector, cliff_slide's cross product goes to zero, the degenerate OK return displaces nothing, and the retry loop accepts the candidate hanging over the drop. The latch dates to 9ea8ae51 (2026-04-13) and has never been retail-verified — consistent with "pre-existing, not a regression".
• The local player is not structurally excluded from anything. 204d0ae0 deleted four remote-only forgeries sitting on top of the shared engine; it never touched the sweep, the edge family, or contact-plane maintenance. The same divergence should affect remotes walked at a rim — the accepted remote gate was a gravity roof-slide, which never reaches edge_slide.
• #134 is the same family and plausibly the same mechanism, and its DONE status is a 2026-07-09 triage inference attributed to work that did not touch this code. Re-open it as a confirmation item on the same probe run.
• The fix is to split SetContactPlane into retail's narrow setter plus an InitContactPlane seed, and point only the per-transition seed at the latter. Two files, ~20-25 lines, mostly deletion. The test cost is larger than the production cost: an existing test pins the divergence as correct and must be rewritten, and nine other files touching LastKnownContactPlane need re-inspection.
• Yes, measure first. The divergence is proven; its reachability in the user's cliff is not, and one branch of my own reasoning predicts a stop rather than a fall, which I could not reconcile from source. ACDREAM_DUMP_EDGE_SLIDE=1 already prints the branch taken and both normals at exactly the deciding site. One walk at the reproducing cliff settles it against the decision table in Section 6. No code should be written before that run.