User and operator guides describe shipped behavior. Contributor assessments explicitly distinguish current implementation from proposed work. Start with one audience and follow links to the owning document instead of reading the whole tree.

Start here

User guide: dashboard map, setup order, imports, playlists, cache, and Intelligence.
Architecture overview: runtime boundaries and code ownership.
Unified music service plan: accepted primary release journeys, canonical catalog direction, keep/modify/shelve decisions, and implementation gates.
Jellyfin and provider routing plan: accepted first-use-case matching, route order, audio quality, fallback, and live qualification contract.
Music ecosystem reference ledger: pinned upstream projects, reusable lessons, license boundaries, and rejected ideas.
Configuration: deployment-owned values, durable settings, and secrets.
Deployment profiles: install, update, optional services, backup, and restore.
Storage: PostgreSQL ownership, migration, backup, and recovery.
Extension SDK v1: package, capability, permission, and account contracts.

Operator guides

Contributor guides

Repository agent guide
Contributing
WebUI design system
Test and qualification tools
Provider capability module
Release readiness assessment: dated feature inventory, code-churn evidence, and proposed first-release gates; not a shipped-support contract.

Documentation rules

User and operator guides describe current behavior only. Contributor plans must lead with a visible status and must not read like shipped setup instructions.
Link to the owning code instead of duplicating long lists that can drift.
Keep deployment choices in operator guides and unfinished work out of public user documentation.
Do not document SQLite, Redis, Valkey, AIO images, Compose overlays, bundled extension registries, or automatic legacy-state conversion as supported runtime features.
When code and documentation disagree, fix the documentation in the same completed implementation chunk.