feat(chat): steer the first queued message on enter with an empty composer - #3
Merged
Merged
Conversation
…poser While a session is running, pressing the send shortcut with nothing in the composer now steers the first queued message instead of no-oping, restoring the double-enter flow (enter queues, enter again steers). Draft content keeps the shortcut on the draft so it can never discard or bypass what the user is composing, and an in-progress queue edit keeps the shortcut inert. Codified in LAWS/CHAT.md.
…ible Steering acts on the true queue head, but the steer button and the empty-composer shortcut were gated on the visible pill list. Hidden records (reliable startup handoffs) cannot coexist with an active run today, so this is a tripwire: if a future longer-lived hidden record ever heads the queue, steering goes inert instead of steering a message the user cannot see.
The steer-queued shortcut guard omitted attachmentWorkPending, so Enter pressed while a pasted or dropped attachment was still being inspected or resized could steer the queued head before the attachment landed as draft content. Mirror the send and current-steer gates. Test holds the image resize open to pin the in-flight window.
morgmart
force-pushed
the
morganm/steer-queued-on-enter
branch
from
August 12, 2026 23:38
96a32d8 to
d61c519
Compare
morgmart
added a commit
that referenced
this pull request
Aug 14, 2026
## Summary - restore the double-enter flow: while an agent is working, a send shortcut with an empty composer steers the first visible queued message - keep steering inert for drafts, queued edits, hidden queue heads, idle sessions, disabled sends, and in-flight attachment admission - restore the durable chat laws and regression coverage that were missed during the OSS repository migration ## Context This completes the behavior from #3, which was merged into the temporary `kalvin/initial-oss-port` branch instead of `main`. Most supporting guards later reached `main` through #7; the ordinary `chat.sendMessage` route, laws, and focused tests did not. ## Testing - `pnpm vitest run src/features/chat/ui/__tests__/ChatInput.test.tsx src/features/chat/ui/__tests__/ChatInput.attachments.test.tsx` — 158 passed - `just check` - `pnpm typecheck` - `pnpm test` — 531 files, 6,205 passed, 1 skipped - pre-push `fmt-check`, `check`, `tauri-check`, and `clippy`
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Category: improvement
User Impact: While the agent is working, pressing Enter with an empty composer now steers your queued message immediately — restoring the double-enter flow (Enter queues, Enter again steers).
Problem: Steering a queued message required reaching for the pill's Steer button. Users naturally try double-enter — type a follow-up, Enter to queue, Enter again to push it through — but the second Enter was a dead key (community request). The original double-enter behavior was removed because steering composer text past a queued message would send messages out of order.
Solution: Instead of bringing back out-of-order steering, the send shortcut with an empty composer now steers the first queued message. Any draft content (text, attachments, or skills) keeps the shortcut on the draft so nothing the user is composing can ever be discarded or bypassed, and an in-progress queue edit keeps the shortcut inert. The behavior is codified in
LAWS/CHAT.md, and both the shortcut and the pill's Steer button are additionally gated so they only offer steering when the true queue head is the message the user can see — a tripwire against any future hidden queue records.File changes
LAWS/CHAT.md
Two new Steering laws: a send shortcut with an empty composer may steer the first queued message while the session is running, and it must not do so while the composer holds draft content or a queued message is being edited.
src/features/chat/ui/ChatInput.tsx
In both send shortcut handlers (plain Enter and Cmd+Enter modes), an empty composer while streaming now steers the first queued message via the existing steer-queued path instead of no-oping. Adds a visible-head guard shared by the shortcut and the pill's Steer button so steering is only offered when the true queue head is user-visible.
src/features/chat/ui/tests/ChatInput.test.tsx
Tests for the new behavior: steer on Enter/Cmd+Enter with an empty composer, inert with draft content, inert when idle, inert during a queue edit, and inert when a hidden record heads the queue. Removes the test that pinned the old empty-composer no-op, which the law change intentionally reverses.
Port note: This ports squareup/berd#1190 (already reviewed, approved, and merged internally) onto the OSS import branch. It stacks on #2 and includes the review hardening from the internal PR: the visible-head tripwire and the
attachmentWorkPendinglock flagged by code review.