diff --git a/docs/ISSUES.md b/docs/ISSUES.md
index b1ac62c1..f5ba2961 100644
--- a/docs/ISSUES.md
+++ b/docs/ISSUES.md
@@ -4455,6 +4455,78 @@ staircase entity's per-frame draw decision.
 
 ---
 
+## #129 — Doors/doorways leak through terrain and houses from over a landblock away
+
+**Status:** OPEN
+**Severity:** MEDIUM (visible at distance during normal outdoor play)
+**Filed:** 2026-06-12 (user report, post-#119-close session)
+**Component:** render — aperture depth punch at distance (#117 family)
+
+**Symptom (user):** "leakage of like doors and doorways through the
+terrain and houses over a landblock" — door/doorway-shaped patches
+visible THROUGH intervening terrain and nearer buildings when the
+source building is roughly a landblock (~192 m) or more away.
+
+**Leads:**
+1. **The #117 stencil depth-gate bias at long range (top suspect).**
+   #117's fix (`478c549`) marks aperture pixels at biased true depth
+   (LEQUAL, bias 0.0005 NDC) then far-Z punches only marked pixels. With
+   a non-linear depth buffer, 0.0005 NDC at ~200 m spans many METERS of
+   view depth — the bias can exceed the separation between the aperture
+   and a hill/house in front of it, marking occluder pixels and punching
+   them → the occluder shows the interior/background behind. The #108
+   coverage constraint pulls the bias up; distance pulls it wrong —
+   re-derive the bias in eye-space (or scale by w) instead of constant
+   NDC.
+2. Per-building look-in floods admitting distant buildings (the #127
+   churn family) — would gate WHICH buildings punch, not the
+   through-occluder leak itself.
+
+**Next:** capture at the spot (ACDREAM_PROBE_VIEWER=1 + a screenshot +
+player/eye position from [snap]/[viewer]); confirm whether the leak
+patch matches an aperture polygon of the distant building; then test
+the eye-space-bias hypothesis headlessly (the #117 commit has the bias
+math).
+
+---
+
+## #130 — Background-color strip along the TOP outer edge of a doorway when looking out from inside
+
+**Status:** OPEN
+**Severity:** LOW-MEDIUM (small strip, but on the most-stared-at pixels in the game)
+**Filed:** 2026-06-12 (user report, post-#119-close session; "also NOW" —
+possibly new since the W=0 clip port `987313a`)
+**Component:** render — doorway aperture edge (seal/punch/OutsideView seam)
+
+**Symptom (user):** standing inside looking out through a doorway, a
+thin strip of background (clear/world) color runs along the OUTER edge
+of the TOP of the doorway opening.
+
+**Leads (capture first — plausibly a `987313a` regression):**
+1. The W=0 port changed `ProjectToClip` (exact w>=0, no 1e-4 epsilon)
+   and DELETED the `EyeInsidePortalOpening` rescue — the OutsideView
+   region through a near doorway is computed slightly differently now.
+   If the OutsideView's top edge sits ~1 px BELOW the aperture's drawn
+   shell edge, terrain/outdoor geometry isn't drawn in that strip while
+   the interior seal/punch still cleared it → background color.
+   Suspects within the port: `MergeSubPixelVertices` shaving a top
+   vertex; the exact-w boundary vs the old epsilon shifting the
+   projected edge; the deleted rescue no longer substituting the full
+   view for an eye-pressed doorway.
+2. The interior SEAL depth vs the shell top edge (the #118-era
+   machinery) — a 1-px mismatch between the seal polygon and the shell
+   aperture would show the clear color exactly at an edge.
+
+**Next:** screenshot + [viewer]/[pv-dump] capture at a doorway showing
+the strip; diff the OutsideView top edge NDC vs the aperture polygon's
+projected top edge for that frame (the CornerFloodReplay harness
+machinery can replay the frame headlessly once the eye/cell are
+captured). If it reproduces at the same doorway with `987313a` reverted
+locally, it's the port's edge math; fix the math, never re-add the
+rescue.
+
+---
+
 # Recently closed
 
 ## #113 — Phantom staircase: REOPENED 2026-06-11, folded into the HOLISTIC BUILDING-RENDER PORT