[captcrock]

What

A pointer action and a screenshot aimed the ring at their display, but a ui_action did not. So in full control, a client acting on an element on another display left the ring on the primary display. After a ui_action whose reply carries the element's frame (TD-5227), the ring is now aimed at the display under the element's centre, as for a click. _aim_overlay becomes aim_overlay so ui.py can use it.

The backlog also records the live checks run against a packaged build of b383be36:

• TD-5226: the ring followed captures and a move across four displays; it never appeared in screenshots; dark in background mode and on Stop.
• TD-5227: two TST Desk sessions (blue, green) and a third client each drew a cursor at the key they pressed; the pointer stayed still. agent-desktop's cursor appeared in a macOS screenshot but not in TST Desk's capture of the same rect. The stop shortcut, the stop-file and the title-bar Stop message each cleared everything.
• TD-5228: the signed-build criterion is ticked. The packaged-daemon run of the four tools stays open.

Stories that are complete are marked Done.

Tests

• test_frame_center_with_a_click now checks the target display with two displays; it fails without the change.
• tst-cu-mcp on macOS: 664 passed, plus the 3 failures main already has (DarwinBackend.hit_test). mypy: the same 4 errors as main.
• Live (source sidecar, full control): a ui_action on Calculator on the left display lit that display's ring.

🤖 Generated with Claude Code

https://claude.ai/code/session_01HUthoCdmzg2hy89ssk2cSF