fix(rig): CosmicFest has no session log because nothing in the inventory knew the recorder existed
PLN: "what gig-log didnt run that night? HOW COME? ... thats sad and needs proper tech debt payment! We cant afford to miss that." The answer is not a crash. gig-log.service was installed 2026-07-29 and then left `disabled`, and rig_units.py mentioned it ZERO times. So the authored inventory could not enable it, --ensure could not assert it, and gig-up never gated on it. It ran only when somebody remembered to start it by hand — and the sessions that exist, up to 2026-08-20, are exactly those manual runs. Two known failure shapes, both already named in this repo, stacked: The unit lived ONLY in $HOME, never in the repo. That is 4d9f1059 again, the two reconcilers rescued from $HOME after five orbits reached no Ardour track. A file that exists in one home directory is not infrastructure, it is a habit. And it was missing from the one authored list. That is what 406a4610 was written to end ("the list lived in three places"). An inventory only prevents the class of bug it actually enumerates; gig-log was simply left off, so it inherited none of the protection. What was lost is not just thermals and xruns. It is the TRACK BOUNDARIES — the gig log's `track` events are the real tracklist (reference_gig_log_is_the_tracklist). Recovering CosmicFest's set afterwards took two independent DSP lenses, 30 reference renders, and it still leaves two unlabelled stretches. One always-on 1 Hz recorder costing 0.4% of a core would have made all of that unnecessary. Paid in three places so it cannot recur: - tools/gig-log.service, versioned, symlinked into ~/.config/systemd/user - gig-log in rig_units.py SERVICES, so --ensure enables it and the generated parvagues-rig.target Wants it (8 units now) - a HARD gate in gig-up.sh The gate deliberately does not ask "is the unit active". A green unit is not a recording — the process can be up while the writer is wedged (reference_sc_supervision, feedback_verify_the_plumbing). It asserts that a session file's mtime is within 20 seconds, i.e. it is writing NOW. Verified it can actually fail, because this repo already has a log titled "the checks that could not fail": stopped the recorder, waited 25s, the gate failed; restarted, age 1s, passed. Still open, recorded not fixed: the HUD's eval-events.jsonl also missed the set. It holds 21 evals on 2026-08-23 from 18:31-18:59 (prep at home) and then four `pluie` evals at 22:14 with zero orbits, with a 3h15m hole across the gig itself. Pulsar was running, so the likely cause is reference_pulsar_lazy_activation — a reload leaves the package dormant — but that is a hypothesis, not a diagnosis.
Showing
tools/gig-log.service
0 → 100644