Describe the bug
Two issues with message send state management in the TUI:
1. Queue vs steer differentiation broken
The TUI does not properly distinguish between messages that are queued (waiting to be sent) and messages that are steering (being actively processed as a user interrupt). These are different states but the UI treats them the same.
2. Sent messages stay in QUEUED state
After a message has been successfully sent and acknowledged by the server, it continues to display as "QUEUED" in the TUI status. This is misleading — once sent, the state should transition to something like "SENT" or "PROCESSING".
Where to look
crates/tui/src/chatwidget.rs — queued user messages and status renderingcrates/tui/src/events.rs:173 — input queue state eventcrates/protocol/src/acp_client_io.rs — client I/O event flow- Server-side turn state tracking
Expected behavior
- Queued (pending) and steering (in-progress interrupt) should be distinct states with different visual indicators
- Once the server acknowledges a message, its state should update from QUEUED to SENT or PROCESSING
Describe the bug
Two issues with message send state management in the TUI:
1. Queue vs steer differentiation broken
The TUI does not properly distinguish between messages that are queued (waiting to be sent) and messages that are steering (being actively processed as a user interrupt). These are different states but the UI treats them the same.
2. Sent messages stay in QUEUED state
After a message has been successfully sent and acknowledged by the server, it continues to display as "QUEUED" in the TUI status. This is misleading — once sent, the state should transition to something like "SENT" or "PROCESSING".
Where to look
crates/tui/src/chatwidget.rs— queued user messages and status renderingcrates/tui/src/events.rs:173— input queue state eventcrates/protocol/src/acp_client_io.rs— client I/O event flowExpected behavior