acdream/docs/research/2026-08-04-c4-route-5-retail-review-round2.md

C4 route 5 — projectile authoritative placement: retail-conformance review, ROUND 2 (delta)

Reviewer lens: retail fidelity only. Delta against 2026-08-04-c4-route-5-retail-review.md (round 1, FAIL) and cross-read against 2026-08-04-c4-route-5-architecture-review.md (A1-A11).

Subject: the uncommitted working tree, HEAD 30d3d114, branch claude/acdream-physics-divergence-5aa784 — 1,626 insertions / 398 deletions across 10 files plus two untracked test files.

---

VERDICT: FAIL

A narrow FAIL. Eleven of the twelve round-1/architecture findings are properly closed, several of them better than the fix direction I suggested. The FAIL rests on two MAJORs:

• B1 — the fix to my own round-1 R6 went the wrong way and introduced a position/cell mismatch on the stored partition. R6 as I wrote it was factually wrong, and I own this: I claimed the render cell was "left behind" while the position moved; it was not — record.FullCellId is already the wire cell at ack time, so the original code was self-consistent. Switching to the body's own cell made it inconsistent. This is a one-token revert.
• B2 — the R2/A3 adopted-body fix closed the teleport branch and left the far branch. Retail's far branch @0x005163C1-@0x005163CB runs StopInterpolating whenever position_manager != 0, and re-anchors the leash @0x00454272 on any nonzero return. For an adopted missile both managers exist, both actions are live in retail, and acdream now performs neither. I confirmed the harm is real, not theoretical.

Both are the same shape as the findings they descend from: an invariant satisfied on one arm only.

---

A. Round-1 / architecture findings — delta status

ID	round-1 / arch	status	notes
R1 / A2	unbound missile dropped	CLOSED — better than my fix direction	see A1 below
R2 / A3	adopted-body hook unwired	PARTIAL	teleport branch closed; far branch open → B2
R3	retry arm skips invalidate/sync	CLOSED	see A3
R4 / A7	hidden-branch LastUpdateTime dropped	CLOSED	restored at SyncProjectilePresentation's else if (spatial) with the correct rationale quoted from TryBind
R5 / A1	App ignores seam status	CLOSED	see A4
R6	stored-outcome cell	REGRESSED — my finding was wrong	→ B1
R7 / A5	no App-level coverage	CLOSED	7 new OnPosition tests incl. the unbound fall-through and the adopted-body hook
R8	unjustified-velocity comment untracked	OPEN, deliberately	judgment in D below — partially acceptable
A4	SyncProjectilePresentation untested	CLOSED	real ShadowObjects entry / TotalRegistered / Active-flag assertions across four new tests
A6	wasInWorld read after placement	CLOSED	captured pre-dispatch and threaded as a parameter; …ReenteringWorldReactivatesBody pins it
A8	silent shadow skip	CLOSED	escalates via ThrowIfWorldFrameUnreachable, matching StoreAcceptedDestinationPose's #284 policy
A9	null-route fallback unfenced from the player	CLOSED	update.Guid != _playerServerGuid && added
A10	OwnsFarSnap doc false in the kind dimension	CLOSED	corrected paragraph added
A11	cutover ledger stale	not checked here (outside D-P7's letter; architecture reviewer's call)

---

B. Verification of the four items you asked me to judge

A1 — the conjunctive kind predicate: is it retail-CORRECT, not merely regression-free?

Yes. PASS, and the reasoning is stronger than "it restores the old fall-through".

RuntimeEntityObjectLifetime.ClassifyRemoteAcceptedPosition now derives:

Missile bit  &&  canonical.Projectile is bound  &&  ReferenceEquals(canonical.PhysicsBody, projectile.Body)
    ? Projectile : Remote

Why this is retail-correct rather than an implementation detail smuggled into a classification:

1. RuntimePositionEntityKind is not a retail concept and has no retail effect. I re-verified RuntimeAuthoritativePositionRouteClassifier: the only kind branch in ClassifyAcceptedPosition is LocalPlayer (:349); ValidEntityKind (:535-538) admits all three; the sole downstream difference is OperationKind (:564-575). Projectile and Remote produce byte-identical disposition, SetPositionFlags, StopInterpolating, TeleportHookPhase and ConstrainPhase. The kind is therefore an acdream ownership label selecting which arm executes, not a reproduction of any retail decision. Retail's MoveOrTeleport @0x00516330 has no state test at all (round-1 §A1, byte-confirmed), so there is no retail predicate for this code to be unfaithful to.
2. The check lives in the right place. It is in the caller that maps acdream state → kind, not inside ClassifyAcceptedPosition, which remains a pure port of retail's decision tree. Nothing acdream-specific entered the retail-faithful classifier.
3. Mis-routing a genuinely-bound missile is harmless in the retail direction. The only way a live missile classifies Remote is if record.PhysicsBody was replaced out from under a surviving RuntimeProjectile — already a broken state, and one that ApplyAcceptedProjectilePosition's identical guard would refuse anyway (round 1: it dropped the packet). Taking the Remote arm instead places the canonical body, which is what retail does; it also arms the leash and runs the full hook, i.e. more of retail's behaviour, not less. There is no direction in which the conjunctive predicate produces less retail-faithful output than the arm it diverts from.
4. The reverse mis-route cannot happen. A non-missile can never satisfy clause 1, so no ordinary remote is diverted into the projectile arm.

The App's null-classification fallback (LiveEntityNetworkUpdateController.cs:2132-2140) now applies the same three conjuncts plus the A9 player fence, so the two discriminators still cannot disagree. Verified by reading both.

The doc comment's claim — "Retail's MoveOrTeleport places EVERY non-player object unconditionally — it has no concept of 'client-side machinery not yet bound'" — is true and matches my byte-level read of the function.

A2 — is "has RemoteMotion" the right proxy for "has managers"?

For actions 1-4, yes, provably. For action 5, the proxy is imperfect but skipping is still the retail-correct outcome. PASS with a note.

Mapping retail's six teleport_hook @0x00514ED0 actions onto acdream's owners:

retail action	guard	acdream owner	reachable without RemoteMotion?
MovementManager::CancelMoveTo @0x00514EDD	movement_manager != 0	RemoteMotion.Movement (a field on RemoteMotion, RemoteMotion.cs:36)	no
PositionManager::UnStick @0x00514EEE	position_manager != 0	RemoteMotion.Host.PositionManager (Host is gated on _fullPhysicsHostBound, :87)	no
PositionManager::StopInterpolating @0x00514EFD	same	RemoteMotion.Interp (:233)	no
PositionManager::UnConstrain @0x00514F0C	same	RemoteMotion.Host.PositionManager	no
TargetManager::ClearTarget/NotifyVoyeurOfEvent @0x00514F1B	target_manager != 0	EntityPhysicsHost.TargetManager	yes — see below
report_collision_end @0x00514F31	unguarded	RuntimeCollisionReportingState.LeaveWorld	run by the Runtime seam regardless ✓

The one leak: LiveEntityMotionRuntimeController.ResolvePhysicsHost:246-250 installs a minimal EntityPhysicsHost for any record the target/moveto resolver touches, and that host carries a TargetManager. So a bare missile can hold a TargetManager while record.RemoteMotion is null, and the reduction skips its ClearTarget/NotifyVoyeurOfEvent.

This does not make skipping wrong. Retail's missile has no TargetManager — MakeTargetManager is lazy and nothing in a ballistic object's life creates one — so retail's guard @0x00514F19 no-ops. acdream's eager minimal-host creation is a pre-existing structural difference from retail, not something route 5 introduced, and running the action would be the divergence, not skipping it. Recorded so the next round does not re-open it.

A3 — the retry arm (my R3)

CLOSED and correct. Advance() now derives the projectile/body pair from pending.Route.OperationKind under the same three conjuncts, captures pendingWasInWorld before the resubmit (matching A6's ordering fix), calls InvalidatePrediction() before both the store fallback and the resubmit, and gates SyncProjectilePresentation on the same non-Deferred/non-RejectedByPlacement partition. The invariant now holds on both arms.

One residual, pre-existing and shared with the remote arm, not a finding: the retry path never calls StoreAcceptedDestinationPose after a SubmitAndResolve that returns Contention/RejectedPreparation, so invariant 1's pose advance is skipped on a re-parked retry. That was true before this slice (_ = SubmitAndResolve(...)) and is the remote arm's behaviour too. Recorded, not filed.

A4 — the App presentation gate, and whether "stored outcomes write the cell too" is now true

The gate is CLOSED and correct. The cell question is NOT — and it is worse than before. See B1.

The gate itself: App now calls SyncPresentationFromResolvedBody only when the status is non-null and neither Deferred nor RejectedByPlacement, mirroring Runtime's own partition exactly. I walked every outcome:

outcome	body state	ack?	retail analogue
Committed	at resolved destination, cell committed	yes	SetPosition success
Refused/Contention/RejectedPreparation/NotApplicable	position stored at destination, cell NOT written	yes	store_position @0x00515CE2
Deferred	snapped to parked result, withdrawn	no	park (acdream-only, AP-136/138)
RejectedByPlacement	untouched	no	@0x00515CB2 / @0x00515CD5 — retail's non-storing failures also leave the object where it was ✓
null (no-op / swallow)	untouched	no	return 0 @0x0051636D, or acdream-only

Correct on every row.

---

C. New MAJOR findings

B1 — MAJOR — the R6 "fix" pairs the destination position with the pre-packet cell on every stored outcome; the correct source was the one it replaced

Where: src/AcDream.App/Physics/ProjectileController.cs, SyncPresentationFromResolvedBody — entity.ParentCellId = runtime.Body.CellPosition.ObjCellId (was record.FullCellId).

Retail contradicted: CPhysicsObj::store_position @0x00515CE2, reached from SetPositionInternal's no-resolvable-cell branch @0x00515C1D. It writes the object's whole Position — objcell_id together with the frame — so after a retail store the object's cell and position are the same cell, the destination. It is never left describing a position in cell B while claiming membership of cell A.

My round-1 R6 was wrong and I induced this. I wrote that on a stored outcome "the render cell is left behind while the render position moves". It is not: RuntimeEntityRecord.RefreshDerivedState → SetFullCell (RuntimeEntityRecord.cs:232-237) stamps FullCellId = position.LandblockId at merge time, before classification, and StoreAcceptedDestinationPose composes body.Position from accepted.PositionX + worldOffsetX where the offset comes from accepted.LandblockId — the same cell. So the original entity.ParentCellId = record.FullCellId paired a wire-frame position with the wire cell: self-consistent, and retail's store semantics. The architecture reviewer had this right in its "Verified — no finding" section; I did not.

What the change now produces on a stored outcome:

• entity.Position = destination, expressed in cell B's world frame
• entity.ParentCellId = body.CellPosition.ObjCellId = cell A (StoreAcceptedDestinationPose never writes the cell — the AP-138 residual)

That is precisely the defect shape the architecture review's A1 named — a render entity parented into a cell it is not geometrically inside, culled or drawn through walls when A is an indoor EnvCell — relocated from the no-op partition (now fixed) to the stored partition (now broken).

Three independent cross-checks all say record.FullCellId:

1. The sibling remote arm. TryApplyGenericRemoteRenderPose (LiveEntityNetworkUpdateController.cs:1010-1025) writes entity.ParentCellId = landblockId — the wire cell — paired with the wire world position. Parity demands the projectile arm do the same.
2. Runtime's own shadow publish, forty lines away. SyncProjectilePresentation publishes ShadowObjects.UpdatePosition(..., record.FullCellId, seedCellId: record.FullCellId) with body.Position. After this change the shadow says cell B and the render entity says cell A for the same body in the same call.
3. Retail, as above.

The doc comment defending the change is self-refuting. It states "Retail's own store_position @0x00515CE2 writes the object's whole Position including objcell_id; reading the body's own cell here is the client-side analogue" — the premise is right and the conclusion inverts it. Retail's objcell_id after a store is the destination (record.FullCellId), not the stale one.

Untested. Both new App commit tests (MissileTeleportCommit_…ParentCellIdAgreesWithBody, MissileFarCommit_…) assert on committed outcomes, where body.CellPosition.ObjCellId == record.FullCellId == DestinationCell and the two sources coincide. No test drives a stored outcome through the App ack, so the suite is green either way — a green suite is not evidence.

Correct behaviour: revert to entity.ParentCellId = record.FullCellId, and add an App-layer stored-outcome test (Refused) asserting the render position and ParentCellId are both the destination cell's.

---

B2 — MAJOR — the adopted-body fix closed the teleport branch only; retail's FAR branch also runs StopInterpolating, and re-anchors the leash, whenever the manager exists

Where: LiveEntityNetworkUpdateController.cs — the hook is gated on route.Disposition is …SetPosition && acceptedPositionCanonical.RemoteMotion is RemoteMotion; and RuntimeRemotePlacementDriveController.ApplyAcceptedProjectilePosition's case …SetPositionSimple: does nothing but invalidate and place.

Retail contradicted, two sites:

005163c1  position_manager = this_1->position_manager;
005163c9  if (position_manager != 0)
005163cb      PositionManager::StopInterpolating(position_manager);
005163d9  CPhysicsObj::SetPositionSimple(this_1, arg2, 1);

and, for every nonzero return including this one, ConstrainTo(arg2, &arg2->m_position, …) @0x00454272 — which re-anchors the leash at the object's just-updated position.

Why the contract's justification does not cover the adopted case. D-P2 pins the far branch's interp skip as "retail-faithful by consequence" because "a never-interpolated missile has none". That premise is exactly what the adopted-body case violates: TryBind's shared-body branch (ProjectileController.cs:176-181) exists for an object that was a live remote first, so it carries a populated RemoteMotion.Interp and, if hosted, a PositionManager whose leash route 4a (RuntimeRemoteSteadyStatePosition.TryArmConstraintAfterOperation) already armed. Retail's position_manager != 0 guard is satisfied there.

The harm is real, not structural. I traced it:

• RuntimePhysicsState.cs:697-708 puts the same key in both _spatialRemotes and _spatialProjectiles when the record has both components.
• RuntimeRemotePhysicsUpdater consumes rm.Interp for every _spatialRemotes entry (:288, :331, :941).
• ProjectileController.Tick's per-quantum tail runs RetailObjectManagerTail.Run(remote.Host?.TargetManager, remote.Movement, null, remote.Host?.PositionManager) for exactly this record shape.

So after a far snap, a stale waypoint and a leash anchored at the pre-snap position both remain live and drag the freshly-placed missile back — the identical scenario the architecture review's A3 used to justify wiring the teleport branch. The teleport branch got the fix; the far branch, which is the more common disposition for a moving object at >=96 m, did not.

AP-141 is now factually wrong in its risk column. It states "a live missile never shows a constraint leash". After the round-2 fix that is false for the adopted-body case: such a missile can carry a leash inherited from its pre-Missile remote life, the teleport branch now clears it, and the far branch neither clears nor re-anchors it. This is the "a register row asserting behaviour the code does not have" defect class the 4b-3 reviews named.

Correct behaviour: either run the same hook seam on the far branch's manager-bearing case (retail runs only StopInterpolating there, not the full hook — so the minimal faithful action is remote.Interp.Clear() gated on the host existing, mirroring @0x005163C9), and decide the leash re-anchor explicitly; or amend AP-141 to state that for an adopted body the far branch skips retail's guarded StopInterpolating @0x005163CB and leaves an inherited leash un-re-anchored. Do not leave the row asserting the opposite.

---

D. MINOR findings

B3 — MINOR — report_collision_end now runs twice for the adopted teleport case, and the hook is split across two owners

App's RunRemoteTeleportHook executes all six actions including ReportCollisionEnd → LiveEntityRuntime.ForceEndCollisionReporting → RuntimeCollisionReportingState.LeaveWorld; the Runtime seam then runs CollisionReports.LeaveWorld(record) again before the placement. Retail calls @0x00514F31 once. The second call is benign (the table is already empty, so ForceEnd finds nothing; it only bumps _mutationRevision), and the ordering relative to SetPosition is preserved, so this is cosmetic — but one retail function now has two owners across a layer boundary, which is how the order of a six-step sequence gets broken later. Cleanest: have the Runtime seam skip its own LeaveWorld when the caller supplied the full hook, or move the whole hook behind the Runtime seam.

B4 — MINOR — the projectile hook allocates a per-packet closure while its comment claims the "#315 pattern"

LiveEntityNetworkUpdateController.cs, projectile arm:

RunRemoteTeleportHook(
    acceptedPositionCanonical,
    adoptedRemote,
    () => _liveEntities.IsCurrentPositionAuthority(   // fresh closure, every packet
        acceptedPositionRecord,
        acceptedPositionAuthorityVersion));

The comment says this uses "the SAME ordered hook seam and per-packet currency check the remote teleport arm already uses (RunRemoteTeleportHook, #315 pattern)". The remote arm does not do this: it passes _remoteArmCallbacks.RunTeleportHook, a cached method group over scratch fields (RunCachedRemoteTeleportHook), which is precisely what #315 introduced to remove per-packet closures from the packet path. The contract restates that constraint (§2 item 5). The seam is shared; the allocation discipline is not, and the comment asserts otherwise.

B5 — MINOR — R8 remains open

Judgment you asked for: deferring the audit is acceptable; deferring the tracking is not. The comment now asserts, in production source, that a live call's retail justification is unestablished. With no docs/ISSUES.md row and no AP row, that assertion is discoverable only by reading LiveEntityNetworkUpdateController.cs. One line in ISSUES.md ("4a remote arm's TryCommitAuthoritativeVelocity has no established retail basis — see the comment at the call site; MoveOrTeleport @0x00516330 byte-confirmed not to install a velocity") costs nothing and should land with this commit. The substantive audit belongs to the 4a family, as the contract says.

B6 — MINOR — the stored-outcome shadow publish uses an unadvanced body on a re-parked retry

Advance()'s retry arm calls SyncProjectilePresentation after a SubmitAndResolve that returned Contention, but never StoreAcceptedDestinationPose on that path (B-section A3's residual). The shadow is therefore published at record.FullCellId (the wire cell) with a body still at its pre-packet pose — the mirror image of B1, inside Runtime. Parity with the remote arm, pre-existing, and it disappears if B1's residual (store never writes the cell, AP-138) is ever closed. Recorded, not filed.

---

E. Retail claims re-verified this round (no change)

Re-checked because the fix touched the surrounding code, not re-derived from scratch (round 1 §A has the full derivations):

• MoveOrTeleport @0x00516330 — no state/kind test; arg5 at [esp+0x7C] never read (byte-confirmed round 1); ret 0x10 at all four exits.
• teleport_hook @0x00514ED0 — six actions, five per-manager guarded, the sixth unguarded. The App fix drives the in-tree ordered port (RemoteTeleportHook.Execute) with per-action host?. guards, so retail's guards decide rather than being re-derived. Correct for the teleport branch.
• ConstrainTo @0x00510520 → MakePositionManager @0x00510523; the single arming site @0x00454272 has no kind test. AP-141 clauses (a) and (b) remain accurate descriptions of retail; only the row's risk column is now wrong (B2).
• store_position @0x00515CE2 writes objcell_id with the frame — the basis of B1.
• ACE never sends a missile UpdatePosition (WorldObject_Tick.cs:333-334 inside the PhysicsState.Missile branch at :265), so B1 and B2 are both test-reachable only. Stated for calibration, not as a reason to ship them.
• AP-131 and AP-135 untouched; docs/ISSUES.md unmodified; #276 not closed.

---

F. Summary

#	Sev	Where	Retail address contradicted
B1	MAJOR	ProjectileController.SyncPresentationFromResolvedBody (entity.ParentCellId)	store_position @0x00515CE2 — writes objcell_id with the frame; also breaks parity with TryApplyGenericRemoteRenderPose and with the shadow publish in the same call
B2	MAJOR	LiveEntityNetworkUpdateController hook gate (SetPosition only) + ApplyAcceptedProjectilePosition's SetPositionSimple arm	StopInterpolating @0x005163C9-@0x005163CB (guard satisfied for an adopted body); ConstrainTo @0x00454272 re-anchor
B3	MINOR	App hook action 6 + Runtime seam LeaveWorld	@0x00514F31 called once in retail
B4	MINOR	projectile arm's Func<bool> closure	— (contract §2 item 5; comment false)
B5	MINOR	no ISSUES/AP row for the acknowledged-unjustified velocity commit	—
B6	MINOR	Advance() retry shadow publish	— (mirror of B1 inside Runtime; parity, pre-existing)

Both MAJORs are small edits. B1 is one token. B2 is the far-branch half of a fix already written for the teleport branch, plus an AP-141 risk-column correction.