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

C4 route 7 — independent ARCHITECTURE / ADVERSARIAL review (2026-08-04)

Verdict: FAIL — remediation is narrow and mechanical (two test gaps plus one incomplete proof enumeration). No defect was found in the shipped propagation mechanism itself; the failure is that the route's single highest-risk, user-visible half (the D4 presentation transfer) has no test that can fail, which is the exact recurring defect class route 5's review rounds named and which §3 item 7 / §6 test 10 of the contract explicitly pinned.

Scope reviewed: uncommitted working-tree diff at HEAD ca96ea5e, branch claude/acdream-physics-divergence-5aa784. Route-7 contract and route-3 scoping docs treated as inputs, not as change under review.

Gates re-run by the reviewer:

• dotnet build tests/AcDream.Runtime.Tests — 0 warnings, 0 errors.
• dotnet test AcDream.Runtime.Tests — 1,156 passed / 0 failed.
• dotnet test AcDream.App.Tests --filter EquippedChild — 36 passed / 0 failed.
• New RuntimeEntityChildCellPropagationTests + the two DirectSink_D5 tests — 14 passed.

---

0. Judgement on the four implementer claims + the SetFullCell blast radius

Claim 1 — "D7's reorder is unobservable" → VERIFIED. Genuinely unobservable.

EndChildProjection(guid) (ParentAttachmentState.cs:749-754) touches exactly three tables keyed by the child guid: _stagedByChild, _recoveryByChild, and (via RemoveCommittedChild) _lastAcceptedByChild plus the removal of that guid from its parent's _committedChildrenByParent list. It never touches _committedChildrenByParent[(update.Guid, incarnation)] — the picked-up entity's own children list.

The three calls now bracketed by the move are Physics.CollisionReports.LeaveWorld, Physics.SetPosition.Forget, and Entities.SuspendObjectClock. I enumerated every ParentAttachments reader reachable from them:

• RuntimeSetPositionState.cs:6027 / :6049 (ArmLostFamilyDeadlines / CancelLostFamilyDeadlines) read ChildrenAttachedToParent(operation.Record .ServerGuid, …) — the record as a parent, unaffected.
• RuntimeSetPositionState.cs:3944 (IsAffectedCollisionResident → HasCommittedParent) reads the record as a child and IS order-sensitive — but it is reached only from ParkCollisionResidents, a landblock-quiescence entry point, never synchronously from Forget.
• CancelExactLostKey iterates operations by RuntimeEntityKey, not by relation.

No other reader exists. The honest "reverted the order, all 12 tests still passed" report is the correct outcome and should be recorded as such, not papered over with a manufactured test. One consistency gap follows from it — see A5.

Claim 2 — "RuntimeEntityChange.Rebucketed has NO consumer" → FALSE as stated. Enumeration incomplete. See A3.

The implementer enumerated IRuntimeEntityObjectObserver implementations and found empty stubs. But GameRuntimeEventHub (GameRuntimeEventHub.cs:45) implements IRuntimeEntityObjectObserver and its OnEntity (:239-254) fans the delta out to every IRuntimeEventObserver, and RuntimeTraceRecorder.OnEntity (GameRuntimeEvents.cs:246-254) is a non-stub shipped consumer that records delta.Change and delta.Entity.CellId. The IHeadlessBotPolicy implementations (HeadlessBotPolicy.cs:48/151/281/516) are the empty stubs; they are not the whole set. No functional break is demonstrated (the trace recorder is diagnostic and equipped-child Rebucketed deltas were graphical-only), so the publication default itself stands — but P8 was answered against the wrong interface and must be restated.

Claim 3 — "a committed child never becomes a spatial root" → VERIFIED, for the right reason (which the claim did not state).

The reason is not the parent relation: it is the projection kind. LiveEntityRuntime.HasSpatialRuntimeProjection (:3251-3256) requires record.ProjectionKind is LiveEntityProjectionKind.World, and EquippedChildRenderController.TryRealize materializes children with LiveEntityProjectionKind.Attached (:569). So RefreshSpatialRuntimeIndexes → AcknowledgeSpatialProjection(canonical, spatial: false) → RemoveSpatialProjection on every tick, and _spatialRoots (RuntimePhysicsState.cs:697-711) never gains the child. Headless never calls AcknowledgeSpatialProjection on any route-7 path at all (its only callers are LiveEntityRuntime.cs:3272 and RuntimeSetPositionState.cs:2756/3664/5138, none of which route 7 reaches). So no child broadphase gap, and the §0 trap-5a "no per-crossing shadow rebuild" pin holds. Note for the record: had the child been kind World, the FullCellId != 0 clause of HasSpatialRuntimeProjection would have made D1/D5 newly promote children into the physics workset — the claim is right, but it is one line of ProjectionKind away from being wrong, and P4's write-up should say so.

Claim 4 — "P5/P6 are safe by construction, no dedicated tests" → ACCEPTABLE for the propagation path; NOT acceptable as a blanket statement for the slice. See A6.

• P6 (zero alloc) on the propagation path: verified. ChildrenAttachedToParent (ParentAttachmentState.cs:648-658) returns the stored List<uint> or the cached Array.Empty<uint>(); both convert to IReadOnlyList<uint> by reference conversion (no boxing). PropagateFullCellToChildren (RuntimeEntityDirectory.cs:381-405) is an index loop with no LINQ, no closures, no temporaries. 0 B confirmed by inspection. ParentIncarnation is a readonly record struct (ParentAttachmentState.cs:923) so the dictionary probe does not box.
• P5 (re-entrancy) on the propagation path: verified. The only work is EnsureKnown, record.SetFullCell field writes, TryGetActive, and an optional Console.WriteLine. Nothing calls back into RuntimeSetPositionState / RuntimePhysicsState / any observer, so the recursion cannot re-enter a mid-commit owner. I also confirmed the live List<uint> returned by ChildrenAttachedToParent cannot be mutated during the loop (nothing on the propagation path touches the relation tables), so the swap-remove in RemoveCommittedChild (:853-859) is not an aliasing hazard here.
• But the slice's OTHER new path is not zero-alloc and was not measured — D5's per-spawn ChildrenWaitingForParent scan. See A6.

The SetFullCell blast radius — enumerated; correct at every site, with one structural caveat (A7).

RuntimeEntityDirectory.SetFullCell (:348-355) now has a side effect for every caller. Full production caller set, each checked:

site	value written	children now follow — correct?
RuntimeEntityObjectLifetime.cs:1314 (TryApplyPickup)	0,0	✔ retail leave_world's recursive leave_cell(this,0) @0x005155E6
:1484 (WithdrawCommittedChildrenToCellless)	0,0	✔ explicit D3 edge
:1509 then :1530 (CommitAcceptedParentCellless)	0,0 then parent's	✔ grandchildren are zeroed then restored inside the same synchronous call
:1945 (CommitRebucket)	new cell	✔ D2's headline case
:1991 (CommitWithdrawal)	0,0	✔
:2737 (InitializeAcceptedCreateResidence)	0,0	✔ vacuous — a fresh incarnation has no committed children (_committedChildrenByParent is keyed by (guid, instance))
RuntimeInitialCreateContinuationExecutor.cs:2188 (dormant pickup replay)	0,0	✔ same shape as TryApplyPickup
RuntimePhysicsState.cs:2148 (CommitCanonicalCell)	new cell	✔ guarded by an equality early-out at :2145, so no probe on a same-cell commit
RuntimeSetPositionState.cs:2743 / :3660 (placement commits)	new cell	✔ both guarded by record.FullCellId != result.CellId
:5003 (residency restore)	resident cell	✔ re-propagates children the park zeroed
:5224 (WithdrawCanonical)	0,0	✔ park/lost-cell; self-heals through :5003
LiveEntityRuntime.cs:192 / :200 (record property setters)	mixed	test-only (no production assignment exists) — but see A7

No caller means "clear only this record": every zeroing site is a retail leave_world/change_cell(null) analogue, and the two "restore" sites re-propagate. The RefreshSnapshot half (:231-246) is correctly gated on an actual change and RefreshDerivedState has exactly the two callers the contract claimed (record ctor RuntimeEntityRecord.cs:29 and RefreshSnapshot) — I re-verified this repo-wide, so contract open question 1 is answered: no canonical cell write bypasses the hook.

Termination: verified by construction and by test. The skip is evaluated in the parent's loop before descending, so an A→B→A wire cycle writes A, writes B, then finds A already equal and stops. PropagationChokepoint_TerminatesAHostileTwoCycle… pins it. A self-parent (reachable headless, where D5 skips ValidateParentProjection's self-parent rejection at EquippedChildRenderController.cs:897-898) also terminates on the first skip.

Ordering: children are written before every parent-side dependent step — before CellCommitted (RuntimePhysicsState.cs:2152), before AdvancePlacementCommit/AcknowledgeSpatialProjection (RuntimeSetPositionState.cs:2746-2756), and before AcknowledgeProjectionAndPublish in CommitRebucket. There is no synchronous callback anywhere inside the recursion, so no observer can see a partially-propagated tree. This matches retail (enter_cell's child recursion runs inside change_cell, before the caller's tail).

---

1. Findings

A1 — MAJOR. The only test for the D4 demotion's presentation half cannot fail if that half is deleted outright.

Where: tests/AcDream.App.Tests/Rendering/EquippedChildProjectionWithdrawalTests.cs:322-362 (TickChild_D4_CanonicalCellIsRuntimesWriteNotTheRenderTicks), against src/AcDream.App/Rendering/EquippedChildRenderController.cs:403 and :409-415.

The test's two assertions are:

1. Assert.Equal(newCell, child.WorldEntity!.ParentCellId!.Value) — "the render tick moved only the DRAW bucket".
2. Assert.Equal(childSpatialVersionBeforeTick, child.Canonical.SpatialAuthorityVersion) — "and did not re-write the canonical cell".

Assertion 1 does not test the bucket. TickChild writes child.Entity.ParentCellId = parent.ParentCellId unconditionally at :403, before the rebucket call, and AttachedChild.Entity is the same WorldEntity instance the test reads (the fixture passes child.WorldEntity! into the AttachedChild ctor — EquippedChildProjectionWithdrawalTests.cs:1529). Assertion 2 is a negative that is trivially satisfied by doing nothing.

Concrete failure scenario: delete lines :409-415 entirely (or let RebucketEquippedChildPresentation return false on its first guard — see A2). The child's canonical cell is still right, ParentCellId still mirrors, both assertions still pass, the whole App suite stays green — and the equipped weapon is left behind at the previous landblock's draw bucket when the player crosses a boundary: exactly the "left behind at a landblock boundary (the demotion's specific risk)" regression the contract's §7 gate names, and the #184 invisible-but-solid family.

RebucketEquippedChildPresentation has zero test references repo-wide (grep across tests/ returns nothing), so this is the slice's only coverage of the presentation transfer.

Contract §6 test 10 asked for precisely what is missing: "assert the child's render entity moved buckets (spatial index / visibility state)". The implementer's sabotage note covers the canonical half only (reverting to RebucketLiveEntity fails assertion 2 — I confirmed that is true, because RuntimeEntityRecord.SetFullCell at :246-251 bumps SpatialAuthorityVersion unconditionally); the presentation half's sabotage was not run.

Fix direction: assert against the spatial layer, not the mirror field. The fixture already reaches LiveEntityRuntime, so either (a) assert record.IsSpatiallyVisible / the spatial index's resident cell for the child key after the tick with the child pre-seeded into a different bucket, or (b) assert RebucketEquippedChildPresentation's observable effect through the fake _spatial (a recorded RebucketLiveEntity(key, entity, cell) call with the new cell). Then run the prescribed sabotage: stub the call out and confirm the test goes red.

A2 — MAJOR. The new App entry point can silently write nothing, and its status is discarded. (Route 5's A1 defect class, recurring.)

Where: src/AcDream.App/World/LiveEntityRuntime.cs:1085-1101 (RebucketEquippedChildPresentation) and src/AcDream.App/Rendering/EquippedChildRenderController.cs:409-415.

The method returns false — writing nothing — on three conditions (!HasCommittedParent, no current projection, no WorldEntity). TickChild discards the return value, then unconditionally returns true and raises ProjectionPoseReady?.Invoke(child.ChildGuid) at :416, i.e. it advances presentation on a write-nothing outcome. That is verbatim the defect the route-7 contract lists among the route-5 classes it "addresses by name" (§preamble: "an App glue site discarding the Runtime seam's status and advancing presentation on write-nothing outcomes").

The HasCommittedParent guard is new; it did not gate the old RebucketLiveEntity call. It is reachable-false while _attachedByChild still holds the child, because Runtime clears _lastAcceptedByChild (via EndChildProjection, RuntimeEntityObjectLifetime.cs:1307 on pickup and :1908 on the Position-unparent) before the App's EquippedChildRenderController.OnChildBecameUnparented (:264-284) runs, and that method can defer the teardown across frames (AdvanceUnparentTransition + _pendingOrphanRemovalByChild, retried at :342). During that window every Tick() composes the pose, mirrors ParentCellId, publishes the pose, raises ProjectionPoseReady, and moves no bucket at all.

Today that window is benign (the child is on its way out). The finding is that the benign-ness is accidental and untested: nothing distinguishes "guard correctly declined" from "guard wrongly declined", and A1 means no test would notice either way.

Fix direction: consume the bool. Either treat false as a TickChild failure (which already has a defined path — Tick()'s failed list → WithdrawForPoseLoss at :296-297), or, if declining is legitimate for the unparent window, make that explicit: return a small disposition (Moved / NotAttached) and assert the NotAttached case in a test rather than inferring it. Do not leave a silent bool on the floor.

A3 — MEDIUM. P8's consumer enumeration is against the wrong interface; a non-stub OnEntity consumer ships.

Where: src/AcDream.Runtime/GameRuntimeEventHub.cs:45 and :239-254; src/AcDream.Runtime/GameRuntimeEvents.cs:104 and :246-254.

See claim 2 above. GameRuntimeEventHub is itself an IRuntimeEntityObjectObserver that forwards to every IRuntimeEventObserver, and RuntimeTraceRecorder.OnEntity records (delta.Change, delta.Entity.CellId) for every entity delta including Rebucketed.

Failure scenario (bounded): any current or future headless gate / trace assertion that counts entity deltas for an equipped child now sees fewer Rebucketed entries than before the demotion, with no note anywhere saying so. I found no such assertion today, so this is a proof defect rather than a live break — but the stated basis for D2's "publish nothing" default ("safe by inspection, every implementation is an empty stub") is not true and must not be carried forward as if it were.

Fix direction: restate P8 in the commit against both observer interfaces, name RuntimeTraceRecorder explicitly as the one real consumer, and say why a diagnostic trace losing graphical-only child Rebucketed entries is acceptable. No code change needed.

A4 — MEDIUM. CommitAcceptedParentCellless now publishes Withdrawn carrying a NON-zero cell.

Where: src/AcDream.Runtime/Entities/RuntimeEntityObjectLifetime.cs:1530-1543.

D1's re-cell is placed before AcknowledgeProjectionAndPublish(…, RuntimeEntityChange.Withdrawn, …). Prior to this slice, a Withdrawn delta from this method always carried FullCellId == 0; it now carries the parent's cell whenever the parent is celled — i.e. in the ordinary equip case.

Failure scenario: any observer that treats Withdrawn as "no longer resident" and reads delta.Entity.CellId to decide where to unregister (the plugin world-state bridge, a future headless bot policy, a future radar/journal consumer) now gets a delta whose kind and payload disagree. The shipped consumers are stubs or diagnostic, so nothing breaks today; the risk is that the invariant "Withdrawn ⇒ cell 0" was previously true and is now silently false, with no test pinning either reading.

Fix direction: cheapest correct answer is to state the new payload contract in the method's doc comment and add one assertion to the D1 attach test (Attach_ParentCelled_…) pinning the published change kind and the delta's cell, so the pair is deliberate rather than incidental. If any consumer is later found to need the old shape, the re-cell moves after publication — which is safe, because the same-transaction argument is about callers, not about the delta.

A5 — MEDIUM. D7's reorder was applied to one of the two pickup leave-world sites; the sibling still has retail's inverted order.

Where: fixed at src/AcDream.Runtime/Entities/RuntimeEntityObjectLifetime.cs:1304-1314; not fixed at src/AcDream.Runtime/Entities/RuntimeInitialCreateContinuationExecutor.cs:2184-2189 (ApplyPickupAction, the dormant-residence pickup replay), where EndChildProjection still runs after LeaveWorld / SetFullCell(0,0).

Failure scenario: none observable — the same inertness argument that validates claim 1 applies verbatim to this site. The defect is bookkeeping: D9 and the commit will say the recorded T7 inversion is "retired", while a second instance of it remains in-tree at the path a pickup takes when it arrives during a pending initial-create residence. A future reader grepping for the inversion finds it and re-opens a settled question.

Fix direction: either apply the same three-line move at :2189 (preferred — it is provably inert and makes both pickup paths one shape), or add one sentence to the D7 commit text naming ApplyPickupAction as a deliberate, inert survivor.

A6 — MEDIUM. D5's per-spawn retry is an O(live-relations) LINQ scan with allocations, on the headless spawn path.

Where: src/AcDream.Runtime/Session/RuntimeLiveEntitySessionController.cs:143 (RetryChildrenWaitingForParent called on every accepted spawn) → src/AcDream.Runtime/Entities/ParentAttachmentState.cs:618-640 (ChildrenWaitingForParent), plus :339-388 (ResolveAndCommitChildAttachment).

ChildrenWaitingForParent allocates a HashSet<uint>, fully enumerates _stagedByChild, _recoveryByChild and _unresolvedByChild, runs queue.Any(lambda) per unresolved child, and returns .ToArray(). _recoveryByChild retains an entry for every child ever committed (CommitProjection, :595), so it grows with the number of equipped NPCs/players in view. ResolveAndCommitChildAttachment additionally allocates three this-capturing closures per call (:341-350).

Failure scenario: a 30-session headless host (Slice K's stated target) loading a dense landblock does one full scan of three dictionaries per accepted CreateObject. With N resident entities of which K are attached children, that is O(N·(N+K)) work and O(N) allocations across the load, on the path Slice K measured to a resource ceiling. The graphical host does the same thing (EquippedChildRenderController.OnSpawn → RetryWaitingDescendants), so the shape is not novel — but the headless host is the one with a per-process allocation budget and a 30-root gate, and this is new cost there.

Fix direction: the retry only needs children whose unresolved queue names this parent. Index that: keep a Dictionary<uint parentGuid, List<uint> childGuids> maintained by Enqueue/Resolve, or at minimum skip the _recoveryByChild and _stagedByChild sweeps (both are already-resolved states that ResolveAndCommitChildAttachment no-ops on). Cache the three callbacks as fields. Then re-measure the K4 30-session resource envelope, or state explicitly that this slice does not.

A7 — LOW. The propagation's idempotence key is FullCellId alone, but SetFullCell takes an independent canonicalLandblockId.

Where: src/AcDream.Runtime/Entities/RuntimeEntityDirectory.cs:389-395 (child.FullCellId == fullCellId → continue).

Every production writer derives the landblock from the cell — (cellId & 0xFFFF0000u) | 0xFFFFu at RuntimeEntityRecord.cs:235, RuntimePhysicsState.cs:2150, RuntimeSetPositionState.cs:2744/3663/5005 — and D1 copies the parent's pair verbatim, so the two fields are coupled today and the skip is safe.

Failure scenario: the coupling is not enforced anywhere. LiveEntityRecord.CanonicalLandblockId's setter (src/AcDream.App/World/LiveEntityRuntime.cs:200-203) calls SetFullCell(Canonical, Canonical.FullCellId, value) — a same-cell, different-landblock write. It has no production caller today (tests only), but if one ever appears, children keep the stale CanonicalLandblockId while the parent updates, because the skip fires. LiveRenderProjectionJournal.cs:273 reads record.CanonicalLandblockId to pick the owning landblock, so the symptom would be a child journaled against the wrong landblock.

Fix direction: make the skip test the pair (child.FullCellId == fullCellId && child.CanonicalLandblockId == canonicalLandblockId), or assert the derivation invariant in RuntimeEntityRecord.SetFullCell. One line either way.

A8 — LOW. Wire-driven recursion depth is unbounded; a deep attachment chain is a StackOverflowException (process kill).

Where: src/AcDream.Runtime/Entities/RuntimeEntityDirectory.cs:381-405 (mutual recursion PropagateFullCellToChildren ↔ SetFullCell).

Termination against cycles is correct (verified above), but depth is bounded only by the length of the committed parent chain, which is server-supplied. Nothing in ParentAttachmentState, TryApplyParent, or TryCommitParent caps chain depth; only self-parenting is rejected, and only in the graphical ValidateParentProjection (which D5 deliberately skips).

Failure scenario: a buggy or hostile server commits a 10k-long A→B→C→… chain; the first cell write on the root overflows the 1 MB stack. StackOverflowException is uncatchable in .NET — the process dies, taking all 30 headless sessions with it. Not reachable against a well-behaved ACE.

Fix direction: a depth counter with a hard cap (retail's own recursion is equally unbounded, so a cap is an acdream divergence — it belongs in AP-142's clause list) or an explicit iterative worklist over a pre-sized scratch buffer, which also removes the stack cost entirely and stays 0-alloc after warmup.

A9 — LOW. The C3c active-residence gate is not carried to the new presentation entry point.

Where: src/AcDream.App/World/LiveEntityRuntime.cs:1085-1101 vs the gate at :806-834.

The public RebucketLiveEntity refuses to install a bucket while an initial-create residence is ACTIVE, with a stated reason ("a re-entrant caller could install a bucket for a suppressed record before its placement ever committed"). RebucketEquippedChildPresentation guards on HasCommittedParent only.

Failure scenario: bounded — CommitAcceptedParentCellless calls ForgetInitialCreateResidence (:1502) before any AttachedChild is installed, so by the time TickChild can run, the child's residence is cancelled. The gap is that the guard's reason is now implicit in call ordering three files away rather than enforced at the entry point.

Fix direction: add && !HasActiveInitialCreateResidence(record.Canonical) to the new method's guard (cheap, and it makes the "can never become a general bypass" claim in its doc comment actually true), or cite the ForgetInitialCreateResidence ordering in that doc comment.

A10 — LOW. Duplicate <summary> block; one existing test lost its documentation.

Where: tests/AcDream.Runtime.Tests/Session/RuntimeLiveEntitySessionControllerTests.cs:316-330.

The new D5 test's doc comment was inserted after the closing </summary> of the C3c-R1 F6 block that documented FirstEntryDriveServesOneRouteAtATimeAndScopesClearToTheOwner. Both summaries now attach to DirectSink_D5_StandaloneParentEventCommitsChildToParentsExactCell; the F6 test is undocumented. Mechanical fix: move the new block below the old one's member, or move the old block down to :231.

---

2. Contract obligations checked and found MET

Recorded so the next reviewer does not re-derive them.

• D2 chokepoint completeness (contract open question 1). RefreshDerivedState has exactly two callers repo-wide (RuntimeEntityRecord.cs:29 ctor, RuntimeEntityDirectory.cs:239); RuntimeEntityRecord.SetFullCell has exactly two (RefreshDerivedState, RuntimeEntityDirectory.SetFullCell). No canonical cell write bypasses the hook.
• D3 delete ordering (P7). WithdrawCommittedChildrenToCellless runs at :2070 before DeleteGeneration at :2073, and at :1005 before EndGeneration at :1009. In the EndGeneration case RemoveActive has already run, but the relation table is untouched by it and children are looked up independently, so the read is valid. Recursion to grandchildren rides D2. Pinned by Delete_ZeroesChildrenBeforeRelationsAreTornDown_P7 and EndGeneration_ReplacementParentGeneration_…. No double-withdraw: the second pass would find every child already at 0 and skip.
• No orphaned teardown sites. ParentAttachmentState.RemoveObject / RemoveChild have zero production callers, so DeleteGeneration / EndGeneration are the complete set of relation-teardown edges needing a cell edge, and both got one.
• D8 never-arm partition. No ConstrainTo, park, service-window, or CanAttemptDestination code was added; NeverArmPartition_D8_… pins the placement-operation count across attach + 5 crossings + pickup + delete. (Contract §6 test 6 also asked for park counts and RemotePlacementDrivePendingCount; only ActiveOperationCount is asserted — a thinner pin than specified, noted but not a finding on its own.)
• §3 item 10 tripwire. The classifier diff is a pure deletion of ClassifyLeaveWorld + its two types + its one test. ValidCreateAuthority survives; no surviving classifier test changed an expectation. 1,156 Runtime tests green.
• D9 bookkeeping. AP-142 and AP-143 both filed; AP-136's writer list correctly shrinks to the projection materializer alone, and the two mirrored doc comments (RuntimeSetPositionState.cs:4542, RuntimeRemotePlacementDriveController.cs:1619) were updated in the same diff. Repo grep for stale "TickChild is a canonical writer" claims returns only the corrected sites.
• Headless gate is a real regression test. Both DirectSink_D5_… tests seed parent and child at distinct landblocks and assert NotEqual(0u, …) alongside the equality, so they cannot pass by coincidence or at zero. Both fail without D1/D2/D5.
• P1. P1_SnapshotMutationOfACommittedChild_… drives an ObjDesc merge and asserts child.Snapshot.Position stays null and the cell still tracks the parent — a genuine behavioural pin, not a source-text pin.

---

3. Remediation required to convert this to PASS

1. A1 — rewrite the App test so it asserts the spatial bucket / visibility move, and run the contract's prescribed sabotage (stub RebucketEquippedChildPresentation out; the test must go red).
2. A2 — consume RebucketEquippedChildPresentation's status in TickChild, and cover the declining branch with a test.
3. A3 — restate P8 against IRuntimeEventObserver as well, naming RuntimeTraceRecorder.

A4–A10 are recommended in the same slice (all are one-to-three-line changes or commit-text corrections) but none of them alone blocks the route.

The connected two-client gate has not been run and remains the acceptance test for the D4 transfer regardless of the above — with the contract's own rule that a session showing zero cause=propagate lines during the landblock-crossing step is a not-run, not a pass.