diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/superpowers/plans/2026-08-03-post-0.1.0-usability-closed.md | 63 | ||||
| -rw-r--r-- | docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md | 81 |
2 files changed, 82 insertions, 62 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 c24ba23..ef5c68f 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 @@ -5461,3 +5461,66 @@ that a green suite endorsed a defect a screenshot found. **Confirmed by the user:** "one change sent now that the sync has finished. And the tag I added, sticked to the message." + +## 92. Nothing distinguishes a tag written by a rule from one the user applied + +**Observed (user, notes):** "should the UI allow to discriminate when a message +has been tagged by a rule?" + +**Clarified by the user, 2026-08-15**, including the doubt: "I want a small +visual hint that an email has been tagged by a rule vs tagged by me, but I'm +questioning the utility of such a hint." + +That is the expensive half of the two this item used to hold. "Tagged by a rule +vs tagged by me" is per-MESSAGE provenance, and the information does not exist +anywhere today: a tag written by the `post-new` hook is an ordinary notmuch tag, +indistinguishable from one applied by hand. The UI cannot show what nothing +records, so the hint costs a format change before it costs any pixels. + +**What it would take**, and this is why the user's own doubt is the right +instinct: + +- A marker the hook writes beside every tag it applies, either an extra tag per + rule (`rule:justeat`) or a field in the shared file. Both are two-repo changes + under "Changing the shared rule format" in `CLAUDE.md`, against a hook running + every ten minutes on real mail. +- Retroactively, nothing. Every tag already on every message stays unattributed + forever, so the hint is blank on the entire existing Maildir and fills in only + as new mail arrives. A hint that is absent on most mail teaches the user to + ignore it. + +**A cheaper question that may be the real one.** If what the user actually wants +to know is "why does this message carry this tag", that is answerable with no +stored provenance at all: the rules name their tags, so the UI can say which +rule WOULD tag a given message, read from `~/.config/mailrules/rules.json` at +the moment it is asked. No format change, no hook change, nothing to backfill, +and it works on mail tagged before the feature existed. It answers "a rule +writes this tag" and never "a rule wrote THIS one", which is a weaker claim and +an honest one. + +**Approach.** Put the cheaper question to the user before building either. If +the answer is that the per-message distinction is genuinely wanted, this is an M +spanning both repos and should be specced, not slipped into a session. + +**Constraint.** The hook is not this repo's to weaken. If provenance is wanted, +the marker has to be something the hook can write without touching `unread` or +`inbox`, and without consuming `tag:new` when the rules fail to load. + +**Postponed, 2026-08-15, at the user's own reading of it:** "let's skip 92 for +now. I don't see the utility, so I don't really know how to answer." + +That is the right call and worth recording as more than a deferral. The +clarification the user gave first ("I want a small visual hint that an email has +been tagged by a rule vs tagged by me, but I'm questioning the utility of such a +hint") names the per-message version, which is the expensive one: a two-repo +format change against a hook that runs every ten minutes on real mail, for a +hint that stays blank on every message already tagged. A feature whose own +requester cannot say what it is for should not be built, and this one costs a +schema before it costs a pixel. + +The cheaper substitute stays recorded above and needs no format change if the +question ever turns out to be "why does this message carry this tag": the rules +name their tags, so the UI can answer from `~/.config/mailrules/rules.json` at +the moment it is asked, retroactively and with nothing stored. Reopen from +there, not from the provenance design, unless real use shows the per-message +distinction is what is wanted. 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 e55bad4..2e5e8c9 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 @@ -155,8 +155,8 @@ taking that too literally. | 86 | A right-click search can replace or narrow, but never exclude | workflow | S | **done** 2026-08-14, unreleased; see `specs/2026-08-14-exclude-from-search-design.md`. Follows 85. The `extend` bool became a `SearchMode` enum across four signatures | | 89 | A sync moves the list under the user's hands, and the auto-sync skips rather than retries | workflow | XS | **done** 2026-08-15, unreleased. The timer half only: a skipped auto-sync re-arms instead of giving up. The list-churn half is **dropped**, not built: the user resolved it as a mental-model question, an Unread view is SUPPOSED to be volatile | | 90 | A saved-query button clears the account selection | workflow | S | **folded into 93** 2026-08-15. Not fixed in place: the button that misbehaves stops being a saved query at all. See `specs/2026-08-15-builtin-filters-design.md` | -| 91 | Double-clicking a thread should open it on its own | workflow | S | open, specified 2026-08-15. NOT a second window: a drill-down to that one thread, the same result an `id:` query gives. One decision left, how the user gets back | -| 92 | Nothing distinguishes a tag written by a rule from one the user applied | information | M | open, specified 2026-08-15. The user wants per-MESSAGE provenance, which nothing records: a two-repo format change, blank on all existing mail. Put the cheaper "which rule would tag this?" to the user first | +| 91 | Double-clicking a thread should open it on its own | workflow | S | open, fully specified 2026-08-15 and ready to build. A drill-down to that one thread, the same result an `id:` query gives. Nothing is built for getting back: the filter buttons already are that | +| 92 | Nothing distinguishes a tag written by a rule from one the user applied | information | M | **postponed** 2026-08-15 at the user's request: "I don't see the utility, so I don't really know how to answer." Needs per-MESSAGE provenance nothing records, a two-repo format change blank on all existing mail. Reopen only if the need appears in use | | 93 | The query buttons are whatever the user pinned, not a designed set of filters | workflow | M | **done** 2026-08-15, unreleased; see `specs/2026-08-15-builtin-filters-design.md`. Absorbs item 90. Four built-in filters composing with the account dropdown; the user's own queries unpinned, never deleted | | 95 | A query in the overflow menu cannot be run | defect | XS | **done** 2026-08-15, unreleased. Pre-existing and not caused by 93: the entry's action owned a submenu, and Qt emits no `triggered` for those, so the connection had never fired. Surfaced because 93 moved every query into the menu | | 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 | @@ -517,66 +517,23 @@ the query bar: `SearchTerm` builds the `id:` query and `runQuery()` runs it. message row, `thread:` for a thread row, built through `SearchTerm` so the quoting rules stay in one place. -**Decide before building: how the user gets back.** A drill-down that cannot be -reversed is a trap, and this is the only real design question left in the item. -Three candidates, and they are not equivalent: - -- Esc. Already means "clear the pane", then "clear the selection". A third - meaning is one too many. -- A Back action, with its own binding and toolbar button. Honest, and the only - option that survives a drill-down FROM a drill-down. -- Restoring the previous query text. Cheapest, and wrong the moment the user - edits the bar while drilled in. - -**Constraint.** `runQuery()` clears the undo stack, by design, since undo -entries refer to rows that are about to be discarded. A drill-down is still a -query, so a double-click would silently discard undo history. Either accept it -and say so, or the drill-down is not a query at all but a filter over the model, -which is item 40's machinery and makes this M rather than S. - -## 92. Nothing distinguishes a tag written by a rule from one the user applied - -**Observed (user, notes):** "should the UI allow to discriminate when a message -has been tagged by a rule?" - -**Clarified by the user, 2026-08-15**, including the doubt: "I want a small -visual hint that an email has been tagged by a rule vs tagged by me, but I'm -questioning the utility of such a hint." - -That is the expensive half of the two this item used to hold. "Tagged by a rule -vs tagged by me" is per-MESSAGE provenance, and the information does not exist -anywhere today: a tag written by the `post-new` hook is an ordinary notmuch tag, -indistinguishable from one applied by hand. The UI cannot show what nothing -records, so the hint costs a format change before it costs any pixels. - -**What it would take**, and this is why the user's own doubt is the right -instinct: - -- A marker the hook writes beside every tag it applies, either an extra tag per - rule (`rule:justeat`) or a field in the shared file. Both are two-repo changes - under "Changing the shared rule format" in `CLAUDE.md`, against a hook running - every ten minutes on real mail. -- Retroactively, nothing. Every tag already on every message stays unattributed - forever, so the hint is blank on the entire existing Maildir and fills in only - as new mail arrives. A hint that is absent on most mail teaches the user to - ignore it. - -**A cheaper question that may be the real one.** If what the user actually wants -to know is "why does this message carry this tag", that is answerable with no -stored provenance at all: the rules name their tags, so the UI can say which -rule WOULD tag a given message, read from `~/.config/mailrules/rules.json` at -the moment it is asked. No format change, no hook change, nothing to backfill, -and it works on mail tagged before the feature existed. It answers "a rule -writes this tag" and never "a rule wrote THIS one", which is a weaker claim and -an honest one. - -**Approach.** Put the cheaper question to the user before building either. If -the answer is that the per-message distinction is genuinely wanted, this is an M -spanning both repos and should be specced, not slipped into a session. - -**Constraint.** The hook is not this repo's to weaken. If provenance is wanted, -the marker has to be something the hook can write without touching `unread` or -`inbox`, and without consuming `tag:new` when the rules fail to load. +**How the user gets back: nothing is built for it.** Answered by the user, +2026-08-15: "I didn't think of a back action, usually I'd go back to a known +list like unread or inbox at that point." The filter buttons are already that, +and they are one click away in every view. A Back action, a history stack and a +restore-the-previous-query scheme were all drafted and are all unnecessary. + +That collapses the only open question in this item. A drill-down is an ordinary +query, entered by gesture instead of by typing, and it is left the way every +other query is left. + +**The undo-stack note below therefore stops being a concern.** `runQuery()` +clears the undo stack because its rows are about to be discarded, and a +drill-down discards them exactly as a typed query does. The user already +expects that from the query bar, so the gesture inherits a behaviour that is +consistent rather than surprising. No filter-over-the-model alternative is +needed, and the item stays S rather than growing into item 40's machinery. + ## Deferred, unsized, or split out |