4 Commits

Include renames

Author	SHA1	Message	Date
bvandeusenandClaude Opus 5.5	08a2c06b85	docs: api comments say what the endpoints do, not how they came to be (#6277) ... Rewrites the internal/api comment blocks to rule 32: task, milestone and rule ids gone, the stories behind them restated as the constraint they left, stale references corrected (the stream secret is wired from config, the timezone handler already refreshes the scheduler, the Android app is the native client, the design docs cited are not in the repo). Also rewraps comment lines over 80 columns left by the earlier batches. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-23 12:23:58 -04:00
bvandeusenandClaude Opus 4.8	16f76ea707	feat(server): emit playlist.system_rebuilt on daily + manual system-playlist rebuild ... The daily 03:00 scheduler rebuild (and the manual refresh endpoint) replace a user's system playlists + You-might-like rows but published no event, so a client left open across the rebuild served yesterday's snapshot until a manual reload — the stale-tab case behind #968. Add a user-scoped playlist.system_rebuilt event (envelope {kind,user_id,data:{}}) from both the scheduler (bus threaded into NewScheduler) and handleSystemPlaylistRefresh. Clients consume it to invalidate home / system-playlist views and proactively re-pull a stale active queue. Issue #968. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-20 12:59:27 -04:00
bvandeusenandClaude Opus 4.7	d67c0de596	refactor(playlists): #411 R2 — generic registry-driven system endpoints ... Replaces the per-kind refresh/shuffle handlers with one generic pair driven off the kind registry, in lockstep across both clients. Server: - systemPlaylistKind gains Singleton; RefreshableSystemKind(key) exported. for_you/discover singleton; songs_like_artist not. - New generic POST /api/playlists/system/{kind}/refresh and GET /api/playlists/system/{kind}/shuffle ({kind} = raw system_variant). Non-singleton/unknown kind → 404. Deleted playlists_{foryou,discover}_refresh.go and the per-kind shuffle wrappers; serveSystemPlaylistShuffle core kept. - playlistRowView.refreshable: server-derived flag so clients show the refresh affordance generically without hardcoding kinds. Web (not drift-cached → uses the server flag): - refreshSystem(variant) replaces refreshForYou/refreshDiscover; systemShuffle drops the for_you→for-you mapping (raw variant). - PlaylistCard + detail page gate the kebab/Refresh button on playlist.refreshable; label is "Refresh {name}". Tests reworked; obsolete refresh-foryou/discover api tests deleted. Flutter (list tiles are drift-cache-sourced → derive, no migration): - Playlist.refreshable getter = isSystem && variant != songs_like_artist (holds for all current + planned kinds). - refreshSystem/systemShuffle use the raw variant; PlaylistCard + detail screen gate kebab/Regenerate/source-tagging on refreshable so songs_like_artist plays via get() (no by-kind endpoint). Pure-plumbing refactor; CI verifies parity. Next (R3): the five discovery mixes — each a candidate query + one registry entry. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-15 13:21:09 -04:00
bvandeusenandClaude Opus 4.7	e43281d1d0	feat(playlists): #415 stage 2 — rotation-aware shuffle endpoint ... GET /api/playlists/system/{discover,for-you}/shuffle returns the caller's system playlist with tracks ordered: unplayed-this-rotation first (shuffled), then already-heard (shuffled). When the whole snapshot has been heard, ResetRotationState fires and the full list reshuffles fresh. Option A (operator's choice): a separate, intentionally-uncached endpoint. The cached GET /api/playlists/{id} detail path stays pure for "open to view"; this varies per play. Same JSON shape as the detail GET so Stage 3 clients reuse track parsing with no new model. Two explicit static routes per variant mirror the refresh handlers and avoid chi static-vs-param ambiguity under /playlists/system/. Empty/absent snapshot → 200 with empty track list (nothing to play, not an error). Rotation reset failure is non-fatal — still returns a playable reshuffled list. No client wiring yet — Stage 3 makes web + Flutter call this on the play/tile gesture and send `source` on play_started. Handler-level test deferred to Stage 3 (needs the full service+pool harness; the end-to-end path is exercised there). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-15 07:47:57 -04:00