PLN: "this becomes our tooling, often a set will be postprocessed as we did —
reusable scripts and views plz". So the per-gig finish.sh is replaced by
spec-driven tools: a new gig is now a copy of judge_specs/<gig>.json, never a
copy of a script. POSTPROD.md documents the whole flow and the trap each stage
exists to avoid.

render_release.py — split every variant, verify durations and format, and
re-render the continuous mixes. Ran clean: 14 tracks x streaming+club, all
durations within tolerance, 48000/24.

Its `continuous` stage answers PLN's other catch: "imo the master club rec will
also have desire removed". A set is released TWICE — as tracks, and as the
unbroken mix — and cutting a track had only fixed the first; both continuous
masters still played Desire in full. This matters past tidiness: the continuous
upload is the lower-risk rights path (an isolated track was flagged on
SoundCloud where the 87-minute mix passed), so the mix is the artefact most
likely to ship and it has to match the tracklist. The excision derives its kept
spans from the same segments the tracks came from, so mix and tracklist cannot
disagree. Both variants now render to 4403.65s = 73.4 min, matching the sum of
the 14 tracks exactly:
    [1.45 .. 4166.30] 69.4 min  +  [4547.57 .. 4786.37] 4.0 min

build_release_joins.py — the confirmation pass PLN asked for ("i wanna confirm
all tracks start/ends/transitions"). It deliberately does NOT use the master:
once Desire is dropped, the seam a listener hears (CRIME straight into
REVOLUTION) exists only in the rendered output, and a master-based window there
would play six minutes of a track that does not ship. Building from the split
FLACs also audits the files that actually ship, so a split error surfaces before
upload rather than after. 15 clips: the record's opening, 13 seams, and its
closing.

apply_boundaries now emits the splitter's native shape — `track` is RELEASE
position because tidal_ears.master split uses it for both filename and the
`track=N/total` tag; performance order stays as `perf_track`. Emitting
performance order would have named the last file "15 - REVOLUTION" in a
14-track album and tagged it 15/14, which stores reject.

Both UI sets pass bounds-smoke (11 assertions each). The test now derives its
data file from the page's own ?set= — hardcoding it meant it could assert
against a different set than the browser had loaded, passing or failing for
reasons unrelated to the code.