"…" before dropped follow-ups; Enter in Claude puts a phone's keyboard away

[andrin-n-dream]

The task strip puts "…" in front when older follow-ups were dropped

Only the newest three follow-ups travel, and the strip could not tell that
there had been more: "three, four, five" looked like the whole story. The
reader now says so -- earlierFollowUps -- and the strip opens the line with
an ellipsis that has no arrow, since it is not something said.

Carried across incremental reads, because a read holding only Claude's reply
has nothing to work it out from again; and written as false by every fold,
because the incremental read spreads a fold over what it had and a key left
out kept the old true after a new task. The tests fail with either broken.

---

On a phone, Enter in Claude puts the keyboard away; in a terminal it does not

Enter in Claude sends the prompt, and what comes next is reading the answer
-- with the soft keyboard covering half the screen, which you then had to
dismiss by hand every time. So on a touch screen (pointer: coarse, the test
softKeys already uses), a lone Enter into a Claude session blurs the
terminal after sending; tap the window to type again. A shell keeps its
keyboard, because Enter there runs one command of several, and a paste ending
in a newline is not a press of Enter.

Measured in a touch-screen context at 390px on a scratch instance: a letter
typed into Claude kept the focus, Enter dropped it to the body, and Enter in
the same worktree's terminal kept it -- and tmux capture-pane shows both
Enters arrived, the stand-in on a new line and the shell at a fresh prompt.

---

🤖 Generated with Claude Code