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.