feat(taste): the pick's half of the digest is chosen for the moment it happens in [spec 14]

[wine-fall]

Implements specs/spec14/14-listening-taste.md §2.12, frozen in #278. PR 3 of 3 — the last of the taste amendment (#278 the budget, #280 the ledger and the per-kind clock).

What changes

The flexible half rendered the same rows on every pick of the day: the newest 40 kept songs, whatever the hour, whatever had just played, whatever the listener had said a minute ago. Those rows are now chosen against the ledger for the pick that is actually happening.

Four signals, all already in the Director's hand — no tool, no extra call, no extra read:

signal	how it is used
the local hour	a bucket word (morning … late night) joined to the query
the persona's own words	joined to the query
the last talk beat	tokenised into the query terms
the last three songs' artists	an exclusion

Score (highest wins): 3 an exact artist or playlist-name match · 2 a prefix either way · 1 a term in the title/artist/album · +0.5 a music sub-zone · −1 when the last read of that row's own list no longer saw it. That last one is how an unliked song fades without the ledger ever deleting. Ties break by lastSeen, then the ledger's own order.

Relevance decides the order; the budget still decides the length. The rows the moment matched lead, and the rest of the line fills behind them.

The red lines

• In code, before the situation string is assembled. No new tool for the brain, no extra model call.
• The pick only. TasteReader.digest() stays the static, mtime-memoised render the context pack gives talk and steer; only buildMusicSituation passes a moment. The reader splits parsing from rendering, so a moment costs the render alone and never a re-read.
• Under 5 ms, asserted as the median of 15 warmed runs over a 4000-row ledger. A median, not a mean: one scheduling stall on a shared runner is not what the budget measures, and a mean lets that stall fail a green build (Flaky on CI: the session-mark invitation test races a 40 ms timer against a 1 s poll budget [spec 14 §2.7] #269 is what that habit costs).
• Degrades silently. No ledger, no match, no moment — the render is byte-identical to the one before this PR.

Performance

Tokenising every ledger row on every pick cost 4.3 ms of the 5 ms budget on a 4000-row ledger. Rows are scanned instead: title/artist/album lowercased once, then each term tested against it — a latin term at a word boundary, a CJK bigram as a plain substring, which is the same match shingling both sides produces. Same answer, no per-row allocation: 2.5 ms. The query side still uses recall.ts's exported queryTokens(), so the CJK bigram problem is solved once and not twice. No taste.db, no second FTS index, no node:sqlite on the pick path — §2.12 records the upgrade path if the assertion ever fails.

Tests

pnpm test 2045 passed (run twice); tsc clean; oxlint clean.

New test/sources-moment.test.ts (the bucket words, the stop list, the 24-term cap, CJK bigrams, the score order, the exclusion, the gone-quiet penalty, determinism), plus the render-level and reader-level tests, the §5.16 acceptance on the full-size fixture, and the 5 ms budget.

Peer review (codex gpt-6-astra): 4 findings, 4 applied, 0 dismissed.

1. [P1] The feature was dead in the real app. runApp spelled the Director's taste adapter out at the call site as digest: () => taste.reader.digest() — no moment parameter, so every real pick got the static render, while the Director tests injected a fake that does take the argument and stayed green. Exactly the seam CLAUDE.md warns about: green tests are not a delivered engine. The adapter is built in buildTaste beside the reader now, where the existing coverage reaches it, and a test asserts the forwarding.
2. The pick's avoid-list is up to 256 songs over seven days, not three. Handed over whole it deleted a week of artists from the selection and cost 10 ms of the 5 ms budget.
3. The candidate pool came from the ledgers alone, so a source whose ledger was missing, unreadable or empty lost its songs from the pick while the Sources line went on counting them. Per source now.
4. With no term matching anything the pool was still reordered by lastSeen — a read time every row of one refresh shares, so ties fell to insertion order and the block came out in an order the static render would never produce. No match now answers nothing.

A fifth, found by the acceptance test rather than the review: the exclusion compared the whole artist string, so Corin Vanterpool & Static Meadow survived after Static Meadow had just played. It is matched inside the credit at a word boundary now — a collaboration and a feat. go, a band whose name merely starts the same stays.

No listener data

Nothing from ~/.murmur is in this branch: no song, artist, playlist or channel name, no account name, no urls. test/fixtures/taste is untouched and was already invented. Checked before pushing — git log -p --all over the branch's whole history greps zero for the real titles, names and refs, and the diff adds no non-ASCII beyond typography.

AI coding brief

Original request. Make the taste data feeding the music pick accumulate and pick for the moment, as three sequential PRs on a settled design. This is PR 3: the moment-matched half, on decisions fixed in the grilling round before #278 froze the spec — the dynamic half serves the pick and not the pack; an in-memory linear scan reusing recall.ts's tokenising instead of a second FTS index; the four input signals; name matches above body hits; an unliked song fading by lastSeen; the artist just played excluded; no ledger meaning today's behaviour; 1500 characters; 5 ms.

Manual interventions. Two standing rules from the user shaped this PR without being restated for it: no content from ~/.murmur enters git, and a pre-existing flaky test is recorded rather than fixed (#269 — a fourth occurrence was added as a comment there, and its pointer line rides this PR). The user also reviewed #280 personally and sent back one defect, which is why this PR's own review was read for seam bugs rather than logic bugs — and the P1 above was exactly that.

Retro. The P1 is the lesson worth keeping: a new optional parameter on an interface is invisible to every test that injects a fake implementing that interface, because the fake is written against the new signature while production is not. When a change adds a parameter, the test that matters is the one over the production wiring, not the behaviour. Cheapest general fix, and the one applied here: build the adapter object next to the thing it adapts, inside an already-covered factory, instead of assembling it at the call site.

🤖 Generated with Claude Code