gestureNoEffect warning is unreachable on hostile-capture screens (the ones it targets)

[thymikee]

Summary

The gestureNoEffect warning added by #1600 appears unreachable on hostile-capture screens — which is the screen class it was built for. #1600's motivating case was element-18 burning ~40 tool calls re-issuing scrolls on a Bluesky feed, and a Bluesky feed is hostile enough to capture that #1601's corroboration gate can never be satisfied.

Found while gathering live evidence for #1615. Not caused by that PR — it changes nothing about when the warning fires.

Reproduction

CLI + daemon built from source, isolated --state-dir, explicit --platform ios --udid throughout, seeded Bluesky fixture simulator.

$ agent-device scroll top
Already at top; no hidden content above detected

$ agent-device swipe 200 250 200 650      # drag down, nothing above → cannot move
Flung

$ agent-device snapshot
Warning: ios snapshots are slow in this run: p95 13442ms over 2 captures
Snapshot: 167 visible nodes (171 total) (truncated)
Detected an overly complex or slow accessibility tree. Fell back to the private-ax snapshot backend.
Some deeper accessibility nodes were omitted; this tree is capped at depth 56.

No gestureNoEffect warning. Five no-effect gestures across two screens (Settings ×3, Bluesky ×2) all silent.

Mechanism

Two independent vetoes, each correct in isolation:

1. Backend flip. Post-gesture stale-accept saturates routinely on the checkout screen; wall-clock retry budget starves under contention into stale-geometry interactions #1569 established that a quiet capture from a different snapshot backend can only be re-baselined against, never concluded from — backends disagree about which nodes exist. A hostile screen falls back tree→private-ax mid-sequence, so the loop never reaches a comparable pair.
2. Truncation drift. fix(daemon): surface proven no-effect gestures to the agent #1601 requires haveIdenticalDiscriminatingSurfaces — discriminating entry sets matching exactly in both directions. A depth-56-capped, truncated 167-node tree will not match its baseline set even when nothing moved.

Both are working as specified. The composite is that the safe failure mode (silence) is the only outcome exactly where the feature is needed.

Why it matters

This is the same shape as #1609: a guard that cannot fire in the conditions it targets. The agent-facing cost is what #1600 measured — an agent re-issuing a gesture the daemon has already proven inert, because the proof cannot be corroborated.

Not yet isolated

I did not determine which veto dominates, or whether either alone is sufficient. That needs per-capture backend identity and the two signature sets, not the rendered warning. Suggested next step: log the corroboration inputs (baseline backend, capture backend, discriminating set sizes, symmetric difference) at debug level on the accept-stale path, then re-run the repro above and read which condition fails.

Possible directions, none validated:

• allow corroboration across a backend flip when both captures are themselves internally quiet;
• compare only the intersection of node identities present in both captures when one is known-truncated, rather than requiring set equality;
• accept the bare accept-stale verdict when the capture is flagged truncated, on the grounds that a truncated pair cannot produce the false-positive fix(daemon): surface proven no-effect gestures to the agent #1601 was guarding against.

[thymikee]

Correction: the first of the two candidate vetoes is not a defect — it is the feature.

I filed this after observing that the no-effect warning never fires on a Bluesky feed, and named two candidates: (1) a backend flip breaking corroboration, (2) truncation drift. I then opened #1622 to "fix" (1). That PR is closed; the premise was wrong.

post-gesture-stability.ts corroborates against the original pre-gesture baseline rather than the loop's mid-poll rebased one, and #1633 documents this as deliberate: "so a backend flip can never launder a cross-backend pair into a no-effect claim." That is right. The rebase assigns baselineSignature = current.signature, and current is a post-gesture capture — so corroborating against it would compare two post-gesture captures, proving only that the screen went quiet, never that the gesture did nothing.

So a backend flip should suppress the claim: comparability with the before-state is gone, and silence is the correct output.

What that leaves. Part of the observed unreachability is simply correct behaviour, not a bug:

• On a fully-hostile screen the tree strategy fails before the first capture, so every capture including the pre-gesture baseline is private-ax. There is then no flip at all — and no defect in that path.
• The remaining open question is narrower than filed: does an untruncated, single-strategy screen with a genuinely inert gesture produce the warning? If yes, this issue is only about hostile screens where suppression is correct, and the honest fix is documentation plus possibly a different signal for "cannot judge" versus "judged inert". If no, truncation drift is a real second veto and worth its own fix.

Also unresolved, and a prerequisite for measuring either way: no post_gesture_* diagnostic appears in the session request logs for a swipe — not the rebase, not the settle, not the stabilization timeout. Without a readable verdict there is nothing to measure against, so making the verdict observable on the gesture path is the first real step, ahead of any fix.

Retitling scope accordingly in my head: this is now "is the no-effect claim reachable on any real screen, and is its silence distinguishable from its absence", not "corroboration reads the wrong baseline".

🤖 Addressed by Claude Code

[thymikee]

Carrying over the live-evidence condition from #1615, so it does not evaporate when that merges.

#1615 was held on: an exact-head no-effect swipe warning retaining its coordinates, followed by a successful command proving the session remains usable. That condition is sound, but it belongs here rather than on a mechanical refactor — the capture validates this warning machinery, not #1615's delta, and it is currently unobtainable for a reason tracked in this issue.

Outstanding here, in the order they need doing:

1. Make the stabilization verdict observable on the gesture path. No post_gesture_* diagnostic — not the rebase, not the settle, not the stabilization timeout — appears in the session request logs for a swipe. Until one does, there is nothing to read a verdict from, and any "live evidence" is inference. This is the prerequisite for everything below and looks like a small PR.
2. Then answer, with data instead of vetoes: does an untruncated, single-strategy screen with a genuinely inert gesture produce the warning? If yes, the remaining unreachability is on hostile screens where suppression is correct (see the correction above), and the fix is documentation plus possibly distinguishing "cannot judge" from "judged inert". If no, depth-56 truncation drift is a real second veto.
3. Then the refactor(daemon): consolidate post-gesture surface-evidence helpers and their rationale #1615 capture itself, which becomes possible once (1) exists.

Taking (1) next.

🤖 Addressed by Claude Code

[thymikee]

Measured both outstanding items live. Item (2) answers yes — on the hostile screen, not merely an easy one — and item (1)'s premise is a lookup-location error, not a missing diagnostic.

Seeded Bluesky fixture (ad-bsky-repro, Bluesky 1.122.0), CLI + daemon built from current main, isolated --state-dir, explicit --platform ios --udid. Every capture in the run reported 167 visible nodes (171 total) (truncated), private-ax fallback, depth-56 cap — the exact screen this issue was filed against.

The warning fires

gesture	reality	outcome
scroll up at feed top (×2)	inert	stale-accept → corroborated → warning fired, 2/2
scroll down, coordinate swipe	moved the feed	stabilized, no claim, 2/2

scroll up produced no visible change: the tree still matches its pre-gesture state.
Either the container is already at its edge, or it ignores synthesized scrolls —
a raw drag moves such lists: swipe x1 y1 x2 y2 (start inside the list).

So the answer to "does a genuinely inert gesture produce the warning?" is yes, on a truncated, single-strategy, fully-hostile screen — a strictly stronger result than the untruncated case the issue asked for. The title's "unreachable on hostile-capture screens" is measurably false as it stands.

Item (1): the diagnostics already exist — they are on the next request

No post_gesture_* diagnostic — not the rebase, not the settle, not the stabilization timeout — appears in the session request logs for a swipe.

That is true of the swipe's own request log and always will be, because nothing observable happens there. markDeferredInteractionOutcome only records intent on the gesture request; capturePostGestureStabilizedResult — the sole emitter of every post_gesture_* event — runs inside the capture that follows. Parsing every request in the run, without exception:

req.command=snapshot  post_gesture_snapshot_stabilized     action='swipe'   {attempts: 2, durationMs: 20870}
req.command=snapshot  post_gesture_snapshot_stale_accept   action='scroll'  {attempts: 2, durationMs: 17905, matchedPreGestureBaseline: True}
req.command=snapshot  post_gesture_snapshot_stabilized     action='scroll'  {attempts: 2, durationMs: 21373}
...

A swipe verdict is right there, carrying action='swipe', on a request whose command is snapshot. The planned "small PR" for item (1) is unnecessary as scoped — the verdict is already observable; you have to read the following capture's ndjson, not the gesture's.

One caveat worth knowing, because it produces exactly the symptom that motivated item (1): two of my early gesture→capture pairs emitted no post_gesture_* events at all, and both captures carried ios_runner_session_invalidated. Hostile captures keep the daemon busy past the CLI response, so an immediately-following command times out connecting and takes over — fresh daemon and runner, stabilization state gone. I accumulated 18 stray daemons before noticing. I can't prove it retroactively, but a takeover is the most likely explanation of the original "no diagnostic for a swipe" observation, and it will corrupt any future measurement run the same way. ~15s between commands avoids it; daemon_startup in the client's --debug stream is the tell.

Truncation drift does not reproduce

The remaining candidate veto is disproven with numbers rather than vetoed by inference. The one suppression I did reproduce:

post_gesture_no_effect_vetoed  action=scroll  reason=surface_divergence  backend=private-ax
   onlyInBaseline: 0   onlyInCurrent: 0   rectMismatched: 4   shared: 158

onlyInBaseline: 0, onlyInCurrent: 0 across 158 discriminating entries: under the remembered depth-56 cap, set membership is exactly stable between captures. Depth truncation is deterministic here, so it cannot break set equality. The four divergences were rects, and that sample had a deliberately unrealistic 105s gap between gesture and capture — i.e. ambient feed motion, a third mechanism this issue never listed and the only one I could make produce silence on an inert gesture. At agent cadence it does not fire.

What is actually still missing

Not the verdict — the reason. A withheld claim is byte-identical to a gesture that simply worked: the response just has no warning. That ambiguity is why this issue needed a live re-run to resolve at all, and it will recur for the next person. I have that on a branch (post_gesture_no_effect_vetoed with reason: baseline_rebased | surface_divergence plus the divergence counts above, which is how I produced the numbers in this comment; also fixes marking storing a truthy baselineSignature: [] that then gets rebased). Happy to open it if useful — it is small and additive, and it is the only part of my original branch that survived contact with this evidence.

Not covered

The #1615 carry-over condition — an inert swipe warning retaining its coordinates, followed by a successful command proving the session stays usable — is not captured here. My inert cases were scroll up; my swipe samples were successful drags. It is now a ~10-minute task given the warning demonstrably fires, provided the cadence trap above is respected.

Suggest retitling (the current title asserts something now measured false) and closing once the veto-reason instrument lands, with truncation drift recorded as investigated-and-absent rather than open.