Found during the #1560 spike's follow-up lab check (2026-08-03, iPhone 17 Pro / iOS 26.2 sim).
Symptom: gesture pan completes in the same ~100ms drag regardless of the requested duration — 400 / 1200 / 3000 ms all finish in ~400–800ms wall against ~560ms baseline CLI overhead. This corroborates #1542's earlier observation of a ~288ms wall for a 400ms-duration pan.
Localization (verified, not fixed): the runner-side ObjC consumes offsetMs correctly, and RunnerContinuousDragPointerPath builds proper eased 60fps samples — but gesture pan routes through the planned path (apple/runner/.../RunnerTests+Interaction.swift:1117 → synthesizeGesture(withApplication:pointerSamples:)), so the suspect is the daemon-side plan builder's offsetMs spread, not the runner.
Why it matters: drag speed changes what a ScrollView does with a gesture (fast drags fling/rubber-band; slow drags track), so an ignored duration makes pan behavior geometry-sensitive in ways scripts can't control. Related context: the pan-landing behavior is position-dependent (pans starting over editable fields get text-selection semantics — see the #1542 investigation; canary-counter evidence shows synthesis/delivery itself is sound).
Repro: request gesture pan with duration 3000 on any screen; measure wall time (~100ms drag). Fix scope: the daemon-side pointer-sample plan builder's timestamp spread.
Generated by Claude Code
Found during the #1560 spike's follow-up lab check (2026-08-03, iPhone 17 Pro / iOS 26.2 sim).
Symptom:
gesture pancompletes in the same ~100ms drag regardless of the requested duration — 400 / 1200 / 3000 ms all finish in ~400–800ms wall against ~560ms baseline CLI overhead. This corroborates #1542's earlier observation of a ~288ms wall for a 400ms-duration pan.Localization (verified, not fixed): the runner-side ObjC consumes
offsetMscorrectly, andRunnerContinuousDragPointerPathbuilds proper eased 60fps samples — butgesture panroutes through the planned path (apple/runner/.../RunnerTests+Interaction.swift:1117 →synthesizeGesture(withApplication:pointerSamples:)), so the suspect is the daemon-side plan builder'soffsetMsspread, not the runner.Why it matters: drag speed changes what a ScrollView does with a gesture (fast drags fling/rubber-band; slow drags track), so an ignored duration makes pan behavior geometry-sensitive in ways scripts can't control. Related context: the pan-landing behavior is position-dependent (pans starting over editable fields get text-selection semantics — see the #1542 investigation; canary-counter evidence shows synthesis/delivery itself is sound).
Repro: request
gesture panwith duration 3000 on any screen; measure wall time (~100ms drag). Fix scope: the daemon-side pointer-sample plan builder's timestamp spread.Generated by Claude Code