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

C4 route 5 — architecture / adversarial review (2026-08-04)

Verdict: FAIL.

Scope reviewed: the uncommitted working tree at HEAD 30d3d114, branch claude/acdream-physics-divergence-5aa784 — git diff HEAD over 8 files plus the untracked tests/AcDream.Runtime.Tests/Entities/RuntimeProjectilePositionKindTests.cs. docs/research/2026-08-04-c4-route-5-contract.md is the contract, not under review. Line numbers below are as-of the working tree and will go stale; every citation also names the symbol (process rule 6).

Independent verification performed for this review: dotnet build AcDream.slnx -c Release (succeeded, 0 warnings / 0 errors), focused Runtime suites 58/58 green, focused ProjectileControllerTests 41/41 green. The complete Release suite was NOT run here.

The design is sound and the Runtime seam is largely a faithful, well-argued reproduction. The FAIL rests on four things: two real defects in the ~35 lines of App dispatch glue (A1, A2), one pinned contract obligation left unwired with a concrete failure scenario (A3), and the fact that the presentation invariant (§5 item 2, "#312's layer — tests must assert it") and the entire App dispatch have zero test coverage (A4, A5) — which is also the direct answer to the scoping-gap question at the end.

---

MAJOR findings

A1 — the App projectile ack ignores the seam's status and writes cell identity on the outcomes the design pins as "write nothing"

Severity: MAJOR. src/AcDream.App/Physics/LiveEntityNetworkUpdateController.cs:2137-2144 (OnPosition, the D-P6 projectile arm):

if (earlyRemoteRoute is { } route)
{
    _remotePlacementDrive.ApplyAcceptedProjectilePosition(
        acceptedPositionCanonical,
        route);
    _projectileController?.SyncPresentationFromResolvedBody(
        acceptedPositionRecord);
}
return;

The returned RuntimeRemotePlacementExecutionStatus? is discarded. The Runtime half is deliberately selective — RuntimeRemotePlacementDriveController.ApplyAcceptedProjectilePosition:975-983 skips SyncProjectilePresentation for Deferred/RejectedByPlacement ("Invariant 2: presentation advances on every committed/stored outcome only") and returns null without touching anything for Interpolate, NoPositionOperation, RejectedAuthority, RejectedData, and every ownership mismatch. App re-projects presentation for all of them.

Concrete failure scenario (the near no-op, D-P2's pinned Interpolate row):

1. An in-flight arrow's canonical body sits in cell A at world P_A.
2. A grounded, <96 m accepted Position for cell B arrives. RuntimeEntityObjectLifetime.TryApplyPosition merges it; the merge's RefreshDerivedState → SetFullCell (RuntimeEntityRecord.cs:230-251) stamps canonical.FullCellId = B before any classification runs.
3. The classifier returns Interpolate — a pinned no-op. The Runtime seam writes nothing: body stays at cell A / P_A, prediction version unchanged.
4. App nevertheless runs ProjectileController.SyncPresentationFromResolvedBody:505-520, which does entity.SetPosition(runtime.Body.Position) (= P_A, correct) and entity.ParentCellId = record.FullCellId (= B, wrong — LiveEntityRecord.FullCellId is Canonical.FullCellId, LiveEntityRuntime.cs:189-191).

The render entity is now parented into a cell it is not geometrically inside, with a position from the other cell. If B is an indoor EnvCell the arrow has not entered, the arrow renders through the wall or is culled. The same write happens on RejectedByPlacement, where the Runtime comment says in as many words that the body must be left "at its prior (already-synced) pose".

This is a genuine regression, not parity: the deleted ApplyAuthoritativePosition had no disposition concept — it always moved the body to the wire cell and wrote the same cell into the entity, so position and cell were always consistent. Splitting the body write out by disposition without splitting the presentation write out with it is what creates the divergence.

Fix direction: return the status through the App boundary and call SyncPresentationFromResolvedBody only on the outcomes SyncProjectilePresentation itself covers (non-null status that is neither Deferred nor RejectedByPlacement) — or move the render-entity projection into the same gate inside the Runtime seam and have App acknowledge, not decide.

---

A2 — a record carrying the Missile bit with no bound RuntimeProjectile now has every accepted Position silently dropped, where it previously fell through to the remote tail

Severity: MAJOR (silent, permanent). Discriminator: LiveEntityNetworkUpdateController.cs:2122-2146 (isMissilePacket); refusal: RuntimeRemotePlacementDriveController.ApplyAcceptedProjectilePosition:930-936 (record.Projectile is not RuntimeProjectile projectile → return null).

isMissilePacket keys purely on the canonical record's Missile bit. It does not require that a projectile component exists. The old short-circuit did: the deleted ProjectileController.ApplyAuthoritativePosition returned false when TryGetCurrent found no bound RuntimeProjectile, and == true failing meant the packet fell through to the generic remote tail.

record.Projectile has exactly one producer: ProjectileController.TryBind → LiveEntityRuntime.BindProjectileRuntime → RuntimePhysicsState.BindProjectile (verified by grep — no other writer of Entities.SetProjectile(record, component)). TryBind has several ordinary, non-exceptional failure returns, e.g. ProjectileController.cs:160-166:

"Missile 0x… Setup 0x… does not have the supported retail one-sphere collision shape."

Scenario: ACE spawns a missile whose Setup does not reduce to the supported one-sphere shape (a diagnosed, expected case — it has its own log line). TryBind returns false; record.Projectile stays null; FinalPhysicsState & Missile stays set. Every subsequent accepted Position for that guid now returns at :2146 having done nothing at all — no TryApplyGenericRemoteRenderPose, no RebucketLiveEntity, no GetOrCreateRemoteMotionRuntime. The object freezes at its create pose for the rest of its life and never follows the server. Before this diff it tracked, via the remote tail.

The contract's D-P6 does pin "dispatch the projectile arm and RETURN", so this is a defect in the design as implemented rather than a slip against it — but it is still a new, silent, permanent freeze, and the same defect class (the frozen entity) that the 4b-family reviews have been hunting. Reachability caveat, stated honestly: ACE never sends a missile UpdatePosition (WorldObject_Tick.cs:333-334), so like every other half of this route it is test-reachable only.

Fix direction: make the discriminator conjunctive — a packet takes the projectile arm only when the arm can actually own it (Missile bit and a bound projectile whose Body is the canonical PhysicsBody); otherwise let it take the ordinary tail, which is what the record's shape actually is. If the swallow is intended, it needs its own register row and a test that pins it, and neither exists.

---

A3 — D-P4's teleport-hook reduction is unwired for the adopted-body case, which the codebase explicitly supports

Severity: MAJOR (contract obligation unmet; concrete scenario). RuntimeRemotePlacementDriveController.ApplyAcceptedProjectilePosition:944 runs exactly one of retail's six teleport_hook @0x00514ED0 actions:

case RuntimeAuthoritativePositionDisposition.SetPosition:
    _entityObjects.Physics.CollisionReports.LeaveWorld(record);

The contract pins more than that: "The other five actions execute iff their owning component exists — for the adopted-body case (a missile that also carries a RemoteMotion), the existing hook actions' per-manager guards already express retail's shape; the implementer wires this without per-packet closures" (D-P4). Nothing wires them, and no note records the omission.

The adopted-body case is not hypothetical. ProjectileController.TryBind's shared-body branch exists precisely for it — "If a non-missile incarnation already created its MovementManager or entered the Physics-Static animation workset, classification adopts that same body" — and RuntimePhysicsState.BindProjectile:757-830 does not exclude a record that has a RemoteMotion. RuntimePhysicsState.cs:697-708 shows the same key can sit in both _spatialRemotes and _spatialProjectiles.

Scenario: an object is a live remote with a populated RemoteMotion.Interp queue and a ConstrainTo leash armed by route 4a's RuntimeRemoteSteadyStatePosition.TryArmConstraintAfterOperation. ACE then sets the Missile bit (a State packet); TryBind adopts the shared body. The next teleport/cell-less Position takes the projectile arm: collisions are force-ended and the body is teleported, but StopInterpolating, UnConstrain, CancelMoveTo, and UnStick never run. The RemoteMotion survives in the remote workset with a stale waypoint and a live leash anchored at the pre-teleport position, and drags the newly-placed missile body back. Retail @0x00514EFD/@0x00514F31 runs all six, each guarded on its own manager, so retail's own guards would no-op for a pure arrow and would fire here.

Note this is not a regression from HEAD — the old short-circuit did not run the hook either — but D-P4 made wiring it an explicit obligation of this slice, and the faithful port (RemoteTeleportHook.Execute + RemoteTeleportHookActions, src/AcDream.App/Physics/RemoteTeleportHook.cs) is sitting in-tree unused for this arm. That is exactly the 4b-3 round-2 R2 defect class the contract cited by name.

Fix direction: drive the projectile teleport arm through the same six-action bundle (cached delegates, #315 pattern), letting each action's per-component guard decide — for an ordinary arrow all five extra actions are no-ops, and the adopted-body case gets retail's shape for free.

---

A4 — SyncProjectilePresentation, the highest-risk reproduced code in the diff, has no test that would fail if it were deleted

Severity: MAJOR (test gap on the invariant the contract singles out). RuntimeRemotePlacementDriveController.SyncProjectilePresentation:987-1039.

Contract §5 invariant 2: "Presentation still advances… the shadow registry is synced (spatial+visible) or suspended (hidden/non-spatial) exactly per the current tail's semantics. A projectile is never left rendered a packet behind its body (#312's layer — tests must assert it)."

Across all seven new Runtime tests, the only assertion that even touches this method is Assert.True(body.InWorld) in ApplyAcceptedProjectilePosition_Refused_StillAdvancesPoseNoParkPredictionInvalidated. That assertion is vacuous with respect to the sync: the fixture's AttachBody (RuntimeRemotePlacementDriveControllerTests.cs:2860-2880) calls body.SnapToCell(...), and PhysicsBody.SnapToCell sets InWorld = true (PhysicsBody.cs:201-205). Nothing in the Refused path clears it. So the assertion passes with SyncProjectilePresentation entirely removed.

Unasserted, at any layer: the shadow-registry publication (ShadowObjects.UpdatePosition), the spatial+hidden Suspend, the non-spatial InWorld = false + Active clear + Suspend, the !body.InWorld activation edge, and the three currency guards at the method's head. The committed-outcome tests (…TeleportCommit…, …FarCommit…) assert status, position, prediction version, velocity, RemoteMotion is null, and collision-owner count — none of which the sync produces.

Fix direction: one test per branch of the sync, keyed on the observable the old tail produced: shadow row present at the resolved pose (spatial+visible), Suspend called (spatial+hidden and non-spatial), Active cleared (non-spatial). These are cheap; the fixture already registers shadows in SeedCollisionOwner.

---

A5 — no App-layer test exercises OnPosition with a missile packet at all; §7 items 8 and 9 are unwritten

Severity: MAJOR (this is the scoping-gap answer).

grep -rn "Missile" tests/AcDream.App.Tests/Physics/LiveEntityNetwork*.cs returns zero hits. The only App file mentioning Missile at all is ProjectileControllerTests.cs, which never calls OnPosition.

So none of the following is covered anywhere:

• the D-P1/D-P6 discriminator itself in its production call site;
• invariant 8's mutual exclusion (Missile-set ⇒ projectile arm and no RemoteMotion afterward; Missile-clear ⇒ remote tail and no projectile effect);
• the null-classification swallow (earlyRemoteRoute is null with the Missile bit set) and its positive half (timestamps consumed, merge advanced);
• the "no early wire-pose write / no RebucketLiveEntity" pins;
• the presentation ack the App owns — i.e. #312's layer at the layer it renders.

Worse, the retired App test MalformedFreshUpdates_DoNotPoisonCanonicalBodyOrPose justifies its Position half's deletion by pointing at "LiveEntityNetworkUpdateController's own 'invalid-payload swallow' test". That test does not exist. The underlying claim (the shared CanAcceptPositionPayload gate rejects the payload upstream) is correct and I verified it independently — but the cited successor coverage is not there, so the assertion was retired against a coverage claim that is false.

Both A1 and A2 live inside the ~35 lines the implementer argued were "thin glue between two well-tested layers". That is the empirical refutation of the argument.

---

MINOR findings

A6 — the !body.InWorld gate is read after the placement, where the deleted tail captured wasInWorld before it

SyncProjectilePresentation:1012-1018 reads body.InWorld after TryExecuteAcceptedRemotePosition has run. The canonical commit calls body.SnapToCell(...) (RuntimeSetPositionState.cs:4974), which sets InWorld = true. The deleted tail captured bool wasInWorld = body.InWorld; before its SnapToCell. Consequence: on every committed outcome the re-activation branch (body.LastUpdateTime = clock + TransientState |= Active) is now dead — a projectile that had left the world and comes back through a committed accepted Position is marked InWorld but never re-flagged Active, and its legacy LastUpdateTime is not rebased. It self-heals on the next tick because RetailObjectActivityGate.Evaluate re-sets the flag (RetailObjectActivityGate.cs:61-67), which is the only reason this is MINOR rather than a frozen body. Fix: capture body.InWorld before dispatching the placement and pass it in.

A7 — the spatial+hidden branch silently drops body.LastUpdateTime = currentTime

Deleted tail: else if (spatial) { body.InWorld = true; body.LastUpdateTime = currentTime; Suspend(); }. New (SyncProjectilePresentation:1031-1035): the LastUpdateTime write is gone. ProjectileController.TryBind's equivalent branch documents why the write exists — "consume the hidden clock so UnHide cannot replay a time backlog". Bounded by TryBegin refusing Hidden and by the RetailObjectQuantumClock being canonical post-R6, but it was a deliberate write and its removal is unremarked.

A8 — the shadow publication is silently skipped when the Runtime world frame is unavailable

SyncProjectilePresentation:1019-1030 wraps the shadow update in if (physics.TryGetWorldFrameOffset(...)) and does nothing on false. The deleted ShadowPositionSynchronizer.Sync always published, using App's live centre, and returned early only for cellId == 0. TryGetWorldFrameOffset additionally returns false when _worldFrameCenterLandblockId == 0 (RuntimePhysicsState.cs:613-632). Two methods away, StoreAcceptedDestinationPose:1113-1119 treats exactly this case as ThrowIfWorldFrameUnreachable — #284's "a frame that can never arrive is terminal, never silent" policy. The new code neither publishes nor escalates.

A9 — the null-route fallback is not fenced off the local player

LiveEntityNetworkUpdateController.cs:2122-2126: when earlyRemoteRoute is null, isMissilePacket falls back to a bare FinalPhysicsState & Missile test. earlyRemoteRoute is always null for update.Guid == _playerServerGuid. A local-player record that ever carried the Missile bit would therefore swallow its own accepted Position and freeze the player. Currently impossible only because ACE never sets Missile on a player — a one-token update.Guid != _playerServerGuid && would make it structurally impossible.

A10 — OwnsFarSnap's doc is now false in the kind dimension

src/AcDream.Runtime/Physics/RuntimeRemoteFarSnapPosition.cs:78-79 still states this predicate is "a strict narrowing of OwnsPlacement to its far half". After the widening it narrows only OwnsPlacement's remote far half. RuntimeRemoteTeleportPosition.cs:33-35 hedges correctly ("OwnsPlacement's remote scope"); the far-snap doc does not. D-P3 asked for exactly this correction where a comment would otherwise mislead (process rule 6).

A11 — the cutover route ledger still lists the deleted methods as live routes

docs/research/2026-08-02-cutover-route-inventory.md:666-694 still describes ProjectileController.ApplyAuthoritativePosition → RuntimeProjectilePhysicsUpdater.ApplyAuthoritativePosition as a live route with SnapToCell + CommitProjectileCell. D-P7 scoped the re-point grep to src/ and docs/architecture/, so this is outside the letter of the obligation — but that file is the C4 route ledger this campaign reads from, and it is now wrong about route 5.

---

Verified — no finding

These were hunted and came back clean; recorded so the next round does not re-litigate them.

• P3 (RuntimeSetPositionState kind-agnosticism) is CORRECT, and I verified it independently rather than accepting the argument. TryBeginExclusiveAuthoredPlacement:1444-1472 returns default (invalid token → Contention) whenever _operations.ContainsKey(key) or HasRetainedCompletion(key). Both constructors that stamp Kind = RemoteAuthoritative — ParkCollisionResidents's window-departure park (:3833/:3866, which itself continues past any record already in _operations) and CreateWithdrawalOperation (:5338/:5350, reached only from Cancel after CancelCoreDeferred) — install an operation into _operations under the record's key. A projectile accepted Position arriving while one is live cannot capture or be relabelled by it; it refuses with Contention, which StoresAcceptedDestination() puts on the storing side, so the pose still advances and no ledger column is mislabelled. The two kind-conditional stage sites (IsExactDormantLocalActivationCurrent:5445-5446, IsDormantLocalActivationPrephaseCurrent:2554-2600) additionally require InitialLogin/LocalAuthoritative and record.Projectile is null, and the family has zero production callers. Residual, benign and pre-existing: a park operation created for a projectile record carries Kind = RemoteAuthoritative, but it never reaches the drive controller's ledger.
• The three ownership fences hold. OwnsPlacement has exactly one production reader — TryExecuteAcceptedRemotePosition:640 (verified by grep across src/; every other hit is a doc comment or a test). OwnsFarSnap and OwnsTeleportPlacement keep their RemoteAuthoritative gate, and a projectile route cannot reach ApplyAcceptedRemoteFarSnap / ApplyAcceptedRemoteTeleport / TryArmConstraintAfterOperation: the App returns before the remote tail whenever isMissilePacket, and isMissilePacket is derived from route.OperationKind whenever a route exists, so the two cannot disagree. The throwing guards stay unreachable, and no RemoteMotion is ever created on this arm.
• The remote route is unchanged. Moving the ClassifyRemoteAcceptedPosition call earlier hops only a pure-read guard block (TryGetRecord / ReferenceEquals / IsCurrentPositionAuthority) with no reentrancy in between; classification itself is side-effect-free. Zero remote classifier tests changed expectation, which is the contract's own tripwire.
• StoreAcceptedDestinationPose never writes a cell, so on Refused/Contention/RejectedPreparation the projectile body's CellPosition stays at the source cell while record.FullCellId is the wire cell. This is identical to the accepted remote behaviour (AP-138's residual) and the quantum stepper takes the cell from record.FullCellId explicitly (RuntimeProjectilePhysicsUpdater.TryBegin), so it is parity, not a new defect. Recorded, not filed.

---

Judgment on the four implementer claims

Claim 1 — both ApplyAuthoritativePosition overloads and the Runtime updater's copy deleted; nothing else called them; no behaviour lost. Deletions and callers: VERIFIED. No code reference survives anywhere in src/ or tests/ (only comments, the contract, and the two research docs noted in A11); Release build green with 0 warnings. "No behaviour lost": PARTIALLY FALSE. Three deliberate behaviours went with them and only one is accounted for: the origin-translated world-position finiteness check (genuinely redundant — worldPos is a finite wire triple plus an integer landblock offset, so it cannot be non-finite when CanAcceptPositionPayload passed); the _lastFiniteGameTime rebase on a Position packet (App tick clock — unremarked, low impact); and the wasInWorld activate edge plus the hidden-branch LastUpdateTime write (A6, A7 — unremarked).

Claim 2 — 7 call sites modified, 2 assertions retired as obsolete. Mostly legitimate, with one false coverage claim. The velocity assertions in FreshVectorAndPositionCorrectionsMutateSameBody are genuinely obsolete under D-P5 and have a real positive successor (…TeleportCommit… / …FarCommit… assert body.Velocity bit-identical after a placement). The AuthoritativeMutation.Position retirement has a genuine, load-bearing successor I read and checked — ApplyAcceptedProjectilePosition_DuringOpenQuantum_CompleteAbortsAfterPredictionInvalidated opens a real quantum, runs the arm, and asserts Complete returns false with the committed pose intact. The rewritten SyncPresentation_ReentrantGuidReuseNeverTouchesTheReplacement is an improvement, not a dilution: it correctly notes that RebucketLiveEntity self-suppresses its own guid's visibility callback and switches to a genuine spatial edge. But the malformed-payload retirement in MalformedFreshUpdates_DoNotPoisonCanonicalBodyOrPose cites a successor test in LiveEntityNetworkUpdateController that does not exist (A5). The upstream gate does cover the scenario; the citation does not.

Claim 3 — OwnsPlacement_FalseWhenOperationKindIsNotRemoteAuthoritative legitimately changed its expected outcome. TRUE, not a test bent to fit the code. The widening makes ProjectileAuthoritative a positively-owned kind by construction, so leaving it in a "these kinds are refused" list would assert the opposite of the design. The positive case is separately and explicitly asserted (OwnsPlacement_TrueForProjectileAuthoritative_…, including the Create exclusion), and the two remaining negatives (InitialLogin, LocalAuthoritative) still pin the predicate's kind dimension. The rename is accurate.

Claim 4 — the new tests use airborne destinations to remove a contact-response confound. Legitimate confound removal, with a named residual. The claim is accurate: the shared placement pipeline's contact response is retail landing behaviour, shared verbatim with the remote arms, and outside route 5's scope; D-P5's pin is specifically "no velocity from the packet", which an airborne destination isolates cleanly. It is not a test dodging a defect. The residual worth stating: no test now places a projectile into ground contact at all, so the interaction between the projectile arm and contact response — including whether the resulting velocity change is the right one for a ballistic body — is entirely unexercised. That is a gap, not a dishonesty.

---

Judgment on the known scoping gap (§7 item 8, the dual-kind OnPosition matrix)

It is a FAIL-level gap. Definite answer: not acceptable.

The implementer's two arguments are (a) the collapse's LiveEntityNetworkOnPositionCollapseMatrixTests fixture unconditionally constructs a RemoteMotion a projectile lacks, and (b) the D-P6 dispatch is ~35 lines of thin glue between two well-tested layers.

(a) is a fixture limitation, and a fixture limitation is a reason to extend the fixture, not to ship zero coverage. The projectile half of the matrix needs a record with the Missile bit, a bound projectile, and no RemoteMotion — which is precisely the assertion the matrix exists to make.

(b) is refuted by this diff itself. Two of the five MAJORs above (A1, A2) are defects inside those 35 lines, and neither is visible from either well-tested layer: A1 is an App/Runtime disagreement about which outcomes may write presentation, and A2 is a discriminator whose reachable set is wider than the arm that consumes it. This is the same shape as 4b-3's three MAJORs — a mapping written against one caller's reachable set, and an invariant satisfied on one arm only — and a dual-kind matrix was the structural fix there for the same reason it is here.

Additionally, the gap is broader than §7 item 8 alone: item 9 (the App-level invalid-payload swallow) is also unwritten, and was cited as existing coverage in a retired assertion's justification.

The minimum this needs before landing: a dual-kind theory over OnPosition covering at least far-commit, teleport-commit, near, airborne, and null-classification, asserting on the projectile half that no RemoteMotion exists afterward, no generic wire-pose write occurred, and the render entity's position and ParentCellId agree with the resolved body — that last assertion alone would have caught A1.