Skip to content

feat(email): one rules screen — learned patterns nested under their rule - #177

Merged
vjvarada merged 2 commits into
mainfrom
email-rules-view-unification
Jul 23, 2026
Merged

feat(email): one rules screen — learned patterns nested under their rule#177
vjvarada merged 2 commits into
mainfrom
email-rules-view-unification

Conversation

@vjvarada

Copy link
Copy Markdown
Contributor

What

The consolidation the user asked for — "everything can be seen in one place" — done at the view layer, keeping the stores separate (the approval gate #96/#97 and per-pattern provenance survive).

  • Each rule card in the Rules tab now discloses its learned patterns: an expandable "N learned patterns · M pending review — filed without the AI" line (amber when review is owed). Expanded rows are the same PatternRow component the Settings screen uses (now exported), with the same verbs: approve/reject for pending auto-learned ones, reject/forget for in-force ones. Rejected patterns stay records-only in Settings.
  • The tab header now states the real execution order: patterns file pinned senders first (no AI) → the AI matches the plain-English rules → whatever nothing matches shows as Uncategorized, whose pill/Fix flow (fix(email): Uncategorized is a state, not a label — recategorize-or-fix on click #175) teaches a new pattern or rule.
  • Fixes stale "Reply" name in the empty-state copy (missed by the feat(email): rename Reply -> Needs Reply everywhere (mig 92 + ingest canonicalisation) #168 rename).

Frontend-only; listRulePatterns already returns rule_id, so no backend change. tsc --noEmit clean; no import cycle (SettingsTab does not import RulesTab).

🤖 Generated with Claude Code

vjvarada and others added 2 commits July 23, 2026 09:11
The engine already runs one pipeline (patterns deterministically first, AI
classifier second), but the VIEW was split: rules in the Rules tab, the
patterns that pre-empt them in Settings. Now each rule card discloses its own
learned patterns (with pending-review state, approve/reject/forget inline —
the same PatternRow the Settings screen uses, so the surfaces can't drift),
and the tab header states the actual execution order, ending at the
Uncategorized pill / Fix flow that teaches new ones.

Storage stays separate on purpose: merging patterns into rule conditions
would lose the approval gate (#96/#97) and the per-pattern provenance.

Also fixes stale "Reply" in the empty-state copy (missed in the #168 rename).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…iss from v2

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@vjvarada
vjvarada merged commit cfd6bce into main Jul 23, 2026
3 checks passed
@vjvarada
vjvarada deleted the email-rules-view-unification branch July 23, 2026 03:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant