# C4 route 4b-2 — dual review FAIL + the pinned correction (2026-08-04)

Both mandated Opus reviews returned **FAIL**. Nothing is committed as final; the
work sits at WIP `dfd27896`.

Review A (retail faithfulness + deletions) confirmed **every retail citation**
independently, including the x87 parity decode proving exactly 96.0 takes the
FAR branch. The deletions are complete and exact, the "Do NOT touch" list was
respected, AP-87 was neither carried onto the far branch nor deleted from the
near branch, and the two-site `ConstrainTo` partition is exhaustive and disjoint.
Review B confirmed the `worldPos` decoy genuinely discriminates, both test
removals are real replacements rather than drops, and `OwnsFarSnap` is exact
against every classifier emission site. **Do not churn any of that.**

## The one root defect — everything else is downstream

**A refused / contended / rejected far snap leaves the remote frozen with an
emptied interpolation queue.**

`ApplyRemoteContactRouting` discards the status
(`LiveEntityNetworkUpdateController.cs:1002`, `_ = placementDrive.…`), while
`Interp.Clear()` has already run unconditionally on the route flag
(`RuntimeRemotePlacementDriveController.cs:485-487`). Three of five outcomes
move nothing: `Refused` (`:405`, `:624`), `Contention` (`:414`, `:588`),
`Rejected` (`:592`, `:630`). The body keeps its stale pose, the queue is empty,
and the next 5-10 Hz packet reproduces the state.

**Reachable, not theoretical.** The graphical service window is
`GpuWorldState.IsNearTier` — collision-published *right now*
(`GraphicalRemotePlacementServiceWindow.cs:89-90`) — with default near radius 4
(`GameWindow.cs:145`). A remote that is rendered but still streaming is refused
while genuinely beyond 96 m. `RetrySetupUnavailable` is reachable for any remote
whose prepared Setup collision has not resolved.

**Retail never does this.** The far branch always calls `SetPositionSimple`
@0x005163D9, and even when `SetPositionInternal` finds no cell it still commits
the destination pose — `store_position` @0x00515CE2, then
`GotoLostCell` @0x00515CF2 and `reenter_visibility` on cell arrival. That is the
finding AP-136 is built on. The deleted legacy block also always tracked. **The
shipped state is strictly further from retail than either.**

### Both reviewers' second MAJOR collapses into this one

Review B rated the `TryAdoptWireCellAfterRouting` arm-asymmetry MAJOR, arguing a
refused player far snap leaves `record.FullCellId` a landblock away from the
body and that `rmState.CellId` seeds the per-tick sweep — the #184
invisible-but-solid producer.

Review A found the same asymmetry and rated it MINOR with the mechanism:
`RebucketLiveEntity(update.Guid, p.LandblockId)` at `:1592` has **already**
committed the wire full cell to canonical
(`LiveEntityRuntime.cs:895-909`), and `RemoteMotion.CellId` reads through to
`record.FullCellId` for every bound remote (`RemoteMotion.cs:169-176` +
`RuntimePhysicsState.cs:965-984`). **Review A is right on the mechanism.** The
suppressed write is a no-op on refusal.

**Resolution: the cell/body divergence is real but is caused by the frozen body,
not by the suppression.** Fix the freeze and it disappears. Do not restructure
the suppression to chase it.

## The correction — pinned, not open for redesign

**On every non-commit outcome the far arm must still advance the body to the
accepted destination pose.** That is retail's `store_position`, and it restores
the tracking the deleted legacy block had.

Constraints on the fix:

- The status must stop being discarded at `:1002`.
- The service window stays an **optimisation**, not a correctness mechanism —
  4b-1's review already ordered that framing corrected and it shipped
  uncorrected. Do not delete it; do not let it be the reason a remote stops
  tracking.
- Do **not** add a timer, retry, settle window, or suppression flag. The
  fallback is a pose write because retail writes the pose, not because it makes
  a symptom go away.
- `LiveEntityNetworkRemoteFarSnapIntegrationTests.cs:120-147` currently
  **pins the freeze as correct** (`Assert.Equal(before, body.Position)`). It
  must be inverted, not deleted quietly.

## Also required

**R1 — AP-137's justification is factually wrong (review A M2).** The row claims
the deleted `_playerController?.Position ?? Vector3.Zero` distance had "no
relationship to `player_distance`". It was streaming-origin-relative
(`LiveEntityNetworkUpdateController.cs:1360-1366`) and the streaming origin
recentres on the player's landblock — a biased but genuinely correlated proxy,
error bounded by roughly one landblock. The policy may still be right; the
stated reason is not true. Rewrite it to say what the deleted test actually
computed.

**R2 — AP-137 must state the cell-less delta (review A M3).** Retail routes a
cell-less body through @0x00516386 → `SetPosition` @0x00516420, an
**unconditional placement** sitting *before* the contact test. 4b-2 routes that
classification into `ApplyInterpolate`, which **enqueues** whenever
`!firstUp && willBeDrTicked && bodyToTarget <= 4 m`. For a cell-less remote
already tracking, acdream now queues where retail places — at *any* distance,
not only >=96 m. State it. If it should instead place, say so and change it.

**R3 — AP-137 must state that `RejectedData` is applied anyway.** It is the one
classification meaning "this payload failed validation"
(`classifier.cs:535-547`), and `UnroutedCatchUp` hands the same payload to
`ApplyInterpolate`. Not a regression — the legacy block did the same — but the
slice's stated purpose was an explicit handler, and the row omits it.

**R4 — a register row for the refusable far placement.** `grep` for
"Refused|service window" in the register returns zero. 4b-1 was dormant and owed
nothing; **4b-2 is the commit that makes it live and therefore owes the row**
(CLAUDE.md register rule 1). Whatever residual divergence survives the fix above
gets measured against retail's `store_position`/`GotoLostCell` behaviour.

**R5 — the two arms' guard/arm ordering must be identical (review A M4).**

| arm | routing | re-entrancy guard | post-op arm |
|---|---|---|---|
| player | `:2020` | `:2047-2054` (`return`) | `:2037` — **before** the guard |
| NPC | `:2202` | `:2214-2221` (`return`) | `:2235` — **after** the guard |

The NPC arm therefore arms `ConstrainTo` **zero** times on a superseded
incarnation, where retail arms unconditionally on the nonzero return
@0x00454254/@0x00454272. The player arm arms the leash on a possibly-superseded
`rmState.Host`. This also contradicts the diff's own new remarks at `:958-966`
("MUST re-validate … before writing anything else for the packet") — the player
arm writes the leash first.

**R6 — six comments the change falsifies** (review A m6; review B found the same
class independently as N6). This is the **fifth** consecutive slice shipping
stale comments asserting behaviour the code no longer has:
`LiveEntityNetworkUpdateController.cs:835`, `:868`, `:1589-1591`, `:2076-2081`;
`RuntimeEntityObjectLifetime.cs:600-605`; and
`RuntimeRemotePlacementDriveController.cs:106-143`, which still headlines "The
central decision — refuse, do not park" and asserts a cancelled park leaves the
entity invisible and intangible for the session — falsified at HEAD by the park
restore **this same class's** `CancelToken` uses (`:698-703`). 4b-1's review
already ordered that one corrected.

**R7 — three tests assert less than their names claim (review B N2/N3).**
- `NoClassificationAtAll_NearAndTicked_EnqueuesInsteadOfSnapping`
  (`:191-213`) never inspects `remote.Interp`. A regression to "snap when
  `bodyToTarget > 4 m`, else do nothing" passes it *and* its sibling. One
  `Assert.True(remote.Interp.IsActive)` closes it.
- The `StopInterpolating` ordering test (`RuntimeRemotePlacementDriveControllerTests.cs:830-871`)
  proves the clear is unconditional, not that it precedes the placement. Its doc
  comment claims proof it does not have. Either pin the order or state plainly
  that it is unobservable in acdream.

**R8 — the `DeferredCell` park branch has zero coverage (review B N5).** The
opt-in chain is correct by reading (`:623` → `:698-703` →
`RuntimeSetPositionState.CancelCore` → `RestoreParkWithdrawal`), but no test in
4b-1 or 4b-2 exercises it, and the far arm is the first production path that can
provoke a park. Add the test: commit the destination collision generation, open
a `CollisionPrefixQuiescence` on the destination prefix, far-snap, then assert
`body.InWorld && record.ObjectClock.IsActive && record.FullCellId != 0`.

**R9 — currency across GUID reuse / incarnation / generation is undelivered
(review B N4).** Contract item 7 named five dimensions; two shipped
(interleaving, teardown). `_pending` and `_awaitingAcknowledgement` are keyed by
`RuntimeEntityKey` (guid+incarnation), so a reused GUID makes a *new* key and the
old entry self-heals only on a ledger read (`:670-688`) or in `Advance()`
(`:513-525`), which early-returns unless something is pending. Dead-incarnation
entries accumulate until `DetachRoute`. Converges at teardown; does **not**
converge in-session. Add the test: far-snap `G` at incarnation 1, retire it,
re-create `G` at incarnation 2, assert `RemotePlacementDrivePendingCount == 0`
**without** a teardown.

**R10 — `AirborneNoOperation` falls into `default:`** (review A m7). Unreachable
today — both callers early-return (`:1876-1881`, `:2130-2136`) — but the
`default:` comment asserts unreachability where an explicit case enforces it.

## Not blocking, recorded

- **n8**: `OwnsFarSnap` also matches the classifier's FORCE_POSITION shape
  (`classifier.cs:329-345`), unreachable for remotes via `ValidAcceptedAuthority`
  (`:522-525`) and `PhysicsTimestampGate` (`:190`). Defense-in-depth; note only.
- **NOT VERIFIED, carried**: what `SetPositionInternal` @0x00515330 does with the
  0x1000 (`SendPositionEvent`) bit, which reaches
  `TryPrepareAndSubmitAuthoredPlacement` for the far snap while the controller
  doc argues acdream has "no ack" for remotes. Those are two different things
  (the `SetPositionStruct` flag vs `CommandInterpreter::SendPositionEvent`
  @0x00454091); 4b-1's review cleared only the latter. Settle with a read of
  @0x00515330-@0x00515543.
- **Process**: `ParkCollisionResidents_StaysUnreachable_AfterRefusalAndAfterCommit`
  (`RuntimeRemotePlacementDriveControllerTests.cs:782`) still calls the method
  directly at `:824` — the shape 4b-1's finding B2 declared void. It shipped at
  `2e8e09ac`, so it is outside this diff, but it is in the tree being counted as
  evidence.
- **Headless (contract item 6) is satisfied vacuously.** Nothing in headless
  constructs the drive controller and `RuntimeLiveEntitySessionController.OnPositionUpdated`
  returns early for every non-local GUID (`:212-217`). The contract allowed this
  only if stated plainly; AP-137 does not mention headless, and
  `IRuntimeRemotePlacementServiceWindow`'s doc still describes the headless
  implementation as a live consumer. State it.

## Gate

Complete Release suite, not a subset. **Corrected baseline: 10,968 / 4 / 0** at
`1b631f12`, measured independently in a throwaway worktree (App 4088, Runtime
1073). The 10,973 figure in the 4b-2 contract was wrong and propagated from an
earlier mis-record — an inflated baseline is exactly what would let a future
slice delete tests and still look green. The WIP state measured 10,990 / 4 / 0
while containing the freeze defect above.

Two known flakes, do not chase and do NOT conflate: **#302**
(`PortalProjectionTests…`, GC-allocation assertion, App.Tests) and **#308**
(`NakEmissionTests.LossSoak_…`, wall-clock deadline, Core.Net.Tests, full-suite
load only).