← Commit history

2.12.0 (doc only): a correct screenshot is not evidence a click will land - desktop_click assumes topmost, screenshot_window does not care

John Lauer ·2b8e86d064 ·1mo ago ·parent 5c4deb6
2 files changed +26−1
package.json+1−1
@@ -1,6 +1,6 @@ {   "slug": "adom-ui-design",-  "version": "2.11.0",+  "version": "2.12.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": {},
skills/dash-screenshot/SKILL.md+25
@@ -121,6 +121,31 @@ adom-shotlog inject -c dock-dashboards -d "<what this shows>" --orig-file <full. `--orig-file` matters: shotlog rejects a pre-shrunk image that cannot declare its original resolution, so the viewer never has to show "orig missing". +## ⛔ A CORRECT SCREENSHOT IS NOT EVIDENCE THAT A CLICK WILL LAND++**`desktop_click` takes SCREEN coordinates and assumes your window is topmost there.+`desktop_screenshot_window` captures an OCCLUDED window perfectly happily.** Those two facts+look identical right up until you click someone else's application.++fusion hit this trying to real-click a Copy button in John's dock. Its coordinates were right,+computed two independent ways that agreed to a pixel. Its screenshot looked perfect. **Six+windows were in front of Hydrogen** (Edge, Google Chat, Claude, RustDesk, Gmail), so three+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.++So, before any `desktop_click` on his machine:++- **Confirm the target window is actually topmost**, not merely present and correctly measured.+- **A real click on a busy machine requires foregrounding, which steals focus from live work.**+  That is a disruption to a person, so it needs asking, not assuming.+- **`/ai-cursor/click` cannot substitute.** Its own hint says it does not move the real cursor+  or steal focus, so it cannot answer any question that is specifically about a REAL user+  gesture, such as whether the async clipboard API accepts one.++The general form: **a passive observation succeeding tells you nothing about whether an active+one will.** Reading a window and driving a window have different preconditions, and only one+of them fails loudly.+ ## Traps  - **A shot of an unforegrounded tab looks fine and measures wrong.** Activate first, always.