Task index: a slider that takes no focus on touch, and the ease that came out again (#182, #153)

[Devski]

Summary

Two entries in the task index, no code.

#182, new — reported by Dawid from
the work form on a phone: with the cursor left in a text field, every move of an R360 slider
pulls the page back to that field.

Nothing puts the focus back — it never leaves. Measured in mobile Chromium (Pixel 7, real
touch events) on a page holding a text field, an input[type=range], a <button> and a
div role="slider" tabindex="0", with the field focused first each time:

touched	where the focus ends up
input[type=range], tapped	stays in the text field
input[type=range], dragged	stays in the text field
div role="slider" tabindex="0"	moves to the div
<button>	moves to the button

So the caret stays in the field, the on-screen keyboard stays up, and the browser holds the
caret in view against every re-render the slider causes. Safari on iOS withholds the focus
from buttons and tabbable divs as well, and Dawid works on both platforms — which is why the
issue scopes the fix past the two sliders it was reported on.

#153, corrected — the index still
said the easing shipped and that the owner has a sixth parameter. It came out again hours
later in #177, and #175 closed unmerged.
SPEC A13 was updated then; the index was not, so it has been claiming a function the product
does not have. It now says what stands (the coast), what came out (the eased travel and the
Motion switch), and that a work still carrying the switch in its JSON reads as one without
it.

Test plan

• pnpm check — green, run after the entries were written
• tasks/plan.md is prettier-clean, verified against a copy normalised to LF (the
  working tree on Windows carries CRLF, which prettier flags on the untouched file from
  main too)
• Rebased onto origin/main (65a4492), so the R360 motion that eases: a ring click that speeds up and slows down, a drag that coasts, the owner's switch #153 correction sits on the revert itself

🤖 Generated with Claude Code