# HANDOFF — 2026-09-10 (transparency hardening applied)

## Branch / Commit State

`main` HEAD will be = the new transparency-hardening commit (slice 14). Ahead of
origin by 19, NOT pushing (user ruling: no push until web-overlay transparency AND
audio-silence are addressed).

## ACTIVE THREAD (ONE problem at a time)

**Web-uri transparency — branch (a) CONFIRMED and FIX-APPLIED, awaiting the verify take.**
The 12:54/13:50 dumps proved the REAL widget document captures TRANSPARENT
(`%TEMP%\ytLive-web-8d7234ec…-w1..5.png` alpha max 0/logged alpha 100% zero) YET the
recording kept showing a black opaque box over the element rect (1231,679,705,396 — crisp
edges, interior mean RGB ≈(1,6,13), NOT the desktop). Conclusion: the OLD inline
`element.style.background='transparent'` injection only holds while the page has nothing
to paint; once the widget connects and repaints a container background-COLOR, the capture
re-opaques → black box. That is the OBS-solved class ("all web-uri resources paint their
own background").

**Slice 14 change (commit target):** `WebView2Manager.TransparentBackgroundScript` is now a
pre-parse `<style id='ytl-transparent-bg'>` wiping `background-color:transparent !important`
on `html,body,html *` (background-images/art survive — only background-COLOR targeted).
Idempotent by element id; `!important` outranks every page rule (OBS forums 2016 `body {
background-color: rgba(0,0,0,0) !important }` + div variant, woahtech OBS custom-CSS guide —
both cited in the commit message and `MyMistakes.md`).
- `internal const` + regression test `TransparentBackgroundScript_Is_A_Important_Element_Wide_Wipe`
  (asserts element-wide `!important`, style-element form, and that the losing inline
  `.style.background=` form is gone).
- Build 0 warnings; 9/9 WebView2Manager tests pass.

## THE ONE REMAINING STEP (verify, no further analysis)

1. User REPLACES the app (build is current) and records the Live scene, widget animating,
   like the 12:54/13:50 takes.
2. Verdict: element rect shows scene bg with widget art over it (NO black box) → transparency
   C LOSED, push gate #1 clears. If it still shows a solid black box you can SEE at a glance
   inside the widget's 705×396 area, bring it + then (and ONLY then) audit what other layer
   paints that rect in the composite — the web capture has been exonerated twice.
3. Then the queued layer-order-save bug (dragging an element over another doesn't persist
   `SortOrder`) is the next single use case.

## Other threads (paused)

- **Audio silence** — `f3d578c` has per-5s `Audio live:` telemetry; next take with desktop
  audio ACTIVE names the stage. Push gate #2.
- **Webcam missing** — "MJPG negotiation refused (being used by another process)". Queued.
- **Web capture speed** — ~10-14Hz effective, user satisfied. Revisit only on request.

## Landmines

- testhost shares startup.log with the app — filter by time.
- App was running at commit time; `taskkill //F //IM ytLive.exe` (Windows `taskkill.exe`,
  bash-quoted `//F //IM`) before rebuilds, and re-run if `MSB3021` copy-lock appears.
- Build/tests: `/mnt/c/Program Files/dotnet/dotnet.exe build …` / vstest.
- Probing: `/mnt/c/Program Files/Krita (x64)/bin/ffmpeg.exe` / `ffprobe.exe` — Windows exes
  take Windows-style paths.
- Never re-derive the transparency story again — MyMistakes "SPIN GUARD → RESOLVED" is the
  record (wash-rinse-repeat cost the user a whole session).