# ADR-0008 — Calendar & Outlook .pst integration

- **Status:** Accepted
- **Date:** 2026-06-30
- **Context source:** Design doc §"Calendar Integration", §"Outlook .pst Integration"

## Context

WA enriches meetings with calendar context (title, organizer, attendees) and reads local Outlook
`.pst` backups to build meeting history and suggest speaker names — all local, no cloud sync
required.

## Decision

- **`.pst` reading:** use the Rust **`outlook-pst`** crate (read-only, MS-PST-based) to extract
  calendar appointments and attendees. Fall back to **libpff** (`pffexport`/FFI or a small
  sidecar) for password-protected or edge-case files. PST is **read-only input**; WA never writes
  to it.
- **Live calendar:** abstract behind a `calendar::CalendarSource` trait. Phase 6 ships the PST
  source. Microsoft Graph (with explicit user consent) and local ICS files are future sources
  behind the same trait; Graph is the *one* allowed remote call and only for calendar metadata,
  never meeting content, and only with consent.
- **Reminders:** action items become **local OS notifications** (Windows toast); optional
  calendar entry creation is deferred and, where added, stays local/consented.
- **Participant-aware naming:** attendee names from the selected event populate the speaker-naming
  dropdown (FR-SPK-2), with an "add new name" escape hatch; mappings persist per meeting.

## Consequences

- **Positive:** delivers Granola-style context fully offline from data the user already has;
  trait keeps Graph/ICS additions non-invasive; read-only PST avoids corrupting user mail stores.
- **Negative:** PST parsing is fiddly (encryption, large files, format variance) → keep libpff as
  a fallback and treat parse failures as non-fatal; Graph path (future) introduces OAuth + the
  product's only remote dependency, so it must be strictly opt-in and clearly labeled.

## Revisit if
`outlook-pst` proves insufficient in practice (promote libpff to primary), or users need live
Exchange more than PST (prioritize the Graph source).