feat(tide-table): a gig page can be generated without inventing anything
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.
Showing
This diff is collapsed.
Click to expand it.
This source diff could not be displayed because it is too large.
You can
view the blob
instead.
Please
register
or
sign in
to comment