CLAUDE.md

@@ -112,12 +112,10 @@ 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, #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.
+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.
 
 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,51 +3968,6 @@ 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"]