Adom UI Design System

@@ -1,6 +1,6 @@ {   "slug": "adom-ui-design",-  "version": "2.14.0",+  "version": "2.15.0",   "type": "skill",   "description": "The Adom UI Design System plus a bundle of focused UI skills (tooltips, floating-windows, toasts, responsive-ui, app-shell, ai-driven-apps, clickable-paths, dark-default, input-feedback, settings-layout). One install drops the whole set of skill files onto your container, plus shared icon assets (the settings cog) so every Adom app draws the same glyph.",   "dependencies": {},

@@ -133,6 +133,36 @@ windows were in front of Hydrogen** (Edge, Google Chat, Claude, RustDesk, Gmail) clicks went into whatever was topmost, in John's live foreground work. Nothing in the frame or the arithmetic said so; the only signal was a toast that never appeared. +**COORDINATES ARE NOT THE INPUT. FOCUS IS.** pup's formulation, and it is the correction to+the obvious reading of fusion's bug: the fix is not "compute better coordinates", because+fusion's were right, computed two ways that agreed to the pixel. `desktop_click` dispatches to+**whatever owns the foreground at that instant**, so a correct rect proves nothing at all.++pup learned this on John's actual work (2026-07-29), when an agent typed a username into his+document because he had alt-tabbed away, and then blamed Windows for failing to foreground the+window.++**Use `pup_assisted_click` rather than hand-rolling raise-then-click.** It is the only path+that verifies, waits and narrates. Its guard:++- poll `osGetForegroundWindow()` until it EQUALS the target hwnd+- **and has been stable for 1200ms**, not merely equal for one sample+- up to a 120s cap, returning false rather than dispatching anyway+- captioning "Adom is waiting: click back into THIS window" at most **3 times, then going+  silent**, because an unattended wait can run for hours and a permanent nag is its own+  disturbance++**And the half that caused fusion's bug: the check must run IMMEDIATELY BEFORE EACH native+event, not once per sequence.** Three clicks means three verifications, because focus can move+between event one and event two. A single up-front check followed by three dispatches is+exactly the shape that puts half a password in the wrong window.++**The asymmetry is by design, and it is why the screenshot lied:** `desktop_screenshot_window`+reads through occlusion deliberately, and pup depends on that constantly to capture background+windows without ever stealing focus. So the same property that makes reading safe makes a+screenshot worthless as evidence for a click. **Two capabilities that look like a matched pair+and are not: one reads through occlusion, the other cannot.**+ So, before any `desktop_click` on his machine:  - **Confirm the target window is actually topmost**, not merely present and correctly measured.