From cc551a4ed348e663601f2fb8e06b59c07a09ead4 Mon Sep 17 00:00:00 2001 From: "Danilo M." Date: Fri, 28 Aug 2026 11:56:56 +0200 Subject: docs: state why the thread reply is reply-all Replying to the sender alone in a multi-person thread drops everyone else from a conversation they are part of, while reading as a reply to it. --- .../superpowers/specs/2026-08-28-thread-row-identity-design.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/docs/superpowers/specs/2026-08-28-thread-row-identity-design.md b/docs/superpowers/specs/2026-08-28-thread-row-identity-design.md index 13a27a3..c464de0 100644 --- a/docs/superpowers/specs/2026-08-28-thread-row-identity-design.md +++ b/docs/superpowers/specs/2026-08-28-thread-row-identity-design.md @@ -139,10 +139,12 @@ one action replaces Reply, **Reply to this thread**: - It quotes NOTHING. "We just add an answer to the thread." - It is `Kind::ReplyAll` with `quote == false`, which `composeReply()` already supports (the existing `reply_no_quote` action uses the same path), so no new - compose machinery is needed. Reply-all rather than reply-to-sender because a - conversation is multi-party by definition; answering one participant of a - four-person discussion is the unusual case, and it stays available on an - individual message. + compose machinery is needed. Reply-all rather than reply-to-sender, and the + user's reasoning is what settles it: replying to the sender alone in a + multi-person thread SILENTLY DROPS everyone else from a conversation they are + part of. It reads as a reply to the thread and is not one. Reply-to-sender + remains on an individual message row, where the user has picked one message + and one correspondent deliberately. - Its threading headers come from the thread's **newest** message, so `In-Reply-To` and `References` land the answer at the end of the conversation and the recipients are the current ones. -- cgit v1.2.3