`5x/sweep-2.md`

45 lines
# /5x sweep 2 — after 15beb44 (test server :9987 `--test`, restarted)

## Verify (5x/tools/sweep.sh 2 → 5x/out/sweep-2/, plus diagnostic re-runs)
| check | result |
|---|---|
| E2E journey Chromium | 19/19 PASS (LIVE path) |
| E2E journey WebKit (cold camera) | **CRASH ×4 in a row** before the fix (see #1) → after fix 21/21 PASS via SNAP front + SNAP back; in the full sweep run the camera happened to start fast → 19/19 LIVE |
| E2E journey Firefox | 19/19 PASS (LIVE path) |
| E2E journey WebKit, WARM_CAMERA=1 (forces LIVE path) | r0 CRASH (#3) · r1 FAIL (#3, now asserted) · r2–r5 19/19 PASS |
| /3x `/` `/captures` `/batch` | M1 M2 M3 B4 PASS (favicon fix held: M3 now PASS on /captures + /batch) |
| /3x `/cam` | M1 M3 B4 PASS · M2 FAIL = known SSE/virtual-time harness artifact (sweep-1 #4) |
| 3-engine console/4xx/broken-img probe | PASS (0 errors, final document status 200 on all 12) |
| index launcher + toolbar clickthrough ×3 engines | 33/33 PASS |
| history thumbs after scroll ×3 engines | PASS |
| missing-side rule API + UI ×3 engines | PASS |

## Caught → diagnosis
1. **REAL DEFECT (pre-existing since 9f4d2c2 / TK-12124, present at 126f917): the camera-timeout recovery
   never reaches the snap camera.** When the live camera doesn't answer within 8s, index.html toasts
   "Camera didn't respond — tap Photo 1 again to use the snap camera", but the next tap called
   `openTwoShotCam()` → `startTsStream()` again — another live getUserMedia and another 8s wait, never the
   native snap input the toast promises. On a phone with a hung camera the user loops forever and can't capture
   a FRONT/BACK at all — which blocks every downstream display this feature adds. Reproduced in WebKit
   (mock 4K capture device cold-starts in ~16s under host load; retry tap opened nothing for 20s, 4/4 runs).
   Small + directly in the capture path the feature depends on → fixed.
2. Harness: the E2E assumed a warm camera. It now takes whichever path the engine gives it and asserts that path:
   LIVE (shutter FRONT→BACK) or cold (timeout toast names Photo 1/2 → tap → native file chooser → real JPEG via
   `setFiles` → shotAdd → tile shows the photo). `WARM_CAMERA=1` forces the LIVE path so WebKit covers both.
3. Harness/env: cam.html remote shot in WebKit — the harness polled only 20s for `cam_live` and then fired the
   shoot anyway (silently). It now waits up to 45s and FAILS LOUDLY (with a screenshot + page text) if the
   phone camera never reports live. 1 of 5 warm WebKit runs still had the phone camera never come up
   (`cam_connected:false`) — WebKit mock-capture flake under load; not reproduced in 4 further runs. **Open,
   environmental**; listed in REPORT.
   Pre-existing observation (not fixed, out of scope): `pairStatus().cam_connected` goes false 20s after the phone
   opens /cam if the camera hasn't started, because `lastSeen` is only refreshed by camera-status posts, not by
   the live SSE connection.
4. Runner B5/B6 still SKIP: tried installing the runner's playwright-1.57 WebKit/Firefox builds; the download
   hung during extraction (killed, partial webkit-2227 removed). Engine coverage comes from the 1.61-based tools.

## Fixes (commit below)
- public/index.html: `_tsSnapNext` — set on camera-timeout; the next Photo 1/2 tap goes straight to the native
  `<input capture>` inside the fresh user activation; toast names the right photo (1 or 2).
- scripts/e2e-front-back-display.cjs: live/snap path handling + assertions, `WARM_CAMERA`, loud cam-not-live check.
- 5x/tools/sweep.sh (sweep driver), console-probe final-status check.