1 files changed, 35 insertions, 0 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 e9f99a4..051d6c4 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
@@ -205,6 +205,7 @@ taking that too literally.
 | 133 | The composer shows no markdown syntax highlighting | v2 | S | open, 2026-08-20, from the item 123 brainstorm. **Blocked on 123.** A `QSyntaxHighlighter` over the composer's editor, so `**bold**` reads as bold while the buffer stays plain markdown. Standard Qt, no dependency. Deliberately after 123's formatting toolbar: agreeing with the grammar about nesting and about code spans suppressing what is inside them is the expensive part, and the toolbar is what makes the feature usable |
 | 134 | The busy indicator is built inline and is about to be built twice | maintenance | S | done, 2026-08-20, af902e0. `BusyIndicator` (`src/busyindicator.h`) carries both modes: `MainWindow` uses the indeterminate one, and item 123's send popup takes the determinate half for its undo countdown, switching the same widget over when the command starts. Only the BAR was extracted, not the status label this row paired with it. `m_statusLabel` has 34 uses across `MainWindow` for transient messages, selection counts and sync phases, so it belongs to the window rather than to the indicator, and the send popup owns its own phase text |
 | 135 | The formatting toolbar's buttons stack rather than toggle | v2 | S | open, 2026-08-21, asked for by the user during item 123 task 8 and reverted the same session. **A spec change, not a defect**: it conflicts with spec:236 ("deliberately no live toggle") and spec:187-190. Both sites need amending FIRST, and the amendment must resolve what replaces bold-then-italic, which is the gesture spec:187's preserved selection exists to serve and which a toggle makes unreachable. That question is the work; the state machine is understood and written up in the section |
+| 136 | `undoMovesTheMessageBack` fails about one run in six | defect | ? | open, 2026-08-21, found while running the suite during item 123 task 10. A pre-existing race in the test or in Delete's file move, NOT caused by 123: reproduced on a clean tree with the branch's work stashed out, 1 failure in 6 runs, and the failing run took 70s against a normal 25s. Unrelated to `SendDialog`. Size unknown until the race is located |
 
 Sizes are rough: XS under an hour, S a sitting, M a session.
 
@@ -1213,3 +1214,37 @@ whether to open the spec at all, and leave the rest there.
 
 Name the spec `<date>-<name>-design.md`, and state in its header which backlog
 items it resolves, so the numbering stays traceable in both directions.
+
+## 136. `undoMovesTheMessageBack` fails about one run in six
+
+**Observed.** `test_mainwindow` failed during a full-suite run while item 123
+task 10 was in the working tree. The failing function is
+`TestMainWindow::undoMovesTheMessageBack`. The run that failed took 70 seconds
+against a normal 25, so whatever goes wrong also blocks for a while before
+giving up.
+
+**Not caused by item 123.** This was checked rather than assumed, because a
+failure appearing during unrelated work is exactly the kind of thing that gets
+blamed on the change in front of it. With the branch's work `git stash`ed out,
+on a clean tree, it still failed **1 run in 6**. Nothing in `SendDialog`
+touches the model, the Maildir, or the undo stack.
+
+**Cause, unverified.** A race around the Maildir file move that Delete
+performs and Undo reverses. Whether the race is in the test's wait or in the
+production move is exactly what the item has to establish, and that is why the
+size is `?` rather than a guess. The two have very different consequences: a
+test that waits wrongly is noise, while a move that races is mail landing in
+the wrong folder, and CLAUDE.md already records that a wrong folder name from
+this code path reaches the mail server.
+
+**Approach.** Reproduce in isolation first, with the suite's own
+`QT_QPA_PLATFORM=offscreen` and a loop over `ctest -R mainwindow`, and capture
+a failing run's output before theorising. The 70-second duration is the useful
+clue: something is waiting on a condition that never arrives rather than
+asserting immediately, so find which `QTRY_*` or `qWait` is timing out.
+
+**Constraints.** A fix must not restore the real `/proc/locks` (item 61), and a
+flaky test must not be "fixed" by widening its timeout until it passes, which
+converts a real race into a slower green. If the race turns out to be in the
+production move rather than the test, this stops being a test-hygiene item and
+becomes a mail-safety one.