feat(compose): hand outgoing mail to the send command, item 123

MessageSender runs the configured command with the message on stdin and
judges the result by its exit status alone. Nothing here waits on the
event loop, so a send does not block the GUI thread; a 1.6MB payload was
probed through a reading stub without deadlocking the pipe buffer.

The command is split and passed to QProcess as a program and an argument
list, never through a shell. A test asserts that by giving the command
shell metacharacters and checking that the marker file a shell would have
created does not exist, so the property fails a mutation rather than
resting on a comment.

Four corrections to the plan's draft. splitCommand handles double quotes
only, so a single-quoted argument splits wrongly and the header now says
so. A crashing command delivers finished(11, CrashExit) and would have
been reported as "exited with status 11", so a crash branch was added. A
command that exits without draining a large stdin emits WriteError before
finished(), which the draft handled correctly and by luck, untested. And
an empty send_command is checked after trimming.

Two contract gaps found in review, both about what this class promises
rather than what it does.

The exactly-once guarantee covers the EMIT, not what a caller receives: a
long-lived sender plus a connect() inside each send accumulates
receivers, and the second result then runs the first send's lambda too,
filing a sent copy of the wrong message. The header now scopes the
promise and requires Qt::SingleShotConnection. The plan's Task 11 call
site already had that flag, sixty-nine lines below the connect and
outside anything a reader would see, so the plan gained a note where
someone retyping it will read it.

And destruction mid-send killed the command with no report, announced
only by a Qt warning: a live SMTP conversation abandoned, possibly
partially delivered, while the user believes it was cancelled. The
destructor now closes stdin, waits a bounded five seconds, and only then
kills. It emits nothing either way, because the outcome after a kill is
genuinely unknown and reporting "not sent" for a message that may have
gone out is the mailsync.sh mistake pointing the other way. Claiming
m_reported before kill() is what makes that true, since kill() delivers
finished(CrashExit), which would otherwise emit exactly that untruth.

No timeout on the send itself: killing a slow but working send is worse
than waiting. Task 10 owns the popup, and deliberately offers no cancel
after commit, so this class promises none either.

Also refreshes the translations Task 5 left out. That gap was invisible
because test_translations builds its rows from the .ts file, so a string
that never entered it is never asserted on.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QP2g3b3kuLx6AYFCNEz6UR

1 files changed, 28 insertions, 0 deletions

diff --git a/docs/superpowers/plans/2026-08-20-compose-and-send.md b/docs/superpowers/plans/2026-08-20-compose-and-send.md
index e7eddfa..7d5f6f1 100644
--- a/docs/superpowers/plans/2026-08-20-compose-and-send.md
+++ b/docs/superpowers/plans/2026-08-20-compose-and-send.md
@@ -4008,6 +4008,20 @@ private:
 `src/composewindow.cpp`. The full file is long; these are the parts that carry
 decisions, and the rest is ordinary widget assembly.
 
+**One thing in this block is load-bearing and easy to drop while retyping it:
+the `Qt::SingleShotConnection` on the `MessageSender::finished` connect inside
+the `committed` handler.** `m_sender` is a long-lived member, so a plain
+`connect()` beside a `send()` call leaks a receiver per send and the second
+result runs every earlier lambda, each still holding an earlier message's bytes
+by value: a sent copy of the wrong message, and `accept()` on a destroyed
+dialog. `MessageSender`'s own once-only guard cannot help, because that guards
+the emit and this is one emit reaching many receivers. The header for
+`MessageSender::finished` states the rule and
+`test_messagesender.cpp::aPerSendConnectionMustBeSingleShot` measures it (3
+deliveries for 2 sends without the flag, 2 with it). Noted here because the
+plan's code blocks are drafts and this is the line whose absence still
+compiles, still runs, and is wrong only on the second send.
+
 ```cpp
 #include "composewindow.h"
 
@@ -4169,6 +4183,20 @@ void ComposeWindow::send()
     connect(dialog, &SendDialog::committed, this, [this, dialog, built, account]() {
         m_sender->send(account.sendCommand, built.bytes);
 
+        // Qt::SingleShotConnection IS REQUIRED HERE, and this line is the
+        // correction of a defect that was in this plan's draft (found while
+        // building Task 6, 2026-08-21). m_sender is a long-lived member, so a
+        // bare connect() beside each send() accumulates a permanent receiver
+        // per send. Send, fail, correct the recipient, send again, and the
+        // second result runs BOTH lambdas: the first still holds the FIRST
+        // message's `built` and `account` by value, so it files a sent copy of
+        // the wrong message and calls accept() on a dialog it already
+        // deleteLater()'d. MessageSender's m_reported guard cannot prevent
+        // this: it collapses two QProcess signals into one emit, and this is
+        // one emit reaching many receivers. Measured in
+        // test_messagesender.cpp::aPerSendConnectionMustBeSingleShot, where
+        // the bare shape delivers 3 results for 2 sends and the single-shot
+        // shape delivers 2.
         connect(m_sender, &MessageSender::finished, this,
                 [this, dialog, built, account](bool sent, const QString &error) {
             if (!sent) {