Calendar email support in mxr

The useful lesson from the calendar-email work is easy to miss if you focus on .ics parsing. The bigger move is smaller: make the scheduling object useful inside email, then stop before you accidentally become a calendar app.

Mxr now handles the email-shaped part of scheduling: receive, parse, show, search, preview, send, and record local RSVP state. The implementation remains local-first and provider-agnostic.

What changed

The original plan was directionally right, but its current-state audit drifted. Code now confirms:

• icalendar is used for parsing instead of line-only scanning.
• Calendar metadata includes event, attendee, organizer, raw ICS, warning, viewer status, and update fields.
• calendar_invites persists first-class invite rows.
• CLI, IPC, TUI, web, and bridge surfaces exist.
• has:calendar search exists.
• RSVP send exists for accept/tentative/decline.
• Backfill can recover already-stored messages and attachment-only invites.

mxr invites backfill --format json
mxr invites list --limit 20

What stayed true

The durable parts of the research still hold:

• Email invites should be handled before full calendar sync.
• Raw ICS matters for auditability.
• RSVP must be dry-runnable.
• Attendee identity matching is safety-critical.
• Stale update and organizer replacement checks are trust boundaries, not polish.

mxr invite reply MESSAGE_ID accept --dry-run --format json \
  | jq '{action, attendee_email, organizer_email, warnings}'

New learnings

Attachment-only invites are common enough to deserve a backfill path. Inline text/calendar is not the only real-world shape.

Viewer status should be derived with account identity in mind. A stored PARTSTAT column can be convenient, but it is not automatically "my RSVP" unless the viewer identity is part of the key.

Reply generation and parsing have different risk profiles. Parsing broad input belongs to a library. Generating one narrow METHOD:REPLY shape can be a small audited builder, as long as tests stay close and docs do not overclaim.

Rules automation should lag behind search. It is fine to let users find calendar-bearing mail with has:calendar; it is a separate decision to let rules automate around invites.

Current boundary

Still not in scope: CalDAV, provider calendar APIs, calendar grid, reminders, free/busy, and automatic external event mutation.

That boundary is doing real product work. It lets Mxr improve the email experience without quietly accepting responsibility for the user's calendar.

Repository notes

The repo version of this synthesis lives under docs/calendar-email/synthesis/, with the current code-truth audit at docs/calendar-email/blueprint/02-current-state.md.