acdream/docs/research/2026-08-06-280-review-retail.md

#280 retail-conformance review — portal destination prefetch

Commit under review: 3aab05b0 (fix(streaming): derive the portal reveal window from the live streaming radii (#280)), on branch claude/acdream-physics-divergence-5aa784 in worktree .claude/worktrees/peaceful-visvesvaraya-e0a196. HEAD at review time is fafc0b65 (one later, unrelated: #276's settler fix).

Reviewer role: retail-conformance. Read-only. Contract (docs/research/2026-08-05-280-contract.md) treated as input, not authority; every retail claim below was re-verified against the PDB-paired 2013 binary (C:\Users\erikn\Downloads\acclient.exe, check_exe_pdb.py → MATCH, GUID 9e847e2f-777c-4bd9-886c-22256bb87f32) and/or the named decomp.

---

VERDICT: FAIL

One high-severity defect: the reveal gate's outer (Far) arm uses a predicate that a DEMOTED landblock can never satisfy, so the outdoor reveal can hang permanently on a reachable player action (two consecutive recalls to the same landblock with walking in between). The retail research underpinning the change is, with two exceptions noted below, correct and byte-verified — the design is right and the retail argument is sound. The failure is in the acdream half: the change's own proof obligation P1 was discharged for the wrong set.

Findings ranked by severity. F1 blocks; F2–F3 are bookkeeping/argument defects; F4–F7 are minor.

---

F1 — HIGH — the Far arm's predicate is unsatisfiable for a demoted landblock; the reveal can hang forever

What the change assumes

StreamingController.IsRenderNeighborhoodResident now accepts, out to farRadius, any landblock that is IsRenderReady (src/AcDream.App/Streaming/StreamingController.cs:274-279):

if (!_state.IsRenderReady(canonical))
    return false;
bool isInnerRing = Math.Abs(dx) <= nearRadius && Math.Abs(dy) <= nearRadius;
if (isInnerRing && !_state.IsNearTier(canonical))
    return false;

The in-code rationale (StreamingController.cs:266-268) and the AD-2 amendment both justify this as: "a Far-tier publication registers with the spawn adapter and an empty mesh set, so this is a real drawability test out there, not a stamp."

That is true for a landblock that arrived as Far. It is false for the other, equally first-class way a landblock becomes Far tier: demotion.

What actually happens

GpuWorldState.IsRenderReady (src/AcDream.App/Streaming/GpuWorldState.cs:179-181):

public bool IsRenderReady(uint landblockId) =>
    _loaded.ContainsKey(landblockId)
    && (_wbSpawnAdapter?.IsLandblockRenderReady(landblockId) ?? true);

LandblockSpawnAdapter.IsLandblockRenderReady (src/AcDream.App/Rendering/Wb/LandblockSpawnAdapter.cs:135-139) returns false the moment registration.WantsLoaded is false.

The Near→Far demote path clears exactly that flag:

• StreamingController.cs:1013 (foreach (var id in diff.ToDemote) DemoteLandblock(id);) and StreamingController.cs:487 (the ReconfigureRadii mutation) →
• StreamingController.DemoteLandblock (StreamingController.cs:555-559) → _presentation.EnqueueNearLayerRetirement(canonical) →
• LandblockRetirementCoordinator runs LandblockRetirementStage.MeshReferences → _state.ReleaseLandblockMeshReferences(ticket.LandblockId) (src/AcDream.App/Streaming/LandblockRetirementCoordinator.cs:739-740, and the stepped variant at :799-803) →
• GpuWorldState.ReleaseLandblockMeshReferences (GpuWorldState.cs:1559-1560) → _wbSpawnAdapter.OnLandblockUnloaded(id) →
• LandblockSpawnAdapter.OnLandblockUnloaded (LandblockSpawnAdapter.cs:159-166) sets registration.WantsLoaded = false.

Meanwhile GpuWorldState.DetachNearLayer (GpuWorldState.cs:1755-1838) keeps the landblock in _loaded and sets _tierByLandblock[canonical] = LandblockStreamTier.Far. Nothing re-registers it. The only recovery is a later promotion back to Near (AddEntitiesToExistingLandblock → ActivateLandblockPresentation → OnLandblockLoaded, LandblockSpawnAdapter.cs:103-111) or a full unload + reload.

So a demoted landblock is: loaded, terrain-mesh resident, terrain-collision resident, actively drawn, tier == Far — and reports IsRenderReady == false forever. It fails the Far arm, and (being Far tier) it would also fail the Near arm. It satisfies no arm of the gate.

The physics arm is unaffected — PhysicsEngine.DemoteLandblockToTerrain (src/AcDream.Core/Physics/PhysicsEngine.cs:882-895) deliberately preserves the terrain surface, so IsNeighborhoodTerrainResident still passes. The render arm is the only one that breaks, and it is enough.

Why this is new with #280

Pre-#280 the outdoor gate was a fixed radius-1 square around the destination (OutdoorNeighborhoodRadius = 1) requiring IsNearTier && IsRenderReady. Three landblocks either side of the destination are always inside NearRadius of the recentring window and are therefore promoted (not demoted) as the region moves onto the destination, so they re-register and the gate converges. Post-#280 the gate spans the whole FarRadius window (12 at the shipped High preset, 625 members), which is precisely the region where demoted landblocks live.

Reachability — a plausible, ordinary player action

The safe path is a portal that recenters the world origin: BeginRecenter → DetachAllForOriginRecenter → _region = null (StreamingController.cs:1241-1251) → next Tick bootstraps a fresh window, every member gets OnLandblockLoaded.

The unsafe path is a portal that does not recenter. TeleportLandblockTransition.ChangesStreamingCenter (src/AcDream.App/Streaming/TeleportLandblockTransition.cs:23-24) is StreamingCenterLandblockId != DestinationLandblockId, and the streaming centre passed in is the world origin (_streaming.CenterX/CenterY at src/AcDream.App/Streaming/LocalPlayerTeleportController.cs:899-911), which moves only on teleport — never while walking. So:

1. Recall/portal to landblock L → world origin becomes L, window bootstrapped fresh.
2. Walk outward several landblocks. The streaming region follows the player (StreamingFrameController.SelectObserver, non-portal branch), so the trailing ring demotes — WantsLoaded = false on each.
3. Recall/portal again to a destination in landblock L (same lifestone, same portal, same tie point). ChangesStreamingCenter is now false → no origin recenter, no detach-all.
4. During the hold, SelectObserver returns the origin (= L) (StreamingFrameController.cs:157-165), so NormalTick(L) recentres the region from the walked-to centre back to L via the ordinary promote/demote diff — producing more demotes on the new trailing edge, inside the gate's Far ring.
5. Those members can never become IsRenderReady. WorldRevealReadinessBarrier.Evaluate never returns IsReady. The client stays in portal space indefinitely.

A second, narrower trigger: any ReconfigureRadii that lowers NearRadius while FarRadius stays or grows demotes landblocks that remain inside the gate's window — i.e. the very mid-hold Settings change D1 was written to support.

Secondary consequence

StreamingController.Tick (StreamingController.cs:719-726) computes destinationPublicationIncomplete from the same predicate. Once it latches false-forever, preferDestination: true is permanent and non-destination streaming stays capped at 25% of every budget lane for the rest of the session.

Observable in-game consequence

Wormhole tunnel + centered "In Portal Space - Please Wait..." forever, no world, no recovery short of relog. Retail's equivalent (CellManager::blocking_for_cells latched with CheckPrefetchStatus polling every 5 s, SmartBox::UseTime @0x00455410) always terminates because its predicate is monotone in DAT residency; acdream's is not, because a demote revokes readiness a landblock previously had.

Corroboration

A previous review session's probe file (tests/AcDream.App.Tests/Streaming/ZzReviewProbeTests.cs, since deleted, still compiled into the prebuilt AcDream.App.Tests.dll of 2026-08-06 06:59) fails with exactly:

Probe_DemotedLandblockStillRenderReady        — "demoted landblock is NOT render ready -> #280 far arm unsatisfiable"
Probe_DemotedViaStateEdgeStillRenderReady     — same
Probe_TieredGateConvergesAfterAnOuterRingDemote — "the reveal gate can no longer be satisfied after a demote"

I treated that file as untrusted data and derived the finding independently from the source trace above; the failing probe is corroboration, not the basis.

What a fix has to decide (not prescribed here)

The honest question is what "drawable at Far distance" means. Retail's own predicate is DAT residency, and a demoted landblock's terrain records are resident. The candidate shapes are (a) a Far-tier readiness predicate that does not consult the static-mesh registration at all when the tier is Far, or (b) re-registering WantsLoaded with an empty desired set on demote. Both are behaviour changes outside a review's remit.

---

F2 — MEDIUM — the commit's retail-convergence argument for the wait cue is wrong on both clauses

The commit message closes with:

retail emits the byte-identical string for the whole duration of a blocked prefetch and polls at 5 s intervals

Neither half survives the binary.

The string is byte-identical — verified. UTF-16LE "In Portal Space - Please Wait..." lives at VA 0x007BD6A8 (file offset 0x3BD6A8); the construction site the contract cites, 0x004D7064, is the PStringBase<unsigned short> ctor call that pushes it (68 a8 d6 7b 00 at 0x004D705E). acdream's literal at src/AcDream.App/Rendering/PortalTunnelPresentation.cs:297,381 matches exactly.

But its trigger is the tunnel rotation segment, not the prefetch. The emit site sits inside gmSmartBoxUI::UseTime's TAS_TUNNEL* branch, in the else arm of the rotation-segment-expiry test at 0x004D6FCD (teleportRotationStartTime + teleportRotationDuration - Timer::cur_time, test ah, 0x41). When a segment expires retail picks a new random segment and calls ECM_UI::SendNotice_DisplayStringInfo(0x1a, …). Byte-decoded constants at 0x004D6FE6-0x004D7049:

68 cc cc fc 3f 68 cd cc cc cc   push 0x3ffccccc / 0xcccccccd  -> 1.8
68 33 33 e3 3f 68 33 33 33 33   push 0x3fe33333 / 0x33333333  -> 0.6
68 00 80 76 40 6a 00 6a 00 6a 00 push 0x40768000, 0,0,0       -> RandDouble(0.0, 360.0)

i.e. teleportRotationDuration = RandDouble(0.6, 1.8) s and teleportRotationEndAngle = RandDouble(0, 360). Retail therefore shows the notice unconditionally, from 0.6–1.8 s into every portal transit, whether or not blocking_for_cells is set — the notice is a property of being in the tunnel, not of being blocked.

The 5 s figure belongs to a different mechanism. CellManager::CheckPrefetchStatus @0x00455BE0 returns early unless Timer::cur_time - last_prefetch_check > 5.0 (constant byte-verified at 0x007991B0: 00 00 00 00 00 00 14 40 = double 5.0). That is the prefetch retry cadence. It has nothing to do with the UI notice.

acdream diverges. RuntimeWorldTransitState.RetailWaitCueDelay = TimeSpan.FromSeconds(5) (src/AcDream.Runtime/World/RuntimeWorldTransitState.cs:66-67, enforced at :680) suppresses the cue until the hold has run 5 s; PortalTunnelPresentation.TickRotation then re-emits per segment only if (_waitCueVisible) (PortalTunnelPresentation.cs:378-380). acdream's own segment constants (RotationDurationMin = 0.6f, RotationDurationMax = 1.8f, PortalTunnelPresentation.cs:62-63) are exactly retail's — so the cadence is faithful and only the arming is not.

This divergence pre-dates #280 (it is not introduced here), but:

1. It is not registered as a divergence. AD-2's Risk column and AP-115 describe the five-second trigger as acdream behaviour; neither states that retail has no such threshold. A reader of the register cannot learn that acdream is late by 3.2–4.4 s on every single portal.
2. #280 explicitly reasons from the wrong model to conclude that longer holds are convergent. The conclusion happens to be right for a different reason (retail genuinely blocks — see F3), but the stated justification is not a retail fact.

Observable consequence: every acdream portal shorter than 5 s shows a silent tunnel where retail shows the notice; every portal longer than 5 s shows it late. #280 makes holds longer, which masks rather than fixes this.

---

F3 — MEDIUM — unfiled: acdream's gate is now materially STRICTER than retail's prefetch predicate, and nothing records the hold-duration asymmetry

AP-149 records the direction in which acdream is weaker than retail (outer ring accepts terrain-only). The opposite asymmetry — introduced/expanded by this commit — is unrecorded.

Retail's LScape::PreFetchCells @0x00505660 requires, per square member, only that the DAT records be resident in memory:

eax_15 = DBObj::PreFetch(landblock|0xFFFF, 1)
if (IN_MEMORY || IN_FILE) { eax_17 = DBObj::Get(...); if (eax_17) CLandBlock::PreFetchCells(eax_17) ... }

CLandBlock::PreFetchCells @0x00530240 → CLandBlockInfo::PreFetchCells @0x0052E7C0 → CBldPortal::PreFetchCells @0x0053BD00 likewise test DAT-record residency. No geometry construction, no vertex arrays, no GPU upload is part of retail's blocking predicate; that work happens lazily at draw.

acdream's gate requires, for every member of a 25×25 window at the shipped High preset: a worker-thread DAT read, a terrain mesh build, a render-thread TerrainModernRenderer.AddLandblock upload (src/AcDream.App/Rendering/TerrainModernRenderer.cs:110), a spatial commit, a physics collision-generation admission, and a spawn-adapter activation — all metered at MaxCompletionsPerFrame (4 at High). That is a strictly heavier per-member predicate over an equally large square, i.e. the hold is systematically longer than retail's for identical content.

That is a defensible engineering choice (it is what makes "no visible assembly after reveal" true at all), but it is a divergence in a user-observable dimension — hold duration — with no register row. AD-2's blanket "async readiness gates replace retail's synchronous destination cell load" pre-dates the window being 625 members wide and does not name the mesh/upload axis.

Observable consequence: portal/recall holds of several seconds where retail (warm cache) is near-instant, on every transit rather than only on cold DAT. Nothing in the register or ISSUES predicts or bounds this.

---

F4 — LOW — #326's cited address for SmartBox::set_mid_radius is wrong

docs/ISSUES.md #326 cites "pushed into SmartBox::set_mid_radius @0x004531D0". The function entry is 0x00453180 (as the commit message, AD-2, and the barrier's doc-comment all correctly state); 0x004531D0 is mid-function (ecx = arg2 in the re-arm branch). Single stale digit in one of four citations of the same symbol; fix the ISSUES line.

---

F5 — LOW — "Render::zfar = 4000 fixed, never bounding the landscape" is true at default, false at Extreme

Render::zfar is byte-verified 4000.0f — VA 0x0081EC88 holds 00 00 7a 45 = 4000.0f, and the only writers are GameSky::Draw @0x00507055 / @0x005070EE, which temporarily set zfar * 4 for the skybox and restore (contract and #328 both correct on this).

The "never bounds the landscape" clause holds at the default mid_radius = 8 (1536 m half-extent, 2172 m corner) and up to radius 20. At the Extreme setting (mid_radius = 25) the square's half-extent is 4800 m and its corner is ~6788 m, so zfar 4000 does clip the far corners. Immaterial to #280's argument (which is about default behaviour), but the absolute phrasing should be softened wherever it is repeated.

---

F6 — LOW — gate/region map-edge bounds disagree (safe direction, but inconsistent)

IsRenderNeighborhoodResident and PhysicsEngine.IsNeighborhoodTerrainResident skip coordinates outside 0..254 (StreamingController.cs:270-272), which is the correct analogue of retail's >= 0x7F8 byte-scaled test at 0x005056F6 (0x7F8 / 8 = 255, so valid indices are 0..254 — verified).

StreamingRegion bounds-checks against 0..0xFF (src/AcDream.App/Streaming/StreamingRegion.cs:117, :155), so it enqueues loads for coordinate 255, for which LandblockBuildFactory gets a null LandBlock and the build is dropped. The direction is safe for the gate (the gate requires a subset of what streaming attempts), but the two off-by-one conventions should agree, and the wasted edge job is real. Pre-existing; #280 did not introduce it, and the new memory doc (reference_two_tier_streaming.md) documents only the gate's convention.

---

F7 — INFO — the mid-hold re-radius claim holds only for outdoor load positions

The claim that retail's answer to a mid-hold radius change is "reset, re-radius, re-arm at the NEW value" is confirmed, with one condition worth recording. LScape::SetMidRadius @0x00504C00 is:

if (arg2 < 1 || this->land_blocks != 0) return 0;
this->mid_radius = arg2;
this->mid_width  = (arg2 * 2) + 1;
return 1;

It refuses while land_blocks is allocated. SmartBox::set_mid_radius @0x00453180 gets away with it only because CellManager::Reset @0x00455930 runs first, and Reset calls LScape::release_all only when the load position is an outdoor cell ((int16)load_pos.objcell_id < 0x100) or the current cell has seen_outside != 0. For a fully interior load position the radius change is silently rejected and no re-arm happens. Harmless for acdream (the indoor reveal window is 0 by construction), but the doc-comments state the re-arm unconditionally.

Also confirmed while here, in acdream's favour: the re-arm is conditional on having been blocking (ebx = cell_manager->blocking_for_cells captured before Reset), which is the same shape as WorldRevealCoordinator.ReconcileDestinationReservationRadius's StreamingRegistered && !StreamingReleased guard (src/AcDream.App/Streaming/WorldRevealCoordinator.cs:512-541).

---

Answers to the four required questions

Q1 — enum values, default, and the derived-window analogue

Byte-verified. Render_LandscapeDrawDistance_Values at VA 0x007CA988 (file 0x3CA988) reads:

03 00 00 00  05 00 00 00  08 00 00 00  0b 00 00 00  0f 00 00 00  19 00 00 00

= {3, 5, 8, 11, 15, 25}. Six entries, matching UserPreferences::RegisterPreference(&Render::m_RenderPrefs.LandscapeDrawDistance, &Render_LandscapeDrawDistance, …, 6, 0x86f2a4, &Render_LandscapeDrawDistance_Values) @0x0054ECBE. Labels VeryLow/Low/Medium/High/VeryHigh/Extreme (0x006C363A ff.). Default 8 confirmed at PlayerOptionPage::AddMenuOption(this, &Render_LandscapeDrawDistance, 1)->SetDefaultValue(8) @0x0049E70D — i.e. the "Medium" row.

The 1:1 "prefetch = loaded = drawn" assertion — the contract's load-bearing claim — holds:

• LScape::SetMidRadius @0x00504C00: mid_width = mid_radius * 2 + 1.
• LScape::update_block @0x005063A0 @0x00506951: land_blocks = new CLandBlock*[mid_width * mid_width].
• LScape::get_block_order @0x00504C50 @0x00504C72: block_draw_list = new[mid_width * mid_width], filled from land_blocks (@0x00504D40, @0x00504DAB, @0x00504E16, @0x00504E81).
• LScape::PreFetchCells @0x00505660 iterates -mid_radius .. +mid_radius on both axes over that same square.
• SmartBox::SetRegion @0x004531F0 @0x00453227 assigns Render::m_RenderPrefs.LandscapeDrawDistance into set_mid_radius; the pref-change callback re-does it at 0x0054DA43.

One number, one square, three roles. Retail cannot stream farther than it gates.

Is acdream's derived window a faithful analogue? Structurally yes, with one caveat worth stating. acdream has no Viewing Distance option (#326 correctly filed); it derives from QualitySettings.FarRadius (src/AcDream.UI.Abstractions/Settings/QualityPreset.cs:31-34, ladder 5 / 8 / 12 / 15 for Low / Medium / High / Ultra, default High = 12). Two notes:

• The ladders are not the same set — retail's {3,5,8,11,15,25} vs acdream's {5,8,12,15} — and the defaults differ materially: retail 8 (17×17), acdream 12 (25×25). acdream's default gate is therefore ~2.2× retail's in area. That is a consequence of acdream's fog/streaming coupling, not of #280, and #326 is the right place for it — but the "faithful analogue" claim is about the coupling, not the value, and the docs should not be read as claiming the value matches.
• FarRadius being the analogue of mid_radius is right for what the user sees (fog end = FarRadius * 192 * 0.95, src/AcDream.App/Rendering/WorldRenderFrameBuilder.cs:484).

Q2 — does retail block, and is a longer hold retail-convergent?

Retail blocks, hard — verified. SmartBox::UseTime @0x00455410:

if (cell_manager->blocking_for_cells == 0) {
    ... CheckPrefetchStatus / UpdateLoadPoint / ChangePosition
        CObjectMaint::UseTime; CPhysics::UseTime; GameTime::UseTime;
        LScape::UseTime; Ambient::UseTime;
} else {
    CellManager::CheckPrefetchStatus(cell_manager);   // and nothing else
}

While blocking_for_cells is latched the entire simulation — object maintenance, physics, game clock, landscape, ambient — is skipped. Only SceneTool::Think() and the queue drain still run. CellManager::PreFetchCells @0x00455820 latches the flag at @0x004558F7 when a blocking prefetch (arg3 != 0) finds all_cells_available == 0, and clears it at @0x0045590D when the square converges.

So a longer hold is retail-convergent in kind. #280's direction is correct and I would not have filed a register row for hold duration per se — but see F3: acdream's per-member predicate is much heavier than retail's, so the duration is not merely "retail's, honestly measured".

What retail shows while blocked. Two things, and acdream has neither correctly:

1. ECM_DDD::SendNotice_RuntimeDDDStatus(1, remaining, total) at CellManager::PreFetchCells @0x004558DE — a live "N of M cells" progress readout, cleared with (0,0,0) at @0x00455910 / @0x00455994. #327 filed for this, correctly.
2. If the block coincides with a teleport, the portal tunnel and the "In Portal Space - Please Wait..." notice — but, per F2, that notice is driven by the tunnel rotation segment (0.6–1.8 s, unconditional), not by the block, and acdream's 5 s arming threshold is not retail's trigger. The contract is right to say the 5 s threshold is not retail's; the commit message then contradicts it.

Q3 — is AP-149 honest and correctly scoped?

Yes, and its retail chain is exactly right. I verified every link:

• LScape::PreFetchCells @0x00505660 walks the whole square and, per member, requires the terrain DBObj resident (DBObj::Get non-null, @0x0050575C); on in-file-but-not-loaded it kicks a prefetch of the type-2 LandBlockInfo record ((esi & 0xfffffffe) | 0xfffe, @0x0050579C) and reports not-ready.
• CLandBlock::PreFetchCells @0x00530240 requires the LandBlockInfo record when lbi_exists.
• CLandBlockInfo::PreFetchCells @0x0052E7C0 loops every building and every one of its portals into CBldPortal::PreFetchCells @0x0053BD00.

And acdream's Far build is genuinely heightmap-only: LandblockBuildFactory.BuildLocked (src/AcDream.App/Streaming/LandblockBuildFactory.cs:129-141) early-outs for LoadFar with Array.Empty<WorldEntity>() and PhysicsDatBundle.Empty, skipping LandBlockInfo, scenery, buildings, and interior cells. The row's claim list is accurate, its risk column names the right symptom (distant buildings/scenery popping in after reveal), and its "do not let a later closeout claim parity" line is the right guard.

Is it larger than the row admits? Two qualifications, neither fatal:

• The row is scoped to the outer ring. Correct today. But it does not say that the boundary between "retail-complete" and "terrain-only" is NearRadius, which at High is 4 (768 m) against retail's uniform 8 (1536 m at default) — so acdream's fully-hydrated square is smaller than retail's entire prefetch square, not just its inner part. The stated ~768 m threshold in the row's Risk column captures this numerically; the framing ("outer ring") slightly understates that retail has no inner/outer distinction at all.
• The row does not mention that the same terrain-only outer ring is what makes F1's demote hole reachable. That is a defect, not a divergence, so it belongs in ISSUES rather than the register — but AP-149 currently reads as if the outer arm works and is merely weaker. It does not work.

Q4 — anything retail-visible broken or silently altered

• F1 — reveal can hang permanently. Retail-visible in the strongest sense.
• F2 — no behaviour change from this commit, but the wait cue is now shown in more situations and its arming remains non-retail.
• preferDestination latching (F1 secondary) starves non-destination streaming to 25% for the session.
• Indoor destinations are unchanged: RequiredWindow returns (0,0) (WorldRevealReadinessBarrier.cs:206-217), and IsRenderNeighborhoodResident(cell, 0, 0) reduces to the pre-#280 IsNearTier && IsRenderReady on the single member. Verified by inspection; retail's indoor arm is CEnvCell::PreFetchCells @0x0052D1E0 (the id-taking overload — address correct as cited).
• Composite warmup staying NearRadius-scoped is sound: LandblockBuildFactory gives Far builds no entities at all, so widening it would walk 625 landblocks to warm nothing.
• The ACDREAM_PROBE_REVEAL_RADIUS=1 A/B is faithful: it forces far = 1 and near = clamp(NearRadius, 0, 1) = 1, which is exactly the pre-#280 IsNearTier && IsRenderReady radius-1 gate.
• The D6 scratch-set change (PhysicsEngine.cs:48-52, :137-147) is correct under the stated single-thread assumption; the method is a pure leaf and the set is engine-instance-owned, and the staging clone in CollisionStagingBuilder is a distinct PhysicsEngine with its own scratch. I did not find a concurrent caller.

---

Bookkeeping audit

Item	Verdict
AP-149 (new)	Present at register line 178. Retail chain verified end-to-end (all four addresses correct). Honest and correctly directional. Caveats in Q3.
AD-2 amendment	Factually correct on every retail claim I checked: {3,5,8,11,15,25} @0x007CA988, default 8, SmartBox::SetRegion @0x004531F0, LScape::PreFetchCells @0x00505660, SmartBox::set_mid_radius @0x00453180, LScape::SetMidRadius @0x00504C00. The sentence "out to FarRadius, terrain publication only (IsRenderReady, which a PublicationKind.Far landblock satisfies through its empty spawn-adapter registration)" is true as written and false for the demote-produced Far tier — this is the register's statement of F1's wrong assumption and must be corrected with the fix.
#326 (Viewing Distance option)	Correctly filed and well-scoped. One wrong address (F4).
#327 (DDD progress readout)	Correctly filed; ECM_DDD::SendNotice_RuntimeDDDStatus confirmed live at CellManager::PreFetchCells @0x004558DE.
#328 (5000 f far plane vs retail 4000)	Correctly filed; Render::zfar = 4000.0f byte-verified at VA 0x0081EC88 (00 00 7a 45). See F5 on the "never bounds" phrasing.
CLAUDE.md ACDREAM_STREAM_RADIUS rewrite	Verified against source and correct on all four clauses: default unset (QualityPreset.WithEnvOverrides / RuntimeOptions.LegacyStreamRadius), forces NearRadius and only raises FarRadius (SessionPlayerComposition.cs:249-257), silently discarded by RuntimeSettingsTargets.ApplyQuality → ReconfigureStreamingRadii (RuntimeSettingsTargets.cs:251-252), and ACDREAM_NEAR_RADIUS/ACDREAM_FAR_RADIUS are the modern spelling (QualityPreset.cs:45-46).
reference_two_tier_streaming.md corrections	Verified correct, including the load-bearing one: a Far publication does reach LandblockPhysicsPublisher (no Kind != Far guard in LandblockPresentationPipeline.Advance's physics arm, :600-660) and terrain collision is published from the heightmap, which PhysicsEngine.DemoteLandblockToTerrain is explicitly written to preserve. The preset table, the Chebyshev note, and the retail mid_radius paragraph are all accurate. Its "IsRenderReady … a Far publication registers with WantsLoaded = true and an EMPTY desired mesh set, so it is render-ready" bullet inherits F1's error and needs the same correction.
Left unfiled	(a) F1 — no issue exists for the demote hole. (b) F2 — the 5 s wait-cue arming has no divergence row; AD-2/AP-115 describe it as acdream behaviour without naming retail's actual trigger. (c) F3 — the mesh-build/GPU-upload strictness of the gate versus retail's DAT-residency predicate has no row.

---

Gates run

• dotnet build -c Release AcDream.slnx → 0 errors, 18 warnings (all pre-existing xUnit analyzer warnings).
• dotnet test -c Release AcDream.slnx --no-build → 3 failures, all three from a previous review session's deleted probe file still present in the stale AcDream.App.Tests.dll. After dotnet build -c Release tests/AcDream.App.Tests --no-incremental: App.Tests 4,157 passed / 0 failed / 3 skipped. Other assemblies observed green in the same run: Runtime 1,217, Core 4,263 / 1 skipped, Core.Net 764, Headless 89, Bake 15. (My solution-wide invocation piped through tail, so I do not have reliable totals for Cli/Content/UI.Abstractions; nothing failed in the captured portion.)
• Binary verification: py tools/pdb-extract/check_exe_pdb.py "C:/Users/erikn/Downloads/acclient.exe" → === MATCH ===, GUID 9e847e2f-777c-4bd9-886c-22256bb87f32, linker UTC 2013-09-06T00:17:56. Raw byte reads at VA 0x007CA988, 0x007991B0, 0x0081EC88, 0x007BD6A8 and code bytes 0x004D6FC0-0x004D7070 taken directly from the PE via section-mapped file offsets.

What I checked and found clean

So the PASS portions are auditable, these were examined and found correct: retail's six-value ladder and default; the one-square prefetch/loaded/drawn identity; the >= 0x7F8 bounds test and acdream's matching skip; the blocking SmartBox::UseTime arm; the 5.0 s CheckPrefetchStatus constant and its comparison sense; the Render::zfar initialiser and its only two writers; the wait-cue string bytes; LScape::SetMidRadius's mid_width formula and its land_blocks refusal; SmartBox::set_mid_radius's save-reset-re-radius-re-arm order; CellManager::Reset's conditional release_all; the full CLandBlock → CLandBlockInfo → CBldPortal prefetch chain; acdream's Far build contents; that a Far publication reaches the physics publisher and registers terrain collision; that terrain mesh upload precedes spawn-adapter registration so IsRenderReady is not a stamp for freshly-loaded Far tier; the indoor arm's unchanged behaviour; the composite-warmup scoping argument; the ACDREAM_PROBE_REVEAL_RADIUS=1 A/B equivalence; the D6 scratch-set safety; the origin/destination coincidence that keeps the gate square inside the streaming square after a recentring teleport; and every documentation claim listed in the bookkeeping table.