Mail UI: threads view for agent-to-agent correspondence

[CameronCrow]

What

Product surface for agent mail (companion to the v1 files-only issue): per-agent mailbox view in Papyrus — thread list, read/unread state, maybe a roster-wide correspondence overview. Deferred from v1 by explicit decision (2026-07-16): v1 ships mail as markdown files in ~/.papyrus/agents/<id>/mail/ surfaced through the existing Agent Files panel, which is enough to audit exchanges.

Why punted

Scoped out during the agent-mail design interview to keep v1 shippable; the mail transport/archive format must stabilize before a UI freezes assumptions about it.

Pointers

• v1 feature (transport, file format, panel group): see the "Agent mail v1" issue — build this strictly on top of the thread-file format it establishes.
• Precedent for a new dashboard surface: the tasks routes under apps/desktop/src/renderer/routes/_authenticated/_dashboard/.

Definition of done

Not yet knowable in detail — first step is a short design pass once v1's file format has been in use: decide thread list vs. unified inbox, unread tracking (file-based vs DB), and whether the human can inject messages into a thread. That design pass is a legitimate first deliverable for whoever picks this up.

[CameronCrow]

Design pass (2026-07-16) — building on the v1 thread-file format from #45 / PR #47

v1 shipped the format this UI freezes against. Recap of the contract:

• One exchange = one markdown file, identical copy in both parties' boxes: asker mail/sent/, recipient mail/inbox/ (plus asker mail/inbox/ for late answers).
• Filename: <iso-stamp>-<from-slug>-to-<to-slug>-<thread-id-8>.md — sortable by time, self-describing.
• Frontmatter: thread, from, to, asked, answered, status (pending | answered | answered-late | timeout | error), depth. Body: ## Question / ## Answer.
• Already surfaced read-only via the Agent Files panel ("Mail" group → file viewer).

Decisions the issue asked for

1. Thread list vs unified inbox → both, one route. A mail dashboard route (precedent: the tasks routes under _authenticated/_dashboard/) showing a roster-wide unified list, dedup'd by thread id (each exchange exists as 2–3 identical files), with a per-agent filter chip. Per-agent-only views already exist for free in the Agent Files panel, so the new surface should be the thing that panel can't do: the cross-roster overview.

2. Unread tracking → file-derived, no DB. Unread = answered timestamp newer than a single mailLastSeenAt watermark persisted in the existing ui-state/settings row, set when the mail route is opened. No per-thread read flags, no frontmatter mutation (the files are an audit trail — the UI shouldn't rewrite them), no new table. If per-thread granularity ever matters, upgrade path is a read: <iso> frontmatter line written by the UI — still no DB.

3. Human injection → punt, with a cheap v2 path. The human already has full terminal access to every agent, which is a strictly better "reply" channel today. When wanted: a compose box that calls the existing mail.ask procedure with a reserved from: user party (server skips the asker-side archive or writes to ~/.papyrus/mail/). Nothing in the v1 format blocks this — from is just a name in frontmatter.

Implementation sketch (when picked up)

• server-core/agent-mail.ts grows a listThreads() (walk roster mail dirs, parse frontmatter, dedup by thread id) exposed as mail.listThreads on both routers (mirror rule).
• Renderer: one route + thread list + reuse the existing markdown file viewer for the thread body. Unread badge on the nav item from the watermark comparison.

Deliberately not building the UI in this pass: the format has existed for hours and the issue's own rationale ("the mail transport/archive format must stabilize before a UI freezes assumptions about it") still applies. Once a few real exchanges have accumulated, the sketch above is a small, well-bounded PR.