docs: park #181 with the full elimination ledger; #177 stairs pickup handoff + companion prompt

#181 parked per user decision (the flicker survived the 7-fix ladder; every fix individually verified and standing). ISSUES #181 carries the shipped-commit list, the evidence-backed eliminations, and the four still-open leads (top: capture a clean frame pair at THE USER'S pose - never done). New handoff docs/research/2026-07-06-177-stairs-pickup-handoff.md: the stair-cell admission miss (0x0178/0x0182/0x0183), the existing Issue176177 replay scenarios as the entry point, the 0x0181 sliver adjacency lead, the lighting DO-NOT-REOPEN, and the companion prompt. Render digest re-bannered.

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

docs/ISSUES.md

@@ -46,8 +46,33 @@ Copy this block when adding a new issue:
 
 ---
 
-## #181 — Portal-flood output flaps on micron eye noise → cell (+ its scoped lights + scissor AABB) strobes in/out (~10 Hz)
+## #181 — Facility Hub flicker at pressed camera (residual after the full 2026-07-06 fix ladder) — PARKED
 
+**⏸️ PARKED 2026-07-06 (user decision after the static-curve gate: "flickering is still
+there — file it, document it, move on to the stairs").** The session shipped SEVEN
+fixes/ports, every one individually verified, and the user-visible flicker at their
+pressed-camera pose SURVIVED all of them. Shipped: `48aaab81` (stateful camera sought),
+`f10fe4e9` (retail adjust_to_plane — the dead ACE port), `87cddce2` (static light
+re-apply stacking), `3f34bca0` (retail viewer step subdivision + viewer-exempt abort),
+`233b469b` (A7 fix #2 — stationary weenie fixtures on retail's STATIC light curve,
+Ghidra-verified 0x0059c8b0). ELIMINATED with evidence: camera eye strobe (post-fix logs:
+zero >2 cm jumps), display tearing (VSync-on 30 fps still shows it; windowed+DWM never
+tears anyway), light-pool membership + applied per-cell sets ([seam-cell]: frozen across
+107k parked frames incl. every vis-flap frame), the light-stacking leak (fresh-session
+flicker), the flood-root flap (stable at the user's standing pose), the sliver-cell's
+own geometry (zero-area region). STILL-OPEN leads for whoever resumes: (1) the parked
+clean captures at MY pose show a pixel-static scene — the flicker has never been
+captured in a frame pair at THE USER'S pose with an unobstructed window: get the user to
+hold the pose, capture ≥8 frames, diff (the apparatus is in the scratchpad scripts —
+capture-still.ps1/imgdiff.ps1/imgdiffmap.ps1); (2) the deep-cell vis 31↔32 flap
+(0x8A020181 sliver admission on the wall-press mm wobble — both real, both measured,
+consequence unproven; Issue181VisFlapReplayTests + Issue181WallPressEquilibriumTests are
+the pins); (3) cdb-trace retail's wall-pressed viewer to compare equilibria (toolchain
+proven, needs a live retail session); (4) the static-curve fix may have changed the
+artifact's LOOK (brightness) without killing the motion-flicker — re-characterize
+before assuming tonight's captures still describe it.
+
+**Original filing (mechanism evidence trail below remains valid):**
 **Status:** OPEN — mechanism PINNED from live evidence; the knife-edge test not yet identified
 **Severity:** HIGH (THE user-visible #176 flicker that survived the #180 camera fixes: washed
 regions with hard screen-space rectangle boundaries pulsing at a parked camera)

docs/research/2026-07-06-177-stairs-pickup-handoff.md

@@ -0,0 +1,131 @@
+# Pickup handoff — #177 dungeon stairs pop in/out (portal-visibility miss at the stair cells)
+
+**Paste the companion prompt (bottom) into a fresh session.** Read this file, then
+`claude-memory/project_render_pipeline_digest.md` (top banners), then **ISSUES #177**
+(full entry — including the superseded lighting attribution and why it was re-attributed
+to VISIBILITY at the 2026-07-06 gate).
+
+## TL;DR — what #177 is
+
+Facility Hub (0x8A02), the staircase connecting two levels (corridor 0x0178 → ramp
+0x0182 → lower room 0x0183): (a) **invisible looking into the stair room from the
+corridor**, (b) **pops into existence on entering the room**, (c) **the last step
+vanishes running down**. The 2026-07-06 gate PROVED this is NOT lighting (the A7
+visible-cell light fix shipped and the stairs were still missing looking back from the
+corridor) — it is a **portal-flood admission miss**: the stair cells are not reached by
+`PortalVisibilityBuilder` from the viewer's cell until the viewer crosses in. The
+digest tags it "#119 class, dungeon edition; floor-portal level links."
+
+**Acceptance:** the staircase renders whenever its room is visible through the
+connecting opening, and stays rendered through the full descent.
+
+## Where to start (the apparatus already exists)
+
+1. **`tests/AcDream.App.Tests/Rendering/Issue176177FacilityHubFloodReplayTests.cs`** —
+   headless flood replays against the REAL dat, with two scenarios written for exactly
+   this issue and never fully mined:
+   - Scenario A (stair approach): eye in corridor 0x0178 at several x positions +
+     pitches, printing whether ramp 0x0182 / lower 0x0183 are admitted.
+   - Scenario B (descent): eye path down the ramp, printing per-step admitted-set
+     diffs (the "last step vanishes" case).
+   **Run these FIRST** — the miss should reproduce headlessly, and the printed
+   admitted sets name which portal hop fails.
+2. **`Issue181VisFlapReplayTests.cs`** — the same-file pattern for perturbation
+   sweeps + per-cell view-region AREA measurement (the shoelace diagnostic). Cell
+   **0x8A020181** — right next to the stair complex 0x0182/0x0183 — rides a
+   knife-edge zero-area admission; the #177 miss and the #181 sliver are plausibly
+   the SAME flood defect seen two ways (a floor-portal chain that clips to nothing
+   from above).
+3. **The builder:** `src/AcDream.App/Rendering/PortalVisibilityBuilder.cs`. The
+   admission gates per portal hop, in order: the side test (`CameraOnInteriorSide`,
+   PortalSideEpsilon 0.01 — AP-19), then `ClipPortalAgainstView` (homogeneous clip
+   against the parent's accumulated region; `clippedRegion.Count == 0` ⇒ the flood
+   stops there). For a DOWNWARD stair chain the suspect class is the FLOOR-portal
+   hop: a horizontal portal seen edge-on from the corridor clips to ~zero area
+   (exactly the 0x0181 sliver signature) and the chain below never floods.
+   `ACDREAM_A8_DUMP_PV=1` dumps per-portal census + EXIT-PROJ/EXIT-CLIP lines for
+   the camera cell (first 2 builds per cell).
+4. **Retail oracle:** retail PView floods portals with per-poly clip
+   (`polyClipFinish` — the W=0 clip pseudocode doc 2026-06-11) and DOES show stair
+   rooms through their openings. If our clip collapses a genuinely-visible aperture
+   to zero, compare `ClipPortalAgainstView` against `PView::ClipPortals`/`GetClip`
+   (decomp:433572) at the failing hop's exact geometry. #119's lesson applies:
+   visibility must derive from the same data that gets drawn
+   (`feedback_culling_bounds_from_drawn_data`).
+
+## What tonight's #180/#181 session gives you for free
+
+- All camera/sweep mechanisms are Ghidra-verified faithful (stateful sought,
+  adjust_to_plane, adjust_sphere_to_poly, viewer radius-anchored stepping) — commits
+  `48aaab81`/`f10fe4e9`/`3f34bca0`. The camera's `ViewerCellId` is trustworthy; the
+  render roots at it (Option A).
+- The wall-pressed camera wanders ~0.5 mm/frame in a bit-exact 12-frame limit cycle
+  (`Issue181WallPressEquilibriumTests` — measured, all local algorithms verified;
+  plausibly retail-class). Any admission knife-edge within that wobble band flaps
+  ~10 Hz (`[flap]` vis 31↔32, whole-session). For #177 this matters at stair
+  THRESHOLDS: expect flappy admission exactly at descent transitions.
+- Lighting is now retail-shaped: resident+player-anchored pool (d8984e87), idempotent
+  re-apply (`87cddce2`), stationary fixtures on the verified static curve
+  (`233b469b`). Do NOT re-open lighting for #177 — the gate already refuted it.
+- **#181 is PARKED** (see its ISSUES entry for the still-open leads). Do not resume
+  it inside the #177 arc; if stair work surfaces new flicker evidence, append to
+  #181's entry instead.
+
+## Watchouts
+
+- The old #177 root-cause text (128-cap light eviction) is SUPERSEDED — kept in the
+  entry for history. The re-attribution is the ⚠️ UPDATE block at the top of #177.
+- The flood replay's ViewProj must match production FOV/aspect (π/3, 16:9) — the
+  Issue181 test does; the older Issue176177 scenarios use 1.2 rad / 1280×720 (fine
+  for admission questions, but keep in mind for NDC-sensitive comparisons).
+- `Issue120ReciprocalPingPongTests.LoadAllInteriorCells` + `CornerFloodReplayTests.
+  ResolveDatDir` are the shared fixtures loaders (App.Tests); Core.Tests has its own
+  `ConformanceDats`.
+- A client may be running — the user manages its lifecycle; ASK before rebuilding if
+  the App DLL is locked (MSB3027 = lock, not code).
+
+## State
+
+- Branch `claude/vigorous-joliot-f0c3ad` @ `233b469b`+ (this handoff's commit).
+  Suites green: Core 2600+2skip / App 733+2skip / UI 425 / Net 385 / Content 56.
+- Test char spawns in the Facility Hub corridor (0x8A020142 area); the stair complex
+  is 0x0178/0x0182/0x0183 (+0x0181 adjacent).
+- Launch recipe + graceful-close rules: CLAUDE.md "Running the client". The
+  GDI-capture + keybd_event autonomous visual loop scripts live in this session's
+  scratchpad (capture-still.ps1, imgdiff.ps1, imgdiffmap.ps1, crop.ps1) — recreate
+  from the #180 handoff's recipe if the scratchpad is gone.
+
+## Companion prompt (paste into the fresh session)
+
+```
+Fix #177 — Facility Hub stairs pop in/out across levels (invisible from the
+corridor, pop on entry, last step vanishes running down). The 2026-07-06 gate
+re-attributed this from lighting to a PORTAL-FLOOD ADMISSION MISS at the stair
+cells (0x8A020178 corridor → 0x0182 ramp → 0x0183 lower; 0x0181 adjacent) — do
+NOT re-open lighting (gate-refuted; the A7 fixes are in and verified).
+
+READ FIRST, in order:
+1. docs/research/2026-07-06-177-stairs-pickup-handoff.md (apparatus map, the
+   #181 park boundary, watchouts)
+2. claude-memory/project_render_pipeline_digest.md (top banners)
+3. docs/ISSUES.md #177 (the ⚠️ UPDATE block supersedes the old root cause)
+
+START by running the existing headless replays (Issue176177FacilityHubFloodReplay
+Tests Scenarios A/B — real dat, no client): they print per-pose admitted sets for
+the stair cells and should reproduce the miss offline. Then trace the failing
+portal hop through PortalVisibilityBuilder's gates (side test → ClipPortalAgainst
+View; the floor-portal seen edge-on clipping to ~zero area is the suspect class —
+the same signature as #181's 0x0181 sliver next door). Retail oracle for the clip:
+PView::ClipPortals/GetClip (decomp:433572) + the 2026-06-11 polyClipFinish W=0
+pseudocode doc. Workflow: replay → identify the gate → read retail → pseudocode →
+port → the replays become pins → autonomous visual loop (stair approach/descent
+drive) → user gate.
+
+#181 (the pressed-camera flicker) is PARKED with its evidence ledger in ISSUES —
+if stair work surfaces flicker evidence, append there; don't resume it in this arc.
+
+State: branch claude/vigorous-joliot-f0c3ad, suites green (Core 2600+2skip / App
+733+2skip). Test char spawns in the Facility Hub corridor. A client may be
+running — the user manages its lifecycle; ASK before rebuilding if the App DLL
+is locked.
+```