diff --git a/docs/ISSUES.md b/docs/ISSUES.md
index a18767c1..efe6cf7e 100644
--- a/docs/ISSUES.md
+++ b/docs/ISSUES.md
@@ -226,6 +226,14 @@ Both are the **entity-lifecycle/render path across a teleport**, NOT the streami
 
 **Files:** `src/AcDream.App/Streaming/GpuWorldState.cs` (`AddLandblock` pending-merge vs record-replace, `AppendLiveEntity`, `RemoveLandblock`/rescue, `DrainRescued`, `RelocateEntity`), `src/AcDream.App/Rendering/GameWindow.cs` (`OnLiveEntitySpawnedLocked` ~:2696, rescued re-inject ~:7421), the per-instance render adapter (`WbEntitySpawnAdapter`). The streaming collapse/expand (`StreamingController`) is no longer the suspect.
 
+**UPDATE 2026-06-21 — root re-scoped again: it's RE-DELIVERY, not render-cull or cache.** A deep dive (probes: `[ent]` append/remove + `[ent-flat]` rendered-set count + `[dyn]` DrawDynamicsLast cull) eliminated the 2026-06-20 hypotheses:
+- **NOT the Tier-1 cache.** Re-created live entities get a fresh monotonic `Id = _liveEntityIdCounter++` (`GameWindow` ~:3251), so `EntityClassificationCache` (keyed on `Id`) is ALWAYS a miss for them — never the cause. *(Side-finding, separate minor bug: the cache has a demote-vs-unload invalidation asymmetry — `RemoveEntitiesFromLandblock` fires `_onLandblockUnloaded` (`:~495`) but `RemoveLandblock` does NOT, violating the documented "demote OR unload" intent. NOT the #138 cause; fix-with-verification later.)*
+- **Render path is FINE when entities are present.** At login `[dyn] rootOutdoor=True dyn=54 drawn=33` — the dynamics partition (`InteriorEntityPartition` :55, every `ServerGuid!=0` with `MeshRefs>0` → dynamic) + `DrawDynamicsLast` draw them.
+- **The ACTUAL cause: re-delivery is unreliable / absent.** `notan/+Je` walk-around run: after teleport-out, `live:spawn` doors = **0**, `[ent] +` door appends = **0**, `[ent-flat] server=1` (only the player), `[dyn] dyn=1` — the server delivered **ZERO** Holtburg objects on return; they never reach acdream. (An earlier `testaccount2` run got ~15 re-sent, but the user confirmed they stayed missing then too — so re-delivery is partial AND unreliable across accounts/sessions.) "Other clients see +Je" → the server has correct player state; acdream's LOCAL world is simply missing the objects. The 2026-06-20 "NOT a re-broadcast gap" claim above was WRONG — it IS (intermittently) a re-broadcast gap.
+- **Mechanism:** acdream UNLOADS the landblock's server-spawned objects on teleport-IN (the dungeon collapse unloads neighbours, including Holtburg), and on the way back NOTHING restores them; ACE does not reliably re-broadcast them (known-set/awareness desync, likely worsened by the rapid relaunch churn).
+
+**Fix direction (NEXT):** restore the landblock's server objects on reload from acdream's OWN retained data model — the `ClientObjectTable` keeps ALL objects (see `project_object_item_model`: "CreateObject = merge-upsert into ClientObjectTable") — i.e. re-hydrate `GpuWorldState` from `ClientObjectTable` on `AddLandblock`, rather than depend on an ACE re-broadcast that doesn't reliably arrive. (Alternative: treat all in-range server objects as persistent across the collapse, like the player.) Cross-check the teleport object-visibility handshake against `references/holtburger` + `references/ACE` (does the client need to signal it dropped the objects? does ACE release on landblock change?). **Best started fresh — this is an entity-lifecycle/protocol change, not a render fix.**
+
 **Acceptance:** portal out of the 0x0007 dungeon → full outdoor world streams (trees/scenery present), **server objects (doors/NPCs/portals) render**, **own avatar renders across repeated round-trips**, collision works, position tracks (no avatar-vs-camera desync).
 
 ---