1 files changed, 46 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 6613059..bcb6431 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
@@ -10232,3 +10232,49 @@ sends, and asserts the row arrives with no further gesture: no second
 against the defect. Mutation-checked by disabling the connection, which fails
 on the row count.
 
+## 101. Sync is account-aware for edits but not for the account the user is looking at
+
+**Done 2026-09-08.** The user chose BOTH halves the entry offered, and then
+narrowed the first one: not a second action beside Sync, but the existing Sync
+made account-aware. "If 'All Accounts' is selected, Sync works as today, if
+'work' is selected, hitting Sync works only for 'work'."
+
+**What was built.** `pendingSyncChannels()` now reads the account dropdown as
+well as `m_editedAccounts`, and the two are a UNION rather than one replacing
+the other. That union is the whole safety property and is the constraint the
+original entry named: looking at one account while having edited another is
+ordinary, and a run that dropped the edited account's channel would strand that
+write with nothing on screen to say so. All accounts is the empty key and
+narrows nothing, so a full fetch is still what an unselected window asks for,
+which is what keeps item 49's reasoning intact. The existing fallback survives
+untouched: an account whose section names no channel still widens the run to
+everything rather than being silently skipped.
+
+The visibility half is `syncStartedText()`, called from `setSyncBusy()`. A run
+used to open with "Syncing..." whether it covered one account or all of them,
+which is precisely the invisibility the entry complained about; it now reads
+"Syncing all accounts..." or "Syncing work-channel, personal-channel...". The
+exit paths pass no channels and overwrite the label with their own wording
+immediately, so the parameter is defaulted rather than threaded through them.
+
+**Four tests**, three on the channel resolution and one on the generated
+string. `syncNarrowsToTheSelectedAccount` asserts the list is EMPTY before the
+gesture, which matters more than it looks: empty is what a full fetch looks
+like, so a test starting from a narrowed state could not tell the fix from a
+window that had never widened. `aNarrowedSyncStillCarriesAnEditFromAnotherAccount`
+is the union, and it is the one that fails under the plausible wrong
+implementation. `theStatusLineNamesWhatASyncWillCover` asserts on the generated
+string rather than on a label after a real run, which would be a test of
+QProcess timing.
+
+Mutation-checked twice: ignoring the selection fails all three channel tests,
+and replacing the pending set instead of unioning with it fails the third one
+alone. That second mutation is the one worth having, since it is the version
+that looks correct and loses a write.
+
+**One thing deliberately not done.** The separator in the channel list is a
+plain `", "`, not a translated string. `lupdate` picked it up as translatable
+when it was written with `tr()`, and a comma joins a list the same way in
+Italian; a translatable separator is a string for a translator to get wrong for
+no gain.
+