1 files changed, 45 insertions, 7 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 d98c91e..9424ea4 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
@@ -89,7 +89,7 @@ taking that too literally.
 | 39 | Thread list cannot be sorted by clicking a column header | workflow | S | open |
 | 40 | No live filter over the current view | workflow | M | open |
 | 41 | A message whose HTML body carries a `Content-Id` renders blank | correctness | S | **done** |
-| 42 | "Syncing..." says nothing about what is being synced | feedback | S | open |
+| 42 | "Syncing..." says nothing about what is being synced | feedback | S | **done** |
 | 43 | No "Mark all read" for the current view | workflow | S | open |
 | 44 | No way to manage the filters applied at sync time | workflow | ? | open, unspecified |
 | 45 | Two Sync buttons, and only one of them works properly | correctness | S | **done** |
@@ -2093,18 +2093,34 @@ away.** `assets/mailsync.sh` streams every mbsync and `notmuch new` line,
 timestamped, through `tee` (`assets/mailsync.sh:75-96`), and `MailSync` emits
 each chunk as `outputReceived` (`src/mailsync.cpp:65-74`), which fills the sync
 log pane. The status label is set once to `tr("Syncing...")`
-(`src/mainwindow.cpp:1569`) and never updated until the run finishes. So this
-needs no change to the script and no new channel; it needs the existing stream
-read for state.
+(`src/mainwindow.cpp:1569`) and never updated until the run finishes.
+
+**Correction (2026-08-07, measured): the paragraph above was half wrong, and
+the "no script change needed" claim with it.** `notmuch new` does stream, but
+plain `mbsync -a` prints **nothing at all** until it exits, then one summary
+line. Measured on a real run: one line at 11:11:08, then 73 lines within the
+single second 11:11:33, at the end of a 46-second run. So for the part of a
+sync that actually takes time there was no output to read, and no parsing of
+the existing stream could have fixed that.
+
+Two wrong diagnoses were made and discarded before the real one. It is **not**
+buffering, so `stdbuf` does nothing: the output streams fine, there simply is
+none. And the account name **is** available, contrary to the first reading of
+this item, which concluded it was not and proposed shipping phases only.
+
+`mbsync -V` is what changes both: it announces each channel as it reaches it
+(`Channel <name>`), which is at once the progress indication and the account
+name the user asked for. The shipped script now passes it.
 
 **Approach.** Derive a short status from the output already being received.
 
 - Recognise the phase from the stream: lines before `notmuch new` starts are
   mbsync's, and `notmuch new` announces itself. Show "Syncing mail (mbsync)"
   then "Reindexing (notmuch)".
-- mbsync prints the channel it is working on, which is the account name the user
-  wants to see. Take it from the output rather than from config, so what is shown
-  is what is actually happening.
+- mbsync prints the channel it is working on **only under `-V`**, which is the
+  account name the user wants to see. Take it from the output rather than from
+  config, so what is shown is what is actually happening, and in the order it
+  actually happens.
 
 **Constraints.**
 
@@ -2120,6 +2136,28 @@ read for state.
 - Match loosely. mbsync's exact wording varies by version, and a status line that
   goes blank because a string moved is worse than the current fixed one.
 
+**Two defects in existing code, found while building this and fixed with it.**
+
+- `startSync()` called `setSyncBusy(true)` **after** `m_sync->start()`, so any
+  per-run state reset there happened after the process had already produced
+  output. A short run delivers everything before control returns, which wiped
+  the phase those lines had produced. The reset now happens before the launch.
+- The first draft deferred a phase while a transient message was still showing,
+  reading the constraint above as "never clobber a message the user is
+  reading". That let a `Background sync completed` message armed **before** the
+  sync started suppress the entire run's phases, which is how the first hand
+  test came back red. A running sync's state outranks an expiring event
+  message, so the deferral was removed. The constraint it was serving is
+  satisfied the other way round: a phase is written directly rather than
+  through `showTransientStatus()`, so the timer never reclaims it.
+
+**Verification note.** A test script that prints its lines at once is delivered
+in a single `readyRead`, so the tracker sees the whole run in one call and only
+the final phase is ever painted, which makes every intermediate one
+unobservable. `test_mainwindow`'s script therefore paces itself with `sleep`,
+standing in for a real sync's tens of seconds. The parser itself was checked by
+replaying real captured `mbsync -V` output through it.
+
 ## 43. No "Mark all read" for the current view
 
 **Observed (user, 2026-08-05):** a "Mark All Read" button next to Sync, Archive,