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.

The desktop icon brought Ardour up at 23:59 and the shell reported it Killed
ten seconds later, three lines before gig-up said 'gig-up done'. One root
cause under three complaints:

parvagues-protect's ardour:80 target promotes Ardour's GUI thread to
SCHED_FIFO/80. Its audio thread already gets RT from the backend the right
way (AudioEngine 1, FIFO|RESET_ON_FORK at 83, above the GUI), so the
promotion buys nothing and costs two things. RLIMIT_RTTIME is inherited and
differs by launcher -- gnome-shell hands children 200000us, a systemd user
unit hands them unlimited -- so an Ardour started from the icon carries a
200ms realtime budget, and loading the session blows it: SIGXCPU then
SIGKILL, with no kernel log line, which is why the journal looked clean.
And a GUI thread at 40-85% of a core on a realtime policy misses deadlines:
xrun_by.ardour went 0->46 in six minutes, and it is chronic, not new --
5172, 4852, 1114 and 987 ardour xruns in the Sep 10/18/20/22 sessions.

d1 alone on the speakers was never a second bug; it is what WirePlumber
does with SuperCollider:out_1/2 when there is no Ardour to route through.

Also: the DJF overlay's third row was an empty string, which is a row paying
no rent. It now carries travel from the bypass detent as a signed percent,
each side normalised against its own throw so 100% means end stop. The
cutoff stays on row 2 -- row 3 is the bezel row.

Findings in TODO_GIG.md with Thursday reordered; story in armada/tasks/046.

Recorded as a decision rather than an omission — he saw the venue, could not
soundcheck, and chose at midnight not to run the arc. The consequence is that
one hour between the talks ending and doors is the entire empirical test of a
two-hour set, so the plan protects that hour: every machine step moves before
5pm, and the hour itself is ears only.

Two orderings that matter and are easy to get backwards: plug the UMC BEFORE
gig-up, because Ardour restores its own saved ports and does not follow the
PipeWire default sink; and check the MIDI log is actually capturing during the
hour, because nine previous sessions were empty while their headers said
otherwise.

Three things had gone stale within the half hour: the push had landed, so the
third move is now the live-fader blind spot it was hiding (check-mix reads the
SAVED session and Ardour OSC is still off, so the Master needs setting and
saving); the MIDI log is no longer 'binds at last' but capturing, verified
against real cc records in corpus numbering; and the footer carries the gate's
own receipt with the gate's own caveat attached, because 0 fail proves the set
BOOTS correct and says nothing about whether the mixer IS correct.

0 fail / 3 warn / 39 ok with the rig warm, 132/132 banks, 0 xruns per hour —
the 457/hour this morning was the dead NVIDIA sink, not the CPU.

Five learnings archived from the morning, all one shape: a check that asks the
wrong question reports success. A resolver matching hardware by product name
outlived the hardware in three files at once; a capability check that asked
'is the tool installed' wrote midi:true over nine empty sessions; a probe
gated on a precondition it did not need skipped the entire setup window; an
availability flag structurally incapable of being false hid a disconnected
cable for months; and a unit's start time is the only thing that distinguishes
running code from readable code.

Rebuilt for Wed 23. Audio, surface and observability all moved this morning:
the laptop card is back on HiFi and the NVIDIA pin is retired, the LCXL3
driver's 1077 silent failures are explained and surface-state.json is live for
the first time, and the MIDI log binds a port at last after nine dead sessions.

The countdown computes from the real clock at every stop, so the page cannot
go stale into the gig; checked at five instants from today through three days
after.

Answering 'now if i reboot, will gig log be part of any parvagues run?' — yes,
gig-log is enabled and starts at login. But lcxl3-driver is linked, not
enabled, by the on-demand policy rig_units.py owns. So at boot this reader
binds the board's own DAW port and the driver appears later, and the loop
re-resolved only once aseqdump exited. 24:1 does not exit, so a whole set
would have been recorded from the raw board.

Translating the numbers is not enough on its own: with the driver up, rows B
and C are switched to RELATIVE, so the raw port carries encoder DELTAS, and
writing those down as absolute values would be a confident wrong record — in
the one file whose entire job is to be trustworthy after the fact.

So a bound reader now asks, between events and at most every 15s, whether
something better appeared, and rebinds if so. 'Better' is preference_rank
against the authored order, not a judgement, and an unplaceable name ranks
last so we can never downgrade into it. A port pinned with --midi-port is
never second-guessed.

'how can i watch yesterday's build? Every new release should restart bro. that
was wasted time' — a pass lost to a midiviz restarted the night before, which
therefore contained none of that night's four commits. systemd said active
(running) the whole time, correctly: a unit holds whatever the interpreter read
at ExecStart, and from outside there is nothing to distinguish it from a unit
on current code.

Comparing the unit's ActiveEnterTimestamp to its ExecStart file's mtime is the
only honest test, and it is deliberately not a git comparison: the question is
'is the process executing what I can read', so an uncommitted edit counts.

ADVISE, never BLOCK — a stale lens is not a reason to refuse a launch. --fix
restarts only the inaudible login units; SuperDirt and the two painters are
reported and left alone, since gig-up's generation-aware chooser owns when
those cycle.

find_seq_port defaulted to the literal string 'Launch Control XL' — the
ORIGINAL board's product name. The LCXL3 advertises itself as 'LCXL3 1', so
the resolver matched nothing from the day the hardware changed. All nine
recorded sessions from 2026-09-06 onward contain zero cc records, and every
one of their headers says "midi": true, because available() only asks whether
aseqdump is installed: the reader existed, reported itself on, and bound
nothing. run() re-resolved every 5s exactly as designed, forever, against a
name that could not match.

Now it walks the same authored preference midimon and midiviz use, translated
port first, because corpus numbering is the only numbering a log is worth
mining in. A night that falls through to the board's own DAW port is
translated through lcxl_grid.V3_TO_V2 on the way into the window, so the log
is always in corpus numbers and a reader months later never has to know which
port that night happened to bind — and an 'mbind' record now states the port,
the name and whether translation was applied, since the nine silent sessions
happened precisely because nothing recorded that the answer was none.

Coalescing is unchanged and keeps v0/v1/lo/hi/n, which is what makes 'minute
23:30 the bass is too saturated' answerable from the file.

Also adds tools/check-stale-units.py: a unit running three-day-old code is
indistinguishable from a healthy one from outside, and comparing its start
time to its ExecStart file's mtime is the only honest test.

PLN on the NVIDIA card: 'it NEVER served me, 100% of the time'. He is right,
and the reason it kept getting chosen was a saved pin to pro-audio — a profile
whose 'available' flag is unconditionally yes, because it maps raw PCMs and
asks no questions about cables. So four sinks reported perfectly healthy while
every ELD on the card read monitor_present 0 and every connector read
disconnected. Sound was not muted or misrouted, it was converted and discarded.

The pin is retired (that card is now off, and WirePlumber's own findBestProfile
will not go back to pro-audio by name). The check that would have said so in
one line now exists, keyed to the ELD rather than to the profile's own opinion.

Narrow on purpose: it accuses only a sink that leaves the box over a video
cable, reusing fold-orbits' predicate, because the sof card carries Speaker AND
an HDMI output — a check keyed on the CARD would have accused the laptop
speakers while sound was coming out of them.

The first resolver called realpath() on /proc/asound/cardN, which is a plain
directory, matched nothing, and made the detector dead code that reported
success. A test now asserts it reads sysfs.

Shipping the translation on raw_port was too wide. That flag means 'the picture
comes from the board, not the driver', which is true in DAW mode AND in custom
mode -- but only DAW mode has a fixed, known numbering we may rewrite. Custom
mode speaks whatever the user assigned, so translating it would have been a
second wrong picture with the opposite sign.

Not hypothetical: midiviz's reader was on 24:0 'LCXL3 1 MIDI In' at the moment
this was written (its aseqdump child, PPID 7049), i.e. exactly the port the
wide rule would have mistranslated.

So two flags for two questions. raw_port keeps the warning pip on any raw LCXL3
read; v3_dialect authorises the rewrite and only DAW satisfies it.