erik/acdream
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 1

docs(p2): re-diagnose cellar wedge — cell-resolver ping-pong, not step-up

Browse source 
Instrumented acdream at the cellar lip (ACDREAM_DUMP_STEPUP=1): step-up WORKS
(518 attempts, 220 SUCCESS landing the candidate on the cottage floor Z=94.0,
matching retail's landings), but the committed CurPos never advances -- every
success is reverted, and [cell-transit] shows ResolveCellId ping-ponging every
tick at the 3-cell junction (0xA9B40175<->0174<->0171, reason=resolver). So the
wedge is a MEMBERSHIP cell-resolution instability reverting a working step-up --
NOT a collision/step-up bug, NOT edge-slide.

Notably this contradicts the master-plan P1 claim that ResolveCellId was demoted
out of the per-frame path: it is STILL driving per-frame cell changes here and is
unstable. Fix direction = the parked, approval-gated (a) ResolveCellId
demotion/stickiness (membership), now justified as a real bug by live evidence.
Collision-side fixes (abbd761 B1, 0935a31 slide_sphere) are correct + kept.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
Erik 2026-06-04 11:39:21 +02:00
parent 5ad897b0a5
commit 664101f08f
1 changed files with 21 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

22
docs/research/2026-06-04-p2-cellar-corner-stepup-handoff.md
View file

@ -1,9 +1,29 @@
# P2 pickup — cellar-top corner wedge = step-up-onto-cottage-floor (retail cdb pinned)
# 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.