HANDOFF: social bar UX is wrong — user's correction lost to ctrl+enter, waiting for re-statement

HANDOFF.md

@@ -7,8 +7,17 @@
 
 ## Session state (last updated: 2026-08-12)
 
-- **Finished:** Webcam resource validation (merged to main, `e1d9e13`) + Social bar (on branch `social-bar`, ready to merge). Social bar: `Models/Socials.cs` (19 services + icons/URLs), `Services/SocialValidator.cs` (HTTP lookup seam), schema v7 (`Socials` + `SocialEntry` tables + `Scene.HasSocialBar`), footer Social button + [+/-] toggle, preview bar rendering (top/bottom, LCR), freemium cap (YT+1, premium seam). 85 tests passing, 0 warnings.
-- **In flight:** Social bar needs merge to main + push, then local testing.
-- **Landmine:** 19041 SDK projection gaps (see Branch A). `HttpSocialValidator` uses synchronous `.GetAwaiter().GetResult()` in the dialog flow — fine for a UI-blocking dialog, but a proper async dialog is a follow-up. The social dialog is currently a simple `ShowInputDialog` (inline WPF Window) — a proper dialog window with service picker + URL field + validation feedback is a UX follow-up.
-- **Next step:** Merge `social-bar` to main, push. Then: local test the social bar (add a social, verify bar renders, toggle on/off scenes). Then: continue TASK 4 (encoder + RTMP push) or the next queued item.
+- **Finished:** Webcam resource validation (merged `e1d9e13`) + Social bar v1 (merged `8868f98`). 85 tests, 0 warnings. On `main`, pushed.
+- **In flight:** Social bar UX is WRONG — the user was re-explaining what they actually want when ctrl+enter cut them off. The correction was NOT received. Do NOT continue the social bar until the user re-states their requirements. What I shipped vs. what they asked differs — they said "did you not understand what I asked for? It's pretty goddamn simple" but the message was lost.
+- **What I shipped (may be wrong):** YT auto-add from connected account, two-box dialog (YT handle + URL/handle for other), service auto-detection from domain, fediverse `@user@domain` support, footer Social button + [+/-] on the LEFT under scenes/sources, meter centered under preview, colored initials badges (not real service logos).
+- **What the user explicitly asked for (from their message before the cut-off):**
+  1. If creator is logged into YT, YT should be the first social by default (✅ done but UX may be wrong)
+  2. YT icon placemarker + text box asking for YT handle (I did auto-add — they may have wanted the placemarker + input flow instead)
+  3. Second box: URL or identifying string (`@gramps@llamachile.tube` is just as unique as a URL) (✅ done)
+  4. Pull the SERVICE logo, not the user's account logo, to represent the service (I used initials badges — they want actual brand logos)
+  5. Finding the user's account on the service validates the input (✅ done)
+  6. Socials bar should appear on the LEFT side of the volume control, centered under the scenes and sources listboxes (✅ done)
+  - **Something in this list is wrong** — the user said "did you not understand what I asked for?" but the correction was lost to ctrl+enter.
+- **Landmine:** 19041 SDK projection gaps (Exclusive/DeviceLost not projected; CameraStreamState.Failed by int). The social dialog uses sync `.GetAwaiter().GetResult()` — fine for now. `HttpSocialValidator` hits real network — tests must fake it.
+- **Next step:** WAIT for the user to re-state what they actually want for the social bar. Do NOT guess. Then fix it.
 - **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 v7); OAuth callback `http://localhost:8765/oauth2/callback`; crash log `%APPDATA%\ytLlive\startup.log`.