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

C4 route 5 — projectile authoritative placement: scoping (2026-08-04)

Research only. Nothing implemented, nothing edited under src/ or tests/. All reads are against the clean tree at d5bdc355 (git status --porcelain empty at the time of reading; route 4b-2 was in flight in another agent's session and had not yet written).

Headline: route 5 is much smaller than route 4, and roughly half of it has already shipped. The Create half and the residence-window Position half are canonical today (C3b/C3c). What remains is one execution seam, three deletions, and two policy decisions that the campaign has not yet made. It should NOT split. But one of those policy decisions — the near-Interpolate branch — has no executable machinery in acdream at all, and if the contract does not settle it up front the implementer will reproduce route 4b-2's "deleted the only handler for a live branch" failure exactly.

---

1. What route 5 actually is

1.1 The classifier surface

RuntimePositionEntityKind.Projectile (src/AcDream.Runtime/Physics/RuntimeAuthoritativePositionRouteClassifier.cs:13) is route 5's entity kind. It has exactly one behavioural effect anywhere in the classifier:

• OperationKind (:559-570) maps it to RuntimeSetPositionOperationKind.ProjectileAuthoritative (:567-568).

That is all. ClassifyCreate (:205-273) gives a Projectile the identical SetPosition + InitialCreateFlags route as any non-local entity — the only EntityKind test in that method is is RuntimePositionEntityKind.LocalPlayer at :263-266, for the teleport hook. ClassifyAcceptedPosition (:308-473) has a single LocalPlayer branch at :349; Projectile and Remote fall through the same code from :393 onward and are byte-for-byte identical in disposition, flags, StopInterpolating, and ConstrainPhase. The existing test RuntimeAuthoritativePositionRouteClassifierTests.cs:418-436 (ProjectilePosition_UsesRemoteMoveOrTeleportClassification) pins exactly that.

So the dispositions route 5 owns for an accepted Position are the same four route 4 owns, discriminated only by OperationKind == ProjectileAuthoritative:

Branch	Condition (classifier line)	Runs SetPosition?
SetPosition	TeleportAdvanced || CommittedCellId == 0 (:399)	yes
NoPositionOperation	!effectiveContact (:425)	no
Interpolate	contact, PlayerDistance < 96 m (:454-459)	no
SetPositionSimple	contact, PlayerDistance >= 96 m (:454-459)	yes

Consequence worth stating plainly: route 5 is not a classification change at all. Whether a projectile's accepted Position is tagged Projectile or Remote, the classifier returns the same route. Route 5 is an execution and ownership consolidation — which owner runs the route, and which ledger the operation lands in.

1.2 What is ALREADY canonical

(a) The Create half — DONE, live in production. RuntimeInitialCreateResidenceState.Begin decides the kind at :591-595:

RuntimePositionEntityKind entityKind = isLocalPlayer
    ? RuntimePositionEntityKind.LocalPlayer
    : (record.FinalPhysicsState & PhysicsStateFlags.Missile) != 0
        ? RuntimePositionEntityKind.Projectile
        : RuntimePositionEntityKind.Remote;

This is the only production producer of RuntimePositionEntityKind.Projectile in the tree (verified by grep across src/ and tests/). The first-entry conductor accepts it explicitly: RuntimeRemoteFirstEntryState.cs:311-313 admits RemoteAuthoritative or ProjectileAuthoritative. And App has already been cut over — DatLiveEntityProjectionMaterializer.cs:848-865 deliberately skips _projectiles.TryBind while initialResidenceActive, with a comment naming the exact bug that forced it ("the conductor then correctly rejected the unexpected owner and the missile remained permanently cell-less"). TryBind is retried on the committed projection-visible edge (ProjectileController.cs:870-897), by which point the canonical body exists and has been placed by the conductor.

(b) The residence-window Position half — DONE, dormant-but-wired. RuntimeInitialCreateContinuationExecutor.ApplyPositionAction:1892 recovers the kind from the lease's OperationKind (EntityKindOf, :2571-2579, which maps ProjectileAuthoritative → Projectile at :2577-2578) and classifies through the one shared request builder RuntimeAcceptedPositionRouteRequests.Build (:1914-1928). A Position arriving while a missile's initial residence is open is already fully canonical.

Note the executor's own recorded gap at :2019-2026: for Interpolate/NoPositionOperation/AwaitFreshPosition it emits a typed trace and returns — "Binding to the live interpolation owner is cutover work." That gap is shared with route 4 and is one half of the policy question in §5 below.

1.3 What is still a duplicate authority

The post-residence (steady-state) accepted Position for a live projectile. Entry point:

• src/AcDream.App/Physics/LiveEntityNetworkUpdateController.cs:1428-1448 — inside OnPosition, positioned AFTER the remote-teleport hook (:1417-1426) and BEFORE route 4a's classification (:1473-1481). It calls _projectileController.ApplyAuthoritativePosition(...) and returns when it returns true, so a projectile never reaches the classifier at all today.
• src/AcDream.App/Physics/ProjectileController.cs:492-590 — ApplyAuthoritativePosition (two overloads + doc comment, 99 lines). Validates, then delegates.
• src/AcDream.Runtime/Physics/RuntimeProjectilePhysicsUpdater.cs:301-424 — the actual authority (124 lines): body.Orientation = orientation (:345), body.SnapToCell(fullCellId, worldPosition, cellLocalPosition) (:346), body.State = record.FinalPhysicsState (:347), a velocity commit (:348-358), CommitProjectileCell (:370-375), the presentation acknowledgement (:387), and the InWorld/Activate/shadow-sync tail (:390-422).

CommitProjectileCell itself is not a bypass — RuntimePhysicsState.cs:1376-1397 routes it into the shared CommitCanonicalCell (:2138-2160), the same canonical-cell writer the remote path uses. The 2026-08-02 inventory called it "ad hoc"; that is wrong and should be corrected in the contract. The bypass is body.SnapToCell + the InWorld/shadow tail running outside the RuntimeSetPositionState transaction, not the cell commit.

1.4 Adjacent, NOT route 5

Per the inventory and confirmed by reading:

• Per-quantum integration stays out of SetPosition. RuntimeProjectilePhysicsUpdater.TryBegin/Complete (:37-205), driven by ProjectileController.Tick (:640-766) and LiveEntityAnimationScheduler (:403-426). Complete's SnapToCell at :145-152 plus CommitProjectileCell at :158-163 is the simulation commit, not an authoritative placement. The 1,880 B/op → 944 B/op placement budget (C2, plan :155-170) is per operation; projectile integration runs per object quantum on every missile in flight. Do not touch it.
• ApplyAuthoritativeVector (RuntimeProjectilePhysicsUpdater.cs:207-250) and ApplyAuthoritativeState (:252-299) are not placement authorities. Vector already goes through _physics.TryCommitAuthoritativeVector (:242). State's one pose write is body.SnapToCell(record.FullCellId, body.Position, ...) at :286-296 — a re-normalize of the frame into the already canonical cell on the Missile-bit rising edge, not a move. The inventory's "reduce to acknowledge-only" framing overstates what is there.

---

2. Retail truth

Verify each yourself; every anchor below was read in docs/research/named-retail/acclient_2013_pseudo_c.txt during this pass.

2.1 There is no projectile branch. At all.

SmartBox::UnpackPositionEvent @0x004542C0 resolves the object from CObjectMaint (@0x004542F2) and calls HandleReceivedPosition (@0x00454358) with no state/kind test.

SmartBox::HandleReceivedPosition @0x00453FD0:

• FORCE_POSITION early return @0x0045400C requires arg2 == this->player.
• unset_parent @0x00454129 unconditional; SetPlacementFrame @0x00454142 gated on !HasAnims.
• if (arg2 != this->player) @0x0045414D → MoveOrTeleport @0x00454254 → ConstrainTo @0x00454272 inside if (MoveOrTeleport(...) != 0), anchored to &arg2->m_position read live (post-move) → return.

A missile is not this->player, so a projectile takes the identical remote arm. No state & Missile test exists anywhere in this function.

CPhysicsObj::MoveOrTeleport @0x00516330:

if (!newer_event(POSITION_TS-ish gate)) return 0;              // @0x00516364/@0x0051636D
if (newer_event(TELEPORT_TS, arg3) || this->cell == 0) {       // @0x00516386
    teleport_hook @0x005163EF; SetFlags(0x1012) @0x00516414;
    SetPosition @0x00516420; return 1;                          // @0x00516438
}
if (arg4 != 0) {                                                // @0x0051638E — the contact bit
    if (player_distance < 96f)                                  // @0x00516390-@0x00516399
        { InterpolateTo(this, arg2, IsMovingTo(this)) @0x005163AF; return 1; }
    if (position_manager) StopInterpolating @0x005163CB;
    SetPositionSimple(this, arg2, 1) @0x005163D9; return 1;     // @0x005163E8
}
return 0;                                                       // @0x0051636D

SetPositionSimple @0x005162B0 with arg3 != 0 builds 0x1012 (Teleport|Slide|SendPositionEvent, @0x005162C4) — the classifier's AuthoritativeTeleportFlags.

Answers to the specific questions asked:

• Does a projectile's authoritative Position take the same MoveOrTeleport path as a remote? Yes, identically. Same function, same branches, no discriminator.
• What flags? Teleport/cell-less → 0x1012 via the explicit SetFlags @0x00516414. Far snap → 0x1012 via SetPositionSimple(…, 1) @0x005162C4. Near and airborne → no SetPosition at all.
• Is ConstrainTo armed for projectiles? Yes — @0x00454272, on any nonzero MoveOrTeleport return, with no kind test. It is NOT armed on the airborne no-op (return 0 @0x0051636D). CPhysicsObj::ConstrainTo @0x00510520 calls MakePositionManager first, so retail creates the manager on demand for a missile.
• Is StopInterpolating called? Only on the far branch, and only if a position_manager already exists (@0x005163C9-@0x005163CB). A missile that has never been near-interpolated has none, so the call is skipped.

2.2 player_distance is maintained for missiles

CPhysicsObj::update_object @0x00515D10 computes player_vector from Position::get_offset @0x00515D5B and stores player_distance @0x00515D95 for every active, unparented, in-cell object — which includes every in-flight missile. So retail's near/far test is meaningful for projectiles.

(BN artifact note: the decomp shows player_distance taking player_vector.x @0x00515D7B-@0x00515D95. That is the standard x87-elision artifact for a vector magnitude; acdream's Euclidean PlayerDistance is the right reading. Flagging it so nobody "fixes" it to .x.)

2.3 MoveOrTeleport discards the velocity argument

MoveOrTeleport(this, arg2, arg3, arg4, arg5) declares arg5 = AC1Legacy::Vector3 const* and never references it in the decompiled body @0x00516330-@0x00516438. HandleReceivedPosition threads arg6 into it @0x00454254 and does nothing else with it. Retail's velocity authority is set_velocity via VectorUpdate, not the Position event.

Confidence: the parameter is textually unreferenced. I did not byte-verify against refs/acclient.exe that BN did not elide a use. Treat as strong but not byte-confirmed; it matters only because acdream currently does commit a velocity here (§3, item 4).

2.4 What retail actually does to an in-flight missile — mostly nothing

Chain the three facts: an in-flight missile has a non-null cell, no advancing TELEPORT_TS, and no ground contact. arg4 == 0 → return 0 @0x0051636D. Nothing is written, and ConstrainTo is skipped.

The contact bit's provenance is ACE PositionPack.BuildFlags (references/ACE/Source/ACE.Server/Network/Structure/PositionPack.cs:72-73): IsGrounded is set from TransientState & OnWalkable. A flying missile is not OnWalkable.

Not established: I did not observe a live missile Position packet, because (see §6) ACE does not send one. The claim "an in-flight missile's Position packet would carry IsGrounded == false" is an inference from ACE's flag definition, not a measurement.

---

3. The duplicate authority to delete

Exact deletion targets, with the fabricated values called out.

#	Site	Lines	What it is
1	src/AcDream.Runtime/Physics/RuntimeProjectilePhysicsUpdater.cs:301-424	124	The real authority: SnapToCell :346, velocity commit :348-358, CommitProjectileCell :370-375, InWorld/Activate/shadow tail :390-422
2	src/AcDream.App/Physics/ProjectileController.cs:492-590	99	Two ApplyAuthoritativePosition overloads + doc; validation, currency closures, render-pose projection :583-586
3	src/AcDream.App/Physics/LiveEntityNetworkUpdateController.cs:1428-1448	21	The early-return call site that keeps projectiles out of the classifier

Raw total 244 lines; roughly 180 non-comment.

Fabricated values on those paths:

• LiveEntityNetworkUpdateController.cs:1442-1443: acceptedSpawn.Physics?.Velocity ?? System.Numerics.Vector3.Zero. This is the exact ?? Vector3.Zero shape route 4b-2's contract calls out, and it is worse than an inert default: it is passed into RuntimeProjectilePhysicsUpdater.cs:348-358, which commits it as the body's authoritative velocity whenever VelocityAuthorityVersion matches. A Position packet with no PhysicsDesc.Velocity therefore zeroes an in-flight missile's velocity. Retail's MoveOrTeleport does not consume its velocity argument at all (§2.3).
• No duplicated distance/threshold constants exist on the projectile path — MaxPhysicsDistance = 96f and BodySnapThreshold = 4f live only in the classifier (:194) and route 4a's seam (RuntimeRemoteSteadyStatePosition.cs:43) plus the surviving 4b legacy far halves. Route 5 introduces no new copy and must not.

Not a deletion target, despite appearances:

• ProjectileController.CanAcceptPositionPayload (:102-126). It is called unconditionally at LiveEntityNetworkUpdateController.cs:1205-1208 for every entity (it returns true for non-projectiles via != false), so it is the shared admission validator, not a projectile authority. It also does not subsume item 1's inner validation: it checks update.Position and update.Velocity, while ApplyAuthoritativePosition additionally checks the origin-translated worldPosition and a different velocity (acceptedSpawn.Physics?.Velocity).
• ProjectileController.TryBind's create branch (:222-267) and its entity.SetPosition/ParentCellId/RebucketLiveEntity tail (:269-291). This is a placement authority — GetOrCreatePhysicsBody with a SnapToCell seeded straight from the CreateObject wire frame (:258-264) — but it is now the fallback for the paths the residence conductor does not own: initialResidenceActive == false (DatLiveEntityProjectionMaterializer.cs:857) and the late-classification route ApplyAuthoritativeState → TryBind (ProjectileController.cs:488), where an ordinary remote gains the Missile bit mid-life. Deleting it belongs to route 5 only if route 5 first proves those two paths unreachable or supplies a canonical replacement. My recommendation: leave it, record it, and let C5's deletion pass own it — see §7 trap T8.

---

4. Prediction / correction

This is where the subtle regression lives, and it is a real one.

The projectile prediction model (J5.6): RuntimeProjectile.PredictionAuthorityVersion (RuntimeProjectile.cs:36-39) is bumped by InvalidatePrediction(). It is bumped in exactly three places, all in RuntimeProjectilePhysicsUpdater: ApplyAuthoritativeVector:241, ApplyAuthoritativeState:272, and ApplyAuthoritativePosition:342.

That version is the sole cancellation mechanism for an in-flight split quantum:

• TryBegin captures it into the commit (:86-87).
• Complete re-checks it via IsSpatialCurrent/IsIdentityCurrent (:114-122, :131-140, :164-174, :200-204, :440-450).
• App re-checks it too, in ProjectileController.IsCurrentQuantumIdentity (:850-859).

And the quantum is genuinely split across other work: LiveEntityAnimationScheduler.cs:403-426 calls TryBeginQuantum at :404-408, runs _animationHooks.Capture at :411, then CompleteQuantum at :418-422. ProjectileController.AdvanceQuantum (:773-782) is the fused variant for un-animated missiles.

The trap: if route 5 replaces ApplyAuthoritativePosition with a RuntimeSetPositionState route and does not invalidate the projectile's prediction version at the same point, then (a) an already-begun quantum's Complete will no longer abort, and will write the pre-correction integrated pose over the freshly committed placement, and (b) the version stops advancing on this channel, weakening the currency checks that the Vector and State channels still rely on. The fix is trivial once seen — the contract must require the replacement to invalidate prediction at the same point in the sequence retail's SetPosition would clobber the body — but it is invisible if you only read the classifier.

Not established: whether the network drain can actually land between :408 and :418 in a single frame (both are on the update thread; the wire pump is a separate frame phase, and _animationHooks.Capture can dispatch effect callbacks). I could not settle re-entrancy by reading alone. The mechanism — InvalidatePrediction being the only cancel — is established regardless, and that is enough to make the requirement binding.

Second prediction interaction: retail's near branch is InterpolateTo(this, arg2, IsMovingTo(this)) @0x005163AF, and CPhysicsObj::IsMovingTo @0x0050EB10 returns nonzero only when a MovementManager exists and is moving-to. A missile has no MovementManager, so retail passes 0. Any acdream near-branch policy that wants to be retail-shaped must pass isMovingTo: false for projectiles.

---

5. The two policy decisions the contract must make

Both are of the shape the 4b-2 contract names: "deleting the legacy block removes the only handler for a live classification." Neither can be deferred into a code comment.

5.1 Interpolate (near, in contact) has NO executable machinery

Route 4a's seam is RuntimeRemoteSteadyStatePosition.ApplyInterpolate (:113-149) and it takes a RemoteMotion — it drives remote.Interp (the interpolation queue) and remote.Body. TryArmConstraintAfterOperation (:165-180) requires remote.Host to reach host.PositionManager.ConstrainTo.

A projectile has none of that. RuntimeProjectile (RuntimeProjectile.cs:17-40) is { Body, CollisionSphere, PredictionAuthorityVersion }. No EntityPhysicsHost, no PositionManager, no InterpolationManager, no ConstraintManager. A pure missile also never acquires a RemoteMotion — that is created on the 0xF74C motion path, and ProjectileController.HandlesMovement (:599-602) plus LiveEntityAnimationScheduler.cs:256-257,336 keep the two owners disjoint while the Missile bit is set. (Coexistence is representable — ProjectileController.Tick:756 handles record.RemoteMotionRuntime is RemoteMotion — but it is the adopted-body case, not the ordinary arrow/bolt.)

So the contract must choose, explicitly:

1. Build retail's PositionManager chain for projectiles. Retail-exact (ConstrainTo @0x00510520 does MakePositionManager on demand). Also the only way to be exact about StopInterpolating @0x005163CB and the leash @0x00454272. Large: a new interpolation/constraint owner for a body type that has none, plus its interaction with the per-quantum stepper. If this is chosen, it is route 5b and route 5 splits.
2. State an acdream divergence: a projectile's near-Interpolate and its ConstrainTo are no-ops, with a register row citing @0x005163AF and @0x00454272 and the reason (no PositionManager exists for a ballistic body; the classifier's own ConstrainPhase is honoured for the placement branches only). Cheap, honest, and — given §6 — has no observable production effect.

My recommendation is (2), with the row filed in the same commit. Choosing (1) for a branch that ACE never triggers would be building machinery for a packet that does not exist.

5.2 The placement dispositions have no owner

RuntimeRemotePlacementDriveController.OwnsPlacement (src/AcDream.Runtime/Session/RuntimeRemotePlacementDriveController.cs:274-278) requires:

route.OperationKind is RuntimeSetPositionOperationKind.RemoteAuthoritative
&& route.Disposition is SetPosition or SetPositionSimple
&& (route.SetPositionFlags & PhysicsSetPositionFlags.Teleport) != 0

ProjectileAuthoritative is excluded. So the moment route 5 stops short-circuiting at LiveEntityNetworkUpdateController.cs:1432, the SetPosition (teleport / cell-less) and SetPositionSimple (far) branches for a projectile have no handler at all.

The controller is otherwise entirely kind-agnostic: the service window, the per-entity _pending map, the _awaitingAcknowledgement ledger, the refuse-not-park decision, and DetachRoute's cancellation all read only the record and the token. Widening the first clause to is RemoteAuthoritative or ProjectileAuthoritative (plus its class/method doc) is ~10 lines and is the right move. Do not clone a sibling controller.

Sequencing constraint: that file is route 4b-2's active edit surface, and route 4b-3 will touch it again. Route 5 must land after 4b-2, and its contract should say so.

---

6. The connected gate — and an honest problem with it

ACE never sends an UpdatePosition for a missile. The only physics-tick site that would is commented out: references/ACE/Source/ACE.Server/WorldObjects/WorldObject_Tick.cs:333-334 (/*if (PhysicsObj.IsGrounded) SendUpdatePosition();*/), inside the branch explicitly gated on (PhysicsObj.State & PhysicsState.Missile) != 0 at :265. Every live SendUpdatePosition / GameMessageUpdatePosition caller in ACE.Server is a Player, Creature/Monster, Pet, GamePiece, inventory move, or an admin command (grepped exhaustively). The projectile classes broadcast GameMessageVectorUpdate (SpellProjectile.cs:238) and GameMessageSetState (:229) on impact — never a Position.

So route 5's authoritative-Position half is unreachable in ordinary play against ACE, and there is no cheap live trigger: the one admin path (AdminCommands.cs:4772, move-selected-object-to-me) requires selecting a projectile inside its ~5 s ProjectileTimeout lifetime.

The contract must say this rather than invent a gate. Concretely:

What the user CAN observe (the Create half + no-regression):

1. In peace mode with a bow: fire an arrow at a target ~20 m away. The arrow must appear at the launch point immediately, fly a clean arc, and vanish on impact.
2. Cast a Force Bolt / Flame Bolt at a target across a landblock boundary (stand near a seam, target something on the other side). The bolt must not freeze, teleport, or vanish at the seam.
3. Fire indoors, in a dungeon: the projectile must respect the EnvCell and impact on the wall rather than passing through.
4. Fire at a target at bow max range (~80 m) and confirm the projectile does not stall or snap.
5. After each impact, walk through the impact point. An invisible collider there is the loud regression — it means a projectile's shadow/cell state survived its retirement.

Regression signatures: projectile spawns at the origin or at the player's feet instead of the launch point; hangs motionless; disappears on frame 1; appears only after it has already travelled; leaves an invisible-but-solid body (the #184 signature); an arrow that visibly slows or stops mid-flight (that would be the §3 velocity-zeroing path, which route 5 removes — so if it is present today, it should stop).

What the gate cannot cover: the four accepted-Position dispositions. Those must be gated by focused Runtime + App tests, with the ACE citation above recorded as the reason. Do not let a green connected gate be presented as evidence for the Position half.

---

7. Traps

T1 — the near-Interpolate branch loses its only handler. §5.1. Highest risk. Today ApplyAuthoritativePosition handles every projectile Position shape by hard-correcting. Route 5 replaces it with four dispositions, two of which (Interpolate, NoPositionOperation) have no projectile executor. The airborne one is correct as a no-op (retail returns 0). The near one is not, and silently dropping it is the same failure as 4b-2's null/Rejected* trap.

T2 — OwnsPlacement excludes ProjectileAuthoritative. §5.2. The far and teleport/cell-less branches have no owner the instant the short-circuit is removed.

T3 — prediction invalidation. §4. InvalidatePrediction() is the only mechanism that aborts an in-flight split quantum; the SetPosition route does not call it.

T4 — the entity kind is decided ONCE, at Create. RuntimeInitialCreateResidenceState.cs:591-595 reads record.FinalPhysicsState & Missile at Create time and freezes it into the lease's OperationKind. But the Missile bit changes at runtime: ACE clears it on impact (SpellProjectile.cs:229 broadcasts the new state), and ApplyAuthoritativeState → TryBind (ProjectileController.cs:473-488) is the path where an ordinary object becomes a missile. Meanwhile RuntimeEntityObjectLifetime.ClassifyRemoteAcceptedPosition:622 hardcodes RuntimePositionEntityKind.Remote. Route 5 must define one per-packet discriminator from the canonical FinalPhysicsState, and the remote arm and the projectile arm must be provably mutually exclusive on the same input — otherwise both or neither will own a packet at the moment the bit flips. Because the classifier is disposition-identical for the two kinds (§1.1), a mis-tag is silent: the route is right and only the ledger/owner is wrong.

T5 — ApplyAuthoritativePosition returns true on an invalid payload. ProjectileController.cs:550-554 and RuntimeProjectilePhysicsUpdater.cs:329-339 both return true — "handled, ignore" — so the packet does not fall through to the generic remote path. Their validation is not subsumed by CanAcceptPositionPayload (§3). Any replacement must preserve the swallow, or an invalid projectile packet starts being routed as an ordinary remote.

T6 — carrying AP-87 onto a branch that does not need it. Same shape as 4b-2's warning. AP-87's bodyToTarget > 4 m / !willBeDrTicked guards (RuntimeRemoteSteadyStatePosition.cs:43,130-138) exist to stop an unplaced remote body being enqueued into an interpolation queue. A projectile has no queue. Do not copy them in. Equally: do not delete the near-branch copies — those are 4a's and still load-bearing.

T7 — routing per-quantum integration through SetPosition. The one explicit prohibition carried from the original route-5 requirement, and the allocation budget is the reason. RuntimeProjectilePhysicsUpdater.Complete (:94-205) runs per quantum per in-flight missile.

T8 — deleting TryBind's create branch as "obviously superseded". ProjectileController.cs:222-267 looks like dead legacy now that C3c owns Create, but it is still the live path for initialResidenceActive == false (DatLiveEntityProjectionMaterializer.cs:857) and for late Missile classification (ProjectileController.cs:488). Same class as the 4a review's R1 (a "duplicate" that turned out to be the only handler for a real case).

T9 — a second snapshot store for the same state. The _pending / _awaitingAcknowledgement maps in RuntimeRemotePlacementDriveController are keyed by RuntimeEntityKey and are already per-entity. Adding a projectile-specific pending map alongside them would recreate the two-stores-for-one-state shape the campaign has hit twice. Widen the existing controller; do not add a parallel one.

T10 — the register. No projectile placement row exists anywhere in docs/architecture/retail-divergence-register.md (grepped). Route 5 introduces at least one deviation (§5.1 option 2) and retires at least one (the velocity zeroing, §3). Both rows land in the same commit as the behaviour.

---

8. Line budget, and whether route 5 splits

Calibration: route 4a = 364 production lines; 4b-1 = 230 + a 57-line park fix; 4b-2 budgeted at 350-500.

Item	Non-comment production lines
Delete the three sites in §3	~180 removed
Runtime projectile steady-state seam (airborne no-op + the §5.1 policy + prediction invalidation)	60-100
Projectile classification entry (extend ClassifyRemoteAcceptedPosition with a kind parameter, or a sibling)	10-35
Widen OwnsPlacement + doc	~10
App call-site rewrite in OnPosition (classify → own → skip generic → project committed placement)	40-70
Total added	120-215

Estimate: 250-400 non-comment production lines touched, of which 120-215 are new. Test work is the larger share as usual — roughly 400-700 lines (Runtime seam tests per disposition, the prediction-invalidation test, a behavioural App test proving the generic path no longer runs for a projectile).

Route 5 should NOT split — conditional on §5.1 resolving to option 2. If the contract chooses to build a PositionManager/InterpolationManager chain for projectiles, that is a separate 5b landing of its own and the estimate above does not cover it.

Sequencing: route 5 lands after 4b-2 and, preferably, after 4b-3, because it edits RuntimeRemotePlacementDriveController and LiveEntityNetworkUpdateController.OnPosition — both of which 4b-2/4b-3 are rewriting heavily. A parallel route-5 landing would be exactly the "coupled plan slices in parallel" failure the project has already recorded.

---

9. Explicitly not established

1. Whether the network pump can land a packet between TryBeginQuantum and CompleteQuantum (§4). Would be settled by an ACDREAM_PROBE_* counter on a straddled Complete returning false, or by reading the frame graph's phase ordering end to end.
2. Whether retail's MoveOrTeleport genuinely ignores its velocity argument, or BN elided a use (§2.3). Would be settled by tools/pdb-extract byte-decode of 0x00516330-0x00516438, or a cdb breakpoint at @0x00454254 dumping arg6 and comparing the object's velocity before and after.
3. Whether an in-flight missile's Position packet would carry IsGrounded == false (§2.4) — inferred from ACE's PositionPack.cs:72-73, never observed, because ACE does not emit the packet.
4. Whether initialResidenceActive == false is actually reachable for a Missile-state top-level Create in the graphical host (§3, T8). It is plainly reachable in the content-less headless path (C3c: "content-less headless keeps pre-flip direct registration") and for Parented/PickedUp Creates. For a graphical top-level missile Create it depends on RuntimeInitialCreateResidenceState.CanAcceptCreate (:559-573) never refusing, which I did not prove.
5. Whether any retail server ever sent a projectile Position. Only ACE was checked. Retail's client clearly supports it (§2.1); acdream targets ACE.