chore(todo): file the flaky fader-drag probe check

It fails about one run in six: the synthetic drag lands before the zoom relayout has settled, so the press misses the fader and the readout never moves. I filed it rather than fixing it, because the tempting fix is raising the sleep, which hides the race instead of removing it.

1 files changed, 13 insertions, 0 deletions

diff --git a/todo.org b/todo.org
index 3fdf673..bd56197 100644
--- a/todo.org
+++ b/todo.org
@@ -207,6 +207,19 @@ Restyle the audio panel's GTK CSS onto =tokens-waybar.css= + the banked composit
 After ~5 hand ports, weigh widget-level codegen with evidence (mechanical duplication vs judgment per port). Recorded as a dated decision in the spec; go spawns its own spec.
 *** TODO Flip the spec to IMPLEMENTED
 When the phases above close: status heading keyword → =IMPLEMENTED=, dated history line with the reason, Metadata =Status= mirror. Three lines, one file.
+** TODO [#C] Gallery probe: the fader-drag check is flaky :bug:test:design:
+=probe.mjs= check 3 ("fader drag tracks at 3x") intermittently reports =level 68 -> level 68=, i.e. the synthetic drag never registers. It has presumably been doing this all along unnoticed, since the suite is normally run once per batch.
+
+Grading: *Minor* severity (a false FAIL costs a re-run and a few minutes, and never ships a defect) x *most users, frequently* = P3 = =[#C]=.
+
+Frequency measured 2026-07-16, not estimated: 1 failure in 6 consecutive runs, having already fired twice in about fifteen that afternoon. The first grading guessed "some users, sometimes" (~1 in 10); at ~1 in 6, both people who run this suite hit it most sessions, so the row is "most users, frequently". The letter lands on =[#C]= either way, but the input was wrong and the matrix is only worth anything if its inputs are measured.
+
+Suspected cause: the check clicks the 3x size chip, calls =scrollIntoView=, waits a fixed 200ms, then reads =getBoundingClientRect= and dispatches the drag against those coordinates. If the zoom relayout or the smooth scroll hasn't settled, the rect is stale and the press lands off the fader — so the drag is a no-op and the readout never moves. The other timing-sensitive checks share the same fixed-sleep shape.
+
+*Do not fix this by raising the sleep.* That hides the race rather than removing it and leaves the check failing again on a slower run. Wait on the actual condition instead: poll until the rect stops changing between frames, or assert the press landed on the fader before dispatching the drag (the probes' own README already warns that a =find()= miss dispatches into nothing and reports as a widget bug).
+
+Why it matters beyond the annoyance: a gate that cries wolf gets its real failures ignored, and this suite is the only thing standing between the gallery and a silent regression.
+
 ** TODO [#C] Maint live-refresh hairline replacement :feature:maint:
 :PROPERTIES:
 :LAST_REVIEWED: 2026-07-14