docs(backlog): settle item 91's open question, postpone item 92

91 needed one decision, how the user leaves a drill-down, and the answer is that
nothing is built for it: "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 already
are that and are one click away in every view, so the Back action, the history
stack and the restore-the-previous-query scheme are all unnecessary. That also
retires the undo-stack concern: a drill-down clears the stack exactly as a typed
query does, which is the behaviour the user already expects from the query bar.
The item is now fully specified and ready to build at S.

92 is postponed at the user's request: "I don't see the utility, so I don't
really know how to answer." The clarification that preceded it named the
per-message version, which needs provenance nothing records, costs a format
change across both repos against a hook running on real mail every ten minutes,
and stays blank on every message already tagged. A feature whose requester
cannot say what it is for should not be built. The cheaper substitute is
recorded beside it for if the question ever turns out to be "why does this
message carry this tag", which rules.json can answer at read time with nothing
stored.

Section moved to the closed-items file on this commit, per CLAUDE.md.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

1 files changed, 19 insertions, 62 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 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