acdream/docs/research/2026-06-04-p2-cellar-corner-stepup-handoff.md

P2 pickup — cellar-top corner wedge = cell-resolver ping-pong (re-diagnosed) reverting a WORKING step-up

Canonical pickup, 2026-06-04. Branch claude/thirsty-goldberg-51bb9b (do NOT branch/worktree; do NOT push without asking; NEVER git stash/gc). PowerShell on Windows; launch logs are UTF-16.

🔴 RE-DIAGNOSED 2026-06-04 (acdream corner trace) — the cellar wedge is a MEMBERSHIP bug, NOT collision. The "## The cdb-pinned finding" below (retail steps up onto the floor) is correct for RETAIL, but instrumenting acdream (ACDREAM_DUMP_STEPUP=1) at the lip showed acdream's step-up WORKS: 518 attempts, 220 SUCCESS landing the candidate on the cottage floor (CheckPos Z=94.0, normal (0,0,1)), 298 FAILED, alternating. But the committed CurPos never advances — it stays on the ramp at (…,9.70,93.41); every success is REVERTED. [cell-transit] shows a cell-resolver ping-pong every tick at the 3-cell junction: 0xA9B40175↔0174↔0171, reason=resolver. So ResolveCellId flips the cell each frame → the floor-landing is validated against the wrong cell + rejected → revert → oscillation → wedge. NOT step-up (works), NOT edge-slide. It's the #98/"Finding-3" cell-ping-pong family. The fix is membership/ cell-resolution stability at the junction — the PARKED, approval-gated (a) ResolveCellId demotion/stickiness from the master plan (P1 claimed it was demoted out of the per-frame path, but this trace shows it's STILL driving per-frame cell changes here + unstable). The collision-side fixes (B1 abbd761, slide_sphere 0935a31) are correct + KEEP. Apparatus: acdream-corner-capture.jsonl + the stepup:/[cell-transit] lines in launch-acdream-corner.log. Next: pin whether the commit-rejection is caused by the resolver flip (trace ResolveWithTransition validate/commit vs the cell change at the lip), then stabilize membership there (do NOT touch step-up/slide — they work).

State both altitudes

• Milestone: M1.5 — Indoor world feels right.
• Phase: P2 (door / building-shell collision) of the verbatim spatial-pipeline port.
• Shipped this session (committed, branch HEAD 0935a31):
  • abbd761 — B1 fix: Path 5 (Contact) near-miss dispatch ported verbatim — gate behind num_sphere > 1, head-first order, neg_step_up mapping (head→false/slide, foot→true/step-up). Retail transitional_insert/find_collisions Contact branch (acclient_2013_pseudo_c.txt:323838-323881, set_neg_poly_hit :323279). Fixed the B1 grounded-step-up wedge (the handoff's "climb" localization was WRONG — proved via ITestOutputHelper capture).
  • 0935a31 — slide_sphere fix: head near-miss (neg_step_up==0) now calls the faithful CSphere::slide_sphere (existing SlideSphereInternal) + continues the insert loop, replacing the A6.P4 Collided shortcut (transitional_insert pc:273350-273351).
  • f984e92 — docs (corrected the prior P2 handoff).
• Visual-verified 2026-06-04: generic step-up climbs; closed cottage door still BLOCKS (slides tangentially, no walkthrough — regression check passed); cellar ascent went from ALWAYS-stuck → WORKS-MOSTLY.
• Remaining: an intermittent corner-wedge at the cellar-top lip. Retail is always smooth there (user-confirmed). So it's a real bug.

The cdb-pinned finding (retail ground truth)

tools/cdb/cellar-corner-escape.cdb traced live retail at the cellar-top corner (decode: parse_corner_log.py; raw: cellar-corner-retail.log). Retail escapes the corner by STEP-UP, not slide:

• step_sphere_up→step_up fired 196× vs only 38 near-misses. step_up normals: +X wall ×78, ceiling (0,0,-1) ×36, +Y wall ×32, −X wall ×18, ramp slope (0,−0.62,0.78) ×11, −Y wall ×10, floor (0,0,1) ×10. So retail step-ups against EVERY grounded full-hit at the corner.
• Contact plane transitions ramp N.z=0.78 (×63) → flat cottage floor N.z=1.0 (×76). That's the escape: retail climbs the lip off the ramp ONTO the cottage floor.
• The user's "run in place against the ceiling (not stuck)" = step_up failing on the ceiling normal (0,0,-1) → step_up_slide (transient; steer out).

Divergence pinned: retail escapes by stepping up onto the cottage floor; acdream slides at the lip and never makes the ramp→floor transition. The slide itself (the 0935a31 fix) is correct + working; the gap is the final lip-climb. This is the original #98 core — DoStepDown/step_sphere_down finding + landing on the cottage floor — which B1+slide got close to but didn't finish.

Next step (evidence-first — #98 saga rule: do NOT guess)

1. Instrument acdream's OWN corner path. The captures so far (cellar-up-capture*.jsonl, door-recheck-capture.jsonl) have positions/normals but NOT the path. Need to answer: at the cellar-top lip, does acdream's step_sphere_up→ DoStepUp FIRE and FAIL to land on the cottage floor (DoStepDown can't find N.z=1.0 within StepUpHeight=0.6), or does it not fire (the hit goes to the slide path instead)? Relaunch acdream with ProbeBuildingEnabled (→ [neg-poly-dispatch]/ [bsp-test]) + ACDREAM_DUMP_STEPUP=1 + ProbeStepWalkEnabled (→ [step-walk]), reproduce the wedge, read the path. (xunit-swallow doesn't apply to the live app — Console probes DO surface in the launch log.)
2. Compare to retail's 196 step_up / ramp→floor transition and port the missing lip-climb verbatim. Likely in DoStepDown (TransitionTypes.cs:3074) / BSPQuery.step_sphere_down (:1206) / find_walkable (:693) — the cottage-floor find+land. Retail anchors: CTransition::step_up pc:273099, step_down pc:272946, BSPTREE::step_sphere_down pc:323665, CObjCell::find_env_collisions (the walkable-refresh that overwrites the contact plane ramp→floor).
3. USER VISUAL GATE: cellar ascent clean (no intermittent wedge); door still blocks; generic step-up still climbs.

Apparatus (committed / available)

• tools/cdb/cellar-corner-escape.cdb — retail corner trace (step_up/step_sphere_up/ neg_poly_hit/contact_plane counts + args; 30K threshold — TOO HIGH for these lower-frequency BPs, lower to ~3000 next time so it auto-detaches in one wedge).
• parse_corner_log.py — decodes the cdb log (hex→float, histograms).
• Captures (UNCOMMITTED, in worktree root, ~32 MB each — do NOT commit): cellar-up-capture.jsonl (v1, pre-slide-fix wedge), cellar-up-capture-v2.jsonl (post-slide-fix: 96 hit-and-advanced slide frames), door-recheck-capture.jsonl, cellar-corner-retail.log (the retail cdb trace).
• analyze_cellar.py / analyze_v2.py — ad-hoc capture analyzers (capture-specific).

Test baseline

Core 1310 pass / 4 fail / 1 skip. The 4 fails are pre-existing documents-the-bug / separate-issue: DoorCollisionApparatusTests.Apparatus_Grounded_50cmOffCenter (synthetic-test artifact — terrain=-1000, no queryable floor; NOT a real door-block failure — see memory/project_p2_door_stepup_findings.md), 2× DoorBugTrajectoryReplay LiveCompare_* (compare against captured-BUGGY-live positions; need re-baseline), and BSPStepUpTests.D4 (airborne Path 6 sliding-normal persistence — separate). App 177 green.

Do NOT

• Guess a step-up fix without acdream's corner path trace (the #98 saga burned 10+ guesses).
• Flip Apparatus_Grounded_50cmOffCenter to Assert.True(blocked) — it blocks via a synthetic-floor artifact, not a faithful door block.
• Re-investigate B1 (the near-miss gate) or the slide_sphere head-near-miss path — both shipped + verified.