feat(email): Triage Dashboard route + 3-column skeleton

[itomek]

Goal

Land a visible Triage Dashboard surface in the Agent UI immediately — even with placeholder data — so the dashboard frame can be dogfooded and the rest of the umbrella's sub-issues fill it in.

Why now

First sub-issue under #1007. Per the umbrella's "fastest dashboard visibility first" build order, this lands the bare surface before any data wiring or state work. The frame appears, the user can navigate to it, the empty states are clear about current limitations. Ships in days, unblocks every item that follows.

Scope

• A new top-level surface for the Email Triage agent in the Agent UI. Implementation choice (new route under the existing app router vs a tab inside the agent's chat view) follows whatever pattern the Agent UI already uses for agent-specific surfaces — pick the smallest delta.
• Three-column layout: Surfaced / Drafted / Archived this session.
• Empty states with explicit copy: this is a v0; data populates when you Refresh; persistence and event triggers land in follow-ups.
• A header with: agent name + version, "Refresh" button (no-op for now, wired in the next sub-issue), session-state indicator (e.g. "Updated never").
• Layout responsive enough that columns stack on narrow viewports.
• Reuse the existing styling tokens (--accent, --bg-section, etc.) so the dashboard reads as part of the same product as the chat surface.

Acceptance

• Selecting the Email Triage agent shows a way to switch from Chat to Dashboard (tab, segmented control, or whatever the Agent UI's convention is).
• Dashboard route renders the three columns plus empty-state copy with no console errors.
• Empty-state copy explicitly notes the v0 limitations (no persistence, manual refresh).
• Refresh button is present but visibly disabled or marked "wired in next sub-issue" — no fake loading states.
• CSS lives next to the new component(s) under src/gaia/apps/webui/src/components/email/ (matches PR #995 layout).
• No backend changes — this issue is frontend-only.
• npm run build clean; existing chat surface unaffected.

Out of scope

• Loading any real data (next sub-issue).
• State machine / task store (sub-issue 3).
• Drafted/calendar/preferences columns (sub-issues 4–6).
• Persistence (sub-issue 7).
• Streaming progress (sub-issue 8).
• Event triggers / background watcher (sub-issue 9).

Depends on

• Nothing — this is the first build-order sub-issue.

Refs

• Parent: #1007
• Engine PR (provides the agent registration + connector wiring this surface will sit on top of): #995

[github-actions]

Thanks for filing this — the build-order rationale (visible frame first, data later) is the right call for dogfooding. A few concrete pointers for whoever picks this up:

Existing UI surface conventions

The Agent UI has no client-side router today — navigation is Zustand state in src/gaia/apps/webui/src/stores/chatStore.ts plus conditional renders in src/gaia/apps/webui/src/App.tsx. The two existing patterns for non-chat surfaces are:

• Full-screen swap — showSettings flag swaps <SettingsPage /> for the chat view at App.tsx:517-536.
• Overlay panels — showDocLibrary / showFileBrowser use <AnimatedPresence> overlays at App.tsx:539-544.

Neither matches the "tab inside an agent's chat view" pattern the issue mentions — that pattern doesn't exist yet, so picking it would be net-new infrastructure rather than the smallest delta. Suggest going with a tab/segmented-control inside ChatView.tsx that only renders when activeAgentId === 'email' — keeps the surface scoped to the agent, no new top-level state, no router introduction. Worth confirming with @itomek before implementing though, since the umbrella's vision is dashboard-as-default-landing eventually (#1007 acceptance), which may favor a top-level swap so the dashboard can replace WelcomeScreen for the email agent later.

🟡 Dependency on PR #995 worth flagging explicitly

The acceptance criterion says "CSS lives next to the new component(s) under src/gaia/apps/webui/src/components/email/ (matches PR #995 layout)" — but #995 is still open and that directory doesn't exist on main yet. The issue lists "Depends on: Nothing" but in practice there's a soft dependency: either #995 lands first (creates the email/ dir + EmailPreScanCard.tsx neighbours), or this PR creates the directory itself and accepts a likely merge conflict on the CSS file layout.

Worth either (a) waiting for #995, or (b) calling out in this PR's description that it bootstraps the email/ directory and #995 will need to rebase. Latter is fine if #995's reviewers are slow.

Detecting "Email Triage agent is active"

activeAgentId lives in chatStore and is synced to the current session's agent_type at App.tsx:434-441. Gate the dashboard surface on activeAgentId === 'email' — the agent ID matches the registry key in src/gaia/agents/registry.py.

Empty-state copy honesty

Strongly +1 on "no fake loading states" in the acceptance. The current ConnectionBanner and SystemStatus UX trains users to trust those indicators, so a fake spinner on Refresh would actively erode that trust. A disabled button with hover tooltip ("Wired in #1009") is the right call.

Reusable styling tokens

CSS variables to lean on (defined in src/gaia/apps/webui/src/index.css and component-level CSS): --accent, --bg-section, --bg-card, --text-primary, --text-secondary, --border-subtle. Check SettingsPage.css and AgentManager.css for column-layout precedents.

Test plan suggestion

npm run build + npx tsc --noEmit in src/gaia/apps/webui are the must-runs (per #995's checklist). For the responsive-stack acceptance criterion, a manual viewport check at 480px / 768px / 1280px is enough — no need for new automated tests on a placeholder surface.

cc @itomek for the tab-vs-route call before implementation kicks off.

[itomek]

Closing as not planned.