LlamaCasty/HANDOFF.md

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<string> enumerated by the test while the pump logged from its own thread. Fixed with ConcurrentBag<string>. 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 <hash> 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-<date>-<time>-<ms>-<seq>.mp4; a duplicate name gets a -2 suffix — the log's path and the file on disk can differ that way).
• LAN credentials: CREDENTIALS.md (gitignored). Google Cloud OAuth project number 198374416003, owned by llamachile.shop@gmail.com — verify at https://console.cloud.google.com/apis/credentials?project=198374416003.