diff --git a/docs/research/2026-06-10-corner-seal-refuted-openings-edgeon-handoff.md b/docs/research/2026-06-10-corner-seal-refuted-openings-edgeon-handoff.md
new file mode 100644
index 00000000..4ac223f9
--- /dev/null
+++ b/docs/research/2026-06-10-corner-seal-refuted-openings-edgeon-handoff.md
@@ -0,0 +1,90 @@
+# §2b corner "camera-seal" REFUTED — both §4 siblings converge on edge-on clip collapse
+
+**Date:** 2026-06-10. **Branch:** `claude/thirsty-goldberg-51bb9b`.
+**Commits this arc:** `b21bb28` (corner-seal replay apparatus + characterization).
+**Earlier same day:** `c4df241` closed the outdoor full-world flap (depth-mask leak —
+see `2026-06-10-flap-outdoor-fullworld-CLOSED-depthmask-leak.md`).
+
+---
+
+## 0. TL;DR
+
+After the depth-mask fix, the user re-validated the §4 siblings and reported two symptoms:
+(1) background covering windows/entrances/passages during ALL transition types
+(room↔room, indoor↔outdoor, cellar↔floor), and (2) background at certain angles when
+pressing the camera into an interior corner ("like the camera is clipping into the wall").
+
+A fresh `[flap-sweep]` capture + a dat-backed replay harness settle it:
+
+- **The §2b "eye penetrates the wall → camera-seal failure" hypothesis is REFUTED.**
+  Every zero-contact camera traversal in the capture runs through a **real opening**:
+  - the viewer-outdoor "escapes" (48 frames) go through **0170's exit-door portal**
+    (`other=0xFFFF`, local x[5.55,7.45] z[0,2.5]) — the player was standing at the
+    threshold (`playerCell` flickering 0031↔0170);
+  - the corner-press frames (player=0172, viewer=0171, 2,963 frames) go through the
+    **0171↔0173↔0172 doorway chain** — 0173 is a 20 cm doorway-threshold cell (two
+    parallel portal planes at local x=4.10 / x=3.90). The captured eyes land **inside
+    the door-opening rectangle**, 0.35 m past the doorway plane.
+- **Camera collision is healthy:** 8,703 of 14,230 indoor sweeps in the same capture
+  collided (pull-in up to 2.77 m, valid normals). Nothing penetrates solid geometry.
+- Therefore the corner symptom is **render-side**: with the eye hovering at/near an
+  opening's plane, the portal's screen projection collapses **edge-on**, the flood
+  through the opening dies for those frames, and the room/world behind it (often the
+  room the player is standing in) is not drawn → background color. That is the **same
+  §2a mechanism** as the transition flashes. **§4 is now ONE mechanism, not two.**
+
+## 1. Evidence chain
+
+1. **Capture:** `corner-seal-capture.log` (untracked, worktree root) — clean run,
+   user did corner presses + doorway passes. Probes: `ACDREAM_PROBE_FLAP` +
+   `ACDREAM_PROBE_PVINPUT`.
+2. **Sweep classification:** 17,999 `[flap-sweep]` frames; 48 player-indoor →
+   viewer-outdoor "escapes", ALL `ok=True pulledIn≈0 collNormValid=False`; plus the
+   player=0172/viewer=0171 corner population (2,963 frames, same signature).
+3. **Replay harness:** `tests/AcDream.Core.Tests/Physics/CameraCornerSealReplayTests.cs`
+   (`b21bb28`) — loads the real Holtburg building cells (0x016F–0x0175), replays the
+   captured sweeps with the camera's exact call shape, reproduces the zero-contact
+   traversals deterministically, and maps the geometry:
+   - full portal/room map (printed by the Diagnostic fact): 016F + 0170 carry the exit
+     doors; 0173 is the 0171↔0172 threshold; 0175/0174 are the cellar chain below 0171.
+   - containment walk: no point of the "escape" paths lies inside solid cell volume.
+   - the assertion fact is now a **characterization**: those opening paths must pass
+     clean (no collision, full traversal) — pins the verified-correct behavior.
+4. **`SmartBox::update_viewer` port verified verbatim** against decomp :92761-92892
+   (including both fallbacks — retail also places the camera at the un-collided sought
+   eye when the sweep fails). No divergence in the camera layer.
+
+## 2. What this kills (DO-NOT-RETRY — added to the render digest)
+
+- Any "camera-seal" / camera-collision fix for the corner symptom. The camera is right.
+- Re-opening the membership/physics side for these symptoms — the digest's #106/#98
+  exonerations stand; `playerCell` flicker at thresholds is the player genuinely
+  straddling a portal.
+
+## 3. NEXT (the §4 fix arc — gated on the retail oracle read)
+
+Per the 2026-06-08 handoff §5.3 (never done): **read retail's edge-on clip handling
+BEFORE designing anything**:
+
+- `PView::GetClip` (0x5a4320, decomp ~:432344)
+- `PView::ClipPortals` (0x5a5520, :433572)
+- `ACRender::polyClipFinish` (the w=0 clip, :702749)
+
+Questions: does retail's clip collapse to zero area at edge-on exactly like ours; does
+retail keep a flooded cell once added (per-frame hysteresis); what does retail draw for
+the 1–2 frames the eye is inside a threshold cell (0173-style reveal slab)? Cross-check
+our `PortalProjection.cs` at edge-on specifically. The fix lands either in clip
+robustness (`PortalProjection` / `PortalVisibilityBuilder`) or in eye dynamics (retail
+holds the eye collided/head-on 93% at doorways while ours floats — `[flap-sweep]`
+pull-in distribution is now measurable in the harness).
+
+Conformance pre-gate for whatever fix: "smooth monotonic eye through/at a doorway ⇒
+monotonic vis (no oscillation)" — buildable on the CameraCornerSealReplayTests fixture.
+
+## 4. Apparatus inventory (reuse, don't rebuild)
+
+- `CameraCornerSealReplayTests` — dat-backed sweep replay + room map + containment
+  (Diagnostic fact prints everything; extend its sample table from any new capture).
+- `corner-seal-capture.log` — the full corner+doorway capture (UTF-16LE).
+- `[flap-sweep]` / `[flap-cam]` / `[pv-input]` probes — unchanged.
+- The §4 outdoor flap probes (`ACDREAM_PROBE_CLIPROUTE`, `[gl-state]`) remain in-tree.