docs(tasks): archive #58 — the LED thread's real bug was that nobody could see the output

Three days stuck on LED feedback that had never once been observed lighting a
physical LED: every validation ran against a fake aseqdump stream. PLN confirmed
the hardware works on 2026-07-28. Building the mock surface took under an hour
and immediately explained the complaint that had survived two rounds of fixes —
the DJ filters rest at BRIGHT AMBER, which is filter_colour(64) behaving exactly
as designed and visually identical to the factory yellow he was trying to escape.
Correct and looks-broken were the same picture.

armada/tasks/completed-archive.md

@@ -522,3 +522,52 @@ bypass**, down is a hard low-pass.
 #56 (event density exonerated as a crackle cause), #12 (one of three tempo questions
 dissolved), #33. Spawned #68 (orphan orbits). Ran alongside #67 (LED painter) in a
 parallel agent.
+
+---
+
+## #58 — Verify the DJF LED ramp live after reload
+
+**Description.** The LCXL LED feedback had been built, wired into `tidal-remote.py boot`
+and `gig-up.sh`, and shipped — but never once seen to light a physical LED. Every
+validation to that point ran against a *fake* `aseqdump` stream. PLN's repeated reports
+("still seeing static colors", "no touch-reactiveness actually neither on button nor
+knobs") could not be distinguished from "the tool is completely broken" because nobody
+on either side of the keyboard could observe the device.
+
+**Done.** Closed 2026-07-28 by PLN on real hardware: *"i see hardware led btw, and press
+states work! ... i see also filters and effects working as expected"*. The value→colour
+ramp, the button press states and the effect colours are all confirmed live.
+
+Supporting work landed the same night (`80b732b`): `tools/mock-lcxl.py`, a virtual
+LaunchControl XL that decodes the same SysEx the device receives and renders it in the
+terminal, so the convention can be designed, reviewed and regression-tested without
+hardware — plus `value_ramp()`, PLN's six-step convention, and 8 regression tests.
+
+**Learnings.**
+
+- *The observability gap was the bug's hiding place.* For three days the LED thread was
+  stuck not because the code was wrong but because neither party could see the output.
+  Building the mock took under an hour and immediately explained the complaint that had
+  survived two rounds of fixes.
+- *"Correct" and "looks broken" can be the same picture.* The mock showed knobC 1-3
+  painting **bright amber (63)** at rest — which is exactly `filter_colour(64)`, the DJ
+  filters at centre/bypass, behaving precisely as designed. Bright amber at rest is
+  visually indistinguishable from the factory yellow PLN was trying to escape. The code
+  passed every test and still produced the exact experience it was meant to eliminate.
+- *A second finding from the same run:* `control_colour()` returns `hue["full"]` for every
+  value from 8 to 119, so a touched knob is one flat bright colour across its whole
+  travel. Touch changes it once and then it never moves again — the literal definition of
+  the "static colors" report.
+- *The palette is the design constraint.* The LCXL is bicolor: 2 bits red × 2 bits green =
+  16 states, of which roughly six read reliably on a dim stage. PLN independently asked
+  for a six-step ramp. The hardware budget and his taste landed on the same number, which
+  is a good sign that the convention is the right shape.
+- *Transport, re-learned:* `amidi` works on a cold rig and fails on a live one, because
+  SuperCollider's ALSA sequencer holds the rawmidi substream. `aseqsend` to the
+  **sequencer** port coexists. The tool that works only when nothing else is running is
+  the tool that fails at the only moment that matters.
+
+**Deps.** Unblocked the remaining LED thread: #11 (colour convention — the two design
+findings above are now its open questions) and #71 (latency: the LEDs work, but lag 1-2 s
+behind fast fader moves, because every changed LED costs a `subprocess` fork+exec inside
+the reader loop).