# P2 — Collision response-layer edge family: port-ready pseudocode

**Status: RETAIL RESPONSE ORDER COMPLETE (2026-07-31).** Originally a
research-only doc for Campaign P Slice P2
(`docs/plans/2026-07-29-physics-parity-campaign.md` §P2). The first TS-4
attempt reproduced a steep-roof fixed point because its fixture discarded
the accepted contact state between frames; §7 item 6 preserves that useful
failure analysis. Slice 1B then completed the exact nested edge/StepDown
dispatcher, Slice 2A restored StepDown's mandatory Placement tail, and Slice
2B repeated the removal with production-shaped state carry and the complete
direction matrix. TS-4 is now retired; see §10.
#166 got a reattribution note in ISSUES.md rather than new code (per §3).
#116's former skipped wall control is now active with the retail Path-6
first-frame hard stop and next-frame slide chronology.
**Headline findings that change the plan's assumptions:** TS-1 was already
substantially ported (the register row and plan phrasing were stale — see
§2); the one real gap needed no code change (acdream's unified world-space
`SpherePath` design makes retail's per-cell recache a no-op correction here
— see §2 and the TS-1 register row's retirement text); #166 is very likely
NOT about a literal `PhysicsState.Sledding` auto-toggle at all (see §3);
AP-7's L.3c regression does not reproduce on the production graphical
root-motion path post-R6, and now ports retail's confirmed 0.25f threshold
(see §1). The apparent TS-4 wedge was a harness-state defect, not a reason to
retain a product compensation: production-shaped vertical, inward,
tangential, uphill, and downhill histories now pass graph/flat raw-bit
parity without the shortcut. Campaign P Slice 1B removed AP-3, AP-4, AD-53,
and AD-54 (§8); Slice 2A retired AP-5 (§9); Slice 2B retired TS-4 (§10).

Every claim below is tagged **FACT** (grep/read-verified against the
named-retail decomp, the register, ISSUES.md, or current acdream source
in THIS worktree at the time of writing) or **INFERENCE** (reasoned but
not yet decomp/cdb/Ghidra-confirmed — do not port on an INFERENCE alone
without the flagged follow-up).

---

## 0. Binding DO-NOT-RETRY entries (copied verbatim from
`memory/project_physics_collision_digest.md`, 3-day-old snapshot —
re-verify line numbers before the implementation session)

These bind the P2 implementer. Do not re-attempt any of these shapes.

1. **Do NOT add `SetSlidingNormal` calls in the BSP/sphere collision
   layer.** Retail's only in-transition writer of `collision_info.sliding_normal`
   is `validate_transition` (0x0050ac21 / 0x0050aa70). A leaked normal +
   success writeback = an absorbing wedge at empty space. (#137
   mechanism-2 lesson; directly governs TS-4 item 4 below.)
2. **Do NOT re-add a forced constant-shell de-penetration** to the
   sphere/cyl response. Retail slides tangentially (crease = collisionNormal
   × contactPlane.Normal) and never force-separates.
3. **`SphereCollision` no longer calls `SetSlidingNormal`** (TS-45
   retired) — the only in-transition sliding-normal writer is
   `validate_transition`. Keep it that way.
4. **Do NOT patch the degenerate-offset guard in `slide_sphere` ad hoc**
   for #116 — the issue explicitly wants an oracle-driven pass, not a
   symptom patch. (#116 DO-NOT-RETRY, both the digest and ISSUES #116.)
5. **Do NOT re-introduce a topology-based outside-add / radial sweep**
   to cell membership while touching this family — unrelated layer, but
   the digest's adjacent #98/#116 sessions warn subagents drift there.
6. **`calc_friction` threshold is retail 0.25 vs acdream 0.0** — this is
   AP-7. The L.3c attempt (naive bump to 0.25, no state gate) regressed
   normal walking 3 → 0.16 m/s and was reverted. Do NOT repeat a bare
   threshold bump without decoding the state gate first.
7. **Shape-1 of #116 (tick-22760 lateral-slide loss) is NOT the
   degenerate-offset guard threshold** — that guard kills slides under
   ~1.4 cm; the lost slide was 3.57 cm, well above it. The real
   divergence is the collision-normal SOURCE (recording layer), not
   slide/validate. Do not re-chase the guard threshold for shape-1.
8. **Do NOT guess the BN `test ah,5` x87 branch polarity/squaring** in
   `slide_sphere` — this exact construct is called out as undecodable
   from BN alone (the PosHitsSphere-saga warning). Ghidra MCP settled it
   once already (2026-06-12) for the EPSILON-vs-EpsilonSq bug; Ghidra MCP
   is DOWN for this research pass — mark any residual x87-ambiguous claim
   Ghidra-verify, cite ACE as the fallback tiebreaker, do not silently guess.
9. **SUPERSEDED 2026-07-31 by Campaign P Slice 1B.** AP-4's CliffSlide-first
   compensation was removed only after the complete retail
   `transitional_insert`/`edge_slide` order was read and branch-order plus
   graph/flat multi-frame roof/ledge controls passed. Do not reintroduce the
   compensation; see §8 and the retired AP-4 row.
10. **TS-46 (two-scalar sphere reconstruction) is OUT OF SCOPE for P2**
    (it's P3) but shares files (`TransitionTypes.cs` `InitPath`) — do not
    fold TS-46 sphere-list work into a P2 commit.

---

## 1. AP-7 — friction state gate

### The function (FACT — named-retail grep-first)

`CPhysicsObj::calc_friction` is named at pseudo-C:276694
(address `0050ee70`), called from `UpdatePhysicsInternal`-equivalent at
pseudo-C:278490 (`0050f0a…` region, `CPhysicsObj::calc_friction(this, arg2,
var_28)` where `arg2`=dt/quantum, `var_28`=velocity_mag2 — matches acdream's
`calc_friction(float dt, float velocityMag2)` signature already).

Full structure read from pseudo-C:276694-276822 (**FACT**, direct read, not
Ghidra):

```
void CPhysicsObj::calc_friction(dt, velocityMag2) {
    if ((transient_state & 2) != 0) {              // OnWalkable (see below)
        if ((state & MASK) == 0) {                  // MASK: BN-garbled string constant, see below
            // ---- Branch A ----
            dot = dot(contact_plane.N, velocity);    // order N·v
            if (!p_5)                                // p_5 from (dot < 0.25f) comparison, x87-ambiguous
                velocity -= dot * contact_plane.N;
                friction = this->friction;            // read field (decompiler shows bare read;
                                                        // almost certainly `1.0f - this->friction`
                                                        // collapsed/elided — see ACE cross-check)
              label_50f00e:
                velocity *= pow(friction, dt);         // shared tail with Branch B
        } else {
            // ---- Branch B ----
            dot = dot(velocity, contact_plane.N);       // same value, operand order swapped
            if (!p_1) {                                  // p_1 from (dot < 0.25f), x87-ambiguous
                friction = 0.2f;                          // LOCAL default inside this branch
                velocity -= dot * contact_plane.N;
                p_2 = (velocityMag2 ⋛ 1.5625f);            // x87-ambiguous direction
                if (p_2) {
                    p_3 = (velocityMag2 ⋛ 6.25f);          // x87-ambiguous direction
                    if (p_3)
                        p_4 = (cos(10°=0.17453292519943295 rad) ⋛ contact_plane.N.z);  // x87-ambiguous
                    if (!p_3 || !p_4)
                        friction = this->friction;          // fall back to object's own friction
                }
                goto label_50f00e;
            }
        }
    }
}
```

Constants confirmed **FACT** by direct read: `0.25f` (both branches,
independently re-derived — not copy-paste, two separate x87 loads),
`0.2f`, `1.5625f`, `6.25f`, `0.17453292519943295` (=10° in radians, fed
to `__fcos`). The outer gate bit is `transient_state & 2`.

### Cross-check: ACE `PhysicsObj.calc_friction` (FACT, `references/ACE/Source/ACE.Server/Physics/PhysicsObj.cs:2120-2141`)

```csharp
public void calc_friction(double quantum, float velocity_mag2)
{
    if (!TransientState.HasFlag(TransientStateFlags.OnWalkable)) return;

    var angle = Vector3.Dot(Velocity, ContactPlane.Normal);
    if (angle >= 0.25f) return;

    Velocity -= ContactPlane.Normal * angle;

    var friction = Friction;                    // this->friction — SAME baseline in ALL cases
    if (State.HasFlag(PhysicsState.Sledding))
    {
        if (velocity_mag2 < 1.5625f)
            friction = 1.0f;
        else if (velocity_mag2 >= 6.25f && ContactPlane.Normal.Z > 0.99999536f)
            friction = 0.2f;
    }

    var scalar = (float)Math.Pow(1.0f - friction, quantum);
    Velocity *= scalar;
}
```

`TransientStateFlags.OnWalkable = 0x2` (FACT,
`references/ACE/Source/ACE.Server/Physics/PhysicsEngine.cs:11`) — matches
the decomp's `transient_state & 2` outer gate exactly, and matches
acdream's own `TransientStateFlags.OnWalkable` bit already.

**This resolves the "state gate" mystery differently than the register's
current framing.** ACE shows ONE linear function, not two branches — the
`state`/`MASK` test that BN rendered as two duplicated blocks is
`PhysicsState.Sledding` (`SLEDDING_PS = 0x800000`, confirmed **FACT** —
`acclient.h:2838` places it directly in the `PhysicsState` enum next to
`EDGE_SLIDE_PS = 0x400000`, and `references/ACE/Source/ACE.Server/Physics/PhysicsObj.cs:2130`
gates on exactly that flag with the exact same 1.5625/6.25/near-1.0
constants). The BN decompiler almost certainly duplicated a single
`if (state & SLEDDING_PS) { ... } ` block into what read as two
near-mirror branches — this is a known BN artifact class
(`feedback_bn_decomp_field_names.md`). **ACE-derived reading, mark
Ghidra-verify**: I could not confirm from the raw pseudo-C alone why the
branches read as fully separate blocks rather than one `if`; a live
Ghidra decompile of `0050ee70` would settle whether the source truly had
duplicated logic (possible if the original C++ had two near-identical
inlined call sites) or whether this is purely a BN rendering artifact. Do
not restructure the port around "two branches" — port ACE's single
linear shape; it is structurally consistent with every constant the raw
decomp independently confirms.

**The threshold-direction ambiguity (`p_5`/`p_1`/`p_2`/`p_3`/`p_4`, all
`test ah,0x5`-class x87 flag tests) is NOT independently Ghidra-verified
this pass** (Ghidra MCP is down). ACE's clean `if (angle >= 0.25f) return;`
is adopted as the **ACE-derived, Ghidra-verify** reading for `p_5`/`p_1`
polarity. The `p_2`/`p_3`/`p_4` velocity-magnitude-band and slope-flatness
polarities are likewise **ACE-derived, Ghidra-verify**.

**⚠️ Constant discrepancy found (FACT, needs Ghidra-verify to resolve):**
the raw decomp's slope test literally computes `__fcos(0.17453292519943295)`
(= cos(10°) ≈ 0.984808) and compares it against `contact_plane.N.z`.
ACE's port instead compares `ContactPlane.Normal.Z > 0.99999536f` directly
— no `cos()` call, and 0.99999536 corresponds to an angle of only
≈0.175° from flat (`acos(0.99999536) ≈ 0.175°`), not 10°. These are
**physically very different tests** (cos(10°) accepts any slope within
10° of flat; 0.99999536 accepts only essentially-perfectly-flat ground).
Two hypotheses, neither confirmed:
  (a) BN misdecompiled a raw float-constant load as an `__fcos()` call
      (a known BN artifact class — spurious x87 opcode reinterpretation);
  (b) ACE's own decompile/port made an independent error and
      `cos(10°)=0.984808` is correct.
  **Do not silently pick one.** File as an open Ghidra question (§7);
  when Ghidra MCP is back, decompile `0050ee70` directly and check
  whether the FCOS opcode is actually present at that instruction, or
  whether it's a raw `FLD` of `0.99999536` (or of `0.984808`).

### Why the L.3c naive threshold bump (0.0 → 0.25) hammered walking — and why that may no longer be true today (FACT + INFERENCE, high confidence, code-derived)

`src/AcDream.Core/Physics/PhysicsBody.cs:576-602` is acdream's current
`calc_friction`. Its threshold is **0.0** (`if (dot >= 0f) return;`),
attributed to the OLDER, unnamed Ghidra decomp (`FUN_0050f940` — a
DIFFERENT address than the named function `0050ee70`; the two decomp
passes disagree, and per CLAUDE.md the named decomp wins). The named
decomp's independently-confirmed **0.25f** (both branches) is FACT-level
confirmation that ACE's 0.25f reading — and the register's AP-7 row — are
correct, and acdream's in-code comment ("we match the decompile" at 0.0)
was matching the wrong (superseded, unnamed) decomp pass.

The recorded L.3c failure (2026-04-30): bumping the threshold alone to
0.25f, with NO other change, dropped measured forward locomotion from
~3 m/s to ~0.16 m/s (≈5.3% remaining) in
`PlayerMovementControllerTests`. The math checks out exactly:
`Friction = DefaultFriction = 0.95f` (confirmed **FACT** — both
`src/AcDream.Core/Physics/PhysicsBody.cs:120` and
`references/ACE/Source/ACE.Server/Physics/PhysicsGlobals.cs:15` agree on
`0.95f`, so this is NOT a divergent constant), and flat-ground walking
has `dot(velocity, groundNormal) ≈ 0` (velocity is ~horizontal, normal is
~vertical). With threshold 0.0, `dot(≈0) >= 0` triggers the early return
— friction NEVER engaged during flat walking. With threshold 0.25,
`dot(≈0) < 0.25` — friction ALWAYS engaged, decaying velocity by
`pow(1 − 0.95, dt)` = `0.05^dt` EVERY tick. At 60 Hz over 1 second:
`0.951^60 ≈ 0.049` — a ~95% velocity loss in one second. That is the
observed 3 → 0.16 m/s hammering almost exactly.

**INFERENCE, code-derived (high confidence, not yet live-verified):** the
L.3c test predates the 2026-07-17 "local player animation-owned grounded
movement" landing (R6). Reading current
`src/AcDream.Runtime/Gameplay/PlayerMovementController.cs:1742-1756`:

```csharp
if (_body.OnWalkable)
{
    float savedWorldVz = _body.Velocity.Z;
    if (hasAnimationRootMotion)
    {
        _body.Velocity = new Vector3(0f, 0f, savedWorldVz);   // <-- XY ZEROED
    }
    else
    {
        Vector3 stateVelocity = _motion.get_state_velocity();
        _body.set_local_velocity(
            new Vector3(stateVelocity.X, stateVelocity.Y, savedWorldVz),
            autonomous: _body.LastMoveWasAutonomous);
    }
}
...
_body.UpdatePhysicsInternal(tickDt);   // calls calc_friction internally
```

When the graphical client's animation root motion drives the walk
(`hasAnimationRootMotion == true`, the production path since R6),
`_body.Velocity.X/Y` are forced to **zero** immediately before
`calc_friction` runs every tick — because walking displacement now comes
from `pmDelta.Origin` (the animation Frame delta, applied directly to
`_body.Position` at lines 1764-1766), not from integrating `Velocity`.
**Friction decaying an already-zero horizontal Velocity is a no-op.** This
means the L.3c hammering mechanism is very likely ARCHITECTURALLY MOOT
for the production graphical local-player path today — the regression
that blocked AP-7 in April may not reproduce post-R6.

The `else` branch (no animation root motion — the headless/test-controller
path, `_motion.get_state_velocity()`) still feeds real XY speed into
`Velocity`, so that path (used by Slice K headless bots and any test
without an attached animation source) is still exposed to the same
hammering risk a naive threshold-only port would reintroduce.

**Action for the implementer, not yet executed by this research pass:**
before porting, re-run `PlayerMovementControllerTests` (or an equivalent
fresh capture) with a 0.25f threshold and the corrected ACE-derived
single-linear-function shape, checked separately against (a) the
graphical/animated local-player path, (b) the headless/`get_state_velocity`
path, and (c) remote/NPC movers (`RuntimeRemotePhysicsUpdater.cs`,
`RemoteMotion.cs` — confirm whether their Velocity is root-motion-zeroed
the same way, or whether they remain velocity-integrated and therefore
friction-sensitive). Do not assume (a) is safe without a fresh capture —
this section's confidence is code-derived, not measured.

### AP-7 verdict

**Port shape:** replace acdream's two-threshold, dead-Sledding-branch
`calc_friction` with ACE's single linear function (0.25f threshold, single
`friction = Friction` baseline, `PhysicsState.Sledding`-gated override
using the already-present 1.5625/6.25/near-flat constants — acdream
already has these at `PhysicsBody.cs:591-597`, just unreachable because
nothing ever sets the state bit; see §3). Flag the cos(10°) vs 0.99999536
discrepancy (Ghidra-verify) and pick ACE's `0.99999536f` provisionally
since acdream's own current dead code already uses it (least churn) —
**do not silently resolve the discrepancy by picking one without a
citation in the eventual commit; carry the open question into the
register row.**

## 2. TS-1 — PrecipiceSlide / EdgeSlide / CliffSlide chain

### ⚠️ Major finding: the register/plan framing is STALE — TS-1 is already substantially ported (FACT, code-verified)

The register row (`docs/architecture/retail-divergence-register.md:238`)
says: *"PrecipiceSlide context missing — conservative stop-at-edge
instead of retail's EdgeSlide → PrecipiceSlide / CliffSlide"*, citing
`TransitionTypes.cs:1254`. **Line 1254 today is unrelated stepping-loop
code (the viewer last-step-remainder computation)** — the file has moved
substantially since that row was written. Reading the actual current
implementation:

- `SpherePath.PrecipiceSlide(Transition)` — `TransitionTypes.cs:943-970`
  — a real port of `SPHEREPATH::precipice_slide` (pseudo-C:274316,
  `0050cc80`), calling `BSPQuery.FindCrossedEdge` (a real port of
  `CPolygon::find_crossed_edge`, pseudo-C:322909, `00539300` —
  `BSPQuery.cs:438-482`), sign-flipping via a dot product exactly like
  retail's `x87_r7_17` sign test, then delegating to
  `Transition.SlideSphereInternal` exactly like retail's tail call to
  `CSphere::slide_sphere`.
- `Transition.CliffSlide(Plane)` — `TransitionTypes.cs:2037-2102` — a
  real port of `CTransition::cliff_slide` (pseudo-C:272397, `0050a6d0`):
  cross product of the two plane normals, Z-flattened, rotated 90° in
  the XY plane (`(-Y, X, 0)`), degenerate-check, sign-resolved offset
  application via `SetCollisionNormal`. **Return-value mapping verified
  FACT-correct against `acclient.h:6100-6108`
  (`OK_TS=1, COLLIDED_TS=2, ADJUSTED_TS=3, SLID_TS=4`):** the degenerate
  case returns `TransitionState.OK` (matches retail's `return 1;` =
  `OK_TS`); the success case returns `TransitionState.Adjusted` (matches
  retail's `return 3;` = `ADJUSTED_TS`). This is correctly ported, not
  guessed.
- `Transition.EdgeSlideAfterStepDownFailed` — `TransitionTypes.cs:1907-2035`
  — a dispatcher structurally mirroring `CTransition::edge_slide`
  (pseudo-C:273001-273090, `0050b3d0`), including the AP-4-registered
  reordering (steep-contact-plane CliffSlide check moved before the
  `!OnWalkable || !EdgeSlide` bail, to compensate for acdream's
  OnWalkable bookkeeping — see DO-NOT-RETRY §0 item 9).

**This means TS-1's row and the P2 plan's "port the EdgeSlide → PrecipiceSlide
/ CliffSlide chain" framing describe work that is largely DONE.** The
register row was not retired in the same commit that landed this — a
process gap, not a code gap. **Recommend re-verifying with a live capture
before writing new code**, not blindly re-porting from scratch.

### Retail source, quoted in full (FACT, pseudo-C:273001-273090, `0050b3d0`)

```
TransitionState CTransition::edge_slide(arg2/*out*/, arg3=step_down_height, arg4=zVal) {
    state = object_info.state
    if ((state & 2) == 0 || (state.byte[1] & 2) == 0) {       // NOT walkable-capable / NOT EdgeSlide-capable
        walkable = null; check_pos = backup_check_pos; check_cell = backup_cell;
        contact_plane_valid = 0; contact_plane_is_water = 0;
        *arg2 = OK_TS; return cache_global_sphere(null);
    }
    if (contact_plane_valid) {
        p_1 = (contact_plane.N.z - arg4) ⋛ 0            // x87-ambiguous, ACE-derived: "N.z >= zVal"
        if (!p_1) {                                       // contact steeper than allowed (zVal = FloorZ or LandingZ)
            walkable = null; restore_check_pos();
            *arg2 = cliff_slide(this, &contact_plane);
            contact_plane_valid = 0; contact_plane_is_water = 0;
            return 0;
        }
        // else: falls through (contact IS walkable-steep-enough)
    }
    if (walkable != null) {
        restore_check_pos();
        contact_plane_valid = 0; contact_plane_is_water = 0;
        result = precipice_slide(sphere_path, collision_info);
        *arg2 = result;
        return (result == COLLIDED_TS);
    }
    if (contact_plane_valid) {                            // walkable was null, contact fell through as OK
        walkable = null; restore_check_pos(); cell_array_valid = 1;
        contact_plane_valid = 0; contact_plane_is_water = 0;
        *arg2 = OK_TS; return ...;
    }
    // ---- back-probe fallback: neither contact nor walkable available ----
    offset = global_curr_center - global_sphere.center;    // back toward where we came from
    add_offset_to_check_pos(offset);
    step_down(this, arg3, arg4);
    contact_plane_valid = 0; contact_plane_is_water = 0;
    restore_check_pos();
    if (walkable == 0) {
        walkable = null; *arg2 = COLLIDED_TS; cell_array_valid = 1; return ...;
    }
    contact_plane_valid = 0; contact_plane_is_water = 0;
    walkable_scale = sphere_path.walkable_scale;
    cache_localspace_sphere(get_walkable_pos(sphere_path), walkable_scale);   // <-- NOT PRESENT IN ACDREAM
    set_walkable_check_pos(sphere_path, localspace_sphere);                  // <-- NOT PRESENT IN ACDREAM
    result = precipice_slide(sphere_path, collision_info);
    *arg2 = result;
    return (result == COLLIDED_TS);
}
```

### Precise, evidenced gap #1: the back-probe fallback path skips retail's localspace re-cache before its second `precipice_slide` call (FACT)

Retail's edge_slide has **two distinct `precipice_slide` call sites**:
one direct (when `sphere_path.walkable != 0` already), one in the
back-probe fallback (when NEITHER a valid contact plane NOR a walkable
polygon survived) — and ONLY the second site performs
`walkable_scale`/`cache_localspace_sphere`/`get_walkable_pos`/
`set_walkable_check_pos` first (pseudo-C:274318-274326, `0050b4e0-0050b507`).

acdream's `SpherePath` has **no** `WalkableScale`, `LocalspaceSphere`,
`GetWalkablePos`, or `SetWalkableCheckPos` member/method anywhere
(confirmed by grep across `TransitionTypes.cs` — zero hits), and its
single unified `PrecipiceSlide(Transition)` method
(`TransitionTypes.cs:943-970`) is called identically from BOTH the
direct branch3 case (`TransitionTypes.cs:2002`, matches retail's first
call site correctly — no re-cache needed there either) AND the back-probe
fallback (`TransitionTypes.cs:2031`, **should** match retail's second
call site but is missing the re-cache step retail performs first).

**Port-ready shape (INFERENCE for the exact field semantics — the
walkable_scale/localspace-sphere machinery itself needs a fresh read of
`SPHEREPATH::get_walkable_pos`/`cache_localspace_sphere`/
`set_walkable_check_pos`, not yet read this pass; FACT that the gap
exists, INFERENCE on the fix shape):** add the three missing
`SpherePath` members/methods, call them in
`EdgeSlideAfterStepDownFailed`'s final fallback block
(`TransitionTypes.cs:2015-2031`) immediately before the
`sp.PrecipiceSlide(this)` call at line 2031, matching retail's ordering.
`get_walkable_pos`/`cache_localspace_sphere`/`set_walkable_check_pos`
were not read this pass (budget) — **read them fresh before porting**
(pseudo-C, search near `SPHEREPATH::get_walkable_pos` — a hit already
appears in the `edge_slide` grep at the top of this section's raw quote,
so the symbol exists and is findable).

### Precise, evidenced gap #2 (likely unregistered adaptation, not a bug per se): `CliffSlide`'s reference-normal fallback chain is an acdream invention (FACT: not in the retail read; adaptation reasoning IS documented in-code)

Retail's `cliff_slide` (pseudo-C:272397) uses
`this->collision_info.last_known_contact_plane.N` **directly, with no
fallback chain** as the second cross-product operand. acdream's
`CliffSlide` (`TransitionTypes.cs:2037-2070`) instead tries THREE
sources in priority order: `LastWalkablePlane` (if `Normal.Z >= FloorZ`),
then `LastKnownContactPlane` (same threshold), then `Vector3.UnitZ`
world-up. The in-code comment ("L.4-cliffslide-fallback", dated
2026-04-30) explains the reasoning (degenerate cross-product when the
player has been on a continuous steep slope for >1 frame and
`LastKnownContactPlane` itself became steep) but **this reasoning does
not appear to have a corresponding register row** (checked AP-4, TS-1 —
neither mentions the fallback chain specifically; AP-4 is about
re-ordering the CliffSlide-vs-Branch1 check, a different concern).
**Flag for the implementer:** either (a) find this exact
prioritization in a further retail read (unlikely given the raw decomp's
directness, but not yet exhaustively ruled out — `last_known_contact_plane`
itself might be retail-maintained differently than acdream's equivalent
field, which could make the fallback chain compensate for an upstream
divergence rather than being a pure invention), or (b) register it
explicitly as an AD/AP row with this citation before or alongside the P2
commit. Do not silently leave an unregistered behavioral invention in
place while "retiring" the TS-1 row — that violates the register's
same-commit rule.

### Precise, evidenced gap #3 (likely unregistered adaptation): the walkable-polygon steepness reroute in `EdgeSlideAfterStepDownFailed`

`TransitionTypes.cs:1972-1997` — when `sp.HasWalkablePolygon` is true,
acdream additionally checks `sp.WalkablePlane.Normal.Z < FloorZ` and, if
so, reroutes to `CliffSlide(sp.WalkablePlane)` INSTEAD of calling
`PrecipiceSlide`. Retail's raw `edge_slide` (`if (walkable != null) { ...
precipice_slide(...) }`) has **no steepness branch on the walkable
polygon itself** — it always calls `precipice_slide` once `walkable !=
null`. The in-code comment ("L.4-walkable-steep") argues this compensates
for acdream's Path-4 airborne-landing branch accepting steep roofs as
"walkable" under the permissive `LandingZ` threshold (a claim this
research pass did not independently verify — Path-4 was not read this
session; TS-4 §4 below covers the adjacent but distinct Path-6 concern).
**Flag for the implementer:** same as gap #2 — verify whether this
reroute is compensating for a real upstream divergence (in which case it
should be an AD/AP row) or is masking a bug that should be fixed at its
source (Path-4's LandingZ acceptance) instead of patched here. Do not
retire TS-1 while leaving this unregistered.

### TS-1 verdict

**Port shape:** narrow, not a rewrite. (1) Add the retail
`walkable_scale`/`cache_localspace_sphere`/`get_walkable_pos`/
`set_walkable_check_pos` step to the back-probe fallback path only (gap
#1 — a real, missing piece). (2) Audit gaps #2 and #3 against a fresh,
focused retail re-read of `last_known_contact_plane` maintenance and the
Path-4 landing-acceptance threshold; register whichever holds up as
AD/AP rows, or align to retail exactly if the compensation turns out
unnecessary. (3) Only THEN retire the TS-1 register row, in the same
commit, updating its citation (the current `:1254` citation is already
stale and should point at `EdgeSlideAfterStepDownFailed`/`CliffSlide`/
`PrecipiceSlide` instead). **Do not** re-derive `edge_slide`/`cliff_slide`/
`precipice_slide` from scratch — the existing port is real and largely
correct; re-porting risks discarding correct, already-tested work (the
CLAUDE.md worldbuilder-inventory lesson applies here by analogy: don't
re-port what's already ported and tested).

## 3. #166 — landing sled (Sledding state set/clear)

### Finding: `PhysicsState.Sledding` appears to be DATA-AUTHORED, not an automatic landing response (FACT, cross-referenced across 3 independent repos)

Searched for a SET (`|= SLEDDING_PS`) or automatic-toggle call site for
`PhysicsState.Sledding` in: the named-retail pseudo-C (no string "sled"
anywhere in the 1.4M-line file — `grep -in sled` returns zero hits; the
raw `0x800000` hex literal also returns zero physics-related hits, only
unrelated Watson/crash-dump flags), `references/ACE/Source/ACE.Server/Physics/PhysicsObj.cs`
(full file, only 3 hits: the two `calc_friction`/`UpdateObjectInternal`
READ sites already covered, no WRITE site), and
`references/ACViewer/ACE/...` (same ACE-derived code, same result).

The only WRITE sites for `PhysicsState.Sledding` anywhere in any
reference repo are:

```csharp
// references/ACE/Source/ACE.Server/WorldObjects/WorldObject_Properties.cs:1105-1109
public bool? Sledding
{
    get => GetPhysicsState(PhysicsState.Sledding);
    set => SetPhysicsState(PhysicsState.Sledding, value);
}
```

— a per-weenie boolean **game-data property** (the same pattern as
`Ethereal`, `Static`, etc.), packed onto the broadcast `PhysicsState` in
`WorldObject_Networking.cs:586-588,700-704`. This is server/database-set,
not a client-side automatic landing-response toggle. Since `CPhysicsObj`
is shared code between the retail client and server binaries (the same
class that produced `calc_friction`, `UpdateObjectInternal`, etc. — all
independently confirmed to structurally match ACE's port), the total
ABSENCE of a write site anywhere in ACE's ~10,000-line `PhysicsObj.cs`
is strong evidence that retail's own `CPhysicsObj` **does not
automatically enter Sledding state on a downhill landing either.**

**INFERENCE (well-supported, not yet cdb/Ghidra-confirmed):** ordinary
downhill-jump glide-and-bounce in retail is NOT the literal `Sledding`
physics state at all for an ordinary player. `Sledding` is most likely
reserved for specific data-authored world content (dungeon/event objects
with the property baked into their weenie default `PhysicsState`, e.g.
an actual in-world "sled ride" mechanic) — a narrow, data-driven case
outside a generic movement port's scope. Grepping WCID/weenie class name
lists in `references/ACViewer/ACE/.../WeenieClassName.cs` for "sled"
found no obviously-named sled-ride weenies, but that catalog is not
exhaustive for retail's original 2013 content and this was not chased
further (out of scope — data content, not an algorithm).

### Cross-check against ISSUES.md #166's OWN root-cause text (FACT)

`docs/ISSUES.md:4254-4262` (filed 2026-07-03, i.e. BEFORE the P2 campaign
plan's phrasing) already attributes #166 to a **named composite of three
rows**, and explicitly does **not** mention a Sledding set/clear
mechanism:

> "This is the REGISTER-PREDICTED composite of three known deferred
> deviations: **AD-25** (landing wall-bounce velocity reflection
> suppressed...), **AP-7** (`calc_friction` threshold 0.0 without
> retail's 0.25-with-state-gate...), and **TS-4** (Path-6 steep-poly
> slide-tangent shortcut...). Retiring those three rows IS this issue."

Cross-referencing the digest's #182 rebuild notes
(`memory/project_physics_collision_digest.md:837-841`, 2026-07-07):
**AD-25's LOCAL-PLAYER landing-bounce reflection was already ported** in
the #182 verbatim `UpdateObjectInternal`/`handle_all_collisions` rebuild
("Contact committed BEFORE the reflect... retire AD-25's micro-bounce
(AD-25 narrowed to the remote-DR sweep)"). What remains open for AD-25 is
**remote/NPC-only** and is explicitly P3 scope
(`docs/plans/2026-07-29-physics-parity-campaign.md` §P3 item 2), not P2.

**#166 verdict:** for the LOCAL PLAYER (the case the user actually
reported — "jumping down a hill" on their own character), the bounce
half (AD-25) is already shipped; what's missing is the glide-deceleration
curve (AP-7, §1 above) and the airborne-steep landing chain (TS-4, §4
below). Porting AP-7 + TS-4 correctly should retire #166 for the local
player WITHOUT inventing any client-side Sledding auto-toggle — inventing
one would be exactly the kind of unargued behavior addition CLAUDE.md's
no-guessing rule forbids (no decomp evidence supports it). The campaign
plan's P2 item 3 phrasing ("port the landing sled (Sledding state
set/clear sites)") appears to rest on an assumption not borne out by this
research pass.

**Recommendation for the implementer:** do NOT build a Sledding
auto-set/clear mechanism speculatively. Land AP-7 + TS-4 first, capture a
fresh downhill-jump-landing trajectory (extend
`ACDREAM_CAPTURE_RESOLVE`), and check the #166 visual-matrix item (row 5,
"Downhill jump landing: sled glide + bounce") against that alone. If the
glide/bounce still visibly mismatches retail after AP-7+TS-4 land, THAT
capture — not a guess — is what should drive any further Sledding-state
work, and it should go through cdb against live retail (a downhill jump
landing, watching `this->state` for the `0x800000` bit) before any client
auto-toggle is written. Keep the already-present dead
`PhysicsStateFlags.Sledding` branch in `calc_friction` (§1) since it's
cheap, decomp-consistent, and harmless if never entered — but do not
manufacture a caller that sets it.

## 4. TS-4 — Path-6 steep-poly shortcut removal

### The former shortcut (HISTORICAL FACT; removed by Slice 2B)

Before Slice 2B, Path-6 (the default
`sphere_intersects_poly → collide_with_pt / SetCollide` dispatch) was not
symmetrically wrong. The parsed-graph primary/foot branch tested the hit
polygon's world-space normal and, below `PhysicsGlobals.FloorZ`, projected
the move along the face, wrote both collision and sliding normals, and
returned `Slid`. Its secondary/head branch had already been corrected by
#116 to retail's unconditional `CollisionNormal` + `Collided` response. The
prepared-flat port still applied the steep shortcut to both spheres and sent
both shallow cases through `SetCollide` + `Adjusted`; its head branch was
therefore wrong for every slope. This distinction matters: retail does not
apply one common response to both spheres.

The in-code comment is unusually candid about why: **"This is a
deliberate deviation from retail... Validated against retail debugger
trace 2026-04-30: retail body did not wedge; our retail-faithful port DID
wedge because we're missing implementation details of the step_up_slide /
cliff_slide chain on grounded-steep movement."** — i.e., this shortcut
was shipped SAME-DAY as (and BECAUSE) the retail-faithful
`EdgeSlideAfterStepDownFailed`/`CliffSlide`/`PrecipiceSlide` chain (TS-1,
§2 above — also dated 2026-04-30, tagged "L.4") still wedged in testing
when tried without this shortcut.

### Retail: NO steepness branch in either Path-6 sphere response (FACT, `0053a730` region)

Read directly from the named decomp (the `sphere_intersects_poly` /
`set_collide` dispatch for the primary/foot sphere inside
`BSPTREE::find_collisions`'s default path):

```
if (sphere_intersects_poly(...) || eax_26 != 0) {
    localtoglobalvec(sphere_path.localspace_pos, &saved_ebx, &poly->plane.N);
    SPHEREPATH::set_collide(&sphere_path, &saved_ebx);
    sphere_path.walkable_allowance = 0.0871556997f;   // = PhysicsGlobals.LandingZ, exact bit match
    return 3;   // ADJUSTED_TS
}
```

**There is no steepness test in this foot branch.** It calls `set_collide`
and returns `ADJUSTED_TS` for a steep roof exactly as for a shallow ramp.
`walkable_allowance` is always set to `LandingZ` (the permissive landing
threshold), regardless of polygon slope. If the foot is clear but the
secondary/head sphere hits, retail instead performs the other slope-agnostic
response:

```
localtoglobalvec(sphere_path.localspace_pos, &normal, &head_poly->plane.N);
COLLISIONINFO::set_collision_normal(&collision_info, &normal);
return 2;   // COLLIDED_TS
```

The head branch neither calls `set_collide` nor returns `ADJUSTED_TS`.
Neither sphere response has a steepness branch. This directly confirms the P2
plan's description and the digest's #137-mechanism-2 finding
(`memory/project_physics_collision_digest.md:1008-1014`): **retail's
BSP/sphere collision layer never writes `collision_info.sliding_normal`
at all** — only `validate_transition` (0x0050ac21/0x0050aa70) does, and
only success-gated. The steepness differentiation (walkable vs.
merely-in-contact, and whether a slide response is needed) happens
STRICTLY DOWNSTREAM, in `ValidateTransition`'s `FloorZ` OnWalkable test
and — when that surface turns out too steep to be walkable —
`EdgeSlideAfterStepDownFailed` → `CliffSlide`/`PrecipiceSlide` (TS-1's
domain, §2 above).

### TS-4 port shape (COMPLETED 2026-07-31)

Delete the primary/foot steep shortcut in both representations. Every foot
hit must call `SetCollide`, set `WalkableAllowance=LandingZ`, and return
`Adjusted`. Preserve the parsed-graph head branch corrected by #116, and
replace the prepared-flat head steep/shallow split with the same unconditional
`SetCollisionNormal` + `Collided` response. No Path-6 branch writes a sliding
normal. This is the exact retail foot/head split, not a shared fallback to the
foot behavior.

### Port-order coupling with TS-1 (historical guard, now satisfied)

**This is the single most important sequencing fact in this whole
document.** The shortcut's comment proves TS-1's retail-faithful chain
was ALREADY BUILT once (same day, same "L.4" slice) and STILL wedged —
that is why the shortcut exists instead of the faithful chain. Simply
deleting the shortcut today, without first confirming TS-1's gaps (§2:
missing localspace re-cache in the back-probe fallback; the two
unregistered adaptations) are closed, risks reintroducing the EXACT
"stuck in falling animation on the roof" / "walks up steep roofs" wedge
that motivated the shortcut in the first place.

**Recommended order:** (1) close TS-1 gap #1 (the missing
`walkable_scale`/`cache_localspace_sphere`/`set_walkable_check_pos` step)
first, on its own, with the TS-4 shortcut still in place as a safety
net. (2) Capture a grounded-steep-slope trajectory (a roof or steep
terrain walk, matching whatever repro the 2026-04-30 L.4 session used —
check `docs/research/` and git log around that date for the specific
repro if it wasn't captured as a fixture) with the shortcut TEMPORARILY
disabled behind a flag or in a scratch branch, and confirm no wedge. (3)
Only once that capture is clean, delete the TS-4 shortcut for real, in
the same commit that closes the TS-4 register row. (4) Re-run the P2
final-matrix items 4-6 (cliff/roof edge, downhill landing, shallow wall
graze) plus a fresh regression sweep before calling TS-4 done — this is
exactly the kind of change the digest's #137 sagas warn compounds subtly
(a leaked `SetSlidingNormal` "absorbing wedge at empty space" was the
recurring failure mode across three separate historical incidents in the
digest, all triggered by a similar not-quite-faithful shortcut).

## 5. #116 — slide-response family oracle pass

This item is explicitly an **oracle-first investigation**, not a known
fix (`docs/ISSUES.md:8426` status: "OPEN (narrowed)"; digest
`memory/project_physics_collision_digest.md:1509`: "OPEN — oracle-first
investigation; NOT cell-set"). This section defines the SCOPE of the
oracle pass precisely, per the mission's request, rather than proposing
a fix — a fix without the live trace below would repeat the exact
mistake the digest's DO-NOT-RETRY table already warns against (§0 items
4, 7, 8).

### The two shapes (FACT, restated with citations — both already
independently verified against source by the 2026-06-12 Ghidra session)

**Shape-1 — tick-22760 lateral-slide loss.** Live retail: blocked
southward push at a cottage door face, KEPT a tiny lateral slide (X
−0.0357 m, `collision_normal=(0,+1,0)`, the door face). acdream's harness
hard-stops both components (`collision_normal=(0,0,1)`, i.e. the
`UnitZ` ground-fallback default). Ghidra-confirmed
(`memory/project_physics_collision_digest.md:1259-1275`):
`TransitionTypes.cs:3701-3702`'s `UnitZ` default on invalid
collision-normal is **retail-faithful** — retail's `validate_transition`
(`0x0050aa70`) has the identical `if (collision_normal_valid==0)
set_collision_normal(UnitZ)`. **The divergence is UPSTREAM of both slide
and validate**: at tick-22760, acdream's `collision_normal_valid` was
FALSE where retail's was TRUE (retail HAD recorded the door-face normal).
The slide guard threshold is exonerated — the 3.57 cm lost slide is
~18× above the ~1.4 cm degenerate-offset cutoff (`F_EPSILON` = 0.0002,
compared against SQUARED magnitude — Ghidra-confirmed, see §0 item 8),
so retail's own guard would have kept the slide too.

**Shape-2 — D4 first-airborne-frame slide vs. hard-stop.** Ghidra
confirms `CSphere::slide_sphere` (`0x00537440`) applies its slide
IN-FRAME (`add_offset_to_check_pos` → returns `SLID_TS`) — acdream's
current in-frame slide to Z=1.92 on frame 1
(`BSPStepUpTests.D4_AirborneMover_TallWall_PersistsSlidingNormalAcrossFrames`,
`tests/AcDream.Core.Tests/Physics/BSPStepUpTests.cs:560-602`, currently
`Skip`-tagged citing #116) is **likely faithful TO `slide_sphere`
itself**. What's unconfirmed is whether retail's first airborne wall
contact frame REACHES `slide_sphere` at all, or whether an earlier stage
(`collide_with_environment`'s dispatch, or the absence of a
`last_known_contact_plane` on the very first airborne frame) intercepts
it with a hard stop before `slide_sphere` ever runs. The #116 threshold
fix (`EpsilonSq` → `F_EPSILON`, shipped `bf18a543`) did **not** move D4 —
confirming the D4 offset is a real slide, not a near-degenerate one the
threshold fix would have caught.

### What the P2 oracle pass must determine (mission-specified scope)

1. **Shape-1's real root cause: where does acdream's collision-normal
   RECORDING diverge from retail's at tick-22760?** Not slide_sphere, not
   validate_transition (both exonerated) — the recording path that feeds
   `collision_info.collision_normal_valid`/`.collision_normal` during the
   BSP/environment hit-test itself. The digest's own next-step
   (`memory/project_physics_collision_digest.md:1274-1275`) is unchanged
   by this research pass: **instrument
   `DoorBugTrajectoryReplayTests.Diagnostic_Tick22760_DumpEngineInternals`**
   (`tests/AcDream.Core.Tests/Physics/DoorBugTrajectoryReplayTests.cs:162`)
   to trace exactly where, in the BSP hit-test chain feeding
   `FindObjCollisionsInCell`/`BSPQuery`, the door-face normal
   `(0,+1,0)` gets computed-and-discarded in acdream but retained in
   retail. Candidate governing retail functions (need a fresh, focused
   read — not done this pass, budget): `BSPTREE::find_collisions`
   (the same dispatch region read for TS-4 in §4, pseudo-C ~323700-323830)
   and whatever populates `collision_info.collision_normal`/
   `.contact_plane` on a BLOCKED (not slid, not adjusted) door-face hit
   specifically — this is a DIFFERENT code path than either Path-6's
   `set_collide` (which returns ADJUSTED_TS, not COLLIDED_TS) or
   `slide_sphere` (called only after a walkable/precipice context
   exists). A blocked door push is most likely dispatched through
   `CollideWithPt`/`collide_with_pt` (the `PathClipped` branch already
   visible in Path-6, §4, `BSPQuery.cs:2158-2163`) or a sibling
   `Path-1`-class function not yet read this pass.
2. **Shape-2's real answer: does retail's FIRST airborne wall-contact
   frame reach `slide_sphere`, or hard-stop upstream?** This needs either
   a Ghidra decompile of the caller chain immediately above
   `slide_sphere` (checking whether a `last_known_contact_plane`
   existence gate exists before the call on frame 1 of an airborne
   trajectory) or a live cdb trace of an actual airborne wall hit in
   retail (per the digest's already-written cdb plan,
   `memory/project_physics_collision_digest.md:8537-8543` /
   ISSUES.md #116). Ghidra MCP is down this pass — **do not guess this
   one; it directly controls which of D4's two competing expectations
   (Z=1.92 in-frame slide vs. Z=2.0 hard-stop-then-slide-frame-2) is
   correct**, and a wrong guess "regresses ALL wall-slide behavior" per
   the digest's own warning (§0 item 8).
3. **Governing retail functions to anchor the oracle pass (FACT, already
   cited in ISSUES #116 and this document's own reads):**
   `CSphere::slide_sphere` (`0x00537440`, pseudo-C:321403-321532 per
   ISSUES #116's own citation — not re-read this pass, already
   Ghidra-verified for the epsilon fix), `validate_transition`
   (`0x0050aa70`, read indirectly via its `UnitZ` default confirmed in
   §2/§4's cross-references), and the `find_collisions`/environment
   hit-test recording sites this pass identified as the likely Shape-1
   location (`BSPTREE::find_collisions` region, pseudo-C ~323700-323830,
   the same region TS-4 §4 already partially read for the unconditional
   `set_collide` call — a focused re-read of the SIBLING branches in
   that same dispatch, specifically the `PathClipped`/`collide_with_pt`
   arm and whatever arm produces a hard COLLIDED_TS with a recorded
   normal, is the concrete next research step).

### #116 verdict — this is NOT a P2 implementation item, it is a P2
research item with its own follow-up research session

Given the depth already logged in the digest and ISSUES.md (an entire
Ghidra session, a threshold fix already shipped, two shapes precisely
characterized, and an explicit "needs a LIVE cdb session" conclusion
reached independently by that prior work), **this research pass concurs
with the existing plan of record**: #116 needs (a) an instrumented
replay of `DoorBugTrajectoryReplayTests` for shape-1, and (b) either a
Ghidra decompile of `slide_sphere`'s caller chain or a live cdb trace of
an airborne wall hit for shape-2, BEFORE any code changes. **Do not**
patch the degenerate-offset guard, the `UnitZ` default, or `slide_sphere`
itself speculatively (DO-NOT-RETRY §0 items 4, 7, 8 all apply directly).
This document does not add new pseudocode for #116 beyond what's already
recorded, because doing so without the trace would be exactly the kind
of guess CLAUDE.md's workflow forbids.

## 6. Port order + blast radius

Recommended sequence, reasoning, and required fixtures/captures BEFORE
each step's behavior change — not a generic "do them in plan order"
list, because this research pass found real coupling the plan's slice
ordering doesn't surface.

### Step 1 — TS-1 gap #1 (localspace re-cache in the back-probe fallback), §2

**Do this FIRST, alone.** It's the narrowest, most mechanically certain
change (a missing setup step before an existing call, not a behavior
redesign), and per §4's coupling analysis, TS-4's shortcut removal is
UNSAFE until this lands and is proven not to wedge. Blast radius: only
the back-probe fallback arm of `EdgeSlideAfterStepDownFailed` — the
rarest of the four dispatch arms (reached only when neither a contact
plane nor a walkable polygon survived the step-down probe). Low risk of
regressing the already-working branch3/branch1/branch2 arms.

**Required before/after:** a targeted unit test exercising the back-probe
arm specifically (check whether one already exists — this pass didn't
find one in `BSPStepUpTests.cs`/`DoorBugTrajectoryReplayTests.cs`; if
absent, write one first per TDD discipline). No connected capture needed
for this step alone — it's a narrow internal-consistency fix.

### Step 2 — TS-1 gaps #2 and #3 (register audit), §2

Read the raw decomp fresh for `last_known_contact_plane` maintenance
(what writes it, and whether acdream's equivalent field diverges upstream
— which would justify gap #2's fallback chain as a real compensating
adaptation) and for Path-4's airborne-landing `LandingZ` acceptance logic
(cited but not read this pass — needed to judge gap #3). Either register
both as AD/AP rows with citations, or remove the acdream-only branches
and re-verify against the existing CliffSlide/PrecipiceSlide test
coverage. This step can run in parallel with Step 1 (different files,
no shared state — a candidate for `superpowers:dispatching-parallel-agents`
if the implementer wants to split it out).

### Step 3 — capture a steep-slope / roof trajectory with TS-4's shortcut disabled

Before touching `BSPQuery.cs`, build a scratch/flagged path that runs
Path-6 WITHOUT the steepness branch (i.e., always `SetCollide` +
`WalkableAllowance=LandingZ` + `Adjusted`, matching retail) and replay
whatever fixture reproduces the original "stuck in falling animation on
the roof" / "walks up steep roofs" symptom the 2026-04-30 L.4 session
used to justify the shortcut. **Find that fixture/repro before writing
new code** — check `docs/research/2026-04-30-*` and git log around that
date; if no fixture survives, this step needs a fresh capture via
`ACDREAM_PROBE_RESOLVE=1` against a known steep-roof landblock. Do not
skip this step even though Step 1 theoretically closes the gap that
caused the original wedge — "theoretically closes" is not "proven not
to wedge," and this exact failure mode (a not-quite-faithful shortcut
masking a deeper gap) has recurred at least three times in the digest's
own history (#137 mechanisms 1-3).

### Step 4 — land TS-4 (delete the shortcut) only after Step 3 is clean

Small, mechanical diff once Step 3 validates it's safe (§4's port shape).
Retire the TS-4 register row in the same commit.

### Step 5 — AP-7, independently sequenced (no coupling to Steps 1-4)

AP-7 touches `PhysicsBody.calc_friction` only — a different file, no
shared call path with the TS-1/TS-4 edge-response chain (friction runs
on GROUNDED, already-resolved velocity; TS-1/TS-4 run during the
collision SWEEP itself, upstream of where friction applies). Can be
done in parallel with Steps 1-4. **Required before any code change**:
re-run (or write, if it doesn't already isolate the right thing) a
regression test capturing (a) graphical/animated local-player grounded
walk speed (§1's finding: likely unaffected today, but UNVERIFIED —
confirm before claiming victory), (b) headless/`get_state_velocity`-path
grounded walk speed (§1's finding: likely STILL exposed to the original
L.3c hammering mechanism — this is the one that needs the real fix, not
just the threshold), and (c) a remote/NPC mover sample
(`RuntimeRemotePhysicsUpdater.cs`/`RemoteMotion.cs` — not audited this
pass for Velocity-zeroing behavter; check before assuming safety).

### Step 6 — #166 visual check, after Steps 1-5

Per §3's verdict: #166 is very likely closed BY PROXY once AP-7 (Step 5)
and TS-4 (Step 4) land — no new code needed beyond those two. Verify
against the P2 visual-matrix item 5 (downhill jump landing) LAST, using
a fresh `ACDREAM_CAPTURE_RESOLVE` trajectory. Only if it still visibly
mismatches retail after Steps 1-5 does #166 need further work, and that
further work should be capture-driven, not a speculative Sledding
auto-toggle (§3's explicit recommendation).

### Step 7 — #116, separately scoped, own research session

Per §5's verdict, this is not an implementation step at all yet — it
needs its own instrumented-replay session (shape-1) and a
Ghidra-availability-gated or live-cdb session (shape-2) before any
pseudocode can be written. Sequence-independent of Steps 1-6 (different
root cause layer — collision-normal recording, not response), but
shares the same `slide_sphere`/`validate_transition` machinery TS-1
depends on, so land it AFTER Steps 1-4 settle to avoid two people
touching `TransitionTypes.cs`'s collision-normal plumbing at once.

### Fixtures/tests that must exist BEFORE any behavior change lands (mission requirement, consolidated)

- A back-probe-arm-specific unit test for TS-1 Step 1 (write if absent).
- The steep-roof/wedge repro fixture for TS-4 Step 3 (locate or
  recapture).
- AP-7's three-way regression test (graphical/animated, headless
  state-velocity, remote/NPC) for Step 5.
- A fresh `ACDREAM_CAPTURE_RESOLVE` downhill-landing trajectory for #166
  Step 6.
- An instrumented `DoorBugTrajectoryReplayTests` capture for #116
  shape-1 (Step 7) — extend the existing
  `Diagnostic_Tick22760_DumpEngineInternals` rather than writing a new
  harness.
- Existing coverage that must NOT regress: `SphereCollisionFamilyTests`,
  `Issue137CorridorSeamReplayTests`, `Issue137SlidingNormalLifecycleTests`,
  `WindowOpening_HeadCannotFit_EntryBlocked`, and the full
  `BSPStepUpTests`/`DoorBugTrajectoryReplayTests` suites (D4 stays
  `Skip`-tagged until #116 shape-2 is actually resolved by evidence, not
  by this campaign's other changes incidentally shifting its numbers).

## 7. Open questions needing Ghidra/cdb (not guessed here)

Consolidated from all five sections above, each tagged with which item
it blocks.

1. **[AP-7]** Is the BN-rendered "two duplicated branches" in
   `calc_friction` (pseudo-C:276694-276822) a genuine BN decompiler
   artifact (single retail `if (state & SLEDDING_PS)` block misrendered),
   or does retail's actual source have two structurally separate paths?
   A live Ghidra decompile of `0050ee70` settles it. Low implementation
   risk either way (ACE's single-linear-function reading is adopted
   regardless), but affects how confidently the port shape can be
   described as "verified" vs. "ACE-derived."
2. **[AP-7]** The `p_5`/`p_1` polarity (does the friction-apply branch
   trigger on `dot < 0.25` or `dot >= 0.25`?) and the `p_2`/`p_3`/`p_4`
   velocity-magnitude-band/slope-flatness polarities are all
   `test ah,0x5`-class x87 flag tests, none independently Ghidra-verified
   this pass. ACE's clean reading is adopted as ACE-derived; a Ghidra
   decompile of `0050ee70` (same function as item 1) would settle all of
   these at once.
3. **[AP-7]** The `cos(10°)` (raw decomp) vs. `0.99999536f` (ACE)
   discrepancy in the Sledding slope-flatness test — genuinely different
   physical behaviors, not a rounding difference. Needs a Ghidra
   decompile of `0050ee70` checking whether the FCOS opcode is real or a
   BN misread of a raw float constant load. Currently unresolved; §1
   provisionally recommends ACE's `0.99999536f` (least churn from
   acdream's existing dead code) but flags this explicitly as
   unconfirmed.
4. **[TS-1 gap #1]** `SPHEREPATH::get_walkable_pos`,
   `cache_localspace_sphere`, and `set_walkable_check_pos` were located
   (symbol exists, called at pseudo-C:274318-274326) but NOT read this
   pass (effort budget). A fresh grep-and-read of these three functions
   is needed before porting Step 1 — this is a same-tool (grep-named)
   follow-up, not a Ghidra/cdb blocker; flagged here only so it isn't
   lost.
5. **[TS-1 gaps #2, #3]** Whether `last_known_contact_plane` maintenance
   and Path-4's `LandingZ` acceptance logic genuinely diverge from
   retail (justifying acdream's CliffSlide fallback chain and the
   walkable-steepness reroute as real compensating adaptations) or
   whether they're unnecessary inventions. Needs a fresh, focused
   named-decomp read (not Ghidra/cdb-gated — just not done this pass).
6. **[TS-4 / Step 3] ANSWERED 2026-07-30 (implementation session) — NOT
   sufficient; the wedge reproduces, and its mechanism is now precisely
   characterized.** TS-1's gap #1 fix (this document's §2, landed the same
   session) does NOT unblock TS-4. A dat-free multi-frame capture
   (`tests/AcDream.Core.Tests/Physics/Ts4SteepRoofWedgeCaptureTests.cs`,
   using `BSPStepUpFixtures.SlopedUnwalkable`'s 63.4° slope,
   `PhysicsEngine.ResolveWithTransition` replayed at 30 Hz with gravity
   integrated between resolves — the same replay idiom as
   `Issue185OutdoorStairsSeamReplayTests`) reproduces the EXACT historical
   shape with the Path-6 steep shortcut temporarily removed (both
   `BSPQuery.cs` sphere0/sphere1 branches): the body falls cleanly (30
   ticks, position advancing every tick), lands at
   `(0.500, 0.000, 1.247)` at tick 17 with `InContact=true, OnWalkable=false`
   (confirming the steep polygon WAS accepted via the permissive
   `CTransition::check_walkable(0.0871556997f)` / `LandingZ` gate exactly
   as predicted from the retail source read below), then **freezes at that
   exact position for the remaining 16+ ticks with zero movement** — the
   test's own wedge-detection threshold (>15 consecutive frozen ticks =
   >0.5s) trips at tick 33. With the shortcut restored, the same test is
   green (the shortcut's explicit `AddOffsetToCheckPos` keeps the body
   moving every tick by construction). **The shortcut stays; TS-4 is NOT
   retired this session.**

   **Root-cause diagnosis (`ACDREAM_DUMP_EDGE_SLIDE=1` capture against the
   scratch shortcut-removed build):** the freeze is NOT inside
   `EdgeSlideAfterStepDownFailed`/`CliffSlide` at all — none of that
   dispatch's diagnostic lines (`DumpEdgeSlideBranch`,
   `DumpStepDownBranchGate`, the `[steep-roof] PHASE3-RESET*` lines) fire
   even once during the frozen ticks. Every frozen tick instead logs only
   `edge-slide: phase2 attempt=0 env=OK obj=Adjusted` followed by
   `attempt=1 env=OK obj=Adjusted` — i.e. `TransitionalInsert`'s Phase 2
   object-collision check (`FindObjCollisionsInCell`, `TransitionTypes.cs:1572`)
   returns `Adjusted` on BOTH retry attempts, and per
   `TransitionTypes.cs:1591-1596` an `Adjusted` `objState` unconditionally
   `continue`s (retries Phase 1/2 from the top) rather than falling through
   toward Phase 2.5/Phase 3. **Phase 3 — the `if (sp.Collide) { ... }`
   block at `TransitionTypes.cs:1625` that contains the `DoCheckWalkable`
   Placement re-test AND (on walkable failure) the reset-with-conditional-
   `kill_velocity` path — is gated on Phase 1 AND Phase 2 BOTH returning
   `OK` simultaneously (`TransitionTypes.cs:1568-1621`). Path 6's own
   unconditional `SetCollide` (the retail-faithful code path TS-4 would
   restore) returns `Adjusted`, not `OK` (matching retail's own
   `return 3; // ADJUSTED_TS` at pc:323783, quoted in §4 above) AND does
   NOT itself reposition the sphere** — unlike the interim shortcut, which
   explicitly calls `AddOffsetToCheckPos` to push the sphere off the face
   every time it fires. With no repositioning, the SAME steep polygon at
   the SAME distance re-triggers Path 6 on the immediate retry, which
   again returns `Adjusted`, forever — an Adjusted↔retry oscillation at a
   fixed point that the loop's 2-attempt-per-resolve budget silently
   absorbs (returning the frozen position as though the resolve
   succeeded), repeating identically on every subsequent tick's fresh
   resolve call. **Phase 3 (and therefore `DoCheckWalkable`,
   `CliffSlide`, and the TS-1 chain entirely) is structurally unreachable
   from this state** — TS-1's completeness is moot here because the code
   path that would call into it never runs.

   **What this means for a future attempt:** the missing piece is NOT
   (only) in `EdgeSlideAfterStepDownFailed`/`CliffSlide` — it is in how
   `TransitionalInsert`'s Phase 1/2/2.5/3 dispatch (`TransitionTypes.cs
   :1568-1710`) distinguishes "Phase 2 found a NEW collision, retry from
   the top" from "Phase 2 registered a touch via `sp.Collide` and should
   fall through toward Phase 3 regardless of its own `Adjusted` return."
   Retail's own `transitional_insert` (pc:273137, `0050b6f0`) has NOT been
   read closely enough this pass to say definitively whether it treats a
   Path-6-sourced `ADJUSTED_TS` differently from an ordinary Adjusted
   result before this session's `continue`-on-Adjusted structure was
   written — that fresh, close read (specifically: does retail's loop
   check `sphere_path.collide` on EVERY iteration regardless of the
   latest Phase-2 return value, or only when Phase 2 returns OK?) is the
   concrete next step, not a second speculative code change. Do not retry
   the plain shortcut-deletion variant without that read; do not invent a
   third variant (e.g. teaching Path 6 to reposition the sphere itself)
   without confirming that's what retail actually does — that would be
   exactly the kind of guess CLAUDE.md's workflow forbids twice in a row
   on the same item.
7. **[#116 shape-1]** Where exactly, in the BSP/environment hit-test
   dispatch (candidate: `BSPTREE::find_collisions`'s `PathClipped`/
   `collide_with_pt` arm, pseudo-C ~323700-323830, sibling to the
   `set_collide` arm read for TS-4), does acdream fail to record the
   door-face collision normal that retail records at tick-22760? Needs
   an instrumented replay (§5 Step 7), not Ghidra/cdb per se, but the
   candidate function itself would benefit from a clean Ghidra
   decompile alongside the BN pseudo-C already read.
8. **[#116 shape-2]** Does retail's first airborne wall-contact frame
   reach `CSphere::slide_sphere` (→ in-frame slide, Z=1.92-style), or
   hard-stop upstream via some `last_known_contact_plane`-existence gate
   (→ Z=2.0-style, sliding deferred to frame 2)? This is the one item in
   this whole document that the digest, ISSUES.md, AND this research
   pass all independently converge on: **it needs a live cdb trace of
   retail landing an airborne wall hit** (toolchain: `docs/architecture`
   references the CLAUDE.md "Retail debugger toolchain" section; the
   digest already has a scoped cdb script sketch at
   `memory/project_physics_collision_digest.md:8537-8543`). A wrong
   guess here, per the digest's own words, "regresses ALL wall-slide
   behavior."

---

## 8. Campaign P Slice 1B closeout — exact response ordering (2026-07-31)

The follow-up read used the complete named-retail bodies, not the earlier
excerpt summaries:

- `CTransition::transitional_insert` at `0x0050B6F0`
  (pseudo-C:273137 onward) returns `OK_TS` as soon as
  `contact_plane_valid != 0`. Only an invalid contact reaches the ordinary
  StepDown tail, whose remaining gates are Contact,
  `!sphere_path.step_down`, a non-null check cell, and ObjectInfo.StepDown.
- Its StepDown schedule is asymmetric by authored sphere count. For a
  one-sphere mover whose requested height exceeds the foot diameter, retail
  clamps the probe to half the foot radius and performs one probe. Otherwise
  a request within the diameter probes once; an over-diameter request on a
  two-sphere mover is halved and probes twice in sequence.
- `CTransition::edge_slide` at `0x0050B3D0`
  (pseudo-C:273001-273090) runs `!OnWalkable || !EdgeSlide` restore-and-OK
  before its steep-contact CliffSlide branch. Any stored walkable polygon
  routes to PrecipiceSlide without a steepness test.
- `CTransition::cliff_slide` at `0x0050A6D0`
  (pseudo-C:272397 onward) crosses the supplied contact normal only with
  `collision_info.last_known_contact_plane.N`. It has no remembered-walkable
  or world-up substitute. A default, invalid, parallel, or otherwise
  degenerate cross naturally returns `OK_TS` through the retail normalization
  guard.

`TransitionTypes.cs` now follows that order exactly. AP-3, AP-4, AD-53, and
AD-54 are retired together. Slice 1B deliberately left the ordinary-tail
`runPlacement: false` choice for the following AP-5-specific slice and did not
alter TS-4's Path-6 steep-polygon shortcut. Slice 2A below closes AP-5.

`RetailEdgeResponseOrderingTests` pins every distinguishing branch: valid
steep-contact early return, the one/two-sphere probe schedule,
not-OnWalkable-before-CliffSlide, last-known-only source selection, degenerate
last-known handling, and stored-steep-walkable-to-Precipice routing. It also
runs multi-frame steep-roof and flat-roof-edge controls through both parsed
graph and prepared-flat collision traversal, requires exact trace parity, and
rejects a greater-than-15-tick frozen streak. The earlier dedicated
`Ts4SteepRoofWedgeCaptureTests` remains green, so retiring these four
compensations did not require weakening or deleting the TS-4 control.

### Corrective review: edge_slide has two outputs

The first Slice 1B commit collapsed `CTransition::edge_slide`'s function
return into its out `TransitionState`. That loses a material retail case:
the steep-contact branch writes the result of `cliff_slide` to the out state
but returns false independently. A degenerate/parallel CliffSlide therefore
writes `OK_TS` **and still tells `transitional_insert` to continue its outer
retry**. Branch 1 and the contact-without-remembered-walkable branch stop with
`OK_TS`; a `COLLIDED_TS` Precipice result stops; `SLID_TS` and `ADJUSTED_TS`
retain their ordinary retry handling.

The corrective implementation preserves this exact bool-plus-out-state seam.
Its end-to-end test drives an invalid-contact StepDown probe into a steep,
parallel-last-known CliffSlide, then proves a second outer object pass occurs
before success. The roof controls were also hardened: the flat-roof fixture
must first land and publish its persistent contact/walkable chronology, fails
its control arm when the roof is removed, and proves outward-X rejection plus
continued edge tangency. The steep-roof fixture now rejects non-finite or
oversized frame steps and signed-plane penetration until polygon exit. Parsed
graph and prepared-flat runs compare every `ResolveResult` field and every
persistent `PhysicsBody` field by raw float/double bits, including the ordered
walkable vertex payload.

## 9. Campaign P Slice 2A closeout — mandatory StepDown placement (2026-07-31)

The complete `CTransition::step_down` body at `0x0050B2A0`
(pseudo-C:272946–272998) has no caller-controlled validation choice. It resets
`walk_interp` to 1, performs the transitional downward/support probe, applies
the `EdgeSlide && !StepUp` walkable-support gate, and then always:

1. saves `sphere_path.insert_type`;
2. installs `PLACEMENT_INSERT`;
3. calls `CTransition::transitional_insert(this, 1)`;
4. restores the saved insert type; and
5. returns true only for `OK_TS`.

The `walk_interp = 1` assignment occurs once at `step_down` entry. Retail does
not reset it again before the final Placement insertion: that insertion sees
and carries the exact interpolation value left by the support probe. Likewise,
`CTransition::check_walkable` (`0x0050AFF0`, pseudo-C:272811–272856) saves its
temporary `check_pos` and cell in stack locals. It does not overwrite
`SPHEREPATH::backup_check_pos`/`backup_cell`, because the enclosing edge-slide
still needs that outer failed candidate after the nested support probe.

This is the same tail for normal grounded contact maintenance, the
`edge_slide` current-position back-probe, and StepUp. The former acdream
`runPlacement: false` argument on the first two callers was therefore a real
behavioral divergence, not a caller-specific retail mode.

The historical justification for the bypass was a wall-slide candidate that
Placement rejected. The correct boundary is the Placement dispatcher, not
StepDown. Retail's BSP, sphere, and cylinder Placement branches are pure
occupancy tests and shave `PhysicsGlobals.EPSILON` from their effective reach.
The current graph and prepared-flat dispatchers already implement that rule:
an exactly tangent sphere remains valid while penetration beyond the retail
epsilon is rejected. With the response-order fixes from §8 in place, restoring
the mandatory placement tail does not reproduce the old wall stall.

`RetailStepDownPlacementTests` pins the mechanism end to end for one- and
two-sphere movers, including raw-bit `walk_interp` carry, nested
`check_walkable` backup preservation, ordinary contact maintenance, StepUp,
and a supported candidate that overlaps only during final Placement. It also
compares graph and prepared-flat Placement at exact wall tangency and
beyond-epsilon overlap. The full-engine floor-plus-wall replay drives ten
grounded maintenance frames for both sphere counts, requires one Placement for
every successful support maintenance, proves no freeze or penetration plus
tangential progress, and compares complete `ResolveResult` and persistent
`PhysicsBody` state by raw bits between parsed-graph and prepared-flat paths.
The #273, #271, #185, StepUp, transition-retry, and TS-4 controls remain
unchanged. AP-5 is retired; TS-4 is intentionally untouched.

---

## 10. Campaign P Slice 2B closeout — TS-4 retired (2026-07-31)

A fresh read of `BSPTREE::find_collisions` (`0x0053A440`) confirms the exact
Path-6 split. A primary/foot-sphere polygon hit transforms the polygon normal,
calls `SPHEREPATH::set_collide`, writes `LandingZ`, and returns `ADJUSTED_TS`
(`0x0053A7B3..0x0053A7DC`) regardless of steepness. Only when that sphere is
clear does a secondary/head-sphere hit write `collision_normal` and return
`COLLIDED_TS` (`0x0053A793..0x0053A7A4`). Neither branch writes
`sliding_normal`.

Both parsed-graph and prepared-flat Path-6 implementations now follow that
split exactly. The steepness branches, in-place tangent projection, and BSP-
layer `SetSlidingNormal` writes are deleted. Exact site tests compare the two
representations by raw bits and pin every mutated and preserved field:

- foot: `SetCollide`, candidate backup, transformed `StepUpNormal`,
  `WalkInterp=1`, `WalkableAllowance=LandingZ`, `Adjusted`;
- head: `CollisionNormal`, `Collided`, with no `SetCollide` state mutation;
- both: a pre-existing sliding normal is preserved byte-for-byte.

The failed first removal was a test-harness lesson, not a retail exception.
Its gravity-only replay always passed `isOnGround:false`, manually zeroed
vertical velocity, and only copied part of the accepted contact state, so it
could not reproduce the live caller's next-frame chronology. The replacement
`Ts4ProductionQuantumConformanceTests` replay executes each already-airborne,
zero-root-motion 30 Hz Core collision quantum in the production order:
`calc_acceleration`, `UpdatePhysicsInternal`,
`ResolveWithTransition`, exact body/cell commit, then
`PhysicsObjUpdate.CommitSetPositionTransition` (the Core owner of retail's
Contact/OnWalkable replacement plus `handle_all_collisions`). It carries the
same body, cell, contact plane, walkable plane, sliding state, stationary-fall
counter, cached velocity, and transient flags for all 90 ticks. PositionManager
root composition, animation hooks, movement callbacks, and fresh-airborne
`LeaveGround`/`HitGround` edges are deliberately outside this already-airborne
dat-free fixture; it does not claim to replay those presentation/motion stages.

Parsed graph and prepared flat match by raw result/body bits for vertical,
inward, tangential, and downhill roof motion plus a genuine positive-Z uphill
jump. The foot-contact jump's apex precedes roof contact and every later
candidate velocity remains non-positive in Z. A separate elevated head-only
collision reaches the wall while Z velocity is still positive and pins the
valid-normal, inward-dot retail 5%-elastic reflection without adding vertical
velocity. Every direction rejects a half-second fixed point and signed-plane
penetration, while exact terminal velocity, Contact/OnWalkable/Sliding bits,
sliding normal, and contact plane are fixed by raw float bits. The older
resolver-only wedge capture remains a deliberately weaker historical control
and is restored to its original three-second bound. The former #116 D4
control remains active: its primary-sphere hit hard-stops frame one through
SetCollide, then the accepted persistent normal permits the downward slide on
frame two.

The complete historical #273/#271/#269/#265/#185/#137/#116/cellar/roof
matrix and the full Core Release suite pass without a replacement
compensation. TS-4 is retired.

---