acdream/docs/research/2026-08-02-cutover-route-inventory.md

# Production cutover — 8-route inventory (2026-08-02)

Repo: `C:\Users\erikn\.codex\worktrees\af5e\acdream`, branch `codex/port-claude-agents`,
HEAD `9ad590dc`. READ-ONLY research; this file is the only write target.

Sources read first:
- `docs/research/2026-08-02-runtime-continuation-executor-handoff.md` (executor mechanism, complete/dormant)
- `docs/research/2026-07-31-remaining-physics-campaign-handoff.md` sections "What remains" (prereqs A-E) and "Production route cutover" (routes 1-8)
- `docs/research/2026-07-31-canonical-set-position.md` (1,880 B/op allocation finding, line 327-333)
- scratchpad `runtime-surface.md` sections 8-9 (GameRuntime construction, the two legacy `RegisterEntity` call sites)

Key confirmed facts carried in from the map:
- `RuntimeInitialCreateResidenceState`/executor is a COMPLETE, TESTED, but 100% UNWIRED
  mechanism. Grep confirms (map file, line 545-549) the ONLY two production Create call
  sites are:
  - `src/AcDream.Runtime/Session/RuntimeLiveEntitySessionController.cs:76` — `Entities.RegisterEntity(spawn)` (headless/direct-host)
  - `src/AcDream.App/World/LiveEntityRuntime.cs:537` — `_entityObjects.RegisterEntity(...)` (graphical/App)
  Neither calls `RegisterEntityWithInitialResidence`. `CompleteInitialCreateResidence`/
  `AcknowledgeInitialCreateResidenceAdoption` have NO production caller anywhere.
- `GameRuntime.cs:180-183` constructs `RuntimeEntityObjectLifetime` once as `context.EntityObjects`.
  `BindEventContext` at `GameRuntime.cs:266-269` supplies the generation function
  `() => generationReset.ActiveRetiringGeneration ?? context.Session.Generation`.
- 1,880 B/op measured on the warmed dormant placement commit/ack route vs a 2,048 B cap
  (`docs/research/2026-07-31-canonical-set-position.md:327-333`) — explicit 4B2 activation
  blocker, not yet resolved (pool/remove envelopes or record an approved budget).

---

## Cross-cutting: observer-seam status (grep results)

`IRuntimePlacementObserver` **already exists** as a Runtime-side interface —
it is NOT vaporware, contrary to a naive reading of "prerequisite D" as
all-still-to-build:

- Defined `src/AcDream.Runtime/Entities/RuntimeEntityObjectEventStream.cs:18-21`
  (`interface IRuntimePlacementObserver { void OnPlacement(in RuntimePlacementDelta delta); }`).
- `RuntimeEntityObjectEventStream` (same file) already has the full pub/sub
  plumbing: `_placementObservers` array (line 40), `SubscribePlacement`
  (119-133, copy-on-write add), `UnsubscribePlacement` (356-369), dispatch
  loop (302-310ish inside the drain routine), `PublishPlacement` (164-171,
  builds a `RuntimePlacementDelta(NextStamp(), placement)` and enqueues it
  through the same ordered synchronous drain as entity/inventory deltas).
- Public host seam: `src/AcDream.Runtime/Physics/RuntimePlacementProjectionChannel.cs`
  (88 lines, read in full) — `Subscribe(IRuntimePlacementObserver)` (31-32,
  thin passthrough to `_events.SubscribePlacement`), `Acknowledge(expectedGeneration, token)`
  (51-55, generation-gated call into `_setPosition.AcknowledgeProjection`),
  `RetryPending` (61-67), `TryPeek` (72-80, non-consuming), `PendingCount` (82).
  This channel is constructed once inside `RuntimeEntityObjectLifetime`'s ctor
  (`Placements = new RuntimePlacementProjectionChannel(Events, Physics.SetPosition)`,
  per the surface map's file-1 section) and exposed on `GameRuntime.Placements`.
- Receipt shape: `RuntimePlacementProjectionSnapshot` (`RuntimeSetPositionState.cs:210-217`):
  `Token, Kind (Withdraw|Place|Discard — enum at line 57-61), WorldPosition,
  Orientation, CellLocalPosition, InContact, OnWalkable`.
- **What does NOT exist**: grep across `src/AcDream.App/**/*.cs` and
  `src/AcDream.Headless/**/*.cs` for `IRuntimePlacementObserver`,
  `SubscribePlacement`, or `Placements.Subscribe` returns ZERO matches
  (confirmed via `grep -rln` across both trees; the only hits anywhere in the
  repo outside `src/AcDream.Runtime/` are 5 Runtime-test fake-observer classes
  in `tests/AcDream.Runtime.Tests/**`, e.g.
  `RuntimeInitialCreateResidenceStateTests.cs:2651`,
  `RuntimeSetPositionStateTests.cs:2610`/`2641` (`ThrowingPlacementObserver`),
  `RuntimeCollisionPrefixQuiescenceTests.cs:877`,
  `RuntimeLocalPlayerPhysicsPublicationStateTests.cs:2326`). **Neither host
  has ever constructed a production `IRuntimePlacementObserver` implementation.**
  Prerequisite D ("Add one graphical and one headless `IRuntimePlacementObserver`
  using `GameRuntime.Placements`") is 100% unbuilt on the host side even though
  the Runtime-side plumbing it will attach to is complete and tested.

## Cross-cutting: connected-gate harness (exact scripts/env)

- **Exact lifecycle/reconnect gate**: `tools/run-connected-world-lifecycle-gate.ps1`
  (477 lines, read in full). Drives two sequential `AcDream.App.exe` sessions
  against the always-up local ACE (127.0.0.1:9000):
  1. `capped` session using route script `tools/connected-world-lifecycle.route.txt`,
     expects exactly 6 named checkpoints (`capped_login, aerlinthe_first, rynthid,
     facility_hub, holtburg_after_dungeon, aerlinthe_revisit`) and 5 screenshots.
  2. `uncapped-reconnect` session (starts as soon as ACE's own log records the
     first session's transport Disconnect — no artificial settle delay) using
     `tools/connected-world-reconnect.route.txt`, expects one checkpoint
     `uncapped_reconnect`.
  Per-session env (lines 250-281): `ACDREAM_DAT_DIR`, `ACDREAM_LIVE=1`,
  `ACDREAM_TEST_HOST=127.0.0.1`, `ACDREAM_TEST_PORT=9000`,
  `ACDREAM_TEST_USER`/`ACDREAM_TEST_PASS`, `ACDREAM_RETAIL_UI=1`,
  `ACDREAM_FRAME_PROF=1`, `ACDREAM_UNCAPPED_RENDER` (1 for the reconnect leg
  only), `ACDREAM_UI_PROBE_SCRIPT=<route.txt path>`,
  `ACDREAM_AUTOMATION_ARTIFACT_DIR=<per-session artifact dir>`; several other
  vars explicitly cleared (`ACDREAM_RENDER_BACKEND`, `ACDREAM_NET_DROP_*`,
  `ACDREAM_DUMP_MOVE_TRUTH`, `ACDREAM_WB_DIAG`) to keep the gate a clean
  baseline. `Validate-Checkpoint` (140-227) asserts, per checkpoint: reveal
  readiness/no invariant failures, Runtime environment ownership initialized
  with exactly one active day group, **every `transitOwnership` counter
  (`bufferedTeleportDestinationCount, pendingTeleportStartCount,
  activeTeleportCount, acceptedTeleportDestinationCount, activeRevealCount,
  pendingDestinationReadinessCount, hostProjectionCount,
  pendingHostAcknowledgementCount`) is exactly zero at a stable checkpoint**,
  zero pending live teardowns/landblock retirements/staged mesh
  uploads/composite warmups, and (optionally) zero collision-shadow
  mismatches/faults. Client must exit only via graceful `WM_CLOSE`
  (`Close-ClientGracefully`, 85-92) and ACE's own log must record
  `graceful logout confirmed` + a `PacketHeader Disconnect` drop
  (347-354) — **this cutover MUST add placement-owner counters
  (pending placement receipts, active leases, pending FIFO continuations) to
  this SAME zero-at-stable-checkpoint discipline**, matching the existing
  `transitOwnership`/`resources` pattern, or the gate will not actually prove
  placement convergence.
- **Canonical nine-stop route**: `tools/run-connected-r6-soak.ps1` (only first
  60 lines read) driving `tools/connected-r6-soak.route.txt`, 9 named
  checkpoints in order: `caul-baseline, sawato-baseline, rynthid, aerlinthe,
  sawato-return, holtburg, caul-return, sawato-plateau, caul-plateau` (Caul/
  Sawato/Holtburg legs additionally "Exercise"d — likely movement stress, not
  just a static stop). Supports `-Uncapped`/`-DenseTown` switches (DenseTown
  swaps in `connected-dense-town.route.txt` against a single `arwic-dense`
  checkpoint instead). Same env-var family as the lifecycle gate
  (`-SkipBuild`, `-LoginTimeoutSeconds`, `-CollisionShadowEvery`). Historical
  evidence of both capped and uncapped passing runs:
  `docs/research/2026-07-25-slice-g5-production-profile.md:38-39`
  (`logs/connected-r6-soak-20260725-105133.report.json` /
  `...-121035.report.json`).
- Both scripts require a pre-existing, already-listening local ACE on UDP
  9000 and a live `AceLogPath` (default `C:\ACE\Server\ACE_Log.txt`) and will
  themselves invoke `dotnet build ... -c Release` unless `-SkipBuild`.

## Cross-cutting: 1,880 B/op allocation budget (4B2 activation blocker)

`docs/research/2026-07-31-canonical-set-position.md:327-333`: "The warmed
immediate commit/ack route currently measures exactly **1,880 managed bytes
per operation** in the Release Runtime test host (1,000 iterations after 64
warmups); the regression gate caps it at 2,048 bytes. This dormant-path
result is an explicit 4B2 activation blocker rather than a claim of
allocation-free production readiness: 4B2 must either pool/remove the
operation and projection envelopes or record an approved measured budget
before routing frame-frequency placement through this owner." Restated
verbatim in the executor handoff
(`docs/research/2026-08-02-runtime-continuation-executor-handoff.md:181-184`).
**Not yet resolved as of this research pass** — no commit after
`2026-07-31-canonical-set-position.md` claims pooling/removal of the
operation/projection envelopes, and the executor handoff still calls it "the
standing 4B2 activation blocker." This matters most for routes 2 (Local
ForcePosition, frame-frequency-ish under repeated corrections), 4 (remote
Position, genuinely per-network-tick high frequency), and 5 (projectile
per-quantum integration, explicitly excluded from SetPosition routing for
exactly this reason per route 5's "Do not route ordinary per-quantum
projectile integration through SetPosition").

## Cross-cutting: `Execute`'s caller-supplied live inputs are unwired in BOTH hosts

`RuntimeInitialCreateContinuationExecutor.Execute` takes an
`in RuntimeInitialCreateExecutionInputs inputs` parameter
(`RuntimeInitialCreateContinuationExecutor.cs:47-49`):
`bool UsePositionFromServer, float PlayerDistance` — doc comment (38-46):
"Executor-time inputs sampled at the retail decision point. These cannot be
retained at admission time because they describe LIVE state (the local
player, the current physics simulation)... contact is NOT one of these — it
comes solely from the retained wire packet's own `IsGrounded` bit, never from
a live body query." Both fields feed directly into
`RuntimeAuthoritativePositionRouteClassifier.ClassifyAcceptedPosition`'s
`RuntimeAcceptedPositionRouteRequest.UsePositionFromServer`/`PlayerDistance`
fields (`RuntimeAuthoritativePositionRouteClassifier.cs:137`, consumed at
line 338 for the LocalPlayer interpolate-vs-not branch and later for the
Remote/Projectile near/far 96 m threshold). **Grep across
`src/AcDream.App/` and `src/AcDream.Headless/` for `UsePositionFromServer`
returns ZERO source hits (only compiled `bin`/`obj` binary matches).**
Neither host currently computes or tracks a `UsePositionFromServer` concept
anywhere in production code — this is a genuinely new per-call input a
cutover caller must supply on every `Execute` call, not something that can be
threaded through unchanged from an existing option/flag. `PlayerDistance` is
likely derivable today from existing local-player/WorldEntity state (it is
NOT a new concept — some form of distance-to-local-player computation
already exists for other purposes, e.g. streaming radius), but it has never
been wired specifically into this call contract either.

---

## Prerequisite C context (atomic local controller/body publication)

Campaign handoff (`docs/research/2026-07-31-remaining-physics-campaign-handoff.md:203-221`)
requires ONE Runtime-owned exclusive/versioned controller/body publication
transaction "respected by **every** canonical body writer" — rejects the
prior prototype (a snapshot/rollback lease) as failure-atomic-only, not
reentrant-safe (line 143-168: a nested SetPosition/remote-bind/GUID-reuse/
clock-epoch-change/disposal racing the open lease could let the outer
rollback erase newer authority or detach a body another owner already uses).

Today's per-host body construction (both confirmed by direct read, both are
literally the two things prerequisite C must unify):
- **Graphical**: `PlayerModeController.BuildControllerAndCamera`
  (`src/AcDream.App/Input/PlayerModeController.cs:244-...`, only the first
  ~140 lines read directly by me) constructs `new PlayerMovementController(...)`
  (line 259-262) directly against `_physics`/`playerRecord.ObjectClock`, wires
  a `MoveToManager` facade and `EntityPhysicsHost` closures over captured
  locals (267-345+), and stores the result in the App-local `_controllerSlot.Controller`
  (not `_runtime.MovementOwner.Controller` directly at this point in the file —
  Agent 1's detailed route-1 report is authoritative for exactly where/whether
  this crosses into `RuntimeLocalPlayerMovementState`/`GameRuntime.MovementOwner`).
- **Headless**: `HeadlessSessionWorldProjection.CreateController`
  (`src/AcDream.Headless/Hosting/HeadlessSessionWorldProjection.cs:639-655`)
  constructs `new PlayerMovementController(_runtime.EntityObjects.Physics.Engine,
  record.ObjectClock, PlayerMovementConstructionOptions.From(...))` (642-646),
  applies physics state/step heights/movement skills (647-652), and is the
  ONLY production writer of `_runtime.MovementOwner.Controller = controller`
  in the entire repo (confirmed by grep — the graphical host does NOT write
  `_runtime.MovementOwner.Controller` anywhere findable by that exact token;
  it may go through a different Runtime seam — flag as an open question for
  whoever designs prerequisite C: **confirm whether the graphical host's
  built controller is ever actually published into `RuntimeLocalPlayerMovementState`
  the same way headless's is, or whether this is itself an existing
  graphical/headless asymmetry prerequisite C must resolve**).
- `HeadlessSessionWorldProjection.SynchronizeLocalPlayer`
  (566-615, read in full) is the duplicate placement authority for headless
  route 1/8: calls `_runtime.EntityObjects.Physics.Engine.Resolve(...)` (589-594)
  then `.ResolvePlacement(...)` (595-605) directly, then
  `controller.SetPosition(resolved.Position, resolved.CellId, wirePosition)`
  (610-613) and `controller.SetBodyOrientation(orientation)` (614) — entirely
  independent of `RuntimeSetPositionState`/`RuntimeInitialCreateResidenceState`.
  `HeadlessSessionWorldProjection.BlipLocalPlayer` (617-637) similarly calls
  `controller.BlipPosition(...)` (633-636) directly with no Runtime placement
  commit/ack in between — this is the headless twin of route 2's "direct
  BlipPosition/pre-commit acknowledgement" duplicate authority.

---

## Cross-cutting: accessibility is NOT a blocker (correction of an initial hypothesis)

I initially suspected the residence/executor surface being entirely `internal`
(`RegisterEntityWithInitialResidence`, `InitialCreateResidences`,
`InitialCreateExecution`, `Execute`, `CompleteInitialCreateResidence`,
`AcknowledgeInitialCreateResidenceAdoption` — confirmed all `internal` via
direct grep of `RuntimeEntityObjectLifetime.cs` and
`RuntimeInitialCreateContinuationExecutor.cs:426`) might block the graphical
host (a different assembly) from calling them at all. **This is WRONG —
verify before citing it as a gap.** `src/AcDream.Runtime/AcDream.Runtime.csproj:11-16`
declares `InternalsVisibleTo` for `AcDream.Runtime.Tests`, **`AcDream.App`**,
`AcDream.App.Tests`, `AcDream.Core.Tests`, **`acdream-headless`**, and
`AcDream.Headless.Tests` — both hosts already have full internal-member
access to `AcDream.Runtime`. Route 1's research agent independently confirmed
this at the exact same csproj lines. **There is no accessibility barrier to
either host calling `RegisterEntityWithInitialResidence`/driving the executor
today** — the reason nobody does is purely that the call sites haven't been
switched yet, not an assembly-boundary problem. Do not resurrect this as a
"gap" in the final report.

---

## Route 1 — Initial login and CreateObject (from parallel research agent, spot-checked)

### Graphical host chain (wire -> presentation)

1. `src/AcDream.App/Net/LiveEntitySessionController.cs:51-53` — `OnSpawned` wire
   entry, routes `CreateObject` via `RetailInboundEventDispatcher.Run` to
   `LiveEntityHydrationController.OnCreate`.
2. `src/AcDream.App/World/LiveEntityHydrationController.cs:226-250` — `OnCreate`
   (dormant/stale-generation classification) -> `OnCreateCore`.
3. `LiveEntityHydrationController.cs:259-262` — `OnCreateCore` (under `_datLock`)
   calls `_runtime.RegisterLiveEntity(spawn)`.
4. `src/AcDream.App/World/LiveEntityRuntime.cs:526-539`, **line 537**:
   `_entityObjects.RegisterEntity(incoming, RetirePriorProjection)` — the
   LEGACY non-residence call, confirmed exact line from the handoff doc.
5. `src/AcDream.Runtime/Entities/RuntimeEntityObjectLifetime.cs:315-322` —
   `RegisterEntity` -> `RegisterEntityCore(incoming, beginInitialResidence:false, ...)`
   — never touches `InitialCreateResidences`/`InitialCreateExecution`.
6. `LiveEntityHydrationController.cs:288-294` — `ApplyAcceptedSpawn(...)` commits
   the accepted snapshot (still cellless authority, no position/rebucket yet).
7. `LiveEntityHydrationController.cs:938-1040` (`ProjectExactOnce`), line 1036:
   `_materializer.TryMaterialize(...)`.
8. `src/AcDream.App/Rendering/DatLiveEntityProjectionMaterializer.cs:407-427` ->
   `MaterializeProjection` (680-857).
9. **Duplicate authority** — `DatLiveEntityProjectionMaterializer.cs:712-737`:
   `_runtime.MaterializeLiveEntity(..., out expectedRecord)` with the
   `residence` parameter OMITTED, defaulting to
   `LiveEntityMaterializationResidence.LegacyImmediate`
   (`LiveEntityRuntime.cs:596-597`).
10. `LiveEntityRuntime.cs:589-789` (`MaterializeLiveEntity`) — constructs the
    `WorldEntity` (sets Position/Rotation/ParentCellId directly from
    wire-decoded world position, ~718-729); because residence is
    `LegacyImmediate` not `AwaitRuntimePlacement`, falls through at **line 777**
    to `RebucketLiveEntity(serverGuid, fullCellId)`.
11. **Duplicate authority** — `LiveEntityRuntime.cs:792-931` (`RebucketLiveEntity`):
    immediately calls `_spatial.RebucketLiveEntity(...)` (spatial bucket
    mutation), sets `IsSpatiallyProjected/Visible`, calls
    `_entityObjects.CommitRebucket(...)` (canonical `FullCellId`/
    `CanonicalLandblockId` write), resets/suspends the object clock — all
    synchronous, no Runtime placement receipt involved anywhere in this path.
12. `DatLiveEntityProjectionMaterializer.cs:791-820` — builds collision, binds
    projectile runtime; for static-animating physics objects,
    `RegisterAnimation` (859-1021) at **1003-1016** calls
    `_runtime.GetOrCreatePhysicsBody(spawn.Guid, incarnation => new
    PhysicsBody{...}.SnapToCell(...))` — a SECOND, narrower body-construction
    duplicate authority (non-player static-animation bodies).
13. `LiveEntityHydrationController.cs:739-759`/`1070-1098` — publish-ready via
    `ILiveEntityReadyPublisher.Publish`.
14. `src/AcDream.App/Input/PlayerModeAutoEntry.cs:214-230` — per-frame guard;
    once `IsPlayerEntityPresent` + `IsWorldReady` (world-reveal, unrelated to
    any Runtime placement receipt) -> `EnterPlayerMode()` ->
    `PlayerModeController.EnterFromAutoEntry`.
15. `src/AcDream.App/Input/PlayerModeController.cs:126-133,217-242` ->
    `TryEnter` -> **`BuildControllerAndCamera`** (244-525).
16. **Duplicate authority** — `PlayerModeController.cs:409-413`:
    `_physics.Resolve(playerEntity.Position, initialCellId, Vector3.Zero, 100f)`.
17. **Duplicate authority** — `PlayerModeController.cs:422-430`:
    `_physics.ResolvePlacement(...)` using a locally computed Setup cylinder
    (`_motionBindings.GetSetupCylinder`) — no shared "exact Setup mover" step.
18. **Duplicate authority** — `PlayerModeController.cs:449-480`: builds
    `EntityPhysicsHost`/`MoveToManager`, installs via
    `EntityPhysicsHostComposition.SelectStableHostWithoutRebind`/`InstallOrRebind`
    (`src/AcDream.App/Physics/EntityPhysicsHostComposition.cs:16,35`) — its own
    body/controller construction, independent of headless's copy.
19. Camera — `PlayerModeController.cs:440-447`: constructs
    `ChaseCamera`/`RetailChaseCamera`, `_camera.EnterChaseMode(...)`
    (host-only concern, stays, but must be gated by the Runtime ack not
    ad-hoc resolve success).
20. **Duplicate authority — final commit** — `PlayerModeController.cs:482-484`:
    `playerEntity.SetPosition(initial.Position); playerEntity.ParentCellId =
    initial.CellId; controller.CommitPreparedPosition();` — direct write,
    bypasses any Runtime `Place` receipt.

### Headless host chain

Same shape as the graphical route through `RegisterEntity`/`ApplyAcceptedSpawn`
(`RuntimeLiveEntitySessionController.cs:73-95`, see Route 8 section above for
the full per-line breakdown), then `IRuntimeDirectWorldProjection.ProjectSpawn`
-> `HeadlessSessionWorldProjection.SynchronizeLocalPlayer`
(566-615)/`CreateController` (639-655) — same duplicate-authority shape as
graphical hops 16-20, but a SEPARATELY HAND-WRITTEN copy, not shared code
(confirmed by the codebase's own comment at
`HeadlessSessionWorldProjection.cs:685-689` contrasting itself with "the
graphical `PlayerModeController.ApplyStepHeights`"). No headless equivalent of
graphical hops 12-14/19 exists (no `WorldEntity`/render sidecar/camera).

### What each hop must become / capability gaps (route 1)

- Switch `RegisterLiveEntity`/`OnSpawned` from `RegisterEntity` to
  `RegisterEntityWithInitialResidence` — **no accessibility blocker** (see
  correction above); this is a pure call-site + follow-up-loop change.
- DELETE `MaterializeProjection`'s direct `RebucketLiveEntity` fall-through;
  pass `residence: LiveEntityMaterializationResidence.AwaitRuntimePlacement`
  (the enum value ALREADY EXISTS and is used by other routes via
  `LiveEntityRuntime.cs:765-776`/`938-1127`'s
  `TryApplyRuntimePlacementPlace`/`Withdrawal` — this route just isn't
  plumbed into it yet).
- DELETE `PlayerModeController.cs:409-430` (own Resolve/ResolvePlacement) and
  `482-484` (direct SetPosition/CommitPreparedPosition); body/controller
  construction becomes acknowledge-only from the shared Runtime-resolved
  position.
- DELETE headless `SynchronizeLocalPlayer:589-607` and `610-614` the same way.
- DELETE the legacy `RegisterEntity` overload entirely once both hosts move
  (`RegisterEntityWithInitialResidence` is already a strict superset).
- **Gap 1 (real)**: no shared "exact Setup mover" / DAT-preparation API.
  `RuntimeInitialCreateResidenceState.Own` only OPENS the placement slot
  (`TryBeginExclusiveAuthoredPlacement`); nothing in Runtime resolves a
  Setup-derived cylinder/sphere-list and feeds it into
  `RuntimeSetPositionState.SubmitPreparedPlacement`. Today that DAT read +
  Resolve/ResolvePlacement call is hand-duplicated with DIFFERENT defaults in
  App (`_motionBindings.GetSetupCylinder`) vs. headless (hardcoded
  `DefaultRadius=0.48f`/`DefaultHeight=1.835f` unless `_preparedCollision`
  supplies a Setup) — this is exactly prerequisite B, confirmed still open.
- **Gap 2 (real)**: no shared "atomic Runtime controller/body" owner exists
  anywhere (`RuntimeEntityRecord` has storage slots — `PhysicsBody`,
  `PhysicsHost` — but no construction logic); `BuildControllerAndCamera` and
  `HeadlessSessionWorldProjection.CreateController` are two independently
  written, divergent implementations of the same "build a
  `PlayerMovementController`/host from a `RuntimeEntityRecord`" job. This IS
  prerequisite C, confirmed still unbuilt in production code.
- **Gap 1 REFINEMENT (verified directly, not from an agent)**: "no shared Setup
  mover API" is not quite right — `RuntimeSetPositionState.PrepareMover`
  (`RuntimeSetPositionState.cs:1079-1133`) + `RuntimeSetPositionMoverPreparer.TryBuild`
  (`RuntimeSetPositionMoverPreparation.cs:69+`) **already exist** as the shared
  authored-mover-preparation API prerequisite B calls for, and
  `SubmitPreparedPlacement` (`RuntimeSetPositionState.cs:2041`) already
  requires `operation.Record.PhysicsBody is not { } body` to be non-null
  BEFORE a placement can even be submitted — i.e. prerequisite C's body must
  exist first, structurally enforced. What's genuinely missing is the HOST
  input: `PrepareMover` takes a `RuntimeSetPositionMoverPreparation` whose
  `Setup` field is a host-supplied `RuntimeSetPositionMoverSetup` (Setup
  table ID + `FlatSetupCollision?`, `RuntimeSetPositionMoverPreparation.cs:23-42`)
  — Runtime does NOT read DAT itself; the host must call
  `IPreparedCollisionSource.ReadSetupCollision(setupId)` (already used by
  headless at `HeadlessSessionWorldProjection.cs:668-679`) and feed the
  result in. **No production call site anywhere chains
  `ReadSetupCollision` -> `PrepareMover` -> `SubmitPreparedPlacement`** — both
  hosts instead read Setup DAT/prepared-collision data ad hoc and call
  `PhysicsEngine.Resolve`/`ResolvePlacement` directly, entirely bypassing this
  already-built pipeline. This is a wiring gap, not a missing-mechanism gap.
- **Gap 3 (real, previously unstated)**: the executor publishes only generic
  `RuntimeEntityChange` via `_events.PublishEntity`
  (`RuntimeInitialCreateContinuationExecutor.cs:2053-2061`), NOT through
  `RuntimePlacementProjectionChannel`/`Placements` — the channel the existing
  App `TryApplyRuntimePlacementProjection`/headless placement sinks already
  consume for OTHER routes. Whether a residence-driven initial commit
  actually surfaces a `Place` token on the SAME channel other routes use is
  unconfirmed/unbuilt — this bridge must be built, not assumed.
- Confirms the executor handoff's own claim: zero production callers of
  `Execute`/`RegisterEntityWithInitialResidence` today.

---

## Route 2 — Local ForcePosition (from parallel research agent)

Graphical-only (headless equivalent is folded into Route 8's ForcePosition
branch, already covered above).

### Call chain

`src/AcDream.Core.Net/WorldSession.cs:1767` (wire opcode `0xF748`
UpdatePosition — same opcode for ordinary and force; "force" is purely a
`ForcePositionSequence` freshness fact) -> `WorldSession.cs:1774-1786` raises
`PositionUpdated` -> `src/AcDream.App/Net/LiveEntitySessionController.cs:67-69`
-> `src/AcDream.App/Physics/LiveEntityNetworkUpdateController.cs:1024` `OnPosition`
-> `:1035-1048` `_authorityGate.TryAcceptPosition` ->
`LiveEntityInboundAuthorityGate.cs:148-206` -> `_liveEntities.TryApplyPosition` ->
`PhysicsTimestampGate.cs:181-218` `TryAcceptPositionEvent` (retail
`SmartBox::HandleReceivedPosition` 0x00453FD0 FORCE_POSITION branch) returns
`ForcePosition` when newer AND `teleport == current teleport stamp` ->
`LiveEntityNetworkUpdateController.cs:1101-1117` `forceLocal` computed ->
**`LocalForcePositionTransaction.Apply`** (`src/AcDream.App/Physics/LocalForcePositionTransaction.cs:10-28`,
**duplicate authority**): `if (!isCurrent()) return false; blip(); acknowledge();
return isCurrent();` where `blip` = `PlayerMovementController.BlipPosition`
(`src/AcDream.Runtime/Gameplay/PlayerMovementController.cs:1759-1773`: `_body.SnapToCell`,
`UpdateCellId` at `:1577-1599` which ALSO publishes the render root via
`_physics.UpdatePlayerCurrCell`) and `acknowledge` = `LocalPlayerOutboundController.SendImmediatePosition`
(`src/AcDream.Runtime/Gameplay/LocalPlayerOutboundController.cs:152-185`,
**sends the outbound `AutonomousPosition` ack BEFORE any Runtime canonical
commit exists — the exact pre-commit-ack bug the campaign handoff names**).
Falls through unconditionally into the **generic tail**
(`LiveEntityNetworkUpdateController.cs:1252-1270`, **second duplicate
authority**): `entity.SetPosition`/`ParentCellId`/`Rotation` +
`_liveEntities.RebucketLiveEntity(...)` on the render-facing `WorldEntity` —
a SECOND independent mutation of the SAME accepted Position, parallel to the
`PlayerMovementController` body mutated by the first authority (two-store
divergence, the exact bug class the executor handoff says it already fixed
for Create).

### What becomes what / gaps

- DELETE `LocalForcePositionTransaction` outright; its job (validate
  ownership, blip, ack-once) becomes `RuntimeSetPositionState.Apply`/
  `BeginAcceptedPlacement` with `RuntimeSetPositionOperationKind.LocalAuthoritative`.
- `OnPosition`'s force branch reduces to: classify via
  `RuntimeAuthoritativePositionRouteClassifier.ClassifyAcceptedPosition` (its
  `ForcePosition` branch — lines 291-313 — **already produces exactly**
  `SetPositionSimple`, `PreserveHeading: true`, `SendPositionImmediately: true`
  — this route kind is FULLY MODELED already, just unused) -> submit through
  `RuntimeSetPositionState` -> only call `SendImmediatePosition` AFTER commit
  (fixes the ordering bug).
- `BlipPosition` becomes acknowledge-only (applies the already-committed
  Runtime projection instead of being an independent authority).
- DELETE the generic tail's second `entity.SetPosition`/`RebucketLiveEntity`
  for the local player (1252-1270) — dead code once the host projects only
  the one canonical result.
- **Gap (confirmed)**: zero production references to
  `RuntimeAuthoritativePositionRouteClassifier`/`RuntimeSetPositionState`
  anywhere in `src/AcDream.App` for Position handling — tracked by issue
  **#275** ("post-cutover unification of the legacy Position path onto the
  classifier"), cited in both the executor handoff and the divergence
  register's AP-131 row.
- **Gap (confirmed)**: "reject a stale host ack" already exists structurally
  (`RuntimeSetPositionState.IsPlacementCurrent`/`ConsumeAcknowledgedPlacement`,
  exact-token requirement) but is unwired for Route 2.
- **Scope note**: the continuation EXECUTOR (`Execute`/FIFO drain) is scoped
  to initial-Create admission, not steady-state Position on an
  already-resident entity — Route 2's correct integration point is
  `RuntimeSetPositionState`/`InboundPhysicsStateController.ApplyAcceptedPositionSnapshot`
  directly, NOT `Execute`. The `AwaitingContinuationPlacement` retry flavors
  are documented generically but demonstrated only for Create — their
  applicability to a live ForcePosition is unproven, not just unwired.
- The 1,880/2,048-byte allocation budget applies directly here: ForcePosition
  is genuinely frame-frequency-ish traffic.

---

## Route 3 — Portal transit and materialization (from parallel research agent)

`LocalPlayerTeleportPlacement` exists verbatim (not renamed) inside
`src/AcDream.App/Streaming/LocalPlayerTeleportController.cs:183-290`.

### Call chain

Two wire inputs join in `RuntimeWorldTransitState`: **F751 start** (`WorldSession.cs:1972-1987`
opcode `0xF751`) -> `LiveEntitySessionController.cs:83-85` `OnTeleportStarted`
-> `LocalPlayerTeleportController.cs:436-459` gates on
`LiveLocalPlayerTeleportAuthority.IsFreshStart` ->
`PhysicsTimestampGate.IsFreshTeleportStart` and
`RuntimeWorldTransitState.TryQueueTeleportStart` (`:426-442`). **Destination
Position** rides the SAME wire path as Route 2, then at
`LiveEntityNetworkUpdateController.cs:1906-1913` (guarded on `disposition==Apply
&& guid==playerServerGuid`) calls `_localPlayerTeleport.OfferDestination(...)`
-> `RuntimeTeleportDestinationAdapter.cs:15-36` (pure mapping) ->
`RuntimeWorldTransitState.OfferTeleportDestination` (`:480-520`). Every frame,
`LocalPlayerTeleportController.Tick` (`:472-570`) drives:
`TryAimAcceptedDestination`/`AimDestination` (`:626-734`, classifies via
`TeleportLandblockTransition.Classify` — streaming-only, no world mutation) ->
`WorldRevealCoordinator.TryBeginPortal` -> `RuntimeWorldTransitState.TryBeginPortalReveal`
(mints reveal generation + host projection token). On `TeleportAnimEvent.Place`:
preflight `RuntimeWorldTransitState.CanPlacePortalDestination` (read-only gate)
-> **`LocalPlayerTeleportPlacement.Place`** (`LocalPlayerTeleportController.cs:214-278`,
**the duplicate authority**) -> THEN `WorldRevealCoordinator.ObserveMaterialized`
-> `RuntimeWorldTransitState.AcknowledgePortalMaterialized` runs AFTER `Place`
has already fully mutated world state — **a rubber-stamp, not a gate**. On
`TeleportAnimEvent.FireLoginComplete`: `_session.SendLoginComplete()` (outbound
ack) -> `RuntimeWorldTransitState.Complete`.

`LocalPlayerTeleportPlacement.Place` (full method, 214-278) mutates in order:
`_physics.Resolve(...)` (own collision placement) -> `controller.SetPosition(...)`
(body+cell) -> `entity.SetPosition`/`ParentCellId`/`Rotation` on `WorldEntity`
-> `_liveEntities.RebucketLiveEntity(...)` (throws on failure) ->
`_host.Host?.NotifyTeleported()` (retail `teleport_hook` tail) ->
`controller.SetBodyOrientation(rotation)` -> camera reset
(`_cameras.Legacy?.Update`/`_cameras.Retail?.ResetViewerToPlayer`, **unique to
this route vs. Route 2**) -> `_spatial.Reconcile()`.
`TeleportViewPlaneController` (view-plane/FOV easing) is presentation-only,
NOT in scope for deletion.

### What becomes what / gaps

- DELETE `Place`'s resolve/controller/world-entity/rebucket/host-notify/
  orientation mutations outright; replace with
  `RuntimeSetPositionState.BeginAuthoredPlacement`/`Apply` carrying a
  populated `RuntimePortalPlacementAuthority`, then project only the
  committed result.
- Re-sequence `WorldRevealCoordinator.CanPlacePortalDestination`/
  `ObserveMaterialized` to be the ACTUAL gate/confirmation around the
  canonical commit (not rubber-stamps around a host-owned mutation) — i.e.
  materialization fires from the Runtime commit callback, not immediately
  after `Place()`'s direct mutations.
- Camera reset and `_spatial.Reconcile()` become acknowledge-only reactions.
- Headless has the analogous duplicate authority in
  `HeadlessSessionWorldProjection.PrepareDestination`/`SynchronizeLocalPlayer`
  (already documented in the Route 8 section above) — must cut over in
  lockstep, same target (`RuntimeSetPositionState`).
- **Gap (confirmed, important)**: `RuntimeWorldTransitState` (1012 lines,
  Slice J6) already fully owns reveal generation/sequence/destination-cell,
  readiness, materialization/completion/cancellation, and the 4-stage host
  acknowledgement protocol (`ProjectionRegistered -> SimulationReleaseProjected
  -> DestinationReservationReleased -> TerminalProjected`) — but ONLY for
  streaming/render-resource bookkeeping, NEVER for gating an actual placement
  mutation. `RuntimePortalPlacementAuthority` (`RuntimeSetPositionState.cs:64-78`,
  carrying `RevealGeneration`/`TeleportSequence`/`RuntimeWorldHostProjectionToken`)
  is a REAL, VALIDATED constructor parameter on `RuntimeSetPositionCommand.Portal`
  (validated in `BeginAcceptedPlacementCore`, `:978-984`) and
  `LiveEntityRuntime.cs:1162-1171` even has an `IsValidPortalPlacementAuthority`
  presentation-side validator — **but grep across App and Headless finds ZERO
  call sites that ever construct one with `Present: true`.** The binding
  machinery is real but 100% dormant end to end.
- **Missing for Route 3 specifically**: (a) the adapter that reads
  `WorldRevealCoordinator`'s current generation/sequence/destination-cell/host
  projection token into a `RuntimePortalPlacementAuthority`; (b) the actual
  `RuntimeSetPositionState.BeginAuthoredPlacement` call site using
  `LocalAuthoritative` + that authority (does not exist anywhere today); (c)
  re-sequencing `ObserveMaterialized` to run from the commit callback.
- **Discard/cancellation semantics** (a stale generation/sequence/cell/token
  must never reveal) look structurally sufficient
  (`RuntimePlacementProjectionKind.Discard`, `IsPlacementCurrent`,
  `RuntimeWorldTransitState.Cancel`/`BeginHostProjectionSupersession`) but are
  UNEXERCISED together for a real placement — treat as an explicit cutover
  test, not an assumed-correct combination.
- Executor scope note: same as Route 2 — the FIFO/`Execute` mechanism is
  Create-admission-scoped; Route 3's target is `RuntimeSetPositionState`
  directly.

---

## Route 4 — Remote CreateObject and Position (from parallel research agent)

### Foundational fact (independently confirmed by this agent AND by direct
grep during this research pass)

`InboundPhysicsStateController.cs:596-608`'s own doc comment states verbatim:
"this file's `TryApplyPosition` is today's **only PRODUCTION Position wire
caller**; the classifier-based path is **test-only** until a host wires the
executor." `RuntimeEntityObjectLifetime.TryApplyPosition` only enters the
classifier/executor path when `TryGetPendingInitialResidence` finds an
in-flight CreateObject continuation (a narrow transient window) — steady-state
remote UpdatePosition always falls to the legacy unconditional-merge path
with **no route-classification concept at all**.

### Call chain

`LiveEntitySessionController.cs:67-69` -> `LiveEntityNetworkUpdateController.OnPosition`
(`:1035`) -> `LiveEntityInboundAuthorityGate.cs:161` `TryApplyPosition` ->
`LiveEntityRuntime.cs:2116,2135` -> `RuntimeEntityObjectLifetime.cs:1229,1299`
steady-state branch -> `RuntimeEntityDirectory.cs:478` ->
`InboundPhysicsStateController.cs:610` (legacy unconditional timestamp-gated
merge). Then `LiveEntityNetworkUpdateController.cs:1197-1211` computes
`remoteHardTeleport`/`remotePlacementRequired` from `timestamps.TeleportHookRequired`
and `_remoteTeleportController.HasPending`; `RunRemoteTeleportHook` (`:1210`)
-> `RemoteTeleportHook.Execute` (`RemoteTeleportHook.cs:17`, CancelMoveTo/
UnStick/StopInterpolating/UnConstrain/NotifyTeleported/ReportCollisionEnd).
**Then, UNCONDITIONALLY** (`LiveEntityNetworkUpdateController.cs:1252-1270`,
**duplicate authority**, BEFORE any placement/teleport branch runs):
`entity.SetPosition`/`ParentCellId`/`Rotation` + `RebucketLiveEntity`. If
`remotePlacementRequired`: `RemoteTeleportController.BeginPlacement` (`:269`)
-> `TryApply` (`:117/151`) -> `Resolve` (`:278`) -> `_physics.ResolvePlacement`
(`:303`) -> `CommitResolved` (`:320`) -> `RemoteTeleportPlacement.Apply`
(`RemoteTeleportPlacement.cs:15`) -> `PhysicsObjUpdate.CommitSetPositionTransition`.
Else (ordinary MoveOrTeleport): **inline classification hand-duplicated in
App**, `LiveEntityNetworkUpdateController.cs:1594-1900` (local constants
`MaxPhysicsDistance=96f`/`BodySnapThreshold=4f` duplicated for player vs NPC)
decides far-snap/near-interpolate/airborne-noop/landing, then
`entity.SetPosition`/`ParentCellId`/`Rotation` + `LiveEntityShadowPublisher.TryPublishRemote`.
Ongoing per-tick DR: `RemotePhysicsUpdater.cs:220` ->
`RuntimeRemotePhysicsUpdater.Tick` (`:61`) — interp catch-up + `ResolveWithTransition`
sweep + shadow sync, independent of SetPosition (retail's continuous
`UpdatePositionInternal` — NOT itself a wire route, out of cutover scope).

### Duplicate authorities

- `LiveEntityNetworkUpdateController.cs:1252-1270` — position/cell/rotation
  AND full rebucket, unconditionally, ahead of any classification.
- `RemoteTeleportController.cs:37,77-109` — `_pending` dictionary, rollback
  capture/restore (`:94-109,477-569`), lost-cell tracking
  (`:529-532`) — exactly the bookkeeping the residence+executor's
  25-second lost-cell lifetime already owns generically.
- `RemoteTeleportPlacement.cs:43-77` — direct `body.SnapToCell`,
  contact-plane fields, `PhysicsObjUpdate.CommitSetPositionTransition` — a
  hand-rolled SetPosition commit parallel to `RuntimeSetPositionState`.
- `LiveEntityNetworkUpdateController.cs:1594-1900` — the "ordinary"
  MoveOrTeleport classification hand-duplicated in App, when
  `RuntimeAuthoritativePositionRouteClassifier.ClassifyAcceptedPosition`
  ALREADY implements identical near(<96m,Interpolate)/far(SetPositionSimple)/
  teleport-advanced(SetPosition)/cellless rules (classifier lines 360-439).
- `RemoteTeleportController.cs:382-475` — `ParkPending`/`OnProjectionVisibilityChanged`
  re-implements deferred-until-visible placement replay, another thing the
  executor's FIFO/replay machinery already generalizes.

### What becomes what

- DELETE outright: `RemoteTeleportController.cs`, `RemoteTeleportPlacement.cs`,
  their pending dictionary/rollback/`ParkPending`, and the pre-placement
  `entity.SetPosition`/`RebucketLiveEntity` at `:1252-1270`.
- DELETE + replace with classifier delegation: the inline near/far/airborne/
  landing block (`:1594-1900`) -> route through
  `ClassifyAcceptedPosition` + `RuntimeSetPositionState` Begin/Watch/resume.
- Reduce to acknowledge-only: `RemoteTeleportHook.cs` stays as the App-side
  execution seam, but its trigger condition should come from the classified
  route's `RuntimeTeleportHookPhase`, not the App's own `remoteHardTeleport`
  flag.
- `RuntimeRemotePhysicsUpdater` per-tick DR is OUT of cutover scope (retail's
  continuous simulation, not a wire route).

### Gap

The classifier's `Remote` branch is FULLY implemented for both `ClassifyCreate`
and `ClassifyAcceptedPosition` — the only gap is wiring (no production caller
ever constructs a `RuntimeAcceptedPositionRouteRequest` for a Remote entity
outside the narrow pending-residence window). The 1,880 B/op budget applies
directly here too (remote Position is genuinely per-network-tick frequency).

---

## Route 5 — Projectile authoritative create/corrections (from parallel research agent)

### Call chain

**Create**: `DatLiveEntityProjectionMaterializer.cs:807` `_projectiles.TryBind` ->
`ProjectileController.TryBind` (`ProjectileController.cs:133`) — constructs/
adopts the shared `PhysicsBody` (`:176-265`), calls `body.SnapToCell` directly
(`:214/256`), then `entity.SetPosition`/`ParentCellId` + `RebucketLiveEntity`
(`:268-271`) and `ShadowPositionSynchronizer.Sync` (`:306`) — all ad hoc, no
classifier. **Vector** (launch velocity): `LiveEntityNetworkUpdateController.cs:840`
`OnVector` -> `ProjectileController.ApplyAuthoritativeVector` (`:345`) ->
`RuntimeProjectilePhysicsUpdater.ApplyAuthoritativeVector` (`:207`). **State**
(Missile bit): `:992` `OnState` -> `ApplyAuthoritativeState` (`:410`) ->
`RuntimeProjectilePhysicsUpdater.ApplyAuthoritativeState` (`:252`, direct
`SnapToCell` at `:288`). **Authoritative Position correction**:
`LiveEntityNetworkUpdateController.cs:1217-1233` (inside `OnPosition`, AHEAD of
the generic remote path — returns early if handled) ->
`ProjectileController.ApplyAuthoritativePosition` (`:508`) ->
`RuntimeProjectilePhysicsUpdater.ApplyAuthoritativePosition` (`:301`, direct
`body.SnapToCell` at `:346`, `CommitProjectileCell` at `:370`, direct
`ShadowPositionSynchronizer.Sync`/`Suspend` `:402-421`). **Ordinary per-quantum
integration**: `ProjectileController.Tick` (`:613`) -> `AdvanceQuantum`/
`TryBeginQuantum`/`CompleteQuantum` (`:761-836`) ->
`RuntimeProjectilePhysicsUpdater.TryBegin`/`Complete` (`:37,94`) — `Complete`
does direct `body.SnapToCell` at line 145 + direct shadow sync — correctly
NOT routed through SetPosition today, but ALSO not through any shared
cell-commit authority; its own ad hoc `CommitProjectileCell` + shadow write.

### Duplicate authorities

- `ProjectileController.cs:214-271` — body construction, `SnapToCell`,
  `entity.SetPosition`/`ParentCellId`, `RebucketLiveEntity`, shadow sync — full
  ad hoc placement authority for missile creation.
- `RuntimeProjectilePhysicsUpdater.cs:145-198` (per-quantum `Complete`) and
  `:346-421` (`ApplyAuthoritativePosition`) — BOTH do direct `SnapToCell` +
  `CommitProjectileCell` + shadow sync, bypassing `RuntimeSetPositionState`
  entirely; **neither distinguishes "ordinary integration" from "authoritative
  correction" at the cell/shadow-commit layer** — only the caller's semantic
  label differs.

### What becomes what

- DELETE outright: the authoritative-placement code in `TryBind`'s create
  branch (`:214-271`) and `ApplyAuthoritativePosition` (`:508-578`); and the
  direct `SnapToCell`/shadow commit inside
  `RuntimeProjectilePhysicsUpdater.ApplyAuthoritativePosition` (`:301-424`).
- REPLACE with `ProjectileAuthoritative`-tagged routes via the classifier
  driving `RuntimeSetPositionState`, using "the same Runtime body and exact
  projectile Setup sphere" — i.e. `RuntimeProjectile.Body`/`CollisionSphere`
  (`RuntimeProjectile.cs:10-40`) plugged into the shared SetPosition
  transaction instead of `CommitProjectileCell`.
- KEEP UNCHANGED (must NOT route through SetPosition): per-quantum
  integration (`TryBegin`/`Complete`, `:37-205`) — correctly outside
  SetPosition today; only its cell/shadow-commit CALL is a candidate to unify
  onto a shared (non-SetPosition) cell-commit primitive.
- Reduce to acknowledge-only: `ApplyAuthoritativeVector`/`ApplyAuthoritativeState`
  (`:332-478`) — smaller scope of change since they don't do placement/rebucket
  themselves today.

### Gap

`ProjectileAuthoritative` exists TODAY ONLY as an `OperationKind` label
(`RuntimeSetPositionState.cs:16`), produced generically by the classifier's
`OperationKind(...)` helper for both entry points — **it is not a distinct
routing rule**: `ClassifyCreate` gives Projectile the exact same
`SetPosition`/`InitialCreateFlags` route as any non-local entity, and
`ClassifyAcceptedPosition` gives Projectile the IDENTICAL near/far/teleport/
cellless branches as Remote (proven by the test name
`ProjectilePosition_UsesRemoteMoveOrTeleportClassification`,
`RuntimeAuthoritativePositionRouteClassifierTests.cs:418-436`). So: PARTIAL —
operation-kind plumbing + generic MoveOrTeleport-shape routing exist; missing
is (a) any production wiring at all (same dormancy as route 4), and (b)
projectile-specific POLICY (should a "near" wire correction ever return
`Interpolate` for a ballistic body, or always hard-correct?) — today's
"never route per-quantum integration through SetPosition" constraint holds
only because per-quantum integration never calls the classifier at all (a
separate simulation-tick path), not because of an explicit guard.

---

## Route 6 — Drops and unparent-to-world (from parallel research agent)

Graphical-only; no headless drop UI exists.

### Call chain

**Whole-item/normal drop**: `ItemInteractionController.ExecutePlacementActions`,
`DropToWorld` case (`src/AcDream.App/UI/ItemInteractionController.cs:976-993`) —
optimistic move + send drop; ordinary server CreateObject flows through the
normal wire pump: `LiveEntityHydrationController.OnCreate`/`OnCreateCore`
(`:226-299`) -> `_runtime.RegisterLiveEntity(spawn)` -> `LiveEntityRuntime.cs:526-556`
-> `_entityObjects.RegisterEntity(...)` (line 537) -> `RuntimeEntityObjectLifetime.RegisterEntity`
(315-322, legacy, `beginInitialResidence:false`). **Split-to-world** (ACE omits
CreateObject, sends only the new GUID's Position first):
`ItemInteractionController.cs:994-1015` (`SplitToWorld` case, raises
`WorldDropDispatched`) -> `InventoryWorldDropProjectionController.OnWorldDropDispatched`
(`:81-98`, records `PendingSplitToWorldProjection`) -> wire Position (F748) for
the new GUID arrives at `LiveEntityNetworkUpdateController.OnPosition:1024-1029`,
FIRST calls `_worldDropProjection.TryRecoverUnknownPosition(update)` (1026) ->
`InventoryWorldDropProjectionController.cs:54-68`: builds a synthetic
`EntitySpawn` via `PendingSplitToWorldProjection.BuildSpawn` (171-209, clones
the SOURCE item's full spawn/PhysicsSpawnData, overriding
Guid/Position/StackSize/Container/Wielder/*Sequence/Parent*) -> calls
`_hydration.OnCreate(spawn)` (66) — **the IDENTICAL entry point as the
ordinary path**, converging on the same `RegisterEntity` call.
`ShortcutDropPlanner` is unrelated to this route (toolbar-slot reshuffling
only, never touches position/physics).

### Duplicate authority / gap

Neither drop flavor calls `Physics.SetPosition.Begin*` or
`RuntimeInitialCreateResidenceState.Begin` today — **there is no App-vs-Runtime
competing mutation for drops specifically**; the gap is identical to routes
1-5: `RegisterEntityWithInitialResidence` is never called from any production
path (confirmed by full-repo grep — only self-referential inside
`RuntimeEntityObjectLifetime`'s own constructors, as the executor's
child-replay delegate, plus tests). Both drop flavors equally bypass the
canonical create-placement transaction — this is a wiring gap shared with
routes 1-5, not a route-6-specific duplicate.
- **Real, previously-unstated Route-6-specific gap**: `PendingSplitToWorldProjection.BuildSpawn`
  clones the source's DTO wholesale (correct for Position, which IS
  explicitly overridden) but presentation-effect replay (create-pop VFX/sound
  driven off `LiveEntityReadyPublisher.Publish`/`EntityEffectController.ReplayPendingForLiveEntity`)
  has NO SIGNAL today distinguishing "real spawn" from "split continuation" —
  and the executor's receipt/trace has no field for "this create is a
  split-recovery continuation, suppress create-time effect replay." This must
  be ADDED, not just wired — a genuine new capability, not merely dormant.

### What becomes what

`LiveEntityHydrationController.OnCreate`/`OnCreateCore` switches to
`RegisterEntityWithInitialResidence` for EVERY CreateObject (both flavors) so
both acquire a lease and drain through `Execute`.
`TryRecoverUnknownPosition`'s call shape doesn't need to change, but the
residence/executor layer needs the new "suppress effect replay for split
continuation" capability above. `WorldDropDispatch`/`ShortcutDropPlanner`/
`ItemInteractionController` dispatch (pure UI/wire trigger) is unaffected.

---

## Route 7 — Pickup, Parent, and Delete (from parallel research agent)

### Confirms/refutes "Runtime hooks already exist"

**Largely CONFIRMED at the App/headless-caller level**: none of
`LiveEntityHydrationController`, `EquippedChildRenderController`,
`LiveEntityDeletionController`, `LiveEntityRuntimeTeardownController` do their
own `SetFullCell`/`SuspendObjectClock`/rebucket math — all of it lives inside
`RuntimeEntityObjectLifetime` (`TryApplyPickup:805-868`,
`TryApplyParent/TryApplyCreateParent` -> shared helper
`CommitPositionChannelUpdate:1705-1737`, `TryCommitParent:944-974`,
`CommitAcceptedParentCellless:976-1007`, `CommitWithdrawal:1401-1422`,
`TryAcceptDelete:1466-1527`). App/headless work is exclusively presentation
(render subtree, shadows/effects/animation/selection teardown) — legitimate,
not duplicated physics authority.

**BUT the claim needs an important qualification (previously-unstated
finding)**: every `ForgetInitialCreateResidence(...)` call in this family
(849, 1720-1721, 990, 1411, 1501) cancels a residence lease that is **NEVER
ACQUIRED** anywhere in production (same Route-1/6 finding —
`RegisterEntityWithInitialResidence` unreached), and every paired
`Physics.SetPosition.Forget(...)` cancels a placement transaction that is
likewise **NEVER BEGUN** anywhere in production
(`BeginAcceptedPlacement`/`BeginAuthoredPlacement`,
`RuntimeSetPositionState.cs:803,815`, zero external callers repo-wide). **So
today these cancellation calls are structurally present but functionally
no-ops against always-empty state** — `InitialCreateResidences.Forget`
returns false; `PreferCancellation` always falls through to the equally-empty
"ordinary" receipt. Route 7 is correctly "already cut over" for the parts
that currently do anything (SetFullCell/SuspendObjectClock/RefreshSnapshot/
AdvanceXAuthority/CollisionReports/EndChildProjection are genuinely
Runtime-owned) — but the specific behavior the campaign doc worries about
("cancel the exact active placement/lost-cell family first") is INERT
because there is nothing upstream yet to cancel. Once routes 1-5 wire the
create/position path live, these existing calls become live with NO code
change required — genuinely pre-built and correctly sequenced already.

### Two internal asymmetries flagged for cutover review (new findings)

- `TryCommitParent` (944-974) is the ONLY method in the family with NO
  `ForgetInitialCreateResidence`/`PreferCancellation` call at all.
- `CommitWithdrawal` (1401-1422) calls `ForgetInitialCreateResidence` but NOT
  `Physics.SetPosition.Forget`/`PreferCancellation`, unlike Pickup/
  `CommitAcceptedParentCellless`/`TryAcceptDelete` which cancel both families.
  Once ordinary placement transactions go live,
  `WithdrawLiveEntityProjectionToCellless` (`LiveEntityRuntime.cs:1315-1331`,
  calls `CommitWithdrawal`) could leave an active mover/lost-cell watch
  dangling. **Flag for explicit cutover test, do not assume symmetric with
  the other four methods.**

### Headless-specific gap (real, pre-existing, adjacent to but distinct from the cutover)

`RuntimeLiveEntitySessionController.OnParentUpdated` (216-220) calls ONLY
`Entities.TryApplyParent` directly — **headless NEVER calls
`TryCommitParent`/`CommitAcceptedParentCellless`** — there is no headless
equivalent of the App parent-realize sequence
(`EquippedChildRenderController.ResolveAndTryRealize`/`PrepareAndTryRealize`,
`LiveEntityHydrationController.cs:470` chain) AT ALL. This looks like a live
gap independent of the residence/executor cutover — a headless parented
child's `FullCellId` may never clear. Needs new code, not just wiring.
`HeadlessSessionWorldProjection`/`IRuntimeDirectWorldProjection` has no
pickup/parent/delete hook at all (only `ProjectSpawn`/`ProjectPosition`/
`BeginTeleport`/`PrepareDestination`) — headless has ZERO duplicate
placement work for route 7 (consistent with "already cut over" for the parts
that do anything).

### Gap vs. the executor

"What the executor owns" already anticipates Route 7's "pickup during
preparation/deferred residence" and "parent during pending withdrawal" test
scenarios via the `TryGetPendingInitialResidence`/`EnqueueDormant` branches
already present in `TryApplyPickup`/`TryApplyParent` — no NEW executor
capability is needed for route 7's steady-state (post-create) behavior; the
gap is entirely "wire up creates to use residence" (routes 1-3's job). One
real gap: the executor's receipt/trace has no concept of "a pickup/delete
cancelled my pending residence" — `RuntimePlacementCancellationReceipt`
contents route only to `Physics.SetPosition.PublishCancellation`, never
surfaced to the calling host for observability/testing.

---

## Route 8 — Headless parity (researched directly, not delegated)

Files read in full: `src/AcDream.Headless/Hosting/HeadlessSessionWorldProjection.cs`
(693 lines), `src/AcDream.Runtime/Session/RuntimeLiveEntitySessionController.cs`
(349 lines).

### Current production call chain — headless host

Entry: `RuntimeLiveEntitySessionController.CreateSink()` (56-68) wires a
`LiveEntitySessionSink` whose delegates are the ONLY headless wire-dispatch
entry points for entity/position/motion/vector/state/parent/teleport traffic.
Each handler below calls straight into `RuntimeEntityObjectLifetime` (the
LEGACY, non-residence overloads — every call passes `acknowledgeProjection: null`)
and then, only for specific cases, into `IRuntimeDirectWorldProjection`
(implemented by `HeadlessSessionWorldProjection`):

1. `OnSpawned` (73-95) — `Entities.RegisterEntity(spawn)` (75-76, **the
   legacy Create entry point — confirmed by the surface map's grep as one of
   only two production Create call sites in the repo**) → if `registration.Canonical`
   present, `Entities.ApplyAcceptedSpawn(canonical, integrationVersion,
   canonical.Snapshot, replaceGeneration: ...)` (81-87) → if applied,
   `_worldProjection?.ProjectSpawn(canonical, isLocalPlayer)` (90-93) →
   `HeadlessSessionWorldProjection.ProjectSpawn` (507-513): **no-op for any
   non-local entity** (`if (isLocalPlayer) SynchronizeLocalPlayer(record);` —
   line 511-512 IS the entire method body); for the local player, calls
   `SynchronizeLocalPlayer` (566-615) which is the duplicate placement
   authority (see below).
2. `OnPositionUpdated` (137-201) — `Entities.TryApplyPosition(update, isLocal,
   forcePositionRotation: localController?.BodyOrientation,
   currentLocalVelocity: localController?.BodyVelocity,
   projectionRequiresTeleportHook: false, acknowledgeProjection: null, ...)`
   (144-153, legacy path) → if `!isLocal` or `Rejected`, return (154-159) →
   if `disposition is Apply`, builds a `RuntimeTeleportDestination` from the
   wire position and calls `_runtime.TransitOwner.OfferTeleportDestination(destination,
   timestamps.TeleportAdvanced)` (161-184, **every accepted local Position is
   offered to the transit owner as a POTENTIAL portal destination — the
   transit owner itself decides whether it's actually a portal**) → looks up
   the active record and calls `_worldProjection?.ProjectPosition(record,
   isLocalPlayer: true, disposition)` (185-193) → `HeadlessSessionWorldProjection.ProjectPosition`
   (515-531): no-op for non-local; if no controller yet, `SynchronizeLocalPlayer`
   (525); **else only for `disposition is ForcePosition` does it call
   `BlipLocalPlayer`** (529-530) — an ordinary `Apply` disposition with an
   existing controller does NOTHING here (ordinary interpolation must happen
   elsewhere, at the physics tick) → back in the session controller, if
   `disposition is ForcePosition`, `_localPlayerOutbound.SendImmediatePosition(_session,
   _runtime.MovementOwner.Controller)` (194-199, **sends the outbound wire ack
   BEFORE any Runtime placement commit/host-acknowledgement — the headless
   twin of route 2's "direct BlipPosition/pre-commit acknowledgement"**) →
   `TryCompletePortal()` (200, 243-332) unconditionally at the end.
3. `OnPickedUp`/`OnMotionUpdated`/`OnVectorUpdated`/`OnStateUpdated`/`OnParentUpdated`/`OnAppearanceUpdated`
   (118-122, 124-135, 203-207, 209-214, 216-220, 237-241) — thin 1-line
   pass-throughs to `Entities.TryApply*(..., acknowledgeProjection: null, out _)`,
   no independent headless placement work.
4. `OnDeleted` (97-116) — `Entities.TryAcceptDelete(...)` →
   `Entities.CompleteAcceptedDelete(acceptance)` → `Entities.RetireCanonicalOnly(retired)`.
   No independent headless placement work (matches route 7's claim that
   pickup/parent/delete are already mostly Runtime-owned — see route 7's
   section for the App-side confirmation).
5. `OnTeleportStarted` (222-235) → `transit.TryQueueTeleportStart` →
   `_worldProjection?.BeginTeleport()` → `HeadlessSessionWorldProjection.BeginTeleport`
   (533-537): sets `controller.State = PlayerState.PortalSpace` directly (no
   Runtime commit gate) → `transit.ActivateQueuedTeleport()` → `TryCompletePortal()`.
6. `TryCompletePortal` (243-332) — a **fully Runtime-driven, already-cutover
   state machine** for the portal handshake itself: `TryGetAcceptedTeleportDestination`
   → `TryBeginPortalReveal` → `TryRegisterHostProjection` → `Acknowledge(...ProjectionRegistered)`
   → `_worldProjection?.PrepareDestination(generation, destination)` (271-274,
   **the ONE point where the headless host does its own destination-prep
   work** — see below) → `transit.AcknowledgeDestinationReadiness(readiness)`
   → `transit.AcknowledgePortalMaterialized(...)` →
   `Acknowledge(...SimulationReleaseProjected)` →
   `transit.RequireDestinationReservationRelease(projection)` →
   `Acknowledge(...DestinationReservationReleased)` →
   `transit.AcknowledgeWorldViewportVisible` + `transit.Complete(generation)` →
   `Acknowledge(...TerminalProjected)` → `_session.SendGameAction(GameActionLoginComplete.Build())`
   → `transit.EndTeleport()`. **This entire sequence is already Runtime-owned
   generation/token bookkeeping (J6.2-J6.4 landed) — it is NOT a route-8
   duplicate authority; it's the shared portal-lifecycle plumbing routes 3
   and 8 both sit on top of.**

### Duplicate authorities — headless (what the residence+executor owner must take over)

- **`HeadlessSessionWorldProjection.SynchronizeLocalPlayer`** (566-615, read
  in full): `_collision.CenterOn(position.LandblockId)` (575) →
  `CreateController(record)` if none exists (577-578, 639-655 — constructs
  `PlayerMovementController` directly, see prerequisite-C section above) →
  `_runtime.EntityObjects.Physics.Engine.Resolve(wirePosition, position.LandblockId,
  Vector3.Zero, 100f)` (589-594) → `.ResolvePlacement(resolved.Position,
  resolved.CellId, DefaultRadius, DefaultHeight, controller.StepUpHeight,
  controller.StepDownHeight, ObjectInfoState.IsPlayer | EdgeSlide,
  record.LocalEntityId ?? 0u)` (595-605) → `controller.SetPosition(resolved.Position,
  resolved.CellId, wirePosition)` + `controller.SetBodyOrientation(orientation)`
  (610-614). **This is a COMPLETE independent physics resolve + placement
  commit, entirely bypassing `RuntimeSetPositionState`.** It is the headless
  mirror of route-1's "Headless performs its own initial resolve/placement/body
  construction" callout in the campaign handoff.
- **`HeadlessSessionWorldProjection.BlipLocalPlayer`** (617-637): direct
  `controller.BlipPosition(wirePosition, position.LandblockId, wirePosition)`
  (633-636) with zero Runtime commit/ack gating — this is exactly the
  "direct Blip" duplicate the campaign handoff names for route 8 ("Delete the
  independent resolve/placement/direct SetPosition and Blip logic in
  `HeadlessSessionWorldProjection`").
  session controller's `_localPlayerOutbound.SendImmediatePosition(...)` at
  `RuntimeLiveEntitySessionController.cs:196-198` fires on the SAME
  `ForcePosition` branch, before any placement receipt exists — pre-commit ack.
- **`HeadlessSessionWorldProjection.PrepareDestination`** (539-564): calls
  `_collision.CenterOn(destination.CellId)` (543) then, if the destination
  entity is active, `SynchronizeLocalPlayer(record)` again (544-549) — i.e.
  portal arrival re-runs the SAME duplicate resolve/placement authority.
  Also directly sets `controller.State = PlayerState.InWorld` (550-551)
  outside any Runtime placement gate.
- **`HeadlessCollisionNeighborhood`** (168-469): NOT a placement-authority
  duplicate per se (it manages per-landblock collision generation
  publication/retirement, a different concern from entity placement) but it
  IS the thing `RuntimeSetPositionState`/`RuntimeInitialCreateResidenceState`
  must be able to wait on (its `IsReady`/`CenterOn` gate the destination
  readiness the residence lease's placement depends on) — this file already
  looks like a reasonable candidate for the "exact authored mover preparation"
  (prerequisite B) collision-readiness signal, not something to delete.

### What each headless hop must become post-cutover

- `OnSpawned` → keep the legacy timestamp-gate call semantics but swap
  `Entities.RegisterEntity(spawn)` for `Entities.RegisterEntityWithInitialResidence(spawn, ...)`
  (the wrapper already exists per the surface map, just unused) so headless
  enters the SAME residence lease as graphical; `ProjectSpawn` becomes
  acknowledge-only: subscribe an `IRuntimePlacementObserver` (does not exist
  yet — see observer-seam section) and, on a `Place` receipt for this
  entity's token, set `controller.SetPosition`/`SetBodyOrientation` from the
  IMMUTABLE `RuntimePlacementProjectionSnapshot` fields only. DELETE
  `SynchronizeLocalPlayer`'s direct `Physics.Engine.Resolve`/`ResolvePlacement`
  calls (589-605) outright — the sweep must happen exactly once, inside
  `RuntimeSetPositionState`, driven by the residence lease.
- `OnPositionUpdated`'s ForcePosition branch → DELETE the direct
  `BlipLocalPlayer`/`controller.BlipPosition` call (633-636) and the
  immediate `SendImmediatePosition` pre-commit ack (196-198 in the session
  controller); replace with: accept timestamp only (still call
  `TryApplyPosition`/`TryAcceptDeferredPosition` for the timestamp-gate
  side-effects already established) → begin the Runtime placement (route 2's
  "LocalAuthoritative" route kind) → wait for the `Place` receipt via the new
  headless `IRuntimePlacementObserver` → apply position from the receipt →
  THEN send the single outbound ack.
- `PrepareDestination` → keep the collision-neighborhood prep (`_collision.CenterOn`/`IsReady`)
  as the readiness signal Runtime's portal-placement authority polls, but
  DELETE the second `SynchronizeLocalPlayer` call (548) — arrival placement
  must come from the SAME Runtime portal-placement commit route 3 defines,
  not a second independent resolve.
- `CreateController` → becomes the headless half of prerequisite C's atomic
  controller/body publication transaction; must stop being callable
  ad hoc from three different places (`SynchronizeLocalPlayer` twice via
  `OnSpawned`+`PrepareDestination`, indirectly via `OnPositionUpdated`) and
  instead run exactly once, gated by the same atomic commit graphical
  route 1 uses.

### Route-8-specific capability gap

The residence+executor mechanism (per
`docs/research/2026-08-02-runtime-continuation-executor-handoff.md`,
"What the executor owns") is host-agnostic by design — nothing in its
API is graphical-only. The concrete gap for route 8 is therefore NOT in the
executor; it is that **no headless `IRuntimePlacementObserver` implementation
exists to consume `GameRuntime.Placements` receipts at all** (see
observer-seam section above — zero hits in `src/AcDream.Headless/`), so
today headless has no mechanism to learn "the Runtime commit landed, project
it" even in principle. Headless also has no analog to a "camera" but DOES
have the same controller/body atomicity requirement as graphical
(prerequisite C applies equally to both hosts — confirmed by the very
existence of `HeadlessSessionWorldProjection.CreateController` as a second,
independent constructor of `PlayerMovementController` next to
`PlayerModeController.BuildControllerAndCamera`).

---

(routes 1-7 sections below filled in as each parallel research agent reports)