1 files changed, 62 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 730c722..ba8b99e 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
@@ -5039,3 +5039,65 @@ when the write is moved above the guard.
 
 The cold-cache cost measured above was not touched and should not be. Nothing
 about the timing changed.
+
+## 90. A saved-query button clears the account selection
+
+**Observed (user, notes):** "select an account and hit the 'unread' button, the
+panel should show unread messages from that account only, instead it refreshes
+the 'all accounts' list."
+
+**Cause, and it is a deliberate line, not an oversight.**
+`MainWindow::runSavedQuery()` (`src/mainwindow.cpp:1907`) resets the account box
+whenever the saved query names no account:
+
+```cpp
+const int index = saved.account.isEmpty()
+                      ? m_accountBox->findData(QString())
+                      : m_accountBox->findData(saved.account);
+if (index >= 0)
+    m_accountBox->setCurrentIndex(index);
+```
+
+The comment above it states the intent: "An unscoped query CLEARS the selection
+rather than inheriting whatever was there, which is the defect the rules preview
+hit." `runQuery()` (`:2020`) then scopes whatever the box holds, so with the
+reset removed the button would inherit the selection and the user would get what
+they asked for.
+
+**So this is a decision, not a bug to fix quietly.** Two behaviours are
+defensible and each breaks the other's case:
+
+- **Inherit.** The account box is a persistent scope and the buttons are
+  queries within it. This is what the note asks for. The risk is the one the
+  comment names: a query that already scopes itself, such as a rules preview
+  with `path:"work/**"`, gets scoped twice and matches nothing.
+- **Reset.** A saved query is self-contained and says exactly what it shows.
+  This is what ships. Its cost is that the account dropdown looks like a filter
+  and silently is not.
+
+**Approach.** Ask the user which they want before writing anything. If it is
+inherit, the narrow version is to inherit only for hand-written and generated
+entries and keep the reset for a preview, since a preview is the one caller that
+supplies its own path; the rules preview already forces index 0 itself at
+`:1637`, so it does not depend on this line.
+
+**Constraints.**
+
+- Whatever is chosen, one rule for every saved-query surface: the buttons, the
+  menu and the dropdown all reach `runSavedQuery()`, and three behaviours here
+  would be worse than either one.
+- A saved query that DOES name an account must keep overriding the box. That is
+  not in question and no test should lose it.
+- `Account::scopedQuery()` is the only place a scope is applied. Do not add a
+  second one to make a caller behave.
+
+**Folded into item 93 on 2026-08-15, not fixed in place.** Explaining this item
+to the user produced the reframing in 93: the button that misbehaves here should
+never have been a saved query, so `runSavedQuery()` keeps this behaviour and the
+filters get their own. The narrow fix considered here, inheriting the selection
+for unscoped entries, was rejected because it would also make every unscoped
+MENU entry compose, and those are the self-contained destinations that should
+keep resetting the account.
+
+Kept in full because the cause, the comment defending the reset, and the rules
+preview that motivated it are all still true of the code.