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>
35961f2039