The CosmicSet release was finished on disk and could not move, because every
upload adapter goes through build_release_plan.py and that refuses to run
without a canonical www gig page. Writing the page by hand was never an option —
`feedback_metadata_vs_mastering` exists because a previous release copied a wrong
ALBUM string out of an intermediate script. So the generator learned to take
supplied facts instead.

--meta takes a JSON sidecar where every field is {value, source, locator, date}.
The builder reads the values, carries the provenance into `_provenance` in the
output, and prints "nothing left to invent" ONLY when no non-derivable field is
still empty. A bare value is accepted — PLN often just says a thing in chat —
but it is recorded as unsourced, so the gap stays visible instead of becoming
indistinguishable from a researched fact.

Which mattered immediately, because ONE OF MY OWN STRINGS WAS WRONG. The gig
spec said 2026-08-23. I had written that with no source. This machine held the
answer in two places all along: www/PRODUCT.md:21 says "cosmicfest_v2.67Hz
(20-23 August 2026, jour J Saturday 22)", and the invite's own lineup section is
headed "le 22 août, dans le jardin". PLN confirmed: "yea it was samedi 22
indeed". The spec is corrected and now says where the date comes from. That is
the second unsourced string of mine to survive into a spec, hence a sidecar with
a locator column rather than one more hand-filled field.

The set's five movements are not invented either: Ouverture / SUNSET / We call it
NuJazz / NUIT / FINALE come from PLN's own plan in backlog.md, which
`reference_gig_tracklist_sources` names as canonical. The sidecar records the one
discrepancy rather than smoothing it: the plan plays WAP second and the recording
has no WAP, so every section from track 2 on shifts up by one. Track 1 is 6.8
min, in line with other single tracks (3 is 6.6, 7 is 6.3), so it does not look
like two merged — but that is an inference and it is labelled as one.

Sample coverage went 7 empty lists -> 0, and the cause was not staleness. The
first two tracks I chased (Rose Rouge, LiveCode Parade) were absent from
catalog_view even after a rebuild, because catalog_view's track universe comes
from `load_gigs()` globbing the ALREADY-PUBLISHED content/lives/**/tracks.json.
A track's first gig page can therefore never find itself in the view: the file
that would add it is the one being written. That is a cycle, not a stale cache,
and rebuilding forever would not have fixed it. The builder now falls back to the
same `tidal_score.orbit_sounds` the view itself calls — one parser, reused, so a
new track's sample list cannot disagree with a catalogued one. With the page in
place the cycle closes: the rebuilt view goes 73 -> 81 tracks, dropping none, and
both tracks are catalogued.

Also: "collab" joins STYLE_DIRS, because OPAL already published it that way for
every live/collab/* score. style_of takes the last matching path part, so
live/collab/nova/techno/x still reads techno.