docs(backlog): settle item 91's open question, postpone item 92

91 needed one decision, how the user leaves a drill-down, and the answer is that
nothing is built for it: "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 already
are that and are one click away in every view, so the Back action, the history
stack and the restore-the-previous-query scheme are all unnecessary. That also
retires the undo-stack concern: a drill-down clears the stack exactly as a typed
query does, which is the behaviour the user already expects from the query bar.
The item is now fully specified and ready to build at S.

92 is postponed at the user's request: "I don't see the utility, so I don't
really know how to answer." The clarification that preceded it named the
per-message version, which needs provenance nothing records, costs a format
change across both repos against a hook running on real mail every ten minutes,
and stays blank on every message already tagged. A feature whose requester
cannot say what it is for should not be built. The cheaper substitute is
recorded beside it for if the question ever turns out to be "why does this
message carry this tag", which rules.json can answer at read time with nothing
stored.

Section moved to the closed-items file on this commit, per CLAUDE.md.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

1 files changed, 63 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 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.