CLAUDE.md, TODO.d: the tray's one Quit, and what the recorder does after a suspend

CLAUDE.md

@@ -82,13 +82,15 @@ ParVagues' main livecoding workspace.
   a gig take not recorded costs the gig. Do not make it opt-in again.
 - **`lcxl3-driver` is `manual` on purpose** (`rig_units.py`): with no board it crash-loops.
   `midi-autoconnect` starts it when a raw LCXL3 is on the bus. Never enable it at login.
-- **Ending a session: `music-work end`** (the ParVagues tile's "End session", the tray's
-  "End session…", and what the tray's Quit offers while the rig is up). It stops the SuperDirt
+- **Ending a session: `music-work end`** (the ParVagues tile's "End session", and the tray's one
+  **Quit** while the rig is up). It stops the SuperDirt
   watchdog first, then SuperDirt (the black box stops with it), then hands over to
   `music-work off`. It refuses while a take is rolling and NEVER closes Ardour (it may hold
   unsaved work): with Ardour open it stops short, exit code 3, and a second run after you
-  have saved and closed Ardour finishes. `--dry-run` says what it would do. Plain tray Quit
-  only closes the tray; the rig and music mode keep running.
+  have saved and closed Ardour finishes. `--dry-run` says what it would do. The tray is up exactly
+  when the rig is up (`parvagues-sc` Wants it, so any bring-up starts it), so Quit has one
+  meaning: rig up -> end the session (the tray goes last, and stays if the end refuses);
+  rig down -> just close the tray.
 - Rig health lives in `~/.cache/parvagues/health.json` (written by `gig-log`, read by the
   tray and the Bridge). Owners repair, `gig-log` observes, the faces only read.
 

TODO.d/2026-10-13-recorder-after-suspend.md

+# The black box after a suspend: found, not yet fixed (2026-10-13)
+
+Owner saw a sticky "rig: recording is down" at 10:00. Two separate facts, one of them
+a wrong first guess worth keeping out of the next investigation.
+
+## What the evidence says
+
+- The alarm was NOT the wake. The only resume that morning was 09:44:15 (lid opened,
+  `PM: suspend exit`); the alarm fired 10:00:39, "newest segment is 56s old", with the graph
+  healthy (SuperCollider and the recorder both running, linked to the live sink). It recovered
+  by itself. Cause of that 56 s write gap: **unknown**. Nearby in the journal: a lock/unlock
+  and a display change at 10:00:40-55. Not proven related.
+- **The recorder has been running on skewed timestamps since the wake.** `recordings/recorder.log`
+  holds ~255,000 `Non-monotonic DTS ... changing to prev+1` lines and libopus says `Queue input
+  is backward in time`; the lines still arrive every packet. Two segments report absurd
+  durations (100k and 158k s). The segment that should have run to 21:02 closed at 09:44. The
+  audio is probably intact; the clock under it is not, and a muxer on a clock that runs backward
+  is a plausible source of the 56 s hole. Not proven.
+
+## What to do (measure before mechanism)
+
+1. Restart `gig-record` alone at a quiet moment: `systemctl --user restart gig-record`. It never
+   touches the sound; it costs the second or two between segments, and it gives the recorder a
+   fresh clock. Verify: the DTS lines stop (`recorder.log` stops growing).
+2. Only then pick the durable fix, and test the pick, do not choose ffmpeg timestamp flags
+   from memory. Candidates: restart the recorder on a resume (resume is detectable without
+   root: `CLOCK_BOOTTIME - CLOCK_MONOTONIC` jumps by the time slept), or fix the input clock.
+   Put it in the recorder's owner (`gig_record.sh` / its unit), never in `rig_health.py`
+   ("owners repair, gig-log observes").
+3. Health side, after the owner fix: a bounded grace after a real resume, just long enough for the
+   first new segment to land, then FAIL again. Keep "unit not installed" and "no segment exists"
+   loud (the 2026-10-11 failures). A grace without the owner fix would hide a real fault.
+
+Do not add a resume-grace on its own: it would not have silenced this alarm.