allstarr/docs/README.md

Allstarr documentation

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.
• 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

• Legacy .env import
• Apple download provider
• Spotify lyrics service
• Client compatibility
• Jellyfin v12 music surface

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

1. Describe current behavior only.
2. Link to the owning code instead of duplicating long lists that can drift.
3. Keep deployment choices in operator guides and unfinished work out of public user documentation.
4. Do not document SQLite, Redis, Valkey, AIO images, Compose overlays, bundled extension registries, or automatic legacy-state conversion as supported runtime features.
5. When code and documentation disagree, fix the documentation in the same completed implementation chunk.