From 8e941f97b94d6770d5234c6578bf2bc869e3115e Mon Sep 17 00:00:00 2001 From: Markus Kovero Date: Tue, 1 Sep 2026 11:24:45 +0000 Subject: [PATCH] docs(rig): restore the #368 and #369 verification blocks lost in a refresh MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Both blocks were written by their PRs' QA rounds and destroyed six days later by a chore commit, so two open QA findings currently have no recorded way to close them. - #368's `TAU_SNR_THRESHOLD_DB` block (17 lines) was added by 8c36a060 and lost in dae1f47a on `issue-368`. - #369's xrun-threshold block (29 lines) was added by d2cbf179 and lost in 30f9c74a on `issue-369`. Both chore commits are titled "refresh .agents, bin, .claude and rig from main" and both moved `work/rig/rig-verify-queue.md` to `rig/` to match main's layout. The move itself was right. Taking main's *content* along with the path was not: git recorded it as a rename with edits (-35/+15 and -38/+15), which reads as tidy-up in the log and conflicts with nothing, so neither branch's own queued measurement survived and nothing flagged the loss. Restored verbatim from those two commits, placed together in "Still to run" ahead of the #243 AC7 bullet, where the #369 block originally sat. The criteria and their falsifying values are unchanged. One line added to each that was not in the original: which branch to build. Both blocks describe behaviour that exists only on their PR's branch — `tau_pre_impulse_snr_db` and `tau_reading{1,2}_xruns` are fields neither of which `main` emits — so a rig operator working from `main` would find nothing to measure and could easily read that as a passing run. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_017tb982HsRpbLenwEq2cay1 --- rig/rig-verify-queue.md | 56 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 56 insertions(+) diff --git a/rig/rig-verify-queue.md b/rig/rig-verify-queue.md index b9fe7030..4bdbf09f 100644 --- a/rig/rig-verify-queue.md +++ b/rig/rig-verify-queue.md @@ -237,6 +237,62 @@ where the issue itself stands rather than trusting this line. **Ring mode is not the way to rehearse it**: `fake_ring` still points every ref ring at one channel, which is #204. +- **#368's `TAU_SNR_THRESHOLD_DB` constant — QA on PR #384 (2026-08-23) + flagged it `derived`, not measured on the sweep configuration it gates.** + Its two anchors (33.8–83.5 dB electrical loopback, ~16 dB #376 acoustic + cliff) come from a different window-length rig session + (`rig-2026-08-22-tau-window-350-results.md`) and a different, longer-ESS + acoustic path — neither is `calibrate`'s own short-ESS electrical τ path. + + Run `calibrate`'s actual τ path against the three cases the issue + measured: hot loopback (+3.01 dB), low-gain loopback (-4.19 dB), muted + route (-83.8 dBFS). Record `tau_pre_impulse_snr_db` for each. + + > **Pass: both real loopbacks read at or above 24 dB, and the muted + > route reads below it.** Either real loopback's SNR coming back under + > 24 dB would wrongly refuse a working cable; the muted route's SNR + > coming back over 24 dB would wrongly accept noise as a peak. Both are + > falsifications of the current constant, not readouts to shrug past. + + **Build `issue-368`, not `main`.** `tau_pre_impulse_snr_db` is the field PR + #384 adds; a daemon built from `main` does not emit it, and `calibrate`'s τ + leg there is still gated on the captured-level `is_loopback` proxy this run + exists to replace. + +- **#369/PR #388 — is "any xrun during a τ lifecycle" the right dirty + threshold?** QA on PR #388 (2026-08-24) tagged this `assumed`: the code + refuses and refuses to store τ whenever `AudioEngine::xruns()` reads above + 0 during either of `measure_tau_twice`'s two lifecycles, but nothing in the + PR, the issue, or a prior comment shows that a single xrun during the + 0.35 s sweep-plus-tail actually perturbs the deconvolved peak enough to + matter, as against not perturbing it at all and the gate being needlessly + strict. + + Measurement: on the rig (`192.168.9.25`, jackd `-p 64 -n 2` at 96 kHz — the + configuration #369 was filed against), capture a `calibrate` τ reading + where a real, timed xrun is induced during one lifecycle's `measure_tau` + window (briefly starve the audio thread), and compare the resulting raw τ + against a clean-lifecycle reading taken immediately before/after under the + same acoustic path. + + > **Falsifying value, either direction closes it.** If the xrun-crossed + > reading's τ lands within the tolerance `compare_tau_readings` already + > treats as agreement, a single real xrun does not reliably perturb the + > peak enough to be caught by the two-lifetime rule on its own — the + > "any nonzero count is dirty" threshold is not over-conservative in the + > way that would make `calibrate` needlessly refuse good readings, which + > supports the current bound. If it diverges by a wide, consistent margin + > instead, that supports the bound from the other direction. Either result + > is informative; no run currently exists. + + **Not fixable from code alone — this entry documents the gap, it does not + close it.** The QA finding stands until this measurement runs. + + **Build `issue-369`, not `main`.** The refusal and the per-reading + `tau_reading{1,2}_xruns` counts are what PR #388 adds; on `main` an + xrun-crossed lifecycle is reported as an ordinary reading, so there is + nothing to compare against. + - **#243's own acceptance criterion 7 — a corrected metres readout against a taped move.** QA on PR #356 (2026-08-20) flagged this as unverified: nothing in the tree runs the built `distance_cal` subtraction against a physical