docs(issues): file #77 (close-range auto-walk + pickup overshoot) + close #76

#77 captures two close-range visual bugs observed during Step 2 verification
that are pre-existing — not caused by 0b25df5. Both live in
PlayerMovementController.DriveServerAutoWalk / threshold logic from
Phase B.6 work (#75). Trace evidence captured from launch.log of the
verification run.

#76 closed with the diag-trace evidence: identity invariants matched
across session / _liveSession / _liveSessionController.Session
(hashcode=1034657 throughout), so the original suspected bug-class was
wrong. The first Step 2 attempt's apparent regression was almost
certainly a stale ACE session.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

docs/ISSUES.md

@@ -46,12 +46,114 @@ Copy this block when adding a new issue:
 
 # Active issues
 
-## #76 — LiveSessionController extraction (Step 2) regresses interaction + chat outbound
+## #77 — Auto-walk doesn't engage at walking range; pickup at walking range overshoots and snaps back
 
 **Status:** OPEN
+**Severity:** MEDIUM (M1-deferred polish; visible during normal play, doesn't block any phase)
+**Filed:** 2026-05-16
+**Component:** physics / auto-walk / `PlayerMovementController.DriveServerAutoWalk`
+
+**Description:** Two related visual bugs observed during Step 2 (`0b25df5`)
+visual verification at Holtburg. Both involve the close-range branch of
+the server-driven auto-walk path (Phase B.6 / closed-issue #75 territory).
+
+**Bug A — NPC at walking range never auto-walks:**
+- User clicks on an NPC (e.g. Royal Guard `0x7A9B46AE`) when the player
+  is in "walking range" — far enough that retail would walk a short
+  distance, not close enough to immediately Use.
+- The client's `WorldPicker` returns `WithinUseRadius=false`, so
+  `OnInputAction.UseSelected` defers the Use and would expect ACE's
+  `MoveToObject` to drive the player to the NPC.
+- ACE sends back `UpdateMotion` with the auto-walk command — observed in
+  the log as `OnLiveMotionUpdated: guid=0x5000000A stance=0 cmd=0x0005
+  speed=-1.84` immediately after each `[B.4b] use guid=...` outbound.
+- But the local player doesn't visibly move. Repeated clicks (the trace
+  shows seq 81 → 87 → 90 → 96 → 105 → 141 → 146 → 159 → 163 → 169 → 173
+  → 177 against the same Royal Guard) produce the same response every
+  time without movement.
+
+**Bug B — Pickup at walking range runs/overshoots/snaps back:**
+- User presses F on a ground item while in "walking range" of it.
+- Player RUNS (not walks) toward the target.
+- Overshoots the item, then "blips back" to the correct position before
+  the pickup actually fires.
+- The pickup completes (item ends up in inventory), but the visual is
+  jarring — clearly the walk/run threshold misclassifies the close-range
+  case, then ACE's position-correction snaps the player back.
+
+**Root cause / status:** Unknown. Likely in one of:
+- `PlayerMovementController.DriveServerAutoWalk` — engagement condition
+  (does it activate on negative speed? on cmd=0x0005?)
+- Walk/run distance threshold (CLAUDE.md notes 1.0m as the corrected
+  threshold from Phase B.6, but the `runRate` / `cmd` derivation may
+  miscalculate at close range)
+- Inbound `UpdateMotion` parser — the `speed=-1.84` is suspicious; if
+  retail sends the magnitude positive with direction encoded elsewhere,
+  the sign may be a sign-extension bug
+
+**Step 2 refactor (`0b25df5`) is NOT a cause** — confirmed by diff scope:
+`src/AcDream.App/Input/PlayerMovementController.cs`,
+`src/AcDream.Core/Physics/PhysicsEngine.cs`, and
+`src/AcDream.Core.Net/Messages/UpdateMotion.cs` were untouched. Both bugs
+exist on the pre-Step-2 branch (eda936d / 32423c2 / main); the close
+visual scrutiny during Step 2 verification just made them obvious.
+
+**Trace evidence (from `launch.log` of task `b01zkw68w`, Step 2 verification):**
+```
+[B.4b] use guid=0x7A9B46AE seq=159                                ← outbound Use
+OnLiveMotionUpdated: guid=0x5000000A stance=61 cmd=0x speed=      ← player → NonCombat
+OnLiveMotionUpdated: guid=0x7A9B46AE stance=61 cmd=0x0003 speed=  ← NPC turns to face
+OnLiveMotionUpdated: guid=0x7A9B46AE stance=61 cmd=0x speed=
+OnLiveMotionUpdated: guid=0x5000000A stance=0 cmd=0x0005 speed=-1.84  ← ACE's MoveToObject for player (NOT followed)
+OnLiveMotionUpdated: guid=0x5000000A stance=0 cmd=0x speed=
+```
+
+**Files (where the investigation should start):**
+- `src/AcDream.App/Input/PlayerMovementController.cs` — `DriveServerAutoWalk`,
+  walk/run threshold, runRate derivation
+- `src/AcDream.Core.Net/Messages/UpdateMotion.cs` — speed sign-extension
+- Phase B.6 spec: `docs/superpowers/specs/2026-05-14-phase-b6-design.md`
+
+**Research:** Recommend an `ACDREAM_PROBE_AUTOWALK=1` trace run capturing
+the player's body state every frame between Use-outbound and arrival,
+correlated with the inbound `UpdateMotion`. The probe already exists in
+`PhysicsDiagnostics` from Phase B.6 work — should produce the per-frame
+evidence needed without a fresh investigation tool.
+
+**Acceptance:**
+- Click NPC at walking range → player walks (not runs) directly to NPC,
+  Use fires on arrival, NPC dialogue appears.
+- Press F on ground item at walking range → player walks (not runs) the
+  short distance, no overshoot, no blip-back, item enters inventory.
+
+---
+
+## #76 — [DONE 2026-05-16 · `0b25df5`] LiveSessionController extraction (Step 2) regresses interaction + chat outbound
+
+**Status:** DONE
 **Severity:** MEDIUM (refactor blocker; doesn't affect main branch which is unchanged)
 **Filed:** 2026-05-16
-**Component:** app / refactor (Step 2 of `docs/architecture/code-structure.md` §4)
+
+**Resolution (2026-05-16 · `0b25df5`):** Step 2 re-attempted with
+`[step2-diag]` traces at every hypothesized fault point. The traces
+showed all four hypotheses were wrong — `session.hashcode` was identical
+through `_liveSession`, `_liveSessionController.Session`, and the
+captured `liveSession` local in the chat-bus lambda, ruling out
+identity mismatches and closure-capture bugs. Doors verified via
+inbound `OnLiveMotionUpdated` round-trip (cmd=0x000B open, cmd=0x000C
+close). Pickup verified via 4 successful `[B.5] pickup` calls. The
+previous broken run was almost certainly a stale ACE session (no other
+code-level explanation survives the diag trace). One small material
+diff: the chat-bus lambda's `var liveSession = _liveSession;` capture
+became `var liveSession = session;` (the non-null parameter) so the
+compiler can statically prove non-null inside the lambda — both pointed
+to the same `WorldSession` instance, only the static analysis changed.
+
+Traces stripped before commit. Walking-range auto-walk bug observed
+during the second verification run is pre-existing (filed as #77, not
+caused by this refactor).
+
+**Description:** A first attempt at Step 2 — extracting `LiveSessionController`
 
 **Description:** A first attempt at Step 2 — extracting `LiveSessionController`
 out of `GameWindow.cs` — was implemented and reverted in the same session