I wrote in 038 that `nohup … &` inside a tool call does not survive, on the
evidence of an empty logfile and no matching process. Both were artefacts, the
diagnosis was wrong, and acting on it cost considerably more than the dead job
I thought I was recovering from.

The log was empty because Python block-buffers stdout to a file. No TTY means a
~8 KB buffer, and PYTHONUNBUFFERED=1 was set in the systemd unit but not on the
nohup line, so forty minutes of genuine work produced a zero-byte log. The process
appeared missing because rtk silently dropped the grep; `rtk proxy ps` showed it
immediately, reparented to PID 1553 — the user systemd manager — and well into its
render. RTK.md says to fall back to `rtk proxy` whenever output looks suspiciously
empty, and I skipped that on the one check the entire conclusion rested on.

So I started the same 63-minute render a second time. For roughly forty minutes two
processes wrote the same output paths, racing on Cosmic26_v1_streaming.flac and
master_report.json. Nothing warned me; it surfaced only because two ffmpeg
processes turned up at different pipeline stages, which is luck rather than a
designed tell. Killed the unsupervised duplicate by PID, removed its 102 MB partial
FLAC so cosmic-finish could not split a truncated file, and let the journaled unit
carry on. The unit has since reported attempt 1 cleanly: pre-gain +11.6 dB giving
I=-15.94, TP=-1.00, LRA 8.30 down from 10.60 — dynamics substantially intact.

Two rules earned the hard way, both recorded in
reference_durable_background_jobs alongside the retraction. An empty logfile is
not evidence of no progress: use `python -u` or PYTHONUNBUFFERED on anything whose
log you intend to read. And before starting a replacement for a job you believe is
gone, PROVE it is gone — via `rtk proxy ps` or the unit's own cgroup.procs —
because a duplicate writing the same paths is a corruption risk, not merely wasted
CPU. feedback_check_the_instrument_first and feedback_absence_needs_proof both
applied here and I honoured neither.

What the episode does not undermine is the house rule, which stands on its own
evidence from the same night: systemd --user units outlive the session. Every
harness background waiter and monitor I had armed was killed at a between-turn
teardown, while all three cosmic-* units kept running untouched. That is the reason
to use them. The nohup story was never the reason.

PLN went to bed with the CosmicFest pipeline in flight. This is the block a cold
session needs to pick it up without reconstructing anything, written because the
run outlives the session that started it.

The teardown test came back the way the design hoped: every harness background
waiter in that session was killed between turns, while all three systemd --user
units kept running untouched. So the resume instructions lead with systemctl and
journalctl rather than with anything session-local, and the expected end state is
listed in full — masters, both split directories, eda_stems.json,
master_report.json, FINISH_SUMMARY.txt, and the section plus global stems — because
cosmic-finish.service is ordered After= both producers and gets there on its own.

Two progress metrics are recorded as WRONG, since I used both and both fooled me.
Counting directories under stems_demucs/sections/ counts sections STARTED, not
finished: the directory appears the instant chunked_separate opens its four
writers. And libsndfile buffers, so a stem file sits at 44 bytes — a bare WAV
header — through minutes of genuine work. I read "4 of 14 done" off the first and
put a speed claim in commit 37eb401f on the strength of it. Judge by mtime and
flushed bytes, or simply by whether the unit is still activating.

The board now also names the first question to ask of the EDA, because it decides
a parameter that is currently an admitted guess. The air shelf sits at +5 dB
against a measured 8-16 kHz share of 0.12%, which on its face justifies far more;
it is held back because a 320 kbps MP3 puts codec hiss in exactly that band. The
EDA prints the verdict: HF concentrated in drums by 2x or more means cymbals and
the shelf can open, HF spread evenly across all four stems means noise and it
stays shut. Re-rendering on that basis costs nothing, since PLN has not yet heard
any of it — which is the one moment such a change is free.

Blockers are ordered by what actually gates a shipment. First is the canonical www
gig page, because build_release_plan refuses without it and every upload adapter
reads that plan; the derivable half is already drafted, so PLN owes four
frontmatter fields and the set's movements. Then the tone, which no measurement
settles. Then three smaller calls, and the still-unreviewed merge 2f947c2c.

Recorded as ready-but-deliberately-undone: OPAL's SoundCloud is 7 of 15 tracks
short and the re-run is idempotent, but PLN was sharing OPAL links that evening
and mutating the account under him was the wrong risk to take unattended. And a
standing warning against uploading CosmicFest's split before he approves the tone —
SoundCloud is idempotent by permalink, so a v2 re-render is silently skipped
rather than replaced, which is the take-five-drops defect waiting to happen
fourteen more times.

Log 038 — "A record from one microphone" — is the night CosmicFest went from
"educated guess game", PLN's phrase, to a pipeline. It carries the measurements
that reshaped the job and a correction to my own previous commit.

eda_stems.py is the mastering EDA a stemless gig could not otherwise have, and it
exists to answer three specific questions rather than to print statistics.

Is the 8-16 kHz deficit cymbals or codec noise? The master measured 0.12% of
total energy up there and the air shelf was deliberately held to +5 dB instead of
the +12 the deficit suggests, because a 320 kbps MP3 puts hiss in that band
alongside hats. A broadband boost cannot tell the two apart; a per-stem view can.
If the HF lives in `drums` it is cymbals and the shelf can open, and if it is
spread evenly across all four it is noise and the shelf stays shut.

Where is the kick? project_floor_problem measured the kick audible in only 59% of
OPAL-26, from real orbit stems. This asks the same question of a gig that has
none, via 40-120 Hz activity over time, thresholded relative to each track's own
p95 rather than an absolute dBFS — a fixed threshold on a quiet room-coloured
source measures the recording level, not the kick. Reported per track so a floor
that drops out gets named instead of averaged away.

And how much does local-versus-global separation actually differ? It compares
each section's stem against the same span cut out of the global stem:
correlation says whether the model made the same decision, the RMS delta says
whether normalisation changed the level. That comparison is the reason the
chunked writer had to be length-exact.

Presence is gated before any stem is compared to another, and demucs' own source
names are treated as hypotheses — feedback_label_and_lens applies to a
separator's labels as much as to a sample's filename.

finish_cosmic.sh + cosmic-finish.service exist because of a structural mistake I
nearly shipped. The master and demucs runs are systemd units so they outlive the
session, but every step AFTER them — split, verify, EDA — was sitting in my
session. PLN said "your autonomous now going to bed tell me results tomo", so a
teardown would have left him with rendered masters and nothing else. The unit is
ordered After= both producers, so systemd does the waiting instead of a polling
loop, and it leaves FINISH_SUMMARY.txt on disk that stands on its own. Wants=
rather than Requires=, deliberately: a club-target miss or a demucs failure must
not cancel the split of a perfectly good streaming master.

The log also corrects commit 37eb401f, which claimed the chunked demucs path was
about twice as fast. It is not, and the claim came from a broken metric: I counted
directories under stems_demucs/sections/, but a directory appears the moment
chunked_separate opens its writers, so the count measures sections STARTED, not
finished. libsndfile buffers on top of that, so three of four in-flight sections
sat at 44 bytes — a bare WAV header — after nine minutes of genuine work.
Measured properly by mtime and flushed bytes, a worker runs at about 4.3x
realtime under four-way contention plus the master render. Chunking fixed the
OOM kill; it did not demonstrably make anything faster.

build_release_plan.py refuses to emit anything without the canonical www gig
page, with the right message: "Gig metadata is never invented here — create it
there first." Every upload adapter reads that plan, so one missing file blocks
SoundCloud, YouTube and Bandcamp at once. CosmicFest 2026 has no page, which
makes that gate the single thing standing between a finished master and PLN
hearing it on the platform he asked to hear it on.

The gate is correct and this does not weaken it. It splits the file along the
line the gate cares about instead of blurring it:

  derivable   name, file, bpm, start/end/duration, style, samples
  PLN only    the gig's title, venue, stage, description, and each track's
              `section` (the movements of the set)

Everything in the second group is emitted as null with a `_needs_pln` list, never
as a plausible guess. The output is a DRAFT at whatever path you pass; promoting
it into the www repo stays PLN's call. So tomorrow is four fields and a review
rather than an afternoon of reconstruction.

Derivations reuse what already parses the corpus rather than re-reading it:
`style` comes from the score's own directory, which is how OPAL's published
styles line up with the tree, and `samples` comes from catalog_view.json's
`score_sounds`. A score absent from that view is REPORTED, not handed an empty
list — an empty sample list is invisible once it is on the shelf, which is the
whole lesson of feedback_parsers_over_copy. Seven of CosmicFest's fourteen are
currently absent because the view is stale; re-running build_catalog_view fills
them.

The derived timecodes then validated themselves against PLN's own ear notes,
which is the reassuring part. Piment Bresilien lands at 0:35:46 against his
playhead comment "starting at 35:45.6 i hear proper only piment start sound",
and LiveCode Parade at 0:54:58 against the 54:59 note where crossmatch had
guessed gimme_acid and the declared 130 BPM broke the tie. 14 tracks, 63.0 min,
30 sample packs, 89-170 BPM.

The first run died at 8.2 GB peak, killed by the kernel, having finished two
sections in 32 minutes of wall clock and nearly five hours of CPU. The arithmetic
was there to be done beforehand and I did not do it: a 532-second section is
188 MB of input, 750 MB of output across four sources, and apply_model's overlap
accumulator wants that again — call it 2 GB, times four workers, on a machine
already holding 18 GB of someone else's Gradle builds.

The fix was already written, in the other half of the same file. `global_pass`
chunked its work specifically because a 63-minute tensor would need ~12 GB, and
sections needed exactly the same treatment for exactly the same reason. So the
two modes now share one applier and differ only in which normalisation statistics
they are handed — which is the entire local/global distinction anyway, since
htdemucs' receptive field is 7.8 s and neither mode can give the model more
musical context than that. Sections pass their own stats; the global pass passes
the whole recording's.

Chunking turned out to be faster as well as smaller: four sections landed in the
time the unchunked version took to finish two, presumably from allocating a few
hundred MB repeatedly instead of gigabytes once. Memory peak is now 5.45 GB.

The unit also grew MemoryMax=10G / MemoryHigh=8G. A bounded algorithm should not
need it, but a cap turns any future regression into a failed unit rather than the
kernel choosing a victim on PLN's desktop while he sleeps.

Two details kept from the global implementation because they are load-bearing:
the chunk seam is joined with an equal-power ramp, since it sums two estimates of
the same audio and a linear fade would dip 3 dB right at the join; and the output
is length-exact, verified at 3969000 frames on all four stems for a 90 s input,
zero drift. That second one matters beyond tidiness — the EDA pass seeks into the
global stems by absolute time to compare them against each section, so any
accumulated drift would silently misalign every later track.

Also discarded the two sections the old code had produced. They were valid
separations, but they were made by a different code path, and a local-versus-
global comparison built on a mixed dataset would have a confound in it that no
amount of care downstream could remove.

Both exist because CosmicFest is one stage-mic MP3, and the house pipeline
assumes twelve Ardour orbit-stems.

demucs_sections.py — per-track stems plus a global pass, PLN's ask: "to see how
both are interpreted locally and globally". One measured fact decides what that
comparison can show. htdemucs' receptive field is 7.8 s (model.segment = 39/5)
and it always splits internally, so a 63-minute file gives the model no more
musical context than a 4-minute one. The local/global difference is therefore
NOT context — it is input normalisation, since demucs normalises by the mean/std
of whatever you hand it. On this gig that is a real lever rather than a nitpick:
the set sits at -25.2 LUFS with 11.1 LU of range, so quiet sections get far less
gain under whole-set statistics than under their own.

So global mode computes the normalisation over the entire recording and then
applies the model in bounded chunks with those statistics. That isolates the one
variable that can actually differ, in about 1 GB instead of the ~12 GB a single
63-minute tensor needs (four sources x 1.33 GB of output, plus apply_model's
overlap accumulator, against 12 GB free). Chunks overlap and are crossfaded with
an equal-power ramp — the seam is two estimates of the same audio summed, so a
linear fade would dip 3 dB in the middle of it.

Written against demucs' Python API rather than its CLI, because the CLI cannot
save here at all: torchaudio 2.10 routes writes through TorchCodec, which is not
installed, so `python -m demucs` separates for 87 seconds and then dies on
ImportError. Going through apply_model and soundfile also avoids installing
anything into PLN's venv to work around it.

Validated before launching a six-hour job: 30 s slice, four stems written, all
populated, and sum-minus-original sits 27.4 dB below the signal. Vocals came
back at -50.6 dBFS RMS on an instrumental passage — correctly near-empty, which
is the kind of agreement that makes later disagreements worth trusting. Runs as
a systemd --user unit per reference_durable_background_jobs, niced with idle IO
so it can never be why the rig stutters.

master_stemless.py — MASTERING.md's chain with the per-stem half removed and one
stage added, because the measurement demanded it. Full-file analysis first:
L/R correlation 0.833 (genuinely stereo, so bass-mono is safe), sub-30 Hz is
0.07% of total energy (the HPF is free headroom), and then the finding that
reshapes the job — 300-1000 Hz carries 34.75% while 4-8 kHz has 1.75% and
8-16 kHz has 0.12%. That is a microphone in a room, not a desk feed: the PA's
treble never reaches the mic, the room absorbs what does, mid-bass piles up. The
tape is dark and boxy, not merely quiet, so the dominant move is a broadband
tilt rather than gain.

Restraint where the numbers cannot justify enthusiasm: the air shelf is +5, not
the +12 the deficit suggests, because a 320 k MP3 puts codec residue in that band
alongside cymbals and a big boost lifts hiss into the master. The demucs stems
are the lens that can tell those apart; until they answer, the shelf stays modest.

Bass-mono runs in mid/side, not by splitting and re-summing bands: a lowpass(120)
summed with a highpass(120) leaves a phase notch at the crossover, whereas
high-passing the side channel alone never filters the mid path.

Two failures worth keeping. First, the club target with the limiter placed before
any gain: the signal reaching it still peaked at -9.5 dBTP, so a -1 dBFS ceiling
never engaged, and loudnorm's linear=true — correctly refusing to breach TP —
capped the master at -11.2 LUFS against a -9 target. The gain has to come first
so the limiter has something to catch. Second, that fix alone still undershot,
because every dB the limiter absorbs is a dB the final loudnorm cannot add; the
shortfall IS the missing gain, so feeding it back converges. Bounded at three
attempts and guarded by an LRA floor, since a loudness target reached by
flattening the music is not reached — presence_is_a_precondition, applied to
dynamics.

On the 90 s trial the streaming target lands at -14.0 LUFS, peak -1.0, with
1.8 LU of range lost. The club target stops at -10.5 with the floor tripped, and
reports the miss instead of clipping its way to a number. Whether -9 is
reachable on the full set, whose LRA is 11.1 rather than the slice's 4.6, is a
question the full render answers.

R-0 and C-0, the two moves the release board put ahead of everything else.

R-0. The CosmicFest master existed in exactly one place: ~/Downloads. It is now
in Prod/Cosmic26_master/ and mirrored to the freebox, sha256 7a197589…d671b
identical on both, and the Downloads original was removed only after both copies
were verified — a move, not a hopeful mv. feedback_freebox_ssot names the freebox
as the SSOT for audio, and an irreplaceable 63-minute gig in a scratch directory
was the cheapest large risk on the board. The spec records the naming trap that
nearly cost an hour: Prod/cosmicfest/ and Prod/cosmicfestv0.live1.* are the 2025
edition, files dated 2025-06-27/28, and nothing in them belongs to this release.

C-0. POSTPROD.md's rule is that a new gig is a copy of judge_specs/<gig>.json and
never a copy of a script — so the question was whether a gig with NO stems can
use the pipeline at all. Answered by reading the code, not by trying it and
hoping: apply_boundaries and render_release touch no stem key whatsoever, only
segments/master/variants/releaseRoot/releaseTag. The single tool that genuinely
needs stems is build_judge_set, which derives nominal segments from per-orbit
activity. That is the one hole, and setlist_to_segments.py fills it.

The converter turns judge_specs/<gig>_setlist_ear.json into the two inputs
apply_boundaries wants, and its real job is keeping two grades of truth apart.
The setlist silently mixes them: some starts are playhead calls PLN made while
listening, others were reconstructed from his notes on boundaries he SKIPPED.
Only the former go into `verified`, so apply_boundaries prints ear or nominal per
row and asserts every playhead call reached the output. An inferred edge can
therefore never be mistaken later for one he actually heard.

That distinction immediately corrected the board. It had named #10 and #12 as the
soft edges, taken from the recovered tracklist's unresolved list. The setlist ear
file supersedes that: ten starts (#2-#11) are playhead calls, #1 is the origin,
and the inferred ones are #12 LiveCode Parade, #13 Vague de CRIME and #14
Outro: La Dub Sirène. #10 PunkAChien was ear-called all along — "perfect cut at
48:27.4 into PunkAChien!". Three tracks to audition, not two, and a different
three. The board also claimed 11 decided boundaries; there are 10.

Titles resolve authored -> OPAL-release -> catalog -> NEEDS_PLN, and never by
title-casing a slug. The authoritative source for a shared track is what actually
SHIPPED: OPAL-26's ear-signed segments_v4.json joined to that gig's tracks.json
on performance order, since neither file alone holds both the score path and the
released title. Four tracks were in no shipped release and no catalog entry, so
the first run emitted them as NEEDS_PLN rather than inventing anything; PLN then
gave all four, and they live in judge_specs/cosmicfest-2026_titles.json with
value+source+locator+date per feedback_metadata_provenance. The same file carries
a `score` alias, because the gig slug "mafia" is mafia_sans_serif.tidal — and
that alias then cross-checked itself, yielding a declared 160 BPM that matches
OPAL's Mafia exactly. Outro: La Dub Sirène has no .tidal at all, being a played
outro rather than a composed track, which is also why the catalog can never hold
its title: the catalog is keyed by score path.

`album` is deliberately absent from the spec. CosmicFest 2026 has no page under
content/lives/2026/, so there is no canonical set title to copy, and inventing
one would be exactly what feedback_metadata_vs_mastering forbids.

The source measures better than "raw stage mic with FOH effects" suggests:
I = -25.2 LUFS, true peak -5.1 dBFS, LRA 11.1 LU over the full 62:59. Not
clipped, not crushed, just quiet — reaching -14 LUFS needs about +11 dB and
therefore limiting, but that is a gain problem rather than a repair job. Recorded
in the spec's sourceProvenance so the next pass starts from the number.

apply_boundaries output: 14 tracks, 63.0 min kept of a 63.0 min master, zero
gaps, all assertions green. variants still point at mastered files that do not
exist; the mix is the next step and render_release will say MISSING until it runs.

PLN reframed the north star: not one release but four deliverables — {OPAL,
COSMIC} x {continuous club mix, per-track album split}. The board only tracked
OPAL, so this amendment measures both sets against the same scorecard instead
of recalling their state.

The four questions he asked, answered from the filesystem rather than memory:
boundaries are DONE for BOTH sets (OPAL ear-signed 2026-08-16, CosmicFest
2026-08-29 — 11 playhead calls plus 8 skip notes). The mix is done and
ear-reviewed for OPAL only. CosmicFest has had zero mastering: its ear pass
settled WHERE the cuts are, never HOW it sounds — there is no mix to review.

Two findings worth more than the status table.

The CosmicFest master has exactly ONE copy, and it is in ~/Downloads. 151 MB,
not on the freebox, not in Prod/. feedback_freebox_ssot says the freebox is the
SSOT for audio; an irreplaceable gig recording in a scratch directory is the
highest-risk, cheapest-to-fix item on the whole board. Filed as R-0, ahead of
all processing. Adjacent trap recorded too: Prod/cosmicfest/ and
Prod/cosmicfestv0.live1.* are the 2025 edition (files dated 2025-06-27/28) —
nothing there belongs to this release, and the names invite exactly that error.

And the tape is far better than "raw stage mic with FOH effects" implies.
Measured with ebur128 over the full 62:59: I = -25.2 LUFS, true peak -5.1 dBFS,
LRA 11.1 LU. The peak says it was recorded conservatively and is NOT clipped;
the 11.1 LU range says the desk did NOT crush the dynamics (a mangled feed lands
under 6). It is simply quiet — reaching -14 LUFS needs ~+11 dB and therefore
limiting, but that is a gain problem, not a repair job. PLN's "80/20 likely" is
reachable; what is genuinely impossible is a premix, because one stereo file has
no stems and none of OPAL's per-orbit surgery has an analogue.

The keystone follows from POSTPROD.md's own rule — "a new gig is a copy of
judge_specs/<gig>.json, never a copy of a script". That file does not exist for
CosmicFest, and BOTH of its deliverables sit downstream of it. One wrinkle to
settle while writing it: OPAL's spec assumes stems (stemsDir, stemmap, keeps,
clipsDir) and CosmicFest has none, so the stemless path must be verified rather
than assumed.

Six decisions are logged as PLN's, not the tooling's: the still-unreviewed merge
2f947c2c; whether the A2 REVOLUTION fix is worth invalidating the A1.7 signoff it
would force a re-render of; whether "Outro Dub Siren" is an album track or
mix-only; the two soft CosmicFest edges (#10, #12) inferred from skip notes
rather than called on the playhead; the rights ledger re-measured at 103 banks
(43 third_party, 31 unknown, 19 dirt_samples, 10 cleared), which gates the split
but not the mix; and artwork, still unchosen for both.

Also traced the collab thread: piment_bresilien is in BOTH sets — OPAL track 07,
already on SoundCloud, and CosmicFest #7 at 2145.6-2525.4 on a playhead call.
Its score carries one uncommitted edit, line 33, |+ note 12 becoming |- note 12.

Brings the v3 control surface work onto master, as PLN called it: "this is the
new tooling/state". The arc is one idea repeated — the driver owns the truths
the hardware refuses to keep.

- it plays: four defects between the driver and a live SuperCollider, all of
  them identity bugs (a port's NAME is not the port)
- it speaks a language: role hue x value lightness, the DJF's diverging
  blue -> breathing-green-zero -> red, glowing at the track's tempo
- it holds state the v3 board dropped: offset-64 relative values, row-E
  latches, paint reasserted every two seconds
- it says what each control DOES, in PLN's own words parsed from his .tidal
  ("Le Delay rose!!!", "HANDS IN THE AIR"), across all 34 display targets
- it follows the track: the editor already published it, the driver only had
  to read — remap, relabel, repaint and reset the lap clock on a change, and
  re-read on save so mapping a control lights the board within a second
- the tempo can be a knob, with landmark detents replacing the notch the v3
  encoders lack, and a bar countdown for the mute-drop transition
- and the rig around it: Ardour hears the surface again, RIG UP owns the
  ordering SuperDirt needs, midiviz replaced the transcript with a picture

Also aboard: a display-semantics probe that asks the device instead of us
guessing, realtime.tidal for composing without the crossfade, and the corpus
marked for quantise at all 14 tempo-knob sites.

Backward compatibility is the standing constraint and it holds: the corpus
speaks v2 forever, everything v3 lives in the driver, and a classic Launch
Control XL still works with nothing running.

PLN wanted `$ realtime` as a prefix. That shape cannot work: `realtime $ d1 $
pat` parses as `realtime (d1 pat)`, and d1 has already applied its transition
by then, so nothing in that position can undo it. What does work ships here:
`rt 1 $ ...` for a single transition-free launch, a one-line `let` that shadows
d1-d12 for the session, and the exact restore. No BootTidal edit, so tomorrow's
boot cannot break on tonight's untested Haskell — every line is copied from
BootTidal's own definitions, and the file says plainly that it has not been
through GHCi yet.

Also written down where he will find it again: the retrigger he blamed on the
crossfade is `resetCycles` sharing a block with the patterns, and the real fix
for the mode (an IORef compose/perform toggle, promoted into BootTidal) is
tomorrow's C-1.

PLN, after seeing the OLED refuse to claim a round number: "quantise would make
sense mark a todo on the tracks sept1 and this commented line replace it with
quantize commented too. where its possible".

The measurement behind it: the house idiom `# cps ((range 60 180 "^29")/60/4)`
spreads 120 BPM across 128 CC steps at 0.94 BPM per step, so exactly 120 is
unreachable — step 63 is 119.5 and step 64 is 120.4. Wrapping the range in
`quantise 1` makes round tempos land exactly AND gives the knob a real two-step
detent at each one, which is the notch the v3 encoder lost.

Two treatments, deliberately different. A LIVE cps line is not edited — the
tempo is playing and this is his set material; it gets a TODO on its own line
above. An already-COMMENTED one is rewritten in place to the quantise form,
still commented, so uncommenting it gives round BPMs from the first click.

The TODO goes on its own line and never as a trailing comment, because the
driver's parse_context uses a line's trailing comment as that control's OLED
label — a trailing TODO would have renamed the tempo knob "TODO(tempo): wrap
the range..." on the screen. The first draft of this change also hard-coded
"60-180" into files whose ranges are 75-165, 100-166, 99+-20 and 60-124; it was
reverted and rewritten range-agnostic before landing.

Verified all 14 matches are genuinely tempo knobs (including one `cpsbus 4`
variant in ragga_la_hierarchie), not incidental cps-and-range coincidences.

The documentary entry for the night the driver stopped being a one-track
instrument: the follow bus that already existed and nobody had read, PLN's
carry policy in his own words, the tempo knob that became the clock, and the
transition move the screen now serves. Plus the three findings that cost only
reading (an innocent v2 service, MIDIIn.connectAll, a disproven off-by-one) and
the two traps worth retelling (the detent that welded itself to the first notch
twice, and zsh eating the backticks out of a commit message).

Three rounds of screen fixes were hypotheses dressed as patches: the lap clock
is frozen at 0:00 on glass while our ghost ticks, and the DJF Hz readout
"refresh maybe every 1s, not smooth at all". Both point at one unproven rule —
that a field write to an ALREADY-VISIBLE display target does not repaint
without a bring-up — and the protocol offers no display readback, so the only
instrument that can settle it is PLN's eyes, asked precise questions in order.

So: a guided probe. Each step prints an instruction, sends a minimal
distinguishing sequence, and records what he saw; the run ends with a table and
a verdict naming the surviving hypothesis, plus JSON in the scratchpad so the
answers outlive the session. --dry-run prints every byte with the hypothesis it
tests, so the whole thing is reviewable without hardware.

It distinguishes: bring-up NONE/AFTER/BEFORE/RECONFIG on the stationary target;
the same on the temporary target plus a 20/10/5-per-second rate ladder (which
directly decides the DJF smoothness fix); whether per-control targets can be
driven while untouched; which auto bit actually summons; and an arrangement
census with a SENTINEL, so an arrangement the firmware IGNORES reads as "still
the sentinel" instead of masquerading as a real layout — without that, "ignored"
and "renders like the previous one" are the same observation and the census
would invent arrangements that do not exist.

Two things it found by reading our code, before touching the device. The
targets showing both symptoms are on arrangement 2, not the 4 we describe in
our own notes (4 is only label_control's default). And CFG_BRING_UP = 0x7F is
arithmetically ARR_TRIGGER | AUTO_TOUCH | AUTO_CHANGE, so every bring-up may
RE-ARM the auto-display bits we deliberately clear on the three DJF knobs —
which would explain, mechanically, why the firmware's number keeps reappearing
over "HPF 3.4kHz !!". That became its own probe step.

Safety, since the rig is live: display and config SysEx only, enforced by an AST
check that there are zero cc/note/rgb/feature call sites plus raisers installed
over those methods at open time; it refuses to run while the driver is up
(printing the pid, the kill, and the restart line); and it restores the
arrangement the driver expects from a finally block.

NOT YET RUN ON HARDWARE — committed so the work is not parked in a scratchpad.

PLN: "ok lets list my demands not handled yet and ensure we track all tasks and
ergonomic issues to improve". So the register: every open ask with his own words
attached, stable IDs, grouped by what unblocks what — and the honest note that
ONE probe run at the desk unblocks five screen items at once.

The fix came out of writing it. nouvelle_couleur.tidal carries a parked tempo
knob, a commented `# cps ((range 60 180 "^29")/60/4)`, and the mapped-set
scanner read commented lines — so B1 glowed on a board whose oldest rule is
"dark = unmapped". parse_context already skipped comments; parse_track now does
too. Live: 12 controls -> 11, 18 lit cells -> 17, B1 dark. Uncomment the line
and the next follow tick (under a second) lights it and the tempo readout
appears with it.

Also recorded: the v2 lcxl-leds-watch service has been logging "no LCXL
sequencer port" every 30 s since 22:39 — its name regex cannot match "LCXL3 1",
so it has never touched the v3 board. It was my prime suspect for the
paint-reset mystery and it is innocent; that mystery is reopened with no
suspect. The Midi-Through to SuperCollider re-add is explained though:
MIDIIn.connectAll, re-running on sample reload, exactly as
midi-autoconnect.sh's own header warned it would.

The driver parsed its .tidal once, at launch, and never looked again. PLN said
it three ways in one session: "i see still ROSE_ROUGE in title", "why dont i
see the lcxl colors evolve as i map buttons on the new track", "probably this
will be an opp to confirm you read current file well". One bug, three faces.

FOLLOW. The editor has published the loaded track for a while
(~/.cache/parvagues/current-track, written by the HUD) and logs every
ctrl+enter (eval-events.jsonl). The driver needed no new channel — it needed to
read. It now polls both once a second: a different path is a track change
(remap, relabel all 32 targets, repaint, reset the lap clock), and a changed
mtime on the SAME path is a re-read, so mapping a button and saving lights the
board within a second. --no-follow pins the old behaviour.

CARRY POLICY, PLN's spec verbatim: "faders are real positions, but could we
reset the knobs to 'defaults' on all effects? and maybe teh DJFs stay across
tracks so i can do djf-and-fader-crossfaded-transitions". So DJFs carry (they
ARE the transition), effect knobs go to 0, faders are physical and untouched.
Two cells carry that he did not name, because the sound would have taught us
the hard way: the TEMPO knob (resetting it means the range floor — a 60->120
transition would slam back to 60 exactly when the new track lands) and every
button (emitting to a gate is the mutebomb; latches reset in the driver so the
LEDs stop lying, but nothing is sent).

LIVE TEMPO. sept1's idiom `# cps ((range 60 180 "^29")/60/4)` makes B1 the
clock — and it steered the tempo all last session while the OLED said "B1
unmapped", which is the whole argument for following the track: the sound was
right and every label lied. The BPM is now derived from the knob, and bar phase
is INTEGRATED rather than read off the wall clock, because `time.time() * bpm /
60` re-scales all of history whenever the tempo moves — the countdown would
have jumped precisely mid-transition, the one moment it is read.

THE MOVE. PLN: "start holding kick mute, move kick to the 120bpm position (i
used the center notch, now ill rely on OLED), drop kick mute at end of a bar".
So the screen becomes the notch: BPM not wire units, an arrow to the nearest
landmark that vanishes when he is on it, and — while a mute is held — the bar
countdown ("DROP kick / ~120 BPM >2"), with the ring breathing at the beat to
count it in. The bar is real, not guessed: `resetCycles` shares a block with
the patterns, so every ctrl+enter IS cycle 0 and the eval log is a phase anchor.

Plus software detents, since the v3 encoder has no ridge: a deliberate single
click that would cross a musical tempo lands ON it and holds for two more
clicks; fast sweeps pass through untouched. Two versions of that welded the
knob to the first notch it met (the closest STEP to a landmark sits just below
it, so stepping up re-crossed it and snapped back — measured, 24 consecutive
clicks stuck at 114.8 BPM); the fix tracks WHICH landmark holds us by identity
and releases only once the value has actually left it.

And the mute overlay finally reports the whole held SET ("MUTE x2 /
kick+percs", "all") instead of the last finger down.

Honesty notes: 60-180 over 128 steps is 0.94 BPM/step, so exactly 120 is not
reachable (step 63 -> 119.5, step 64 -> 120.4). The readout prints "~120" for
the closest step and a bare "120" only when it is exact. A track wanting true
round tempos can quantise in the pattern:
`# cps ((quantise 1 (range 60 180 "^29"))/60/4)` — then two steps both land on
120 and the detent is the music's, not the driver's.

Also closed by evidence rather than code: A1's label is correct ("d9 level
[ard]" — the grid puts d9-d12 on row A, faders carry d1-d8), so the suspected
off-by-one that sat on the board was never real.

Ground-truth pass found lcxl-leds-watch.service (the v2 LED watcher) still
running beside the v3 driver — the likely author of the paint-reset mystery —
and midi-autoconnect as the probable Midi-Thru→SC re-adder. Plan: kill the
tug-of-war first, then the A1 label off-by-one, then the generalize thread
PLN named (track-follow + live BPM from the cps knob), then the display
probe with his eyes on the device.

sept1.tidal proved the architecture mid-set: translation is track-agnostic
(the cps knob on ^29 changed tempo with the driver still mapped for
rose_rouge), so playability generalizes for free and only paint/labels/BPM
are per-track — exactly the next thread. Fresh eye-batch bugs boarded with
the discipline note: READ label_control before believing the off-by-one.

The Pinterest bloom gif is one-way (bud → full rose on black), so a
plain loop snaps. Four loop treatments now sit in visuals/scenes/,
auditionable live by swapping the header directive (ctrl+s reapplies):

  rose_bloom          ping-pong at half speed, mci-interpolated —
                      the rose breathes open/closed over ~13.5s (default twin)
  rose_bloom_fast     ping-pong at native speed (~6.8s cycle)
  rose_bloom_rebloom  seam-crossfade: blooms again every ~2.5s
  rose_bloom_noir     fade through black, cinematic gap

Recipes (ffmpeg): ping-pong = split+reverse+concat with boundary frames
trimmed; slow = setpts 2x + minterpolate mci; rebloom = xfade against
itself, trim [fade, offset+fade]; seams verified by first/last-frame
RMSE (0.028 = codec noise for the ping-pongs).

Source renamed to ~/Downloads/rose_bloom.gif (stable stem for the
twin lookup).

Two things, one restart.

The 10-second home-refresh ticker read last_home, which was never initialised:
my init patch targeted the pre-merge line and the merged code had renamed it
(last_labels joined the chain), so the replace silently no-opped — I had
asserted every replacement in that patch EXCEPT this one. The driver died at
its first tick, 10 s after start, while the surface kept showing the labels
the startup had already written: a dead translator behind a live-looking
display. Fixed, and verified past the tick this time.

And the stuck "0" PLN saw on row 3: arrangement 4's numeric value is drawn by
the FIRMWARE from its own internal control value, which never moves for a
relative encoder — the driver owns those values now. So the driver echoes each
integrated value back to the device on the encoder's own CC (plain DAW-style
feedback). --no-echo exists in case the echo ever fights the RGB paint; the
2 s paint reassert heals any skirmish regardless.

Next display experiment, deliberately not built blind: arrangement 1
(host-supplied TEXT value) on per-control targets, which would let
probability-style constructs (sometimesBy / someCyclesBy / midiOn ranges)
read as percentages instead of 0-127.

PLN, from the chair: seated, OLED row 2 reads clearly and row 3 hides behind
the bezel. So the information hierarchy now follows the sightline, not the
protocol's field order:

- HOME: track name / "118BPM 4:32" / ParVagues. The drip moves to the bezel
  row; tempo and TIME PLAYED take the prime row. The elapsed counter is the
  overstretch check PLN asked for ("maybe time played that track eventually
  when in a set recording to help know when overstretching") — refreshed every
  10 s by a field write on the stationary target, no re-summon. Lap reset
  belongs to the future Track </> setlist cursor; today, track load = lap 0.
- DJF overlay: "DJF percs" / "LPF 2.4kHz !!" / (blank). The cell name is gone
  entirely — "C1 C2 C3 are noise i know the button positions ahah".
- Gates: "d1 gate" / "ON" / context. Value rides row 2 everywhere.
- The zero-mark heart animation moved to row 2 with everything else.

Display byte-pinning tests still pass; the ghost mirrors the new layout.

Pre-compact ritual: 11 threads closed tonight, 8 resume points with exact
next commands. The theme of the night was identity bugs — a port's name is
not the port, a device's saved identity is not the device — written up in
log 036 and banked to memory (ardour9 generic midi, worktree roots,
34-display-targets protocol update).

The LCXL3 OLED fix as a story: three rounds tuning a keep-alive for a race that
was unwinnable by construction, and the partial symptom (buttons were always
fine) that pointed at addressing rather than timing the whole time.

PLN, three rounds in: the OLED "still shows values". Move a fader and you get
the firmware's bare 0-127; move a relative encoder and you get "0", because the
wire value of a relative encoder IS 0-ish. "No info at all." Meanwhile our own
overlay — track name, what the control does, a readout — was being re-summoned
every 0.9 s under a 1.2 s firmware timeout, field-diffed, stamped only on real
bring-ups. Three increasingly clever versions of the same losing move.

The programmer's reference says why, in the display chapter's first list:

    "• 05h (5) - 24h (36): Temporary display for Analogue controls (same as CC
       indices, 05h (5) - 0Ch (12): Faders, 0Dh (13) - 24h (36): Encoders)
     • 35h (53): Permanent/Stationary display
     • 36h (54): Overlay/Temporary display"

There are not two display targets. There are thirty-four. Every fader and every
encoder owns a display target of its own, addressed by its own DAW-mode CC
index, and THAT is the one the firmware auto-triggers when you touch the
control — not 36h, which is where we had been writing all evening. Config bit 6
is its on-switch and it defaults to on:

    "• Bit 6: Allow Launch Control XL 3 to generate temporary display
       automatically on Change (default: Set).
     • Bit 5: Allow Launch Control XL 3 to generate temporary display
       automatically on Touch (default: Set; this is the Shift + rotate)."

So a fader sweep fired target 05h thirty times a second while we re-summoned
36h once a second. Unwinnable by construction, and no amount of keep-alive
tuning was ever going to change that. It also explains the one part of the
symptom that never fit a timeout story — buttons were fine. Buttons live at
25h-34h, outside the analogue range, own no per-control target, and so were
never contested at all.

And the fix is not to win the fight. Arrangement 4 is the firmware's default:

    "4 | 2 lines: Parameter Name and Numeric Parameter Value (default) | Yes | 1 | Name"

One field, Name, and a value the firmware draws itself. The Name field was
empty because nobody had ever written it. Write it, and the display we were
trying to suppress becomes the display we wanted: it already tracks the value at
wire speed and already times its own dismissal. So the driver now labels all 32
analogue controls on their own targets at startup — "d4 # crushbus",
"d5 # octerbus", "d1 level [ard]" — and stands down from the overlay for them.

Faders and A1-A4 carry no ^NN in any .tidal, because they are Ardour-learned
levels; their label comes from the grid's role table instead, with an explicit
[ard] mark. Mid-set, "this fader is Ardour's, not Tidal's" is the most useful
sixteen characters the panel can hold. Unmapped controls say "unmapped", because
dark-means-unmapped is the surface's oldest rule and the screen must not
contradict the LED beside it.

Three controls keep our overlay: the DJF knobs. "HPF 3.4kHz !!" and the heart
frames at the zero detent are prose, and arrangement 4's value field is a
number. For exactly those three targets we clear bits 5+6 — which is the
documented, per-control way to make the firmware stand down — and take the
screen back uncontested. Restored on exit, since a next session finding three
knobs that silently refuse to show a value would be a worse bug than this one.

Along the way, three things the per-control screen made visible by being the
first thing to render our labels at full width:

- set_text filtered to `0x20 <= c <= 0x7E` and so dropped the four reassigned
  control codes its own docstring advertised. The language module's heart frames
  had been arriving as plain spaces this whole time.
- parse_context said "an inline trailing comment IS the best label" and did not
  do it: the only `--` strip was anchored at the start of the body, where a
  trailing comment never is, so the Haskell always won. C8 of piment_bresilien
  read `d8 # n "23")) --` on a line ending in PLN's own `-- Raise COMEON!`.
  The comment is split off first now and preferred.
- With no stage note, the body fallback was raw combinator soup. It now reads
  the sample name off the first quoted string and the effect off the first
  identifier — "break:18", "n 6" — which is what PLN asked the line to say
  ("sample name or effect like 'rose:4'"). Across live/: 158 syntax-noisy
  labels out of 22368 became 3.

Verification I can actually do, given a write-only display and no readback:
--show-oled dry-runs the whole label table offline, opening no port, and fails
on any name over 16 characters; the new test pins the target numbers against the
guide's table, the exact configure/set_text bytes, that a button raises instead
of writing into the void, that the hearts survive the filter, and the three
parse_context cases above. What no test can prove is a pixel. That needs eyes.

Fallbacks kept in case the name field turns out not to render: --oled-overlay
suppresses every native display and restores the uncontested-overlay behaviour
across the whole surface, and --oled-native-all hands even the DJFs to the
firmware, for the eye test that compares the two side by side.

Round 4 of the live design session, plus the nine-press census.

DJF readout speaks Hz, not percent — and the numbers come from BootTidal's own
gDJF ranges (lpf: range 180 20000 over 2v; hpf: range 20 8000 over 2(v-.5)),
so what the OLED says is what the filter DOES. The zero mark animates: heart
frames at ~3 fps while a DJF rests in the detent (charset 0x1E is a heart).
Home screen line 3 is now "118 BPM" — "36 live" was a control count nobody
asked for, and PLN rightly mocked it.

The OLED GHOST (/tmp/lcxl3-oled-ghost.txt): the protocol has no display
readback, so nothing can pull the screen — instead the driver mirrors every
frame IT sends into a box-drawing the shell can read. What the ghost cannot
show is the firmware's own native value overlay, and that is the point: when
PLN's eyes see content the ghost does not have, the discrepancy itself is the
diagnosis. (That discrepancy is live: the native overlay still outdraws our
temporary text on every control move — an Opus worker is in the programmer's
reference hunting per-control display targets, the likely correct fix.)

Keep-alive: the round-3 overlay stamped _oled_up_at on every push, so after
the firmware's 1.2 s timeout our overlay was never re-summoned — one good
overlay per touch, then raw values forever. Now the bring-up re-fires every
0.9 s of continuous activity and stamps only when actually sent.

THE EDGE-BUTTON CENSUS (PLN pressed, the log answered): Solo/Arm is ONE key
(ch1 CC65, two press cycles for his presses 1+2), Mute/Select is ONE key
(CC66), the Novation logo is alive (CC104), Track </> are CC103/102, Page
up/down CC106/107. Authored as EDGE_BUTTONS in lcxl3.py; the driver now names
them in the log instead of counting them unmapped. No functions assigned yet —
the settled direction is Track = setlist cursor, Page = OLED pages, the two
verb keys = record-arm and panic, logo in reserve.

The glitch loop cut live from the Afia ad (afia_flow.gif) is now this
track's backdrop, through the HUD's new standard: the header names the
source, scene-ingest derives the playable twin into visuals/scenes/.

PLN, 2026-08-29: "midiwatch still naively verbose [`14:0 Control change ch0,
controller 29, value 15`] improve it massively. no more console, tiny borderless
window that exits on q/exit/ctrl+c/alt+f4, that renders the stream in a nicer,
cyberpunk matrix dense cryptic purple-on-dark, style. no word like 'control
change' pure viz"

The complaint is not about verbosity, it is about REGISTER. One line per event is
the right shape for a debugger and the wrong shape for a performer: a fader sweep
emits ~400 events a second, so midimon's prose scrolls past faster than an eye
can land on it, and the one question you actually have mid-set — "which orbit did
I just touch" — is the one thing a sentence makes you decode. So this is a lens,
not a log.

The picture
-----------
Zero English words render. An event's identity is its POSITION, its type is a
GLYPH CLASS, its value is a BAR plus two hex digits, and its recency is
BRIGHTNESS. The layout is the authored surface itself — lcxl_grid's rows A..F in
PHYSICAL_ORDER down, columns 1..8 across, column N *is* orbit N — so the answer
is spatial and needs no decoding. A per-orbit charge glow behind each column says
"this one is live"; the column digit brightens with it. Buttons render as latches
(filled above half, hollow below) because rows E/F are gates, not levels — a bar
would have lied about what they do. Channel shifts the hue of the digits, not of
the cell, so the cell keeps meaning "which control" while the tint carries "from
where". Only what the grid CANNOT place — foreign CCs, notes, bend, program —
falls as rain in the right-hand gutter, which makes "that came from somewhere
else" a visible fact rather than a thing you read. A ribbon along the bottom
scrolls the raw order of arrival, brightest at the right.

Every hue stays inside the violet→magenta arc, so eight roles stay
distinguishable while the window still reads as one colour.

Choices worth keeping
---------------------
* **Mapped-but-idle must not be black.** All 48 grid cells carry a floor tint
  even when nothing has ever arrived on them. "Dark = not mapped" is the reading
  a cockpit trains you into, and a dark cell that IS mapped reads as a hardware
  fault — the same trap the LED work settled.
* **Toolkit: PySide6 (Qt6), already installed (6.11.2).** PyQt6 and pygame are
  not present; GTK4 + pycairo are, but Qt gave frameless + always-on-top hints +
  startSystemMove (the only way a Wayland client may reposition itself) without
  hand-rolling a drag.
* **Two frame rates, not a busy loop.** This machine performs live audio. ~25 fps
  while events arrive, dropping to 5 fps two seconds after the last one, where
  the only motion is a slow dim pulse. Colours are a precomputed LUT (8 families
  x 16 decay levels), paint uses the int overloads, the CRT scanline texture is
  one cached pixmap blitted once, and the ribbon is bounded to exactly what fits
  so a frame copies nothing.
* **Profiled rather than guessed.** The first version cost 30.6% of a core under
  a sustained 400 ev/s sweep. Stage-by-stage timing put the cost in the sheer
  NUMBER of drawText calls, not in pixels: gutter rain alone was 3.1 ms of an
  8.9 ms frame (a 96-drop cap with a trail glyph each = up to 192 calls). Capping
  rain at 32 heads with a trail only on the brightest, batching the ribbon into
  same-colour RUNS, and 33→40 ms took the frame to 5.5 ms and the sweep to 17.7%.
  Idle is 1.4%. The ribbon batches only hex glyphs, because those are guaranteed
  to come from the monospaced face at exactly one advance — a class glyph (◆ ≈ ≡)
  may be served by a fallback face and would drift the ribbon off its grid.

Port choice: delegated, not re-derived
--------------------------------------
`midimon.resolve_port()` owns "which port", and midiviz delegates to it. Two
things about it are load-bearing and were nearly re-derived wrong here: the
preference order is authored, and it matches the whole `aseqdump -l` ROW rather
than the CLIENT column — python-rtmidi registers the lcxl3 driver's client as
'RtMidiOut Client' and puts 'ParVagues LCXL3' on the PORT. A client-name match
(which is what surface.resolve_port does, correctly, for its own purpose) falls
straight through to the raw hardware: the monitor would work and show the wrong
stream. Confirmed live on this rig, which has both up — the driver is 133:0 under
'RtMidiOut Client'. The local fallback copy exists only for trees whose midimon
predates the helper, and a test asserts it cannot drift from the original.

Launcher
--------
The `midimon` KEY is kept, so the Bridge hub's and the tray's existing button open
the new thing with no change on either face; midimon.py is untouched and remains
the terminal fallback. `terminal: True` is dropped — midiviz draws its own
window, and wrapping a GUI in konsole would have parked an empty black terminal
behind it for the length of the set. That also re-enables the already-running
guard, so the button is now idempotent instead of spawning a window per click.

Verified
--------
* `ast.parse` clean; full bridge suite 90 passed (was 78 + 12 new).
* `midiviz.py --selftest`: 3 s of synthetic events — every one of the 48 authored
  grid cells, four channels, un-gridded CCs, notes, bend, program, aftertouch,
  sysex — pushed through the REAL parse_line + enrich + ingest + paint path, 140
  paints, 68 grabs, 139 distinct sampled colours. It grabs the widget each tick,
  so the drawing code is exercised for real and offscreen, not merely constructed.
* Exit paths run, not assumed: SIGINT and SIGTERM each exit 0 from a live process
  (q/Esc/close share that path).
* Plumbing, not just pure functions: a real Reader subscribed to the resolved
  driver port with no error, and a second one pinned to Midi Through received 8
  genuine events played in with aplaymidi — aseqdump → parse_line → enrich →
  drain, end to end against real ALSA.
* Rendered and looked at, at 420x260 and at 2x, before and after the
  optimizations: identical output, which is the point of the run-length batching.

Found on the way: data-less realtime messages (Start/Stop/Continue/Clock) print
with no data column, and midimon's row regex requires one, so they never parse —
midimon's console silently omits transport too, and midiviz has four glyphs that
cannot light up. Left in midimon (one parser per concept) and pinned by a test
that says what to delete when it is fixed.

PLN's report: "no impact of lcxl in ardour... why would i need to remap midi
controls there across lcxl gens?" He is right: he never needs to remap. The
session file has the learned bindings (v2 CC 77-84 + 13-16, channel 1) and the
lcxl3-driver emits exactly that. The path was broken in TWO places, both by
name-vs-identity rot:

1. midi-autoconnect resolved its source by NAME and connected "name:0" — but
   aconnect resolves CLIENT names only, and the driver's virtual port carries
   its name on the PORT line (client = python-rtmidi's 'RtMidiOut Client').
   The connect failed into 2>/dev/null for exactly the source the candidate
   list most prefers, so Midi Through carried NOTHING in DAW mode. Now the
   resolver returns a numeric client:port address (awk over aconnect -i,
   matching client AND port lines). Fourth name-identity bug of the day.

2. Ardour's Generic-MIDI input connection was saved by device identity, and
   that identity was "ALSA;;C922 Pro Stream Webcam" — the webcam had taken
   over the slot the surface once owned. The purest stale-binding specimen the
   rig has produced. tidal-ardour-autoroute now asserts
   Midi-Bridge Midi Through -> ardour:MIDI Control In on its 2 s cadence,
   no-op until Ardour registers the port, permanent once it does.

Midi Through stays the rendezvous ON PURPOSE: v2 raw or v3-translated, both
feed it, which is what keeps the classic LCXL plug-and-play (the BC
constraint). Ardour 9.7 note for the archives: the Control Surfaces page is
now a vendor tree built from the .map files' manufacturer field — the old
"Generic MIDI" lives under vendor "Any" (GenericMIDI.map, manufacturer="Any"),
NOT under "Other", and Novation's "Launch Control XL (generic)" entry is the
factory map that would OVERRIDE the learned bindings — do not enable it.

surface that breathes at the track's tempo

The design session with PLN, hands on the device, four AskUserQuestion answers
and three live iterations. Everything here is v3-only BY CONSTRUCTION: the
corpus, BootTidal, SC and Ardour still speak v2 absolutes, so the classic LCXL
(PLN's fallback, and his friend's surface) keeps working with zero changes —
"we need to be BC always" is the standing constraint.

THE LANGUAGE (lcxl3_language.py, new — parallel to lcxl-leds.py, replacing
nothing):
- rings: hue = ROLE (per-orbit family anchors, warm rhythm bloc / purple bass /
  cool melodics), lightness = VALUE. This is the exact trade v2 could not make
  with three LED hues — the settled 2026-07-29 language spent all hue on value
  because role had nowhere else to live. RGB dissolves the trade.
- dark = unmapped survives unchanged: it outranks everything on both surfaces.
- DJF row C, PLN's spec after the first blue<->green attempt proved "too
  subtle": blue = lows kept, DEEP GREEN BREATHING SLOWLY = the zero mark
  (there is no pot ridge on an endless encoder — the 0 must be VISIBLE),
  then green -> yellow -> red as the HPF cut grows. Near-silence extremes
  breathe to the BEAT — sine, not blink ("a bit aggressive atm"), rate from
  the track's setcps (118 BPM for rose_rouge). Wall-clock phase: it breathes
  AT tempo without claiming to know Tidal's cycle position — true phase sync
  is a feed from SC, later, not a silent assumption now.

DRIVER-OWNED TRUTH (three kinds, one principle):
- encoder VALUES: rows B/C relative, offset-64 decode — MEASURED off PLN's
  slow clicks arriving as 63/65/66; the first decoder assumed two's complement
  and read +1 as -63, direction inverted, every click a full-range jump. Row A
  stays absolute deliberately: A1-A4 are Ardour-learned levels, and integrating
  them from a blind seed would yank a live fader toward silence.
- row-E LATCHES: the latch never lived in Tidal (midiOn/midiOff read the last
  value) — it lived in the v2 hardware's toggle buttons. v3 DAW buttons are
  momentary, so the driver flips state on press, swallows the release, and the
  LED paints driver state — which IS what Tidal hears. Row F stays momentary:
  gestures are held, and the panic chord needs four simultaneous 127s.
- PAINT as a binding: the device repaints its own defaults on events we cannot
  see, so the driver re-asserts the full board every 2 s — same doctrine as
  every aconnect link on this rig. Faders are OUT of the paint path: they have
  no LEDs, and painting them was a no-op lie this commit stops telling.

OLED:
- touched-control context in CORPUS terms, line 2 parsed from the .tidal:
  "# crushbus", "mask <f f f t>", and — best of all — PLN's own inline stage
  notes: ^35 shows "HANDS IN THE AIR", ^59 "Le Delay rose!!!", ^36 "Savoy 8/8
  Break". His words, on his hardware, at the moment his finger lands.
- anti-blink: fields are diffed and the configure/bring-up pair fires only when
  the overlay has likely expired — re-summoning a live overlay every event was
  the blink PLN saw.
- gates read ON/off, DJFs read "LPF 43% / BYPASS / HPF 61% !!".

Validated on the live rig across three rounds of PLN's eyes and hands:
translation + paint + OLED coexist in one process; 27 live cells / 13 dark on
rose_rouge; 18/18 controls context-labelled; latch verified against E1.

Three gaps PLN hit launching the rig on 2026-08-29, reported as "had to launch
ardour myself / had to open midi watch myself / once opened had to wire it to
midi through myself". All three were real, and one of them nearly got "fixed"
the wrong way.

GAP 1 — the button looked dead for over a minute. _run() ran gig-up --converge
to completion (~100 s on a cold boot while SuperDirt warms 51 banks, up to the
300 s timeout) and only THEN launched the apps. So RIG UP showed a spinner and
no window, PLN concluded it had failed, and launched Ardour by hand.

My first attempt was to launch the apps first. That was wrong, and PLN caught
it: "superdirt froze before loading midi when in my launcher, when ardour was
midi connected, had to untick ardour midi, then launch". Ardour holding the
surface makes sclang hang inside MIDIClient.init / MIDIIn.connectAll — the same
rawmidi contention that stops `amidi` writing LEDs while SC is up. The original
ordering was not an accident, it was load-bearing, and reordering it would have
traded a cosmetic complaint for a reliable boot freeze. Reverted.

The correct shape is a SPLIT, not a reorder:

    PRE_APPS  = ["pulsar"]              touch no MIDI -> open immediately
    POST_APPS = ["ardour", "midimon"]   contend for the surface -> wait

Pulsar's GHCi reaches Tidal over TCP 6010 and never touches ALSA, so it can
open at once and give the button a visible effect within a second, while its own
multi-second startup overlaps converge instead of queuing behind it. Ardour
still waits for SuperDirt to own MIDI first. Converge output now appends to the
launch lines rather than overwriting them, so the log shows both halves.

GAP 2 — midimon was in NEITHER list. RIG UP never had it to open, so "had to
open midi watch myself" was exactly correct. Added to POST_APPS.

GAP 3 — midimon opened blind. `aseqdump` with no -p subscribes to nothing and
prints "Waiting for data at port", so every launch needed hand-wiring before it
could be used. Added resolve_port(), which picks the most interesting source
present, in a deliberate order: the lcxl3-driver's TRANSLATED stream first
(the numbers the corpus speaks — what you want when a knob does the wrong
thing), then the raw v3 DAW port (the numbers the hardware speaks — for "is it
even sending"), then the custom-mode port, then Midi Through as a catch-all.

It matches CLIENT and PORT names both, because python-rtmidi registers the
driver's client as 'RtMidiOut Client' and puts 'ParVagues LCXL3' on the port —
a client-only match misses precisely the stream most worth watching. That is
the third bug today caused by treating a MIDI endpoint's name as its identity.

Verified with the driver running: resolve_port() -> ('133:0', 'ParVagues LCXL3'),
i.e. it selects the translated stream over the two raw ports and Midi Through.

Follow-up to fa22bb85, which fixed the direction trap but still could not run.
Two more defects, then the first verified end-to-end translation.

DEFECT 3 — the virtual port could never be found. _clients() returned
(port_id, CLIENT_name) and every lookup matched the client name. python-rtmidi
registers the client as 'RtMidiOut Client' and puts OUR chosen name on the
PORT:

    client 133: 'RtMidiOut Client' [type=user,pid=...]
        0 'ParVagues LCXL3 '

So `VIRTUAL_PORT_NAME in client_name` was false forever. The driver printed
"reconcile: src=None dst=130:0 — nothing to do yet" on every cycle while
`aconnect -i` listed the port plainly two lines below. _clients() now returns
(port_id, client_name, port_name) and _find_port() matches either — both names
are real and each is load-bearing somewhere.

DEFECT 4 — prune() would have cut the driver's own link. It skipped "our" port
by testing VIRTUAL_PORT_NAME against the name from `aconnect -l`, which is the
CLIENT name — 'RtMidiOut Client'. That never matches, so the very first prune
after a successful connect would have severed the connection it had just made,
every cycle, forever. prune() now takes an explicit set of protected PORT IDS.
Identity here is the ALSA port id; the names are decoration. Any place that
matches a MIDI endpoint by name on this rig is a latent version of this bug.

Also: reconcile() prunes only AFTER a confirmed connect. Cutting the raw
surface while the replacement stream is not actually delivering would leave a
dead surface, which is worse than a wrong one.

VERIFIED END TO END on the live rig, PLN's hands on the hardware:

    fader 1      v3 #5   -> v2 #77   (38 events, full sweep 37..0)
    button E1    v3 #37  -> v2 #41   (127 then 0)

^77 is lcxl_grid's row D cell 1 and ^41 is the kick gate — the exact control
the #94 migration aligned all 169 tracks onto, and the one v3 renumbering would
have moved to button E5. 0 unmapped, 0 dropped. The graph after prune:

    133:0  RtMidiOut Client  -> 130:0    (ours, the only surface path)
    20:0 / 20:1 LCXL3 1                  GONE from SuperCollider
    14:0 Midi Through -> 130:2           re-cut every cycle

Open, and deliberately not guessed at: something re-adds Midi Through -> SC
within 5 s. midi-autoconnect only ever creates the OTHER direction, so the
re-adder is unidentified. prune contains it each cycle; the window is real but
small, and naming a culprit without evidence is how the last three "rig is
broken" findings turned out to be the measuring tool.

Resume point 1 is closed: the driver has met a live SuperCollider, and it took
four defects to get one fader through. Every one of them was invisible to
reading — three reported success while doing nothing.

Resume point 1 was "run lcxl3-driver against a live SuperCollider, because it
never has been". It has now, and the run found two defects that no amount of
reading could have found — both invisible precisely because the code reported
success.

DEFECT 1 — the aconnect direction trap. reconcile() resolved its destination
with `_clients("-i")`:

    dst = next((p for p, n in _clients("-i") if "SuperCollider" in n), None)

`aconnect -i` lists ports you can read FROM. SuperCollider appears in both
directions: in0..in4 are destinations, out0..out6 are sources. So `-i` returned
SC's *output* port — 130:5 on this rig — and the driver ran

    aconnect ParVagues LCXL3:0  130:5

which writes into an output-only port and fails. The CompletedProcess was
discarded, so the failure had no way to be seen, and the next line printed
"reconcile: src -> dst" as though the link existed. Every previous reasoning
step about this driver rested on a connection that was never made.

Fixed by resolving destinations from `-o` via a new _sc_input_ports(), and by
checking the return code and PRINTING the failure. A reconciler that cannot say
"I failed" is decoration — the rig has been bitten by this shape before
(feedback_verify_the_plumbing, reference_check_the_instrument_first).

DEFECT 2 — reconcile only ever ADDED links, so it could not be correct here.
`MIDIIn.connectAll` subscribes SC to every source present at boot. Measured on
the live rig:

    14:0  Midi Through  -> 130:2
    20:0  LCXL3 1 MIDI  -> 130:3
    20:1  LCXL3 1 DAW   -> 130:4

So the moment the driver published a correct, translated stream, SC was hearing
it ALONGSIDE two raw ones. This is worse than duplication: v3's DAW map
collides with the corpus's v2 numbers on 16 indices with different meanings, so
row C knob 4 would drive ^52 (right) and ^32 (row B's cell) at once — two
orbits moving when one knob turns. And a doubled CC is fatal on a latch: the
toggle fires twice and cancels, which reads from the stage as "the button does
nothing".

Added prune(), which cuts every path into SC that is not our virtual port,
re-asserted on the same timer as the connect (the binding must be re-asserted,
never assumed — feedback_stale_binding_pattern). Midi Through is cut by default
because midi-autoconnect's rule 1 pushes the surface into it, i.e. it is a
second copy of the same stream; --keep-thru opts out.

Added `--graph`, which prints what actually feeds SC and what prune would do.
That is the diagnostic whose absence let defect 1 hide: the driver's own view
of the graph was never printable, so it could never be checked against reality.

Verified on the live rig (sclang 845344 / scsynth 845718, LCXL3 on client 20):
--graph now resolves 130:0-130:4 and correctly classifies 3 WOULD CUT paths and
PipeWire-RT-Event's monitor bridge as left alone. Hardware also confirms the
translation table's row D: PLN reports fader 1 = CC5, which is V3_ROWS["D"][0].

Eleven threads closed, six resume points with exact commands. The first one is
load-bearing and gets said plainly: tools/lcxl3-driver.py has never run against a
live SuperCollider, because sclang, scsynth and Ardour were all at zero when it
was written. Every claim about PLN playing his corpus on the new surface rests on
that one untested step, so it is resume point 1 rather than a footnote.

Also records what is deliberately left running (the audition server, plus the
firewall holes its LAN access needs and the ?set= key that cost PLN a listening
session), and what is parked because it is not mine to commit — four uncommitted
www files from a prior session's CosmicFest page work.

Three threads worth their own entries in the documentary trail.

032 — the LCXL3. Closes the board's twelve-day-old OLED question (arbitrary
128x64 bitmaps, ACKed per frame for animation), records the keystone result that
paint is DAW-mode-only, and the sixteen-index CC collision whose decisive case is
v3 #41 = button E5 against v2 #41 = the kick gate log 031 had just aligned 169
files onto. Plus two instruments that lied: aseqsend -s takes a FILENAME and exits
0 on 32 silent no-ops, and pgrep -c -f matched its own command line.

033 — fourteen tracks from one microphone. 12 of 14 named correctly off a
handheld stage mic with no stems and no log. Includes the three lenses, the three
failed tempo estimators, the same reference-size bias appearing in three separate
costumes, and PLN's ears beating my reporting twice because I printed 4 of 86
detections.

034 — the recorder nobody enumerated. Why CosmicFest has no session log: the unit
was installed 2026-07-29, never enabled, and absent from the authored inventory,
so nothing could assert it. Paid in three places, with a gate proved capable of
failing.

sample_tfidf.json re-run over the corpus; set_finder_locate.json is the 35-bank
pass (was 19) after MAX_DF rose from 6 to 40 on the strength of 1/df weighting.

The npz hash DB (2.3 MB, rebuilds in 39 s) and the per-recording query profile
are ignored: they are caches keyed on inputs, not sources. Noting the tension
deliberately — 'generated + gitignored + never compared' is exactly what made
preload staleness debut at a venue — so both are produced by an explicit
subcommand and their inputs are versioned.

fix(rig): the other two thirds of the gig-log fix, which 30fceb43's message claimed but did not contain

30fceb43 said the debt was "paid in three places" and shipped one file, the unit
itself. The inventory entry, the regenerated target and the hard gate stayed in
the working tree — so the commit that explains the fix and the commit that
performs it were different commits, and only one of them existed.

What is here:

  rig_units.py    gig-log joins SERVICES, so --ensure enables it and --status
                  reports it. 7 units, 0 problems. It was absent until now, and
                  that absence is the entire reason CosmicFest has no log: the
                  unit was installed 2026-07-29, never enabled, and nothing in
                  the authored list knew it existed.

  parvagues-rig.target  regenerated, now Wants 8 units.

  gig-up.sh       a HARD gate, deliberately not "is the unit active". A green
                  unit is not a recording — the process can be up while the
                  writer is wedged. It asserts a session file's mtime is within
                  20 s, i.e. it is writing NOW. Proved it can fail rather than
                  assuming: stopped gig-log, waited 25 s, gate failed at age
                  25s; restarted, age 1 s, passed.

Same class of error as the amend on c628415e earlier this session, where a message
described a midi-autoconnect fix the commit did not carry. Both times the message
was written from intent rather than from `git show --stat`.

PLN, auditioning CosmicFest: "at 22:42 its end of reose_rouge, theres a loud blip
noise, at 22:44.9 its the start of rose rouge, could we cut noise and blend
better?"

The lab could only ever answer one question — where does the next track start —
so garbage living in the 2.9 s BETWEEN two tracks had nowhere to go. It survived
as prose in a comment box, which no downstream tool reads.

`n` marks the playhead as noise and deliberately leaves the cut call untouched: a
blip between two tracks is not an opinion about where either begins, and forcing
it through the cut field would corrupt the one number the mastering chain trusts.
`N` clears them, because a mis-tapped defect marker you cannot remove is worse
than no marker at all.

They render in warm orange, distinct from every existing mark colour: those are
all CANDIDATES for a cut, and this one is the opposite — a place to avoid.

Exported from both the decided and skipped blocks, so a seam PLN rejects can still
carry "and there is garbage at 22:42". That combination is exactly what happened
here and exactly what the old export could not represent.

PLN: "wait you dont get the notes when i skip? DANG they have lots of info."

The exporter emitted skipped boundaries as bare integers:

    skipped: Object.entries(calls).filter(([, c]) => c.t === null).map(([k]) => Number(k))

so eight CosmicFest seams exported as `[2,4,9,10,15,16,17,18]` while the notes he
had typed into every one of them vanished. And a skip is not an absence of
judgement — it is usually a judgement that the SEAM is wrong, which is more
informative than confirming a cut time. What was lost included "theres no
blue_gold in this set, we're hearing do_it_right throughout", "there was no
gimme_acid in this performance", "theres no funk->piment transition! in this set
i playd piment once, then funk", and "it could be called Outro Dub Siren".

The notes were never actually gone: the textarea writes `{t: t ?? null, comment}`,
so a skipped call keeps its comment in state and in localStorage. Emitting
`skipped` as {id: {source, note}} therefore recovers notes ALREADY STORED, not
only future ones — PLN re-exports and gets them back verbatim. Verified the built
bundle carries it, after first mis-verifying: `grep -c` counts LINES and a
minified bundle is one line, so the honest count is 2 occurrences, not 1.

With his corrections the true set is 14 tracks, written to
judge_specs/cosmicfest-2026_setlist_ear.json as ground truth.

Scored against it, the three-lens pipeline named 12 of 14 tracks correctly and
labelled 81% of the 63 minutes, 85% of the labelled overlap correct. bombe_dj,
rose_rouge, ouais_je_funk, punkachien and livecode_parade landed at 100%.

The two failures are the same failure. `perfect` was called gimme_acid and the
improvised outro was called REVOLUTION, and both are reference-bound: crossmatch
can only choose among tracks it holds a prior render of, so audio from a track it
has never heard gets assigned to the nearest thing it has. All five "ghosts" —
blue_gold, desire, gimme_acid, quand_on_decolle, REVOLUTION — are that same
mechanism. It is a structural limit, and the fix is one render per track, not a
better threshold.

Also banks his ear-feedback in performance_notes.md, including two things no
analysis could have produced: a loud blip in the 2.9 s between two tracks (a
defect belonging to NEITHER, which the boundary tool currently has no way to
express), and why desire was dropped — "Clearly didnt play desire i was not found
of that closing at opal".

PLN, on hearing a rose_rouge sample inside a seam I had labelled quand_on_decolle:
"where is our samples mathcing? gosh, i should not do so excruciating details
myself. you have all the data bro." He was right. I had 86 offset-consistent
detections and printed 4, because `locate` reported each bank's single BEST window
and threw away temporal extent — which is the informative part.

What was hiding in data I already had:
  rose        -> rose_rouge            22:35-24:00 (max cons 0.81), and on to 31:30
  movie_paris -> something_about_drums   6:15 (0.62), 10:30 (0.49)
  take5       -> take_5_drops           32:10-35:30
  love_parade -> livecode_parade        55:20-56:10

So rose_rouge is continuously present 22:35-31:45 — a stretch I had split into
quand_on_decolle, blue_gold and UNRESOLVED. And something_about_drums sits in the
5:04-11:33 hole I reported as unclaimed, exactly where PLN said he played it
("im sure i played something about drums between bombe and do it right").

Then his second point, which is the principled fix: "its almost tfidf we should do
here. when we know rose sample is around a time slot, its a tell. when we see e.g.
_jungle_BreakS_, it's way less idf relevant."

Implemented as `fuse`: evidence for track T at time t is the sum, over detected
banks that T uses, of offset-consistency divided by that bank's df. A bank in one
track hands over all its evidence; a bank in eighty splits it eighty ways.

One refinement, from measuring rather than assuming: plain log-IDF is too flat for
this. jungle_breaks (df=80) carries 0.50x the weight of rose (df=2) — a 2x penalty
for being 40x more common, which would still let it dominate since it fires
constantly. 1/df gives 0.0125 vs 0.50.

Two normalisations that are not decoration. Per track, divide by the total 1/df its
banks could contribute, or a track referencing many rare banks beats a track with
one perfect tell — the reference-size bias in a third costume. And close gaps
before deciding: a rare sample fires intermittently INSIDE the track that owns it,
so `rose` at 22:35, 25:15, 28:15, 30:00, 31:10 is one track, not five appearances.

A NEGATIVE result worth recording. Weighting let MAX_DF rise from 6 to 40, taking
fingerprint coverage from 15/23 to 23/23 candidate tracks — and it added no
evidence at all: every new bank scored consistency 0.02-0.21 against a 0.30
threshold. I guessed reference duration was the binding constraint and that was
WRONG: correlation with best consistency is -0.144, and the three longest
references are among the worst detectors. Then the confound surfaced — suns_keys
belongs to blue_gold, which PLN did not play, so its low score is a TRUE NEGATIVE.
Failures and true negatives are indistinguishable without the setlist, so the
reason remains unestablished rather than explained away.

Also fixes two things that wasted PLN's time. The Boundary Lab query key is `set`,
not `gig` — bounds.tsx does get('set') ?? 'opal-festival-2026', so a wrong key
silently loads the DEFAULT document, and he auditioned OPAL's Sunset Forest seams
believing they were CosmicFest. The variable there is named `gig`, which is exactly
how I made the mistake: grepping found the word, not the key. And the generator
offered "bombe_dj -> bombe_dj" as cut #1, a seam between a track and itself,
because it read the un-merged segment file.

PLN: "dotn we have a webapp for listening to seams in a set? you could use it for
me to confirm your labels. reusable tooling pattern."

It does — armada/ui/bounds.html, the Boundary Lab. So this builds no second page.
make_bounds.py generates the document that page already reads, which means the
confirmation loop is the one that already stores calls per gig in localStorage and
already exports boundaries-<gig>.json.

That direction is the point. The three-lens fusion is a machine opinion: 11 of 18
segments have two lenses behind them, 4 are honestly unresolved, and the two rows
that were WRONG were caught by PLN's memory rather than by any score. An analysis
pipeline whose output lands in a report has nowhere to be corrected.

The contract was read from BoundaryLab.tsx, not assumed, and two details would
have been wrong if guessed: marks[].t is in MASTER time (the page subtracts
clipStart itself), and `url` is handed to WaveformPlayer with dur = clipEnd -
clipStart, so it must point at a CLIP of that length rather than at the whole
recording. Mark keys are colour-coded by the page, so the segments where a lens
OVERRODE the embedding get `takeover` — brand magenta, which its own comment calls
"the one to try first" — because that is exactly where an ear call is worth most.

Clips plus a mount rather than the whole file, following audio-mounts.json's own
reasoning: it maps /audio/<prefix>/ for BOTH vite dev and armada/serve.py
deliberately, since "a UI that only works under npm run dev is a demo, not a
tool". A 40s clip also loads instantly on a phone over LAN, which is where this
gets used. Peaks are normalised per clip because these are 40s windows of a room
mic whose level wanders, and a waveform you cannot see is not a waveform.

Verified rather than asserted: /bounds.html 200, the document 200 at 190 KB, a
clip 200 at 641 KB, and a Range request returns 206 with exactly 1024 bytes — so
seeking works, which is the whole point of auditioning on a phone.

PLN corrected two rows: he played rose_rouge and livecode_parade, not blue_gold.
The fusion now reaches both WITHOUT being told, which is the whole point.

29:57 crossmatch said blue_gold at a weak 0.44 margin; tempo measured 118.1
against blue_gold's declared 124 — a clash — and rose_rouge is declared 118,
with locate holding `rose` at 0.602 offset consistency. Two lenses override one.
54:59 the same shape: measured 130.0, gimme_acid declares 80, livecode_parade
declares 130, locate had `love_parade` at 0.399.

Both were only reachable because crossmatch STRUCTURALLY cannot name them.
rose_rouge played neither reference gig, and livecode_parade's .tidal was created
in the CosmicFest prep commit itself, so no prior render of it can exist anywhere.
A blind spot, not a tuning failure — and the fix is one render per new track.

The tempo lens took three attempts, and the first two measured nothing.
librosa.feature.tempo returned 107-130 for every segment of an 80-170 BPM set:
that is its log-normal prior centred on 120, not the music. Mode of inter-onset
intervals on the full mix returned 233-648 BPM, locking onto the hats rather than
the beat — and its apparent matches were hollow, because five octave multiples at
5% tolerance passes roughly a quarter of random values. Autocorrelation of the
40-120 Hz kick band works: bombe 123.9/124, punkachien 170.1/170, vague_de_crime
120.1/120, do_it_right 178.3/2 = 89.15/89. Four exact to 0.1%.

That validation is what licenses the overrides. An instrument which agrees where
it should is one whose disagreements carry information; without those four hits I
would be overriding a strong embedding on the word of an estimator I had not
checked (feedback_check_the_instrument_first).

I also had to fix my own fusion: counting each top-3 tempo candidate as a vote let
cafe_bouillant beat ouais_je_funk, which measured 120.1 against a declared 120 —
a perfect match demoted by an alphabetical tie. Tempo compatibility CONFIRMS the
embedding's proposal; it only overrides when it clashes AND a second lens agrees
on a specific alternative.

Four rows are now marked unresolved rather than confidently labelled. That is a
real answer: a confident wrong row costs more than a blank one.