acdream/docs/research/2026-08-04-c4-routes-6-7-scoping.md

# C4 routes 6 and 7 — scoping (2026-08-04)

Read-only research. Worktree
`C:\Users\erikn\source\repos\acdream\.claude\worktrees\peaceful-visvesvaraya-e0a196`,
branch `claude/acdream-physics-divergence-5aa784`, HEAD `d5bdc355`.

Scoped together deliberately: the campaign groups route 6 (drops +
split-recovery marking) and route 7 (residual pickup/parent/delete polish) as
adjacent item/container work. **They turn out not to share a single production
file.** The reason to keep them in one document is different from the reason
they were paired: both routes' premises in
[`2026-08-02-cutover-route-inventory.md`](2026-08-02-cutover-route-inventory.md)
were written **before C3c flipped both hosts' Create paths onto the residence
lease**, and both are now substantially or entirely satisfied by that flip.
Splitting the scoping would have produced two documents each re-deriving the
same C3c correction.

**Headline: route 6 requires no production change. Route 7 has exactly one
real defect, and it is a two-writer split on the child's canonical cell —
which is also the reason headless has no parent-realize sequence at all.**

---

## 0. The correction that governs both routes

The inventory's route-6 and route-7 sections both rest on this claim
(`2026-08-02-cutover-route-inventory.md:759-767`, repeated at `:806-824`):

> `RegisterEntityWithInitialResidence` is never called from any production
> path (confirmed by full-repo grep …). Both drop flavors equally bypass the
> canonical create-placement transaction.

**That is no longer true.** C3c (`529e0e9d`) flipped both hosts:

- Graphical: `src/AcDream.App/World/LiveEntityRuntime.cs:544-548` —
  `_entityObjects.RegisterEntityWithInitialResidence(incoming, isLocalPlayer,
  RetirePriorProjection)`, with the C3c rationale comment at `:538-543`.
- Direct/headless: `src/AcDream.Runtime/Session/RuntimeLiveEntitySessionController.cs:118-123`
  — the same call, except for the deliberately-excluded content-less host
  (comment `:108-117`).

Route 7's inventory paragraph "these cancellation calls are structurally
present but functionally no-ops against always-empty state" is likewise
obsolete: `InitialCreateResidences` is populated in production now, so every
`ForgetInitialCreateResidence` in the pickup/parent/delete family is live.

Anything in the inventory's routes 6/7 sections that reasons from
"nothing upstream to cancel" must be re-derived, not cited.

---

# ROUTE 6 — drops and unparent-to-world

## 6.1 What the route actually is

**There is no route-6 classifier disposition and no route-6
`RuntimePositionEntityKind`.** A dropped item is an ordinary non-local
CreateObject:

- `RuntimePositionEntityKind.Remote`
  (`src/AcDream.Runtime/Physics/RuntimeAuthoritativePositionRouteClassifier.cs:8-14`).
- `RuntimeCreateResidenceKind.TopLevel`, produced at
  `src/AcDream.Runtime/Entities/RuntimeInitialCreateResidenceState.cs:603-606`
  (`Parented` when the wire frame carries a parent, `PickedUp` when it has
  neither parent nor position).
- `ClassifyCreate` (`RuntimeAuthoritativePositionRouteClassifier.cs:205-275`)
  returns disposition `SetPosition` with
  `InitialCreateFlags = Placement | Slide` (`:168-170`, applied `:254-258`).

That is byte-for-byte route 1's create classification. Route 6 is a *source*
of route-1 traffic, not a route of its own.

## 6.2 Both drop flavors already converge on the canonical transaction

**Whole-item drop.** `ItemInteractionController.ExecutePlacementActions`,
`DropToWorld` case
(`src/AcDream.App/UI/ItemInteractionController.cs:974-991`): optimistic
`MoveItemOptimistic(objectId, newContainerId: 0u, newSlot: -1)` then
`_sendDrop(objectId)`. No physics, no position. The server's CreateObject
comes back through the ordinary wire pump into
`LiveEntityHydrationController.OnCreate` → `_runtime.RegisterLiveEntity` →
`RegisterEntityWithInitialResidence` (`LiveEntityRuntime.cs:544-548`).

**Split-to-world.** Same file `:992-1013` (`SplitToWorld` case) raises
`WorldDropDispatched`; `InventoryWorldDropProjectionController.OnWorldDropDispatched`
(`src/AcDream.App/World/InventoryWorldDropProjectionController.cs:81-98`)
records the pending identity; the new GUID's F748 Position is recovered by
`TryRecoverUnknownPosition` (`:54-68`), which calls **`_hydration.OnCreate(spawn)`
at `:66` — the identical entry point**. Same residence lease, same conductor,
same placement.

**Therefore the campaign handoff's route-6 requirement
(`2026-07-31-remaining-physics-campaign-handoff.md:357-362`) —
"`TryRecoverUnknownPosition` may create the logical object, but it must enter
the same canonical create-placement transaction" — is already met, by C3c, with
zero route-6-specific code.**

## 6.3 "Do not expose a stale source position" — satisfied

`PendingSplitToWorldProjection.BuildSpawn`
(`InventoryWorldDropProjectionController.cs:171-209`) overrides every
positional field from the arriving update:

| Field | Line |
|---|---|
| `Physics.Position` | `:179` |
| `Physics.Parent = null` | `:180` |
| `Physics.Velocity` | `:181` |
| `Physics.Timestamps.{Position,Teleport,ForcePosition,Instance}` | `:182-188` |
| DTO `Position` | `:194` |
| DTO `ContainerId = 0`, `WielderId = 0`, `CurrentWieldedLocation = 0` | `:197-199` |
| DTO `{Instance,Position}Sequence`, `ParentGuid = null`, `ParentLocation = null`, `PlacementId` | `:200-206` |

No source pose survives into the synthetic spawn.

## 6.4 "Do not replay create-time effects" — NOT ESTABLISHED as a defect

The inventory calls this "a genuine new capability, not merely dormant"
(`2026-08-02-cutover-route-inventory.md:768-775`). I could not find a reachable
defect behind it, and the retail decomp says there should not be one.

**acdream's only create-time effect replay is the F754/F755 network queue
drain, keyed by server GUID.** `LiveEntityReadyPublisher.Publish` calls
`effects.ReplayPendingForLiveEntity(record.ServerGuid)`
(`src/AcDream.App/World/LiveEntityHydrationPorts.cs:97`, body at
`src/AcDream.App/Rendering/Vfx/EntityEffectController.cs:199-205`). That queue is
written only by `HandleDirect`/`HandleTyped`
(`EntityEffectController.cs:92-126`) from inbound `PlayPhysicsScript` /
`PlayPhysicsScriptType` for that exact GUID. A fresh split GUID has nothing
queued unless ACE actually sent an effect for it — and draining it then is
retail's own behaviour, which the class documents and ports:
`SmartBox::HandlePlayScriptID @ 0x00452020` / `HandlePlayScriptType
@ 0x00452070` queue while the object is absent, and
`SmartBox::HandleCreateObject @ 0x00454C80` drains through
`ProcessObjectNetBlobs` (cited `EntityEffectController.cs:17-24, :37-45`).

**The one plausible mechanism — a cloned default script — does not fire at
create in either client.** `BuildSpawn` does clone `DefaultScriptType` /
`DefaultScriptIntensity` from the source (they are not in the override list;
fields at `src/AcDream.Core.Net/Messages/PhysicsSpawnData.cs:58-59`), and they
reach `EntityEffectProfile.RawDefaultScriptType`
(`src/AcDream.App/Rendering/Vfx/EntityEffectProfile.cs:67`). But acdream's
`PlayDefault` (`EntityEffectController.cs:409-418`) has exactly two callers,
both animation hooks: `DefaultScriptHook` and `DefaultScriptPartHook`
(`:428-435`). Retail matches: `CPhysicsObj::play_default_script @ 0x005132B0`
/ `@ 0x00513300` is reached only from `ACCWeenieObject::DoCollision
@ 0x0058C3A0` (call @0x0058C3B4) and the animation-hook dispatcher
(@0x00526C08, @0x00526C14). **Neither client plays a default script from
`set_description` or CreateObject.**

**Live evidence that would settle it if someone still doubts:** split a stack
of a WCID whose PhysicsDesc carries a nonzero `DefaultScriptType` and watch for
a script at the drop. Per the two call-site sets above there is none to
observe, so this is a confirmation, not an open question.

## 6.5 Retail truth for drops and for "split-recovery marking"

**Whole-item drop.** `ACCWeenieObject::UIAttemptPutIn3D @ 0x0058D700`: gate on
`IsPlayerReadyToMakeInventoryRequest` @0x0058D70F, send
`CM_Inventory::Event_DropItem` @0x0058D715, then record only
`prevRequest = IR_MOVE` (@0x0058D74F) or `IR_DROP` (@0x0058D731). **No
placement call, no split marker, no client-side position.** The dropped object
re-enters the world through the ordinary CreateObject path.

**Split.** `ACCWeenieObject::UIAttemptSplitTo3D @ 0x0058D850` sends
`Event_StackableSplitTo3D` @0x0058D86B and then records exactly three fields:
`splitStackSize = arg2` @0x0058D8A2, `splitClassID = this->pwd._wcid`
@0x0058D8A8, `splitTime = cur_time` @0x0058D8AE.
`ACCWeenieObject::UIAttemptSplitToContainer @ 0x0058D7D0` records the
**identical three fields** at @0x0058D82D / @0x0058D833 / @0x0058D838.

**The marker's consumer is `ACCWeenieObject::DeclareValid @ 0x0058E340`:**

```
splitClassID read                                  @0x0058E44A
if (splitClassID != INVALID) {
    if (splitClassID == this->pwd._wcid)           @0x0058E462
        stack = this->pwd._stackSize; if (0) 1     @0x0058E464-@0x0058E46E
        if (splitStackSize == stack) {             @0x0058E479
            ACCWeenieObject::SetSelectedObject(this->id, 0);   @0x0058E481
            splitClassID = INVALID; return;                    @0x0058E490
        }
    if (cur_time - splitTime >= 10.0)              @0x0058E49F-@0x0058E4B0
        splitClassID = INVALID;                    @0x0058E4B2
}
```

**So retail's "split-recovery marking" is (i) a WCID + stack-size + 10-second
identity recorded for BOTH split flavors, and (ii) a recovery action that is a
SELECTION TRANSFER — `SetSelectedObject` — not effect suppression and not
anything placement-related.**

acdream implements (i) partially and (ii) not at all:

- The 10-second window is exact: `PendingSplitToWorldProjection.RetailRecognitionSeconds = 10.0`
  (`InventoryWorldDropProjectionController.cs:113`), enforced `:146-153`.
- The match is **"any unknown GUID that is not the source"** (`:155-156`), not
  WCID + stack size, because ACE's F748 carries neither. This is the
  already-registered **AP-124**
  (`docs/architecture/retail-divergence-register.md:274`), which cites both
  retail symbols correctly.
- acdream records the marker only for `InventoryRequestKind.SplitToWorld`
  (`:86`); retail records it for split-to-container too.
- No `SetSelectedObject` equivalent runs. The controller's constructor
  (`:33-52`) takes interaction / objects / runtime / hydration / clock and has
  no selection dependency at all.

## 6.6 Route 6 — what remains

**Nothing that C4 must do.** The three genuine residuals are:

| # | Item | Kind |
|---|---|---|
| R6-a | `DeclareValid`'s `SetSelectedObject(this->id, 0)` @0x0058E481 is not ported — the split result does not become the selected object, and the container-split flavor has no marker at all | UI/selection behaviour, **not placement**; file as an issue, out of C4 scope |
| R6-b | AP-124's WCID/count approximation | already registered; retiring it needs ACE to send CreateObject to the initiator, not a client change |
| R6-c | `BuildSpawn` clones `Children`, `Movement`, `AnimationFrame`, `SetupTableId` etc. wholesale from the source | **not established** as a defect: a stackable inventory item's `Children` should be empty and its `Movement` inert. Settled by dumping a source spawn's `PhysicsSpawnData` at a live split — one `ACDREAM_DUMP_*`-style probe, or an assertion in the new tests |

**Recommended route-6 landing: evidence + tests only, no production diff.**
Add the coverage the campaign handoff's route-6 test list names
(`2026-07-31-remaining-physics-campaign-handoff.md:363-365`) against the
now-flipped path: whole item, split stack, new GUID, second drop position,
unavailable destination, newer Position while waiting. Note that "attached
child becoming a world root" from that list is **not route 6's** — it is a
cell-less Position on an existing entity, owned by 4b-3.

## 6.7 Route 6 — line budget

- **Production: 0 lines** for the campaign mandate. If R6-a is adopted inside
  C4 (I recommend against it — it is selection UX, and mixing it in makes the
  landing un-reviewable against a placement contract), **40-80** lines.
- **Tests: 150-250 lines.** Route 4a was 364 production lines; this is an
  order of magnitude below the threshold where splitting is a question.

## 6.8 Route 6 — connected gate

Cheap and directly visible.

1. Stand on open ground in Holtburg. Drop a whole item from inventory (drag to
   3D or the drop action). It must appear **at your feet**, resting on the
   ground, immediately, and be pickable.
2. Split a partial stack of a stackable (e.g. pyreals) to the ground. Same
   result, with the correct quantity on the new pile and the remainder still
   in inventory.
3. Drop a second item within ~1 m of the first. Both must remain visible and
   separately pickable.
4. Repeat once indoors (an inn interior) and once immediately after a portal
   recall.
5. Walk two landblocks away and back. Both piles must still be there and still
   pickable.

**Regressions to watch for:** the item appears at the world origin or at your
*previous* position (stale pose); the item is invisible but blocks you
(invisible-but-solid, the #184 class); the item sinks into or floats above the
floor; the item cannot be picked up; the split pile never appears at all
(the recovery window failed); the second drop is swallowed by the first.

---

# ROUTE 7 — pickup, parent, and delete

## 7.1 What the route actually is

**Dispositions.** Route 7's classifier surface is
`RuntimeAuthoritativePositionRouteClassifier.ClassifyLeaveWorld`
(`:475-505`), taking a `RuntimeLeaveWorldRouteRequest` (`:141-145`) whose
`RuntimeLeaveWorldCause` is `Pickup` or `Parent` (`:31-36`). It returns
disposition `AwaitFreshPosition` with `LeaveWorld: true`,
`SetPositionFlags.None`, `ConstrainPhase.None`, and no teleport hook.

The create-side siblings are `RuntimeCreateResidenceKind.Parented` and
`PickedUp`, which `ClassifyCreate` routes to the same `AwaitFreshPosition` /
no-SetPosition branch (`:219-241`), with the comment at `:230-233` stating why
initial residence invents no withdrawal edge.

**`ClassifyLeaveWorld` has ZERO production callers.** Repo-wide grep returns
its own definition and exactly one test
(`tests/AcDream.Runtime.Tests/Physics/RuntimeAuthoritativePositionRouteClassifierTests.cs:341-342`),
plus a comment in `RuntimeInitialCreateContinuationExecutorTests.cs:1672`
noting that `ApplyPositionAction` does not call it. Every production pickup /
parent / delete performs its leave-world work by hard-coded sequence inside
`RuntimeEntityObjectLifetime`, never through the classifier.

**Entity kind** is whatever the object is — `Remote` for items, and the
classifier's `OperationKind(kind, initialCreate: false)` derives from it.

## 7.2 Retail truth: route 7 performs NO placement

This is the single most important fact for scoping route 7, and it inverts the
trap list that governed routes 2 / 4a / 4b.

**Pickup — `SmartBox::DoPickupEvent @ 0x00452240`:**

```
gate on obj->update_times[0] (the POSITION stamp)   @0x0045224B-@0x00452274
    obj->update_times[0] = incoming                 @0x00452278
    CPhysicsObj::unset_parent(obj);                 @0x0045227F
    CPhysicsObj::leave_world(obj);                  @0x00452286
```

No `SetPosition`, no `MoveOrTeleport`, no `ConstrainTo`, no placement flags.

**Parent — `SmartBox::DoParentEvent @ 0x00452290`:**

```
gate on child->update_times[0]                      @0x00452296-@0x004522C5
    if (child had no parent && parentId != player)
        parentWeenie->SetParentedState(1);          @0x004522F4
    CPhysicsObj::set_parent(child, parent, loc);    @0x00452305
    CPhysicsObj::SetPlacementFrame(child, arg5, 1); @0x00452313
```

**`CPhysicsObj::set_parent @ 0x00515A90` (3-arg):**

```
if (parent != 0 && add_child(parent, this, loc) != 0) {   @0x00515A9D
    unset_parent(this);                                   @0x00515ABA
    leave_world(this);                                    @0x00515AC1
    this->parent = parent;                                @0x00515AC6
    if (parent->cell != 0) {                              @0x00515AD1
        change_cell(this, parent->cell);                  @0x00515AD6
        UpdateChild(parent, this, part_number, frame);    @0x00515B0E
        recalc_cross_cells(this);                         @0x00515B15
    }
    if (parent->state & NODRAW-bit) {                     @0x00515B26
        this->state |= 0x20;
        part_array->SetNoDrawInternal(1);                 @0x00515B38
    }
    return 1;                                             @0x00515B45
}
return 0;                                                 @0x00515B4D
```

The 4-arg overload @0x00515B50 is the same shape, minus the `CHILDLIST`
index lookup and plus `m_bExaminationObject` inheritance @0x00515B76.

**`CPhysicsObj::unset_parent @ 0x00513470`:** `CHILDLIST::remove_child`
@0x00513484 → NoDraw restore @0x00513495-@0x005134A7 → `parent = null`
@0x005134AC → `update_time = cur_time` @0x005134BF → tailcall
`clear_transient_states` @0x005134CE.

**Conclusion.** Route 7's entire mandate in this campaign is the one the
campaign handoff already states
(`2026-07-31-remaining-physics-campaign-handoff.md:367-373`): pickup / parent /
delete must **cancel** the exact active placement / lost-cell family first and
publish `Discard`/`Withdraw` before the later entity delta. There is no
placement to port, no leash, no distance threshold, no flags.

## 7.3 What is already canonical (verified, not assumed)

**Every cancellation choke point exists and is live.** Six sites in
`src/AcDream.Runtime/Entities/RuntimeEntityObjectLifetime.cs`, each running the
identical `ForgetInitialCreateResidence` → `Physics.SetPosition.Forget` →
`PreferCancellation` sequence and threading the receipt into
`AcknowledgeProjectionAndPublish`:

| Method | Cancellation lines |
|---|---|
| `CommitPositionChannelUpdate` | `:1074-1094` |
| `TryApplyPickup` | `:1226-1245` |
| `TryCommitParent` | `:1360-1374` (added at C0; rationale `:1344-1359`) |
| `CommitAcceptedParentCellless` | `:1390-1407` |
| `CommitWithdrawal` | `:1845-1860` (added at C0; rationale `:1837-1844`) |
| `TryAcceptDelete` | `:1939-1952` |

`ForgetInitialCreateResidence` is at `:2552-2569`; `PreferCancellation`
(initial wins over ordinary) at `:2571-2574`.

**The two C0 asymmetries the inventory flagged (`:826-837`) are FIXED.**
`TryCommitParent` had no choke point at all; `CommitWithdrawal` cancelled only
the residence family. Both now cancel both families, and both carry the
explanatory comment naming the C0 finding. `TryCommitParent`'s deliberate
omission of `Physics.CollisionReports.LeaveWorld` is documented `:1352-1359`
against `set_parent @ 0x00515A90`'s single gated `leave_world` @0x00515AC1 —
**do not "fix" this; the campaign contract already pins it.**

**Ordering is correct.** `AcknowledgeProjectionAndPublish` (`:2187-2213`) runs
`Physics.SetPosition.PublishCancellation(cancellation)` as its **first**
statement at `:2194`, before the currency re-check, before the host
acknowledgement callback, and before `PublishEntity`. That is exactly the
handoff's "publish `Discard`/`Withdraw` before the later entity/inventory
delta."

**Cancellation receipts ARE host-visible.**
`RuntimeSetPositionState.PublishCancellation` (`:5296-5309`) republishes the
retained `Discard`-kind `RuntimePlacementProjectionSnapshot` through
`PublishPlacement`, i.e. through the same one placement stream. Both hosts
consume the kind: `src/AcDream.App/World/RuntimePlacementPresentationSink.cs:102`,
`src/AcDream.App/World/LiveEntityRuntime.cs:1179`, and
`src/AcDream.Headless/Hosting/HeadlessRuntimePlacementProjectionSink.cs:27`.
**The C0 note "route-7 needs … host-visible cancellation receipts" is
satisfied.**

**Pickup/parent during a pending residence already defer.** `TryApplyPickup`
`:1189-1215` enqueues a dormant `RuntimeInitialCreateContinuationKind.Pickup`
continuation when `TryGetPendingInitialResidence` hits; `TryApplyParent` and
`TryApplyMotion` have the same shape.

**App and headless carry no duplicate placement authority for route 7.**
`LiveEntityDeletionController` (102 lines) is purely logical.
`LiveEntityHydrationController.OnPickup` (`:455-474`) calls
`_runtime.TryApplyPickup` then `_relationships.OnChildBecameUnparented`.
Headless `OnPickedUp` / `OnDeleted` / `OnParentUpdated`
(`RuntimeLiveEntitySessionController.cs:176-180, :155-174, :313-317`) are thin
pass-throughs. Grep for `SnapToCell` / `CommitRebucket` / `SuspendObjectClock`
/ `SetFullCell` across `src/AcDream.App` and `src/AcDream.Headless` returns no
pickup/parent/delete site.

## 7.4 The one real defect — the child's canonical cell has two writers

This is route 7's whole substance.

**Retail** puts the child in the parent's cell **inside `set_parent`**:
`change_cell(this, parent->cell)` @0x00515AD6 followed by
`recalc_cross_cells(this)` @0x00515B15, gated on `parent->cell != 0`
@0x00515AD1.

**acdream splits that in half across two assemblies:**

1. Runtime commits the child **cell-less, unconditionally**.
   `RuntimeEntityObjectLifetime.CommitAcceptedParentCellless` (`:1377-1408`)
   runs `Physics.CollisionReports.LeaveWorld` `:1396`,
   `Entities.SuspendObjectClock` `:1397`, `Entities.SetFullCell(canonical, 0u,
   0u)` `:1398`. Its App wrapper's doc comment
   (`LiveEntityRuntime.cs:2288-2292`) claims it "commits retail
   `CPhysicsObj::set_parent`'s cell-less edge" — accurate only for the
   `parent->cell == 0` case; retail's `parent->cell != 0` case immediately
   re-cells the child and acdream never performs that half in Runtime.
2. **App re-cells the child from a presentation tick.**
   `EquippedChildRenderController.TickChild` `:405-408` calls
   `_liveEntities.RebucketLiveEntity(child.ChildGuid, parentCellId)`, and the
   public `LiveEntityRuntime.RebucketLiveEntity` (`:801-977`) is *not*
   presentation-only — it writes the canonical cell through
   `_entityObjects.CommitRebucket(record.Canonical, committedFullCell,
   committedLandblock)` at `:904-907`.

So the canonical `FullCellId` of every equipped child is produced by a
per-frame render-composition tick, not by the parent commit. Two consequences,
and they are the same bug seen from two sides:

- **Headless leaves every parented child cell-less forever.**
  `RuntimeLiveEntitySessionController.OnParentUpdated` (`:313-317`) calls only
  `Entities.TryApplyParent`. Neither `TryCommitParent` nor
  `CommitAcceptedParentCellless` has any headless caller — repo grep finds only
  `EquippedChildRenderController.cs:869` and the App wrappers at
  `LiveEntityRuntime.cs:2280-2312`. There is no headless
  `EquippedChildRenderController`, so nothing ever supplies step 2. The
  inventory called this a "headless-specific gap, pre-existing, adjacent"
  (`:839-853`) — it is not adjacent, it is the *same* missing commit.
- **The two-store shape is exactly the failure class this campaign exists to
  remove**, and it is the shape the trap list names ("two separate snapshot
  stores for one piece of state").

**Fix shape:** move the parent-cell commit into `TryCommitParent` /
`CommitAcceptedParentCellless` (i.e. perform retail's `parent->cell != 0` half
in Runtime, gated the same way), and demote App's `TickChild` rebucket to
presentation-only — `RebucketLiveEntityPresentationOnly`
(`LiveEntityRuntime.cs:993-1050`) is the existing shape, added by C3c for
exactly this "Runtime already owns the canonical commit" case. Headless then
gets the correct child cell for free.

## 7.5 The second item — `ClassifyLeaveWorld` is dead

Either wire pickup/parent through it so route 7 stops being the one route with
hard-coded dispositions, or delete it and record why the hard-coded sequence is
the right shape. Leaving a classified disposition with one test and no
production caller is how routes 2 and 4 accumulated their divergences.

I lean **wire it**, because the cause discriminator (`Pickup` vs `Parent`)
is the thing that decides whether `EndChildProjection` runs, and today that
decision is implicit in *which method the caller picked*.

## 7.6 Route 7 — line budget

| Piece | Production lines |
|---|---|
| Runtime child-cell commit in `TryCommitParent` / `CommitAcceptedParentCellless` (retail's `change_cell` + `recalc_cross_cells` half, gated on parent cell) | 120-180 |
| Demote `EquippedChildRenderController.TickChild`'s rebucket to presentation-only + the follow path that replaces it | 60-100 |
| Headless parent-realize drive (`OnParentUpdated` → the same commit) | 60-100 |
| Wire or delete `ClassifyLeaveWorld` | 60-150 |
| **Total** | **300-490** |

Calibration: route 4a was 364 non-comment production lines, 4b-1 was 230 + a
57-line park fix. **Route 7 fits one slice and must not be split** — the child
cell commit and the App demotion are the two halves of one transfer and cannot
land separately without leaving the child cell-less in the interval. Test work
~400-700 lines.

If the implementation crosses **550** production lines, stop and report; the
most likely cause would be discovering that the per-tick follow (7.8, T5) needs
its own Runtime mechanism, which is a second slice.

## 7.7 Route 7 — connected gate

Two clients. `+Acdream` plus a second character observing.

1. **Equip / unequip cycle.** Wield a weapon, then a shield, then unwield both,
   five times, while the observer watches. The weapon must appear in the hand,
   at the hand, oriented with the hand, and disappear cleanly on unwield.
2. **Carry across a landblock boundary.** With the weapon equipped, run across
   at least two landblock boundaries and back, both while the observer watches
   and while observing the other character do it.
3. **Pickup.** Drop the weapon, pick it back up. It must leave the ground
   (route 7's `leave_world`) and re-appear equipped or in inventory with no
   ghost left on the ground.
4. **Delete under load.** Kill something and loot its equipped items.
5. **Reconnect.** Log out with equipment and back in; the equipment must
   re-attach.
6. **Headless.** Run the headless bot with an equipped item and assert the
   child's canonical `FullCellId` equals the parent's at a stable checkpoint —
   this is the direct regression test for 7.4, and it fails **today**.

**Regressions to watch for:** the equipped weapon draws at the world origin or
at its last ground position; the weapon is invisible while equipped;
**invisible-but-solid** — the weapon's collision remains at the drop site after
being picked up; the weapon is left behind when the wearer crosses a landblock
boundary (this is the R1/#184 class and is the specific risk of demoting the
tick rebucket); the child is culled when the parent is visible or vice versa;
a picked-up item still blocks movement.

## 7.8 Traps

Mapped to the shapes that already bit this campaign, plus route-7-specific
ones.

**T1 — the inverse leash trap. Route 7 must NOT arm `ConstrainTo`.**
4b-2's contract correctly says "arm on refusal and rejection too" because
`MoveOrTeleport` returns 1 regardless and `HandleReceivedPosition` @0x00454254
arms @0x00454272. **Route 7 never reaches `HandleReceivedPosition` at all** —
`DoPickupEvent` @0x00452240 and `DoParentEvent` @0x00452290 are separate wire
handlers. An implementer arriving from 4b-2 will carry the "always arm" rule
across. There is no leash on this route.

**T2 — deleting the only handler for a rejected classification.**
`ClassifyLeaveWorld` returns `RejectedAuthority` when
`Cause is RuntimeLeaveWorldCause.Unknown` or `ValidCreateAuthority` fails
(`:481-487`). Retail's `DoPickupEvent` has **only** a stale-timestamp no-op —
there is no "rejected" outcome that skips `unset_parent`/`leave_world` once the
stamp is accepted. If route 7 wires the classifier and performs the leave-world
only on `Accepted`, every rejected classification silently drops a pickup. This
is 4b-2's `null`/`Rejected*` trap, one level up: state the policy explicitly.

**T3 — `ValidCreateAuthority`'s teleport-equality predicate is the #307
shape.** `ClassifyLeaveWorld` gates on `ValidCreateAuthority` (`:507-512`),
which requires `PreviousTeleportSequence == AcceptedTeleportSequence`. That is
exactly the predicate #307 (`19d95094`) had to fix on the live Position path,
where `PreviousTeleport` was always 0 and every previously-teleported entity
failed it. Before wiring T2's classifier, **verify first-hand** that the
pickup/parent authority actually populates `PreviousTeleportSequence`, and that
retail's own gate is the *position* stamp (`update_times[0]` @0x0045224B), not
a teleport stamp at all — the two may simply not correspond.

**T4 — do not carry `MoveOrTeleport`'s guards onto this route.** AP-87's 4 m
`BodySnapThreshold` and `!willBeDrTicked` conditions and the 96 m
`MaxPhysicsDistance` are near/far *interpolation* decisions inside
`MoveOrTeleport @ 0x00516330`. Pickup and parent have no distance concept.
Importing any of them is the "carry a guard onto a branch that does not need
it" shape AP-87's own row and the 4b-2 contract both warn about.

**T5 — demoting the tick rebucket can reproduce #184 / route-4a's R1.**
`EquippedChildRenderController.TickChild`'s rebucket (`:405-408`) runs on every
recomposition, and `LiveEntityRuntime.RebucketLiveEntity` is what moves the
GPU draw bucket, sets `IsSpatiallyVisible`, calls `RefreshPresentation`, and
publishes `ProjectionVisibilityChanged` (`:844-953`). Route 4a's R1 finding was
precisely that gating this call left a creature body-and-shadow-correct but
draw-bucket-stale — **invisible but solid**. The replacement must keep the
child following the parent across cell boundaries.
**Retail-side status: PARTIALLY ESTABLISHED.** `CPhysicsObj::UpdateChild
@ 0x00512D50` composes the frame and calls `CPhysicsObj::set_frame(child, …)`
@0x00512D8D; `set_frame @ 0x00514090` writes `m_position.frame` @0x005140E9,
pushes it to the part array @0x00514101, and cascades
`UpdateChildrenInternal` @0x00514108 — **it never touches `objcell_id` or
`cell`.** So retail's per-move child update is frame-only, and the child's cell
is established once at `set_parent`'s `change_cell` @0x00515AD6. **Whether a
parent crossing a cell re-cells its children is NOT established** from
`UpdateChild`/`set_frame`/`UpdateChildrenInternal` alone. Settle it before
demoting: read `CPhysicsObj::change_cell` / `CPhysicsObj::set_cell`'s child
handling, or take a cdb trace with breakpoints on
`CPhysicsObj::change_cell` and `CPhysicsObj::UpdateChildrenInternal` while a
retail character carrying an equipped weapon walks across a landblock boundary.

**T6 — the pre-flight-guard trap probably does NOT apply, and saying so
matters.** 4b-1's finding was that a pre-flight service-window guard cannot see
conditions only Core can see (`AdjustToOutside` residency,
`ResultTouchesPrefix` over `QueriedCellIds`). Route 7's child-cell commit is
retail's `change_cell` — **no sweep, no `AdjustPosition`, no placement** — so
there is no deferrable Core condition to miss. Do not import 4b-1's
service-window machinery here. If an implementer finds a reason a child cell
commit *can* defer, that is a new finding and needs its own stop-and-report.

**T7 — ordering divergence on pickup, significance NOT ESTABLISHED.** Retail
runs `unset_parent` @0x0045227F **before** `leave_world` @0x00452286. acdream
inverts it: `RuntimeEntityObjectLifetime.TryApplyPickup` runs
`Physics.CollisionReports.LeaveWorld` `:1229` → `SetFullCell(0,0)` `:1235` →
`ParentAttachments.EndChildProjection` `:1236`, and at the App layer
`LiveEntityHydrationController.OnPickup` (`:460-473`) runs `TryApplyPickup`
first and `OnChildBecameUnparented` second. The two operations touch different
structures (collision reporting vs the relation table), so I could not
construct a case where the order is observable — but I did not prove it inert.
Decide deliberately and record the decision; do not silently preserve the
inversion because "tests are green".

**T8 — do not add a second `LeaveWorld` to `TryCommitParent`.** Already pinned
by the campaign plan and by the in-code comment at `:1352-1359`, but it is the
most natural-looking "asymmetry" a reviewer will flag, because every sibling
method calls `Physics.CollisionReports.LeaveWorld` and this one does not.
Retail's `set_parent` has exactly one `leave_world` @0x00515AC1, inside the
`add_child` success branch that acdream's staged/deferred realize sequence
represents.

---

## 8. Coupling, merge/split, and order

**Do they share files?** **No.** Route 6's surface is
`InventoryWorldDropProjectionController.cs`, `ItemInteractionController.cs`, and
(read-only) `LiveEntityHydrationController.OnCreate`. Route 7's surface is
`RuntimeEntityObjectLifetime.cs`, `EquippedChildRenderController.cs`,
`RuntimeLiveEntitySessionController.cs`, and
`RuntimeAuthoritativePositionRouteClassifier.cs`. The only shared *concept* is
that both funnel through `LiveEntityHydrationController`, and route 6 does not
modify it.

**Can 6 land without 7?** Yes, trivially — route 6 has no production diff.

**Should they be ONE slice?** **No, but not for the campaign's reason.** They
should be *two landings of very different kinds*:

- **Route 6 is a closure, not a slice.** No production change; a short evidence
  note plus the drop/split coverage tests. Landing it as a "slice" with the
  full contract → implementer → dual-review discipline would be ceremony over
  a zero-line diff.
- **Route 7 is one genuine slice** of ~300-490 production lines, and its two
  halves (Runtime child-cell commit; App demotion) **must not** be split from
  each other.

**Recommended order: route 6 first, then route 7.** Not because of a
dependency — there is none — but because route 6's closure is what removes the
inventory's false "genuine new capability, not merely dormant" claim
(`:768-775`) from the campaign's live record. Leaving that claim standing means
route 7's implementer inherits a planning document that asserts an effect-replay
suppression signal must exist. Cost of doing 6 first: a few hours.

**One planning-record correction to fold in when route 6 closes:** the campaign
plan's own pre-cutover gap list
(`docs/plans/2026-08-02-placement-cutover.md:98-100`) still says
"Route-6 split-recovery creates need an effect-replay suppression signal;
route-7 needs `TryCommitParent`/`CommitWithdrawal` cancellation-symmetry fixes
and host-visible cancellation receipts". The first clause is unsubstantiated
(§6.4) and the second and third were both closed at C0 (§7.3). The list should
say what actually remains: the child-cell two-writer split and the headless
parent-realize gap.

---

## 9. What I could not establish

1. **Whether retail re-cells a child when its parent crosses a cell** (T5).
   `UpdateChild` @0x00512D50 → `set_frame` @0x00514090 is frame-only and never
   writes `objcell_id`. `change_cell`/`set_cell`'s child handling was not read.
   This is load-bearing for demoting App's per-tick rebucket, and it is the one
   thing route 7's contract must nail down before implementation.
2. **Whether the pickup ordering inversion is observable** (T7). Different data
   structures; no constructed failure case; not proven inert.
3. **Whether `BuildSpawn`'s wholesale clone of `Children` / `Movement` /
   `AnimationFrame` can carry anything harmful onto a split result** (R6-c).
   Expected empty for a stackable inventory item; not measured.
4. **Whether `ClassifyLeaveWorld`'s `ValidCreateAuthority` teleport-equality
   gate is even meaningful for pickup** (T3). Retail's gate is the position
   stamp @0x0045224B; the classifier's is a teleport-sequence equality
   inherited from the create path. The two may not correspond at all, in which
   case wiring the classifier unchanged would reject valid pickups the way
   #307 rejected valid force corrections.