docs: record the message bar's next actions as item 189

From the user's notes: Star and Archive on the pane's own bar, and Mark all
read raised as a question. Two of the three fit the rule items 185 and 186
settled, that the bar carries what acts on the displayed message; mark_all_read
does not, since it deliberately ignores the selection and acts on every row in
the view.

Also records why Archive stays off the trash branch, which is narrower than it
looks: Delete already strips inbox, so Archive is a genuine no-op on mail this
application trashed. It is a real but pointless write on mail trashed by
another client, which never had its tags rewritten and can still carry inbox.

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

1 files changed, 66 insertions, 0 deletions

diff --git a/docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md b/docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md
index 3ace9d2..8370e35 100644
--- a/docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md
+++ b/docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md
@@ -262,6 +262,7 @@ taking that too literally.
 | 186 | Delete sits on the main toolbar rather than beside Reply and Forward | presentation | XS | **done 2026-08-29**, unreleased, with 185. Moved to the message bar's ordinary branch; still in the Message and context menus. Section in the closed file. Original entry: `toolBar->addAction(... "delete")` at `mainwindow.cpp:2251`. The user places it with the message actions, so this rides with item 185 rather than being done alone: moving it before the bar is trash-aware leaves Delete in a bar that still offers Reply on trashed mail |
 | 187 | There is no Spam view beside Trash | workflow | S | open, 2026-08-29, from the notes. `kQueryGenerators` (`config.cpp:62`) holds six generators and no `spam`, while the `spam` ACTION has existed since 0.2.x and writes the tag. So mail can be marked spam and never listed. A tag generator like `unread`, not a folder one like `trash`: nothing in the config names a spam folder, and adding one would make it a per-account mandatory key like `trash` |
 | 188 | Does Empty trash respect the account selector? | question | XS | **answered 2026-08-29** by reading the code, no work needed. It does: `MainWindow::emptyTrash()` (`mainwindow.cpp:6567`) reads `m_accountBox->currentData()` and uses `allTrashQuery()` only for All accounts, and the confirmation names which. Recorded so the notes' question has an answer rather than sitting open |
+| 189 | The message bar carries only Reply, Forward and Delete | presentation | S | open, 2026-08-29, from the notes, and a follow-on from 185 and 186 rather than a defect. Asks for Star (`flag`) and Archive on the bar, and raises Mark all read as a question. Two of the three are selection-scoped and fit the bar's rule as it stands; **`mark_all_read` does not**, since it deliberately ignores the selection and acts on every row in the view, which is the one action in the window that does. Needs a decision from the user on that one and on whether Archive LEAVES the main toolbar the way Delete did |
 
 Sizes are rough: XS under an hour, S a sitting, M a session.
 
@@ -1461,3 +1462,68 @@ dialog names the scope ("every account" or the account's display name).
 
 Recorded rather than dropped so the notes' question has an answer here, which
 is where the user will look for it.
+
+
+## 189. The message bar carries only Reply, Forward and Delete
+
+**Observed.** The user asks for more of the standard message actions on the
+pane's own bar, now that items 185 and 186 established it as where actions on
+the displayed message live:
+
+- **Star (Important)**, per message or selection
+- **Archive**, per message or selection, possibly moved off the main toolbar
+  the way Delete was
+- **Mark all read**, raised as a question rather than a request
+
+**Cause.** Nothing is broken. The bar was filled with the reply pair when it
+was built (items 139 to 141) and has gained a branch at a time since: Edit
+draft for a draft (157), the trash trio and Delete (185, 186). Its rule has
+never been written down, which is why the third of these does not obviously
+fit.
+
+**The rule the bar has actually followed, stated.** An action belongs on the
+bar when it acts on **what the pane is displaying**. That is why Compose is on
+the main toolbar and Reply is not (item 140), and it is what made Delete's move
+correct in item 186.
+
+**So two of the three fit and one does not.**
+
+- **`flag`** is selection-scoped and is a toggle over the displayed message.
+  It fits with no decision needed.
+- **`archive`** is selection-scoped and fits the same way. The open part is
+  only whether it LEAVES the main toolbar, as Delete did, or appears on both.
+  Delete left because a duplicate reads as two different controls when the
+  toolbar is icon-only; the same argument applies here.
+- **`mark_all_read` does NOT fit.** It is the one action in the window that
+  deliberately ignores the selection (`markAllRead()`, "Every row, not the
+  selection"), and it is gated on the query being COMPLETE rather than on
+  anything being displayed. Putting a view-wide action on a bar whose every
+  other entry acts on one message is how a user marks a thousand threads read
+  meaning to mark one. This is the user's own `#discuss` and the answer from
+  here is: leave it on the main toolbar.
+
+**Approach.** Add `flag` and `archive` to the ordinary branch of
+`refreshMessageBarActions()` beside Reply, Forward and Delete. Decide with the
+user whether `archive` also comes off the main toolbar. Leave `mark_all_read`
+where it is unless the user overrules the reasoning above.
+
+**Constraints.**
+
+- **The trash branch must not grow with it**, though the reason is narrower
+  than it first looks. Delete already strips `inbox` alongside `unread` (the
+  `sendMove()` call in `trashMessages()`, since 2026-08-26), so on mail THIS
+  application deleted, Archive is genuinely a no-op, as the user observed.
+  The gap is mail trashed by ANOTHER client: nothing rewrote its tags, so it
+  can sit in a trash folder still carrying `inbox`. That is the same reason
+  the trash view is path-based rather than `tag:deleted`. On such a message
+  Archive is a real write that strips `inbox`, counts an unsynced change and
+  rewrites the Maildir filename under `synchronize_flags`, all with no visible
+  effect, which is item 168's shape exactly. Star is harmless there but adds a
+  fifth button to a bar that is already three. Whatever is added goes on the
+  ORDINARY branch only.
+- **Five buttons is the practical ceiling** on an icon-only bar next to the
+  view controls, so this is close to full. Anything after this needs the
+  overflow question answering rather than one more icon.
+- **Every action added must carry a distinct icon**, which the existing test
+  enforces for anything reachable from a toolbar. `flag` and `archive` already
+  have their own.