feat(email): "Learned this session" preferences strip in dashboard footer

[itomek]

Goal

Surface what the agent has learned about the user's preferences during the current session — priority senders, low-priority senders, category defaults — as a visible strip on the dashboard. This is the smallest visible signal of the trust-arc: the agent shows the user what it has picked up, the user can correct it on the spot. Without it, the agent's adaptation is invisible and feels random; with it, the user can see and tune the behavior.

Why now

Sixth sub-issue under #1007. Lightweight — pure UI on top of the session-preferences subsystem already shipped in PR #995. Lands before persistence (#1007 sub-issue 7) so the visibility loop ("agent says: I learned this; user says: yes / no") is in place by the time persistence flips it to a real adaptive system.

Scope

• A footer strip on the dashboard that reads from the agent's existing _session_preferences (priority senders, low-priority senders, category defaults).
• Three groups of chips, each with a small "remove" affordance per chip:
  • Priority senders — chips for each address; remove → calls existing tool to drop it.
  • Low-priority senders — same shape.
  • Category defaults — chips like "informational → archive"; remove → resets to default.
• A "Clear all" link that calls existing clear_session_preferences.
• Empty-state copy: "I'll learn from your actions during this session." Sets the expectation that this is session-scoped (until sub-issue 7).
• Hover state on each chip displays a brief explanation: where the preference came from (e.g. "you marked as low-priority on May 8") — derives from the session store; doesn't require new logging.

Acceptance

• Footer strip renders below the columns with the three preference groups.
• Removing a chip dispatches the corresponding tool call and the chip disappears.
• "Clear all" calls existing clear_session_preferences and the strip empties.
• Empty-state copy is explicit about the session-scoped nature.
• Reuses the existing preference tools — no new tools, no new API surface.

Out of scope

• Persistent learned preferences (lands with sub-issue 7).
• Behavior-derived inference (e.g. "you archived 6 newsletters from this sender — want to set as low-priority?") — that's a separate UX nudge worth its own issue once the learning loop is in place.

Depends on

• #1010 (the dashboard reads its state from the store; preferences live alongside).

Refs

• Parent: #1007
• Existing preference tools: PR #995 (set_priority_sender, set_low_priority_sender, set_category_default, clear_session_preferences)

[github-actions]

Nicely scoped — this is the smallest possible surface that makes the agent's session adaptation visible, and deferring behavior-derived inference to its own issue keeps it tight. A few notes from a quick pass through the chain:

🟡 Dependency chain status

This sits behind a stack that isn't fully merged yet:

• PR #995 (engine + _session_preferences) is still open / draft — its branch strategy explicitly waits on the memory + 5-agent split PR. The preference tools (set_priority_sender, set_low_priority_sender, set_category_default, clear_session_preferences) will live in src/gaia/agents/email/tools/preference_tools.py once that lands.
• #1008 (dashboard skeleton) and #1010 (in-session store + state machine) are both still open, and feat(email): In-session task store + state machine for dashboard items #1010 is a hard dependency per the body.

So the practical sequencing is #995 → #1008 → #1010 → this. Worth flagging on the umbrella's checklist if anyone tries to pick this up out of order.

🟢 Two small UX questions worth pinning down before implementation

1. Hover-explanation provenance. The body says hover copy should derive from the session store without new logging — but the current _session_preferences schema in PR #995 only stores the value, not the when/from-which-action metadata needed for "you marked as low-priority on May 8". Either the session store needs a source / set_at field added (preferably in feat(email): daily-driver UI pass — pre-scan card, in-chat Connect, session prefs #995 before it merges, since changing the schema after persistence lands in sub-issue 7 is more painful), or this hover copy degrades to a generic "set this session" string. Worth deciding which.

2. Conflict with feat(email): In-session task store + state machine for dashboard items #1010's "respect dismissed" rule. If a user clicks "remove" on a low-priority sender chip mid-session and a refresh later re-classifies that sender as low-priority again from heuristics, the chip will reappear silently. That mirrors the dismissed-item conflict feat(email): In-session task store + state machine for dashboard items #1010 already documents — calling it out here keeps the two consistent ("respect explicit chip removal for the rest of the session" probably).

🟢 Reuse note

The chip + remove-affordance pattern doesn't exist in the webui today — closest analogue is the in-row action buttons in EmailPreScanCard.tsx (also from PR #995). Worth landing the chip as a small reusable component (PreferenceChip) rather than inlining it, since the persistent-preferences UI in sub-issue 7 will want the same primitive.

Ready to pick up once #995 + #1010 land — happy to help draft the chip component once the store interface from #1010 is settled.