1 files changed, 217 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 1208c42..7261bd9 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
@@ -8491,3 +8491,220 @@ and the `unread` removal. The suite is 37 of 38, the failure being item 136 on
 an unrelated path, and no new user-facing strings were added.
 
 **Size: S** for the visibility half, XS for the `unread` half. Done.
+
+
+## 68. A forwarded subject gets no `passed` tag
+
+**Observed (user, from the notes):** "passed tag should appear when subject is
+`Fwd:` and `Fw:`." Refined in session on 2026-08-11: the user had noticed
+`passed` appearing on messages whose subject carried `Fwd:` and not on `Fw:`,
+and asked to expand the rule to both.
+
+**Cause:** there is no rule to expand. `passed` is the Maildir `P` flag in the
+message filename, translated into a tag by notmuch because
+`maildir.synchronize_flags=true`. The flag is written by whichever client
+forwarded the message, or by the server over IMAP; nothing reads a subject line
+anywhere in the chain. qtmaildir only ever colours the tag
+(`src/tagcolors.cpp:36-37`) and the database's `post-new` hook does not mention
+it either.
+
+**Measured against the real database (2026-08-11):**
+
+| Query | Count |
+|---|---|
+| `tag:passed` | 6 |
+| `tag:passed and subject:"Fwd:"` | 1 |
+| `tag:passed and subject:"Fw:"` | 0 |
+| `subject:"Fwd:" and not tag:passed` | 194 |
+| `subject:"Fw:" and not tag:passed` | 28 |
+
+Six tagged messages in the whole database, and every one of them carries `P` in
+its filename flags. The single overlap with `Fwd:` is a message that was
+forwarded and whose subject was already a forward, not evidence of a rule: 194
+`Fwd:` subjects carry no tag at all. The correlation the observation rests on
+does not exist.
+
+**Approach and the decision it needs first.** Two different features, and the
+measurements above decide how far apart they are.
+
+*Display only.* The card shows a forwarded mark when the subject matches. Touches
+no mail, changes no flag, reversible by deleting the rule. XS.
+
+*Write the tag.* qtmaildir sets `P` from a subject heuristic. With
+`maildir.synchronize_flags=true` that flag is a filename change that mbsync
+carries out to the server, on 222 existing messages, on a guess about a string.
+Not cleanly undoable, and it asserts a meaning for a flag this application did
+not define. Recommended against; recorded so the choice is deliberate rather than
+forgotten.
+
+**Constraints:** localised clients use their own prefixes, and `Fwd:` can appear
+inside a subject rather than at its head, so whatever matches must be anchored.
+If the tag is ever written, it must not be re-applied on every sync in a way that
+produces pending edits the user never made, item 28 is the record of a count
+going wrong. The display-only route avoids that entirely, since it derives the
+mark at paint time and stores nothing.
+
+**Size: S** as written, XS if it is display only. Most of it is the decision, not
+the code.
+
+**Status:** left open deliberately on 2026-08-11. The cause is settled and the
+options are costed; the user has not chosen, and no code was written.
+
+**Built 2026-08-26, and the observation was wrong in a way worth recording.**
+The note asked for one thing (expand a subject rule to `Fw:`) and the
+measurement above had already shown there was no subject rule and no
+correlation to expand. Taken literally the item was unbuildable; taken as what
+the user actually wanted ("I want to know visually if someone has forwarded a
+message to me") it split into three, and the user chose all three.
+
+**1. `replied` on a reply, `passed` on a forward.** The gap the item was
+really sitting on, and it was never reported. Measured 2026-08-26 against the
+developer's own index: 317 `replied` and 6 `passed`, spread over five
+accounts, every one of them written by another client or the server. Nothing
+in qtmaildir has ever written either flag. `ComposeWindow` emits
+`sourceMessageAnswered` after a SUCCESSFUL send; `MainWindow` routes it
+through `sendMessageTagChange`, message-scoped, off the undo stack for the
+reason `markCurrentThreadRead` gives (the flag records that the mail went, and
+the send cannot be undone, so an undo that retracted only the flag would leave
+the two disagreeing).
+
+**Two traps here, one of which was caught only by reading.** `inReplyTo` is
+deliberately EMPTY on a forward (carrying In-Reply-To would file the forward
+under the thread it left, in the recipient's client), so keying the emit on it
+made the `passed` half dead code that compiled and never fired. `ComposeContext`
+carries `sourceMessageId` instead, set for all three kinds. And a resumed
+`Kind::Draft` is excluded: its kind records how the FILE was opened, not what
+the user is doing, so a draft that began as a reply cannot be told from one
+that began as a new message. The cost is a missing flag on a reply finished in
+two sittings, which is the safe direction, since `maildir.synchronize_flags` is
+on and a wrong flag reaches the server.
+
+**2. A received-forward mark, display only.** `Marks::Mark::ReceivedForward`,
+a seventh SVG, drawn from `ThreadListModel::IsReceivedForwardRole` in BOTH the
+thread and the message branch per CLAUDE.md's rule. It is a different mark
+from `passed` on purpose: `P` means "I forwarded this", which is a different
+fact about a different person, and setting it from a subject guess would
+assert something false on 222 existing messages and propagate it to the
+server. Derived at paint time, stores nothing.
+
+**3. `[general] forward_prefixes`.** `subjectIsForwarded()` lives beside
+`forwardSubject()` and shares its prefix table, so "do not double the prefix"
+and "this is a forward" cannot drift apart. The config key EXTENDS that table
+rather than replacing it, so adding a locale does not lose the measured
+English/German/Iberian/French spellings. A `Re:` chain is stripped first
+(bounded to 8, since the subject is input from a stranger and this runs per row
+per repaint), so `Re: Fwd: x` is recognised.
+
+**A mutation survived the first round and corrected a claim in the code.** The
+word-validation guard on a configured prefix was commented, and tested, as
+protecting against an invalid pattern from an unescaped `(`. Measured with a
+standalone probe: `QRegularExpression::escape` already makes punctuation inert
+rather than invalid, so that test passed against the guard being removed. What
+the guard actually buys is narrower and real: a configured `-` would match
+`-: x` and a digit would match `2: x`. The comment and the test now assert
+that instead.
+
+**Not built, and left as the item's own recommendation:** writing `P` from a
+subject heuristic. Rejected on the same grounds the entry gave before the
+work started.
+
+
+## 119. The unsynced-changes count cannot be opened to see what it counts
+
+**Observed (user, from the notes):** "the bottom left statusbar message needs to
+be clickable and show what 'N unsynced changes' are in a modal window".
+
+**Cause (verified in the code).** `m_pendingLabel` is a plain `QLabel` added to
+the status bar with `addPermanentWidget` (`src/mainwindow.cpp:502-505`). A
+`QLabel` has no clicked signal and none is installed, so there is nothing to
+click and no route to a list. It carries a tooltip and nothing else.
+
+**The count is a SUM OVER FOUR SOURCES, and that is what makes this bigger than
+it looks.** `pendingEditCount()` returns
+`m_pendingTagEdits.size() + m_unnettablePendingEdits + held + heldMoves`.
+Three of those can name what they hold: `m_pendingTagEdits` is a
+`QHash<QString, bool>` keyed by message id, `m_heldEdits` and `m_heldMoves` are
+queues of edits waiting for a sync to end. **`m_unnettablePendingEdits` is a
+bare `int`** (`src/mainwindow.h:1248`), deliberately so: it counts confirmed
+changes that carry no message ids and therefore cannot be netted against
+anything.
+
+So a dialog built from what is currently kept would list three of the four
+groups and then have to account for a remainder it cannot describe. Showing "and
+3 more" is worse than the tooltip, because the user opened the window
+specifically to find out what those were.
+
+**Approach.** Two halves, and the second is the real work.
+
+- The clickable half is small: a label that emits on click (an event filter, or
+  a flat `QToolButton` styled as a label), plus a dialog listing what the three
+  describable groups hold. The message pane already resolves an id to a subject.
+- The complete half needs `m_unnettablePendingEdits` to become something that
+  can name its entries. Its comment says why it is an int: understating the
+  indicator is the direction that costs the user work, so it counts what it
+  cannot identify rather than dropping it. Making it describable means finding
+  out what those changes actually are and whether they can carry an id.
+
+**Constraints.**
+
+- **The count is deliberately conservative and must stay so.** Item 28 and item
+  54 both landed on this indicator being wrong in the direction that made the
+  user think their work was safe. A dialog that lists fewer changes than the
+  count claims is the same failure in a new place: reconcile the two, or state
+  the remainder honestly rather than hiding it.
+- **An external `notmuch` run can clear pending changes without this count
+  noticing**, which the tooltip already admits. A dialog makes that staleness
+  much more visible, since a listed change may no longer exist. Worth deciding
+  whether the dialog re-verifies against the database before showing.
+- Read-only. This is an information window, not a place to retry or discard a
+  change; either would be a new mutation path with its own undo question.
+
+**Size: S** for the clickable half over the three describable groups. **Unknown**
+for the fourth, and the item is not complete without it.
+
+**Closed 2026-08-26.** The blocker above was investigated first and did not
+survive: `m_unnettablePendingEdits` counted confirmed changes carrying no
+message ids, and `NotmuchWorker::applyTags()` (the only emitter of
+`tagsApplied`) returns early on an empty id list, which is that exact
+condition. `applyTagsToThreads()` resolves through a query and errors out on
+an empty result, so it cannot hand `applyTags()` an empty list either.
+
+**Measured rather than read**, twice, because reading is what produced the
+wrong answer the first time: a `qFatal` in the branch fired in 4 of 70
+`test_mainwindow` cases, all four building a `TagChange` by hand and invoking
+the slot directly with no worker, and a `Q_ASSERT` before the worker's own
+emit never fired across the whole suite. The counter was deleted and the
+guard it shadowed is pinned where it lives, by
+`applyTagsWithNoIdsDoesNothing()` in `test_notmuchworker`.
+
+Built in four commits: the snapshot, the subject resolve, the dialog and the
+click, then a sizing fix after a hand test.
+
+Three decisions the user made, each of which shapes the code:
+
+- **Scope follows the ACTION, not the storage.** A thread action shows one
+  thread row with the count of messages it covered; a message action shows
+  its message. The three queues already encoded this, so nothing is expanded
+  and nothing is escalated: `HeldEdit` is thread-scoped because a `*_thread`
+  action made it, and everything else carries message ids.
+- **A snapshot, frozen.** Taken at the click and never refreshed under the
+  user, who asked for exactly this: "if I keep the popup open for 20 minutes,
+  I don't want the popup to keep updating the info it's showing me."
+- **Subjects resolved, stale rows kept.** An id the index no longer holds
+  still gets a row saying its subject is unknown, because the count the user
+  clicked has to equal the list they are shown.
+
+The re-verify question this item worried about mostly dissolved: item 54
+already clears the count when an external sync carries the edits, so a change
+applied by cron does not survive to be clicked on.
+
+`resolvePendingSubjects()` answers POSITIONALLY, one subject per input row,
+because one id can legitimately appear on several rows and a combined query
+returns a set. `PendingChangeRow::startsMessage` is carried rather than
+inferred from a non-empty subject, so an unresolved id still opens a run of
+its own instead of folding its actions under the message above it.
+
+Read-only, per the constraint above. The dialog's height is sized to its
+content; that is a hand test, since the offscreen platform returns an
+identical frame either way.
+