docs #137: corridor gate PASSED; file #176 (purple seam flash) + #177 (stairs pop-in) + the window-climb repro

User gate 2026-07-06 evening: 'not collision anymore. Good.' — the
corridor-phantom arc (stub sliding-normal leak, slide_sphere opposing
branch, CheckOtherCells stale footCenter) is user-verified fixed.

Same gate surfaced three follow-ups:
- #137 remaining scope: the window/opening climb — running into the last
  corridor window steps the player up into the opening, head+camera
  through its roof. Log anchor: transit 0x8A020179 -> 0x8A02017E at
  (90.209,-41.774,-5.209) — sill ~0.8m > stepUpHeight 0.6, climbed anyway.
- #176 (NEW, render): purple floor flashing at cell seams, camera-angle
  dependent — survives the physics fix, so render-side; the seam floors
  ARE portal polygons to the under-rooms (placeholder-surface suspicion).
- #177 (NEW, render): stairs between levels pop in/out — invisible from
  the corridor, appear on entering the room, vanish on the last step
  down. The #119 visibility class, dungeon edition.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

docs/ISSUES.md

@@ -46,6 +46,65 @@ Copy this block when adding a new issue:
 
 ---
 
+## #177 — Dungeon stairs pop in/out across levels (invisible until entering the room; last step vanishes running down)
+
+**Status:** OPEN
+**Severity:** MEDIUM (visible geometry churn in the M1.5 dungeon)
+**Filed:** 2026-07-06
+**Component:** render — indoor portal-flood visibility (dungeon multi-level)
+
+**Description (user, Facility Hub, 2026-07-06 gate session):** a staircase
+connecting two levels (a) disappears on roughly the last step when running
+DOWN it, (b) is not visible when looking into the stair room from the
+corridor, and (c) pops into existence on entering the room. Classic
+portal-visibility miss: the stair geometry's cell is not reached by the
+portal flood from the viewer's cell until the viewer crosses into it.
+
+**Root cause / status:** unknown; the #119 class (visibility volumes /
+portal flood), dungeon edition. Level connections here go through
+floor-portal slabs (see the #137 topology notes — corridor floors are
+portal polygons to under-rooms), which the render flood may treat
+differently from wall portals. Read
+`claude-memory/project_render_pipeline_digest.md` FIRST (Option A: one
+DrawInside(viewer_cell); DO-NOT-RETRY table applies). Log
+`launch-137-gate2.log` covers the session (cells around
+`0x8A020182 → 0x8A020183` show a −6 → −9 level transition on stairs).
+
+**Acceptance:** the staircase renders whenever its room is visible through
+the connecting opening, and stays rendered through the full descent.
+
+---
+
+## #176 — Purple flashing on dungeon floors at cell seams, camera-angle dependent
+
+**Status:** OPEN
+**Severity:** MEDIUM (visible artifact along every corridor seam in the M1.5 dungeon)
+**Filed:** 2026-07-06
+**Component:** render — floor-portal polygons / portal surface state
+
+**Description (user, Facility Hub, 2026-07-06 gate sessions):** the floor
+flashes with a purple overlay at cell seams, at certain camera angles only.
+Initially suspected to be the #137 physics oscillation exposed by the
+render; the physics fix landed (seam shake gone, user-gated) and the flash
+REMAINS — so it is a render-side issue in its own right, correlated with
+camera angle.
+
+**Root cause / status:** unknown. Suggestive topology fact from the #137
+work: the corridor floor tiles ARE portal polygons (PortalSide floor
+portals to under-rooms — e.g. 0x8A02016E polys 1/3/5 → 0x011E, spans in
+`Issue137CorridorSeamInspectionTests.CorridorCell_PortalPolygonWorldSpans`),
+so "the floor at the seams" is exactly where portal surfaces live —
+suspect the portal polygon being drawn with a placeholder/uninitialized
+surface under some flood/culling state ([[feedback_ui_resolve_zero_magenta]]:
+magenta = the 1×1 placeholder texture class). Angle-dependence points at
+the visibility/stencil state, not geometry. Read
+`claude-memory/project_render_pipeline_digest.md` FIRST.
+
+**Acceptance:** no purple/placeholder flashes on dungeon floors from any
+camera angle at the corridor seams.
+
+---
+
 ## #175 — Door collision registers the Setup PLACEMENT pose, not the motion-table CLOSED pose (phantom slab behind the visual door)
 
 **Status:** 🟡 FIX SHIPPED 2026-07-05 (same session) — pending user gate (Facility Hub double door: closed blocks AT the visual panels from both sides, no embed, no phantom wall; Holtburg cottage door unregressed).
@@ -1183,6 +1242,25 @@ walls** in particular. (Symptoms not fully characterized yet: likely walking thr
 openings that should block / blocking at openings that should pass, and door collision not
 matching the door's open/closed state.)
 
+**✅ CORRIDOR GATE PASSED 2026-07-06 evening (user: "not collision anymore.
+Good.")** — the corridor phantom arc (mechanisms 1–3) is user-verified
+FIXED. REMAINING #137 scope from the same gate session:
+- **Window/opening climb (NEW repro, this is #137's "openings in walls"
+  half):** running into the last corridor window, the player STEPS UP into
+  the opening — head (and camera) pop through the opening's roof. Retail
+  blocks this. Log anchor (`launch-137-gate2.log`): transit
+  `0x8A020179 → 0x8A02017E at (90.209,-41.774,-5.209)` and back — the
+  south-wall opening at y≈−41.7, sill ≈0.8 m (world z −5.2) — climbed
+  despite stepUpHeight 0.6. Investigate the step-up acceptance (sill
+  height vs budget; suspect the step-up's walkable probe accepting the
+  sill top or the opening's floor from the neighbor cell).
+- Doors half (block/pass per open state) — unchanged.
+Two RENDER issues also observed at the gate (filed separately below as
+#176/#177): the purple floor flashing at seams is angle/camera-dependent
+(the floor IS a portal polygon to the under-room — likely the portal
+surface drawn under some culling state), and a stairs pop-in/out between
+levels (the #119 visibility class, dungeon edition).
+
 **SEAM SHAKE FIXED (same day): the stale `footCenter` in `CheckOtherCells`'
 per-cell loop** — the P2 cellar-lip lesson one loop deeper. A mid-loop
 other-cell query can MOVE the sphere (the boundary full-hit dispatches