# ADR-0006 — Storage: SQLite index + on-disk audio/transcript files

- **Status:** Accepted
- **Date:** 2026-06-30
- **Context source:** Design doc §"Recording Persistence and Storage", §"Crash Recovery"

## Context

WA stores recordings, transcripts, notes, speakers, participants, tags, and meeting metadata
locally; needs fast list/filter/search; must survive crashes; and must let users choose the base
directory, set retention, and export.

## Decision

- **Large/opaque artifacts on the filesystem:** audio (`.wav`/compressed) and the canonical
  transcript JSON live as files under the storage root, one folder per meeting.
- **Index & relations in SQLite** (via `sqlx`): meetings, speakers, participants, tags, action
  items, and file paths; **FTS5** virtual table over transcript/notes text for full-text search
  (FR-SEARCH-1).
- **Audio is the source of truth.** Audio is flushed to disk during capture; transcript/notes are
  derived and regenerable. Auto-save transcript/notes at intervals; on startup, detect meetings
  with audio but no finalized transcript and offer recovery (FR-REL-1).

Default root: `%LOCALAPPDATA%\WhispAssist` with per-meeting subfolders; user-configurable base
directory and retention policy (size cap / age cap) in Settings (FR-STORE-2).

## Consequences

- **Positive:** embedded, serverless, zero-config; FTS5 covers search; files keep the DB small and
  make export/backup a folder copy; crash recovery is straightforward because audio persists first.
- **Negative:** must keep DB rows and files consistent (transactional writes + a reconcile pass on
  startup); retention enforcement is a background job that must respect "audio is source of truth"
  (never orphan a meeting's audio while its transcript is mid-generation).
- Optional at-rest encryption (NFR-SEC-3) can wrap the storage root and/or use SQLCipher; deferred
  to Phase 8.

## Revisit if
We need multi-device sync (would change the data model and conflict story) — out of scope for the
local-only product.