diff --git a/MainWindow.xaml b/MainWindow.xaml
index 4c25257..b847181 100644
--- a/MainWindow.xaml
+++ b/MainWindow.xaml
@@ -45,24 +45,10 @@
-
-
-
-
+
diff --git a/MyMistakes.md b/MyMistakes.md
index 0d6a81c..5c11844 100644
--- a/MyMistakes.md
+++ b/MyMistakes.md
@@ -89,3 +89,38 @@ paths to `\\wsl.localhost\Debian\…` and throws "not a valid application for th
OS" when handed a Linux ELF ffmpeg. So never plan to have dotnet exec a Linux
ffmpeg here; verify the contract with shell/python instead, and leave the
CLR→real-ffmpeg run to the native Windows suite.
+
+## WPF hit-test truth in tests: `UIElement.InputHitTest`, NOT `VisualTreeHelper.HitTest`
+
+(2026-09-01, the RoundClip "known failure" post-mortem — a failure the map carried as
+"not a regression" for weeks without ever recording WHY.)
+
+**The trap:** `VisualTreeHelper.HitTest(window, pt)` returned the window's
+`WebViewHostPanel` overlay (`IsHitTestVisible="False"`, `Opacity=0`, ZERO children) for
+EVERY point in the window — so a "corner is grabbable" assertion could never pass, and
+it looked like a real interaction bug. The actual input pipeline (`UIElement.InputHitTest`,
+what Mouse routing uses) correctly returned the element's Grid at elem-center/corner-in/
+corner-exact and fell through to CanvasGrid just past the corner. The product was fine;
+the TEST was probing an API that doesn't model input semantics.
+
+**Rule:** any test asserting "where does a click land" uses `window.InputHitTest(pt)` +
+`IsDescendantOf` — never `VisualTreeHelper.HitTest`.
+
+**Diagnosis recipe (how the lie was caught in ~3 probe cycles, no guessing):** add a TEMP
+probe `[Fact]` in the RealApp collection that hit-tests a spread of points
+(elem-center / corner-in / corner-exact / corner-out / bg-center) and `Assert.Fail`s with a
+composed dump: per-point VTH hit + `InputHitTest` hit + ancestor chain (`GetParent` walk
+with `#Name`) + panel properties (`IsHitTestVisible/Opacity/children/actual size`) +
+`TranslatePoint` origins. Run the class alone, read the message, delete the probe.
+
+**Two sibling facts learned the same session (record-once):**
+1. A UserControl owns its own XAML namescope — after extracting a region out of a window,
+ `window.FindName("InnerPart")` returns null; resolve the UserControl by its window-level
+ name, then `pane.FindName("InnerPart")`. And window-scope STYLES are invisible to a
+ UserControl's `StaticResource` at parse time — move such styles to `Themes/Controls.xaml`
+ (the app-scope rule exists for this).
+2. Per-class `dotnet.exe vstest` from WSL DOES execute the RealApp/`MainWindow` tests fine
+ (they passed natively 2026-09-01) — only the FULL suite hangs (WASAPI startup). And the
+ test process shares `%APPDATA%\ytLlive\startup.log` with the real app: lines like
+ `camera 'test-camera' failed` are test noise, not DB state — to check pollution, query
+ the DB directly (`python3 sqlite3`, `SELECT DeviceId FROM Webcam`), not the log.
diff --git a/TASKS.md b/TASKS.md
index a2d8537..9ab2605 100644
--- a/TASKS.md
+++ b/TASKS.md
@@ -1311,8 +1311,16 @@ What landed — core optimization + SceneGraph component, all in one commit:
**Verification:** SceneCompositorTests 4, StretchMathTests 4, BackgroundTests 16, SceneCatalogTests 18,
LayoutStorePersistenceTests 12, FramePumpTests 9, SceneGraphTests 1 all green. RealAppHost GUI/collection
-tests (SourceNaming, RoundClip, BackgroundHeal, ...) construct a real `MainWindow` and cannot run in a
-headless WSL session (pre-existing limitation, not caused by this change).
+tests (SourceNaming, RoundClip, BackgroundHeal, ...) construct a real `MainWindow` — **CORRECTED
+2026-09-01:** they DO run from WSL when invoked per-class through the Windows `dotnet.exe` vstest host
+(the old "cannot run headless" claim conflated them with the full-suite WASAPI hang). Two first-launch
+crashes this refactor shipped with were caught on the first real native launch and fixed same day:
+ctor-order `SceneGraph` NRE (`null!` field assigned after first ctor use — now field-initialized) and
+window-scope `EyeButton`/`EyeIconStyle` consumed via `StaticResource` from the extracted `LeftPanel`
+(UserControl namescopes can't see window resources — styles moved to `Themes/Controls.xaml`, the
+app-scope rule honored). The RoundClip "known failure" was then root-caused to stale test code
+(`window.FindName` across namescopes + `VisualTreeHelper.HitTest` where `UIElement.InputHitTest`
+models input) — test green 2026-09-01, the sole remaining known failure is the audio one.
### Design
diff --git a/Themes/Controls.xaml b/Themes/Controls.xaml
index 6db611c..6f35c14 100644
--- a/Themes/Controls.xaml
+++ b/Themes/Controls.xaml
@@ -66,6 +66,29 @@
+
+
+
+
+
+