diff --git a/CLAUDE.md b/CLAUDE.md
index 30b699e..39c1fa3 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -764,11 +764,31 @@ divergence (low confidence).** Full divergence reading +
 fix-plan pickup prompt at
 [`docs/research/2026-05-23-a6-p3-issue98-replay-comparison.md`](docs/research/2026-05-23-a6-p3-issue98-replay-comparison.md).
 Current A6 phase:
-**A6.P3 — write evidence-driven fix plan against Target 1 or 2;
-NO speculative fixes (4 prior sessions guessed and were wrong).
-The replay harness ([`tests/AcDream.Core.Tests/Physics/Issue98CellarUpReplayTests.cs`](tests/AcDream.Core.Tests/Physics/Issue98CellarUpReplayTests.cs))
-is the test loop; a fix that doesn't change the failing assertions
-is not the fix.**
+**A6.P3 — PAUSED 2026-05-23 evening after two days of work.** The
+session shipped further apparatus + first failed fix attempt + revert:
+`8a232a3` (`[step-walk-adjust]` probe inside `Transition.AdjustOffset`
+revealing branch tokens and per-call zGain), `8daf7e7` (findings note
+at [`docs/research/2026-05-23-a6-stepwalkadjust-findings.md`](docs/research/2026-05-23-a6-stepwalkadjust-findings.md)
++ capture snapshot), `0cb4c59` (Shape 1 fix: gate `BSPQuery.AdjustSphereToPlane`'s
+two `SetContactPlane` call sites by `Normal.Z >= 0.99`), `402ec10`
+(revert — Shape 1 broke OnWalkable tracking, sphere went into falling
+state on every sloped surface). **Refined diagnosis:** AdjustOffset is
+CORRECT (145/146 calls take `into-plane` branch, +0.045 m mean zGain
+per call when offset points into ramp); the climb CAPS at world Z ≈
+92.80 because step-up's downward step-down probe finds no walkable
+within 0.6 m below the proposed position (cottage floor is ABOVE).
+Earlier "Fix targets 1–4" priority list is OBSOLETE — AdjustOffset
+projection is not the problem. The actual bug is in the step-up
+validation at the ramp top. **Honest next-session moves**: (1) build
+deterministic trajectory replay harness so fix attempts iterate in
+<500ms instead of 5-minute live-test cycles; (2) pivot to a less-
+coupled M1.5 issue while #98 awaits the harness; (3) targeted decomp
+research on `CEnvCell::find_env_collisions` → `BSPTREE::find_collisions`
+indoor CP-setting chain (prior research worked on the outdoor
+`CLandCell` path; indoor was never fully traced). Session-end ISSUES.md
+entry has the full reading and pickup prompt. **NO further #98 fix
+attempts until apparatus or research has converged — five+ failed
+attempts in the saga is the signal.**
 Findings doc:
 [`docs/research/2026-05-21-a6-cdb-capture-findings.md`](docs/research/2026-05-21-a6-cdb-capture-findings.md).
 Original demo scenario (Holtburg Sewer end-to-end) is unreachable: sewer
diff --git a/docs/ISSUES.md b/docs/ISSUES.md
index 35d738f..fc6baa0 100644
--- a/docs/ISSUES.md
+++ b/docs/ISSUES.md
@@ -762,6 +762,23 @@ Our `ResolveCellId` + `CheckBuildingTransit` lack this stickiness — every tick
 
 **Acceptance:** User can walk up out of a Holtburg cottage cellar without getting stuck at the last step. Cell-transit log shows no ping-pong on the cellar boundary. Issue #90 workaround can be removed (verified by ping-pong staying absent at the inn doorway too).
 
+**2026-05-23 evening session update — Shape 1 attempted + reverted:**
+
+- New apparatus committed:
+  - `8a232a3` — `[step-walk-adjust]` probe inside `Transition.AdjustOffset` (PhysicsDiagnostics.LogStepWalkAdjust + four branch tokens). Reveals which projection branch fires per call.
+  - `8daf7e7` — captured findings note at [`docs/research/2026-05-23-a6-stepwalkadjust-findings.md`](docs/research/2026-05-23-a6-stepwalkadjust-findings.md) + log snapshot at `docs/research/2026-05-23-a6-captures/stepwalkadjust/acdream.log`.
+- **Refined diagnosis (corrects the 2026-05-23 evening "fix targets" priority above):** AdjustOffset is CORRECT — 145/146 calls take the `into-plane` branch with consistent +0.045 m mean zGain per call when offset points into the ramp normal. Sphere world Z climbs monotonically 90.95 → 92.80 across the ramp. **The climb caps at world Z ≈ 92.80** (cottage floor at 94.00 still 1.20 m above) because at the ramp top, the proposed check (Z=92.85) gets rejected by step-up's downward step-down probe — no walkable surface exists below the proposed position within stepDownHeight=0.6 m (cottage floor is ABOVE, not below). 101 `stepdown-reject` hits in the capture vs 1 acceptance.
+- **Shape 1 fix attempted (`0cb4c59`, reverted in `402ec10`):** Added `PhysicsGlobals.ContactPlaneFlatThreshold = 0.99f` and gated `BSPQuery.AdjustSphereToPlane`'s two `SetContactPlane` call sites by `worldNormal.Z >= threshold`. The intent: match retail's cdb-observed pattern where CP is ONLY ever set on flat polygons (cellar floor or cottage floor — Normal.Z = 1.0 in all 161 BPE writes). Live test confirmed the fix breaks OnWalkable tracking: 18,916 / 25,671 step-walk lines (74%) ended in `contact=False onWalkable=False cp=n/a walkPoly=False` (the falling state). User report: "can't get up the first step. Jumped, stuck in falling animation." The gate was too aggressive — sloped walkable polygons (stair tops, ramp faces) NEED ContactPlane set for the sphere to register as on a surface.
+- **What we learned about Shape 1:** simply skipping `set_contact_plane` on sloped polygons doesn't match retail behavior. Either retail synthesizes a flat CP from a sloped contact (the `step_sphere_down:321203` `Plane::Plane(&plane, esi, &point)` codepath — `esi` may be a synthesized direction, not the polygon's normal), OR retail's gate is upstream of `set_contact_plane` (the polygon never reaches CP-setting in the first place), OR our `OnWalkable` tracking is over-coupled to `ContactPlaneValid` in a way retail's isn't. The named-decomp research did not converge on a definitive answer.
+
+**Session paused 2026-05-23 evening after two days of work.** Apparatus + probe + findings + plan + first failed fix + revert all committed. M1.5 demo's cellar half remains blocked. The honest next-session moves, in order:
+
+1. **Build a deterministic trajectory replay harness** (drives the physics engine through N ticks with mocked input + snapshotted starting state, runs in <500ms). The Issue98 replay tests are half of this — they have the cell fixtures. The missing half is the per-tick driver. With a 200ms inner loop instead of 5-minute live-test iteration, evidence-driven fix attempts become tractable.
+2. **OR pivot to another M1.5 issue** with less cross-subsystem coupling. The cellar-up bug lives at the seam of AdjustOffset + ContactPlane + WalkInterp + step-up + walkable tracking + OnWalkable + cell-set membership — fixing one piece breaks another. Less-coupled issues (chronic open #2/#4/#28/#29/#37/#41, or #90 workaround removal) would yield faster forward progress.
+3. **OR a deeper named-decomp research pass** focused specifically on `CEnvCell::find_env_collisions` → `BSPTREE::find_collisions` → indoor CP-setting chain. This path was never fully traced; the first two research passes worked on the outdoor (`CLandCell`) path. The indoor path is where the cellar lives.
+
+**Replay tests at [`tests/AcDream.Core.Tests/Physics/Issue98CellarUpReplayTests.cs`](tests/AcDream.Core.Tests/Physics/Issue98CellarUpReplayTests.cs)** document the failing-frame geometry and will be the regression oracle when a real fix lands. They do not currently simulate trajectory.
+
 ---