The task a worktree was given sits above Claude, and what followed it under it

[andrin-n-dream]

The window's bar showed the newest prompt, and after any piece of work the
newest prompt is "merge and deploy" or "yes" -- what the worktree was told
last, not what it is for. Now the newest prompt that set a task gets up to
three lines above Claude, and the prompts since it follow beneath as
"→ yes → merge and deploy", on one line while they fit and wrapping after.

Telling the two apart is length, with no model call. Measured over every
transcript on this machine -- 63 sessions, 1,151 prompts: the short end is
nearly all steering (merge and deploy, continue, and as often mege and
Metge and deploy, which is why a word list would do worse than a count).
Ten words or more is a task, unless it is a question under twenty. The
misses sit at 8-12 words, where either reading is fair. Runs of follow-ups
between tasks are short (none 318 times, one 155, two 61), so six are kept.
With no task in reach, the first prompt stands in for one.

The incremental transcript read used to re-read a 64KB overlap to catch a
record straddling the boundary. Harmless for one newest prompt, a duplicate
in every list once it keeps several; it now stops at the last newline and
starts there next time, so a half-written line is read whole once. Checked by
putting the overlap back: the straddling test fails.

The strip hides while the soft keys are up, by the same :has(.keybar) the
top bar uses. An older linked machine sends only prompt, which is then
shown as the task.

Verified on a scratch instance with stand-in transcripts: the strip renders
above vim with its status line intact, a long task clamps at three lines, an
appended follow-up appears on the next poll, six follow-ups wrap to three
rows at 390px with no horizontal overflow, and an injected .keybar hides
every strip.

🤖 Generated with Claude Code