kami
755de34501
The entire admin surface of the SPA had been dead since auth landed (5ed8d9e/3bc9f2d). nginx.conf.template injected only `Authorization: Bearer ${MUZICK_API_KEY}` for all of /api, docker-compose passed only MUZICK_API_KEY to the frontend container, and app.ts requires token === adminKey for /api/admin/*. The two keys differ, and services/api.ts sets no headers of its own. All 10 admin call sites were affected: the Jobs page polled 403s every 3s/5s forever and rendered a blank Overview with no error state, and every Settings library action (Scan, Reindex, Reprocess artists, Re-enrich, Duplicates merge) silently failed. Three changes, each necessary: - a `location /api/admin/` block injecting the admin key - the Dockerfile envsubst list widened to include MUZICK_ADMIN_KEY, without which the new variable substitutes to empty and the header becomes a bare "Bearer" - MUZICK_ADMIN_KEY passed to the frontend service in docker-compose nginx selects the longest matching prefix regardless of block order; verified empirically in a throwaway nginx:stable-alpine running the real envsubst output against a stub that echoes $http_authorization: /api/admin/queue-stats -> Bearer ADMINKEY456 /api/admin/duplicates/merge -> Bearer ADMINKEY456 /api/tracks -> Bearer APIKEY123 /api/health -> Bearer APIKEY123 All 10 call sites use /admin/... under the axios /api baseURL and none request bare /api/admin without a trailing slash. Also gives the Jobs page an error state: a banner that names a 401/403 as a missing or wrong admin key, a Retry button, "Loading queue stats..." in place of a blank Overview, and refetchInterval returning false once the query has errored so it stops hammering a failing endpoint. Deletes frontend/nginx.conf — unreferenced by the Dockerfile (confirmed by grep) and the insecure variant of the template. Worth noting and not addressed here: the outer LAN-only proxy already forges credentials for everything reaching /api, so this key split buys no real security while having cost the whole admin surface. Collapsing to one key would be simpler. REVIEW-2026-07-30.md finding 2. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
muzick
A high-performance, distributed music orchestration and recommendation platform.
Overview
muzick is designed to manage a local music library while providing an "infinite vibe" listening experience. It bridges the gap between a local filesystem and advanced discovery engines through a tiered recommendation architecture.
Tech Stack
Frontend
- Framework: React
- Routing: TanStack Router
- Data Fetching: TanStack Query (with Look-ahead Buffering)
- State Management: Zustand (for Session/Vibe state)
- Styling: CSS Variables (Customizable Themes)
Backend
- Runtime: Node.js / TypeScript
- Framework: Fastify
- Task Queue: BullMQ (via Redis)
- Search: Typesense
Infrastructure & Data
- Database: PostgreSQL (Source of truth for metadata, relationships, and session state)
- Cache/Queue: Redis
- Audio Analysis: Essentia (via Worker processes)
- External Metadata: MusicBrainz, Discogs, LRCLib, Cover Art Archive
Core Concepts
- The Rolling Vibe: A continuous, evolving stream of music that uses a "Rolling Window" of tracks. It interleaves owned library tracks with high-probability "probation" tracks (external discoveries).
- The Dislike Lifecycle: A multi-stage state machine that protects users from accidental deletions while ensuring the library stays clean.
- Tiered Similarity: Instant metadata-based matches, followed by deep audio-feature similarity.
Getting Started
Prerequisites
- Docker & Docker Compose
Running Locally
docker-compose up -d