From 664101f08fcceb328a90dceca69269d74f40144e Mon Sep 17 00:00:00 2001 From: Erik Date: Thu, 4 Jun 2026 11:39:21 +0200 Subject: [PATCH] =?UTF-8?q?docs(p2):=20re-diagnose=20cellar=20wedge=20?= =?UTF-8?q?=E2=80=94=20cell-resolver=20ping-pong,=20not=20step-up?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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) --- ...6-06-04-p2-cellar-corner-stepup-handoff.md | 22 ++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/docs/research/2026-06-04-p2-cellar-corner-stepup-handoff.md b/docs/research/2026-06-04-p2-cellar-corner-stepup-handoff.md index fbc71f17..62570079 100644 --- a/docs/research/2026-06-04-p2-cellar-corner-stepup-handoff.md +++ b/docs/research/2026-06-04-p2-cellar-corner-stepup-handoff.md @@ -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.