1 files changed, 43 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 85e6ce8..f10a301 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
@@ -95,6 +95,7 @@ taking that too literally.
 | 45 | Two Sync buttons, and only one of them works properly | correctness | S | **done** |
 | 46 | `uiStateSurvivesARestart` fails under the offscreen platform | testing | XS | **done** |
 | 47 | The query bar looks unfinished, and cannot be cleared by mouse | presentation | XS | **done** |
+| 48 | Removing a tag suggests every tag, not the thread's own | workflow | XS | open |
 
 Sizes are rough: XS under an hour, S a sitting, M a session.
 
@@ -2361,6 +2362,48 @@ user as acceptable; suppressible if it becomes annoying in daily use.
 **Verification:** by hand. The tests do not click the ✕, which is a mouse path.
 The user confirmed the icon renders correctly, is themed, and clears the field.
 
+## 48. Removing a tag suggests every tag, not the thread's own
+
+**Observed (user, 2026-08-06):** "when removing a tag from a thread using the
+input box, I get suggested all tags, not only those relevant to the message
+being edited."
+
+**Cause (verified in code):** both fields share one completer setup.
+`TagDialog`'s constructor loops over `{ m_addEdit, m_removeEdit }` and builds
+`new QCompleter(knownTags, edit)` for each (`src/tagdialog.cpp:163-164`), and
+`knownTags` is every tag in the database. That is right for Add, where the point
+is to reach any tag and even create one, and wrong for Remove, where the only
+tags that can be removed are the ones the selected threads already carry.
+
+**The data is already in the dialog.** The constructor takes `currentTags`, a
+`QHash<QString, int>` of tag to how many selected threads carry it
+(`src/tagdialog.h:66-67`), and uses it at `:212` to render the existing-tag
+display. It is simply never given to the remove field's completer, so this needs
+no new plumbing and no worker query.
+
+**Approach.** Build the two completers from different vocabularies rather than
+in one loop: `knownTags` for Add, `currentTags.keys()` for Remove.
+
+**Constraints.**
+
+- **Keep the setWidget/prefix machinery exactly as it is.** Both fields hold a
+  comma-separated list, and `QLineEdit::setCompleter` is the documented trap
+  this dialog already works around, hit twice in this codebase. Only the
+  candidate list changes; the wiring does not.
+- **Completion stays a suggestion, not a whitelist.** The dialog's own comment
+  records that a tag absent from the list is exactly what it exists to create.
+  For Remove that matters less, but typing a tag not in the list must still be
+  possible rather than blocked, so nothing may start validating input against
+  the candidates.
+- On a multi-thread selection `currentTags` is the union across the selection,
+  with counts. That is the right set to offer, since removing a tag two of three
+  threads carry is meaningful. Do not filter to tags every thread has.
+
+**Verification:** a test can construct the dialog with a known `currentTags` and
+assert the remove field's completer offers only those. The keys must be typed,
+not `setText()`, since `setText` does not drive a completer at all, which
+`CLAUDE.md` records.
+
 ## Deferred, unsized, or split out
 
 Items noted while triaging but not part of the original list. Same numbering