# Issue #319 — retail-conformance DELTA review, round 2 (2026-08-05)

**Verdict: PASS, with one MAJOR documentation/gate-coverage finding (D1) that
must be closed before the connected gate runs — it does not require a code
change.**

Scope: delta only, against my round-1 report
([`2026-08-05-issue-319-retail-review.md`](2026-08-05-issue-319-retail-review.md)).
Same working tree, same base HEAD `af828a8a`, uncommitted. Reviewed
`git diff HEAD` (14 files, +934/-20) plus the three untracked docs.

Independent gates re-run for this round:

- `dotnet build AcDream.slnx -c Release` — exit 0.
- `AcDream.Runtime.Tests` Release — **1176/1176**, 0 skipped.
- `AcDream.App.Tests` Release — **4127 passed, 3 skipped, 0 failed**.

Matches the coordinator's reported numbers. A green suite is not evidence;
every finding below comes from source or pseudo-C.

---

## 1. The coordinator's primary question: does deleting our deferral diverge
## from retail's queue-by-GUID replay?

**No. Answered structurally, and it needs no register row.**

Retail's mechanism is real: `QueueBlobForObject` @0x005092D0 buckets a
missing-parent blob under the parent's GUID on `CObjectMaint` and replays it
when that GUID is (re)created (AP-132's retail half). The question is whether
acdream still has that mechanism after the App-layer deferral was deleted.

It does, and the deleted code was never it. acdream's port of retail's
per-GUID blob bucket lives in `ParentAttachmentState` and is **untouched by
this diff**:

- `_deferredCreatesByParent` (`ParentAttachmentState.cs:22-23`) — raw
  CreateObjects waiting on a parent GUID, filled by `EnqueueDeferredCreate`
  (`:87-119`) from `RuntimeEntityObjectLifetime.RegisterEntityCore:798-812`.
- `_deferredAcceptedRelationsByParent` (`:34-35`) — accepted relations waiting
  on a parent GUID. Its own doc comment already names the anchor: "Shares the
  SAME per-guid 'blobs waiting on guid X' shape … retail's
  `QueueBlobForObject`/`CObjectMaint` bucket does not distinguish a raw Create
  blob from any other blob type queued against the same guid."
- Replay on parent arrival is live: `DetachDeferredCreates` /
  `DetachDeferredAcceptedRelations` are driven from
  `RuntimeInitialCreateContinuationExecutor.ReplayDeferredChildren:1250-1275`,
  whose comment cites retail's atomic per-parent detach (pseudo-C ~93617) and
  whose `RestoreDeferredCreates` path explicitly preserves retail's "blobs live
  on `CObjectMaint`, not on the object instance, so they survive the object and
  replay against a recreated GUID."

So the deleted `DeferCreateObjectRelation` was a **third, redundant queue** at
the App producer layer, sitting *downstream* of the layer that already
implements retail's mechanism — and downstream of the very gate that makes it
unreachable. Removing it removes duplication, not a retail behaviour.

Verified again for this round that the gate covers both wire shapes:
`RegisterEntityCore:798` reads
`incoming.ParentGuid ?? incoming.Physics?.Parent?.Guid ?? 0u`, and
`SameGenerationCreateObjectEvents` (the sole source of `CreateParentUpdate`)
are produced inside `AcceptCreate`, reached only after that gate passes. The
implementer's structural-unreachability proof is correct for both producers,
which is what round 1's R1 found independently.

**No register row is owed.** The divergence that exists here — acdream gating
queued relations on parent incarnation where retail's replay is pointer-only —
is AP-132, already filed, and this diff does not widen it. `_unresolvedByChild`
(the ParentEvent queue) is untouched.

**Retail-side consequence of the simplification:** with deferral gone, the fix
is exactly "bind to the parent's live incarnation at accept time," and the
parent is guaranteed addressable at that moment by the layer above. That is a
*closer* mapping of `GetObjectA(this, parent_id)` @0x00558a2d than the deferred
version was — retail resolves the GUID once, at the attach, against whatever
`CObjectMaint` currently holds; it does not carry a pending relation forward at
the attach site either. `GetNullObject` @0x005093e6 (the `SetChildren`
placeholder) is retail's only "not yet constructed" accommodation, and it lives
on the *parent-names-children* direction, which acdream does not implement at
this producer. Nothing retail does was lost.

## 2. The refusal paths leave retail-correct state — verified

Two refusal sites, both new:

**(a) `AcceptLateBoundCreateObjectRelation`'s else branch**
(`EquippedChildRenderController.cs:866-873`). Logs to stderr, mutates nothing.
No relation is staged, queued, or committed; the child keeps its own snapshot
and cell. That is a retail-representable state (an unattached object), and the
round-2 test `OnCreateParentAccepted_ParentNotYetKnown_RefusesWithoutStateOrCrash`
additionally pins that a later parent arrival does **not** retroactively attach
it — honest about the consequence rather than implying a recovery that does not
exist.

**(b) `CanCommitIncarnation`** (`ParentAttachmentState.cs:588-604`, called at
`EquippedChildRenderController.cs:983` and
`RuntimeLiveEntitySessionController.cs:414`). Verified the full refusal
sequence:

- It is genuinely pure — reads `resolveParentInstance`, writes nothing.
- Both production call sites now evaluate it **before** their canonical
  mutation (`CommitStagedParent` / `TryCommitParent`), so the A1 torn
  transaction is structurally impossible, not merely unlikely.
- On refusal both call `RejectProjection` (`:649-658`), which removes the
  staged relation **only if it matches exactly** — so nothing is stranded to
  block `Resolve` forever, and a concurrently-replaced staged relation is not
  clobbered.
- The App site returns `CanAdvanceWireQueue: true`, and since the staged
  relation is gone the enclosing `while` loop's next `TryGetStagedProjection`
  fails and breaks. No infinite loop, and the recovery branch still runs.
- `CommitProjection` re-checks the same precondition as its own first mutation-
  free step (`:625-626`), so the method is non-tearing for any caller, not only
  the two that pre-check.

The switch from `throw` to logged `false` also moots round 1's **R6** in the
way that matters: I flagged that I could not exhaustively prove
`_inbound._snapshots[parent].InstanceSequence` never leads
`_activeByGuid[parent].Incarnation` inside a re-Create transaction. That gap
still exists as a fact, but its consequence changed from "destructive throw on
an unproven window" to "a logged refusal and an unattached child" — an outcome
retail can represent. Round 1's R6 is **withdrawn as a risk** and downgraded to
the observation in §5 below.

## 3. Round-1 findings — disposition

| round 1 | status |
|---|---|
| **R1** (both deferred branches unreachable) | **Resolved by deletion.** The unreachable code is gone; the remaining else branch logs. The `AcceptLateBoundCreateObjectRelation` `<remarks>` block (`:57-78`) states the structural argument correctly, including that it is "not an empirical absence, a structural one." |
| **R2** (sentinel-0 collides with `EndGeneration`/`DeleteGeneration` filters) | **Moot.** `LateBindParentInstance` and `DeferCreateObjectRelation` are gone; no relation with a placeholder incarnation ever enters `_unresolvedByChild`. Verified `FilterParentCandidates` (`:1002-1018`) now only ever sees wire-named incarnations. |
| **R3** (two wrong test rationales) | **Corrected, but incompletely — see D2.** Both now cite the zero-`FullCellId` inertness and acknowledge `HasCommittedParent` is child-keyed and committed pre-fix. |
| **R4** (D1's comment made vacuous) | **Fixed correctly.** `RuntimeEntityObjectLifetime.cs:1531-1539` now distinguishes the ParentEvent producer (protection ACTIVE, AP-132) from the CreateObject producer (vacuous-by-design, enforced by `CanCommitIncarnation`). Accurate. |
| **R5** (cross-file "above") | **Fixed.** `LiveEntityPresentationController.cs:211` now names `LiveEntityHydrationController.OnLandblockLoaded`. |
| **R6** (tripwire throw provability) | **Withdrawn as a risk** — see §2. |
| **R7** (hydration gate broader than @0x00515D40) | **Fixed.** `LiveEntityHydrationController.cs:179-187` now records that the exclusion covers the whole candidate loop and rests on route 7's P4 record, not on @0x00515D40 alone. |

## 4. Contract §1 row 5 correction — verified correct, cite it freely

`docs/research/2026-08-05-issue-319-contract.md:82`. Every address in the
correction was re-read at the pseudo-C for this round and is exact:

- `this->m_position.objcell_id = objcell_id` @0x00515385 (same-cell branch) ✓
- child loop `*(uint32_t*)((char*)eax_2 + 0x4c) = objcell_id_1` @0x005153BD ✓
- `CPartArray::SetCellID` @0x005153CC ✓
- loop bounds @0x005153AE–@0x005153D8 (`do { … } while (ebx_1 < this->children->num_objects)`) ✓
- cross-cell branch `CPhysicsObj::change_cell(this, curr_cell)` @0x00515372 ✓
- function header `CPhysicsObj::SetPositionInternal(CPhysicsObj*, CTransition const*)` @0x00515330 ✓ (the 4-arg overload at @0x00515BD0 is a different function; the row cites the right one)

The characterisation — "retail's D2 equivalent lives INSIDE THE SAME FUNCTION
as the player's own per-tick cell write" — is accurate and is the strongest
single anchor for both the equality invariant and AP-146. Safe for future
sessions to cite.

---

## 5. New findings this round

### D1 — MAJOR (documentation + gate coverage; no code change required). The A4 creature-parent correction was applied to `RestoreShadow` and NOT to the hydration gate, which carries the identical live behaviour change — and no gate watch item covers it.

**Sites:** `src/AcDream.App/World/LiveEntityHydrationController.cs:569-570`
(the gate and its comment block `:551-569`);
`docs/research/2026-08-05-issue-319-contract.md:247-276` (§3.1, uncorrected);
`docs/research/2026-08-05-issue-319-contract.md:544-559` (§7 Half B watch item,
covers only `RestoreShadow`); `docs/ISSUES.md:13370-13374` (records A4 for §3.2
only).

The architecture review's A4 established that §3.2's "no-ops today on
`FullCellId == 0`" premise holds **only for player-parented children**, because
route 7's D1 already re-cells CREATURE-parented children to a nonzero cell — so
the `RestoreShadow` gate is a live behaviour change for that class. That
correction is applied at `LiveEntityPresentationController.cs:212-220` and
mirrored into the contract's Half B recipe.

**The identical argument applies to the hydration gate, and nothing records
it.** Verified chain at HEAD for a creature/static parent (incarnation 0):

1. `OnSpawn` stages the relation with the hardcoded `0`, which **matches** the
   parent's real incarnation.
2. D1's gate `parent.Incarnation == parentInstanceSequence`
   (`RuntimeEntityObjectLifetime.cs:1541-1543`) passes → `SetFullCell(child,
   parent.FullCellId, …)`. The child's canonical cell is **nonzero at HEAD**.
3. `ProjectionCellId => WorldEntity is not null ? FullCellId : …`
   (`LiveEntityRuntime.cs:387-389`) → nonzero for a realized child.
4. `OnLandblockLoaded`'s candidate filter (`:571-577`) admits on
   `projectionCellId != 0` + landblock match + `SetupTableId is not null`. An
   equipped weapon satisfies all three when the parent's landblock loads.
5. It therefore enters the second loop and takes one of
   `ProjectExact(CreateSupersessionRecovery)` (`:599`),
   `RebucketLiveEntity` (`:611`), or `ProjectExact(SpatialRecovery)` (`:618`).
   `RebucketLiveEntity` writes `entity.ParentCellId` unconditionally
   (`LiveEntityRuntime.cs:885-898`, no attached-child guard) and calls
   `_spatial.RebucketLiveEntity` — a **second spatial writer** competing with
   route 7 D4's `RebucketEquippedChildPresentation`.

So the hydration gate removes a live code path for creature-parented children,
exactly as the shadow gate does. The direction is right (route 7's P4/D4, and
retail's `update_object` `parent != 0` early-out @0x00515D40 for the canonical
half), but three things are wrong as it stands:

- The gate's own comment (`:551-569`) still frames the change as affecting only
  "a #319-fixed (nonzero) child", i.e. the player class.
- The contract's §3.1 still asserts "A committed child today falls through all
  three sources to `0`" and "The gate is correct TODAY (it changes nothing for
  a zero-cell child)" — **false for the creature class**, and it is the
  sentence a future session will read as the justification.
- **Half B of the connected gate watches the shadow row but not the hydration
  path.** A creature-parented weapon that stops being re-placed on landblock
  load is precisely route 7's "left behind at a boundary" regression shape, and
  nothing in §7 asks the runner to look for it.

**Correct behaviour:** mirror A4 into the hydration gate's comment and contract
§3.1, and add a Half B step that carries an armed NPC across a landblock
boundary (the parent's landblock unloading and reloading) and confirms the
weapon still follows. Blast radius is one paragraph of docs plus one gate step,
not code.

One link in the chain I did **not** close empirically and am flagging rather
than guessing: whether a realized attached child reliably has
`InitialHydrationCompleted == true` (`TryMarkInitialHydrationCompleted`,
`LiveEntityRuntime.cs:2913-2928`, requires only `WorldEntity != null` and
`ResourcesRegistered`, with no `ProjectionKind` filter). This only decides
*which* of the three second-loop branches the child took at HEAD — candidacy,
and therefore the behaviour change, holds either way.

### D2 — MINOR. The R3 comment corrections are precise for the player row and imprecise for the creature row, in tests whose second row IS the creature class.

`tests/AcDream.App.Tests/World/LiveEntityHydrationControllerTests.cs:150-158`
and `tests/AcDream.App.Tests/World/LiveEntityPresentationControllerTests.cs:102-109`.

Both corrected comments end with "what was unreachable pre-fix is the NONZERO
`FullCellId` this candidate loop actually gates on … the child's cell stays 0
forever for a player parent." True for the player row
(`0x50000123u`/`0x50000456u`); **false for the creature row**
(`0x70000099u`/`0x70000199u`), where D1 already produced a nonzero cell at
HEAD — the same D1 fact that drives A4. Correct behaviour: qualify the sentence
per parent class, the way `LiveEntityPresentationController.cs:212-220` now
does for the production comment.

### D3 — LOW / observation. Two new unconditional `Console.Error.WriteLine` sites on paths reachable at wire cadence.

`EquippedChildRenderController.cs:868-873` and
`ParentAttachmentState.cs:601-606`. Both are "should be structurally
unreachable" refusals, so volume is expected to be zero — but neither is
rate-limited or routed through a diagnostic owner, and CLAUDE.md's rule 5
prefers a subsystem diagnostic owner over ad-hoc writes. If either ever fires
on a per-frame retry path it becomes a log flood on a host that must survive
long endurance sessions (Slice K4's own constraint). Not blocking; worth a
follow-up rather than a change in this slice.

### D4 — OBSERVATION (favourable). The ledger-convergence gap I judged non-blocking in round 1 was closed anyway.

Contract §6 test 9 now exists as three dual-parent-class tests
(`ParentAttachmentStateTests`: child removal, parent removal, full teardown
with mixed pending state), each asserting all four tables converge to zero.
Notably the teardown test deliberately leaves a live `_unresolvedByChild`
ParentEvent entry — proving convergence for the queue this fix did **not**
touch, which is the right target now that the deferred queue is gone. The
round-2 `PrepareAndTryRealize_MismatchedIncarnation_RefusesBeforeCanonicalCommit`
test is also well-aimed: it asserts at the **canonical** layer
(`snapshot.ParentGuid` null, `snapshot.Position` non-null) rather than at the
relation table, which is the layer the A1 tear actually corrupted.

Contract §6 tests 5 and 6 remain unwritten; my round-1 judgement stands
(test 5's premise is code-verified at
`RuntimeEntityObjectLifetime.cs:2750-2752`; test 6 pins a flavour the
short-circuit OR makes unobservable). Neither blocks.

---

## 6. Errors in the CONTRACT itself, round 2

One, and it is D1's second bullet: **§3.1 (`:247-276`) was not given the A4
correction its twin §3.2 received.** Its "the gate is correct TODAY (it changes
nothing for a zero-cell child)" is false for creature-parented children and is
the sentence most likely to be cited later. §3.2's body text (`:279-289`, "no-ops
today on `record.FullCellId == 0`") has the same residue, though the §7 Half B
note now overrides it — §3.1 has no such override anywhere.

Everything else re-checked this round — §1's table including the new row-5
correction, §4 F1/F2's pinned constraints, §5's invariants, §7's corrected
criterion and its new Half B addendum, AP-142 clause (f), AP-132's amendment,
AP-146, and #320 — remains accurate against source and pseudo-C.