midi-autoconnect, CHANGELOG, TODO.d: say what is actually bounded, fix the drills

Only rule 4's own start calls are capped; once started, the unit's
Restart=always retries forever by design. The first drill would have 'failed'
for the right reason (the repairer beats the observer's debounce), so it now
stops the repairer first.

CHANGELOG.md

@@ -13,8 +13,8 @@ while the real fault sat unread.
 ### Fixed
 - **Faders that did nothing.** The LCXL3 enumerated *after* `gig-up` had chosen
   its painter, so nothing ever started `lcxl3-driver`. `midi-autoconnect` now
-  starts it whenever a raw LCXL3 is on the bus (bounded retries, never the v2
-  painter). The unit stays `manual` on purpose: enabling it at login would
+  starts it whenever a raw LCXL3 is on the bus (its own starts are capped and
+  spaced; never the v2 painter). The unit stays `manual` on purpose: enabling it at login would
   crash-loop on every day the surface is unplugged.
 - **A silent rig.** PipeWire's graph was clocked by the MIDI bridge instead of
   a sound card, so nothing played and no MIDI crossed to Ardour. After a card

TODO.d/2026-10-11-rig-health-followups.md

@@ -21,10 +21,19 @@ are the threads left, in the order they cost to leave. Two need a human decision
 ## 2. Witnessed drills (need a quiet moment and the owner's OK, not mid-play)
 
 The unit tests prove the logic; only these prove the wiring.
-1. Stop `lcxl3-driver`: tray goes red and notifies within ~10 s; midi-autoconnect
-   restarts it within its cooldown; tray recovers.
+1. **Observer drill.** Stop `midi-autoconnect` FIRST, then stop `lcxl3-driver`.
+   (With the repairer running, it restarts the driver on its next 2 s tick, which
+   beats the 5-tick debounce: the tray never goes red and the death shows only in
+   the journal. That is the repair working, not the observer failing.) Expect a red
+   dot and a critical notification within ~10 s, and a "recovered" one after you
+   start the driver again.
+   **Repair drill.** With `midi-autoconnect` running, stop the driver: it must be
+   back within a few seconds. Open question for the owner: a self-healed death is
+   invisible in the tray by design; say if you want it surfaced.
 2. Unlink Master from every sink: autoroute re-links it within 2 s.
-3. Stop `gig-log`: the tray shows "observer stale" (red dot), not green.
+3. Freeze `gig-log` (`kill -STOP` its MainPID, then `-CONT`): after ~30 s the tray
+   shows "observer stale" (red dot). A *stopped* gig-log reads "not observed" (no
+   badge), which is correct: the rig is simply not being watched.
 4. Unplug and replug the LCXL3 with `lcxl3-driver` stopped: the driver starts on its
    own within a few seconds.
 5. `check-gig.py` returns GO at pilot rung 1 and a BLOCK with the driver stopped.

tools/midi-autoconnect.sh

@@ -189,9 +189,11 @@ reconcile() {
 #   * Only the RAW kernel client counts. 'ParVagues LCXL3' is the driver's own
 #     virtual port and matching it would make the driver vouch for itself.
 #   * The v2 painter is never auto-started (it Conflicts= the v3 driver).
-#   * BOUNDED: a driver that fails with the board present is retried a few times,
-#     then left alone. An unbounded retry is how priapos reached 1069 restarts;
-#     the gate (BLOCK) and the log say what is wrong instead.
+#   * BOUNDED, but only THIS loop's own `start` calls: a few tries with a cooldown,
+#     then it leaves the unit alone. Once started, the unit's own Restart=always
+#     with StartLimitIntervalSec=0 keeps retrying forever, by design (that is what
+#     rebinds within seconds of a replug), so a driver that cannot bind is retried
+#     by systemd, not by us. The gate (BLOCK) and the log say what is wrong.
 DRIVER_UNIT="lcxl3-driver.service"
 DRIVER_COOLDOWN="${MIDI_AUTOCONNECT_DRIVER_COOLDOWN:-30}"
 DRIVER_MAX_TRIES="${MIDI_AUTOCONNECT_DRIVER_TRIES:-4}"