35 Commits

Include renames

Author	SHA1	Message	Date
bvandeusenandClaude Opus 5	eff3d88931	fix(recommendation): make the candidate draw reproducible, not accidentally so ... Four arms of the candidate query ended in a bare `ORDER BY random()` with no seed: similar_artists, likes_overlap, coplay_artists and random_fill. Such an arm returns a STABLE set only while its LIMIT exceeds the rows eligible for it — at that point it returns all of them and the order stops mattering, because scoreAndSortCandidates sorts by track id before drawing jitter. Below that threshold it returns a random SUBSET, and two builds on the same day draw different ones. So daily determinism held BY ACCIDENT, and only for libraries smaller than the limits. Any real library is larger, which means same-day rebuilds have been producing different mixes since those arms were written — invisible, because a mix that changes after a refresh looks like a feature rather than a broken promise. Found by breaking it: cutting RandomFill to 10 while tuning Songs-like turned TestBuildSystemPlaylists_DailyNonceDeterminism red. That test seeds ~20 tracks against a default RandomFill of 30, so its determinism came from the limit exceeding the library, not from the code being right. It is now a real guard. The arms order by md5(id || $12) instead. The CALLER decides what that means, which is the point: system mixes pass a per-(user, day) seed and get the determinism they promise, radio passes a fresh value per request and keeps varying, which is what a radio should do. Same shape the browse queries in this file already use (`md5(id::text || current_date::text)`) — existing idiom, not a new one. This also unblocks the trim that #3881 wanted and could not have. Shrinking a randomly-ordered arm was what broke membership; a seeded one takes a smaller but REPRODUCIBLE slice. Songs-like's seed-independent share drops from 29% to 12%, which was the original intent before determinism forced it back to 20%. TestSongsLikeLimits_DoNotShrinkTheUnseededRandomArms is DELETED rather than kept passing. It existed to stop anyone trimming those arms while the ordering was broken; the ordering is fixed, so the constraint is gone and a guard enforcing it would now forbid correct code. Was filed as blocked on tooling. It was not: `make generate-go` runs sqlc as a pinned Go tool and is the same path CI takes. One thing worth knowing for next time: three files in internal/db/dbq are owned by root, left by `make generate` running sqlc in Docker. sqlc errored on the first it could not write. They are untouched by this change and the regeneration of recommendation.sql.go completed, but `make generate` will keep failing until they are chowned. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SQ31KQpYbStyK5y58UmPLH	2026-09-11 08:44:33 -04:00
bvandeusenandClaude Opus 5	721154847e	fix(recommendation): size the candidate pool to the library ... Operator, 2026-09-10: "is the pool that we draw from somehow scaled to the amount of music in the library... my earlier understanding of the tuning and work may have been skewed by what was in my library." It was not. DefaultCandidateSourceLimits returns what its own comment calls "the v1 hardcoded constants per spec" — ~170 candidates for a 500-track library and a 100,000-track one alike. The pool therefore samples a shrinking FRACTION of a growing collection: 17% of 1,000 tracks, 1.7% of 10,000, 0.17% of 100,000. RandomFill, whose whole job is exploration, becomes a thinner and noisier slice at exactly the moment a library gets more diverse — which is the "starting to feel weird" being reported. 1,000 tracks -> pool 170 (unchanged) 5,000 -> pool 170 (unchanged) 20,000 -> pool 280 80,000 -> pool 500 (ceiling) THE SCALING IS PER-ARM, and that is the substance rather than a refinement. A limit only matters if there are rows for it to cut off, so what an arm is BOUNDED BY decides whether library size can help it. LBSimilar, SimilarArtist, TagOverlap and RandomFill grow: they are bounded by similarity/tag data and by the library itself. LikesOverlap, UserCoplay and TasteOverlap do not: they are bounded by the user's likes, the instance's co-play graph and the taste profile, none of which grow when the library does. Raising those would sample more of a set that did not change — churn, not reach. It also keeps this from inflating the sim_score-0 share, since TasteOverlap is one of the two zero-similarity arms. sqrt, not linear: linear would put a 100,000-track library at a 3,400-candidate pool, long past where more candidates improve the answer. A 4x ceiling bounds it at ~500. Never shrinks an arm. The base limits are a floor, and #3889 makes that load-bearing rather than tidy — shrinking an arm ordered by unseeded random() changes pool membership between same-day rebuilds. Library size comes from a TTL-cached count reusing CountTracksMatching with an empty pattern (rule 28 — a new query would need sqlc regeneration, which is blocked). The ILIKE defeats every index, so it is a full scan and must not run per request. It degrades rather than fails: an error keeps the last known value, a never-counted cache returns 0, and 0 scales to the base limits — today's behaviour exactly. Nothing about sizing a pool justifies failing the request it is sizing. Bounded by a 3s deadline (rule 156), and a failed refresh does not stamp the clock, so a blip cannot pin a stale value for the whole TTL. THE REFERENCE IS ASSUMED, NOT MEASURED. libraryScaleReference = 5000 is where growth starts, and the size the v1 constants were really tuned against is unrecorded. #3879 should replace it; until then that constant is the one thing to change. Deliberately conservative: below it nothing scales at all, so no existing install changes behaviour. Falsification caught a weak guard: the sqrt-vs-linear assertion was written at SIXTEEN times the reference, where linear has already been clamped by the ceiling and both curves land on 4x. It proved nothing. Moved to four times the reference, below the ceiling for both, where sqrt gives 2x and linear would give 4x. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SQ31KQpYbStyK5y58UmPLH	2026-09-10 23:23:04 -04:00
bvandeusenandClaude Opus 5	31190657d8	feat(recommendation): Songs-like can include the seed artist's own music ... Operator, 2026-09-10: "it should also be able to include music from the same artist." Completes #3881 — the weights and pool landed in f367eeaa; this is the eligibility half. produceSeedMixes filtered the seed artist out entirely: // "Songs like X" excludes X's own songs. if !pgtypeUUIDEqual(c.Track.ArtistID, artistID) { ... } That reads as obviously right and is not. The seed is a TRACK — the artist's top-played one — and the tracks most likely to sound like it are usually the rest of that artist's catalogue. The filter threw away the seed's nearest neighbours, then reached FURTHER OUT to replace them. On the one surface whose job is staying in a neighbourhood, that is backwards, and it worked against the coherence tuning rather than with it. Domination is bounded by the cap instead of by exclusion, which is the distinction that makes this safe rather than a new problem: capCandidatesByAlbumAndArtist already allows at most 3 tracks per artist in a 25-track mix, so the seed artist gets 12% at most — a presence, not a takeover. Without that bound this would just be the radio failure (#3882) arriving on a different surface. The seed track itself still cannot appear; it is passed to LoadCandidatesFromSimilarity as an exclusion. Guarded end-to-end rather than by reading the source, for two reasons: the check has to survive the filter returning in a different shape, and an absence check would now match the comment that explains why the filter is gone — rule 167's prose trap exactly. The test asserts both directions, that at least one mix contains its seed artist and that none exceeds the cap. Its falsification is by construction rather than by execution: under the previous code every mix's own-artist count was necessarily zero, so the assertion could not have passed. Running it needs Postgres, which is the integration lane's job. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SQ31KQpYbStyK5y58UmPLH	2026-09-10 21:13:32 -04:00
bvandeusenandClaude Opus 5	f367eeaa9d	fix(recommendation): Songs-like gets its own profile so it stops wandering ... Operator, 2026-09-10: "when I play it I'm expecting to get a consistent sound and style from the experience... I was getting a seeming wide variety of music from each one when I was hoping to stay in a certain neighborhood." Songs-like shared the `daily_mix` weight profile with For-You, and that sharing WAS the bug. The two surfaces want opposite things: For-You answers "what will they enjoy today" and is supposed to roam; Songs-like answers "what sounds like THIS". Under one profile the broad answer wins. The arithmetic, from the shared weights: unrelated track, liked, not played recently → 1.0 + 2.0 + 1.0 = 4.0 PERFECT similarity match, not liked → 1.0 + 1.5 = 2.5 Liking something outranked sounding like the seed, because LikeBoost (2.0) exceeded SimilarityWeight's whole range (1.5) and TasteWeight (1.5, and seed-INDEPENDENT) matched it outright. Under the new profile the same pair scores 5.00 vs 2.00. Two levers, because either alone leaves the other's failure intact: POOL. Songs-like now takes its own CandidateSourceLimits. The default gave ~29% of candidates a sim_score of literally zero — `taste_overlap` and `random_fill` are both `0.0::float8` in recommendation.sql, seed-independent by construction. Same total pool size; composition shifts to arms that measure distance from the seed, LBSimilar doubled. WEIGHTS. A third profile beside radio and daily_mix, DB-backed and live per rule 25, with the property that similarity's range exceeds the combined range of every seed-independent differentiator — so a closer match cannot be beaten on likes, freshness and taste alone, while tracks within ~0.39 similarity of each other still get ordered by what the user likes. Rule 131 changed the pool design mid-way and for the better. Zeroing the two seed-independent arms was the first instinct and is exactly the vanish-or-nothing shape that rule forbids: a seed with thin ListenBrainz coverage would yield a short mix or none. They are the tier-3 FLOOR — cut hard, never removed — and the weights keep them at the bottom of the ranking rather than out of the pool. "A few tracks further from the seed than we'd like" beats "no playlist". Caught while wiring it: switching only pickTopN's final Score would have been nearly INERT. scoreAndSortCandidates does the selection sort, and the caller caps and truncates in that order — so the playlist would still have been chosen by daily_mix and merely relabelled with songs_like numbers. It now takes the profile as a parameter, and each surface passes its own. Also corrects the daily_mix card's blurb, which claimed Songs-like as one of its surfaces and no longer is. Guards pin behaviour rather than the numbers, since numbers get retuned: that similarity beats an unrelated liked track, that daily_mix still DOESN'T (or the split buys nothing), that the tier-3 floor is non-zero, and that the UI card shows its own values rather than falling back. Each falsified against its named regression first. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SQ31KQpYbStyK5y58UmPLH	2026-09-10 20:51:15 -04:00
bvandeusenandClaude Opus 4.8	199fec2058	feat(taste): household co-play similarity — #1533 ... Milestone #160 Opt 5. A collaborative candidate arm: tracks by artists co-played across the instance with the seed's artist. Minstrel is a single shared-library, multi-user server (no per-user library ACL — verified: no owner/share/group model), so the "household" is the whole instance's user set; the rule #47 scoping is satisfied by the shared-library boundary. Single-user servers produce no edges. - No migration: source='user_cooccurrence' was pre-whitelisted in the 0009 similarity CHECK from day one. - internal/db/queries/coplay.sql: Delete + Insert artist co-play edges. Score = Jaccard of the two artists' distinct-player sets (controls for globally-popular artists); >= 2 co-players AND Jaccard >= floor kept (the floor also self-limits hub artists). Completed plays, 365d window. - internal/coplay: periodic worker (6h) that atomic-replaces the user_cooccurrence edge set from play_events — pure local SQL, no external calls. Wired in main.go alongside the similarity worker. - LoadRadioCandidatesV2: new coplay_artists arm (source='user_cooccurrence', seed-artist based, 0.5 damp like similar_artists) + $11 limit; CandidateSourceLimits.UserCoplay (default 20, For-You 40). - Integration tests: perfect-overlap Jaccard=1.0 edge + single-user empty-set gate. Device axis and AcousticBrainz (Opt 4) are separately tracked; this closes the milestone-#160 sequential options. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-14 10:07:19 -04:00
bvandeusenandClaude Opus 4.8	65dd132b3d	feat(taste): time-of-day / weekday context conditioning — #1531 ... Milestone #160 Opt 3 (temporal half). A new additive scoring term that boosts a candidate when its artist's play history concentrates in the CURRENT daypart × weekday-type cell, in the user's local timezone. - Migration 0046: recommendation_weight_profiles.context_time_weight (per-profile scoring weight, DEFAULT 1.0). - Query ListArtistContextPlayCountsForUser: per-artist completed-play counts split by the current cell (daypart night[22,5)/morning[5,12)/ afternoon[12,17)/evening[17,22) × weekday-vs-weekend) via started_at AT TIME ZONE users.timezone; 365-day window, skips excluded. - internal/recommendation/context.go: LoadContextAffinity computes each artist's shrunk cell-share minus the user's baseline share, clamped to [-1,1]; sparse artists shrink toward baseline (pseudo-count 5), unknown artists → 0 (cold-start neutral). - Score() gains context_affinity_score · ContextTimeWeight; both candidate loaders set it per candidate. - Tuning lab: ContextTimeWeight threaded through recsettings + admin API + web card ("Time-of-day weight" row) + Go/web tests. Shipped 1.0 both profiles (uniform start, re-bakeable). Device-class axis deferred to #1551 (needs a client_id → device-class mapping that doesn't exist yet). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-14 09:31:43 -04:00
bvandeusenandClaude Opus 4.8	c1d143cf4a	feat(home): Songs-like → dedicated row + wider spread (#1491) ... Promote the best-performing surface ("Songs like {artist}", ~8% skip / ~86% completion) out of the shared Playlists carousel into its own Home row on both Android and web, and widen the daily build from 3 to 6 mixes so the dedicated row shows a wider spread. Server (internal/playlists): - PickSeedArtists candidate pool 5 → 12; pickSeedArtistsForDay now takes songsLikeSeedCount (6) instead of a hardcoded 3. Graceful degradation and daily rotation preserved. Android (HomeScreen.kt): - New songsLikeSection + buildSongsLikeRow; PlaylistsRow takes a title so it renders both the "Playlists" and "Songs like…" rows. buildOnlineRow / orderedRealPlaylists no longer reserve the 3 songs-like slots. Offline shows cached mixes (available-first), hides the row when none. Web (+page.svelte): - Dedicated "Songs like…" row from songsLikeRow; dropped the 3-slot cap and removed songs-like from the Playlists carousel. Tests: seed_selection_test.go, BuildPlaylistsRowTest.kt, page.test.ts. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-13 20:41:08 -04:00
bvandeusen	7226dab9ff	feat(discover): taste-targeted novelty bucket + rebalance toward discovery ... The 2-week metrics review found Discover beating the manual baseline on skip rate — which for a discovery surface means it plays it safe. On a single-user server it's effectively dormant + crude-random, and the per-user taste profile (taste_profile_tags, #796) went unused (#1254 gap). Add a fourth Discover candidate bucket, ListTasteUnheardTracksForDiscover: unheard / non-liked / non-quarantined tracks ranked by summed taste-tag weight over tracks.genre (split like the radio tag_overlap arm), md5 tiebreak. Its picks are stamped pick_kind = 'taste_unheard' (migration 0041 widens the CHECK on playlist_tracks + play_events, rule #36). Rebalance the slot allocation 40/30/30 → taste_unheard 35 / dormant 30 / cross_user 20 / random 15, and lead the interleave with taste_unheard so a track shared with another bucket keeps the taste stamp and the targeted-novelty arm stays measurable. Metrics label "Taste-matched" + order entry added to the single server-side pickKindLabels map, so web and Android surface the new breakdown row with no client change. Cold start (empty taste_profile_tags) yields an empty taste bucket that redistributes to the survivors, so Discover still fills. Scribe #1488. Companion review outcomes: Songs-like starvation already fixed (#1255); For You v2 ratified as-is (fresh-injection cost disproven). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-13 18:16:04 -04:00
bvandeusenandClaude Fable 5	0d0a8f46b1	feat(tuning): scoring weights → DB-backed admin tuning lab ... The recommendation scoring knobs move out of YAML (radio profile) and out of the systemMixWeights hard-code (daily_mix profile) into DB-backed settings with live effect (#1250) — the defaults-discovery lab per decision #1247: the operator turns knobs to find good values, which then get baked back into shipped defaults; end users and other operators should never need the card. - Migration 0040: recommendation_weight_profiles (radio / daily_mix, 8 weight columns), taste_tuning singleton (engagement half-life + completion-curve points), recommendation_tuning_audit (one row per change with a {field, old, new} diff — the trend view's markers, #1251). - internal/recsettings: boot reconcile seeds shipped defaults without clobbering tuned rows (coverart SettingsService pattern), validates patches (bounds, curve ordering), writes audit rows, and pushes daily_mix weights + taste config into package playlists. No-op patches write no audit row. - playlists gains SetSystemMixWeights / SetTasteConfig swap points under a RWMutex — no signature threading through the producers; the scheduler's taste rebuild reads the pushed config. - Radio reads its weight profile from the service per request; the 8 weight fields leave config.RecommendationConfig (YAML keeps only RecentlyPlayedHours / RadioSize / RadioSizeMax). - Admin API: GET/PATCH/reset under /api/admin/recommendation-tuning, echoing current + shipped values. - Web: new admin Tuning tab — two weight profiles side by side, taste card, per-scope save (changed fields only) + reset, deviation dots against shipped defaults. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TsF3cNoKrqCYsU78cXC8U6	2026-07-03 09:22:03 -04:00
bvandeusenandClaude Fable 5	9e02878b61	feat(playlists): For You composition v2 — multi-seed blend + weighted fresh tail ... Two approved composition changes (#1269), mechanism only — the taste/fresh share stays data-decided (#1252) and pick_kind attribution is unchanged. Multi-seed blending: each day's build now seeds from up to 3 of the user's top-5 tracks (pickDailySeeds, the generalized daily shuffle) instead of one rotating anchor, so the mix spans neighborhoods within a day and stops feeling bipolar as the rotation swings between dissimilar seeds. Per-seed pools merge first-seen-deduped; the head is filled best-first under 50/30/20 per-seed quotas (60/40 for two seeds) so one neighborhood can't monopolize it, with thin-seed quota spilling best-first. Score-weighted fresh tail: the tail sample (rank 2*headN onward) was uniform — the 380th-best candidate as likely as the 101st. It now uses deterministic Efraimidis-Spirakis keys with weight halving every 50 ranks, so freshness keeps its "you'll probably enjoy this" half while still rotating daily. The retired single-seed picker's one other caller, You-might-like, moves to pickDailySeeds(n=1) — a single neighborhood per day is right for a short shelf, and the behavior note is inline. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TsF3cNoKrqCYsU78cXC8U6	2026-07-03 09:02:35 -04:00
bvandeusenandClaude Fable 5	48f288e2e5	feat(mixes): tiered rebuilds for New for you + First listens (rule #131) ... Both mixes move from a single hard eligibility rule to the tiered ladder, with their tier stamped onto playlist_tracks.pick_kind via the #1270 provenance pipeline. New for you (#1267) — consume on play, degrade by stepping back: - "Consumed" = any track attempted >=30s; played albums leave the mix at the next build instead of crowding it until the calendar window expires. - Tier 1: unconsumed albums added <30d by direct-affinity artists. Tier 2: unconsumed affinity albums from the wider 30-90d window — added while you weren't looking. Tier 3: any unconsumed album added <90d, newest first. First listens (#1268) — track-level "attempted" threshold: - A 2-second accidental brush no longer disqualifies a whole album; "attempted" is duration_played_ms >= 30000 per track. - Tier 1: albums with zero attempted tracks. Tier 2: barely-attempted albums (<=25% of tracks reached 30s), minus the attempted tracks themselves. The artist-affinity ordering signal also moves to the >=30s definition so skip-only contact doesn't read as trust. Producer plumbing: fetch adapters map the tier column onto pick kinds, finishMix propagates PickKind into the persisted candidates, and rotateForDay now rotates within contiguous same-pick-kind blocks so daily rotation can't hoist tier-3 filler above tier-1's exact fits (untiered pools are one block — original behavior). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TsF3cNoKrqCYsU78cXC8U6	2026-07-03 08:54:20 -04:00
bvandeusenandClaude Fable 5	a670840114	fix(playlists): Songs-like mixes no longer vanish after a quiet week ... PickSeedArtists had a hard 7-day window with no fallback: a week without listening emptied the seed pool, produceSeedMixes returned zero playlists, and the daily atomic-replace build deleted every existing "Songs like X" mix until the user played something again (#1255). The query now falls back through widening engagement windows — 7d → 30d → all-time → liked artists — the same tiered shape that fixed the identical vanish for For You's seeds (PickTopPlayedTracksForUser). Like-boost scoring is preserved in every tier. All returned rows share the winning tier, and produceSeedMixes maps it onto the rule-#131 pick-kind ladder (7d = tier1 exact, 30d = tier2, all-time/liked = tier3) and stamps the built tracks — the #1270 provenance pipeline then attributes plays and skips to seed freshness, so the metrics card can say whether stale-seeded mixes actually perform worse. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TsF3cNoKrqCYsU78cXC8U6	2026-07-03 08:38:54 -04:00
bvandeusenandClaude Fable 5	5faa57634b	feat(metrics): provenance as standard — pick_kind for all system mixes ... The #1249 mechanism (stamp WHY a track is in the snapshot at build time, freeze it onto the play at ingestion, break it down in metrics) generalizes from a For You one-off to the standard for every system mix (#1270): - Migration 0039 widens both pick_kind CHECKs (drop + re-add in the same change) to taste/fresh + Discover's dormant/cross_user/random + tier1-3 for the rule-#131 eligibility ladders. - GetForYouPickKindForTrack becomes GetSystemPickKindForTrack (user, variant, track); ingestion stamps any systemPlaylistSources play from its own variant's live snapshot, live + offline paths. - Discover stamps its candidate bucket on discoverTrack before the interleave, making the 40/30/30 allocation measurable; dedup keeps the taking bucket's stamp. - Metrics replace the for_you special-case with one pick-kind vocabulary — any family with attributed plays gets a breakdown, future stamping mixes need no metrics change. - Web: breakdown sub-rows are now toggled per surface (collapsed by default) so eight stamping mixes don't swamp the card. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TsF3cNoKrqCYsU78cXC8U6	2026-07-02 23:26:52 -04:00
bvandeusenandClaude Fable 5	fb4431207d	feat(recommendation): For You exploration attribution — taste vs fresh picks ... Milestone #127 step 2 (#1249). For You deliberately blends two populations — a head of top-scored taste picks and a tail sampled from deeper ranking (the freshness injection) — but the metrics judged it as one blob, so its skip rate couldn't distinguish "the taste engine is missing" from "the freshness tax is too high". That number decides the exploration share before we tune it. - Migration 0038: nullable pick_kind ('taste'|'fresh') on both playlist_tracks (stamped at snapshot build) and play_events (frozen at play-ingestion — the snapshot rebuilds daily, so attribution cannot be reconstructed at read time). - Builder: pickHeadAndTail marks head=taste / tail=fresh; the small-pool fallback is all taste (top-N-by-score IS the taste mechanism). Other variants persist NULL. - Ingestion: for_you plays (live + offline replay) look the track up in the user's current snapshot; not found → unattributed, never guessed. - Metrics: For You's row gains a breakdown (taste / fresh / earlier unattributed plays), parent row stays the sum; web card renders the sub-rows indented with the same baseline deltas + low-data dimming. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TsF3cNoKrqCYsU78cXC8U6	2026-07-02 20:39:41 -04:00
bvandeusenandClaude Opus 4.8	6c26ba807e	feat(taste): phase 2b — taste_overlap candidate arm (#796) ... 2a re-ranks the existing pool by TasteMatch; this ensures taste-relevant tracks ARE in the pool. Adds a 6th arm to LoadRadioCandidatesV2: in-library tracks by the user's top positively-weighted taste-profile artists ($10 K, weight > 0, deterministic weight-DESC,id order so it doesn't reintroduce same-day nondeterminism). Pool-inclusion only (sim_score 0) — TasteMatch already scores the fit. Empty for cold-start users (no profile). - CandidateSourceLimits.TasteOverlap; default 20 (radio), 80 for For-You via systemForYouSourceLimits. - You-might-like deliberately sets TasteOverlap=0: it surfaces NOT-actively- engaged artists, so flooding its pool with top-taste (mostly already-played) artists would just feed the read-time dedup. - Test: positive-weight artist's track enters via the arm; negative-weight one is excluded (weight > 0). Existing pool tests unaffected (no profile seeded). Deferred within 2b: profile-seeded For-You — marginal given the arm + TasteMatch already inject taste broadly (top-played seed ≈ top-taste artist). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-12 00:05:50 -04:00
bvandeusenandClaude Opus 4.8	aff346c731	feat(taste): phase 2a — apply the taste profile via a TasteMatch scoring term (#796) ... The profile built in phase 1 now changes what gets surfaced. Adds a TasteMatch term to the weighted-shuffle score so candidates are re-ranked by their fit to the user's learned taste (positive draws toward it; negative reflects passive avoidance; 0 at cold start). - recommendation/score.go: ScoringInputs.TasteMatchScore ([-1,+1]) + ScoringWeights.TasteWeight + the term in Score. - recommendation/taste.go: LoadTasteProfile reads the taste_profile_* tables; TasteProfile.Match blends the candidate's artist weight (0.7) and avg genre-tag weight (0.3), each tanh-squashed by a fixed scale so one outlier artist can't compress the rest. Unknown artist/tags and empty profiles → 0 (neutral). - candidates.go: both candidate loaders set TasteMatchScore per candidate, so every Score caller (system playlists incl. You-might-like, radio) becomes taste-aware automatically. - weights: systemMixWeights.TasteWeight = 1.5 (daily mixes are the primary taste surface); config.RecommendationConfig gains taste_weight (default 1.0, lighter — radio is seed-directed) wired into the radio handler. - tests: pure (Match curve incl. saturation/clamp/empty-neutral, Score term add+subtract) + DB round-trip (seed taste rows → Match positive). All green vs real Postgres; existing playlist/radio tests unaffected (empty profile → zero taste effect). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-11 21:29:42 -04:00
bvandeusenandClaude Opus 4.8	752906b054	fix(playlists): pin candidate order before jitter to make daily builds deterministic ... scoreAndSortCandidates drew per-candidate jitter by slice position, but the candidate query (LoadRadioCandidatesV2) has ORDER BY random() arms and no stable outer ordering, so DB row order varies call-to-call. When the recency spread between candidates is smaller than the ±jitter (small or recency-clustered libraries), two same-day rebuilds assigned jitter to different tracks and reordered near-ties — so the build was not actually deterministic-within-a-day as documented. Pre-existing latent flake in TestBuildSystemPlaylists_DailyNonceDeterminism (passed in isolation / by luck in CI; deterministically reproduced when the system-build tests run in sequence). Confirmed independent of the You-might-like change by neutralizing buildYouMightLike — the flake persisted. Fix: sort the candidate slice by track id before assigning jitter, so the jitter for a track is a function of (track, day) alone, independent of DB return order. Verified: full playlists package green 4/4 and the build-test sequence green 5/5 (was 0/4 before). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-11 19:56:13 -04:00
bvandeusenandClaude Opus 4.8	fdd14ef04c	feat(server): "You might like" album/artist Home rows (#790) ... Surface in-library albums/artists the listener doesn't actively spin but is predicted to enjoy, derived from the same similarity + like-weighted candidate engine that powers For-You — rolled up from track scores to album/artist granularity. Built in the daily 3am BuildSystemPlaylists pass, atomic-replaced alongside the system playlists, and read back by /api/home (+ /api/home/index). Cold-start gate: skips generation entirely below 20 distinct unskipped tracks AND 5 distinct artists, so a thin profile ships empty rows rather than near-random tiles. - migration 0034: you_might_like_albums / you_might_like_artists (id+rank, CASCADE, per-user rank index). - playlists/you_might_like.go: cold-start gate + similarity roll-up (sum-of-top-3 aggregation, per-artist album cap, daily-rotating via the same userIDHash jitter as For-You) + atomic-replace persist in the tx. - recommendation/home.go: two new HomePayload sections with read-time cross-section dedup vs Most Played / Rediscover / Last Played, trimmed to 10 each. - api: you_might_like_albums / you_might_like_artists on /api/home and /api/home/index, reusing albumRefFrom / artistRefFromCovered. - tests: pure roll-up/aggregation/cap unit tests + DB-backed gate, sufficiency, and atomic-replace tests (all green vs real Postgres). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-11 19:33:46 -04:00
bvandeusen	7473e98d91	fix(server): unify discovery-mix producers + daily-rotate the deterministic ones ... The five discovery-mix producers (Deep Cuts, Rediscover, New for you, On this day, First listens) were near-identical boilerplate that differed only in (a) which SQL query they ran and (b) whether to diversity-cap the result. Folded into one produceDiscoveryMix(spec) factory + a per-mix discoveryMixSpec slice. The registry composes the factory over the spec list so adding a new mix is one struct literal + a SQL query, never a new func. Also fixes the user-reported bug that several mixes 'show the same content from yesterday'. Audit of the SQL queries: - Deep Cuts: ORDER BY md5(t.id::text || $2::text) → day-keyed - On this day: ORDER BY w.c DESC, md5(...) → day-keyed - Rediscover: ORDER BY tier, c DESC, id → invariant - New for you: ORDER BY al.created_at DESC, disc, track → invariant - First listens: ORDER BY tier, al.id, disc, track → invariant The three invariant ones produced identical content day-over-day. The unified spec carries a dailyRotate bool: when set, the producer applies a daily-deterministic offset rotate-left of the candidate pool BEFORE diversify+truncate. Rotation (not shuffle) preserves contiguous-block ordering inside each day's slice — matters for First listens which is album-coherent. Set on Rediscover + First listens (where same-content-every-day is clearly a bug). Left off New for you because 'newest album first regardless of day' is the intended UX for that surface — daily rotation there would feel wrong. Daily rotation seed: rand.New(NewSource(int64(userIDHash(userID, dateStr)))) — same primitive used by For-You's pickHeadAndTail sampling so behavior is consistent across the system playlist family. No test file referenced the deleted produceXxx functions directly, only the registry, so this is a closed refactor.	2026-06-03 13:18:17 -04:00
bvandeusenandClaude Opus 4.7	2e7b81fdfe	fix(playlists): robust For-You seed + deep fill; young-library mix fallbacks ... For-You silently vanished after ~7 days of not listening (seed query required a non-skip play in the last 7 days) and capped at ~40 on self-hosted libraries with no ListenBrainz similarity data. - PickTopPlayedTracksForUser: tiered seed — last 30d top plays, else all-time top plays, else liked tracks. For-You only disappears now if the account has zero plays AND zero likes. - produceForYou uses deeper candidate source limits (raised random/ tag/similar K) so it reaches ~100 even with empty lb_similar / similar_artists; richer when LB enrichment is present. - Rediscover: tiered — 6-month-dormant, else ≥5-play 30-day-dormant. - On This Day: floor 60→30 days, window ±7→±10 doy; still skips cleanly (no rows → no playlist) on insufficient history. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-16 12:48:20 -04:00
bvandeusenandClaude Opus 4.7	c7ee0871a5	feat(playlists): #411 R3 — five discovery mixes (#419-423) ... Each is one candidate query + one registry entry; zero client work (R2 made tiles/refresh/shuffle generic, all are singleton kinds so web's server `refreshable` flag and Flutter's derived getter both light up automatically). - deep_cuts (#419): <=2-play tracks from liked / heavily-played artists; diversity-capped. - rediscover (#420): >=5-play tracks not heard in 6 months, by historical affection. - new_for_you (#421): tracks from albums added <=30d whose artist the user likes/plays; album-coherent (no cap). - on_this_day (#422): tracks played within ±7 day-of-year in prior windows (>60d ago), weighted by play count. - first_listens (#423): never-played albums, tiered liked-artist → played-artist → rest; album-coherent. system_mixes.go producers mirror the Discover model (SQL gives the ranking; finishMix caps+truncates to 100 to match For-You/Discover shuffle depth; album-coherent mixes skip the cap). Builder query failure is non-fatal (logged, yields no playlist) like Discover. Existing system_test existence checks are unaffected. Closes the #411 system-playlists-v2 umbrella's new-types thread. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-15 13:55: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	e3957b8eed	fix(lint): rename unused now param in produceDiscover to _ ... revive unused-parameter: produceDiscover keys off dateStr, not now, but must keep the uniform systemPlaylistProducer signature. Blank the unused param (param names don't affect func-type identity). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-15 12:33:05 -04:00
bvandeusenandClaude Opus 4.7	1379595e82	refactor(playlists): #411 R1 — system-playlist kind registry ... Behavior-preserving prep for the new mix types. Extracts the three inline candidate computations in BuildSystemPlaylists into producers (produceForYou / produceSeedMixes / produceDiscover) and drives the build off a systemPlaylistRegistry. The shared machinery (run-claim guard, atomic delete+insert tx, post-commit collages) is now generic over a []builtPlaylist. Fatal-vs-skip error semantics unchanged: a base query failure (PickTopPlayedTracksForUser, PickSeedArtists) still aborts the whole build; candidate-load / per-seed-artist / Discover-bucket failures are still logged and just yield fewer playlists. Materialize order (for_you, songs_like_artist, discover) is unchanged and functionally irrelevant. No API/client/schema change — CI's system/foryou/service tests verify For You / Songs-like-X / Discover parity. Adding a new mix is now: a producer + one registry entry + its candidate query. Next (R2): generic /api/playlists/system/{kind}/{refresh,shuffle} off the registry; then the new kinds. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-15 12:25:54 -04:00
bvandeusenandClaude Opus 4.7	69569a5c2b	feat(playlists): expand For You to 100 tracks (Discover parity) ... Closes Fable #414. forYouHeadN/forYouTailN go 12/13 → 50/50 so the For-You snapshot is 100 tracks, matching Discover. Motivated by the shuffle-on-play default that just shipped (#413): a 25-track shuffle pool repeats fast; 100 makes re-plays within a day feel varied. pickHeadAndTail already degrades gracefully when the candidate pool is too thin for a full head/tail split (returns top-N-by-score), mirroring how Discover returns <100 when its buckets are thin — no new edge-case handling needed. No build-path test asserts the For-You total; pickHeadAndTail unit tests pass their own head/tail values so they're unaffected. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-15 07:32:55 -04:00
bvandeusenandClaude Opus 4.7	5cd342d521	feat(playlists): daily seed rotation + jitter + 12+13 split for system playlists ... Five diversity mechanics — applied to both For-You and Songs-Like-X. 1. For-You seed rotates daily across the user's top-5 most-played tracks. pickForYouSeedForDay uses userIDHash(user, day) mod len(seeds) so today's mix uses an entirely different similarity pool than tomorrow's. Within-day determinism preserved. 2. JitterMagnitude bumped 0.0 → 0.1. The scoring RNG is now seeded by userIDHash(user, day) rather than the no-op, so near-tied candidates shuffle daily without breaking within-day stability. 3. Head/tail split moves from 20+5 to 12+13. Roughly half the playlist comes from the tail now (daily-deterministic via tieBreakHash), giving the user substantially different content while a 12-track anchor of strong similarity matches keeps the mix recognizable. 4. Songs-Like-X seed artists shuffle daily across the user's top-5 played artists. pickSeedArtistsForDay applies a userIDHash-seeded Fisher-Yates and takes 3. 5. scoreAndSortCandidates / pickTopN / pickHeadAndTail gain a userID parameter so the RNG can be seeded per-user; existing call sites updated; noopRNG removed. Test fixtures widened similarity gaps (e.g. float64(50-i) instead of (50-i)/50) so the new jitter (±0.1) doesn't perturb head ordering in assertions about the head/tail mechanism. New seed_selection_test coverage for userIDHash + pickForYouSeedForDay + pickSeedArtistsForDay spans deterministic-within-day, varies-across-days, and graceful degradation with small candidate pools. PickTopPlayedTrackForUser replaced by PickTopPlayedTracksForUser :many in the prior commit (b4801c2). The For-You seed lookup now goes through pickForYouSeedForDay over the returned slice. PickSeedArtists's LIMIT widened to 5 in the same prior commit. For #392 Half A — system playlist content diversity. Half B (per-user timezone scheduling) is a separate spec. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-13 10:19:49 -04:00
bvandeusenandClaude Opus 4.7	1f0f7eee1a	fix(playlists): unblock Discover by removing SELECT DISTINCT + ORDER BY plan error ... The cross-user bucket query combined SELECT DISTINCT with ORDER BY md5(...), which Postgres rejects at plan time (SQLSTATE 42P10). buildDiscoverCandidates returned that error on first bucket failure, so the whole Discover playlist was skipped every nightly run — even though the random bucket pool was healthy. Switched to GROUP BY so the md5 ordering expression no longer needs to appear in the select list, and hardened the function so future single- bucket failures degrade gracefully via slot redistribution instead of taking out the whole playlist. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-12 09:50:01 -04:00
bvandeusen	042f9919fe	fix(server/playlists): redistributeSlots double-counting + tieBreakHash avalanche ... Two real algorithm bugs in F-T1's For-You composition + Discover allocator. Both surfaced as failing unit tests under go test -race. 1. redistributeSlots was re-redistributing a bucket's full deficit on every pass instead of just the residual. The loop computed `deficit = b.want - final[i]` each iteration, but final[i] for a deficit bucket never increases (its supply is exhausted), so pass N saw the same deficit as pass N-1 and kept shoveling it to peers. For [want:40 avail:100, want:30 avail:0, want:30 avail:100], four passes pushed cross-user's deficit into dormant+random four times each, hitting the 100-slot clamp at the end and producing [50, 0, 50] instead of the spec'd [55, 0, 45]. Fix: track per-source `redistributed[i]` and subtract it from the deficit each pass. Multi-pass behavior still works for the case where a peer's supply runs out mid-distribution. 2. tieBreakHash used FNV-1a 64-bit with trackID + dateStr appended. For dateStrs differing only in the last character ("2026-05-07" vs "2026-05-08"), the FNV state diverged only in low bits at the final byte; multiplication by FNV_prime propagates upward but the relative ordering of 60 small candidate UUIDs (which differ only in their last byte) ended up identical across the two dates. The For-You head/tail test asserted that the tail's first 5 should change across days; it didn't. Fix: switch to SHA-256 truncated to 8 bytes. SHA-256 has full avalanche, so any single-bit input change roughly half-flips the output bits and meaningfully reorders. The hash isn't security-load-bearing; we just need strong avalanche for tiny dateStr deltas. Determinism (same inputs → same output) is preserved.	2026-05-07 18:33:06 -04:00
bvandeusenandClaude Sonnet 4.6	0bfd51a149	feat(server/playlists): For-You head+tail + diversity caps ... Two improvements to the system playlist builder: 1. Per-artist (<=3) and per-album (<=2) caps applied to the pickTopN truncation step, using the same numeric caps Discover already enforces. Both For-You and Songs-like-X benefit. Same skewed candidate pool no longer collapses to "10 tracks from the same artist" — the playlist always carries at least 9 distinct artists in 25 slots. 2. New pickHeadAndTail function for For-You: 20 top-similarity tracks + 5 sampled from the tail (positions 2*headN onward of the score-sorted, cap-applied pool). Tail sampling uses tieBreakHash for daily determinism — same user same day still sees the same playlist, but the daily refresh feels less stuck-in-a-rut. Tail tracks are still similarity-related (they passed the similarity candidate filter) so the user should enjoy them, just from artists they wouldn't have surfaced via strict top-N ranking. Songs-like-X keeps the simple pickTopN call — the seed-artist context already provides the "you'll like this" framing without needing a tail injection. Refactors pickTopN internals: now sorts candidates first via scoreAndSortCandidates, applies the cap on []Candidate via capCandidatesByAlbumAndArtist, and truncates. Removes the now- dead stableSortByScoreThenHash helper (only used in old pickTopN). The cap helper mirrors capByAlbumAndArtist in discover.go but operates on recommendation.Candidate so it sees Track.AlbumID / Track.ArtistID directly. Tests cover the cap helper truth table, head+tail split with small/large pools, buffer-zone exclusion, daily determinism, and cross-day tail variance. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-05-07 10:34:39 -04:00
bvandeusenandClaude Sonnet 4.6	f77a0699ec	feat(server/playlists): Discover system playlist ... Adds the third system playlist variant: 'discover'. Surfaces 100 tracks the operator has not played and not liked, biased toward artists they rarely play (< 10 plays) and complemented by tracks liked by other users plus a random unheard sample. Cold start collapses to all-random; single-user servers redistribute the cross-user-likes allocation equally across the other two buckets. The build runs as a fourth phase inside BuildSystemPlaylists alongside For You and the seed-artist mixes. Same daily-deterministic md5(track_id || dateStr) ordering as the other variants. Per-album (<=2) and per-artist (<=3) caps prevent collapse onto a single prolific artist. Buckets interleave round-robin so the playlist order doesn't front-load one bucket's flavour. Post-commit collage generation (already wired) gives Discover the same 4-cell cover treatment as the other system playlists — no new collage code needed. Tests cover the slot-redistribution table (all-available, cold-start, single-user, partial-dormant, fully-empty), the per-album/per-artist caps, the round-robin interleave, and a DB-backed cold-start integration test that asserts a Discover playlist lands with non-zero tracks. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-05-07 08:35:54 -04:00
bvandeusen	735383fb1d	feat(server/playlists): generate cover collages for system playlists ... System-generated playlists ("For You", "Songs like X") rendered with empty placeholder boxes in the UI even when their contributing tracks had album art. The build path inserted playlist rows directly without ever invoking the existing playlists.GenerateCollage machinery — that was only wired into user-edited playlist mutations. After this change, BuildSystemPlaylists generates a 4-cell collage for every system playlist it creates, post-commit. Same cover mechanism user playlists use, same on-disk layout (<DataDir>/playlist_covers/<id>.jpg). Cells whose source album lacks art fall back to the FabledSword glyph, so a partially-covered library still produces a sensible visual. Threading: BuildSystemPlaylists, StartSystemPlaylistCron, and the api lazy-build path all gain a dataDir string parameter; main.go passes cfg.Storage.DataDir. Drops the now-redundant PickTopAlbumCoverForArtistByUser lookup — the collage is more visually informative than a single album cover copy, and the seed-artist's top album is one of the contributing tracks in the mix anyway, so it'll appear as one of the four cells. Tests pass t.TempDir() for the dataDir parameter.	2026-05-07 08:14:13 -04:00
bvandeusenandClaude Opus 4.7	0dbe326d8b	fix(server,web): forward-fix CI lint + vitest failures ... - gofmt -s on system.go, system_cron.go, api.go - rename unused r → _ in 3 fetcher_test.go HTTP handlers - TrackRow +queue test uses /add .* to queue/i (track-aware aria-label from #377) - /library/artists page test mocks likes + tanstack-query (ArtistCard now embeds LikeButton) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-04 17:39:06 -04:00
bvandeusen	797a2c8a45	fix(server/m7-352): log Finish/Fail run errors; drop unused seed-limit constant	2026-05-04 09:14:40 -04:00
bvandeusenandClaude Sonnet 4.6	46a9de8e9a	feat(server/m7-352): BuildSystemPlaylists with atomic replace + concurrency guard ... Implements T5 of #352 slice 2: adds CreateSystemPlaylist sqlc query, BuildSystemPlaylists function (For-You + Songs-like mixes, tx atomic replace, in_flight guard, tieBreakHash determinism), and 7 integration tests covering activity, quarantine exclusion, atomic replace, concurrency, daily nonce stability, ListActiveUsers, and stale-in-flight recovery. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-05-04 08:35:02 -04:00
bvandeusen	ef478778ef	feat(server/m7-352): system mix helpers (tieBreakHash, pickSeedArtists)	2026-05-04 08:24:39 -04:00