1 files changed, 1 insertions, 52 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 6a5e64d..1f71006 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
@@ -167,7 +167,7 @@ taking that too literally.
 | 100 | The message pane offers Back, Forward, Reload and Save page, none of which mean anything | defect | XS | **done** 2026-08-17, unreleased. `MessageView::removeBrowserActions()` filters the standard menu by `pageAction()` POINTER, never by text; `ViewSource` went with them, and stranded separators are swept |
 | 101 | Sync is account-aware for edits but not for the account the user is looking at | workflow | S | open; item 49 built the edit half deliberately. Needs a decision, see the entry |
 | 102 | The rules table shows no note, so the field explaining a rule is invisible until it is opened | workflow | XS | **done** 2026-08-17, unreleased. A Note column before `ColumnCount`, so the appended Matches column stays last. Found a second defect on the way: `restoreState` REFUSES a header state with a different column count, and the sized flags were being set regardless |
-| 103 | What Delete does to mail on the server is undocumented and unverified | clarification | S | open; a question first, possibly no code at all |
+| 103 | What Delete does to mail on the server is undocumented and unverified | clarification | S+M | done; Delete moves to the account trash, with Restore and a stranded-mail cleanup. Section in the closed file |
 | 104 | Mail visible in Thunderbird never reaches qtmaildir | defect | ? | open, reported 2026-08-16, cause NOT established. Most likely outside this repo; see the entry before writing code |
 | 109 | A root card's own message is invisible to a message-scoped write | defect | S | **done** 2026-08-16, unreleased. Found by hand-testing 108. `applyMessageTagChange` and `messageById` searched only the loaded replies, and a root's message is never among them, so the ORDINARY gesture repainted nothing and wiped the pane's chip row |
 | 110 | A card and the message pane show tags belonging to a message's siblings | defect | S | **done** 2026-08-16, unreleased. Found by hand-testing 109 against a real 4-message thread. `ThreadSummary::tags` is notmuch's UNION; a card standing for one message drew it. Also the reason a root card could not repaint at all |
@@ -485,57 +485,6 @@ reaches it (item 42), so most of this exists.
 
 **Size: S** for the on-demand button, XS for the visibility half. Ask which.
 
-## 103. What Delete does to mail on the server is undocumented and unverified
-
-**Observed (user, from the notes):** "verify how 'delete' works", with two
-sub-questions of their own: "trash bin (?)" and "delete from server (?)".
-
-**This is a question first.** The user is not reporting a defect; they are saying
-they do not know what the button does to their mail, which for a destructive
-action is its own problem regardless of the answer.
-
-**What the code does (verified).** `src/mainwindow.cpp:825` adds and removes the
-`deleted` tag, and nothing else. It is a toggle, it goes through the undo stack,
-and it writes a notmuch tag.
-
-**What that means downstream is what needs verifying, and it is NOT in this
-repo.** `maildir.synchronize_flags` is true, so notmuch maps certain tags to
-Maildir filename flags, and mbsync carries filename flags to the server. Whether
-`deleted` is one of those, whether the user's `~/.mbsyncrc` has `Expunge Both`
-(it does, on every channel), and what each provider does with a message flagged
-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.
-
-**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
 
 **Observed (user, from the notes):** "sync doesn't work compared to thunderbird.