pastilhasandClaude Opus 4.8
7a966c780e
Mirrors the existing per-user music state (favorites / now-playing): Postgres tables + query layer + REST endpoints on the music router, all scoped to the caller's user id and served directly by the platform (not proxied to the user-stateless sidecar). Item `key`s are opaque track homePaths, same contract as favorites — the server never interprets them. - schema: music_playlists (name unique per user) + music_playlist_items (0-based position, dupes allowed, cascade delete). - queries: get/create/rename/delete playlists; add (append) / set (replace, covers reorder+remove) items; every mutation ownership-checked; item ops in a transaction that also bumps the playlist updatedAt. - router (/api/music, before the catch-all proxy): GET/POST /playlists, GET/PATCH/DELETE /playlists/:id, POST/PUT /playlists/:id/items. 409 on name collision, 404 on a playlist that isn't the caller's. - migration 0002 (also backfills music_favorites/now_playing into the snapshot, which were originally applied via a direct db:push). Applied to the DB. Verified end-to-end against the live DB: create, dupes, ordering, append, replace/reorder, ownership scoping, rename, counts, delete — all pass. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>