Captured at task close, not reconstructed. The learning worth keeping is
that a green light is a claim about liveness and liveness was never the
question — and that a test in this repo had pinned the MIDI re-resolve
design so firmly that 'cheap by construction: an idle surface costs
nothing at all' went un-re-examined until an idle surface cost a gig.

PLN, 2026-09-25: "a better 'tableau de bord' to confirm all is armed".

The Bridge answered liveness: units active, processes alive, surface
connected. On 2026-09-24 all of that was green while Tidal 08 was
unarmed, gig-log's MIDI lens held a dead subscription and the black box
had never run. None of those are liveness questions, so no number of
green process dots could have shown them.

The panel renders tools/check-gig.py --json and decides nothing itself.
Severity, wording and — the part that matters on a screen — the FIX all
come from the probe that owns the question, so a probe added to check-gig
appears here for free. A bespoke "armed" tile would have been a third
place the truth lives, which is the failure this rig keeps paying for.

Read-only by construction: check-gig is fenced by gig_gate.mutations()
and tested for it, so unlike RIG UP this button changes nothing and makes
no sound. It runs off the request thread like _Converge, because the repo
layer takes ~40s and holding a poll open reads as a hung dashboard.

Also: two failing rows said nothing useful. gig_gate._detail() shows a
probe's LAST line, and check-mix ended on a paragraph — so the dashboard
read "is tools/gig_record.sh." and "which looks exactly like Tidal
emitting nothing. It isn't." Both now end on the fact: "1 orbit(s) NOT
ARMED — Tidal 08" and "9 route(s) cannot be heard — Tidal 02, ...". A
verdict is read standing up, in a field.

Verified against a throwaway instance on a spare port: 43 checks, NO-GO,
ardour armed at the top naming Tidal 08.

tools/gig_record.sh has existed since OPAL, is item 9 of RUNBOOK.md's
checklist, and had never run once on this machine — no unit, no row in
rig_units.py, so nothing in the authored inventory knew it existed and no
converge asserted it. Precisely gig-log's own story, which is why
CosmicFest has no session log.

The cost this time: 2026-09-24 lost 17m44s off the head of a 94-minute
set (REC at 18:27:41, set from 18:09:57), so salut_nu and love_first
exist in no recording at all. Orbit 08 went with them for every track,
and Ardour cannot help — Master is a BUS, no playlist, no rec-enable, so
the DAW cannot record the mix even in principle. One stereo opus of the
master bus makes both losses survivable.

It no longer records the default sink. That sink was the laptop card on
the 24th while Ardour's Master had been hand-linked to the UMC, so the
net would only have caught the show because TODO_GIG step 4 was never
done — do that step and the black box records silence, which is the worst
failure a black box has, because it looks like it is working. It now
follows whatever sink ardour:Master/audio_out 1 is linked to, falls back
to the default when Ardour is closed, pins to GIG_RECORD_TARGET when told,
and says out loud which road it took.

on-demand, not login: ~72 MB/hour, so gig-up starts it and idle hours are
not recorded. PROOF stays None because 'pgrep -x ffmpeg' would be
satisfied by any stranger's transcode; its liveness is a recent segment
mtime, the same assertion the gig-log probe makes.

The probe ADVISES rather than blocks — a missing net does not stop a set.

Also: nothing checked that rig_units.SERVICES and rig-install.sh's
UNIT_SRC name the same units, which is the 'list lived in three places'
failure this module was written to end. Three tests now do, shrink-only
on perf-tray's $HOME-only unit. Verified they fail when the new row is
removed.

Zero control moves were logged for the whole 2026-09-24 set, and every
cheap check said fine. Two independent faults, both found by looking:

THE CHECK RAN ON TRAFFIC, NOT ON A CLOCK. The re-resolve lived inside
'for line in self._proc.stdout', so it only ran after a line ARRIVED. A
bound port that goes quiet blocks that iterator forever, and aseqdump does
not exit — so the loop parked on a blocking read from 01:01 through a
94-minute set. Now a timed select: the liveness question is asked every
UPGRADE_S whether or not the board said anything. The old test asserted
this the other way round, on the reasoning that running in the read loop
was 'cheap by construction: an idle surface costs nothing at all'. An idle
surface cost the gig. 'Costs nothing when idle' and 'notices when idle'
are the same code path and only one can be true.

A NAME AND AN ADDRESS ARE BOTH USELESS HERE. 38 hours after the set, 133:0
'ParVagues LCXL3' still resolved to that exact address under that exact
name — so neither 'is it gone' nor 'did it move' could see anything. What
happened is the third thing: lcxl3-driver restarted repeatedly between
00:34 and 10:27, and the kernel handed each new sequencer client the same
number. Our subscription died with the old one. Verified live: client 133
was 'Connecting To: 129:0, 14:0' and gig-log's aseqdump, client 135, was
not in the list.

So subscription_alive() asks the kernel's own wiring table, matching the
CHILD's pid — the same discrimination lcxl3-driver's board_link_alive
makes, for the same reason. It reads False on the real dead link and True
on SuperCollider, which is wired to the same port; 'cannot tell' is None,
never False, so a box where aconnect differs does not thrash.

gig-log status now names the binding, its subscription state and the
session's control-event count. It used to answer 'is it writing', which
was true and useless on the night the file grew at 1 Hz with nothing in
it. A dashboard that shows LIVE while a whole lens is dead is the green
check this rig has learned not to trust.

Note: tools/tests/test_one_tidal_parser.py fails at HEAD too, on
fold-orbits.py. Untouched here.

Twelve tools audit this rig's faders, mutes, routing, ghosts, preload,
samples and thermals. None audited arm state, and on 2026-09-24 Tidal 08
sat at rec-enable=0 for the whole set — alone among the twelve — so Ardour
never created the file. Eleven stems, and that orbit was in all fifteen
tracks' control maps.

Arm lives in the same mixer, in the same XML, under the same verb, so it
goes in check-mix rather than a new screw. Only the Tidal NN routes block:
Master has no rec-enable at all, which is how Ardour says 'bus' — reported
as n/a, because sending PLN hunting a button that does not exist is worse
than saying nothing. Mic and Keys are reported, never gated.

A new 'ardour armed' probe carries its own fix (click record + Ctrl+S, not
raise + Ctrl+S), and 'ardour faders' now passes --no-arm so neither probe
reports the other's failure. Run against the session as it stands, the gate
says NO-GO and names Tidal 08.

The disk caveat cuts both ways and the docstring says which: this proves
the session BOOTS armed. It is exactly right for the Tidal 08 case, where
saved and live agreed all night. Nothing here reads Ardour's OSC surface —
that surface reported arm:false for all 76 minutes it was recording.

PLN, from the stage: "moving from track X to Y, i had to press states like
^42 twice to 'apply their state'? was weird". ^42 is row E, column 2 — a
driver-owned latch.

carry_values deliberately emits no CC for buttons, because a 0 into a midiOn
gate is someCyclesBy 0 and the stream stops playing. It also cleared the
driver's latch, on the reasoning that LEDs should stop lying across a change.
Those two halves contradict: nothing is sent, so Tidal's bus still holds 127,
while the driver now believes 0. The next press computes 'not False' = ON and
re-sends 127 into a bus already at 127 — inaudible — and the press after it
closes the gate he was trying to open.

Not a hypothesis. The lcxl3-driver journal logged 37 of these across 14 of
the 2026-09-24 set's 15 track changes, and the service runs without
--no-latch, with Midi Through cut, so the doubled-CC path is not involved.

The fix is a deletion: the latch IS what Tidal sees, so it survives exactly
as the CC value does. Row F stays momentary — its release travels the generic
path and really does send 0. A carried latch now paints lit under the new
track's label, which is true, and doubles as the ghost-gate indicator this
surface never had.

The test's own assertions are checked against the pre-fix code: both fail
there.

Corrections and additions to the Thu-24 reconstruction, all from sources
that should have been read first.

The fader claim was wrong on cause: I blamed the LCXL lap reset, but every
one of those journal lines says 'effect knobs -> 0' and '(no CC sent)' —
Tidal params, not Ardour gain. The 2026-08-14 forensics had already settled
it as a faithful save of faders in motion. Same verdict now reached from
the audio side, which is the new part.

Verified rather than assumed: dN == Ardour 'Tidal NN', from BootTidal.hs,
fold-orbits.py and check-mix.py independently. That is what makes the
missing stem d8.

New: all nine off-map orbits were declared by the immediately preceding
track, so #68's ghost mechanism is now measured in audio, with levels —
take_5_drops ran its whole 8m43s under piment_bresilien's orbit 04 at 99%
active. And the answer to 'why no Master to recover from': Master is a bus
Ardour cannot arm, while the out-of-Ardour net gig_record.sh has no unit
and no inventory entry, so nothing ever asserts it.

Dropped: a killed-recorder verdict that was an artifact of reporting on a
sliced log, a laptop-speaker inference the data does not support, and a
13-of-15 peak count that should have been 12 of the 13 captured.

Reconstruct 2026-09-24 from four independent lenses: gig-log eval, the
lcxl3-driver journal, gig-log focus, and full-resolution per-second levels
off the eleven Ardour stems. Eval and the surface journal agree to the
second on all fifteen boundaries, so nothing here is a statistical guess
the way CosmicFest's recovery had to be.

What the numbers say: 94 minutes, all fourteen planned tracks in order plus
sunny_side_up sixth, five xruns, zero throttle events. REC landed 17m44s
into the set, so salut_nu and love_first have no audio at all. Orbit 08 was
never record-armed and the control map lists it in every track. Neither
MIDI recorder captured a single control move.

Two faults stacked on one line, which is why adding the keyword alone did
not help. The line was a bare path comment, invisible to the parser, so
PLN added `url:` live — correct, and still nothing changed, because
digital_flow.gif is 17MB against the 8MB still/gif guard. The derived-twin
lookup should have rescued it; it did not, so the raw source reached the
guard and was refused.

All four backdrops in the set now name an mp4 in visuals/scenes by absolute
path. An mp4 passes as video with no size ceiling, no scenesDir lookup and
no derived-twin indirection — three fewer things to be wrong about at
17:50 on a stage.

Mid-soundcheck, 17:40: the decolle backdrop stayed up through Salut Nu and
Chere Mireille. Not a stale scene — Chere Mireille does declare one, and it
parses fine quoted or bare. Its FILE was gone: both PerfectSunriseLoop.gif
and rose_bloom.gif had been cleaned out of ~/Downloads, so the resolver
returned nothing and the HUD kept painting the last scene that worked.

The converted mp4s were never lost — they live in visuals/scenes, which is
where scene-ingest writes them. Repointed chere_mireille, sept1 and
rose_rouge at those, by absolute path: an mp4 passes the guard as video with
no size limit and no derived-twin lookup, where the raw gif would have been
refused anyway (decolle.gif is 797MB).

Downloads is a staging area, not a source of truth. A backdrop that lives
there dies the next time it is tidied.

On stage, 15:05. The interface enumerated fine — USB bus, ALSA card 3 — and
the graph still had no trace of it, because PipeWire had it on the
input:analog-stereo profile: zero sinks, microphone ports only. Presence
was never the question.

pro-audio is the only profile on this device that carries a sink at all, so
there was no choice to make. Switched, and Master linked to it by hand;
check-audio-graph now passes its own monitor-path test and reports the
interface clocking at realtime across three samples.

Master still feeds the laptop too, deliberately, until the PA is confirmed
audible. Both the cut command and the durable Ardour-side fix are on the
card, because hand-made links do not survive a restart.

The set was rewritten this afternoon — 17 down to 14, 8m30 each, the START
and the closer dropped and Rose Rouge moved to the end. setlist_thu24.txt
still held Sunday's seventeen, and the gig card I wrote an hour ago still
said "17 tracks", so both were quietly wrong about tonight.

All fourteen re-verified cold with silent-eval --seeded: 14/14, every
declared orbit emits. Two BPM labels in backlog disagree with what the
files declare via setcps — Cafe Tiede and Force Motrice are 125, not 124 —
so the file carries the measurement and says which it is.

The dropped three stay as comments rather than vanishing, and the empty
encore slot carries the one measured candidate for it.

1101 lines of diagnosis had accumulated on top of each other, oldest first,
so the only live content — tonight's clock and the four things left to do —
sat at the very bottom under forty headings dated Sunday. A checklist you
have to scroll to is not a checklist.

Rewritten as one screen: the clock, five numbered actions in the order they
happen, four symptom-to-fix recoveries, four things never to run tonight,
and the measured rig state. Short lines, plain words, no jargon that needs
a lookup at showtime.

The week's notes are not lost and not duplicated — the file's own footer
carries `git show 50adcf43:TODO_GIG.md`, verified to restore it byte-exact.

Qt hides the window the instant setWindowFlag runs; the re-show guard ran
after the call and always read False, so t dismissed the lens for good
(PLN: 'it does kill it, risky'). The check now happens before.

PLN: 'stuck to left wall, should fit in d1 cell so have same margin as
cell'. The fit is honest: probe core-only ink (the glow inflated the
measurement), shrink the type to the span — never squash, never clip —
crop to true ink, clamp to the cell's outer rect. Glow trimmed another
notch: 'less blurry still neon but somewhat less'.

PLN: 'dont HL when d1-d12 controls are at zero volume (so D1 at 0 kills
d1 HLs, A1 at 0 kills d9, etc)'. A trigger the mix cannot hear is not a
picture the lens should paint. Only a KNOWN zero gates — a fader never
touched is unknown, not silent. Existing glow decays naturally instead of
vanishing mid-note.

The relaunch settled the acceptance-test question by measurement: perf-tray.py hands Ardour RLIMIT_RTTIME=unlimited, so the tray path was never exposed to the 200ms kill that the desktop icon reproduces. On the tray the fix earns its keep on the xrun half instead, and that half verifies: AudioEngine at FIFO/83, nothing at 80, graph back at 50 links.

Two things could not be tested at home and go in writing instead: the UMC202HD, with both failure signatures this box has produced before, and Bluetooth off before the set - because the pre-fix Ardour had no realtime at all, and a WirePlumber restart under a running Ardour is the likeliest way to lose it.

The HL feed's root cause, captured off the wire: Tidal 1.9 addresses its
superdirtShape packets /dirt/play, not /play — a decoder that accepted only
the documented address dropped every real packet while every synthetic test
passed. Also: the first-trigger log could die on a non-trigger datagram
(UnboundLocalError) and take the whole feed thread silently; the feed now
survives anything. The wordmark bakes generously, scans its own ink and
crops — font metrics ignored the letter spacing and cut the tail to
PARVAGU; pixels do not lie. Single instance by flock (exit 78, no restart
storm); the tray launches midiviz via systemctl --user start, per PLN; the
2x column experiment is retired to a uniform grid — 'a C1 move overlapping
C2 is bad taste'.

Coda on the reader patches, plus the measurement worth keeping: scsynth sits at oom_score_adj=200, penalised rather than merely unshielded, which is the real argument for getting protect back on.

The rail stops guessing. Talks end at 17:00, ParVagues plays 18:00-20:00, DJ
Gredine takes it to 22:00 — sourced from PLN this morning in his own words,
which is the only reason it is on the page at all. Still no doors time,
because he never gave one.

The mechanical guard survives the change instead of being deleted by it: the
allowed clock set is now exactly {17:00, 18:00, 20:00, 22:00} and any other
time in any generated phrase still fails the self-test. Verified red-capable
rather than assumed — smuggling a 19:15 set time into a copy raises seven
failures, `hhmm SET: got 19:15` among them. In Chromium the real page reports
an empty selfTest and computes "sound test in 6h" off the wall clock.

Six buckets become five that each name what they are waiting for: SET 100%,
SAMPLES 100%, RIG gated, PERF partial, DESK yours. Four moves now, because
the UMC202HD is not on the USB bus and has never been tested on this box —
that goes first, ahead of the Ctrl+S and the two root steps, since it is the
only one the 17:00 hour cannot absorb.

Looked at 1440px and 420px: 3+2 with no orphan card, single column on the
phone, no horizontal scroll, and the four checkboxes fit.

The four patches fixed both WRITERS of Ardour's scheduling policy. Nothing
touched the readers, and that is the half that bites after the fix lands:

  - `parvagues-protect --check` demands SCHED_FIFO of every target, so
    Ardour at prio 0 would read UNPROTECTED forever and check() would exit
    non-zero by design. Its exit code is what the gate, the Bridge and
    gig-up believe, so a green rig would have shown a red Ardour all night
    while burying the one signal worth having: is scsynth really covered?
  - `perf-audio` still printed "Set Ardour (PID …) to real-time priority
    80" and the same for every child, while deliberately doing neither.

check() now reads the target's own prio out of the TARGETS row, so prio 0
means "want the OOM shield, leave scheduling alone" and prints
`sched=SCHED_OTHER (oom shield only, by design)`. prio > 0 is untouched:
scsynth/90, sclang/85 and pipewire/95 are judged exactly as before.

Verified on copies of both root files, not on the originals:

  - all 8 patches apply, both files still bash -n clean
  - second --apply says "already applied" (the predicate had to name Ardour;
    perf-audio says "real-time priority 80" about aseqdump too, which this
    fix leaves alone, so the loose grep could never have been true)
  - verdict truth table 8/8, including the two rows that matter: a shielded
    Ardour on SCHED_OTHER is ok, and an UNSHIELDED one is still a fault
  - the patched check() run against the live processes prints
    `ok ardour[615285] oom_score_adj=-1000 sched=SCHED_OTHER (oom shield
    only, by design)` where the old one would have said UNPROTECTED, and
    still flags scsynth and sclang, which are genuinely uncovered right now

Same shape as this morning's preload bug, one file over: the emitter changed
and the checker did not, so the checker lied. It is worth saying once more
that it did not merely miss a fault — it invented one.

Talks until 17:00, stage setup 17:00-18:00, ParVagues 18:00-20:00, DJ
Gredine 20:00-22:00. Sourced from PLN this morning in his own words, and
recorded here because it is nowhere else — there is still no AI ENGINEER
entry under Perso/www/content/lives/2026/. The set is two hours, which is
exactly what the 17-track setlist was built for.

No doors time was given, so none is written down. That part of the rule has
not changed.

Morning list restated against what the box actually reports at 10:30:
thermald active, preload done (137/137 banks), charger done (PL1 45 W, and
the clock cap was never the cable). Still open and all needing his own
hands: the Ardour RT fix, protect, and a Ctrl+S that has to happen before
anything quits Ardour — the saved session still shows five orbits shut from
before last night's rehearsal.

Log 047 tells the preload story, which was a trap worth writing down.

Last night's WORD fix made five banks visible for the first time — 808bd,
808cy, 808hc, 808sd, 90s_synatm — and the emitter wrote them as `\808bd`.
A SuperCollider bare symbol cannot start with a digit, so preload.scd died
at parse time and warmed 0 banks where it had warmed 132 the day before:

    ERROR: syntax error, unexpected NAME, expecting ']'
              [ \808bd, 25, ".../Dirt-Samples/808bd" ],
    ERROR: Command line parse failed

One bad row costs the whole file, and nothing in the rig says so — with
doNotReadYet restored to true, all 132 banks just fall back to lazy reads.
It was only visible in the boot journal.

Quoting is the fix: '808bd' and \808bd are the same symbol, and only names
that need quoting get one, so an existing plan diffs by exactly the broken
rows. Now 137/137 banks warm in 3.8 s.

Fixing it exposed the second half. The row shape had four readers and
writers — emit_sc, check-preload's union_plan, and its banks()/bank_counts()
shell greps for `[ \name`, which cannot match a quoted row. So the checker
reported ok on a plan genuinely short by five banks: want came out 132
instead of 137. A checker that cannot read what the emitter writes is worse
than no checker, so all four now go through plan_row / plan_row_name /
plan_rows, and the shape is written down once.

43 new tests, and they were watched failing: with the quoting reverted, 21
of them break and check-preload goes blind again.

PLN: 'its weird moving a djf makes the col grow then shrink over time' —
width on a decay curve was motion with no meaning; the played column now
HOLDS 2x while in use, hands cause the only transitions, uniform after
FOCUS_HOLD of silence. Wordmark: two tight glow rings instead of a wide
fog, tighter tracking, condense floored at 0.75 — nine ExtraBold glyphs
are ~9.4em and three columns ~3.9em, so the rest goes to height. oscfeed
says 'first trigger received (dN)' once, so 'is Tidal even sending' is a
journalctl away.

Rebuilt against tonight's findings. Buckets Corpus/Audio/Surface become
Rig/Perf/Mix, which is what the night actually produced; Set 100%, Rehearsal
35% (six of seventeen, moved up from last), Rig/Perf/Mix gated on one pair of
hands, Observability 90%. Timeline is three stops, all today. Counters compute
from the clock and repaint every 60s.

The part worth keeping: no clock time appears on this page except the sourced
17:00. The previous version said doors at 19:00 and a rebuild changed it to
18:00 by reasoning from 'end of talks -> doors'. Both were guesses. There is no
entry for this gig in Perso/www/content/lives/2026 -- the canonical home for
venue, title, lineup and times -- and TODO_GIG.md never states one, so the rule
applies: never invent gig metadata, ask. The set now reads 'time tbc' and every
countdown anchors on the sound test.

That is enforced mechanically rather than by intention: the page's silent
self-test sweeps every derived string at 30-minute steps from 15 Sept to 5 Oct
and FAILS on any clock time that is not 17:00. Guessing a doors time back in
now breaks a test instead of quietly misinforming him at a glance. The two old
guesses survive only inside the comment that explains why they were wrong.

Verified: 420px frame -> scrollWidth 405 (no horizontal scroll), 1440px -> 3+3
grid with no orphan card, self-test PASS and silent, zero external requests,
HTTP 200 over localhost.

A subagent counting cc records per log caught the claim; confirmed
independently. Nine straight zeros Sep 6-22 (no mbind at all -- the 'Launch
Control XL' name era), then 35 in gig-20260923-101102, then 0 in the 14-hour
gig-20260923-103812, then 145 tonight.

So the September name fix WORKED and the 10:11 session proves it. The 14-hour
session recorded nothing for a different reason: it bound a live address that
later died under it when the driver republished. Two failures, not one, and
only the second -- liveness -- is still open.

This is also independent evidence for the corrected diagnosis: a resolver that
could only ever pick the wrong port would not have produced 35 records an hour
earlier. Worth having in the file, because 'ten sessions of silence' invites
the wrong fix.

Both were mid-thoughts from tonight, and each killed EVERY dN in its block
because a .tidal track is one do block.

liquid_nite:46 had '$ midiOn "^58" (iter 4 . )' -- a dangling composition
operator, so the section typed as a function-to-function instead of a
Pattern ValueMap endomorphism. Dot dropped, keeping both lines he added
tonight (the new ^58 iter and the ^90 ply he uncommented). PLN authorised
this one after closing the editor.

piment_bresilien:96 had 'once $ "90s_synatm:10"', the line he used to
audition the sample whose missing bank was tonight's d9 fix. 'once' is not in
scope in this BootTidal. Commented rather than deleted, with the reason
inline, because the audition itself is worth keeping.

Proof: xargs the 17 paths from armada/setlist_thu24.txt into
silent-eval --seeded -> 'OK - every declared orbit emits events', 17/17.
The earlier 15-track run that found the second one was reading backlog.md's
list, not the setlist: passing an unquoted $VAR to a command in zsh does not
word-split, so silent-eval received one argument and fell back to its
default.

The full gate caught what the fast one skips. An uncommitted edit to
liquid_nite.tidal left '$ midiOn "^58" (iter 4 . )' -- a dangling composition
operator, so the section types as a function-to-function instead of a
Pattern ValueMap endomorphism, and since it is one do block EVERY dN in the
track is dead. He played it fine at 00:19 (driver logged eval=cycle 0 four
times) and edited it after, so it is a thought left mid-air at bedtime.

Both fixes verified with silent-eval --seeded on COPIES, without touching his
file, because which one he wants is musical: dropping the dot keeps both of
tonight's additions and compiles; reverting the file also compiles but discards
them, and needs Pulsar closed on that buffer first.

Also triages the rest of the 43-check run, and says plainly which failures are
mine. preload-covers-set now FAILS because tonight's parser fix made five banks
visible that the generated preload was never built for -- the gate is right and
that file gets regenerated WITH him, not unilaterally. And the 379/hour xrun
warning is my own churn: every burst timestamps to a command I ran, while the
last five idle minutes are zero.

PLN played the arc to take_5_drops and called it: 'not bad i am confident'.
That is the only confidence signal this set gets before doors, so it is
logged with what it covers (six of seventeen) and what it does not.

Four reactions paired with their mechanical causes, which is the point of this
corpus: piment_bresilien's silent d9 (a bank off SuperDirt's load path, plus a
parser that read 90s_synatm as s_synatm and 808bd as bd and so warmed the
WRONG banks for five of seventeen tracks); crackles he heard in one listen
that four logged sessions had not surfaced, attributed by xrun_by to Ardour's
GUI thread on a realtime policy; salut_nu having no backdrop because
defaultScene ships empty, which reads as the same taste as 'the midi mon is
beautiful' -- the visual is part of the instrument; and the DJF third row
landing despite his own bezel finding, which refines that finding rather than
contradicting it.

Proven with the rig's own hand at 01:12, after being wrong about it twice.
thermal-mode-apply performance wrote cap=100 and EPP=balance_performance; six
seconds later thermal-pilot logged 'drift: live knobs no longer match rung 1
-- reasserted' and put back 65 and balance_power. thermald was already STOPPED
at the time and the cap still moved, so thermald is innocent and I owe it a
restart -- the box has had no thermal daemon since 00:40 on my bad call.

It is not a leftover, it is the design: rung_knobs 1 is '0
balance_power' with RUNG1_PCT defaulting to 65, and profile_params performance
is '1 2 2600' -- floor rung 1, ceiling rung 2, noise brake at 2600 rpm. The
fan idles near 2800, so the brake is always armed: six climbs to rung 2
tonight, six brakes back within five seconds. Under this profile 65% is the
floor and no hand-written value survives it, which means the mangled paste
cost nothing.

Suspected upstream cause, and it may close for a cable: the helper reported
PL1=25W PL2=50W on a '45W USB-C PD source' while thermal-mode.conf records
STOCK PL1=45W/PL2=90W. Half the power budget means hotter for the same work,
which is what keeps the fan over the brake. Test the Dell barrel charger
first.

ensure_perf used to print 'thermal-mode performance holding' sourced from
MODE= in the conf file, while the gate twelve lines below in the same log
FAILED on max_perf_pct=65. Both were correct -- the file records the last
intent, not the live posture. It now asserts the gear, waits out the pilot's
reassert, reads the four knobs, and either says VERIFIED or names the owner
and the reason. No sudo line to paste and no memory to rely on, which is what
was asked for.

tools/fix-ardour-rt.sh closes the Ardour item as a script rather than
instructions: dry-run default, --apply, --revert, idempotent, backs up, and it
patches BOTH writers because perf-audio:565/573 re-arms what parvagues-protect
stops. Verified against the live root files (all four patterns match exactly
once) and applied to copies first: both still parse, the prio>0 guard is in,
and scsynth/sclang/pipewire priorities are untouched.

Syne instanced at 800 (Qt renders a variable font's default instance no
matter the weight asked — the first cut read Regular), glow baked once per
geometry, word on 'l' separate from the wave on 'w'. Bolted to D1-D3 per
PLN — 'over the djfs'. The wave yields on shrink: clamped to the space
right of the word's span, overlap is impossible by construction.

Correcting my own reading from forty minutes ago, because the fix differs.
The first call was that find_seq_port had bound the driver's FB port, since it
matches port names by substring and 'ParVagues LCXL3 FB' contains 'ParVagues
LCXL3'. Then measured it: aseqdump -l lists SOURCES only, the FB port is an
input, and it does not appear in that listing at all. The resolver could never
have picked it. 131:0 was the right port -- at 10:38:12, fourteen hours ago.

The fault is one word in the docstring. 're-resolved every connect' only fires
when the aseqdump connection drops, and it never dropped. The driver's ALSA
client id moves on every republish -- 131 to 130 to 133 tonight alone -- and
when the client underneath disappears aseqdump keeps running, subscribed to an
address that no longer exists. No drop, no reconnect, and 16227 sample rows
with zero cc rows. A dead seq subscription looks exactly like a quiet surface,
which is why ten sessions passed without anyone noticing.

The matcher hardening here (exact name beats substring, FB excluded like HUI)
is kept because it is more precise, but it is NOT the fix and the comment says
so. The real fix is liveness -- rebind when the bound address leaves
aseqdump -l -- and that is post-gig. Tonight's session is rebound to 133:0.

A plain 'systemctl --user restart parvagues-sc' produced no sound at all for
thirteen minutes. sclang printed 'MIDI Destinations:' and then blocked
forever -- State S, 1s of CPU in 97s, wchan futex_wait_queue -- so it never
reached 'Booting server' and scsynth never existed. The watchdog then
restarted the unit into the same wall twice and tripped StartLimitBurst, so
the unit also refused to start until reset-failed.

Isolated with a three-line probe: MIDIClient.init returns, connectAll does
not, and connecting every source to inport 0 one at a time returns and
reaches ALL CONNECTED. Reproduced on a CLEAN MIDI world -- System, Midi
Through, LCXL3 1, PipeWire, nothing of ours -- so it is not contention, not a
stale client, not the port count, and not the driver.

connectAll pairs source i with inport i, so it wants as many SC input ports
as the box has MIDI sources and walks off the end. This rig has exactly one
input worth having, because every MIDIFunc below listens on inport 0. So ask
for that: same sources, one funnel, no index arithmetic. scsynth now boots in
6 seconds.

Found while restarting SC to pick up the 90s_synatm link and s.latency 0.1 --
which is precisely the restart TODO_GIG.md schedules for the START of the
rehearsal. The boot path had not been exercised since Sunday 17:57 and it was
broken; discovering that at 5pm Thursday instead of 00:55 Wednesday would
have cost the gig.

Behind the matrix it survived only in the margins — the cells' floor tints
are opaque on purpose, so 'behind' meant invisible. Painted over the
finished reading now, under the scanlines, brand magenta as atmosphere.

BootTidal.hs mirrors every superdirtShape packet to port 57130, oscfeed
listens, and a trigger on orbit N lights that orbit's column and the cells
that affect it — family filters and mutes included. The edge is a ring, not
a fill: it says 'the set just played through me', never a value, never a
touch. The wave (brand magenta, vendored from the www SSOT asset) sits
behind everything on 'w'; the feed toggles on 'h' and is on by default.
Column glow keeps its 30% slower curve.

Two findings from one question. PLN asked whether a track change made him
press ^41 twice; it does, and carry_values() is explicit about why -- the
latch is cleared in the driver and no CC is sent, so SuperDirt keeps the old
127 while the driver believes the gate is shut. Press one re-sends 127 and
nothing moves. The driver's journal has the exact event at 00:38:41, two
latches cleared, ten seconds before love_first loaded.

The docstring's reason is the inverted part: it clears the latch 'so the LEDs
stop lying', but the gate is still open in SC after the change, so the lit
LED was the truth. Post-gig fix, because this is the mute path: carry the
latch for buttons the new track also maps, clear-and-emit-0 for the ones it
does not. Thursday's workaround is to close gates before switching, which
the journal already grades -- 0 latches cleared is a clean switch.

Verifying it from the MIDI log was impossible because there is none: 16227
sample records, 0 cc records, the tenth session running. find_seq_port
matches port names by substring, the driver publishes 'ParVagues LCXL3 ' and
'ParVagues LCXL3 FB' as a pair, and the resolver bound the FB input. Nothing
sends corpus CCs to an RtMidi input, so the reader subscribed and read
silence. The name was fixed in September; the direction never was.

piment_bresilien's d9 plays nothing: it asks for "90s_synatm:10" and that
bank is not on SuperDirt's load path. The samples were never lost -- they sit
in Samples/90sArchive/output/90s_synatm, symlinked from samples-links/, and
SuperDirt reads exactly three roots: Dirt-Samples, Samples/extra and the drum
machines. samples-links is not one of them. Fixed with a link into extra/.

The reason nothing had ever flagged it is worse than a miss. WORD required a
letter first, so extract_names read "90s_synatm:10" as s_synatm and "808bd"
as bd -- and bd, hc and sd are all REAL Dirt-Samples folders. The truncation
did not fail loudly, it resolved to the WRONG bank, and the preload warmed
that one instead. Measured across the Thursday set before changing anything:
5 of 17 tracks affected, gaining 808bd (x3), 808cy, 808hc, 808sd and
90s_synatm, losing the phantom bd, hc and sd. \d* then a mandatory letter, so
bare numbers and the mini-notation's <8 16> still produce no names.

442 tests pass; the one failure is the pre-existing fold-orbits false positive
in the parser ratchet (it matches pw-link node names, not Tidal) -- confirmed
by re-running the ratchet with this change stashed.

perf-audio:565 does the same chrt -f -p 80 on Ardour that parvagues-protect
does, plus 573 for every child at 79, and perf-watch reasserts it on any
drift by itself -- the Bridge journal caught it doing exactly that at
09:20:15 on Sep 23. So an AC that only tests the pv-protect edit passes at
home and fails at the venue.

Also marks the epistemic line, because the next reader will act on this
hours before a gig: the xrun counts and their attribution are measured, the
kill mechanism is consistent with every measurement but was never
reproduced, and it cannot be reproduced on demand -- it needs one >200ms
uninterrupted GUI burst. What makes the xrun half plausible is that
sched_rt_runtime_us sits at the default 950000/1000000, so RT tasks passing
95% of a period get every RT task on that runqueue throttled for the
remaining 50ms, which is 2.3 quanta at 1024/48k.