docs: file Empty Trash as item 118, point 103 at its spec

Item 103's measurement is done, so its section carries the finding and the
three constraints that decide whether to open the spec, rather than the
design inline.

Item 118 is blocked on 103 and is the first action that would destroy mail
with no undo, which is why it is filed separately rather than folded in.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2 files changed, 73 insertions, 23 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 82860a3..6a5e64d 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
@@ -182,6 +182,7 @@ taking that too literally.
 | 115 | A copy from the message pane gives no confirmation | presentation | XS | open, 2026-08-17. Copy link address, Copy image address and Copy image all work, silently. `statusMessage` already exists and already expires |
 | 116 | Copy image copies markup instead of the image | defect | XS | **dropped** 2026-08-17, same day. NOT A DEFECT: `wl-paste --list-types` run immediately after a copy reports `image/png`, `application/x-qt-image` and 30 more image flavours. The clipboard is correct and Chromium is behaving. The earlier "text only" reading was taken minutes late off a clipboard that had been overwritten, and a whole cause was theorised on it |
 | 117 | The message pane offers no Select all | workflow | XS | open, found 2026-08-17. NOT caused by item 100: verified by hand against a build with that filter reverted, and the menu holds Copy and the search entries either way |
+| 118 | No way to empty the trash from inside the app | workflow | S | open, 2026-08-17. **Blocked on 103**, which creates the trash in the first place. Deliberately left out of 103's spec at the user's request rather than squeezed in |
 
 Sizes are rough: XS under an hour, S a sitting, M a session.
 
@@ -505,26 +506,35 @@ Maildir filename flags, and mbsync carries filename flags to the server. Whether
 deleted, together decide whether this button is reversible. The undo stack makes
 the TAG reversible; it says nothing about what a sync did with it in between.
 
-**Approach.** Measure before designing anything: the notmuch config's
-`maildir.synchronize_flags` and its tag-to-flag mapping, one real message tagged
-and synced in a test account, and what the server shows afterwards. Then decide
-whether the UI needs to say what it does, whether "Delete" is even the right
-word for it, and whether a trash view is wanted.
-
-**Constraints.**
-
-- **This is the one place the no-confirmation rule should be re-examined rather
-  than assumed.** `CLAUDE.md` records that a human at a GUI gets undo instead of
-  confirmation dialogs, and that is right for tags. If the measurement shows the
-  next sync expunges mail from the server, then undo does not in fact cover this
-  action, and the premise the rule rests on does not hold for it.
-- Do not test this against the user's real accounts. A message that is expunged
-  to prove that it is expunged is still gone.
-- Any answer that involves a trash view is a much larger item and should be
-  split out rather than folded in here.
-
-**Size: S** for the investigation and whatever the UI needs to say. Unknown
-beyond that, and deliberately not sized further until the measurement exists.
+**Measured 2026-08-17, and the answer is that Delete does not delete.** notmuch's
+tag-to-flag table has no row for `deleted` and no `T` flag, confirmed by a probe
+on a throwaway database: `+deleted` left the filename untouched while the
+control `+flagged` immediately produced `:2,F`. mbsync carries filename flags, so
+`Expunge Both` never sees anything to expunge, and `assets/mailsync.sh` contains
+no delete path. Both sub-questions answer no: no trash bin, no deletion from the
+server, and the mail stays in the Maildir and the index forever.
+
+**Specified in
+`specs/2026-08-17-delete-to-trash-design.md`. Read that before writing code.**
+Delete becomes a real move into the account's trash folder, with a `Trash`
+filter beside the other built-ins and a Restore action. Three constraints decide
+whether the spec is worth opening:
+
+- It needs a **mandatory per-account `trash` key**, so an existing config warns
+  until five keys are added. User-visible: minor bump and an `### Upgrading`
+  note.
+- The worker gains its **first non-tag mutation**, a rename plus a reindex,
+  deliberately shaped as `moveMessages(ids, destFolder)` so Send in v2 reuses it
+  for Drafts and Sent.
+- **848 messages carry the old tag** while sitting in an inbox, and would be
+  invisibly half-deleted after the change. A repeatable menu entry queries them
+  into the list for review; it is not a startup migration.
+
+The no-confirmation rule survives, with its justification amended: the mail
+lands in a browsable folder, but reversibility is now bounded by the provider
+where the trash is purged on a timer.
+
+**Size: S** for the investigation, which is done. The build is **M**.
 
 ## 104. Mail visible in Thunderbird never reaches qtmaildir
 
@@ -845,6 +855,40 @@ entry is missing.
 
 **Size: XS.**
 
+## 118. No way to empty the trash from inside the app
+
+**Observed (user, 2026-08-17):** raised while reviewing item 103's spec, as
+something that had been forgotten rather than newly noticed: "we could add
+'Empty Trash' to the backlog as a future item. I forgot it existed, but I don't
+want to squeeze it in this spec."
+
+**Blocked on 103**, which creates the trash folder this would empty. Until that
+ships there is nothing to empty: Delete writes a tag and moves no file, so no
+account has a populated trash folder except through another client.
+
+**Deliberately excluded from 103's spec**, at the user's request and recorded in
+its "Out of scope" section. Worth keeping separate for a reason beyond scope
+control: emptying the trash is the first action in this application that would
+destroy mail with no undo. Every mutation so far is a tag or, after 103, a move,
+and both are reversible. A purge is not.
+
+**Approach, unspecified.** The shape depends on decisions not yet made, and the
+spec for 103 answers none of them:
+
+- **Local or remote.** Deleting the files locally and letting `Expunge Both`
+  carry it to the server is one thing; asking the provider to empty its own
+  trash is another, and mbsync offers no verb for the latter. The first is
+  probably what "Empty Trash" should mean here.
+- **Whether the no-confirmation rule survives it.** It does not, on the face of
+  it. `CLAUDE.md` grants undo in place of confirmation dialogs, and this is the
+  action where undo cannot exist. That makes it the second item, after 103, that
+  re-examines the rule rather than assuming it, and unlike 103 it will probably
+  have to break it.
+- **Per-account or all-accounts**, which should follow whatever the Trash filter
+  does once 103 ships rather than being decided independently.
+
+**Size: S**, provisionally, and not worth sizing properly until 103 exists.
+
 ## Deferred, unsized, or split out
 
 Items noted while triaging but not part of the original list. Same numbering
diff --git a/docs/superpowers/specs/2026-08-17-delete-to-trash-design.md b/docs/superpowers/specs/2026-08-17-delete-to-trash-design.md
index 87b8634..dae5122 100644
--- a/docs/superpowers/specs/2026-08-17-delete-to-trash-design.md
+++ b/docs/superpowers/specs/2026-08-17-delete-to-trash-design.md
@@ -1,6 +1,8 @@
 # Delete moves mail to trash
 
-Item 103. Design settled 2026-08-17 with the user.
+**Resolves item 103.** Design settled 2026-08-17 with the user. Item 118
+(Empty Trash) is blocked on this and deliberately out of scope, see the last
+section.
 
 ## The problem, measured
 
@@ -211,5 +213,9 @@ folder is purged on a timer.
 ## Out of scope
 
 No purge, no empty-trash, no expiry inside the app. Mail leaves the trash folder
-when the server does it or when the user restores it. Purging from inside
-qtmaildir is a separate item if it is ever wanted.
+when the server does it or when the user restores it.
+
+Emptying the trash is **item 118**, filed separately at the user's request
+rather than folded in here. It is blocked on this item, and it is the first
+action in the application that would destroy mail with no undo, so it needs the
+no-confirmation rule re-examined in a way this item does not.