acdream/docs/research/2026-07-04-r5v5-facade-pickup-prompt.md
Erik aa734f3409 docs: R5 arc close-out — V5 facade shipped, arc DONE; M1.5 critical path next
- r5-wiring-handoff.md: arc close-out banner (V1-V5 trail, relay/anchor
  inventory, carried follow-ons #167 / R6 TS-42 / TS-43)
- roadmap: R5 ledger entry completed through V5 (incl. the #170/#171/V4
  gate history that had only lived in memory/handoffs)
- milestones: the interleaved parity-track note — R5 arc DONE 2026-07-05
- CLAUDE.md Current state: R5 arc DONE; next work = M1.5 critical path
  (#137 dungeon collision, #138 teleport-OUT, A7 dungeon lighting)
- pickup prompt marked DONE

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-05 11:12:37 +02:00

3.6 KiB

Pickup prompt — R5-V5: MovementManager facade (paste into a fresh session)

DONE 2026-07-05. Implemented as specified; suite 4052 green with the protected suites unmodified. Arc close-out lives in 2026-07-03-r5-managers/r5-wiring-handoff.md (top banner).

Read docs/research/2026-07-03-r5-managers/r5-wiring-handoff.md first (the §V4 status note + the facade paragraph are the SSOT), then docs/research/2026-07-03-r5-managers/r5-movementmanager-decomp.md (the retail struct + method inventory is already decompiled — do NOT re-decompile). Then implement R5-V5.

Context: the R5 arc is one slice from done. Shipped + user-gated 2026-07-04: V3 sticky melee (#171, three slices 5bd2b8bc/7a823176/ 69966950 — TS-39 retired, TS-43/TS-44/AP-82 added) and the V4 behavioral items (f423884b — head style-on-change for all movement types, #164 action-replay Autonomous bit, mt-0 wire flags 0x1 stick_to_object / 0x2 StandingLongJump). Worktree vigorous-joliot-f0c3ad, branch claude/vigorous-joliot-f0c3ad.

The slice (STRUCTURAL — zero behavior change): retail gives every entity ONE MovementManager (acclient.h; decomp 0x00524xxx) that owns the motion_interpreter + moveto_manager the R4/R5 work ported. acdream carries them as loose per-entity objects (RemoteMotion.Motion/.MoveTo, PlayerMovementController.Motion/.MoveTo) wired by hand at three sites (EnsureRemoteMotionBindings, EnterPlayerModeNow, the harness). Build the owner class in src/AcDream.Core/Physics/Motion/MovementManager.cs:

  1. Owns MotionInterpreter + MoveToManager (lazy MakeMoveToManager per retail 0x005245b3) + the relay methods whose call shapes are already in the decomp doc: UseTime (minterp → moveto order), HitGround (minterp FIRST then moveto — 0x00524300, already wired inline at 3 sites), HandleExitWorld, CancelMoveTo, HandleUpdateTarget (→ moveto).
  2. Repoint the three wiring sites to construct/hold ONE MovementManager per entity; the existing seam bindings (sinks, StickTo/Unstick, UnstickFromObject, PositionManager handoff) move onto/through it unchanged. GameWindow keeps the wire unpack (Core.Net types stay out of Core.Physics).
  3. Do NOT reshuffle the per-tick order (TS-42's documented inversion is R6 scope, not this slice), do NOT touch the #170/#171 gate-passed machinery, do NOT absorb RouteServerMoveTo/the routing heads into Core.

Acceptance: dotnet build + full dotnet test green with the 183-case/funnel/moveto/chase/sticky suites UNMODIFIED (a structural slice that needs a test edit is a red flag — stop and reassess). Register: no new rows expected; update row source columns that name the old wiring shape. No visual gate needed (zero behavior change) — but launch once and confirm a creature still chases + a door still opens before calling it done.

After this slice: the R5 arc is DONE — update the roadmap/milestones line, write the arc close-out in the wiring handoff, then return to M1.5's critical path (#137 dungeon collision, #138 teleport-OUT, A7 lighting).

Gotchas: revert-prone area — structural moves only, no "while I'm here" improvements; the three wiring sites are load-bearing and comment-dense (keep the retail-anchor comments with the code they describe); the harness (RemoteChaseEndToEndHarnessTests) mirrors GameWindow's wiring field-for-field — update its construction to the facade in the SAME commit or the mirror lies; PowerShell Tee logs are UTF-16 (tr -d '\000' before grep); the user manages client lifecycle (graceful close; if a rebuild is locked by a running client, ask).