# C4 route 4a — dual review findings, and a contract correction (2026-08-03) Both mandated reviews returned **FAIL**. Nothing is committed. This supersedes the 4a contract where they disagree, and **corrects an error in that contract that caused one of the findings.** Reviews: retail-conformance (Opus) and adversarial/architecture (Opus), run independently against the same uncommitted diff. Suite was green at 10,917/4/0, which again proves nothing. ## Verified correct — do not churn - The Runtime seam `RuntimeRemoteSteadyStatePosition.cs` itself: pure, stateless, correctly decomp-anchored, genuinely well tested. Both reviewers passed it standalone. - Retail truth re-verified independently: `MoveOrTeleport` @0x00516330 `arg4 == 0` -> `return 0` writing nothing; `player_distance < 96f` -> `InterpolateTo`; `ConstrainTo` @0x00454272 only inside `if (MoveOrTeleport(...) != 0)`, anchored post-move. - AP-87's two headline conditions survive with identical semantics and no bypass path. - `skipGenericPositionWrite` IS derived purely from classification (the staged- cutover discriminator condition is met). - Per-entity currency on the callee is sound; the caller re-validates `IsCurrentPositionAuthority` between classify and apply. - Budget respected: ~343 production lines against ~400. --- ## R0 — CRITICAL, and it is a defect in ALREADY-COMMITTED route 2 **`AcceptedPhysicsTimestamps.PreviousTeleport` is always 0 on the live Position path.** `InboundPhysicsStateController.cs:636` calls `Current(gate, teleportAdvanced: ...)` and omits the `previousTeleport` argument, which defaults to 0 (`:1119`). The ONLY site that populates it is `:926-941`, the deferred initial-create path — which is why the continuation executor is correct and every newer consumer is not. Verified first-hand. Two live consequences: **(a) Route 2, at HEAD, silently drops force corrections.** `LiveEntityNetworkUpdateController.cs:1199` and `RuntimeLiveEntitySessionController.cs:268` feed the always-zero value into the route-2 drive, where `ValidAcceptedAuthority` (classifier `:524-525`) requires `Previous == Accepted` for `ForcePosition`. For any local player whose TELEPORT_TS is nonzero — i.e. anyone who has portalled or recalled this session — the authority is rejected and the correction is dropped. The user's `@pklite` acceptance was genuine but narrow: that character had not teleported, so the stamp was still 0. **(b) Route 4a misclassifies every previously-teleported remote.** `TeleportAdvanced` becomes `IsNewer(0, T)`, true for any `T` in `[1, 0x7FFF]`, so the classifier returns `SetPosition` — a disposition 4a does not own — and (per R3) the entity falls into the far-snap arm and hard-snaps on EVERY packet at 5-10 Hz. That is worse than the pre-4a behaviour it replaced, and it is exactly the per-packet stepping the connected gate screens for. Reachable the first time an observed character portals or recalls, permanently thereafter. **Fix at the source**: capture `previousTeleport = gate.TeleportTimestamp` BEFORE `TryAcceptPositionEvent` mutates it, and pass it into `Current` — the shape `:926` already uses. Then audit every consumer. **Commit this separately and first.** It is a shipped-code defect independent of 4a, and it needs its own bisectable commit and its own issue. --- ## R1 — HIGH — my contract was wrong: the rebucket must NOT be deleted The 4a contract listed `RebucketLiveEntity` among the generic-tail writes to delete, and said the result "must reach the render entity through the existing placement-projection sink instead." **That instruction was copied from route 2 and does not transfer.** Route 2 performs a placement and therefore has a committed receipt to project. 4a's two branches perform NO placement, so there is no receipt and nothing substitutes for the bucket transaction. The implementer followed the contract precisely; the contract was wrong. `skipGenericPositionWrite` currently also gates `_liveEntities.RebucketLiveEntity` (`:1400`), which is the ONLY site that moves an ordinary moving remote's spatial bucket (the nine other call sites are player, projectile, teleport, hydration, materialization, equipped-child and rescue paths; the per-tick DR writers deliberately do not rebucket — see `LiveEntityRuntime.cs:856-858`). So for every grounded remote inside 96 m none of these runs again: the GPU draw bucket, `IsSpatiallyVisible` + `RefreshPresentation`, `CommitRebucket` (the canonical `FullCellId`), the `prepare_to_enter_world` clock rebase, and `PublishProjectionVisibilityChanged`. Failure: a creature chasing you across a landblock boundary keeps its body and collision shadow but leaves its draw bucket behind, is frustum-culled, and goes **invisible-but-solid** — the #184 class AP-87 exists to prevent, through a different door. Secondary: the stale `FullCellId` feeds back as the classifier's own `CommittedCellId` and as the `ConstraintDistance` cell key. **Required: keep the rebucket running for both 4a classifications.** Delete only the three render-pose writes. Also note R12 below: the per-UP rebucket doubles as the pending-bucket promotion recovery (`GpuWorldState.cs:1113-1126`, the 2026-07-03 invisible-player fix) — the cell-change-gated canonical commit does not cover it. --- ## R2 — HIGH — the App acceptance tests are tautologies `LiveEntityNetworkRemoteSteadyStateIntegrationTests.cs:75-86` recomputes `skipGenericPositionWrite` in the test body, asserts it true, then places the mutation inside `if (!skipGenericPositionWrite)` — a branch the preceding assert proves unreachable. The second test writes the tail sync itself and then asserts its own arithmetic. **Both pass unchanged with the production file reverted to HEAD**, and the fixture supplies a correct `Previous/Accepted` teleport pair that production never produces, so the suite is structurally incapable of catching R0(b). This is #292 again, in a WEAKER form than route 2's: a source-text pin at least fails when the source changes; this never observes production at all. The contract's acceptance bullet said "behavioural, not a source-text pin… do not repeat it." **Required: a test that fails if the generic tail double-writes a remote.** If `LiveEntityNetworkUpdateController` genuinely cannot be constructed, then extract the decision+mutation into something that CAN be tested and have production call it — do not simulate production in the test body. --- ## R3 — HIGH — "not Interpolate" is treated as "far", mis-owning five dispositions Player `:1723-1740`, NPC `:1867-1888` use `if (Interpolate) … else `. The `else` also swallows `SetPosition` (cell-less half — `remotePlacementRequired` covers only the teleport half), `RejectedAuthority`, `RejectedData`, and `null`. So a wire quaternion failing validation, or a cell-less remote, now hard-snaps every packet where the legacy code did distance-based routing — a behaviour change to branches contract item 7 forbids touching. `ClassifyRemoteAcceptedPosition`'s own doc comment (`:47-50`) claims null leaves the legacy path "completely unchanged"; that is false. **Required: test explicitly for the two dispositions 4a owns. Everything else falls through to untouched legacy routing.** One classification, one owner. --- ## R4 — HIGH — the NPC airborne branch still writes cell, render entity and shadow Contract item 5 says the airborne branch writes NOTHING. The player arm complies (`:1624-1628` returns). The NPC arm only skips the snap and falls through to `rmState.CellId = p.LandblockId` (`:1931` — which commits the canonical cell via `RemoteMotion.cs:169-177` and can rebucket), `LastServerPos/Time`, `RemoteServerControlledVelocityCycle.Apply` (an animation decision from an airborne packet), the `entity.SetPosition`/`ParentCellId`/`Rotation` tail (`:1976-1978`), and `LiveEntityShadowPublisher.TryPublishRemote` (`:1979`). Worse than before *because* the body no longer moves: previously body, cell, entity and shadow all agreed; now the body stays put while the cell jumps to the server's and the shadow publishes against a cell that need not contain it. (Contract-precision note: `:1616` writes `rmState.CellId` before the PLAYER return too. That is pre-existing free-fall bookkeeping the contract's "not the cell" wording did not intend to forbid — decide deliberately and record it, rather than leaving the contract and the code silently disagreeing.) --- ## R5 — MEDIUM — `ConstrainTo` lost on the player-remote landing packet The deleted unconditional arm sat before `if (IsPlayerGuid(...))`, so it ran for the landing transition. The new arm at `:1747-1752` is after the landing block's return at `:1710`. A landing UP is a grounded near correction where retail's `MoveOrTeleport` returns nonzero, so retail DOES arm the leash. Behaviour loss on a path 4a was to leave alone. Also: when the route is null or `Rejected*`, `ConstrainAfterRouting` is false so the leash never re-arms, yet the `else` arm still hard-snaps — a hard move with a stale anchor. --- ## R6 — MEDIUM — AP-87 and TS-44 changed silently; both register rows now misdescribe the code **AP-87:** the NPC variant's third condition `firstUpNpc` (`LastServerPosTime <= 0`) was dropped with no replacement, and the updated row still describes it as a "belt hint". Low blast radius (a UP-created `RemoteMotion` is seeded so `bodyToTarget == 0`), but the contract demanded the choice be stated, and the original code carried an explicit comment about why `LastServerPosTime` is unreliable. **TS-44:** the sticky check moved inside `ApplyInterpolate`, which BOTH kinds call, so it now suppresses player-remote near corrections that previously had no sticky check at all (the old `snapSuppressedByStick` gate was structurally unreachable for players). Player remotes are stickable (`LiveEntityMotionRuntimeController.cs:144-145`, `:342-352`). The updated row still says "NPC UpdatePosition enqueue is suppressed" and calls the App gate an "NPC-only caller gate" — both now false. The player arm is also internally inconsistent: near is suppressed, far is not. **Required: decide each deliberately, and make the rows true.** --- ## R7 — MEDIUM — contract items 1 and 2 are not met; this is a helper extraction, not an ownership transfer The Runtime "owner" is two stateless statics. App still owns request assembly (`ClassifyRemoteAcceptedPosition` is private to the App controller), branch selection, the airborne early return, the cell write, the entity write, and the shadow publish. No second host can reuse any of it. The headless claim is factually true (`RuntimeLiveEntitySessionController.cs:212-216` returns early for remotes, so nothing diverges) but it satisfies item 2 by redefinition. Note Runtime ALREADY builds this exact request in `RuntimeInitialCreateContinuationExecutor.ApplyPositionAction:1907-1945`. The new App builder is a third copy of the same construction — which is precisely how R0 and R8 diverged from it. **Prefer sharing that builder over maintaining a third copy.** --- ## R8 — MEDIUM-LOW — the request builder fabricates `Vector3.Zero`, violating a documented invariant `:75-77` uses `_playerController?.Position ?? Vector3.Zero`. `GameRuntime.cs:288-290` states the rule for this exact field: a null controller "must yield null, never a fabricated Vector3.Zero that would misclassify every remote entity as implausibly far." `RuntimeInitialCreateContinuationExecutor.ResolveInputs:510-521` honours it. The new builder does the opposite. --- ## R9 — LOW-MEDIUM — the new generation plumbing is decorative `RuntimeEntityObjectLifetime.CurrentGeneration()` and `LiveEntityRuntime.Generation` return the lifetime's CURRENT generation, not the classified record's. The classifier only tests `Generation.Value != 0`, never compares it — so the token cannot detect a generation change, and the currency it claims to add is supplied entirely by the surrounding `IsCurrentPositionAuthority` checks. Two new public members for a non-zero placeholder. Also `_generation` is assigned in `BindEventContext` but never cleared in `Dispose`, unlike its siblings. Either make it load-bearing or drop it. --- ## R10 — LOW — residue - **R11:** `ApplyInterpolate`'s return value is discarded at both call sites, and the NPC caller still wraps it in its own `if (!snapSuppressedByStick)` — duplicating the check that moved into the seam. - **R12:** the deleted per-UP rebucket also lost the pending-bucket promotion recovery (`GpuWorldState.cs:1113-1126`, the 2026-07-03 invisible-player fix). Covered by fixing R1, but note it explicitly. - **R13:** HTML entity escapes leaked into plain `//` comments (`>=96 m`) at `:1718`, `:1735`, `:1864`, `:1883`. - **R14:** `preSnapPos` (`:1394`) assigned, never read, with a comment describing behaviour that no longer exists. --- ## R15 — live-gate addition, not a code defect D1 makes ACE's wire `IsGrounded` newly load-bearing for NPC remotes. ACE emits it from `TransientState & OnWalkable` (`PositionPack.cs:73`), while acdream's NPC free-fall is gated on the client-tracked `rmState.Airborne`, set only by `0xF74E` VectorUpdate or `!Body.OnWalkable` — never from the wire bit. A creature ACE reports as not-in-contact while the client believes it grounded now receives NO correction where the legacy routing pulled it. **Add to the connected gate: push a monster off a ledge / pull one down a cliff.** --- ## Gate Complete Release suite, not a subset. Pre-4a baseline is 10,909/4/0. R2 means the current green number is not evidence for the thing it claims to test.