docs: open item 94, dropping pinned once the buttons are built-in

The user's end state for the query row is built-in filters only, with every
saved query living in the menu. At that point SavedQuery::pinned has nothing
left to decide.

Blocked on 93 and deliberately separate from it: the four buttons have to be
lived with first, and if one of them is wrong, pinning is the escape hatch,
which has to still exist to be used.

Recorded as a user-visible removal rather than a cleanup. pinned shipped in
0.18.0 as a checkbox in SaveQueryDialog and a right-click action, so removing
it is a minor bump with an Upgrading note. The stored field is a separate
decision from the UI, and leaving it in queries.json unread is both cheaper
and reversible.

The spec for 93 gains the ordering rule this resolves: filters first in fixed
order, the user's pinned queries after them, and nothing configurable, since
the mixed row exists only until 94 lands.

1 files changed, 45 insertions, 0 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 9b38d03..884c56b 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
@@ -158,6 +158,7 @@ taking that too literally.
 | 91 | Double-clicking a thread could open it in its own window | workflow | ? | open, unspecified; the user marked it "(?) UX not sure" |
 | 92 | Nothing distinguishes a tag written by a rule from one the user applied | information | ? | open, unspecified; the user asked it as a question, and the answer decides whether it is a display item or a format change across two repos |
 | 93 | The query buttons are whatever the user pinned, not a designed set of filters | workflow | M | open, specified 2026-08-15; see `specs/2026-08-15-builtin-filters-design.md`. Absorbs item 90. Four built-in filters that compose with the account dropdown |
+| 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 |
 
 Sizes are rough: XS under an hour, S a sitting, M a session.
 
@@ -584,6 +585,50 @@ account deliberately runs nothing, since the button is the verb.
 
 **Size: M.**
 
+## 94. `pinned` has nothing left to decide once the buttons are built-in
+
+**Observed (user, 2026-08-15),** thinking past item 93 rather than from the
+notes:
+
+> after we've migrated [...] we can drop my 4 redundant (by then) saved queries,
+> and there won't be a need for pinning anymore. The buttons will be driven by
+> the hardcoded queries, the menu will be the home for saved queries.
+
+**The end state this describes:** the query row is built-in filters ONLY, and
+every saved query lives in the menu. No mixing, so nothing has to decide which
+saved queries get button real estate, and `SavedQuery::pinned` is dead weight.
+
+**This also disposes of a problem item 93 would otherwise have to solve.** With
+both tiers sharing one row, something must order the four filters against the
+user's pinned queries. Under this end state the question does not arise.
+
+**Blocked on 93, and deliberately not part of it.** The user needs to live with
+the four buttons first and confirm they cover what they actually use. If one is
+wrong, pinning is the escape hatch, and it has to still be there to be used.
+Closing 93 and this together would remove the fallback before it was needed.
+
+**This is a user-visible removal, not a cleanup.** `pinned` shipped in 0.18.0:
+`SaveQueryDialog` offers "Show as a button" (`src/savequerydialog.cpp:104`) and
+the right-click menu offers "Move to menu" / "Show as a button"
+(`src/mainwindow.cpp:1797`). Anyone who put a saved query on the row loses that
+permanently. Semver on the user-visible surface makes it a minor bump with an
+`### Upgrading` note.
+
+**The stored field is a separate decision from the UI.** `pinned` is written to
+queries.json (`src/config.cpp:603`) and read back (`:542`). Two options, and the
+cheaper one is also the reversible one:
+
+- **Stop reading it, leave it in the file.** Harmless: an ignored key, preserved
+  by the unknown-field handling, and a build that reintroduces pinning would
+  find every user's setting intact.
+- **Strip it on the next save.** Cleaner file, and irreversible for anyone who
+  had it set.
+
+Prefer leaving it unless the user asks otherwise. No `kQueriesFormatVersion`
+bump either way: an ignored optional field is not a breaking change.
+
+**Size: S.** Removing a field, two UI affordances and their tests.
+
 ## 91. Double-clicking a thread could open it in its own window
 
 **Observed (user, notes):** "double clicking a message/thread should open it in