# HANDOFF — 2026-10-16 (work committed locally; NOT pushed — push at the next milestone) ## At a glance - **Branch** main, tracking `origin/main`. **origin/main = `931ab46`; HEAD = the tip commit "Read the first instrumented take: the judder did not reproduce, no element is slow"** — **4 ahead, 0 behind** (nothing pushed this session; per the commit/push policy, push only when the creator says so). This file cannot record its own commit's hash — amending a commit changes that hash — so the tip is named by subject. - The four local-only commits: `3cb29ea` (**previous session's HANDOFF refresh — the old handoff claimed it was pushed; it never was**), `a3a4681` (per-element composite timing + scene dump), `84cbec2` (FramePumpTests thread-safe log sink), the tip. Always check `git log origin/main..HEAD` — never a handoff's own "0 ahead" claim. - Working tree clean after the tip commit. - **The creator's first take of the instrumented build happened today** (18:40–18:44, Release recording). **The judder did NOT reproduce and no element is slow** — full reading in `ai.md` → "✅ What the first instrumented take said". Nothing is queued to fix from it. ## This session (2 commits — both unpushed) 1. **`84cbec2` — FramePumpTests race fix (own commit, creator-approved).** A full-suite failure (`Stats_ReportRealRendersAndDistinctWebcamFrames…`, "Collection was modified") was a **test-side data race**: a plain `List` enumerated by the test while the pump logged from its own thread. Fixed with `ConcurrentBag`. **Proof: full suite 428/428 passed, 0 warnings.** Lesson recorded in `MyMistakes.md` → "known failure label" (2nd instance). 2. **The reading (this is the tip commit).** Take `ty-20261016-1841-559-0002.mp4` (174.5s, Release `e95154d9`, 1920×1080 1:1, recording): **60 composites/s, avg render 1.0–1.1ms, biggest element = webcam 0.4ms**, backdrop 0.2ms, other four under the 0.1ms floor, `cache 151R/150H`, webcam 30.0/s at the resolver (longest gap 50ms), and the FILE holds **29.6 distinct webcam images/s with 82% of images held exactly 2 frames**. No culprit element exists in this take. - **The historic slow numbers are different configurations:** Oct 9 19:48 (still on disk) was the **vertical** tier (`comp=608x1080`, 45ms, 92 renders/5s); Oct 5 12:01's geometry was never logged (the `scene=/comp=` suffix didn't exist) so the map's 21:9 story stays a hypothesis. Every slow window shows `cache xR/0H`; one Oct 5 take latches fast→slow (1.5ms → 45ms) within 15s. - **Corrected in the map (not appended):** "it was never Debug-vs-Release" is withdrawn (same 1920×1080 tier: Oct 9 = 10.4ms vs today's Release 1.0ms, and `Build ` records no configuration), and the "same scene shape" 10:01/12:01 comparison is superseded. - **Same commit ships the probe + its recipe.** `scripts/webcam-cadence.py` (new tool): the ground-truth check for what the FILE holds. Its three traps (H.264 re-encoding defeats exact-pixel comparison; a round-clip crop's corners leak 60fps background; a fixed crop across a scene switch reads background) cost three wrong readings — all in `MyMistakes.md`, with an ffmpeg-native cross-check (`tblend=difference` + `signalstats.YAVG`) that agreed (52.2% duplicates / 28.6 distinct/s). ## Next step - **Creator take in the FAILING geometry — the vertical 1080p60 tier first** (creator's pick from the two options offered). Then, if the creator is willing, the 21:9 display config. - Read three lines in `%APPDATA%\ytLlive\startup.log`: `FramePump parts (N renders/5s): …` (which stage/element eats the budget), the `FramePump scene dump:` block (the shape), and `cache NR/NH` (0 hits = the slow state's signature). **No fix until that take names the stage** — the latch hypothesis (a composite pushed past the camera period can never reuse the whole-frame cache again) is unproven and the `parts` line is what decides it. ## Open (operational) - **verify.sh's known-failure whitelist is too loose (confirmed twice on 2026-10-16):** it passes when ANY known failure appears, so a new failure rides along unnoticed — and when the ONLY failure is a known flake (`LayerReorderPersistenceTests.RealMouseDrag_OnTheLayerList_PersistsTheReorder`, which passes in isolation) it reports "NOT the known pre-existing pair". **Follow-up: require EVERY failure line to be whitelisted**, and add `MasterLimiter_CapsTheLiveMix_OnThePipe` + `RealMouseDrag_OnTheLayerList_PersistsTheReorder` to the list. Not fixed here — `scripts/verify.sh` was never in a declared file list. - **A pre-existing stash from older work is still sitting there:** `stash@{0}` = "WIP on main: 0464593 Compositor: fast-path opaque 1:1 when source fills canvas" (NOT this session's; do not drop it blindly). - **Vertical-format regression (STALE, not fixed):** 1080p60-vertical selection no longer shrinks the capture border in the preview (`Controls/PreviewPane.xaml:319-322` + `MainViewModel.Streaming.cs` `ApplyStreamQuality`). Root cause unknown — paused. Note the vertical tier is ALSO the only slow take still on disk, so if the next take reproduces the 45ms there, this area gets touched twice. - ⛔ Sudo password rotation pending (user; then update both `CREDENTIALS.md` password lines). - TASK 56 secret scan before `gramps/LlamaCasty` goes public. - TASK 55 disk hygiene (`startup.log` uncapped — 23MB and the new lines add to it every 5s). ## Tests - Full suite **428/428 passed, 0 warnings** (2026-10-16, the gate run for `84cbec2`) — a completely clean run, including the audio tests that usually flake. - Known flaky-by-environment (all pass in isolation): `AudioPipelineTests.Mix_HonorsProviderGains…`, `MasterLimiter_CapsTheLiveMix_OnThePipe`, `LayerReorderPersistenceTests.RealMouseDrag…`, `Round_Clip_Corner…`. **Read verify.sh's output — it can pass with an unlisted failure present, or fail on a known flake (see above).** ## Secrets / paths (do not re-hunt) - Layout DB: `%APPDATA%\ytLlive\ytLlive.db` (SQLite, full-rewrite per save). Auth: `%APPDATA%\ytLlive\ytLlive.auth` (DPAPI). Startup log: `%APPDATA%\ytLlive\startup.log` (23MB). - Recordings land in `C:\Users\gramp\Downloads\recordings\` (`ty--