acdream/docs/research/2026-08-04-c4-route-3-scoping.md

C4 route 3 — portal / local-player placement: SCOPING (2026-08-04)

This is scoping, not a pinned contract. Verified at HEAD cff52c44, branch claude/acdream-physics-divergence-5aa784, clean tree. Line numbers are as-of-HEAD and will go stale; every citation also names the symbol — trust the symbol (process rule 6).

Route 3 is NOT a bug fix. Portalling works today — /ls, spell recalls, portal use, and admin teleports all place correctly and are user-accepted behaviour. Route 3 removes a duplicate placement authority: the local player's portal arrival is committed by two host-owned hand copies (LocalPlayerTeleportPlacement.Place in App, ResynchronizeLocalPlayerForPortalArrival in Headless) instead of the one canonical Runtime SetPosition transaction every other C4 route now uses. Nobody should read this document as "portals are broken".

Route 3 is the LAST C4 route. Routes 1 (C3a-c), 2 (9966b531), 4a, 4b-1/2/3, 5 (36255af0), and 6 (zero production lines, 1b484937) are landed; route 7 is scoped with its research blocker resolved (2026-08-04-retail-child-cell-ownership.md).

Inputs verified for this scoping: the campaign plan (docs/plans/2026-08-02-placement-cutover.md), the 2026-08-02 route inventory (dated — §3 below lists what is now false), the route-5 contract + its round-3 reviews (the current contract standard), the 4b-3 contract's 13 invariants, claude-memory/project_portal_space.md, the J6.2/J6.3 closeouts, the six process rules in 2026-08-04-session-handoff-c4-remaining.md, and direct reads of every file cited below plus the retail pseudo-C.

---

1. Headline findings

1. The campaign plan overstates what is missing. Plan line ~92-93 says "RuntimePortalPlacementAuthority has zero producing call sites; the adapter from RuntimeWorldTransitState does not exist." The first half is still true — zero production producers, confirmed by exhaustive read of every Begin*/TryPrepareAndSubmit* call site (§4). The second half is now HALF-false: the consumption/validation side of the adapter exists and is LIVE production code, exercised (with an empty portal) by every placement in the game:

   • RuntimeWorldTransitState.IsCurrentPlacementAuthority (RuntimeWorldTransitState.cs:258-275) — generation + sequence + cell + host-token + not-superseding check;
   • RuntimePlacementPresentationSink.TryApply (src/AcDream.App/World/RuntimePlacementPresentationSink.cs:100-106) — every graphical Place receipt is already gated on it;
   • HeadlessRuntimePlacementProjectionSink.TryApply (src/AcDream.Headless/Hosting/HeadlessRuntimePlacementProjectionSink.cs:100-121) — the headless twin;
   • LiveEntityRuntime.IsValidPortalPlacementAuthority (src/AcDream.App/World/LiveEntityRuntime.cs:1448-1457) — token-shape validation inside every projection-record lookup;
   • RuntimeSetPositionState.BeginAcceptedPlacementCore:1528-1534 — Begin refuses a non-empty portal unless kind is LocalAuthoritative AND the authority's destination cell equals the record's accepted-position landblock;
   • the portal authority is threaded through the whole pipeline already: RuntimeSetPositionCommand.Portal (:128), RuntimeSetPositionMoverPreparation.Portal (RuntimeSetPositionMoverPreparation.cs:121, consistency-checked in TryBuild:146), Operation.Portal (:433), and RuntimePlacementProjectionToken.Portal (:250, a REQUIRED positional on every projection token).

   What is actually missing is only the producer: nothing constructs a RuntimePortalPlacementAuthority with Present: true (grep: zero in src/; three test constructors), and no portal arrival drives a Runtime placement at all. That makes route 3 materially smaller than the plan's phrasing implies.

2. Retail's local portal arrival is the GENERIC path — the pattern from routes 2 and 5 holds a third time (§5). SmartBox::TeleportPlayer @0x00453910 is two calls: CPhysicsObj::SetPositionSimple(player, dest, 1) — the EXACT primitive route 2 already routed through Runtime's CommitCanonical for ForcePosition, flags 0x1012 — and SmartBox::PlayerPositionUpdated(this, 1, FLT_MAX). There is no dedicated local portal placement path to port; the work is wiring, ordering, and the post-placement suffix.

3. The classifier's LocalPlayer+TeleportAdvanced route is fully modeled and steady-state dead (RuntimeAuthoritativePositionRouteClassifier.cs:349-368): SetPositionSimple + AuthoritativeTeleportFlags + hook AfterPositionOperation + constrain AfterPositionOperation + ZeroVelocity: true + SendPositionImmediately: false — matching the retail listing exactly (§5). Its only production caller today is the initial-create continuation executor inside the residence window; route 3 would be its first steady-state producer.

4. #280 is mechanically distinct from route 3 and must SPLIT (§7).

---

2. Site inventory at HEAD (re-verified, not inherited)

2.1 The duplicate authorities to replace (both hosts)

#	site (symbol)	at HEAD	what it does
D1	LocalPlayerTeleportPlacement.Place	src/AcDream.App/Streaming/LocalPlayerTeleportController.cs:214-278 (class :183-290)	The graphical duplicate authority, intact and essentially as the 2026-08-02 inventory described plus the 2026-07-25 rebucket fix: _physics.Resolve(pos, cell, 0, StepUpHeight) :219 → controller.SetPosition :230 (which runs the whole teleport tail in SetPositionCore, see 2.4) → direct entity.SetPosition/ParentCellId/Rotation :242-244 → RebucketLiveEntity (throws on failure) :254 → _host.Host?.NotifyTeleported() :264 → SetBodyOrientation :265 → camera resets :267-268 → _spatial.Reconcile() :269. No Runtime transaction, no receipt, no portal authority.
D2	HeadlessSessionWorldProjection.ResynchronizeLocalPlayerForPortalArrival	src/AcDream.Headless/Hosting/HeadlessSessionWorldProjection.cs:788-836	The headless duplicate authority — the old SynchronizeLocalPlayer body, SURVIVING ONLY FOR THIS ROUTE (its own doc at :779-787 says "TODO-C4 (route 3)"): CenterOn → Physics.Engine.Resolve(wire, lb, 0, 100f) :810 → Engine.ResolvePlacement(0.48f/1.835f, IsPlayer|EdgeSlide) :816 → controller.SetPosition :831 → SetBodyOrientation :835. Called from PrepareDestination:757-762.

2.2 The drive machinery (graphical)

site	at HEAD	note
LocalPlayerTeleportController (drive)	LocalPlayerTeleportController.cs:385-789	OnTeleportStarted:436-459 (F751 → TryQueueTeleportStart); OfferDestination:461-470; Tick:472-570 — readiness = destination + !IsRecenterPending + _worldReveal.Evaluate(cell).IsReady; on TeleportAnimEvent.Place: CanPlacePortalDestination preflight :514 → _placement.Place :521 → ObserveMaterialized :527 (still a rubber-stamp AFTER the mutation — the inventory's structural claim holds); PlayExitSound → RevealWorldViewport; FireLoginComplete → EnterWorld + SendLoginComplete + Complete.
destination offer	src/AcDream.App/Physics/LiveEntityNetworkUpdateController.cs:2950-2957 (was :1906-1913)	Last statement of OnPosition: Apply disposition + local guid → _localPlayerTeleport.OfferDestination(FromAcceptedPosition(update), timestamps.TeleportAdvanced). No placement runs for a local Apply anywhere in OnPosition (route 2's ForcePosition drive at :2014-2071 is disposition-exclusive with it).
WorldRevealCoordinator	src/AcDream.App/Streaming/WorldRevealCoordinator.cs (574 lines)	Holds the current RuntimeWorldHostProjectionToken PRIVATELY in _hostProjections (:40-62, FindCurrentHostProjection:516); TryBeginPortal:117-149 mints generation + registers the host projection. The producer needs read access to this token (or re-derives it via the transit's idempotent TryRegisterHostProjection) — a small exposure decision for the contract.
local generic render-pose write	LiveEntityNetworkUpdateController.cs:2284-2289 + :2314	Live finding, verified against the code (the comment at :2276 is stale): TryApplyGenericRemoteRenderPose(entity, null, …) gate is OwnsSteadyState(route) (:1037-1052) which is FALSE for the local player's null route — so every accepted local Apply, including the portal DESTINATION Position, writes the raw wire pose onto the local player's WorldEntity and rebuckets to the wire landblock while portal space still covers the viewport. Pre-existing, hidden by the portal viewport, later overwritten by Place. AP-131/#275 territory — see trap T8.

2.3 The headless portal flow

RuntimeLiveEntitySessionController.TryCompletePortal (src/AcDream.Runtime/Session/RuntimeLiveEntitySessionController.cs:339-428), called from OnPositionUpdated:296 and OnTeleportStarted:330: TryGetAcceptedTeleportDestination → TryBeginPortalReveal → TryRegisterHostProjection → ack ProjectionRegistered → PrepareDestination(generation, destination) :368 (this is where D2 runs, plus controller.State = PlayerState.InWorld and the readiness report) → AcknowledgeDestinationReadiness → AcknowledgePortalMaterialized → ack SimulationReleaseProjected → RequireDestinationReservationRelease → ack DestinationReservationReleased → AcknowledgeWorldViewportVisible + Complete → ack TerminalProjected → SendGameAction(LoginComplete) → EndTeleport. The J6 lifecycle itself is canonical and healthy; only the placement inside PrepareDestination is the duplicate.

2.4 Runtime surfaces route 3 builds against

site	at HEAD	relevance
RuntimePortalPlacementAuthority	RuntimeSetPositionState.cs:105-119	(bool Present, long RevealGeneration, ushort TeleportSequence, RuntimeWorldHostProjectionToken Projection). The shape is RIGHT for what transit holds — it is exactly the tuple RuntimeWorldTransitState owns per reveal (Snapshot.Generation, ActiveTeleportSequence, the registered host token whose DestinationCell is validated everywhere). No shape change needed.
RuntimeWorldTransitState	RuntimeWorldTransitState.cs (1,012 lines)	Producer inputs all exist: IsTeleportActive:96, ActiveTeleportSequence:97, TryGetAcceptedTeleportDestination:522, CanPlacePortalDestination:534 (read-only preflight), TryRegisterHostProjection:189 (idempotent for the same generation/cell — a legitimate token re-derivation path), AcknowledgePortalMaterialized:595, IsCurrentPlacementAuthority:258.
RuntimeAcceptedPositionDriveController	src/AcDream.Runtime/Session/RuntimeAcceptedPositionDriveController.cs (924 lines)	Route 2's landed local-player accepted-Position seam over TryBeginExclusiveAuthoredPlacement:389 + TryPrepareAndSubmitAuthoredPlacement:677 (resolveWorldOffsetFromRuntimeFrame: true). ForcePosition-only by gate (:340-360); its Pending/ack funnel is ForcePosition-shaped (PositionEventOwed). The natural home for a sibling portal arm — but see trap T7 before inheriting any of its funnel.
PlayerMovementController teleport tail	src/AcDream.Runtime/Gameplay/PlayerMovementController.cs:1845-1920 (SetPositionCore)	Today's controller.SetPosition on the portal path performs, in one method: body snap, render-lerp anchor reset, UpdateCellId publication, Contact|OnWalkable|Active transient set, zero velocity, StopCompletelyAtPhysicsObjectBoundary (retail StopCompletely 0x00527E40), input-edge/mouse state reset, UnStick + UnConstrain + RearmConstraintLeashAtCurrentPosition (retail @0x0045418A analog), and _objectClock.ResetForEnterWorld(). Under a canonical commit the BODY write moves into Runtime's CommitCanonical; every one of these controller-local duties must be re-homed into a teleport analog of CommitCanonicalForcePositionFrame (:1944-1950) — losing any one of them is the 4b-2 round-1 defect class. This is the single largest and riskiest piece of the slice.
classifier LocalPlayer teleport branch	RuntimeAuthoritativePositionRouteClassifier.cs:349-368	See §1.3. Production classify callers: the drive controller :922 (Force only), ClassifyRemoteAcceptedPosition (remote/projectile), the continuation executor :1928 (residence window).
SpawnPlacementSettler	src/AcDream.Core/Physics/SpawnPlacementSettler.cs:22; local-player call site RuntimeLocalPlayerPhysicsPublicationState.cs:812	First-entry only (C3c-F5/AD-61). Not invoked on the portal path today, and retail's portal arrival has no settle sweep either — contact resolves inside SetPosition's own transition (SLIDE flags). Do not add it (trap T10).
world frame	RuntimePhysicsState.ObserveLocalWorldFrame:550-562; callers RuntimeEntityObjectLifetime.cs:1739/:1794	Runtime's world frame rebases on teleportAdvanced at the accepted-Position merge; App's LiveWorldOriginState recenters asynchronously afterwards. See trap T4.

2.5 What is already canonical and must not regress (J6)

Slice J6.2/J6.3/J6.4 ownership stands: RuntimeWorldTransitState owns the reveal generation, destination latch, F751 correlation (both packet orders), materialization/simulation edge, viewport observation, wait cue, completion/ cancellation, and the 4-stage host acknowledgement suffix. Route 3 must not move ANY of that; it only makes the transit owner additionally gate the placement mutation it currently rubber-stamps. The lifecycle gate's transitOwnership zero-at-stable-checkpoint discipline (tools/run-connected-world-lifecycle-gate.ps1) already covers this state.

---

3. The dated inventory: claims now false

The 2026-08-02 route inventory predates C3c, route 2, the four route-4 sub-slices, route 5, and the OnPosition collapse. Eight of its claims bearing on routes 3/8 are now materially false, plus pervasive stale line numbers:

1. "The binding machinery is real but 100% dormant end to end." — FALSE. The validation half is live at three production layers (§1.1) and runs for every placement (empty-portal case). Only the producer is dormant.
2. "Neither host has ever constructed a production IRuntimePlacementObserver implementation" (prerequisite D "100% unbuilt on the host side") — FALSE. RuntimePlacementPresentationSink (graphical) and HeadlessRuntimePlacementProjectionSink (headless, wired at HeadlessSessionHost.cs:701) are production consumers of the placement FIFO.
3. "BeginAcceptedPlacement/BeginAuthoredPlacement … zero external callers repo-wide" / "a placement transaction … never begun anywhere in production" — FALSE. Three production controllers drive TryBeginExclusiveAuthoredPlacement + TryPrepareAndSubmitAuthoredPlacement (local force, remote, first-entry). (The two named legacy wrappers BeginAcceptedPlacement/BeginAuthoredPlacement themselves are now test-only entry points.)
4. "InboundPhysicsStateController.TryApplyPosition is today's only PRODUCTION Position wire caller; the classifier-based path is test-only" — FALSE since routes 2/4a/4b-2/4b-3/5.
5. The entire route-2 chain (LocalForcePositionTransaction, pre-commit ack, generic-tail double write for ForcePosition) — GONE; route 2 landed.
6. Headless route-8: "SynchronizeLocalPlayer (566-615) is the duplicate placement authority … CreateController (639-655) constructs PlayerMovementController" — FALSE at HEAD. C3c deleted the route-1/8 initial-entry hand-copy and the controller construction; the ONLY surviving headless duplicate is the renamed portal-arrival re-resolve (D2).
7. "BlipLocalPlayer (617-637) direct blip" — FALSE; deleted by route 2 (halves split into CenterOnAcceptedForcePosition + the drive controller).
8. "The executor publishes only generic entity deltas; nothing bridges its completion to RuntimePlacementProjectionChannel" — FALSE since C0/C3-1 (ExecutorCompleted receipts; TryGetInitialCreateCompletion).

Still TRUE from the inventory's route-3 section: the call-chain shape (F751 → queue → offer → aim → TryBeginPortal → Place at anim event), the Place-mutates-then-ObserveMaterialized-rubber-stamps sequencing, the "discard/cancellation semantics structurally sufficient but UNEXERCISED for a real placement" warning (now with live validators, still zero portal-carrying operations — the explicit cutover tests it demanded are still owed), and the executor scope note (portal arrival is a steady-state placement, not a Create admission — the FIFO executor is not the target).

Stale-but-substantively-true: the offer site (:1906 → :2950), the validator (:1162 → :1448), PrepareDestination (:539 → :752, re-resolve retained under a new name), RuntimeWorldTransitState still 1,012 lines.

---

4. The missing producer, precisely

What route 3 must build (and ALL it must build on the authority side):

1. The producer: at the placement moment, construct new RuntimePortalPlacementAuthority(Present: true, RevealGeneration, ActiveTeleportSequence, hostProjectionToken) from the live transit state. Graphical: the generation is already at hand (_pendingRevealGeneration, LocalPlayerTeleportController:404/694), the sequence is _transit.ActiveTeleportSequence, and the host token needs a small accessor on WorldRevealCoordinator (or re-derivation via the idempotent TryRegisterHostProjection). Headless: all three are in scope inside TryCompletePortal (generation, destination.TeleportSequence, projection).
2. The placement call: a portal arm on the local-player drive seam that runs TryBeginExclusiveAuthoredPlacement(record, version, LocalAuthoritative, portal) + TryPrepareAndSubmitAuthoredPlacement(…, portal, resolveWorldOffsetFromRuntimeFrame: true) with the classifier's LocalPlayer-teleport route, invoked at each host's existing placement edge (graphical: the TeleportAnimEvent.Place handler after CanPlacePortalDestination; headless: PrepareDestination).
3. The controller-local teleport frame commit (§2.4's SetPositionCore re-homing) invoked on the committed receipt.
4. Re-sequencing: AcknowledgePortalMaterialized fires from the committed placement receipt (it then actually gates — IsCurrentPlacementAuthority requires the materialization state it sets), camera reset + _spatial.Reconcile() become acknowledge-edge reactions, and D1/D2's direct mutations are deleted.

The authority's shape does not need changing (§2.4). One genuine edge to design for: BeginAcceptedPlacementCore:1528-1534 validates the authority's destination cell against record.Snapshot.Physics?.Position ?? record.Snapshot.Position — the LATEST merged Position — while transit pins the FIRST accepted destination per generation (J6.3). A second local Position merging between the offer and the Place edge would make Begin refuse (default token). Today that window is benign (ACE sends one destination per teleport), but the refusal path must be defined and tested rather than discovered: on refusal the transit generation must be cancelled or the placement re-aimed — never a silent wedge in portal space.

---

5. Retail ground truth (verified in acclient_2013_pseudo_c.txt for this scoping; verify again at contract time)

claim	address	status
F751 (SmartBox::HandlePlayerTeleport) writes exactly three flags — position_update_complete = 0, has_been_teleported = 0, waiting_for_teleport = 1 — after a wrap-safe TELEPORT_TS check. No position, no cell, no physics.	@0x00452150, writes @0x00452193-0x004521A7	✓ read
HandleReceivedPosition's local/non-local split is arg2 != this->player @0x0045414D. The LOCAL teleport branch (newer_event(TELEPORT_TS) @0x0045415F): TeleportPlayer @0x00454168 → ConstrainTo(player, &var_48 /* the WIRE destination */, start, max) @0x0045418A → set_velocity(player, 0, 1) @0x004541B4 → return.	@0x00453FD0	✓ read
SmartBox::TeleportPlayer is TWO calls: CPhysicsObj::SetPositionSimple(player, dest, 1) @0x00453924 and PlayerPositionUpdated(this, 1, FLT_MAX) @0x00453932. The generic placement primitive — the same one route 2 ported (BlipPlayer @0x00453940 is the identical shape with arg 0).	@0x00453910	✓ read
SetPositionSimple(…, 1) builds flags 0x1012 = SEND_POSITION_EVENT | SLIDE | TELEPORT (acclient.h:6123) → generic CPhysicsObj::SetPosition @0x005160C0. Identical flags to the remote teleport branch. SLIDE is consumed in CheckPositionInternal @0x00511E90 (accept what find_valid_position resolved).	@0x005162B0 (0x1012 @0x005162C2)	✓ read
PlayerPositionUpdated teleport arm (AFTER the placement): position_update_complete = 0, waiting_for_teleport = 0 (the F751 wait ends at PLACEMENT, not at reveal), has_been_teleported = 0, teleport_hook(player) @0x004538AE, cmdinterp->PlayerTeleported() (= SetAutoRun(0,1) + SendMovementEvent, @0x006B32B0), set_viewer(&player->m_position, 1) (camera reset, reset_sought), LScape::update_viewpoint(0) (destroys the terrain draw list), CellManager::ChangePosition(&m_position, 1 /* blocking */).	@0x00453870	✓ read
The hook ordering FLIPS versus the remote route: local runs teleport_hook @0x00514ED0 AFTER SetPositionSimple returns (from PlayerPositionUpdated); the remote branch runs it BEFORE SetPosition (@0x005163EF). The hook UnConstrains @0x00514F0C, and HandleReceivedPosition re-arms ConstrainTo @0x0045418A after TeleportPlayer returns, so the leash survives. The classifier already encodes this (TeleportHookPhase.AfterPositionOperation local vs BeforePositionOperation remote).		✓ read
CPhysicsObj::enter_world @0x00516170 is NOT on the portal path. Its local-player caller is the initial-login path only (@0x00455095, with store_position + blocking ChangePosition). Portal arrival never re-runs enter_world or CPartArray::HandleEnterWorld/MovementManager::HandleEnterWorld — the cell install happens inside SetPosition itself. 2026-07-16-portal-completion-pseudocode.md §2.1 attributes portal arrival to enter_world — that is the login path and the doc needs a correction note (its conclusion about committing the cell before releasing simulation survives; the cited mechanism is wrong).	callers of 0x00516170	✓ read (agent-verified caller sweep)
The FORCE_POSITION branch (@0x0045400C → BlipPlayer → SendPositionEvent → return @0x0045409D) never reaches any ConstrainTo — route 2's finding reconfirmed. The local TELEPORT branch DOES arm, wire-anchored, and DOES zero velocity — the inversion trap T1.		✓ read
Prefetch (#280's oracle, re-verified): blocking CellManager::ChangePosition @0x004559B0 releases the old landscape and calls CellManager::PreFetchCells @0x00455820 → outdoor LScape::PreFetchCells @0x00505660 walking ±mid_radius landblocks (DAT-record residency, not GPU upload); indoor CEnvCell::PreFetchCells. mid_radius = Render::m_RenderPrefs.LandscapeDrawDistance via SmartBox::SetRegion @0x00453227 / set_mid_radius @0x00453180 — the prefetch window IS the landscape draw distance, centred on the destination. While blocking_for_cells, SmartBox::UseTime @0x00455410 runs ONLY CheckPrefetchStatus; object/physics/landscape/game-time/ambient all hold. Reveal (SmartBox::Show) is a further TunnelFadeOut second after the readiness edge; LoginComplete a WorldFadeIn second after that.		✓ read
Retail places IMMEDIATELY on the accepted destination Position and blocks SIMULATION on prefetch behind the portal viewport. acdream inverts this: it holds the PLACEMENT until reveal-readiness (ready in LocalPlayerTeleportController.Tick) and then places. This is the accepted portal-presentation architecture (J6/E5, user-gated repeatedly) — route 3 keeps the deferred-Place timing and changes only WHO commits it (trap T3).		✓ (architecture fact)

Unverified residuals from the retail pass (mark for the contract, none load-bearing for scope): the exact second argument of teleport_hook at @0x004538AE (decompiler-elided, almost certainly 1); CheckPrefetchStatus's apparent 5.0 s re-check throttle (@0x00455BEE — suspicious, byte-verify if #280 uses it); where SEND_POSITION_EVENT/TELEPORT flag bits are consumed below SetPositionInternal (not traced; irrelevant to route 3's seam choice).

---

6. Shape sketch (scoping altitude — the contract pins the real design)

• Runtime: a portal arm on RuntimeAcceptedPositionDriveController (a sibling entry point, e.g. TryExecuteAcceptedPortalArrival(record, route, authority)), sharing Begin/Submit/status handling with the force arm but NOT its PositionEventOwed/re-issue funnel (trap T7). It consumes the classifier's LocalPlayer-teleport route, applies ZeroVelocity, invokes the controller-local teleport frame commit on the committed receipt, and arms the leash post-operation (the route's ConstrainPhase — today's SetPositionCore re-arm relocates here).
• Graphical: LocalPlayerTeleportPlacement.Place becomes acknowledge-only — build the authority, call the Runtime arm, and on the committed receipt run the presentation suffix (camera resets, NotifyTeleported, _spatial.Reconcile()), then ObserveMaterialized. The direct Resolve/SetPosition/entity-write/rebucket bodies are deleted; the render entity moves via the existing RuntimePlacementPresentationSink Place projection (whose portal gate finally goes live).
• Headless: PrepareDestination keeps CenterOn + readiness reporting + state writes; ResynchronizeLocalPlayerForPortalArrival is deleted and the same Runtime arm is driven from the portal completion flow.
• Probe: ACDREAM_PROBE_LOCAL_TELEPORT=1 (PhysicsDiagnostics-owned, TEMPORARY family) — one line per portal arrival with cause (portal/recall), placement status, portal generation/sequence, destination cell, and hook/leash confirmation.

Register bookkeeping to expect (contract finalizes): AD-42's headless portal-arrival-resync citation dies with D2; locate-or-add the row recording the deferred-place timing adaptation (§5 last row — UNVERIFIED whether an existing AD row states it; if none exists the route-3 commit must add it — a deviation without a row is a bug twice over); the 2026-07-16 pseudocode correction note (§5); the stale :2276 comment (§2.2) corrected or the finding filed.

---

7. #280 — definitive recommendation: SPLIT (do not bundle into route 3)

The campaign plan and the session handoff disagree, and the plan is right. The plan lists #280 as its own numbered work item (item 3 of the remaining campaign work), separate from "finish C4's routes 2-7" (item 2). Only the 2026-08-04 session handoff says "#280 rides with [route 3]". They cannot both be followed; this scoping recommends the plan's sequencing.

Why they are mechanically distinct:

• Route 3 changes WHO commits the placement. Its blast radius is RuntimeSetPositionState/drive-controller/PlayerMovementController/the two host placement bodies. It does not touch readiness evaluation at all — the ready predicate in LocalPlayerTeleportController.Tick:489-493 and everything behind WorldRevealCoordinator.Evaluate is read, not written.
• #280 changes WHAT the reveal waits for. Its fix shape (per its own ISSUES entry, whose retail oracle this scoping re-verified §5): replace WorldRevealReadinessBarrier.OutdoorNeighborhoodRadius = 1 (src/AcDream.App/Streaming/WorldRevealReadinessBarrier.cs:38) with a retail-derived, quality-configured destination prefetch window (mid_radius == landscape draw distance) and hold one generation-scoped reservation across terrain/statics/EnvCells/render publication/composites/collision until the complete visible window is ready. Its blast radius is streaming/reveal/render-resource scheduling — WorldRevealReadinessBarrier, GpuWorldState readiness joins, the streaming reservation schedulers. It does not touch placement.
• The ONLY shared surface is the transit lifecycle both sit inside — and J6 already owns that; neither change moves it.
• Bundling would put a placement-authority cutover (physics-review skillset, connected teleport gate) and a streaming-window change (render/streaming skillset, view-distance visual gate at multiple quality settings) in one diff, and would push the slice far past the ~500-line budget (#280 alone plausibly rivals route 3 in size). 4b-2's process lesson ("split on discovery; a defect outside scope rides for three review rounds") applies prospectively here.

Sequencing: #280 can land before or after route 3 with no dependency in either direction — route 3 keeps the Place gated on the SAME ready predicate, whatever radius that predicate uses. Recommend: route 3 first (closes C4), #280 immediately after as its own slice with its own visual gate, before C5's closeout matrix (the campaign plan already sequences it exactly there).

One honest caveat: bundling advocates would note both changes gate "what happens at the Place edge" and a single connected session could gate both. True but insufficient — a shared test session is not a shared mechanism, and the review lenses are disjoint.

---

8. Size estimate and split recommendation

Calibration: route 4a 364; 4b-1 230+57; 4b-2 350-500; 4b-3 ~250 net new (400-700 budget) with 739 deleted; route 5 ~131 added, ~180 deleted.

piece	est. non-comment production lines
Runtime portal arm on the drive controller (Begin/Submit/status/receipt handling, ZeroVelocity, leash arm)	90-150
PlayerMovementController teleport frame commit (re-home the SetPositionCore suffix; split shared private helpers)	40-80
Graphical producer + Place rewrite + ObserveMaterialized/camera/reconcile re-sequencing	60-110 (deletes ~55)
WorldRevealCoordinator host-token exposure	10-20
Headless: PrepareDestination flip + drive call	15-30 (deletes ~50 incl. D2)
Probe line	~10
Total added	~225-400

Net roughly +150 to +250 (deletions ~105-120). Tests are the larger share, an estimated 500-900 lines (per-outcome placement tests on the portal arm, supersession/cancellation/stale-generation discard tests — the inventory's still-owed "explicit cutover test" for the discard semantics — presentation assertions at #312's layer, dual-host parity, the Begin cell-mismatch edge of §4).

Recommendation: ONE slice, no split — comfortably under the ~500 threshold PROVIDED #280 splits out (§7). Stop-and-report conditions for the implementer: added production lines exceed ~500; the design starts needing changes to RuntimeWorldTransitState's lifecycle semantics, the TeleportAnimSequencer timings, or the readiness barrier (each is a sign #280 or a J6 regression is being smuggled in); or the Begin cell-mismatch edge (§4) turns out to be reachable in ordinary play.

Allocation: a portal placement is once-per-teleport, not frame-frequency — the C2 1,536 B budget is not an activation blocker here (route 2's reasoning applies). Do not spend lines pooling.

---

9. The connected gate (real and mandatory — unlike route 5)

Portals are trivially reachable and user-visible; a live gate exists and is required. A clean-looking session is NOT a pass (process rule 5; 4b-3's gate was a pass only because 16 probe lines proved the arm executed, and its cell-less half is still honestly recorded as unverified).

Recipe (user-run, graphical): Release build, ACDREAM_RETAIL_UI=1, ACDREAM_PROBE_LOCAL_TELEPORT=1, live ACE. Exercise, in one session:

1. a physical portal (e.g. Holtburg portal) — outdoor destination;
2. a dungeon portal (indoor destination, EnvCell readiness path);
3. /ls lifestone recall and one spell recall (the F751 recall family);
4. an ACE admin teleport of the LOCAL player (@teleto/@teleloc) — this advances ObjectTeleport and, per the route-2 visual-gate doc, exercises exactly this route;
5. a same-destination revisit (ACE may omit CreateObject on revisit);
6. graceful close.

Pass requires ALL of:

• one probe line per arrival showing the CANONICAL path executed: placement=Committed, the portal authority's generation/sequence, and the resolved destination cell — zero arrivals through the deleted path (which no longer exists to run) and zero Refused/Contention lines in ordinary play;
• user visual: purple materialization silhouette without an opaque pop or late tail (the 2026-07-25 accepted baseline must not regress), camera reset behind the player at arrival, movement works immediately (walk out with W held — the input-edge reset half of the teleport frame commit), idle stance not a run-in-place, no rubber-band or tether after arrival AND no leash absence (the leash IS armed on this route — a creature-free way to observe it is beyond a visual check, so add a probe field leash=armed instead of inventing a visual);
• the exact lifecycle/reconnect gate (tools/run-connected-world-lifecycle-gate.ps1) passes with every transitOwnership counter zero at every stable checkpoint — this is the supersession/cancellation convergence evidence;
• headless parity: the K-style connected portal route (four-stop portal routing from the K3 closeout) with the probe enabled — same probe-line-per-arrival requirement, proving D2's replacement executed on the no-window host.

Known gap to state up front, 4b-3-style: mid-transit supersession (a second teleport starting before the first materializes) and mid-transit disconnect are hard to provoke against ACE on demand. If the session does not produce them, record the stale-generation discard behaviour as test-verified-only — do not fold it into a blanket "gate passed".

---

10. Traps — rules from earlier routes that flip or do not transfer

• T1 — route 2's leash rule INVERTS. Route 2 pinned "the constraint leash is NOT re-armed" because the FORCE_POSITION branch returns at @0x0045409D before every ConstrainTo. The local TELEPORT branch is the opposite: retail arms ConstrainTo @0x0045418A (anchored at the received destination) AND zeroes velocity @0x004541B4. The classifier already carries both (ConstrainPhase.AfterPositionOperation, ZeroVelocity: true); the drive-controller doc comment (RuntimeAcceptedPositionDriveController.cs:127-132) explaining why the force arm never arms MUST NOT be generalized to the portal arm. Also inverted: SendPositionImmediately is FALSE (no AutonomousPosition ack on this route — retail's teleport branch returns without SendPositionEvent; the outbound tail is LoginComplete, which stays where it is, see T11) and PreserveHeading is FALSE (the wire orientation applies).
• T2 — 4b-3's hook ordering INVERTS. Remote: teleport_hook BEFORE the placement (@0x005163EF). Local: the hook runs AFTER SetPositionSimple, from PlayerPositionUpdated @0x004538AE. The classifier encodes the flip (AfterPositionOperation vs BeforePositionOperation). Copying 4b-3's hook-first arm shape onto the local route would be retail-wrong. Also: the local "hook" is not RemoteTeleportHook — its live actions for the local player are the controller-local UnStick/UnConstrain (+ re-arm afterwards), NotifyTeleported (TargetManager pair), the autorun cancel (PlayerTeleported → SetAutoRun(0,1) — verify against the J5.4 autorun latch at contract time), and report_collision_end.
• T3 — do NOT move the placement to packet-accept time. Retail places immediately and blocks simulation on DAT prefetch; acdream's accepted portal architecture defers the placement to the reveal-ready Place edge behind the portal viewport (user-gated repeatedly; J6/E5). Route 3 changes the executor of the Place, never its timing. An implementer "fixing" the timing toward retail would regress the whole accepted presentation and collide with #280's territory. Locate-or-add the register row for this adaptation (§6).
• T4 — two world frames disagree during the teleport window (#283). Runtime's frame rebases at the accepted teleport Position's merge (ObserveLocalWorldFrame(…, teleportAdvanced: true)); App's LiveWorldOriginState recenters asynchronously. Today Place runs only after !IsRecenterPending (inside ready), so both frames agree at placement time. The canonical arm must keep that gating and must resolve through Runtime's frame (resolveWorldOffsetFromRuntimeFrame: true, as route 2 does) — the App-translated _pendingPosition vector dies with D1. A placement submitted during the disagreement window is the failure mode.
• T5 — the Begin cell-mismatch edge (§4): transit pins the FIRST accepted destination per generation; Begin validates against the LATEST merged snapshot. Define and test the refusal path; never wedge in portal space.
• T6 — hands off J6 and the presentation. RuntimeWorldTransitState's lifecycle semantics, the 4-stage host acknowledgement, the TeleportAnimSequencer seven-state machine, AD-38's viewport-retire timing, the wait cue, and TeleportViewPlaneController are all user-accepted and out of scope. The ONLY transit-adjacent change is that AcknowledgePortalMaterialized fires from the commit receipt instead of rubber-stamping after a host mutation.
• T7 — do not inherit the force arm's funnel. PositionEventOwed, the _newestForce re-issue observation (AD-62), and SendImmediatePosition are ForcePosition-shaped: ACE never repeats a portal destination, the portal route owes no AutonomousPosition ack, and a dead-watch re-issue of a portal placement would fight the transit generation. The portal arm shares Begin/Submit/receipt handling only. (The mirror of 4b's "do NOT port route 2's re-issue funnel" lesson.)
• T8 — the local generic render-pose write is a pre-existing second writer; do not silently delete OR silently keep it. Every accepted local Apply — including the portal destination Position — writes the raw wire pose to the local player's WorldEntity and rebuckets to the wire landblock (:2284-2289/:2314; the :2276 comment claiming otherwise is stale). Hidden by the portal viewport today and overwritten by Place. It is AP-131/#275 (the ordinary local Apply path no route owns) — route 3 must TOLERATE it (the canonical projection overwrites on commit) and the contract must decide explicitly whether the teleport window suppresses it; whichever way, correct the stale comment (process rule 6).
• T9 — no allocation work. Once-per-teleport; the C2 budget is not in play.
• T10 — no settle sweep. SpawnPlacementSettler is first-entry-only (C3c-F5); retail's portal arrival has none — contact resolves inside the SLIDE placement itself. If arrival contact looks wrong in the gate, the bug is in the placement flags/transition, not a missing settle.
• T11 — LoginComplete does not move. It stays on TeleportAnimEvent.FireLoginComplete (retail: ~2 s after reveal; TS-28 is narrowed to initial login only). C3c's 175ad6b0 moved LOGIN's LoginComplete to the first-placement terminal edge — that reasoning does NOT transfer to the portal route.
• T12 — headless keeps its non-placement duties. PrepareDestination's CenterOn, readiness report, and PlayerState writes stay host-owned; only the D2 re-resolve body flips. BeginTeleport's direct PlayerState.PortalSpace write is out of scope.

---

11. What route 3 does NOT do / what remains for C5

• #280 — split out (§7); its own slice with its own visual gate.
• AP-131 / #275 — the shared merge call and the ordinary local Apply path (including T8's generic write) stay for C5.
• AP-1/AD-1 retirement, the legacy-deletion sweep, parity tests, the final connected matrix — C5. Route 3's deletions are only D1/D2's bodies and their direct wiring; any surviving dead seams (ILocalPlayerTeleportPlacement if it reduces to a trivial adapter, legacy BeginAcceptedPlacement/BeginAuthoredPlacement test-only wrappers) are C5 sweep candidates, recorded not deleted here.
• Route 7 (pickup/parent/delete) — separate, already scoped.
• No headless remote consumer, no reveal-gate changes, no presentation/ anim/viewport changes, no enter_world/HandleEnterWorld additions (retail does not run them on this path — §5).
• The six LiveEntityRuntimeTests fixture failures named in the campaign handoff and the final-binary soak remain campaign-level obligations, not route-3 scope.

12. Open gaps (each with the check that closes it)

1. The deferred-place register row — grep the divergence register for the portal place-at-readiness adaptation; if absent, the route-3 commit adds it (T3).
2. The autorun cancel — confirm acdream's arrival path cancels autorun (retail PlayerTeleported → SetAutoRun(0,1)): read the J5.4 RuntimeLocalPlayerMovementState autorun latch against SetPositionCore's input reset.
3. WorldRevealCoordinator token exposure shape — accessor vs re-registration; decide at contract with a test that a superseded token can never be handed to the producer.
4. The Begin cell-mismatch refusal path (§4/T5) — design + test.
5. Retail residuals from §5's unverified list (teleport_hook arg, prefetch throttle) — byte-verify only if the contract leans on them.
6. RuntimePlacementPresentationSink Place projection for the local player — route 2's B2 recorded that no test drives a local-player Place end-to-end through the sink to a moved WorldEntity; route 3 makes that seam load-bearing for portals and MUST close the coverage gap (an App-layer test asserting the render entity moved from the committed receipt), not inherit it.

---

Summary for the campaign plan

• Size: ~225-400 added non-comment production lines, net ~+150-250 — ONE slice, no split (contingent on #280 splitting out).
• #280: SPLIT. The handoff's "rides with route 3" is wrong; the campaign plan's own sequencing (separate item) is right. Reveal-window/streaming concern, not placement.
• Eight dated-inventory claims now false (§3), the most consequential being "100% dormant end to end" — the validation half of the portal machinery is live production code; only the producer is missing.
• Contradictions with the campaign plan: (a) plan line ~92-93's "the adapter … does not exist" overstates the gap — only the producer is missing; (b) the plan's #280 sequencing contradicts the session handoff's bundling — this scoping sides with the plan; (c) the inventory's "route 3's target is RuntimeSetPositionState directly" is refined: the target is a portal arm on route 2's RuntimeAcceptedPositionDriveController seam OVER RuntimeSetPositionState.
• Two documentation defects found while verifying: the 2026-07-16 portal pseudocode attributes portal arrival to enter_world (that is the LOGIN path — needs a correction note), and LiveEntityNetworkUpdateController.cs:2276's "the local player never reaches this generic-remote code path" is false for TryApplyGenericRemoteRenderPose/RebucketLiveEntity (T8).