2 files changed, 82 insertions, 62 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 c24ba23..ef5c68f 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
@@ -5461,3 +5461,66 @@ that a green suite endorsed a defect a screenshot found.
 
 **Confirmed by the user:** "one change sent now that the sync has finished. And
 the tag I added, sticked to the message."
+
+## 92. Nothing distinguishes a tag written by a rule from one the user applied
+
+**Observed (user, notes):** "should the UI allow to discriminate when a message
+has been tagged by a rule?"
+
+**Clarified by the user, 2026-08-15**, including the doubt: "I want a small
+visual hint that an email has been tagged by a rule vs tagged by me, but I'm
+questioning the utility of such a hint."
+
+That is the expensive half of the two this item used to hold. "Tagged by a rule
+vs tagged by me" is per-MESSAGE provenance, and the information does not exist
+anywhere today: a tag written by the `post-new` hook is an ordinary notmuch tag,
+indistinguishable from one applied by hand. The UI cannot show what nothing
+records, so the hint costs a format change before it costs any pixels.
+
+**What it would take**, and this is why the user's own doubt is the right
+instinct:
+
+- A marker the hook writes beside every tag it applies, either an extra tag per
+  rule (`rule:justeat`) or a field in the shared file. Both are two-repo changes
+  under "Changing the shared rule format" in `CLAUDE.md`, against a hook running
+  every ten minutes on real mail.
+- Retroactively, nothing. Every tag already on every message stays unattributed
+  forever, so the hint is blank on the entire existing Maildir and fills in only
+  as new mail arrives. A hint that is absent on most mail teaches the user to
+  ignore it.
+
+**A cheaper question that may be the real one.** If what the user actually wants
+to know is "why does this message carry this tag", that is answerable with no
+stored provenance at all: the rules name their tags, so the UI can say which
+rule WOULD tag a given message, read from `~/.config/mailrules/rules.json` at
+the moment it is asked. No format change, no hook change, nothing to backfill,
+and it works on mail tagged before the feature existed. It answers "a rule
+writes this tag" and never "a rule wrote THIS one", which is a weaker claim and
+an honest one.
+
+**Approach.** Put the cheaper question to the user before building either. If
+the answer is that the per-message distinction is genuinely wanted, this is an M
+spanning both repos and should be specced, not slipped into a session.
+
+**Constraint.** The hook is not this repo's to weaken. If provenance is wanted,
+the marker has to be something the hook can write without touching `unread` or
+`inbox`, and without consuming `tag:new` when the rules fail to load.
+
+**Postponed, 2026-08-15, at the user's own reading of it:** "let's skip 92 for
+now. I don't see the utility, so I don't really know how to answer."
+
+That is the right call and worth recording as more than a deferral. The
+clarification the user gave first ("I want a small visual hint that an email has
+been tagged by a rule vs tagged by me, but I'm questioning the utility of such a
+hint") names the per-message version, which is the expensive one: a two-repo
+format change against a hook that runs every ten minutes on real mail, for a
+hint that stays blank on every message already tagged. A feature whose own
+requester cannot say what it is for should not be built, and this one costs a
+schema before it costs a pixel.
+
+The cheaper substitute stays recorded above and needs no format change if the
+question ever turns out to be "why does this message carry this tag": the rules
+name their tags, so the UI can answer from `~/.config/mailrules/rules.json` at
+the moment it is asked, retroactively and with nothing stored. Reopen from
+there, not from the provenance design, unless real use shows the per-message
+distinction is what is wanted.
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 e55bad4..2e5e8c9 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
@@ -155,8 +155,8 @@ taking that too literally.
 | 86 | A right-click search can replace or narrow, but never exclude | workflow | S | **done** 2026-08-14, unreleased; see `specs/2026-08-14-exclude-from-search-design.md`. Follows 85. The `extend` bool became a `SearchMode` enum across four signatures |
 | 89 | A sync moves the list under the user's hands, and the auto-sync skips rather than retries | workflow | XS | **done** 2026-08-15, unreleased. The timer half only: a skipped auto-sync re-arms instead of giving up. The list-churn half is **dropped**, not built: the user resolved it as a mental-model question, an Unread view is SUPPOSED to be volatile |
 | 90 | A saved-query button clears the account selection | workflow | S | **folded into 93** 2026-08-15. Not fixed in place: the button that misbehaves stops being a saved query at all. See `specs/2026-08-15-builtin-filters-design.md` |
-| 91 | Double-clicking a thread should open it on its own | workflow | S | open, specified 2026-08-15. NOT a second window: a drill-down to that one thread, the same result an `id:` query gives. One decision left, how the user gets back |
-| 92 | Nothing distinguishes a tag written by a rule from one the user applied | information | M | open, specified 2026-08-15. The user wants per-MESSAGE provenance, which nothing records: a two-repo format change, blank on all existing mail. Put the cheaper "which rule would tag this?" to the user first |
+| 91 | Double-clicking a thread should open it on its own | workflow | S | open, fully specified 2026-08-15 and ready to build. A drill-down to that one thread, the same result an `id:` query gives. Nothing is built for getting back: the filter buttons already are that |
+| 92 | Nothing distinguishes a tag written by a rule from one the user applied | information | M | **postponed** 2026-08-15 at the user's request: "I don't see the utility, so I don't really know how to answer." Needs per-MESSAGE provenance nothing records, a two-repo format change blank on all existing mail. Reopen only if the need appears in use |
 | 93 | The query buttons are whatever the user pinned, not a designed set of filters | workflow | M | **done** 2026-08-15, unreleased; see `specs/2026-08-15-builtin-filters-design.md`. Absorbs item 90. Four built-in filters composing with the account dropdown; the user's own queries unpinned, never deleted |
 | 95 | A query in the overflow menu cannot be run | defect | XS | **done** 2026-08-15, unreleased. Pre-existing and not caused by 93: the entry's action owned a submenu, and Qt emits no `triggered` for those, so the connection had never fired. Surfaced because 93 moved every query into the menu |
 | 94 | `pinned` has nothing left to decide once the buttons are built-in | maintenance | S | open; **blocked on 93**, and deliberately not part of it. A user-visible removal: the row becomes built-ins only and every saved query lives in the menu |
@@ -517,66 +517,23 @@ the query bar: `SearchTerm` builds the `id:` query and `runQuery()` runs it.
 message row, `thread:` for a thread row, built through `SearchTerm` so the
 quoting rules stay in one place.
 
-**Decide before building: how the user gets back.** A drill-down that cannot be
-reversed is a trap, and this is the only real design question left in the item.
-Three candidates, and they are not equivalent:
-
-- Esc. Already means "clear the pane", then "clear the selection". A third
-  meaning is one too many.
-- A Back action, with its own binding and toolbar button. Honest, and the only
-  option that survives a drill-down FROM a drill-down.
-- Restoring the previous query text. Cheapest, and wrong the moment the user
-  edits the bar while drilled in.
-
-**Constraint.** `runQuery()` clears the undo stack, by design, since undo
-entries refer to rows that are about to be discarded. A drill-down is still a
-query, so a double-click would silently discard undo history. Either accept it
-and say so, or the drill-down is not a query at all but a filter over the model,
-which is item 40's machinery and makes this M rather than S.
-
-## 92. Nothing distinguishes a tag written by a rule from one the user applied
-
-**Observed (user, notes):** "should the UI allow to discriminate when a message
-has been tagged by a rule?"
-
-**Clarified by the user, 2026-08-15**, including the doubt: "I want a small
-visual hint that an email has been tagged by a rule vs tagged by me, but I'm
-questioning the utility of such a hint."
-
-That is the expensive half of the two this item used to hold. "Tagged by a rule
-vs tagged by me" is per-MESSAGE provenance, and the information does not exist
-anywhere today: a tag written by the `post-new` hook is an ordinary notmuch tag,
-indistinguishable from one applied by hand. The UI cannot show what nothing
-records, so the hint costs a format change before it costs any pixels.
-
-**What it would take**, and this is why the user's own doubt is the right
-instinct:
-
-- A marker the hook writes beside every tag it applies, either an extra tag per
-  rule (`rule:justeat`) or a field in the shared file. Both are two-repo changes
-  under "Changing the shared rule format" in `CLAUDE.md`, against a hook running
-  every ten minutes on real mail.
-- Retroactively, nothing. Every tag already on every message stays unattributed
-  forever, so the hint is blank on the entire existing Maildir and fills in only
-  as new mail arrives. A hint that is absent on most mail teaches the user to
-  ignore it.
-
-**A cheaper question that may be the real one.** If what the user actually wants
-to know is "why does this message carry this tag", that is answerable with no
-stored provenance at all: the rules name their tags, so the UI can say which
-rule WOULD tag a given message, read from `~/.config/mailrules/rules.json` at
-the moment it is asked. No format change, no hook change, nothing to backfill,
-and it works on mail tagged before the feature existed. It answers "a rule
-writes this tag" and never "a rule wrote THIS one", which is a weaker claim and
-an honest one.
-
-**Approach.** Put the cheaper question to the user before building either. If
-the answer is that the per-message distinction is genuinely wanted, this is an M
-spanning both repos and should be specced, not slipped into a session.
-
-**Constraint.** The hook is not this repo's to weaken. If provenance is wanted,
-the marker has to be something the hook can write without touching `unread` or
-`inbox`, and without consuming `tag:new` when the rules fail to load.
+**How the user gets back: nothing is built for it.** Answered by the user,
+2026-08-15: "I didn't think of a back action, usually I'd go back to a known
+list like unread or inbox at that point." The filter buttons are already that,
+and they are one click away in every view. A Back action, a history stack and a
+restore-the-previous-query scheme were all drafted and are all unnecessary.
+
+That collapses the only open question in this item. A drill-down is an ordinary
+query, entered by gesture instead of by typing, and it is left the way every
+other query is left.
+
+**The undo-stack note below therefore stops being a concern.** `runQuery()`
+clears the undo stack because its rows are about to be discarded, and a
+drill-down discards them exactly as a typed query does. The user already
+expects that from the query bar, so the gesture inherits a behaviour that is
+consistent rather than surprising. No filter-over-the-model alternative is
+needed, and the item stays S rather than growing into item 40's machinery.
+
 
 ## Deferred, unsized, or split out