# §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.