acdream/docs/research/2026-08-04-c4-route-3-retail-review.md

# C4 route 3 — retail-conformance review (2026-08-04)

**Verdict: FAIL.**

Reviewer scope: the uncommitted working-tree diff at HEAD `cd3129e9`
(`git diff HEAD` + untracked), branch
`claude/acdream-physics-divergence-5aa784`. Review only — no edits made.

The retail *reading* in this slice is excellent. Every §1 claim in the
pinned contract reproduces line-for-line in
`docs/research/named-retail/acclient_2013_pseudo_c.txt` (§A below), both
inversions are implemented in the right direction, the D-T3 duty map is
complete, and the implementer's P1 finding on TransientState is not just
correct — it retires a real pre-existing divergence.

The slice fails on **what happens when the placement does not commit**.
`TeleportAnimEvent.Place` is one-shot, so every non-`Committed` outcome
silently skips the placement, the presentation suffix, and the
materialization acknowledgement while the animation stream marches on to
reveal the world and fire LoginComplete anyway. The headless host has the
same hole with the extra property that it *asserts a materialization that
did not happen*. Neither is covered by a test, because the App-layer
presentation suite the contract made mandatory (§8 items 8/9/10, closing
route 2's B2 gap) was not written — the existing App assertions were
weakened instead. And the one probe field the connected gate keys on
(`leash=armed`) can never be true as coded.

---

## Findings

### R1 — MAJOR — `TeleportAnimEvent.Place` is one-shot; there is no re-attempt driver, and the reveal completes anyway

`src/AcDream.Core/World/TeleportAnimSequencer.cs:136-141`

```csharp
case TeleportAnimState.Tunnel:
    if (worldReady)
    {
        evts.Add(TeleportAnimEvent.Place);
        Advance(TeleportAnimState.TunnelContinue, enterTunnel: false);
```

The state advances in the **same tick** the event is emitted. `Place`
never fires again for that reveal.

`src/AcDream.App/Streaming/LocalPlayerTeleportController.cs:505-522`

```csharp
case TeleportAnimEvent.Place:
    if (!_worldReveal.CanPlacePortalDestination(...)) return;
    if (!TryExecuteCanonicalPortalPlacement(sequence)) return;   // :513
    ...
    _placement.Place(_pendingRotation);                           // :517
    ...
    _worldReveal.ObserveMaterialized(...);                        // :520
```

`TryExecuteCanonicalPortalPlacement` returns `true` **only** on
`RuntimeAcceptedPositionExecutionStatus.Committed`
(`LocalPlayerTeleportController.cs:597-598`). Every other status —
`Contention`, `Rejected`, `NotApplicable`, and notably `DeferredCell` —
returns `false` and the `Tick` returns.

Consequences, all reachable:

- `_placement.Place` never runs → no `entity.SetPosition` /
  `ParentCellId` / `RebucketLiveEntity`, no `NotifyTeleported()`, no
  camera reset, no `_spatial.Reconcile()`.
- `_worldReveal.ObserveMaterialized` never runs →
  `RuntimeWorldTransitState.AcknowledgePortalMaterialized` never fires →
  `Materialized` stays false.
- The **next** tick still advances the sequencer:
  `TunnelContinue` → `TunnelFadeOut` → `PlayExitSound`
  (`RevealWorldViewport`) → `WorldFadeIn` → `FireLoginComplete`
  (`_mode.EnterWorld()` + `SendLoginComplete()` + `_worldReveal.Complete()`
  + `ResetTransit`).
- `RuntimeWorldTransitState.Complete` then trips
  `FailInvariant("portal-complete-before-materialized")`
  (`RuntimeWorldTransitState.cs:701-706`) and returns `false`;
  `WorldRevealCoordinator.Complete()` (`:268-276`) **discards** that
  `false`. `ResetTransit(clearSession:false)` then calls
  `_transit.EndTeleport()` + `_worldReveal.Cancel()`, so the ledger
  converges — but the reveal is recorded cancelled, not completed, with
  one invariant failure logged.

User-visible outcome on `Contention`/`Rejected`: the player is revealed
into the destination world **standing at the origin position**, with
LoginComplete sent. On `DeferredCell`: the body commits later at the
collision-generation wake (`Advance` → `ReconcileAndAcknowledgePortal`),
but the presentation suffix, camera reset, rebucket, and materialization
ack are gone forever.

This is exactly what contract §4 items 4 and 5 forbid ("a refused
placement must NOT … must not advance the anim-event stream's terminal
events"; "never a half-state", "never a silent wedge in portal space")
and it is the D-T5/P4 obligation the contract flagged in advance: *"if
the Place anim event is one-shot, the re-attempt must be driven by the
same Tick predicate that produced it, and THAT mechanism must be stated
in the commit."* It is one-shot, and no mechanism was added.

The comment shipped in its place is false. `LocalPlayerTeleportController.cs:566-572`:

> "On any refusal this returns `false` without mutating anything — the
> D-T5 refusal shape: … the transit's own cancellation/supersession
> machinery is the authority on what happens next."

The transit is not the authority on what happens next. The animation
sequencer is, and it does not wait.

**Correct behaviour:** either re-drive the Place edge from the same
`ready`-gated Tick predicate until it commits (holding the sequencer in
`Tunnel` — which is what retail's `blocking_for_cells` hold is), or
cancel the reveal explicitly on refusal so the player is never revealed
without a committed placement. Retail has no third option: it places
unconditionally and immediately (`SmartBox::TeleportPlayer` @0x00453910)
and only the *simulation* waits on prefetch.

---

### R2 — MAJOR — headless discards the arm's status and acknowledges a materialization that did not happen

`src/AcDream.Headless/Hosting/HeadlessSessionWorldProjection.cs:775`

```csharp
_ = _acceptedPositionDrive.TryExecuteAcceptedPortalArrival(
    destination,
    authority);
```

The status is dropped on the floor. `PrepareDestination` then
unconditionally returns a ready readiness report, and
`RuntimeLiveEntitySessionController.TryCompletePortal` continues its
fully-synchronous suffix: `AcknowledgeDestinationReadiness` →
`AcknowledgePortalMaterialized` → `SimulationReleaseProjected` →
`Complete` → `SendGameAction(LoginComplete)` → `EndTeleport`.

So on any refusal or park, the headless host **fires
`AcknowledgePortalMaterialized` for a placement that never committed** —
contract §4 item 5 and D-T5 rows 1/2 both state in terms that the
materialization ack must fire only from the committed outcome. The bot
reports a completed teleport while standing where it started, with no
log line of any kind (see R8).

Retail contradiction is indirect but real: retail's
`SmartBox::PlayerPositionUpdated` @0x00453870 clears
`waiting_for_teleport` **inside the same call that performed
`SetPositionSimple`** (@0x00453924 → @0x0045389A). The "wait is over"
edge is downstream of the placement in retail; here it can precede a
placement that never occurred.

---

### R3 — MAJOR — the D-T8 probe's `leash` field can never read `armed`; the connected gate as pinned is unpassable

`src/AcDream.Runtime/Session/RuntimeAcceptedPositionDriveController.cs:694`

```csharp
leashArmed: controller.PositionManager?.IsFullyConstrained() ?? false,
```

Retail `ConstraintManager::IsFullyConstrained` @0x005560D0 is
`constraint_distance_max * 0.9 < constraint_pos_offset` — "has strained
past 90 % of the leash", the predicate `jump_is_allowed` reads. It is not
"is the leash armed". The acdream port says so explicitly
(`src/AcDream.Core/Physics/Motion/ConstraintManager.cs:79-89`).

Retail `ConstraintManager::ConstrainTo` @0x00556240 (pseudo-C
:353528-353537) ends with
`constraint_pos_offset = Position::distance(anchor, physics_obj->m_position)`;
acdream mirrors it at `ConstraintManager.cs:65-71`. Because
`RearmConstraintLeashAtCurrentPosition`
(`PlayerMovementController.cs:1836-1845`) anchors at the body's **own**
`CellPosition`, that distance is 0. `max * 0.9 < 0` is false.

Therefore every committed portal arrival prints `leash=unarmed`. The
contract's §9 pass criterion — *"Pass requires ALL of … `leash=armed`"* —
cannot be met, and a future reader hitting `leash=unarmed` would chase a
phantom missing leash (the exact 4b-3 A1 defect class the contract
warned about, inverted).

The correct observable is `ConstraintManager.IsConstrained`, which the
Runtime test itself uses
(`RuntimeAcceptedPositionDriveControllerTests`,
`Assert.True(controller.PositionManager.Constraint!.IsConstrained)`).
`PositionManager` does not currently surface it; it needs to.

---

### R4 — MAJOR — the mandatory App-layer presentation suite is missing, and the existing App assertions were weakened

`tests/AcDream.App.Tests/Streaming/LocalPlayerTeleportControllerTests.cs`
gained **zero** new `[Fact]`s. All five new tests in the diff are in
`tests/AcDream.Runtime.Tests/Session/RuntimeAcceptedPositionDriveControllerTests.cs`.

What changed in the App file is assertion *strength*, downward:

```diff
-        Assert.Equal(new Vector3(7f, 8f, 9f), harness.Placement.Position);
+        Assert.True(harness.Placement.Called);
```

(and the same substitution at eight further sites). The interface change
makes the literal old assertion impossible, which is fine — but the
contract required the replacement coverage and named it as load-bearing:

- §8 item 8: "after a committed portal placement through the REAL sink +
  suffix, the render `WorldEntity` position/rotation/`ParentCellId` equal
  the resolved body, the draw bucket moved, the local-player shadow
  agrees, and the sink's Place receipt was consumed with a VALID portal
  authority … **route 2's B2 coverage gap … becomes load-bearing here and
  MUST close**."
- §8 item 9: the T8 overwrite ordering (wire pose then resolved pose).
- §8 item 10: refused Place edge presentation.

None exist. Since `RuntimePlacementPresentationSink.TryPublishPlace`
writes no pose (contract §3.4, re-confirmed), the suffix in
`LocalPlayerTeleportPlacement.Place` is now the render entity's **only**
mover — and nothing asserts it moves the entity to the resolved pose.
Combined with R1 (where that suffix is skipped entirely on refusal), this
is the #312 shape verbatim: process rule 4, "tests must assert the layer
that broke."

---

### R5 — MAJOR — headless dual-host parity (§8 item 6, D-T6) has no coverage, self-declared open

`tests/AcDream.Headless.Tests/HeadlessSessionHostTests.cs:413-422`
(added in this diff):

> "no accepted-position drive controller is wired into this fixture's
> projection … so the canonical portal arm this method now calls is a
> no-op here by construction (`_acceptedPositionDrive` is null) … a
> headless-host-specific committed-portal test is an open item, not
> attempted here given this session's time budget."

D2 (`ResynchronizeLocalPlayerForPortalArrival`, ~40 non-comment lines and
AD-42's last citation) was deleted and its replacement has **zero**
headless test coverage. D-T6 pinned this: *"dual-host parity is a test
obligation, not an aspiration."* The honest disclosure is appreciated and
does not change the finding.

Related, and unremarked in the diff: the deleted method also performed
`controller.LocalEntityId = record.LocalEntityId ?? 0u`. Verified safe —
`RuntimeLocalPlayerPhysicsPublicationState.cs:214` sets it at publication
and the entity key is stable across a portal — but the drop deserves a
line in the commit message.

---

### R6 — MEDIUM — the `enter_world` caller-sweep correction mis-states the retail record it is correcting

`docs/research/2026-07-16-portal-completion-pseudocode.md` §2.1 banner:

> "a caller sweep … shows both `CPhysicsObj::enter_world` call sites
> living inside `CObjectMaint::CreateObject`'s player branch
> (`SmartBox::init_player` + `CellManager::ChangePosition` immediately
> precede it)"

Verified independently. The two call sites are pseudo-C :93797
(@0x004550EC) and :93824 (@0x00455095). Both live inside
**`SmartBox::HandleCreateObject` @0x00454C80**, not
`CObjectMaint::CreateObject` — the latter is merely a *callee* at
@0x00454FD8 inside that same function. And they are **not both in the
player branch**: @0x004550EC is in the `if (arg3 != this->player_id)`
NON-player branch (`PhysicsDesc::get_position` → `enter_world(var_bc, …)`
for a newly created remote object); only @0x00455095 sits in the player
branch after `init_player` + `ChangePosition`.

The load-bearing NEGATIVE is **CONFIRMED**: the `Position*` overload
@0x00516310 has exactly those two callers, the `int` overload @0x00516170
is reached only from @0x00516327, and neither is on the portal path.
`SmartBox::TeleportPlayer` → `SetPositionSimple` is correct.

But this banner is explicitly a correction to the retail record that
future sessions will cite, and it is wrong in two of its three factual
clauses. Same defect class as "a register row asserting behaviour the
code does not have," applied to a research doc — the exact reason the
contract ordered the correction in-slice.

---

### R7 — MEDIUM — retail's post-teleport movement refresh is autonomy-gated; acdream's is not

Contract open question (c), answered.
`CommandInterpreter::SendMovementEvent` @0x006B4680 (pseudo-C
:700274-700313):

```
if ((player != 0 && this->smartbox != 0) && CPhysicsObj::InqRawMotionState(player) != 0)
    if (this->autonomy_level != 0)
        MoveToStatePack::MoveToStatePack(...)
        SendMoveToStateEvent(...)
```

Two gates: a non-null raw motion state, and **`autonomy_level != 0`**.
Under server control retail sends nothing.

`RuntimeAcceptedPositionDriveController.cs:678-681` calls
`_localPlayerOutbound.TrySendMovement(...)` unconditionally;
`LocalPlayerOutboundController.TrySendMovement:187-229` gates only on a
resolvable outbound position. The controller already holds
`UsePositionFromServer` (retail's `UsePositionFromServer()`), and
`_usePositionFromServer` is already a field on this very class — the
autonomy fact is in scope.

Everything else about the port checks out: the message family is
`MoveToState` (retail packs `InqRawMotionState` into `MoveToStatePack`),
the contact byte is `Contact && OnWalkable` in both, exactly one is sent,
and no `AutonomousPosition` goes out (retail's teleport branch returns
before `SendPositionEvent` — verified at @0x004541C0). Order is right:
`CommitCanonicalTeleportFrame` (hook tail) → `CancelAutoRun` →
movement send, matching @0x004538AE → @0x004538B3 → tail-jump.

Either add the autonomy gate or file the delta as a register row.

---

### R8 — MEDIUM — D-T8 emits one line per *committed* arrival, not per attempt; refusals are invisible under the pinned gate environment

`PhysicsDiagnostics.LogLocalTeleportArrival` is called from exactly one
site, `ReconcileAndAcknowledgePortal`
(`RuntimeAcceptedPositionDriveController.cs:687-696`), reached only on
`CommittedHostAcknowledgementPending`. Its `placementStatus` argument is
the literal `"Committed"`.

The graphical refusal path logs via `PhysicsDiagnostics.LogTeleport`
(`LocalPlayerTeleportController.cs:582-583`, `:598-599`), which is gated
by **`ACDREAM_PROBE_TELEPORT`** (`PhysicsDiagnostics.cs:1160-1161`) — a
different env var from the `ACDREAM_PROBE_LOCAL_TELEPORT` the gate pins.
The headless refusal path logs nothing at all (R2).

Net: with the contract's pinned gate environment, a refusal produces zero
output on either host. D-T8 specified "One line per portal-arrival
attempt: cause … placement status", and §9 requires "zero
`Refused`/`Contention` lines in ordinary play" — unobservable as built.
Given R1, an unobserved refusal is precisely the failure that would ship.

---

### R9 — LOW — stale directional reference in a comment added by this diff

`src/AcDream.App/Streaming/LocalPlayerTeleportController.cs:775`:
"TryBeginPortal (below) drives …". `_worldReveal.TryBeginPortal` is
called **above** this comment, at `:741`, in the same method. Process
rule 6.

### R10 — LOW — `AD-131` does not exist

`src/AcDream.App/Physics/LiveEntityNetworkUpdateController.cs:2292`
cites "AD-2/AD-131/#275". The AD section has 48 rows. The row is
**AP-131** (`docs/architecture/retail-divergence-register.md:283`), which
is what the contract itself says. Introduced by this diff, in the very
comment the slice rewrote to fix a stale comment.

### R11 — LOW — the probe asserts more than it observes

`RuntimeAcceptedPositionDriveController.cs:693-695` hardcodes
`hookTailRan: true` and `autorunCancelled: true`.
`RuntimeLocalPlayerMovementState.CancelAutoRun():226-234` returns `false`
when autorun was already off (correctly mirroring retail's
`SetAutoRun` @0x006B4850, which acts only on a state *change* at
@0x006B4871). The field reports the action ran, not the state changed —
report the returned bool.

---

## §A — retail claims verified independently (do not re-derive)

All against `docs/research/named-retail/acclient_2013_pseudo_c.txt`.

| claim | where | result |
|---|---|---|
| `SmartBox::TeleportPlayer` @0x00453910 = `SetPositionSimple(player, dest, 1)` @0x00453924 + `PlayerPositionUpdated(this, 1, FLT_MAX)` @0x00453932, nothing else | :92514-92523 | **CONFIRMED** — the generic path, route 2's exact primitive, third route running |
| `PlayerPositionUpdated` teleport arm order: `position_update_complete=0` @0x00453890, `waiting_for_teleport=0` @0x0045389A, `has_been_teleported=0` @0x004538A4, `teleport_hook` @0x004538AE, `cmdinterp->PlayerTeleported()` @0x004538B3, `set_viewer` @0x004538D5, `LScape::update_viewpoint` @0x004538E2, `CellManager::ChangePosition` @0x00453903 | :92469-92509 | **CONFIRMED**, exactly the contract's order |
| `CommandInterpreter::PlayerTeleported` @0x006B32B0 = `SetAutoRun(0,1)` + tail-jump `SendMovementEvent` | :699036-699041 | **CONFIRMED**. New: `SetAutoRun` @0x006B4850 only acts when `(arg2==0) != (auto_run==0)` (@0x006B4871) — acdream's `CancelAutoRun` early-return matches |
| **Inversion A** — local TELEPORT branch @0x0045415F: `TeleportPlayer(&var_48)` @0x00454168 → `ConstrainTo(arg2, &var_48, start, max)` @0x0045418A → `set_velocity(player, {0,0,0}, 1)` @0x004541B4 → return | :93013-93023 | **CONFIRMED**, including the WIRE-destination anchor |
| FORCE_POSITION branch returns @0x0045409D before every `ConstrainTo` | :92925-92933 | **CONFIRMED** — route 2's no-re-arm rule intact and correctly left force-scoped |
| **Inversion B** — the local hook runs AFTER the placement (from `PlayerPositionUpdated`), opposite to the remote arm's @0x005163EF | :92497 vs 4b-3's citation | **CONFIRMED** |
| `enter_world` is NOT on the portal path | :93797, :93824 | **NEGATIVE CONFIRMED** — but the attribution in the new correction banner is wrong; see R6 |
| **P1 (TransientState not re-seeded)** — retail `CPhysicsObj::SetPositionInternal(CTransition*)` @0x00515330 derives Contact from `collision_info.contact_plane_valid` @0x00515430, WaterContact from `contact_plane_is_water` @0x00515453, OnWalkable from `set_on_walkable(contact_plane.N.z vs floor_z)` @0x00515467-0x0051548E, Sliding from `sliding_normal_valid` @0x005154E1. **No unconditional `Contact\|OnWalkable` seed anywhere.** | :283484-283519 | **THE FINDING IS CORRECT AND IS A FIDELITY GAIN.** `PhysicsObjUpdate.CommitSetPositionContactPrefix` (`src/AcDream.Core/Physics/PhysicsObjUpdate.cs:154-176`) is that exact port, and runs inside the canonical commit (`RuntimeSetPositionState.cs:5038`). The old `SetPositionCore` seed (`PlayerMovementController.cs:1859-1862`) was the divergence; dropping it is right. The `Active` argument also holds — `PlayerMovementController.cs:2069` and `:2449` re-set it every frame. |
| `ConstraintManager::ConstrainTo` @0x00556240 initializes `constraint_pos_offset = distance(anchor, m_position)` | :353528-353537 | **CONFIRMED** — acdream matches; also the basis for R3 |
| `CommandInterpreter::SendMovementEvent` @0x006B4680 is autonomy-gated | :700274-700313 | **CONFIRMED** — see R7 |

## §B — implementation facts verified correct

- **D-T3 duty map (P1) is complete.** All nine `SetPositionCore` duties
  land in `CommitCanonicalTeleportFrame`
  (`PlayerMovementController.cs:1993-2041`) or the canonical commit, in
  `SetPositionCore`'s own order (StopCompletely → input/mouse resets →
  UnStick/UnConstrain/re-arm → edge resets → clock reset). Nothing
  silently dropped except the TransientState seed, which is correct
  (§A).
- **Inversions implemented in the right directions.** The portal arm
  consumes the classifier's dormant LocalPlayer-teleport branch
  (`RuntimeAuthoritativePositionRouteClassifier.cs:336-356`) unchanged;
  `ConstrainPhase.AfterPositionOperation` + `ZeroVelocity: true` +
  `SendPositionImmediately: false` + `TeleportHookPhase.AfterPositionOperation`
  all flow through. The hook tail runs only from the committed receipt.
- **The force arm is untouched.** The only route-2 edits are one
  force-scoping doc sentence (`:133-137`) and a non-`required`
  `Portal { get; init; }` on `Pending` that defaults empty. Zero route-2
  test expectation changes — §4 item 8's tripwire is clean.
- **The synthetic `priorTeleport = accepted - 1`** in
  `ClassifyPortalArrival` is sound: `TeleportAdvanced` reads only the
  boolean `PhysicsTimestampGate.IsNewer(prev, accepted)`, the branch's
  resulting route does not depend on the previous stamp's magnitude, and
  wrap is safe at `accepted == 0`.
- **AD-42 deleted** (row gone, header 49 → 48 rows), **AD-2 amended in
  place** with the deferred-place timing, the T8 tolerated-overwrite
  note, and the leash-anchor nuance. Plan gap-line correction present.
  Register rules satisfied.
- **Release build green.** Focused
  `RuntimeAcceptedPositionDriveControllerTests`: 22 passed / 0 failed /
  **0 skipped**. No `Skip` attribute remains in any of the four touched
  test files, and no Runtime test was weakened — the five new ones are
  strong (the happy path pre-arms the leash at a *stale* anchor so a
  missing re-arm fails the `ConstraintPos` assertion; the refusal tests
  assert positive "nothing moved, transit still active, no packets"
  facts).

## §C — the production bug fix: correct, complete, no stale-destination hazard

Verified. `RuntimeWorldTransitState.TryBeginPortalReveal:159-182` sets
`_hasAcceptedDestination = false` and `_acceptedDestination = default`
the instant it claims the generation, and
`TryGetAcceptedTeleportDestination:522-527` returns
`_teleportActive && _hasAcceptedDestination`. So the pre-fix Place-time
re-read was **guaranteed** to fail — the canonical portal arm was 100 %
dead code, refusing with `cause=host-token-unavailable` before ever
reaching Runtime. The diagnosis is right and this was a real production
bug, not a fixture artifact.

The fix is the right lifetime:

- `_pendingDestination` is written in `AimDestination:781-784`, in the
  same statement block as `_pendingCell`/`_pendingRotation`, only after
  `TryBeginPortal` succeeded (`:741-748`) — so the four Aim-time
  snapshots are mutually consistent by construction.
- **Cancellation:** `ResetTransit:801-804` clears all four; every
  cancellation path funnels through it.
- **Supersession:** a second accepted destination re-enters
  `TryAimAcceptedDestination` → `AimDestination` →
  `WorldRevealCoordinator.TryBeginPortal` → `WithdrawHostForReplacement`
  + a **new** generation, overwriting all four snapshots together. A
  superseded destination cannot survive.
- **Staleness at Place:** three independent gates still validate —
  `CanPlacePortalDestination(_pendingRevealGeneration, sequence, _pendingCell)`
  (`:507-511`), the idempotent
  `TryRegisterHostProjection` re-derivation (generation ==
  `_snapshot.Generation`, cell == `_snapshot.DestinationCell`,
  `!Cancelled`, `!Completed` — `RuntimeWorldTransitState.cs:189-227`),
  and `BeginAcceptedPlacementCore`'s own
  `portal.Projection.DestinationCell == acceptedPosition.LandblockId`
  against the **latest merged** snapshot
  (`RuntimeSetPositionState.cs:1528-1534`).

The re-read was protecting nothing. `WorldRevealCoordinator.BeginHostLifetime`
throws if the Aim-time registration fails, so the Place-time
re-derivation is genuinely idempotent and can never mint a second host
projection in production.

## §D — contract open questions, answered

**(b) leash anchor — keep the resolved anchor as shipped.** Retail's
`constraint_pos` is write-only (never read by `adjust_offset`, confirmed
in the port's own doc at `ConstraintManager.cs:41-44` and against ACE);
the only downstream consumer of `ConstrainTo`'s inputs is
`constraint_pos_offset = distance(anchor, m_position)`, which is the
placement adjustment (centimetres) in retail and exactly 0 in acdream.
Both are orders of magnitude inside the `0.9 * max` band, so no behaviour
in the leash's brake taper can distinguish them. The AD-2 note is the
right disposition; do **not** switch anchors.

**(c) `SendMovementEvent` shape — see R7.** Message family, contact
derivation, count, and ordering are all correct; the missing
`autonomy_level` gate is the one delta.

## §E — errors in the contract itself

1. **§4 item 3 / D-T5's re-attempt reasoning is the proximate cause of
   R1.** D-T5 offered "the anim event re-fires while `ready` holds" as
   the leading case and demoted the one-shot case to a parenthetical
   verify-and-state. It is one-shot. The contract should have read the
   sequencer before writing the row and pinned the driver. This is
   process rule 1 ("the contract causes the defect") recurring for the
   third documented time.
2. **§9's `leash=armed` criterion is unachievable** with any
   `IsFullyConstrained`-shaped observable; the contract should have named
   `ConstraintManager.IsConstrained`. See R3.
3. **§3.5 overstates the change:** "`AcknowledgePortalMaterialized` fires
   from the committed placement receipt instead of rubber-stamping after
   a host mutation." As built it still fires from the host Place edge,
   merely gated on a committed status. Substantively equivalent on the
   commit path; wording should be corrected so a future reader does not
   look for a receipt-driven ack that does not exist.
4. **§1's `enter_world` row** carries the same wrong caller attribution
   the banner does (R6) — it says "its local-player caller is the initial
   login path only (@0x00455095)", which is right about that site but
   silently drops the *other* site @0x004550EC and mis-names the
   enclosing function in the derived correction.

## What must land before this can pass

1. A re-attempt (or explicit-cancel) mechanism for a non-`Committed`
   Place edge, with the driver named and tested — R1.
2. Headless must consume the arm's status and must not acknowledge a
   materialization for a placement that did not commit — R2.
3. Fix the probe's `leash` observable (and emit a line per *attempt*,
   under the gate's own env var) — R3, R8.
4. Write the App-layer presentation suite (§8 items 8/9/10) closing route
   2's B2 gap, plus one headless committed-portal test — R4, R5.
5. Correct the `enter_world` caller-sweep banner — R6.
6. Gate the movement refresh on autonomy, or file the register row — R7.
7. Comment/citation cleanups — R9, R10, R11.