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

C4 route 5 — architecture / adversarial DELTA review, round 3 (2026-08-04)

Verdict: FAIL — one finding (C1), coverage-only, no identified defect.

Every behavioural finding from rounds 1 and 2 is now closed and independently verified. The single remaining item is that the Advance() retry arm's projectile branch — added in round 2 (R3) and semantically modified in round 3 (B5, a prediction-invalidation reordering) — is executed by no test at any layer. I traced the reordering and believe it is safe; but "safe by reading" is the standard this project rejects, and it is the standard I applied to the implementer twice (A4, A5). The templates to close it are already in the same file. The bar for round 4 is one test.

Gates run for this review: dotnet build AcDream.slnx -c Release --no-incremental — 0 errors, 21 warnings, all pre-existing and none in any route-5 file (they are in AcDream.App.Tests/Composition, AcDream.Core.Tests nullability and xUnit-analyzer nits; my earlier "0 warnings" readings were incremental builds that skipped those projects — no regression). Focused Runtime suites 59/59; focused App suites including UpdateFrameOrchestratorTests 94/94.

---

1. Finding

C1 — the Advance() retry arm's projectile branch has never been executed by a test, and round 3 changed its prediction-invalidation semantics

Severity: MAJOR (coverage). No defect identified — the code reads correct.

RuntimeRemotePlacementDriveController.Advance:1221-1305 contains the R3 projectile branch (kind/identity re-validation, pendingWasInWorld capture, prediction invalidation, SyncProjectilePresentation) and the B5 reordering. All six drive.Advance() call sites in RuntimeRemotePlacementDriveControllerTests.cs (:533, :549, :592, :1015, :1021, :1755) belong to remote-kind tests. No test parks a ProjectileAuthoritative retry and pumps Advance().

What is therefore unexercised:

• prediction invalidation on a retried projectile placement (trap T3 — a straddling quantum clobbering a committed placement is exactly what this guards);
• the B5 semantic change: invalidation skipped when SubmitAndResolve returns Contention;
• SyncProjectilePresentation on the retry arm (invariant 2 on a second call site);
• the stale-route guard (pending.Route.OperationKind + body/component re-validation) that exists precisely because a retry can outlive its binding.

The R3 comment states the intent plainly — "Neither invariant this route pins … may hold on the direct arm only" — and both invariants are, in fact, asserted only on the direct arm.

Reachability: _pending receives a projectile entry whenever SubmitAndResolve returns a retryable preparation status (RetrySetupUnavailable/RetryWorldFrameUnavailable) for a ProjectileAuthoritative route — an ordinary streaming-edge condition — and Advance() is the host cadence pump. Standing caveat: like the whole route, ACE-unreachable in play.

Fix direction (cheap — both templates are in the same file): rebuild FarSnap_RetryablePreparation_StoresThePoseAndStillRetainsTheRetry (:985) and Advance_DestinationLeavesTheWindow_StoresTheNewestDestinationPose (:1707) against CreateProjectileRecord + a ProjectileAuthoritative route — the same borrowing the projectile ledger test already did from Teleport_LedgerConverges_…. Assert, on the retry: the pose advanced, the prediction version moved on the storing outcomes and did not move on a re-parked Contention, and the shadow row followed the body.

---

2. The B5 reordering — safety verified

Asked to scrutinise this specifically. It is safe, and for a reason stronger than the comment's "single-threaded and synchronous".

The invalidation exists solely so a straddling quantum aborts at Complete. PredictionAuthorityVersion has exactly four consumers, enumerated across src/: RuntimeProjectilePhysicsUpdater.TryBegin/Complete/IsIdentityCurrent, RuntimePhysicsState.CommitProjectileCell's IsExactOwner, and ProjectileController.IsCurrentQuantumIdentity (:837). The only callers of CompleteQuantum are ProjectileController.AdvanceQuantum (:760) and LiveEntityAnimationScheduler (:419) — both frame-loop driven. Nothing in the placement pipeline's synchronous publish chain (placement projection sink, RebucketLiveEntity's visibility callbacks, collision-report observers) can reach either. Notably, the one projection callback that does re-enter the projectile controller — OnProjectionVisibilityChanged → TryBind — returns early on a retained runtime and never touches a quantum. So no Complete can interleave between the write inside SubmitAndResolve and the invalidate on the next statement.

The skip on Contention is also correct: Contention from SubmitAndResolve means preparation returned a retryable status, so PhysicsEngine.SetPosition never ran and nothing wrote the body — verified by walking TryPrepareAndSubmitAuthoredPlacement's non-Prepared path, which touches only operation.* fields and reads (body.InContact/OnWalkable), never the body's pose.

Two ordering details I checked and found sound: the Refused branch still invalidates before StoreAcceptedDestinationPose (the one body write on that arm); and CancelToken's synchronous cancellation receipt — which the class doc warns can delete or replace the incarnation — is harmless here because pendingProjectile is a captured strong reference (invalidating a displaced component is inert, and a displaced component's quantum already fails IsIdentityCurrent's ReferenceEquals(record.Projectile, projectile)), while both StoreAcceptedDestinationPose and SyncProjectilePresentation re-validate currency at entry.

Honest note on the invariant's status: contract §5 item 4 says invalidation is "before the write". On this arm it is now after, resting on a reachability argument rather than structural ordering. The argument holds today; it is recorded here so a future change that lets a projection callback drive a quantum knows it broke something. The comment states the reasoning openly, which is the right handling.

---

3. The indoor staging in the B2 regression test — legitimate, and it corrects my round-2 finding

Judgment: the staging is legitimate, the test genuinely pins production behaviour, and the diagnosis behind it is correct.

I verified the mechanism at source. PhysicsBody.Position's setter (PhysicsBody.cs:153-162) calls SyncCellPositionDelta(delta) on every write, including StoreAcceptedDestinationPose's. That method (:287-308) has two branches:

• outdoor (low word 1..0x40): LandDefs.AdjustToOutside re-derives the cell index from the shifted local origin and bumps the landblock on a 192 m crossing — so after a store to a cross-landblock destination the body's own cell id self-corrects to the destination cell;
• indoor (low word outside that range — an EnvCell id): the local origin shifts but the cell id is kept verbatim, so it stays pinned at the source EnvCell.

So the implementer's finding is right, and it corrects my round-2 B2: the defect I reported was real but its blast radius was narrower than I stated. My stated scenario ("a missile crosses a landblock boundary at the streaming edge") is an outdoor case, which self-heals through AdjustToOutside; the genuinely divergent case is a body in an EnvCell — a bolt fired inside a dungeon. That correction is recorded here rather than smoothed over.

The staging is not a fixture artefact: IndoorSourceCell = SourceLandblock | 0x0100 is a well-formed EnvCell id (the first EnvCell index), and SnapToCell seeds indoor claims verbatim by design (PhysicsBody.cs:190-205, "Indoor EnvCell claims (low word >= 0x100) … seeded verbatim"). The scenario — indoor body, outdoor wire destination, service window refuses — is production-reachable.

One asymmetry worth naming, which does not affect the pin: the test stages the indoor cell on the body while leaving record.FullCellId at the outdoor SourceCell, a pairing production would not produce. It is inert here because the merge overwrites record.FullCellId with the wire cell before the ack runs, so the pre-packet value is never read. The assertion depends only on the two expressions diverging, which they genuinely do.

Discrimination confirmed by construction: the test asserts body.CellPosition.ObjCellId == IndoorSourceCell (the divergence actually occurred) and then entity.ParentCellId == DestinationCell. Restoring round 1's body.CellPosition.ObjCellId read fails the second assertion.

---

4. Round-2 findings — disposition

#	status	verification
B1 (adopted-body far snap leaves Interp armed; AP-141 asserts the opposite)	CLOSED, well	The clear landed in the Runtime seam at ApplyAcceptedProjectilePosition's SetPositionSimple case, before the placement — matching retail's @0x005163CB-before-@0x005163D9 ordering — guarded on route.StopInterpolating && record.RemoteMotion is RemoteMotion, the exact shape ApplyAcceptedRemoteFarSnap ports. Correctly scoped to one action, not the full hook. MissileAdoptedBody_FarCommit_ClearsInterpQueueButLeavesConstraintArmed is discriminating in both directions: it pins the queue clear and pins that UnConstrain did not run, proving the fix did not over-apply the teleport hook to the far branch. AP-141 is now narrowed to "faithful ONLY for a BARE missile" and additionally names the surviving ConstrainTo re-anchor divergence for the adopted case — a more accurate row than before the finding.
B2 (ParentCellId regression)	CLOSED, well	Reverted to record.FullCellId; the A1 gate kept. The doc now carries three independent justifications, of which two I verified directly (the sibling remote arm pairs wire pose with wire cell; Runtime's own SyncProjectilePresentation publishes the shadow at record.FullCellId in the same call, so the body-cell read would have disagreed with the shadow for one body in one packet) and the third is retail's store_position @0x00515CE2 writing objcell_id. Regression-tested — see §3.
B3 (store path unasserted at both layers)	CLOSED at both layers	Runtime: Refused_StillAdvancesPoseNoParkPredictionInvalidated now asserts shadowEntry.Position == body.Position; on the Refused path nothing but SyncProjectilePresentation publishes the shadow, so it discriminates. App: MissileFarRefused_StorePathStillMovesEntityToDestinationParentCellIdAgreesWithWireCell asserts entity position and ParentCellId; deleting the ack leaves the entity at its spawn pose. What remains untested from B3's neighbourhood is only the A1 gate's own two statuses (Deferred/RejectedByPlacement), which round 2 already accepted as an unconstructible carve-out, and the retry arm (C1).
B4 (per-packet closure)	CLOSED, correctly	IsCurrentProjectilePositionOwner is now a third cached delegate inside RemoteArmCallbacks, bound to IsCurrentProjectileArmPositionOwner, reading _projectileArmPosition* scratch fields stamped immediately before use — byte-for-byte the same shape as the existing _remoteArmPosition* / IsCurrentRemoteArmPositionOwner pair (:92-93, :1467-1468, :1502-1506). Same reentrancy exposure as the incumbent #315 pattern, therefore parity rather than a new hazard. The UpdateFrameOrchestratorTests zero-Delegate-field guard holds — it ran green inside the 94/94 App suite, and the cache stayed inside the named type rather than becoming bare fields.
B5 (retry arm invalidating with no write)	CLOSED — see §2	Correct, and the safety of the reordering verified independently. Untested (C1).
Round-1 MINOR (c) (4a velocity comment with no retail basis)	FILED as #317	docs/ISSUES.md — accurate description, correct scoping rationale, and an acceptance criterion that names the actual work (audit the whole accepted-Position velocity chain, then cite or remove with a register row). Better handling than a silent comment fix.

No round-1 or round-2 finding regressed, and nothing in this round's diff introduced a new behavioural defect that I could identify.

---

5. What would make this PASS

One test: a ProjectileAuthoritative retained retry driven through drive.Advance(), asserting the pose advanced, the prediction version moved on a storing outcome and did not move on a re-parked Contention, and the shadow row followed the body. Two existing remote tests in the same file are the templates.

Nothing else is outstanding.