#116 oracle desk read: slide-response leads pinned, needs a live cdb to finish

Read both sides quote-for-quote (verified against source): our
CSphere::slide_sphere port (TransitionTypes.cs:3054-3133) vs retail
0x00537440 (decomp 321403-321532). Findings:

1. Shape-1 (tick-22760 lost 3.57cm slide) is NOT the degenerate-offset
   guard - retail's guard only kills slides under ~1.4cm. The real
   divergence is the collision-normal SOURCE: our harness cn=(0,0,1) vs
   live cn=(0,+1,0). Strong lead: TransitionTypes.cs:3701-3702 defaults
   cn=Vector3.UnitZ when no valid normal.
2. Shape-2: retail's slide_sphere applies the slide IN-FRAME
   (add_offset_to_check_pos @0x53777e, return SLID) - our in-frame slide
   to Z=1.92 is likely retail-faithful and the D4 frame-1 hard-stop pin
   is the stale one (pending the first-airborne-frame plane state).
3. Candidate epsilon-squaring divergence: retail compares SQUARED
   quantities against 0.000199999995 (non-squared) while we compare
   against EpsilonSq=0.0002^2 - possibly 1e4x too small. Explains
   neither shape; DO NOT change without cdb (the test ah,5 branch
   polarity is the undecodable BN construct from the PosHitsSphere saga).

No code change (oracle-first; the issue title calls for cdb and the BN
decomp is provably ambiguous on the branch signs). ISSUES.md #116 +
physics digest carry the leads + the scoped cdb plan.

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

CLAUDE.md

@@ -112,10 +112,12 @@ movement queries.
 (M1 — Walkable + clickable world — landed 2026-05-16 via Phase B.6).
 The holistic building-render port (Option A: ONE `DrawInside(viewer_cell)`,
 no inside/outside branch; BR-2..BR-7/T1..T6) is SHIPPED and user-gated.
-2026-06-12 closes: #119/#128, #112, #113, #124 (interior-root look-ins),
-#129, #130, #131, #132, UN-2. Open render/physics ledger: #108-residual,
-#116, #127, #125 sticky-drop debt (leads in ISSUES.md). Keep this
-paragraph ≤5 lines + pointers — detail lives in the docs below, NOT here.
+2026-06-12 closes: #119/#128, #112, #113, #124, #129, #130, #131, #132,
+UN-2, **#108-residual** (terrain was double-sided — backface-cull port),
+**#127** (distant-building flap died with the W=0 clip port). Open
+render/physics ledger: #116 (slide-response, oracle-first), #125
+sticky-drop debt (leads in ISSUES.md). Keep this paragraph ≤5 lines +
+pointers — detail lives in the docs below, NOT here.
 
 For canonical state, read in this order:
 - [`docs/plans/2026-05-12-milestones.md`](docs/plans/2026-05-12-milestones.md) — milestone targets + freeze list per milestone

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"]