feat: flag what you answered, mark what was forwarded to you

Item 68, which turned out to be three things once its premise was
measured. The note asked to extend a "passed" subject rule to "Fw:";
there was no subject rule, and the correlation it rested on did not
exist. What did exist was a gap nobody had reported.

Reply and forward now flag their source. The Maildir R and P flags,
which every other client sets and notmuch reads back as "replied" and
"passed", had never been written here: measured on the developer's
index, all 317 "replied" and all 6 "passed" came from other clients.
ComposeWindow emits sourceMessageAnswered after a successful send and
MainWindow routes it through sendMessageTagChange, message-scoped and
off the undo stack, for the reason auto mark-read is: the flag records
that the mail went, and the send cannot be undone.

ComposeContext carries sourceMessageId rather than reusing inReplyTo,
which is deliberately empty on a forward so the recipient's client does
not file it under the thread it left. Keying on it made the "passed"
half dead code that compiled and never fired. A resumed draft is
excluded: its kind records how the file was opened, not what the user is
doing, so flagging on it would set R from a guess.

A received forward gets its own mark. Derived from the subject at paint
time, storing nothing and reaching no server, because "passed" means "I
forwarded this" and setting it from a guess would assert something false
on 222 existing messages. subjectIsForwarded() shares forwardSubject()'s
prefix table so the two cannot disagree, strips a Re: chain first, and
takes extra locale spellings from [general] forward_prefixes, which
extends the built-in table rather than replacing it.

A mutation survived the first round and corrected a claim in the code:
QRegularExpression::escape already makes a punctuation prefix inert, so
the word guard is not about pattern validity. It stops a configured "-"
matching "-: x". The comment and test say that now.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LXCZFLXbAii5n5wtovpdhh

2 files changed, 117 insertions, 57 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..39026cb 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,119 @@ 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.
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 437ceda..ffb41ae 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
@@ -136,7 +136,7 @@ taking that too literally.
 | 87 | Auto mark-read marks a whole thread, including replies never displayed | defect | S | **done** 2026-08-16, unreleased. Built on 108, which is why it stayed small: the timer tracks a MESSAGE id now, and arms for a reply too, which it never did before |
 | 88 | `threadAt(current.row())` answers about the wrong thread for a reply row | defect | M | **done** 2026-08-16, unreleased. The audit found FOUR live sites, not one. `ThreadListModel::threadFor(index)` resolves a reply through its parent; every caller holding a selected index converted, and no `.row()` on a selected index remains in `mainwindow.cpp`. Unblocks 87 |
 | 67 | The placeholder pane counts unread, flagged and inbox, but not sent or drafts | information | XS | **done** 2026-08-11, shipped in 0.15.0 |
-| 68 | A forwarded subject gets no `passed` tag | workflow | S | open; no subject rule exists, measured 2026-08-11. Decision needed: display mark (XS) or write the flag (S, syncs out) |
+| 68 | A forwarded subject gets no `passed` tag | workflow | S | **done 2026-08-26**, unreleased, as THREE things once the premise was measured away. The note asked to expand a subject rule to `Fw:`; there was no subject rule, and the correlation it rested on did not exist. What did exist was a gap nobody had reported: qtmaildir has never written `R` or `P`, so a reply and a forward now flag their source (off the undo stack, per the auto-mark-read precedent), and `subjectIsForwarded()` drives a SEPARATE received-forward mark, display only, extendable through `[general] forward_prefixes`. The user chose all three |
 | 69 | `passed` and `replied` read as words where every other state is a glyph | presentation | S | **done** 2026-08-11, inside item 70 |
 | 70 | Pane icons are a private set where the main window uses the system theme | presentation | M | **done** 2026-08-11; six shipped SVGs |
 | 71 | A toolbar action does not sync, so the edit sits until the next cron run | workflow | S | **done** 2026-08-11; 2s default, `auto_sync_delay_ms` |
@@ -374,62 +374,6 @@ recorded.
 
 **Size: `?`, unspecified.** Do not propose a design for this; ask.
 
-## 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.
 
 ## 72. No khard/khal integration