docs: Campaign P final physics slice — ledger updates (#116, #166, P2)

Per docs/research/2026-07-30-ts4-116-oracle-plan.md, following the four
code commits that closed out TS-4 (5e2be19b), #116 shape-2 (01492205),
and AD-55 (252e8068), plus #116 shape-1's Path-6 fix (db2889af) and the
TransitionalInsert return-value fix (7e1be3de):

- ISSUES.md #116: shape-2 marked CLOSED (D4 un-skipped, structurally
  confirmed, no cdb needed). Shape-1 narrowed, not closed: the Path-6
  head-sphere fix is a real, independent improvement but the tick-22760
  confirming replay showed it doesn't explain that specific symptom --
  the mover is grounded there (Path 5, not Path 6) and the actual
  no-normal-recorded mechanism (SpherePath.PrecipiceSlide's
  find_crossed_edge-false fallback) is independently confirmed byte-exact
  retail behavior too. Recorded the concrete next step (re-run against
  the faithful Setup-based door registration instead of the simplified
  fixture) rather than closing on an unmet acceptance criterion.
- ISSUES.md #166: noted TS-4 and AD-55 landed (the AP-7-family
  completion this note was waiting on); closure still pends the visual-
  matrix scenario-5 recheck against live retail.
- Campaign P plan (2026-07-29-physics-parity-campaign.md) P2 status
  block: TS-4 outcome (retired, not deferred), #116 outcome (shape-2
  closed / shape-1 narrowed), AD-55 outcome (retired).

Docs-only; no build/test change required for this commit.

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

docs/ISSUES.md

@@ -4382,7 +4382,9 @@ wall from acdream, matching the retail-observer view side-by-side.
 
 ## #166 — Slope-landing glide + bounce absent (retail "sled" on downhill jumps)
 
-**Status:** OPEN (post-R6 polish — user: "we could polish later")
+**Status:** OPEN (post-R6 polish — user: "we could polish later"); all
+four register-predicted composite deviations (AD-25, AP-7, AD-55, TS-4)
+are now landed as of 2026-07-30 — pending only a visual-matrix recheck
 **Severity:** LOW (feel/polish)
 **Filed:** 2026-07-03 (user observation during the R2-R4 visual pass)
 **Component:** physics, landing
@@ -4439,24 +4441,43 @@ transition except grounded→grounded-and-not-sledding, matching retail's
 `shouldReflect = !(prevOnWalkable && nowOnWalkable && !sledding)`. Both
 halves of AD-25 (local player and remote) are now retired.
 
-Closure of #166 therefore pends only: (a) TS-4 actually landing, and (b)
+**TS-4 landed (2026-07-30, Campaign P final physics slice):** the
-re-checking Campaign P's final visual matrix item 5 ("Downhill jump
+Path-6 steep-poly shortcut this note previously flagged as "deferred" is
-landing: sled glide + bounce") against a fresh capture — if the glide/
+now retired — the decisive confirming run
-bounce still visibly mismatches retail after AP-7 and AD-25 (with TS-4
+(`Ts4SteepRoofWedgeCaptureTests`, horizontal-velocity variant) showed the
-still deferred), that capture, not a guess, is what should drive any
+shortcut-removed engine converges cleanly for the realistic (non-
-further work here, and it should go through cdb against live retail
+degenerate) case. See `docs/research/2026-07-30-ts4-116-oracle-plan.md`
-before any client-side Sledding-state mechanism is written.
+§1 and its own register row (struck through, TS-4).
+
+**AD-55 also landed the same slice** (the sled-flatness constant in this
+SAME `calc_friction` function AP-7 already fixed): retail's Sledding
+fast-sled override compares against `cos(10°) ≈ 0.98480775f`, byte-proven
+against `0x0050ee70`, not the previously-carried ACE-derived `0.99999536f`
+(≈0.175° from flat, essentially unreachable). This is the AP-7-family
+completion the "sled deceleration differs" framing above was waiting on —
+all four of AD-25, AP-7, AD-55, and TS-4 are now landed.
+
+Closure of #166 therefore pends only re-checking Campaign P's final
+visual matrix item 5 ("Downhill jump landing: sled glide + bounce")
+against a fresh capture — if the glide/bounce still visibly mismatches
+retail now that every register-predicted composite deviation is retired,
+that capture, not a guess, is what should drive any further work here,
+and it should go through cdb against live retail before any client-side
+Sledding-state mechanism is written (recall: no client-side
+`PhysicsState.Sledding` auto-toggle exists in retail per the reattribution
+above — a data-authored toggle exists only server-side).
 
 **Where:** `src/AcDream.Runtime/Physics/RuntimeRemotePhysicsUpdater.cs`
 (remote reflect, AD-25 — DONE 2026-07-30),
-`src/AcDream.Core/Physics/PhysicsBody.cs` (`calc_friction`, AP-7 — DONE
+`src/AcDream.Core/Physics/PhysicsBody.cs` (`calc_friction`, AP-7 and AD-55
-2026-07-30), `src/AcDream.Core/Physics/BSPQuery.cs` (Path 6 steep branches,
+— both DONE 2026-07-30), `src/AcDream.Core/Physics/BSPQuery.cs` +
-TS-4 — deferred, shortcut still in place).
+`FlatBspQuery.cs` (Path 6 steep branches, TS-4 — DONE 2026-07-30).
 
 **Acceptance:** side-by-side downhill jump: acdream glides/bounces like
 retail; flat-ground landings unchanged; no micro-bounce death spiral
-(the reason AD-25 existed) reintroduced. Blocked on TS-4's eventual
+(the reason AD-25 existed) reintroduced. Every code-side composite
-landing per the note above.
+deviation is now landed; only the visual-matrix recheck remains before
+this issue can close.
 
 ## #164 — UM action-replay dispatches drop the per-action Autonomous bit
 
@@ -8615,8 +8636,12 @@ retail's viewer-distance smoothing (update_viewer region) before touching.
 
 ## #116 — Slide-response divergence family: near-perpendicular lateral slide lost + first-airborne-frame in-frame slide vs hard stop
 
-**Status:** OPEN (narrowed) — one Ghidra-confirmed faithfulness fix
+**Status:** OPEN (narrowed further, 2026-07-30) — **shape-2 CLOSED**
-SHIPPED 2026-06-12; both reported shapes still need a runtime trace.
+(D4 un-skipped and passing, oracle-plan-confirmed, no cdb needed after
+all — see the 2026-07-30 update below); **shape-1 narrowed, not closed**:
+a real, independently-decomp-confirmed Path-6 head-sphere fix landed, but
+it does NOT explain the tick-22760 symptom this issue was filed against —
+see below for the new evidence and the concrete open candidate.
 **Severity:** LOW-MEDIUM (over-blocking, never under-blocking — no
 walk-throughs; feel-level divergence at walls/doors)
 **Filed:** 2026-06-11 (BR-7 / A6.P4 ship session)
@@ -8734,6 +8759,63 @@ door push to confirm whether the `cn=(0,0,1)` comes from our
 
 **2026-07-09 triage:** investigated, verdict STILL_OPEN — the pinned harness diagnostic (`Diagnostic_Tick22760_DumpEngineInternals`) still shows the harness hard-stopping laterally where live retail slides, and `BSPStepUpTests.D4_AirborneMover_TallWall_PersistsSlidingNormalAcrossFrames` remains explicitly `Skip`-tagged citing this issue; only one Ghidra-confirmed partial fix (`bf18a543`, `F_EPSILON` vs `EpsilonSq`) has landed.
 
+**2026-07-30 (Campaign P final physics slice) — shape-2 CLOSED, shape-1
+narrowed with new evidence, no cdb session needed for either after all:**
+
+- **Shape-2 CLOSED — no cdb needed.** The oracle plan
+  (`docs/research/2026-07-30-ts4-116-oracle-plan.md` §3, cross-referencing
+  the raw BN pseudo-C, ACE's `BSPTree.cs`, and current source) found the
+  ROUTING question (does retail's first airborne wall-contact frame reach
+  `slide_sphere`?) answerable from static structure alone: retail's
+  dispatch never calls `slide_sphere` on a genuine first-airborne-frame
+  FOOT-sphere hit — `Path 6` sets `Collide` without repositioning, the
+  retry routes to `Path 4` (`find_walkable`), which for a sheer vertical
+  wall finds no candidate, and `Phase 3`'s `sp.Collide` block then hard-
+  stops with the wall's real normal. A confirming instrumentation run
+  (probes on which `BSPQuery.cs` path fires + whether `FindWalkableInternal`
+  finds a candidate, added in `5e2be19b`) reproduced exactly this sequence
+  for the D4 fixture once TS-4's shortcut was removed (`5e2be19b`) — Path 6
+  → Path 4 (`changed=false`) → Phase 3 `Collided` with `StepUpNormal`. D4
+  un-skipped as a test-only change (`01492205`) and passes. TS-4's own
+  removal is what unblocked this; D4's own code was never wrong.
+- **Shape-1: the Path-6 head-sphere fix landed, but does NOT explain
+  tick-22760.** The oracle plan's §2.3 hypothesis (a foot-clear/head-hit
+  airborne contact deferred through `SetCollide`/`Adjusted` instead of
+  retail's direct `Collided`+`SetCollisionNormal`) is CONFIRMED as a real,
+  independently-decomp-confirmed divergence (pc:323824-323834, ACE
+  `BSPTree.cs:221-230`) and is now fixed in both `BSPQuery.cs` and
+  `FlatBspQuery.cs` (`db2889af`). **But re-running
+  `Diagnostic_Tick22760_DumpEngineInternals` after the fix shows NO
+  CHANGE** (harness still `cn=(0,0,1)` vs live `cn=(0,+1,0)`). New
+  dispatch-entry probes (`[path-dispatch]`, `[path5-diag]`, permanent,
+  gated on `ProbeIndoorBspEnabled`) traced the ACTUAL tick-22760 call
+  sequence: the mover is GROUNDED (`Contact` bit set in the seeded
+  snapshot), so it never reaches Path 6 at all. It dispatches Path 5 →
+  `StepSphereDown` (Path 3, both `DoStepDown` half-steps fail to find a
+  walkable candidate on the door's simplified BSP registration) →
+  `EdgeSlideAfterStepDownFailed` → `SpherePath.PrecipiceSlide`, whose
+  `find_crossed_edge`-false fallback returns `Collided` with **no**
+  collision-normal write. A fresh byte-level read of retail's
+  `SPHEREPATH::precipice_slide` (pc:274316-274326, `0x0050cc80`) confirms
+  this is byte-exact retail behavior (`if (eax == 0) { walkable = 0;
+  return 2; }`, no `set_collision_normal` call) — not a bug; `validate_transition`'s
+  `UnitZ` default fires identically in both engines here. **The tick-22760
+  divergence is therefore NOT explained by anything in the response/slide
+  layer this issue was filed against.** Leading candidate (not yet
+  chased): `DoorBugTrajectoryReplayTests.BuildEngineWithDoorFixture`
+  registers the door's raw BSP directly at its captured bounding-sphere
+  center rather than via the faithful `ShadowShapeBuilder.FromSetup` +
+  `PlacementFrame` transform `BuildFaithfulDoorEngine` uses elsewhere in
+  the same file — the harness's door geometry may simply not be where
+  live retail's was at that exact tick, which would make this a
+  test-fixture gap, not an engine bug. See
+  `docs/research/2026-07-30-ts4-116-oracle-plan.md` Addendum 2 for the
+  full trace. **Next step, if picked back up:** re-run the tick-22760
+  capture against `BuildFaithfulDoorEngine`'s Setup-based registration
+  (not the simplified fixture) to see whether a real BSP hit against the
+  door — instead of the seeded generic floor triangle — changes the
+  outcome, before considering any further code change.
+
 ---
 
 ## #118 — Character clipped + disappears for a moment when exiting houses — [DONE 2026-06-11 · 5a80a2e, user re-gate "Yes solved"]

docs/plans/2026-07-29-physics-parity-campaign.md

@@ -94,14 +94,36 @@ character state continuously.
 
 ### P2 — Response-layer edge family — retires TS-1, TS-4, AP-7; closes #166, #116
 
-**Status (2026-07-30):** TS-1 and AP-7 retired; #166 reattributed in
+**Status (2026-07-30, FINAL — Campaign P final physics slice):** TS-1 and
-ISSUES.md (no new code — see the research doc §3). **TS-4 is deferred, not
+AP-7 retired same-day as originally recorded. **TS-4 is now ALSO
-retired** — the fixture-first removal attempt this doc's §6 Step 3 requires
+RETIRED** — the oracle follow-up pass
-reproduced the historical 2026-04-30 L.4 wedge (a dat-free capture,
+(`docs/research/2026-07-30-ts4-116-oracle-plan.md`) found the freeze the
-`Ts4SteepRoofWedgeCaptureTests`); the shortcut stays in `BSPQuery.cs`. Root
+first implementation attempt hit was one layer downstream of Path 6
-cause and the concrete next research step are recorded in
+(inside `AdjustOffset`'s crease projection against a purely-vertical
-`docs/research/2026-07-30-response-layer-edge-family-pseudocode.md` §7 item
+offset — a genuine retail-identical degeneracy, not a bug) and ran the
-6. #116 is untouched (oracle-first, own session).
+plan's own decisive confirming test: `Ts4SteepRoofWedgeCaptureTests`'s
+horizontal-velocity variant (matching the realistic live-play input that
+originally validated the shortcut) converges cleanly with the shortcut
+removed. The Path-6 steep-poly shortcut is deleted from both
+`BSPQuery.cs` and `FlatBspQuery.cs`; the pure-vertical degenerate case is
+pinned (not fixed) as register row AD-56. **#116 is narrowed, not
+closed**: shape-2 (D4 first-airborne-frame hard-stop) is CLOSED — the
+oracle plan's structural dispatch-routing hypothesis was confirmed by
+instrumentation with no cdb session needed, and the D4 pin is un-skipped.
+Shape-1 (tick-22760 lateral-slide loss) got a real, independently-decomp-
+confirmed fix (Path 6's foot-clear/head-hit branch now returns `Collided`
++ `SetCollisionNormal` directly, matching pc:323824-323834/ACE
+`BSPTree.cs:221-230`), but the confirming replay showed this does NOT
+explain tick-22760 itself — that mover is grounded (dispatches through
+Path 5, not Path 6) and the actual "no normal recorded" mechanism
+(`SpherePath.PrecipiceSlide`'s `find_crossed_edge`-false fallback) is
+independently confirmed byte-exact retail behavior too. The remaining
+divergence is most likely this test's simplified door-registration
+fixture, not the response layer — see ISSUES.md #116 and the oracle
+plan's Addendum 2 for the full trace and the concrete next step (re-run
+against the faithful Setup-based door registration). AD-55 (the sled
+slope-flatness constant, split out of AP-7's retirement) is ALSO retired
+this same slice — byte-proven `cos(10°)` per the oracle plan's Addendum.
 
 The collision *response* layer (what happens after a hit): ground
 friction, cliff edges, downhill landings, near-perpendicular wall