Music policy can point at specific sources — a Bilibili UP主, a channel, a playlist — beside the open search [spec 03-01 §2.3, ROADMAP line 3]

[wine-fall]

What it is

search_music is one open-ended keyword query, and it is a YouTube query: YtDlpMusicProvider.search runs ytsearch{limit}:<query> (src/music.ts:107), so a policy line like "reach for what a certain Bilibili UP主 uploads" cannot be honoured today — the words go to YouTube's ranking and Bilibili is never searched at all. The README's "yt-dlp, covering YouTube + Bilibili" is true only of resolve (a Bilibili URL plays); nothing in the pick can find anything on Bilibili. More generally there is no notion of a source the model can go to on purpose: whatever ranks first on an open search is what gets judged, and nothing vouches for it. ROADMAP.md line 3 already names the direction ("candidates from places worth trusting — a channel's uploads, a curated list — as additional tools beside the open-ended search"); #164 records the cost of fishing (three dead stream probes in half an hour, every pick 1.5–3.5× the spec-04 baseline). This issue is the listener-facing half of that line: let the music policy point at specific places.

What yt-dlp 2026.08.19 (the installed one) already offers, so none of this is a second provider:

• bilisearch{N}:<query> (BiliBiliSearch) — Bilibili search, the same shape as ytsearch.
• BilibiliSpaceVideo / BilibiliSpaceAudio — an UP主's uploads from a space.bilibili.com/<uid> URL, --flat-playlist gives the list.
• BilibiliSeriesList, BilibiliCollectionList, BilibiliFavoritesList — a series, a collection, a favourites folder.
• YouTube channel /videos and playlist URLs, the same way.

The shape that fits the existing seam (spec 03-01 §2.3: tools wrap MusicProvider, the policy directs the tools): one or two source-shaped tools beside search_music — e.g. search_music gaining a site: 'youtube' | 'bilibili' argument, and a list_source(url) that returns a channel's / UP主's / playlist's entries as candidates — with MusicProvider widened by the smallest step that carries them. The policy file then does the rest: a listener writes "for late nights, go to UP主 (space.bilibili.com/123) first", and the model has somewhere specific to go instead of fishing. Suspected, NOT verified: that a source-shaped candidate list also cuts #164's dead probes (an uploader's own list is likelier to resolve than an open search's top hit) — the measurement is part of the work.

Not yet investigated

• Whether bilisearch returns uploader / duration / view_count in --flat-playlist output the way ytsearch does (parseSearchOutput needs them to judge). If not, the judging signal has to come from a second call or the tool says so.
• Whether Bilibili space/series listing needs a cookie past a small page size (ties into ROADMAP line 5's credential work; not a blocker for the first cut).

Spec

specs/spec03/03-01-brain-harness.md §2.2 (MusicProvider) and §2.3 (music tools; the policy/contract split). ROADMAP.md line 3.

Done when

• A policy line naming a Bilibili UP主 (or a YouTube channel / playlist URL) leads the pick to call the source tool, and a now playing: line in .dev/dev.log shows a track from that source airing — read from the tool calls, not the model's narration.
• bilisearch is reachable from the pick (a policy saying "search Bilibili" produces Bilibili candidates).
• Unit tests for the tool shapes and the provider parsing of the new outputs; a real-seam smoke for each source kind.
• The measured pick time and dead-probe count against Music picks failing and running long: 3 dead probes, one 'nothing suitable', 82-192s picks in one session [spec 04 §3.3] #164's numbers go into spec 03-01, and this issue links to them.