diff --git a/docs/ISSUES.md b/docs/ISSUES.md
index 0408c390..6e656fb9 100644
--- a/docs/ISSUES.md
+++ b/docs/ISSUES.md
@@ -180,6 +180,68 @@ afterwards. **The test was not modified.**
 
 ---
 
+## #256 — Server-spawned objects go invisible after repeated portal runs
+
+**Status:** OPEN
+**Severity:** HIGH (world objects invisible but interactive; live-server observed)
+**Filed:** 2026-07-28
+**Component:** live-entity render publication / streaming (backend attribution pending)
+
+**Description:** During the first live-server session (Coldeve, Vulkan backend,
+~long session with repeated town-portal-network runs), the user observed that
+some server-generated objects — signs and portals in the portal network — became
+visually missing after repeated transits. The portal remained *usable* while
+invisible: interaction worked, so the entity was alive in the object table and
+only its render projection was gone.
+
+**Class candidates:** render-publication retirement across reveal generations
+dropping statics without re-publish on revisit; texture-slot or composite churn
+per transit exhausting/leaking table entries (see #249's GL-side residency
+finding); the streaming residence race class (entities pending during
+recenter — see the #168/#169 memory note). "Invisible but interactive" pins it
+to the presentation half, not the wire or object table.
+
+**Discriminator to run BEFORE V11 deletes GL:** the same repeated
+portal-network route on the GL backend, same session length. Vulkan-arm-only →
+the leak/retirement bug is in the new arm's resource lifecycle; both arms → a
+pre-existing publication bug the campaign merely witnessed. After V11 this
+question costs far more to answer.
+
+**Acceptance:** repeated portal-network transits leave every server-spawned
+sign/portal visible; a soak instrument counts published-vs-live entities per
+transit and holds at zero drift.
+
+---
+
+## #257 — Working set balloons to ~1.5 GB over a live portal-churn session
+
+**Status:** OPEN
+**Severity:** HIGH (memory; live-server observed)
+**Filed:** 2026-07-28
+**Component:** GPU/streaming resource lifetime (backend attribution pending)
+
+**Description:** Same session as #256: the process working set grew to
+~1,500 MB, versus 877 MiB (VK) / 944 MiB (GL) measured by V8's stationary
+vehicles and the ~930 MiB private-set neighborhood of the campaign baselines.
+V8's vehicles were stationary or a single 9-stop circuit; a live session with
+heavy repeated portal transits is a different lifetime profile, and the growth
+suggests a per-transit accumulation (texture table entries, composite arrays,
+mesh-arena ranges, or per-generation buffers) that eviction never returns.
+
+**Likely coupled to #256** — if per-transit churn leaks presentation resources,
+exhaustion (invisible objects) and growth (working set) are two symptoms of one
+lifecycle bug.
+
+**Discriminator:** same as #256, same reason, same before-V11 urgency. The
+existing lifetime/uncapped soak machinery plus `GpuMemoryTracker` accounting per
+transit is the instrument; the campaign's typed-residency ledgers (Slice D/E)
+are the model to hold this to.
+
+**Acceptance:** a repeated-portal soak (≥30 transits) holds working set flat
+after warmup, with per-category GPU accounting drift at zero.
+
+---
+
 ## #253 — Attribute/skill icons: not centered in their cells, and fully opaque
 
 **Status:** OPEN