1 files changed, 1 insertions, 44 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 681200e..47c46fb 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.
 | 98 | "Important" adds the tag but cannot remove it, unlike every other toggle | defect | XS | **done** 2026-08-17, unreleased. Calls `everySelectedRowHasTag()`, as the entry required. Its reply test needed THREE different states (list-first thread, the reply's own thread, the reply) before it could tell the two wrong answers apart; with the reply defaulted to its thread's state the item 105 mutation stayed green, measured |
 | 99 | The unread action is labelled "Toggle unread" whichever way it will go | presentation | S | **done 2026-08-25**, unreleased, with 112: the user's note is ONE design across both. The label names the direction it will go, and the entry is hidden on a selection with no single state. `refreshUnreadAction()` reads the new three-valued `selectionTagPresence()` |
 | 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 |
+| 101 | Sync is account-aware for edits but not for the account the user is looking at | workflow | S | **done 2026-09-08**, unreleased. The user chose both halves the entry offered and narrowed the first: no second action, the existing Sync reads the account dropdown. Selected account narrows the run, All accounts is a full fetch as before, and the edited accounts are a UNION with the selection so a narrowed run cannot strand a write. The status line names what a run covers. See the closed 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+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 | XS | **done 2026-08-25**, hand-tested. The worker never reopened its read-only notmuch handle, so no query saw mail indexed after startup. Confirmed on a sync run from the application that added 20 messages: they appeared without a restart |
@@ -484,49 +484,6 @@ literals `lupdate` can see; a string built by concatenation is not translatable.
 
 **Size: S.** Mostly the mixed-selection and toolbar decisions, not the code.
 
-## 101. Sync is account-aware for edits but not for the account the user is looking at
-
-**Observed (user, from the notes):** "sync button should be account-aware."
-
-**Cause (verified in the code).** `MainWindow::pendingSyncChannels()`
-(`src/mainwindow.cpp:3550`) resolves channels from `m_editedAccounts`, the set of
-accounts the user has made EDITS in, and from nothing else. The account dropdown
-is not consulted. With nothing pending it returns empty on purpose, and
-`mailsync.sh` turns that into `mbsync -a`, every channel.
-
-**Item 49 built exactly this and the reasoning still holds.** The comment states
-it: with nothing pending the run is a FETCH, and narrowing a fetch to wherever
-the last edit happened would "quietly stop collecting mail everywhere else".
-Fetching is global by nature; carrying edits is not.
-
-**So this needs a decision, not a fix.** The note does not say which of two
-things the user means, and they are different features:
-
-*Sync only the selected account, on demand.* A deliberate "sync this account"
-that ignores the pending set, presumably beside the existing Sync rather than
-replacing it. Useful when one account is slow and the user wants their mail from
-another one now. The risk is the one item 49 named: a button that looks like
-Sync and quietly does not collect the rest of the mail.
-
-*Show which accounts a sync will cover.* No behaviour change at all, just making
-the existing account-awareness visible, since today the user cannot tell whether
-a run is narrowed or full. The status bar already names each channel as mbsync
-reaches it (item 42), so most of this exists.
-
-**Constraints.**
-
-- The account dropdown is a VIEW filter. Making it also steer sync couples two
-  things the user may reasonably want apart: looking at one account while
-  fetching all of them is the normal case, not an edge case.
-- Whatever narrows a run must still carry every pending edit, or an edit is
-  stranded with nothing on screen to say so. `pendingSyncChannels()` already
-  falls back to a full sync when it cannot resolve a channel for an edited
-  account, and that safety must survive.
-- An account with no `[account.<key>]` section, or one whose section names no
-  channel, has no channel to sync. The fallback covers it today.
-
-**Size: S** for the on-demand button, XS for the visibility half. Ask which.
-
 ## 113. No way to see a message's HTML source
 
 **Observed (user, 2026-08-17):** reviewing item 100's removals, "view source