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

internal/playlists/system.go

@@ -219,6 +219,24 @@ var (
 		// uniform with radio pending trend data.
 		ContextTimeWeight: 1.0,
 	}
+	// Songs-like's own profile (#3881). Pre-push literal only; shipped
+	// defaults live in recsettings.ShippedSongsLikeWeights and must stay in
+	// sync with it, exactly as systemMixWeights does above.
+	//
+	// SimilarityWeight dominates here and every seed-INDEPENDENT term is
+	// demoted, which is the whole difference between this surface and For-You.
+	// See ShippedSongsLikeWeights for the property the numbers encode.
+	songsLikeWeights = recommendation.ScoringWeights{
+		BaseWeight:        1.0,
+		LikeBoost:         0.5,
+		RecencyWeight:     0.25,
+		SkipPenalty:       2.0,
+		JitterMagnitude:   0.05,
+		ContextWeight:     0.5,
+		SimilarityWeight:  4.0,
+		TasteWeight:       0.25,
+		ContextTimeWeight: 0.5,
+	}
 	systemTasteConfig = taste.DefaultConfig()
 )
 
@@ -230,6 +248,20 @@ func SetSystemMixWeights(w recommendation.ScoringWeights) {
 	systemMixWeights = w
 }
 
+// SetSongsLikeWeights installs the songs_like scoring profile (#3881).
+// Same push model as SetSystemMixWeights — recsettings calls it on boot and
+// after every knob turn, so a tuning change takes effect on the next daily
+// build with no restart.
+//
+// Separate from systemMixWeights because Songs-like and For-You want opposite
+// things: For-You roams, Songs-like must not. Sharing one profile is what made
+// "Songs like X" wander.
+func SetSongsLikeWeights(w recommendation.ScoringWeights) {
+	systemTuningMu.Lock()
+	defer systemTuningMu.Unlock()
+	songsLikeWeights = w
+}
+
 // SetTasteConfig installs the taste-profile build configuration
 // (half-life + engagement curve, #1250). Same push model as
 // SetSystemMixWeights.
@@ -239,6 +271,12 @@ func SetTasteConfig(c taste.Config) {
 	systemTasteConfig = c
 }
 
+func currentSongsLikeWeights() recommendation.ScoringWeights {
+	systemTuningMu.RLock()
+	defer systemTuningMu.RUnlock()
+	return songsLikeWeights
+}
+
 func currentSystemMixWeights() recommendation.ScoringWeights {
 	systemTuningMu.RLock()
 	defer systemTuningMu.RUnlock()
@@ -392,7 +430,13 @@ func pickWeightedTail(tailPool []recommendation.Candidate, dateStr string, tailN
 // tieBreakHash). The scoring RNG is seeded by userIDHash so jitter is
 // deterministic per (user, day) but rotates across days. Pure — no
 // truncation, no cap.
-func scoreAndSortCandidates(cands []recommendation.Candidate, userID pgtype.UUID, dateStr string, now time.Time) []recommendation.Candidate {
+// weights is a parameter rather than a read of currentSystemMixWeights()
+// because this sort IS the selection: the caller caps and truncates in the
+// order this returns, so whatever profile ranks here decides which tracks
+// reach the playlist. Scoring with daily_mix here and re-scoring with
+// songs_like afterwards would have let the new profile relabel tracks it had
+// no part in choosing — inert where it matters (#3881).
+func scoreAndSortCandidates(cands []recommendation.Candidate, userID pgtype.UUID, dateStr string, now time.Time, weights recommendation.ScoringWeights) []recommendation.Candidate {
 	rng := rand.New(rand.NewSource(int64(userIDHash(userID, dateStr))))
 	type scored struct {
 		c     recommendation.Candidate
@@ -411,7 +455,6 @@ func scoreAndSortCandidates(cands []recommendation.Candidate, userID pgtype.UUID
 	sort.SliceStable(ordered, func(i, j int) bool {
 		return uuidLessPL(ordered[i].Track.ID, ordered[j].Track.ID)
 	})
-	weights := currentSystemMixWeights()
 	pairs := make([]scored, len(ordered))
 	for i, c := range ordered {
 		pairs[i] = scored{c: c, score: recommendation.Score(c.Inputs, weights, now, rng.Float64)}
@@ -647,9 +690,13 @@ func produceSeedMixes(
 			continue
 		}
 		zeroVec := recommendation.SessionVector{Seed: true}
+		// Songs-like's own pool shape, not the default (#3881). Same total
+		// size; the composition shifts toward arms that actually measure
+		// distance from the seed. The default gave ~29% of candidates a
+		// sim_score of literally 0.
 		cands, cerr := recommendation.LoadCandidatesFromSimilarity(
 			ctx, q, userID, seedTrack, 1, zeroVec, []pgtype.UUID{seedTrack},
-			recommendation.DefaultCandidateSourceLimits(),
+			recommendation.SongsLikeCandidateSourceLimits(),
 		)
 		if cerr != nil {
 			logger.Warn("system playlist: seed candidates load failed; skipping",
@@ -838,13 +885,20 @@ func BuildSystemPlaylists(ctx context.Context, pool *pgxpool.Pool, logger *slog.
 // truncates to n. Used by Songs-like-X (and as the fallback inside
 // pickHeadAndTail for small pools).
 func pickTopN(cands []recommendation.Candidate, userID pgtype.UUID, dateStr string, now time.Time, n int) []rankedCandidate {
-	sorted := scoreAndSortCandidates(cands, userID, dateStr, now)
+	// songs_like, not daily_mix (#3881). produceSeedMixes is this function's
+	// only caller, so the switch moves exactly one surface — For-You ranks
+	// through pickHeadAndTail and keeps the broader daily_mix profile.
+	//
+	// The SAME profile does the selection sort and the final score. Passing
+	// one and using the other is the subtle version of this bug: the playlist
+	// would still be chosen by daily_mix and merely wear songs_like numbers.
+	weights := currentSongsLikeWeights()
+	sorted := scoreAndSortCandidates(cands, userID, dateStr, now, weights)
 	capped := capCandidatesByAlbumAndArtist(sorted)
 	if len(capped) > n {
 		capped = capped[:n]
 	}
 	rng := rand.New(rand.NewSource(int64(userIDHash(userID, dateStr))))
-	weights := currentSystemMixWeights()
 	out := make([]rankedCandidate, len(capped))
 	for i, c := range capped {
 		out[i] = rankedCandidate{
@@ -873,10 +927,11 @@ func pickHeadAndTail(
 	cands []recommendation.Candidate, seedOf map[pgtype.UUID]int, numSeeds int,
 	userID pgtype.UUID, dateStr string, now time.Time, headN, tailN int,
 ) []rankedCandidate {
-	sorted := scoreAndSortCandidates(cands, userID, dateStr, now)
+	// daily_mix — For-You is the broad surface and keeps the roaming profile.
+	weights := currentSystemMixWeights()
+	sorted := scoreAndSortCandidates(cands, userID, dateStr, now, weights)
 	capped := capCandidatesByAlbumAndArtist(sorted)
 	rng := rand.New(rand.NewSource(int64(userIDHash(userID, dateStr))))
-	weights := currentSystemMixWeights()
 
 	total := headN + tailN
 	if len(capped) <= total {