docs(tasks): Tue-22 gig state — the latency cut is not live, the CPU is capped,…

docs(tasks): Tue-22 gig state — the latency cut is not live, the CPU is capped, and the play log names the set

Three corrections from measurement: sclang predates the s.latency edit (still 0.2 in the
process), max_perf_pct is 55 so every audio number is suspect, and the driver journal shows
12 tracks actually played in 5 days — five of them outside the overnight sweep.

TODO_GIG.md

@@ -16,10 +16,12 @@ Set material: shortlist pending from PLN. Rehearsal Tue 22. Rig: XPS24 (corpo bo
   max_perf_pct — a leftover cap from a prior `--cool`/`--silent` (55%!) silently survives a
   standard perf pass. The sudo line is mandatory, not optional. This is the preflight FAIL
   behind the 270 xruns/h signal.
-- [x] **s.latency 0.2 → 0.1** — EDITED (start_and_midi.scd:432, comment rewritten honestly);
-  restart of parvagues-sc pending in the combined restart window. AC: after 10 min of playing,
-  0.1) + restart parvagues-sc. AC: after 10 min of playing, `journalctl --user -u parvagues-sc
-  -b | grep -cE '\blate [0-9]'` still 0. Revert to 0.2 on any 'late'.
+- [ ] **s.latency 0.2 → 0.1** — EDITED in `start_and_midi.scd:430` but **NOT LIVE**
+  (verified Tue 22: sclang running since Sun 20 17:57, file edited Sun 21 22:48 — the process
+  still holds 0.2). Needs a `systemctl --user restart parvagues-sc`, which interrupts play, so
+  do it at the START of tonight's rehearsal. AC after 10 min of playing:
+  `journalctl --user -u parvagues-sc -b | grep -cE '\blate [0-9]'` still 0 — revert to 0.2 on
+  any 'late'. (The 0-late reading taken Tue 22 measured the OLD 0.2 config and proves nothing.)
 - [ ] **Quantum 512 test** — `pw-metadata -n settings 0 set clock.force-quantum 512`, listen to
   Keys/Mic monitoring vs 1024. Keep-or-revert decision recorded here: ____
 - [ ] **BT hardening** — `rfkill block bluetooth` behind a gig-up flag (the wireplumber-churn
@@ -57,6 +59,49 @@ DJF readout into HUD via Ardour OSC · record-arm automation at session open ·
 add-bursts · re-encode 120MB scene twins (crf 28) · event-driven reconcile (pw-link -m) ·
 bitmap-rendered DJF needle · Pulsar upstream #229 / tidal.nvim evaluation.
 
+## Tue 22 — state (2 DAYS OUT, gig Thu 24)
+
+Shipped + live today: OLED bring-up-after-write (9507ad6), all 32 knobs on our overlay
+(9a4918a), stale-copy tripwire (8f00e29), cyber_hump revived (0f99fba), encoder end-stop
+slam (8e7b713), lookahead + BT flag (aa41686).
+
+Open, highest leverage first:
+
+- [ ] **YOU: lift the CPU cap** — `max_perf_pct` measured at **55** right now (governor IS
+  `performance`, so perf.sh ran; the pstate cap survives it). Until this is 100 every audio
+  measurement (xruns, quantum, headroom) is untrustworthy:
+  `echo 100 | sudo tee /sys/devices/system/cpu/intel_pstate/max_perf_pct`
+- [ ] **YOU: pick + order the 2h arc** — Set Builder: http://192.168.1.11:8899/setbuilder.html
+  (status page: http://192.168.1.11:8899/status/). Export the paths back here and the preload
+  plan + a final silent-eval pass follow.
+- [ ] **SC restart** to load 0.1 latency (see above) — at the start of the rehearsal.
+- [ ] **OLED stale-value fix** — root-caused Tue 22 by code reading, fix in flight:
+  (1) `tick_overlay`'s 0.9 s re-arm REPLAYED cached strings, so a stale readout was reprinted
+  forever; (2) `oled_touch`'s 20 Hz front door DROPPED events without parking any pending
+  value; (3) `run()`'s "pinned at an end stop" `continue` skips the display entirely at 127.
+  Together: a hard DJF swing froze the readout (PLN saw "HPF 5.6kHz" ≈ value 108 while the
+  filter kept moving; 127 = 8.0kHz, and each count moves the string ~0.13 kHz so the readout
+  is NOT quantized — it was genuinely stuck). Fix = recompute on re-arm (self-heals within
+  0.9 s), park instead of drop, flush the freshest value. Momentary `family_mute` lines still
+  replay (mutes_held() is transient).
+- [ ] **End-stop slam is UNMEASURED** — shipped with a `|d| >= 63` trigger, but a read-only
+  75 s probe captured **0 CC messages** (PLN was away), so whether the firmware ever emits a
+  saturated ±63 delta is unknown. Likely dead code. Re-run
+  `scratchpad/delta_probe.py` while PLN sweeps, read the delta histogram, THEN set the
+  threshold from reality. Builder also flagged 123 → 127 overshoot at the `>=115` band.
+- [ ] **techno_orage d2** (line 158) silent even seeded — fix or cut. PLN's call.
+- [ ] **Preload gaps**: `bass2`, `humps` lazy-load mid-set. Regenerate after the arc is picked.
+
+### Play history — the real candidate pool (discovered Tue 22)
+
+`journalctl --user -u lcxl3-driver` logs every track load. Last 5 days, 12 distinct tracks:
+techno_orage(2), rose_rouge(2), piment_bresilien(2), you_my_sunshine, sunny_side_up,
+something_about_drums, sept1, quand_on_decolle, jeudrill, ete_a_mauerpark, cafe_glace,
+bombe_dj. That is a 2h set at ~10 min each, chosen by PLN's own hands — a stronger signal
+than git-modified files. Five of them (rose_rouge, sunny_side_up, quand_on_decolle,
+something_about_drums, bombe_dj) were outside the overnight sweep and are being validated.
+Catalog for reference: 703 `.tidal` files under `live/`.
+
 ## Learnings (Sun 21 night)
 
 - LCXL3 protocol has no LED/OLED readback — ghost file (`/tmp/lcxl3-oled-ghost.txt`) is the