12 Commits

Include renames

Author	SHA1	Message	Date
bvandeusenandClaude Opus 5	ecfa056d4d	fix(recommendation): don't shrink a candidate arm ordered by unseeded random() ... Fixes the integration failure from f367eeaa: "same-day rebuild produced different track lists". Cutting RandomFill 30→10 for Songs-like broke TestBuildSystemPlaylists_DailyNonceDeterminism, and the reason is worth stating because the number is not the bug. `likes_overlap` and `random_fill` end in a bare `ORDER BY random()` with no daily seed (recommendation.sql:118, :161). Such an arm returns a STABLE set only while its LIMIT exceeds the rows eligible for it — then it returns all of them, and the random order stops mattering because scoreAndSortCandidates sorts by track id before drawing jitter. Below that threshold the arm returns a random SUBSET, and two builds on the same day draw different ones. So the test was green by accident. It seeds ~20 tracks against a default RandomFill of 30; the limit exceeded the library, so the arm returned everything. Determinism held for a reason unrelated to the code being right. Which means it does NOT hold in production. Any real library is larger than 30, so same-day rebuilds have been drawing different mixes since that arm was written — invisible, because a mix changing after a refresh looks like a feature. Filed as #3889; the fix is a seeded ordering per (user, day), which needs a .sql change and sqlc regeneration and so cannot land from here. The correction: grow an arm freely, never shrink one whose ordering is unseeded random. LikesOverlap and RandomFill go back to the defaults; TasteOverlap stays halved because it sorts by `tpa.weight DESC, t.id` and is genuinely deterministic. Guarded by a test that names the reasoning, so the next person to trim these has to read why first — and it should be DELETED once #3889 lands rather than worked around. The cost is honest: the seed-independent share of the Songs-like pool falls from 29% to 20% instead of the intended cut. That matters less than it sounds. The pool only biases the draw; the songs_like WEIGHTS are what actually demote sim_score-0 candidates, and they are untouched here — a perfect match still scores 5.00 against an unrelated favourite's 2.00. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SQ31KQpYbStyK5y58UmPLH	2026-09-10 20:59:39 -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	5749f48b4a	feat(taste): device-class context conditioning — #1551 ... Milestone #160 Opt 3b. Adds device class as a third context axis on top of the #1531 time-of-day/weekday affinity: on the radio path, a candidate is boosted when its artist concentrates in the current (daypart × weekday × device) cell. Client-sent (client_id is opaque; no UA stored), so it's captured going forward and applies to radio only (daily mixes are cron-built with no device → stay device-agnostic). Server: - Migration 0048: play_events.device_class text NULL (no CHECK; normalized in Go — one whitelist entry per new client class, not a migration). - events.go: eventRequest.device_class + normalizeDeviceClass (whitelist → mobile/web/…, else "other", empty → NULL); threaded through both RecordPlayStartedWithSource and RecordOfflinePlay into InsertPlayEvent. - ListArtistContextPlayCountsForUser gains a current-device param; the cell FILTER adds AND ($2='' OR device_class=$2) — '' reproduces the #1531 time-only behaviour exactly (used by mixes). SessionVector.DeviceClass carries it; the radio handler derives the current device from the user's latest play (GetLatestPlayDeviceClassForUser) — request-free proxy. - No new tuning knob: device narrows the existing ContextAffinityScore (reuses context_time_weight). Clients: - web: play_started sends device_class 'web'. - android: play_started + offline replay send 'mobile' (EventsWire + PlayOfflinePayload + MutationReplayer + PlayEventsReporter). Test: LoadContextAffinity device-narrowing integration test (mobile vs web artist separation; device-agnostic parity). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-14 12:47:59 -04:00
bvandeusenandClaude Opus 4.8	f0c08e7326	feat(taste): mood taste facet — #1534 ... Milestone #160 Opt 2b (mood half of the era+mood option). A fourth taste facet alongside artists + genre tags + eras: signed weights over canonical mood buckets (melancholic / energetic / chill / …) derived from a track's enriched folksonomy tags (#1490). - internal/mood: shared vocabulary — Of(tags) maps folksonomy tags to canonical mood buckets (synonyms collapse). Imported by both the taste builder and the scorer so a track's mood is derived identically. - Migration 0047: taste_profile_moods table + taste_tuning.mood_scale (DEFAULT 0.5). - Build side (internal/taste): Config.MoodScale ([0,1] damper, mirrors EraScale); accumulate folds each play/like's mood buckets at base*MoodScale; persist atomic-replaces the mood rows. - Scorer (internal/recommendation): TasteProfile gains a mood term (own tanh scale + additive 0.12 share, so it never weakens the existing signal when a track has no mood tags). Match now takes the candidate's mood buckets; loaded per candidate (ListTrackTagsForTracks → mood.Of) in the primary similarity loader only — the near-whole-library fallback pool passes nil (mood → 0) to avoid a full-library tag scan. - Tuning lab: mood_scale threaded through recsettings + admin API + web card ("Mood weight" row) + Go/web tests. Coverage is partial (grows with tag enrichment; richer once Last.fm is keyed), so mood is a supplement — neutral for tracks with no mood tags. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-14 10:32:41 -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	40384cc05e	feat(taste): era/decade taste facet — #1530 ... Milestone #160 Opt 2 (era half). A third taste facet alongside artists + genre tags: signed weights over decade buckets ("1990s") derived from albums.release_date, rebuilt daily and scored into the taste match. - Migration 0045: taste_profile_eras table (mirrors taste_profile_tags) + taste_tuning.era_scale column (DEFAULT 0.5). - Build side (internal/taste): Config.EraScale ([0,1] damper, mirrors EnrichedTagScale), accumulate folds each play/like's decade at base*EraScale, persist atomic-replaces the era rows. - Scorer (internal/recommendation): TasteProfile gains an era term (own tanh scale + additive 0.15 share so it never weakens the existing artist/tag signal when a track is undated); candidate queries return album release_date; decadeOf mirrors the builder helper. - Tuning lab: era_scale threaded through recsettings + admin API + web card (auto-renders the new row) + Go/web tests. Mood facet deferred to #1534 (partial enrichment coverage + needs candidate-side enriched-tag loading). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-14 09:01:00 -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 Sonnet 4.6	51811c9d35	feat(recommendation): add LoadCandidatesFromSimilarity (5-source candidate pool) ... Implements M4c's similarity-driven candidate pool: CandidateSourceLimits, DefaultCandidateSourceLimits, and LoadCandidatesFromSimilarity consuming LoadRadioCandidatesV2 (5-way UNION + max-score dedup). Adds 10 integration tests covering all sources, exclusions, dedup, and edge cases. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-04-29 08:30:53 -04:00
bvandeusenandClaude Sonnet 4.6	5b79aa1047	feat(recommendation): LoadCandidates computes per-candidate ContextualMatchScore ... Adds a 6th argument (currentVector SessionVector) to LoadCandidates, bulk-fetches the user's active contextual_likes in one query, and sets ContextualMatchScore on each candidate's ScoringInputs via max-similarity over that candidate's like vectors. Adds helper + 6 integration tests covering no-likes, single match, multi-like max, soft-delete filtering, seed-like filtering, and seed-current short-circuit. Adds contextual_likes to the TRUNCATE list in testPool to prevent cross-test leakage. internal/api/radio.go is intentionally left broken (Task 6 fixes it). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-04-27 20:41:55 -04:00
bvandeusen	b513c91520	feat(recommendation): add LoadCandidates DB-backed loader ... Wraps the LoadRadioCandidates sqlc query, projects rows to []Candidate. Live-DB tests verify seed exclusion, recently-played exclusion, stat-join correctness (likes + plays + skips + last_played_at), and cross-user isolation.	2026-04-27 08:03:20 -04:00