1 files changed, 124 insertions, 0 deletions
diff --git a/docs/superpowers/plans/2026-08-03-post-0.1.0-usability-closed.md b/docs/superpowers/plans/2026-08-03-post-0.1.0-usability-closed.md
index ef51b5c..783e4ed 100644
--- a/docs/superpowers/plans/2026-08-03-post-0.1.0-usability-closed.md
+++ b/docs/superpowers/plans/2026-08-03-post-0.1.0-usability-closed.md
@@ -6699,3 +6699,127 @@ database directly.
 **Verified:** clean build with no warnings from any changed file, 24 of 24
 suites over three consecutive runs, 211 tests in `test_mainwindow`. Every one of
 the spec's six testing bullets has a test, each mutation-checked.
+
+## 115. A copy from the message pane gives no confirmation
+
+**Observed (user, 2026-08-17):** Copy link address, Copy image address and Copy
+image all work, and none of them says so. The user asked for "a small
+'link copied' transient that appears and disappears after a few seconds".
+
+**Cause:** not a defect, unbuilt. These are Chromium's own menu entries and it
+does not report success; nothing in this application is listening to them.
+
+**Copy image was thought to be broken and is not**; see item 116 in the
+closed-items file, which is worth reading for how a stale clipboard reading
+produced a confident wrong cause.
+
+All three work. Copy image was briefly filed as broken (item 116) and is not:
+the pixels reach the clipboard correctly, and the reading that said otherwise
+was taken off a stale clipboard. So this item covers the confirmation for Copy
+link address, Copy image address and Copy image alike.
+
+**Approach.** `MessageView::statusMessage` already exists and the status bar
+already expires its messages (item 33), so this is one connection per action and
+no new widget, no new timer. `QWebEnginePage::action()` gives each entry's
+QAction; connect `triggered` and emit the appropriate string.
+
+**Constraints.**
+
+- The message must name what was copied. "Copied" alone is worse than nothing
+  when three entries sit next to each other in the same menu.
+- Do not build a floating overlay for this. The status bar is where this
+  application reports transient results, and a second mechanism for the same
+  job is the kind of thing item 45 recorded when two Sync buttons disagreed.
+- Depends on nothing; can be built alongside 114 since both touch the same menu.
+
+**Size: XS.**
+
+**Built 2026-08-19.** Four entries report through the pane's existing
+`statusMessage`: Copy, Copy link address, Copy image and Copy image address,
+each naming what it copied rather than saying "Copied". Connected to the PAGE's
+own QActions in the constructor, which are the same instances the standard
+context menu holds, so the report follows the entry wherever it is triggered
+from and no menu of ours is involved.
+
+That is also what makes this fully testable, unlike item 117 beside it:
+triggering the action runs the production path with no context-menu event
+needed. The test enables each action first, since Chromium disables a copy entry
+when there is nothing of that kind under the cursor and `trigger()` on a
+disabled QAction emits nothing at all, which would have left the loop asserting
+nothing while looking thorough. Two mutations fail it: a duplicated message, and
+one entry left unwired.
+
+The strings are `QT_TR_NOOP` inside an array, which CLAUDE.md warns extracts
+NOTHING at file scope. Verified rather than assumed: `lupdate` found all four
+under the `MessageView` context with no warning, because the array sits inside
+a member function where the class context exists.
+
+## 117. The message pane offers no Select all
+
+**Observed (user, 2026-08-17):** right-clicking a body selection offers Copy and
+the search entries, and no Select all. Noticed while hand-testing item 100.
+
+**NOT caused by item 100, and this was verified rather than argued.** The user
+ran a build with `src/messageview.cpp` and `src/messageview.h` reverted to HEAD,
+so `removeBrowserActions()` did not exist, and reported the same menu: Copy and
+the search entries only. Chromium's standard menu for this pane has never
+carried Select all.
+
+**Three wrong theories preceded that measurement**, which is the part worth
+recording, because each was plausible and each cost a round trip:
+
+1. *The separator sweep removed it.* Disproved with a standalone program
+   reproducing the sweep against a realistic menu: it drops the leading
+   separator and keeps every action.
+2. *Chromium omits it when there is no selection.* Killed by the user, who had a
+   selection at the time.
+3. *A probe will show what the real menu holds.* `createStandardContextMenu()`
+   returns NULL outside an actual context-menu event, on the offscreen platform
+   and on a real display alike, so two probe attempts measured nothing.
+
+The lesson is the one item 100 had already written down and the agent did not
+follow: **a menu built by hand proves nothing about the menu Chromium builds.**
+`theBodyMenuDropsTheBrowsersOwnActions` constructs its own QMenu, which is right
+for testing the filter and useless for testing what is offered. That test now
+says so, and deliberately does NOT assert on SelectAll, since a passing
+assertion there would read as a guarantee the code does not make.
+
+**Approach.** Add it explicitly rather than hoping Chromium supplies it. The
+action already exists as `QWebEnginePage::SelectAll` and works; only the menu
+entry is missing.
+
+- `menu->addAction(page->action(QWebEnginePage::SelectAll))` in
+  `showBodyContextMenu`, placed beside Copy rather than appended after the
+  search entries.
+- Worth considering a `Ctrl+A` binding for the pane at the same time, though
+  note the pane is not the only focusable widget and the query bar has its own
+  claim on that key. Check `KeyMap::defaultBindings()` before adding one.
+
+**Constraints.**
+
+- **A test for this cannot use a hand-built menu.** That is the trap above. The
+  honest options are asserting the action is in the menu the production code
+  returns, which needs a real context-menu event, or leaving it to a hand test
+  and saying so. Do not write a test that constructs a QMenu and calls it
+  covered.
+- Select all selects the rendered body, not the header label, which is a
+  separate widget with its own selection. That is probably the desired
+  behaviour but should be looked at rather than assumed.
+
+**Size: XS.**
+
+**Built 2026-08-19** as `MessageView::addPaneActions()`, static and taking the
+menu, mirroring `removeBrowserActions()` beside it. Two stale comments went with
+it: both `showBodyContextMenu()` and the header of `removeBrowserActions()`
+claimed Select all was among the entries the standard menu supplied and that the
+filter preserved. Neither was true, and either would have sent the next reader
+back down the same three wrong theories.
+
+**The call site is not covered, and the test says so rather than pretending.**
+`addPaneActions()` has a test and a mutation dropping the entry fails it. A
+mutation deleting the CALL from `showBodyContextMenu()` leaves the whole suite
+green, measured, because `createStandardContextMenu()` returns nothing outside a
+real context-menu event and the offscreen platform cannot deliver one. The
+honest options the entry named were an assertion on the production menu or a
+hand test; the first is impossible here, so it is the second, recorded in the
+test so nobody adds an assertion that appears to cover it.