diff --git a/docs/ISSUES.md b/docs/ISSUES.md
index 15684e22..aea90676 100644
--- a/docs/ISSUES.md
+++ b/docs/ISSUES.md
@@ -3968,6 +3968,51 @@ them byte-identical):**
 fixture as the acceptance pair. Do NOT patch the degenerate-offset guard
 ad hoc — the DO-NOT-RETRY table's slide entries (physics digest) apply.
 
+**ORACLE DESK READ DONE (2026-06-12) — needs a LIVE cdb session to
+finish.** Both sides quoted + verified against source (our
+`CSphere::slide_sphere` port = `TransitionTypes.cs:3054-3133`; retail
+`CSphere::slide_sphere` = decomp `0x00537440`, lines 321403-321532).
+Three concrete leads, none safely fixable from the static BN decomp:
+
+1. **Shape-1 re-attributed — it is NOT the degenerate-offset guard
+   threshold.** Retail's guard kills slides under ~1.4 cm (`|offset|² <
+   0.000199999995` at `0x537735`); the lost tick-22760 slide was 3.57 cm
+   (`X −0.0357`), well above it — retail would keep it too. The real
+   divergence is the COLLISION-NORMAL SOURCE: our harness recorded
+   `cn=(0,0,1)` (ground), live retail `cn=(0,+1,0)` (the door face).
+   Strong lead: `TransitionTypes.cs:3701-3702` — on a blocked move with
+   no valid collision normal we DEFAULT `cn = Vector3.UnitZ` ("push up");
+   that exact (0,0,1) is what the harness sees. Whether retail has an
+   equivalent default (vs keeping the wall normal) is a runtime question.
+
+2. **Shape-2 — retail's slide_sphere applies the slide IN-FRAME**
+   (`add_offset_to_check_pos` @`0x53777e`, returns 4=SLID), so our
+   in-frame slide to Z=1.92 on frame 1 is likely retail-faithful and the
+   D4 frame-1 hard-stop pin (`BSPStepUpTests.D4_*`, expects Z=2.0) is the
+   STALE expectation. BUT retail always uses `contact_plane` OR
+   `last_known_contact_plane` (`0x53755a`); it has no "airborne wall-only,
+   no plane" third branch like ours (`TransitionTypes.cs:3080-3092`) — the
+   first-airborne-frame plane state needs a trace before flipping the pin.
+
+3. **Candidate epsilon-squaring divergence (real, but explains neither
+   shape).** Retail compares SQUARED quantities (`|cross|²` @`0x5375a5`,
+   `|offset|²` @`0x537735`) against `0.000199999995` (≈0.0002, NON-squared);
+   our port compares against `EpsilonSq = 0.0002²` (line 3105 + the
+   `dirLenSq >= EpsilonSq` branch @3098) — potentially ~10⁴× too small.
+   DO NOT change this without cdb confirmation: the BN `test ah, 0x5`
+   branch polarity (lines 321466-321467/321484-321485) is the exact
+   undecodable construct the PosHitsSphere saga warned about, and the
+   register reuse garbles which quantity is squared. A wrong guess here
+   regresses ALL wall-slide behavior.
+
+**Next (cdb session, well-scoped):** (a) `cdb -z uf
+acclient!CSphere::slide_sphere` OR a live attach to disassemble
+`0x00537440` and settle the two `test ah,5` branch signs + the
+squared-vs-not threshold (prefer LIVE attach — prior lesson: static
+`-z uf` misdecodes at OMAP boundaries); (b) live trace the tick-22760
+door push to confirm whether the `cn=(0,0,1)` comes from our
+`UnitZ`-default (lead 1) and what retail's normal is at that instant.
+
 ---
 
 ## #117 — Aperture-shaped see-through: doors/interiors visible through terrain hills and through nearer buildings — [DONE 2026-06-11 · 478c549, user re-gate "Yes solved"]