# HANDOFF — 2026-09-10 (late afternoon)

## Branch / Commit State

`main` HEAD currently = `f3d578c` (slice 12 audio telemetry). **Slice 13 (web transparency
diagnostic re-point) is uncommitted** in the working tree. Ahead of origin by 18, NOT pushing
(user ruling: no push until web-overlay transparency AND audio-silence are addressed).

## ACTIVE THREAD (the user's directive: ONE problem at a time)

**Web-uri transparency: still a black, opaque block** (take `ty-20260910-1202-0000-2.mp4` —
user: "the web-uri resource transparency is still a black, opaque block. The desired animation
runs just fine."). The animation-speed work is done; transparency is now THE web problem.

Institutional memory (MyMistakes, spin-guard entry): WebView2 `CapturePreviewAsync` honors the
page's CSS — the pre-parse injection (`1a39b09`, `AddScriptToExecuteOnDocumentCreatedAsync`)
is the recorded fix and is INTACT in `WebView2Manager.cs` (line ~157). The "? VERIFY" was never
closed because the diagnostic dump + alpha log bound to the FIRST capture ever = the about:blank
placeholder (blind; 5/5 sessions alpha=0 rgb=0).

**Slice 13 change (uncommitted):** re-point the instrument at reality —
- `WebSourceSession.WidgetDumpRemaining`; `NavigationCompleted` arms `= 5` when the newly-loaded
  document is NOT about:blank.
- Next 5 captures dump `%TEMP%\ytLive-web-<id>-w1..5.png` + `AlphaStats(...)` + FindContentBounds
  to startup.log.
- `AlphaStats` extracted from the old inline first-capture block.

Build 0 warnings; 8/8 WebView2 tests pass (runtime not instantiable — re-point is log-only, no
new test). Suite otherwise 290/291 (pre-existing compositor pixel).

## THE DECISION LADDER (no more cargo-culting)

1. User launches the app with the widget sources active, waits ~10s, closes. (NO recording needed.)
2. Read the `widget capture [1..5/5]` lines in startup.log:
   - **zero% ≈ 0 (opaque):** pre-parse injection did NOT hold for this widget's own CSS →
     FIX = stronger transparent-background enforcement (document-level `!important` stylesheet
     injected pre-parse + re-asserted, per the OBS user.css precedent) OR chroma-key the known
     backdrop color in `CaptureFrame`. Pick after seeing the `-w1..5.png` PNGs.
   - **zero% large + tight contentBounds:** the capture HAS transparent margins → the recording's
     black block lives downstream → audit the compositor web-layer blend/underlay (PMA-vs-straight
     alpha, black pre-fill). Do NOT touch the capture path.
3. Implement the branch's fix with ONE integration test (chroma-key math or compositor blend has
   testable seams), docs same-commit, then ONE verification recording.

## Other threads (paused)

- **Audio silence** — `f3d578c` added per-5s `Audio live:` telemetry; next take with desktop
  audio ACTIVE + those lines names the stage. Push gate #2.
- **Web capture speed** — 30Hz NOT achieved (35-117ms/capture → effective ~10-14Hz). The
  animation "runs fine" so the user is satisfied; revisit only if they want more.
- **Webcam missing** in the 10:38/12:02 takes — "MJPG negotiation refused (being used by
  another process)" at startup. Queued behind transparency+audio.

## Landmines

- testhost shares startup.log with app — filter by time.
- `taskkill //F //IM testhost.exe //IM ytLive.exe` before rebuild.
- Build/tests: `/mnt/c/Program Files/dotnet/dotnet.exe build …` / vstest.
- Probing: `/mnt/c/Program Files/Krita (x64)/bin/ffmpeg.exe` / `ffprobe.exe`.
- Do NOT delete the crop/compositor paths while debugging source alpha (MyMistakes rule 3 —
  take-25 vandalism).
- The user is frustrated with take-loops; the widget dump needs NO recording — an app launch
  suffices. Ask for launch + 10s + close, not a take.