bvandeusen
7b91718fc9
The admin overview was just two stat cards. Promotes it to a proper workbench by surfacing the top-5 of each actionable queue with inline handlers, while keeping the dedicated /admin/requests and /admin/quarantine pages as the deep-action surfaces. Changes: - Top stats grow from 2 cards to 3 (requests / quarantine / lidarr). - New "Pending requests" preview list — top-5 rows with inline Approve and Reject buttons that call the same approveRequest/rejectRequest endpoints used on the dedicated page (default profiles, no override modal — that flow stays on /admin/requests for power users). - New "Quarantine" preview list — top-5 rows with three inline actions matching the dedicated page: Resolve (single click), Delete file (two-click confirm with inline "Confirm?" state), Delete via Lidarr (two-click confirm). The two-click confirm avoids modal duplication on the overview while still gating the irreversible operations. - "View all <N> →" link surfaces beneath each preview only when the full queue exceeds the preview limit, pointing to the dedicated page. - Shared toast surface with errorCopy mapping for the same lidarr_* codes the dedicated requests page handles, so failed actions surface meaningful text instead of "unknown". Test fixture migrated from per-test dynamic imports to top-level imports — the previous pattern was producing stale-mock symptoms where mockReturnValue was set after the page bound against the original mocks. 12 tests cover stat counts, empty states, links, each handler binding, the two-click confirm pattern, and the "View all" surfacing rule. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Minstrel
Self-hosted music server with OpenSubsonic compatibility plus an extended API for server-side smart shuffle, a dual-like model (general + contextual), session-aware radio, ListenBrainz scrobble/similarity, and Lidarr integration. Go + Postgres, packaged as a Docker container.
State and intelligence belong on the server, not the client.
Specs
Authoritative v1 scope lives under docs/:
- Server spec — current implementation focus.
- Client spec — Flutter companion app; work starts once the server reaches its Subsonic-compatible baseline.
Development workflow
- Day-to-day work happens on the
devbranch (or feature branches merged intodev). mainis protected — changes land only via pull request fromdev.- Production builds are cut by tagging a release (
v*) offmain.
CI / container image
Forgejo Actions handles:
- Tests on push to
devand on PRs intomain. - Container image build + push to the Forgejo registry on merge to
main(:main) and onv*tags (:<version>).
Task and milestone tracking: Fable (Minstrel project, id 12).
Development
Minstrel has two concurrent dev processes:
- Backend:
docker compose up— starts Postgres and Minstrel on:4533. - Frontend:
cd web && npm install && npm run dev— Vite dev server on:5173with HMR.
The Vite dev server proxies /api/* and /rest/* to the backend on :4533,
so session cookies work correctly when the SPA is loaded from the Vite origin.
Production build
docker build -t minstrel . runs the SvelteKit build inside a node stage,
copies the output into the golang stage, and //go:embeds it into the
final binary. The resulting container serves the SPA from / alongside the
API surfaces. No separate static-file server is required.