All incident data (titles, descriptions, log contents, AI conversations, resolution steps, RCA documents) must be stored locally and at rest must be encrypted. The application cannot rely on OS-level full-disk encryption being enabled.
Requirements:
- AES-256 encryption of the full database file
- Key derivation suitable for per-installation keys (not user passwords)
- No plaintext data accessible if the `.db` file is copied off-machine
- Rust-compatible SQLite bindings
---
## Decision
Use **SQLCipher** via `rusqlite` with the `bundled-sqlcipher-vendored-openssl` feature flag.
---
## Rationale
**Alternatives considered:**
| Option | Pros | Cons |
|--------|------|------|
| **SQLCipher** (chosen) | Transparent full-DB encryption, AES-256, PBKDF2 key derivation, vendored so no system dep | Larger binary; not standard SQLite |
| Plain SQLite | Simple, well-known | No encryption — ruled out |
The `cipher_page_size = 16384` is specifically tuned for Apple Silicon (M-series) which uses 16KB kernel pages — using 4096 (SQLCipher default) causes page boundary issues.
---
## Key Management
Per ADR-005, encryption keys are auto-generated at runtime:
- **Release builds**: Random 256-bit key generated at first launch, stored in `.dbkey` (mode 0600)
- **Debug builds**: Hardcoded dev key (`dev-key-change-in-prod`)
-`bundled-sqlcipher-vendored-openssl` significantly increases compile time and binary size
- Cannot use standard SQLite tooling to inspect database files (must use sqlcipher CLI)
-`cipher_page_size` mismatch between debug/release would corrupt databases — mitigated by auto-migration (ADR-005)
**Migration Handling:**
If a plain SQLite database is detected in a release build (e.g., developer switched from debug), `migrate_plain_to_encrypted()` automatically migrates using `ATTACH DATABASE` + `sqlcipher_export`. A `.db.plain-backup` file is created before migration.