[gjkim42]

What type of PR is this?

/kind feature

What this PR does / why we need it:

Improves the single pending Session message in three ways:

• Preserves line breaks in the web pending-message card, so combined follow-up submissions remain readable.
• Adds Remove beside Edit in the web client.
• Lets terminal UI users press Up on an empty composer to recall and edit the pending message. Submitting the recalled message empty removes it, without adding a slash command.

Edits and removals use the pending message revision to reject stale requests. Removal is persisted as a dedicated event, frees the pending slot immediately, prevents the buffered turn from reaching the provider, and remains removed after runtime recovery.

Which issue(s) this PR is related to:

N/A

Special notes for your reviewer:

The removal path covers both a turn still buffered in the runtime channel and the race where the dispatcher has received the turn but has not started it. Removed messages are omitted from conversation history.

Validated with make test and make verify.

Does this PR introduce a user-facing change?

Display combined pending Session messages on multiple lines and allow them to be edited or removed before they start.

[cubic-dev-ai]

All reported issues were addressed across 2 files

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[gjkim42]

/kelos claude-review

[kelos-bot]

🤖 Kelos Task Status

Task kelos-claude-reviewer-issue-comment-45718b9f3a31 has succeeded. ✅

[kelos-bot]

🤖 Kelos Claude Reviewer Agent @gjkim42

Review Summary

Verdict: APPROVE
Overall correctness: patch is correct
Scope: Renders the pending Session message on multiple lines in the web client, adds a Remove action (web) and Up-arrow recall/edit/remove (terminal UI), backed by a new user.message.removed journal event with revision-checked removal that survives runtime recovery.

Findings Overview

Priority	Count	File:Line	Summary
P0	0	—	none
P1	0	—	none
P2	0	—	none
P3	1	internal/sessionserver/server_test.go:619	Test asserts the exact full CSS rule string, brittle to unrelated property edits

Findings

Tests

• [P3] internal/sessionserver/server_test.go:619 — TestSessionPendingMessagePreservesLineBreaks matches the entire .pending-message-text rule verbatim, so any unrelated edit to that rule (a color or font-size tweak, property reordering) fails the test even while multiline rendering still works. Asserting the behavior-relevant fragments — that the rule contains white-space: pre-wrap and overflow-wrap: anywhere — would pin the fix without over-constraining the rest of the rule, consistent with the targeted-fragment style of neighboring tests in this file.

Suggestions (optional)

• [P3] internal/cli/session_terminal_tui.go:577 — Once a pending message is recalled with Up, there is no way to leave edit mode without submitting: submitting the text unchanged works but bumps the revision, and clearing the composer and pressing Enter removes the message — the opposite of normal mode, where an empty submit is a no-op. Because edit-path submissions are not appended to m.history, an accidental removal loses the text irrecoverably (the web client guards this with a window.confirm dialog; the TUI has no equivalent). Consider letting Esc cancel a pending edit while one is active, or appending the removed text to input history as a recovery path.

Key takeaways

• The dispatch race is handled correctly: takePendingTurn now reports whether the turn was still pending, so a turn removed after the dispatcher received it from the channel is skipped instead of run (internal/sessionruntime/server.go:426), and TestServerDoesNotRunPendingMessageRemovedAfterDispatch pins this. removePendingMessage mirrors finishTurn's outstanding/drain-report accounting under submitMu, so idle-drain and update reporting stay consistent when the pending slot is freed.
• Removal is durable: recoverJournal treats user.message.removed as turn completion, the journal drops the turn from its unstarted-turn retention, and projectHistory marks the turn hidden — so a removed message neither resurrects after a runtime restart nor reappears in replayed history.
• Revision checking is sound end to end: the server rejects stale or non-positive expectedRevision, the web client normalizes revision || 1 on every pending event, and the TUI normalizes with max(1, revision), so removal of a never-edited message (revision-0 journals included) works from both clients.

[gjkim42]

/kelos claude-review