acdream/docs/research/2026-08-04-c4-route-4b-1-review-findings.md

C4 route 4b-1 — dual review FAIL, and a design correction (2026-08-04)

Both mandated reviews returned FAIL. Nothing is committed. This supersedes the 4b-1 contract, whose central premise was factually wrong.

The premise error — mine

The contract justified refuse-rather-than-park with: "retail's world is fully resident, so 'arrived but not placeable' is unrepresentable there."

False. Retail represents it explicitly, with a working park:

• CPhysicsObj::SetPositionInternal @0x00515BD0 — when AdjustPosition yields no cell (@0x00515C1D): prepare_to_leave_visibility @0x00515CDA, store_position @0x00515CE2 (the destination pose IS committed), CObjectMaint::GotoLostCell @0x00515CF2, clear transient 0x80 @0x00515CF7, return OK_SPE @0x00515D07.
• CObjectMaint::GotoLostCell @0x00508210 appends the object to that cell's lost list.
• CObjectMaint::InitObjCell @0x00508260 drains the list on cell load and calls reenter_visibility per object @0x00508296.
• MoveOrTeleport discards the SetPositionError from both SetPosition @0x00516420 and SetPositionSimple @0x005163D9 and returns 1 regardless, so ConstrainTo @0x00454272 is armed even when the placement failed.

Retail's reaction to an unplaceable remote: advance the pose, hide the object, register it lost, wake it on cell arrival, arm the leash anyway. Our refusal leaves the remote visible at a stale pose. For a remote that teleports into a non-resident landblock and then stops moving — ACE stops broadcasting for a stationary entity — "the next packet is the retry" never arrives and the divergence is permanent.

Refuse cannot be made complete — the second reason to abandon it

The guard checks ONE landblock (accepted.LandblockId). Core defers on at least four independent conditions:

1. PlacementTouchesPrefix matches the entity's CURRENT cell, not only the destination (RuntimeSetPositionState.cs:3668-3673, consumed :2916). A remote standing in a quiescing landblock, moving to a perfectly published destination, parks. That is the contract's own producing sequence with ordinary streaming churn behind it.
2. ResultTouchesPrefix matches every cell in QueriedCellIds (:3675-3690, consumed :2981) — the sweep footprint spans neighbouring landblocks near a boundary, so a quiescing NEIGHBOUR parks a fine placement.
3. Engine-level non-residency after AdjustToOutside (PhysicsEngine.cs:1309-1318, :1464-1475) — the adjusted cell can land in an adjacent landblock, evaluated against THAT landblock. Not visible to any pre-flight caller.
4. Headless, where the predicate is weaker still (see below).

A pre-flight guard cannot close conditions that only Core can see. Refuse is structurally incapable of being complete.

The actual root cause — and it is shipped, not new

ParkDeferred (RuntimeSetPositionState.cs:4088-4120) withdraws the entity: body.InWorld = false, Active cleared, WithdrawCanonical (→ RemoveSpatialProjection + SetFullCell(record, 0u, 0u)), SuspendObjectClock.

CancelCoreDeferred (:5131-5198) removes the operation, rewrites Withdraw→Discard, and restores none of it. The only InWorld = true in the file is the local-player dormant-activation commit (:2591).

So cancelling a wakeable park is strictly worse than retaining one: the park is at least wakeable; the cancel destroys the only object that could wake it.

This affects route 2's DeferredCell path too. Route 2 compensates with its re-issue funnel — which is correct for a one-shot ForcePosition and wrong for a 5-10 Hz remote stream. So the underlying defect has been masked, not fixed.

Corrected direction for the next round

Make the park work, at the source, modelled on retail's lost-cell. A cancellation of a wakeable park must restore what ParkDeferred withdrew — InWorld, the object clock, and canonical residency — or the park must survive the merge-time Forget so its collision-generation wake can still fire.

The 4b-1 contract said a withdrawal-restore inside RuntimeSetPositionState required STOP-and-report. That stop has now happened and this is the answer: refuse is structurally incomplete, retail has a working park, and the restore fixes route 2's latent path as well. Proceed with it deliberately.

The service-window guard still has value as an OPTIMISATION — avoiding parks we can cheaply predict — but it is no longer the correctness mechanism and must not be presented as one.

Whatever residual divergence remains after this needs a docs/architecture/retail-divergence-register.md row measured against retail's GotoLostCell/reenter_visibility behaviour, not against a "retail-shaped" label.

The other blocking findings

B1 — the headless predicate is not a service window. HeadlessSessionWorldProjection.cs:254-266 is a pure 3x3 Chebyshev GEOMETRY test against _requestedCenterLandblock, and returns true outright when no centre has been requested. Its own pre-existing doc says "can EVER collision-publish". The new interface promises "currently published". Signature match, predicate mismatch — the same over-permissiveness the graphical adapter explicitly rejected IsNearTierOrPending for. IsReady (:268-285) is the correct shape and sits fourteen lines below. Remove the "same question" claim.

B2 — the ParkCollisionResidents evidence is void, and the real hazard is a different one. The delivered test demonstrates the two states that were already safe and calls ParkCollisionResidents DIRECTLY, bypassing TryAcquireCollisionPrefixMutationPermission's HasOldPrefixPlacementDebt check (:3641-3666, consumed :887) — which is the thing that actually makes the throw unreachable. The genuine hazard is not a throw but an indefinite streaming stall: that predicate refuses permission on every poll while a retained retry is held, so the landblock never retires. RetrySetupUnavailable on an asset that never loads makes it permanent, and DetachRoute clears _pending WITHOUT cancelling the operation, orphaning it until session reset while it continues to pin the prefix.

B3 — Advance() re-submits with no service-window re-check (:298-332, SubmitAndResolve :334-394). A retained entry can sit across many frames while its destination retires.

B4 — Committed leaves an untracked live operation. It returns and retains nothing while the operation sits at AwaitingCommitAcknowledgement, retired only by AcknowledgeProjection. RemotePlacementDrivePendingCount cannot see it, so the ledger is blind to exactly the class that produces B2's stall.

B5 — N3's actual fix is untested. HeadlessSessionHost.cs:328 has zero coverage; the new test hand-builds the route and never touches Tick. Also: per-tick RetryPendingProjections() does _pendingProjection.Values.ToArray(), a new per-tick allocation K4's 30-session envelope was measured without; and headless dereferences the route directly with no generation latch, where graphical goes through RuntimePlacementProjectionRetrySlot which refuses a stale-generation callback.

B6 — OwnsPlacement keys on Disposition alone (:189-191). The classifier also emits SetPositionSimple for the local player's FORCE_POSITION and teleport branches, and SetPosition for every initial Create. record and route are separate parameters, so a mismatched pair is expressible. One route.OperationKind is RemoteAuthoritative guard makes ownership exact.

B7 — three comments cite a "route 4b-1 report" that does not exist (GraphicalRemotePlacementServiceWindow.cs:57, RuntimeRemotePlacementDriveController.cs:122, and the test file :28). Two of them point at precisely the evidence the contract demanded.

B8 — advisory for 4b-2/4b-3: retail arms ConstrainTo even when the placement failed, so the successors must arm on refusal/rejection too, not only on commit. "Arm on Committed" is the natural misreading and is the same shape as the already-recorded unarmed-leash bug.

Verified correct — do not churn

• Both omissions are right: SendPositionEvent is local-player-FORCE-only (@0x00454091 inside the @0x0045400C gate); the remote arm @0x0045414D has no equivalent, and retail never re-attempts — stale timestamps just bump error_count @0x004542AC.
• The disposition mapping is exact for Remote-kind routes: SetPosition ≡ teleport-or-cell-less (@0x00516386, flags 0x1012), SetPositionSimple ≡ far snap (@0x005163C1-E8).
• The graphical co-extensivity argument holds in both directions, independently verified by both reviewers. IsNearTier over IsNearTierOrPending is right.
• Contract item 2 holds: no production caller, no behaviour change, ledger member always 0 in production.
• The "Do NOT touch" list was respected — AP-135's writes, the teleport classes, the legacy far halves, the single ConstrainTo site, route 1's executor.
• Per-entity mechanics are otherwise sound: incarnation-keyed identity, self-heal, _driveScratch snapshotting, _driving re-entry guard.
• N3's ordering matches the graphical route.

Gate

Complete Release suite, not a subset. Baseline 10,938 / 4 / 0; the 4b-1 state measured 10,955 / 4 / 0 while being defective. 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).