feat(tui): stream replies, cancel tasks, and handle input-required

[alDuncanson]

First step toward A2A parity. The TUI sent a message and blocked until the task finished — it never called stream(), cancel_task(), or resubscribe(). Streaming is A2A's headline capability and the agent card advertises it, but Handler's flagship interface showed nothing until a task completed and offered no way to stop one.

The events were already there. A2AService.send() consumed a stream internally and kept only the final event, discarding every TaskStatusUpdateEvent and TaskArtifactUpdateEvent on the way past.

A turn layer, not a bigger _send_message

_send_message was ~90 lines mixing widget access, credential syncing, protocol retry logic, state mutation, session persistence, and rendering. Adding streaming there would have made it worse.

Instead this adds a2a_handler.turn: one user message and the agent's streamed reply, as AgentTurn yielding TurnEvents and ending in a TurnResult. It owns the protocol semantics of an exchange — when a turn is over, which task a follow-up continues, what to do when a server refuses a stale task — with no dependency on any user interface.

That matters for what's next: the CLI and MCP bridge can adopt the same rules instead of reimplementing them, and the rules stay in one tested place. The stale-task retry moved here out of the widget, where it had been tangled up with rendering. 25 of the 35 new tests are plain async tests with no Textual involved.

INPUT_REQUIRED — a correctness bug, not a missing feature

Nothing in Handler referenced this state. It isn't terminal, so a turn that waits for a terminal state waits forever: an agent that paused to ask a question left the client hanging with the input disabled.

Turns now settle on the interrupted states as well as the terminal ones. The input is released with a prompt explaining the agent is waiting, and the open task is kept so the reply continues it rather than starting a new thread. AUTH_REQUIRED settles the same way and points at the Auth tab.

Cancel

A STOP control appears while a turn is in flight, sends a real CancelTask, and releases the input. If the agent can't cancel, that's said plainly rather than left ambiguous. Turns also stop consuming after a cancel request, so an agent that keeps streaming can't hold the UI.

Rendering

Replies stream into a transient StreamingMessage that is replaced by a normal AgentMessage once the turn settles, so a finished transcript looks the same whether or not the reply arrived incrementally.

Verification

450 tests pass (35 new), plus ruff, ruff format, and ty.

The earlier round of this work could only be checked against an agent advertising streaming: false, so the streaming path was covered by tests alone. That gap is now closed with a deterministic streaming agent (kept outside this repo — it needs google-adk, which v0.2.0 deliberately removed). Against it:

Checked	Result
CLI message stream	8 events, 4 distinct progress updates arriving separately
TUI streaming	Drove the real TUI headlessly; 4 distinct live updates observed as they arrived, final message rendered, transient widget removed, task ID cleared
Cancel	Input released 0.29s after STOP — and the server reports canceled when queried afterward, so it's a real protocol cancel, not a client-side abandon
Failure path	Streams a working update, then settles at TASK_STATE_FAILED with the reason attached
CLI message send	Unchanged

Worth knowing for anyone testing this: ADK's AgentCardBuilder defaults to a bare AgentCapabilities(), leaving streaming false. That's why most ADK agents won't exercise this path — the card has to set it explicitly.

Coverage

TUI method coverage goes 2/11 → 4/11 (SendStreamingMessage and CancelTask). SubscribeToTask is still unwired in the TUI.

Not in this PR

Sending non-text parts, ListTasks, the two missing push-notification config methods, GetExtendedAgentCard, transport negotiation, and the remaining auth schemes.

🤖 Generated with Claude Code