diff --git a/docs/ISSUES.md b/docs/ISSUES.md
index 9da21c58..380dec77 100644
--- a/docs/ISSUES.md
+++ b/docs/ISSUES.md
@@ -46,6 +46,45 @@ Copy this block when adding a new issue:
 
 ---
 
+## #187 — Non-hinged doors (sliding doors, "fading wall" gates) don't play their open animation
+
+**Status:** OPEN — under investigation
+**Severity:** MEDIUM (visual correctness; collision + interaction already work — #137)
+**Filed:** 2026-07-08
+**Component:** render — entity animation registration (`GameWindow.cs` live-spawn dispatch)
+
+**Description (user):** door COLLISION is confirmed fixed (#137) — all doors can be clicked
+and passed through correctly. But not all door TYPES play their open animation: normal
+hinged doors swing open, but sliding doors and "fading wall" style dungeon gates do not
+animate — the player passes through as if the door/wall just isn't there.
+
+**Suspected root cause (pre-investigation read, NOT yet decomp-verified):**
+`GameWindow.cs:3897` registers the door-swing sequencer only when
+`IsDoorSpawn(spawn)` (`GameWindow.cs:3128`: `spawn.Name == "Door"`, an exact
+display-name string match). The branch above it (`:3818`) already handles ANY entity
+generically via its resolved idle cycle (multi-frame, framerate != 0) — no name check.
+Doors need the special branch only because their REST pose is a static single frame
+(fails the generic gate) while their MotionTable still carries reactive On/Off cycles
+ACE drives via `UpdateMotion`. That "static rest + reactive motion-table cycle" shape
+is not unique to hinged doors — any sliding/lever/gate prop with the same shape would
+need the identical rescue, but only literal name `"Door"` gets it. Retail's own decomp
+has ZERO `CDoor`-class or door-specific dispatch (only `ObjCollisionProfile::SetDoor`,
+a collision-only concept) — suggesting retail's client-side animation dispatch is
+entity-type-agnostic (MotionTable-driven), and the name-string gate is an acdream-only
+divergence, not a port of anything retail does.
+
+**Open question for the investigation:** are "fading wall" gates even MotionTable/
+skeletal objects, or a structurally different mechanism (an ObjectDescription /
+translucency-toggle triggered by a script, no motion involved)? Needs dat/weenie-data
+survey before designing the fix — must not just add more name strings (same class of
+bug, just deferred).
+
+**Acceptance:** sliding doors + fading-wall gates play their open/close transition
+matching the door's actual open/closed wire state, same as hinged doors today. Hinged
+doors keep working (no regression). Suites green.
+
+---
+
 ## #186 — [DONE 2026-07-08 · `8257b9ba`] Indoor→indoor GREY flap at a connecting room (top floor, new house type)
 
 **Status:** CLOSED 2026-07-08 — live gate PASSED (no grey at any camera angle) + probe
@@ -1891,9 +1930,13 @@ Both are the **entity-lifecycle/render path across a teleport**, NOT the streami
 
 ---
 
-## #137 — Dungeon collision incorrect at doors and wall openings
+## #137 — [DONE 2026-07-08] Dungeon collision incorrect at doors and wall openings
 
-**Status:** OPEN
+**Status:** CLOSED 2026-07-08 — user re-gate: "door collision is fixed" (clicked/passed
+through multiple dungeon door types, no phantom blocks, no fall-through). Combined with
+the 2026-07-06 corridor + window/opening gates already passed, all #137 COLLISION scope
+is done. (The doors-open-but-don't-ANIMATE gap the same check surfaced is a SEPARATE
+concern — filed as **#187**, since it's a visual/animation-dispatch issue, not collision.)
 **Severity:** MEDIUM (movement/collision correctness in dungeons)
 **Filed:** 2026-06-14
 **Component:** physics — EnvCell collision (doors, portal openings, cell geometry)