diff options
Diffstat (limited to 'docs/superpowers/plans/2026-08-03-post-0.1.0-usability-closed.md')
| -rw-r--r-- | docs/superpowers/plans/2026-08-03-post-0.1.0-usability-closed.md | 46 |
1 files changed, 46 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 0f7181b..7314700 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 @@ -7392,3 +7392,49 @@ draft stayed disabled on a draft selected that way, and the reply family had the same blind spot without a test that could see it. It is now connected to both signals. Reading `currentRowChanged` is safe here for the reason `CLAUDE.md` gives: it answers "which row is current", and no count is read. + +## 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. + +**Closed 2026-08-24** (unreleased). See the status table row for the outcome. |
