Real native validation for pixel-snapshot coordinate authority (#8, #68) found that a point click from an unused snapshot, after a verified move of its exact window, returns signed unknown even though the native service rejects it before input.
Observed
Signed Ace-dev build of codex/pixel-snapshot-authority at 769438a, disposable AppKit pointer fixture:
- Inspect the exact window and keep its unused snapshot.
- Move the window with
desktop_move (completed, verified geometry).
- Call
desktop_click with a normalized point from that snapshot.
The result has outcome: unknown and native outcome indeterminate / may_have_dispatched / completion_unknown / retry_safety: unsafe. The message is Snapshot is stale: Exact-window click identity changed before final dispatch; capture a fresh snapshot. The fixture recorded no pointer events and no button activation. Fresh inventory showed the same window and process generation at the moved bounds.
This reproduces identically with a pixels snapshot and with an Accessibility snapshot (separate fresh fixture, one attempt each, never repeated). It is not caused by pixel authority.
Cause (source)
In Peekaboo 4.8.0 plus Ace's patch stack, ClickService.executeClick prepares clicks with requireCurrentTarget(..., validateExactWindow: false), so preparation checks only the process generation. A coordinate click then resolves no Accessibility element: performActionClick throws ActionInputError.unsupported(.missingElement) before its own target check, and the action-first executor falls back to the synthesis route. The first exact-window check runs in that route, in performClick, as requireCurrentTarget(afterDispatch: false). It throws an untyped PeekabooError.snapshotStale. The bridge's canonical mutation-failure mapping treats an untyped error from a mutating operation after execution starts as executionMayHaveStarted, so it reports indeterminate / may_have_dispatched.
The route-level check cannot simply be typed as a refusal. A route can follow an earlier Accessibility attempt that may have dispatched: for example, a right-click AXShowMenu failure classified as targetUnavailable becomes fallback-eligible unsupported, and performClick's check then runs after possible input. (The original description attributed the failing check to performActionClick before tryClick; that is not the path for coordinate clicks.)
Expected
Keep unknown whenever input may have been dispatched. Where the native service proves that rejection happened before any input unit, return a typed pre-dispatch refusal with its evidence and receipt. Do not classify by error text, and do not weaken exact-window checks. #69 made the same kind of narrow typed correction for literal insertion. Verify with a real moved-window click that the receiver stays unchanged and the result is refused.
Tracked by #8 / #68; dogfooding #5.
Real native validation for pixel-snapshot coordinate authority (#8, #68) found that a point click from an unused snapshot, after a verified move of its exact window, returns signed
unknowneven though the native service rejects it before input.Observed
Signed Ace-dev build of
codex/pixel-snapshot-authorityat769438a, disposable AppKit pointer fixture:desktop_move(completed, verified geometry).desktop_clickwith a normalized point from that snapshot.The result has
outcome: unknownand native outcomeindeterminate/may_have_dispatched/completion_unknown/retry_safety: unsafe. The message isSnapshot is stale: Exact-window click identity changed before final dispatch; capture a fresh snapshot.The fixture recorded no pointer events and no button activation. Fresh inventory showed the same window and process generation at the moved bounds.This reproduces identically with a pixels snapshot and with an Accessibility snapshot (separate fresh fixture, one attempt each, never repeated). It is not caused by pixel authority.
Cause (source)
In Peekaboo 4.8.0 plus Ace's patch stack,
ClickService.executeClickprepares clicks withrequireCurrentTarget(..., validateExactWindow: false), so preparation checks only the process generation. A coordinate click then resolves no Accessibility element:performActionClickthrowsActionInputError.unsupported(.missingElement)before its own target check, and the action-first executor falls back to the synthesis route. The first exact-window check runs in that route, inperformClick, asrequireCurrentTarget(afterDispatch: false). It throws an untypedPeekabooError.snapshotStale. The bridge's canonical mutation-failure mapping treats an untyped error from a mutating operation after execution starts asexecutionMayHaveStarted, so it reportsindeterminate/may_have_dispatched.The route-level check cannot simply be typed as a refusal. A route can follow an earlier Accessibility attempt that may have dispatched: for example, a right-click
AXShowMenufailure classified astargetUnavailablebecomes fallback-eligibleunsupported, andperformClick's check then runs after possible input. (The original description attributed the failing check toperformActionClickbeforetryClick; that is not the path for coordinate clicks.)Expected
Keep
unknownwhenever input may have been dispatched. Where the native service proves that rejection happened before any input unit, return a typed pre-dispatch refusal with its evidence and receipt. Do not classify by error text, and do not weaken exact-window checks. #69 made the same kind of narrow typed correction for literal insertion. Verify with a real moved-window click that the receiver stays unchanged and the result isrefused.Tracked by #8 / #68; dogfooding #5.