2 files changed, 61 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
diff --git a/docs/superpowers/specs/2026-08-15-builtin-filters-design.md b/docs/superpowers/specs/2026-08-15-builtin-filters-design.md
index cd22bab..d44502e 100644
--- a/docs/superpowers/specs/2026-08-15-builtin-filters-design.md
+++ b/docs/superpowers/specs/2026-08-15-builtin-filters-design.md
@@ -143,6 +143,22 @@ class of complaint item 89 is about. And the account combo is a plain
 `QComboBox`, so a keyboard user arrowing through it would fire a query per
 account passed on the way to the one they wanted.
 
+## Ordering, and why it is temporary
+
+The four filters and the user's remaining pinned queries share one row, so
+something has to order them. **Filters first, in the fixed order Unread, Inbox,
+Flagged, Sent; the user's pinned queries after them, keeping their own order.**
+
+Do not build anything configurable for this. The arrangement is transitional:
+item 94 removes `pinned` entirely once the user has confirmed the four buttons
+cover what they use, after which the row is filters only and there is nothing
+left to order. A settings surface for a mixed row would be built and deleted
+inside two items.
+
+`pinned` itself is untouched by this item and stays exactly as it is. The user's
+own queries are unpinned as a migration step, which is a change to their data,
+not to the mechanism.
+
 ## Constraints
 
 - **One rule across all three surfaces.** Buttons, the "more queries" menu and