ytLlive/HANDOFF.md

HANDOFF — session state

Current operational state, read right after TASKS.md. Trust this file as the truth of what is in flight — do not re-derive from git/fs unless it points at a problem. Conventions: schema.md. Rewrite this file at session end, compaction, or any interruption.

Session state (last updated: 2026-08-13)

• Branch: main. TASK 4 ship step 5.5 is implemented, tested, and staged for commit — the social bar bug-fix branch (drag snap + fediverse heal + the bar on the live output). Uncommitted: the feature work, tests (+8 → 155), and the memory updates in TASKS.md / ai.md / Services/index.md / this file. Next action is git add + commit + push (feature + its memory docs in ONE commit, per the working rules).

• Finished this session: both reported bugs diagnosed to root cause and fixed; compositor rendering of the social bar added per user approval.

  • Bug 1 — drag didn't snap: Canvas.SetTop set a local value that permanently overrides {Binding SocialBarTop}; the release-time snap could never win. Fixed with SocialBarSnap.Decide (direction-snap during drag, ±6px deadzone) + bar.ClearValue(Canvas.TopProperty) on release.
  • Bug 2 — Mastodon showed the generic honeycomb: @gramps@llamachile.tube had Software = NULL (nodeinfo only ever asked of the landing-page domain). Fixed via subdomain probing (mastodon. → social. → … candidates, ~15s budget), a load-time heal (MainViewModel.HealFediverseSoftwareAsync), and a settable SocialEntry.FediverseSoftware that raises LogoData.
  • Compositor bar: Services/Compositor/SocialBarRenderer.cs (new, WPF RenderTargetBitmap → straight-alpha strip), SceneCompositor blits it above the flash, FramePump gains a re-read-each-frame socialBar: seam, MainViewModel owns the strip frame.

• Verified: Windows-host build 0 warnings; 155/155 tests passing (147 baseline + 8 new). Full commit contents pending.

• Landmines:

  • The pump reads the active scene on a background thread while the UI can still edit it — a concurrent-mutation exception is contained (logged + Failed + the pump stops), not a crash. The background thread + video pipeline is the new reality since ship step 5.
  • StopAsync must stop the encoder (closes stdin) before awaiting the pump loop — closing stdin unblocks a write stuck on pipe backpressure; the reverse order deadlocks.
  • FramePump.IsRunning must be set true before the loop starts (a completed-task delay can run the first iteration synchronously on the caller's thread).
  • StartAsync never throws; the VM fires-and-forgets it. Failed while live flips StreamStatus.Error (minimal — real health surfacing is ship step 6).
  • The heal runs off the UI thread and applies via the dispatcher; a config swap mid-heal (dialog Save) can orphan the healed values on the old entries — harmless (best-effort, re-healed next load).
  • Tests never instantiate MainViewModel directly except the round-clip integration test (a real MainWindow), which never goes live — keep it that way.
  • Sandbox can't reach outbound HTTPS — the subdomain-probe logic is verified via stub-handler tests only, not against the real mastodon.llamachile.tube.

• Next step: commit + push ship step 5.5 (one commit incl. memory docs). Then TASK 4 ship step 6 — health stats: bind FramePump.HealthUpdated (bitrate/FPS/duration) into the bottom bar. Nothing else queued — do not expand the task queue on your own. Optional, not queued: rewriting the healed entry's ProfileUrl to https://mastodon.llamachile.tube/@gramps (user must say the word).

• Secret/DB/port facts live: OAuth client id/secret in Helpers/OAuthCredentials.cs; OAuth session token in Helpers/TokenStore.cs (DPAPI → %APPDATA%\ytLlive\ytLlive.auth); layout DB %APPDATA%\ytLlive\ytLlive.db (schema v8; SocialEntry.Software column is a column-presence migration like the others, no version bump); OAuth callback http://localhost:8765/oauth2/callback; crash log %APPDATA%\ytLlive\startup.log.