Architecture Decision Records

[!WARNING] Architecture Decision Records (ADRs) capture historical design decisions at a specific point in time. As the system evolves, the implemented source code may diverge from the original ADR. The current source code is always the single source of truth. - ADR-0001: Use uv as Python Package and Project Manager - ADR-0002: Use pyproject.toml for Configuration and Dependencies - ADR-0003: Frontend Architecture ("The Modern Monolith") - ADR-0004: Use Podman instead of Docker - ADR-0005: Separation of Immutable Code & Mutable State ("Two-Worlds") - ADR-0006: Host Bind Mounts as Default Persistence Strategy - ADR-0007: Rootless Podman & OS Compliance - ADR-0008: Domain-Driven Workspace Isolation - ADR-0009: Zero-Trust Data Sharing Policy - ADR-0010: Naming Conventions - ADR-0011: Audio Recording Strategy (Raw vs Processed) - ADR-0012: Use Pydantic for Data Validation - ADR-0013: Tier 2 Container Management — Podman-Only with podman-py - ADR-0014: Dual Deployment Strategy — Compose (Dev) / Quadlets (Prod) - ADR-0015: NVMe-Only Storage Policy - ADR-0016: Hybrid YAML/DB Profile Management - ADR-0017: Service State Management — Desired vs. Actual State - ADR-0018: Worker Pull Orchestration — Self-Service Analysis via DB Polling - ADR-0019: Unified Service Infrastructure — SilvaService Pattern - ADR-0020: Resource Limits & QoS — Protecting Data Capture Integrity - ADR-0021: Frontend Design System — Tailwind CSS + DaisyUI + ECharts + Wavesurfer.js - ADR-0022: Live Log Streaming — Podman Logs via Redis SSE - ADR-0023: Configuration Management — YAML Seed, DB Settings, Users Table - ADR-0024: FFmpeg Audio Engine — Replacing sounddevice/soxr with FFmpeg - ADR-0025: Recordings Table — Standard PostgreSQL Table (No Hypertable)