fix: gate τ on the peak's own pre-impulse SNR, not captured level

[mkovero]

closes #368

what changed

calibrate used to run τ only when cal_prompt step 2's is_loopback
captured-level flag was true — a ±2 dB unity-gain proxy for "is this cable
patched" that a hot loopback (+3.01 dB) or low-gain loopback (-4.19 dB) both
failed on the rig even though both carried a real, measurable arrival; a
muted route was the only genuine absence, and all three printed the same
asserted line, not measured (loopback not detected this run).

Per the architect's option-B decision on the issue: τ is now attempted
unconditionally (is_loopback no longer gates it — it still gates only
step 2's DMM pre-fill, unchanged). The gate moved inside measure_tau
itself, on the quantity that actually distinguishes "patched" from "not
patched": after the deconvolved peak is located, its pre-impulse SNR is
checked against a 24 dB threshold before the existing edge-margin check
runs. A lifecycle below threshold produces a new tau_state,
not_measured_low_snr, kept distinct from the generic error state a real
engine/deconvolution failure produces, and short-circuits the second
lifecycle the same way error already does.

The SNR formula itself was lifted out of ac-core's ir_stats() into
sweep::pre_impulse_snr_db so both callers share one implementation of
"does this peak stand clear of its own noise floor" rather than keeping two
copies that could drift apart — ir_stats()'s own behavior is unchanged,
this is a pure dedup there.

files touched

• ac-rs/crates/ac-core/src/measurement/sweep.rs — new pub fn pre_impulse_snr_db(ir, peak_index) -> f64, extracted from
  report.rs::ir_stats()'s inline calculation.
• ac-rs/crates/ac-core/src/measurement/report.rs — ir_stats() calls the
  extracted function instead of its own copy; behavior unchanged.
• ac-rs/crates/ac-daemon/src/handlers/calibrate.rs — TAU_SNR_THRESHOLD_DB
  constant (env-overridable under tau-window-override, same mechanism as
  TAU_EDGE_MARGIN_FRAC); new check_peak_snr (modeled on
  check_peak_within_window); measure_tau now returns (tau_s, snr_db)
  and gates on SNR before the edge-margin check; TauAttempt gains a
  LowSnr variant and a pre_impulse_snr_db field on Compared;
  tau_result drops its is_loopback parameter and always calls
  attempt; tau_probe_log now takes the real gate SNR as a parameter
  instead of recomputing its own separate copy.
• ac-rs/crates/ac-daemon/src/audio/fake.rs — play_and_capture gains two
  opt-in, fake-only env-var test hooks (AC_FAKE_TAU_GAIN_OVERRIDE,
  AC_FAKE_TAU_NOISE_AMPLITUDE_OVERRIDE) so a muted/low-SNR loopback is
  drivable headless; both default to byte-identical pre-calibrate's ±2 dB unity gate refuses correct loopbacks, and calls it "loopback not detected" #368 behavior when
  unset.
• ac-rs/crates/ac-daemon/tests/it_protocol.rs — new end-to-end test
  driving the low-SNR refusal through the fake hooks above; stale doc
  comments on two existing tests updated (they described the old
  is_loopback-keyed branch).
• ac-rs/crates/ac-cli/src/commands/calibrate.rs — print_tau_leg renders
  not_measured_low_snr with the observed SNR and threshold (UX-specified
  wording); the unrecognised/older-daemon fallback now prints the raw
  tau_state value instead of asserting "loopback not detected."
• ac-rs/ZMQ.md — cal_done schema: tau_state enum renamed
  not_measured_no_loopback → not_measured_low_snr; two new fields
  documented (tau_pre_impulse_snr_db, tau_snr_threshold_db); τ section
  prose rewritten to describe the SNR gate instead of the loopback
  piggyback it replaces.

test output

cargo test --workspace: all suites green, 0 failed (1135+ tests across
crates, same as before this change plus the new coverage below)
cargo clippy --workspace -- -D warnings: clean
cargo clippy -p ac-daemon --features tau-window-override -- -D warnings: clean
cargo fmt --check: clean

New/changed coverage: check_peak_snr_* boundary tests (mirrors
check_peak_within_window's), tau_result_low_snr_reports_new_state_and_fields,
tau_result_error_state_has_no_snr_fields-equivalent assertions folded into
the existing error test, and
calibrate_reports_not_measured_low_snr_on_muted_fake_loopback in
it_protocol.rs (paired with the existing
calibrate_measures_tau_against_fake_loopback_delay, so one test proves
"measured because SNR is genuinely adequate" and the other proves the gate
isn't just deleted).

ZMQ schema changed

Yes — ac-cli is the only current consumer (ac-view does not subscribe to
cal_done), so this does not touch the transfer-stream schema ac-scene/
ac-view consume. Updated in ac-cli's print_tau_leg and in ZMQ.md in
this same PR, per the architect's design comment.

new dependencies

none

related

none

open questions for reviewer

None — the architect's design comment resolved the wire field names, the
state rename, and confirmed captured_dbfs stays off cal_done.

[mkovero]

spec coverage

criterion	provenance	covered	notes
AC1: τ measured on 3.01 dB hot loopback	measured (rig 2026-08-23)	✓	level gate removed entirely from τ path; SNR gate is level-independent, so structurally satisfied. No fake-audio test exercises a non-unity gain, though — see test coverage gaps.
AC2: τ measured on 4.19 dB low loopback	measured (rig 2026-08-23)	✓	same as AC1.
AC3: τ refused on muted route	measured (rig 2026-08-23, -83.8 dBFS)	✓	calibrate_reports_not_measured_low_snr_on_muted_fake_loopback (it_protocol.rs) drives it end-to-end via new fake hooks; check_peak_snr_refuses_the_rigs_measured_muted_route pins the rig's own -3.45 dB anchor.
AC4: replacement condition carries margin with own provenance, not assumed	derived	✓	TAU_SNR_THRESHOLD_DB doc comment cites both rig anchors (33.8–83.5 dB electrical, ~16 dB #376 acoustic cliff) and states the gap-split reasoning explicitly, tagged derived. Gap closed in-PR by cited derivation per the spec-coverage rule.
AC5: refusal states observation, not inferred cause	n/a (wording requirement)	✓	CLI renders "peak SNR X dB, need Y dB, threshold derived" and "state: {state}" fallback — matches UX comment's proposed text exactly, asserts nothing about wiring.
AC6: cal_done carries enough for one-round-trip render	n/a (wire decision, architect-resolved)	✓	tau_pre_impulse_snr_db / tau_snr_threshold_db added, present per the documented state set; captured_dbfs correctly not added, per architect's resolution.
AC7: step 2 DMM pre-fill keeps its own unity gate	n/a	✓	is_loopback / loopback_dbfs unchanged at calibrate.rs:702-703, still only feeds the step-2 prompt text and DMM pre-fill; tau_result no longer takes it.
AC8: a test distinguishes "measured on off-unity" from "measured because gate deleted"	n/a (explicit test requirement)	✗	Only the refusal half is new (AC_FAKE_TAU_GAIN_OVERRIDE=0.0). The "passing" half re-uses calibrate_measures_tau_against_fake_loopback_delay, which never sets AC_FAKE_TAU_GAIN_OVERRIDE — it runs at the fake backend's default gain, which is exactly 1.0 (unity), the one case the old gate already handled correctly. No test in this PR ever drives a non-unity gain through calibrate and asserts measured — see test coverage gaps below for a concrete addition closing this.

standards conformance

standards check: not applicable — this PR changes interface round-trip latency (τ) gating logic and its CLI text rendering. No AES-17 THD+N methodology, IEC 60268-3 frequency-response/S-N display, IEC 61260-1 band filtering, IEC 61672-1 weighting, ITU-R BS.468-4/BS.1770-5 noise/loudness, or ISO 18233/3382 acoustic-substitution clause governs an interface-calibration delay gate or its refusal wording; no dBu/weighting/loudness/octave-band value or label is touched.

correctness issues

none found. pre_impulse_snr_db extraction is a verified pure dedup — report.rs's prior inline guard/pre-region/RMS/dB formula is byte-for-byte reproduced in sweep.rs::pre_impulse_snr_db, parametrized on ir.len() in place of the caller-local window_len, which is the same value at both call sites (report.rs:613: window_len = linear_ir.len(); calibrate.rs: irs.linear is exactly window_len_used[0]-long as returned by extract_irs). check_peak_snr boundary (< threshold refuses, >= accepts) matches check_peak_within_window's shape and is asserted at both ends. LowSnrRefusal is downcast via typed error rather than string match, so a wording change can't silently break the not_measured_low_snr vs error state split. Fake-only test hooks (AC_FAKE_TAU_GAIN_OVERRIDE / AC_FAKE_TAU_NOISE_AMPLITUDE_OVERRIDE) are additive and verified byte-identical to prior behavior at their defaults (noise loop only runs when noise_amp > 0.0; out[j] += s * 1.0 with out still zero-initialized equals the old out[j] = s).

test coverage gaps

• AC8 is not actually closed. The PR's stated pairing — "measured because SNR is genuinely adequate" vs "measured because the gate was deleted" — needs the passing side to be an off-unity level, since unity is exactly the case the old is_loopback gate never refused. As written, a regression that reintroduced a captured-level check keyed near unity (e.g. someone restores is_loopback-style gating with a wider but still level-anchored window) would pass every test in this PR, because the only "measured" fake-audio test never leaves unity gain.

suggested test additions

/// #368 AC8: closes the gap the muted-route test alone leaves — the
/// "passing off-unity level" half. 3.01 dB hot is the exact rig case from
/// the issue (drive -30 dBFS, captured -30.0 dBFS); the old ±2 dB gate
/// refused it, and a regression that reintroduced any captured-level check
/// near unity must fail this, not just the muted-route test above.
#[test]
fn calibrate_measures_tau_on_hot_off_unity_fake_loopback() {
    let d = Daemon::spawn_with_env(&[
        ("AC_FAKE_TAU_GAIN_OVERRIDE", "1.4142135623730951"), // +3.01 dB
    ]);
    let c = Client::new(&d);

    let r = c.call(json!({"cmd": "calibrate", "ref_dbfs": -30.0,
                           "output_channel": 0, "input_channel": 0}));
    assert_eq!(r["ok"], json!(true));

    for step in 1..=2 {
        c.wait_for_topic("cal_prompt", Duration::from_secs(5))
            .unwrap_or_else(|| panic!("step {step} prompt"));
        let _ = c.call(json!({"cmd": "cal_reply", "vrms": null}));
    }
    let done = c
        .wait_for_topic("cal_done", Duration::from_secs(5))
        .expect("cal_done frame");

    assert_eq!(
        done["tau_state"], json!("measured"),
        "3.01 dB hot must not be refused (#368 AC1): {done}"
    );
    assert!(done["tau_s"].as_f64().is_some(), "frame: {done}");
}

A second case at gain 0.6170338627 (-4.19 dB, AC2's low-gain rig anchor) would close the pair fully but is not strictly required if the reviewer judges the hot case sufficient to catch a level-keyed regression.

scope issues

none. Files touched match triage's "files likely affected" plus the sweep.rs/report.rs dedup the architect explicitly called for; no unrelated changes.

verdict

request-changes
AC8, an explicit acceptance criterion requiring a test that distinguishes "measured on an off-unity loopback" from "measured because the gate was deleted," is not actually satisfied — the only passing fake-audio test runs at unity gain, the one case the old gate already got right; add the off-unity test above (or equivalent) and this is ready.

rig verification required

TAU_SNR_THRESHOLD_DB = 24.0 dB is tagged derived, not measured on this exact (short-ESS, electrical-loopback) sweep — its two anchors come from a different window-length rig session (rig-2026-08-22-tau-window-350-results.md) and a different (long-ESS, acoustic) path (#376). Needed: a rig session running calibrate's actual τ path (this sweep configuration) against the three real cases the issue measured — hot loopback (+3.01 dB), low-gain loopback (-4.19 dB), and the muted route (-83.8 dBFS) — recording tau_pre_impulse_snr_db for each. Falsifies the threshold if either real loopback's SNR comes back below 24 dB (would wrongly refuse a working cable) or the muted route's comes back above it (would wrongly accept noise as a peak). No existing block in work/rig/rig-verify-queue.md covers this; needs a new one.

[mkovero]

Addressed the request-changes verdict.

AC8 (blocking) — fixed

Added calibrate_measures_tau_on_hot_off_unity_fake_loopback in it_protocol.rs, exactly the test QA proposed: drives the issue's own +3.01 dB hot loopback through AC_FAKE_TAU_GAIN_OVERRIDE and asserts measured. This pairs with the existing calibrate_reports_not_measured_low_snr_on_muted_fake_loopback so one test now proves "measured because SNR is genuinely adequate" at an off-unity level and the other proves the gate isn't just deleted — the existing calibrate_measures_tau_against_fake_loopback_delay alone only ran at the fake backend's default unity gain, which the old level gate already handled correctly. Did not add the second (-4.19 dB) case QA called optional — one off-unity case is enough to catch a level-keyed regression, and a second identical-shaped test adds no new discriminating power over the first.

Rig verification required — queued, not run here

Added a block to work/rig/rig-verify-queue.md (new bullet under "Still to run") recording exactly what QA asked for: run calibrate's own τ path against the three real cases (hot/low-gain loopback, muted route) and check tau_pre_impulse_snr_db against the 24 dB threshold, falsifying it if either loopback comes in under threshold or the muted route comes in over. This needs the physical rig (192.168.9.25) and drive-level consent, neither of which this session has — recording the block is what's in scope here; running it isn't.

Everything else in the review

No other correctness issues, scope issues, or spec-coverage gaps were raised — nothing to disagree with. cargo test --workspace, cargo clippy --workspace -- -D warnings, and cargo fmt --check all clean on top of the new commit.

[mkovero]

Re-review. Commit range: 2eb0208e3c..8c36a06051 (my prior review was on 2eb0208).

prior points, one line each

1. AC8 not closed (only unity-gain "measured" test existed) — fixed: calibrate_measures_tau_on_hot_off_unity_fake_loopback added (it_protocol.rs), drives AC_FAKE_TAU_GAIN_OVERRIDE=1.4142135623730951 (+3.01 dB, the issue's own hot case) and asserts tau_state == "measured".
2. requires-rig — TAU_SNR_THRESHOLD_DB derived, not measured on this sweep config — addressed procedurally: block added to work/rig/rig-verify-queue.md recording exactly the three cases and the falsifying condition I named. Not run (needs physical rig + drive consent), which is correct — recording it is in scope, running it isn't. Label stays.
3. Everything else in prior review (correctness, scope, standards-n/a, AC1-AC7) — no new commits touch that code; stands as before, not re-litigated.

spec coverage (delta only)

criterion	provenance	covered	notes
AC8: test distinguishes "measured on off-unity" from "measured because gate deleted"	n/a (explicit test requirement)	✓	New test uses a non-unity gain (1.4142…, +3.01 dB), the exact case the old is_loopback ±2 dB gate refused. A regression reintroducing a unity-anchored captured-level check would fail this test without touching the muted-route test — the discriminating pair QA asked for now exists.

Verified the test is reachable and actually exercises the claim, not just present: ran it filtered (cargo test --workspace calibrate_measures_tau_on_hot_off_unity_fake_loopback) — 1 passed. Read fake.rs:162-175 (unchanged since prior pass) confirming AC_FAKE_TAU_GAIN_OVERRIDE scales the played-signal copy, so 1.4142… really produces a +3.01 dB captured level relative to unity, not a no-op.

mechanical gate — re-run at new tip, full workspace

• cargo fmt --check — clean.
• cargo clippy -- -D warnings (and --workspace) — clean. Note: cargo clippy --workspace --all-targets -- -D warnings does fail, at crates/ac-daemon/src/handlers/mod.rs:817,837 (field_reassign_with_default in a test helper) — but that file has zero diff in this PR (git diff origin/main...HEAD -- crates/ac-daemon/src/handlers/mod.rs is empty; last touch 683962a, already on main before this PR branched). Pre-existing on main, not introduced here — not this PR's gate to carry. Flagging separately, not blocking.
• cargo test --workspace — clean, 0 failed across all crates (ac-daemon integration suite: 104 passed, includes the new test).

correctness issues

none found in the delta.

test coverage gaps

none remaining — AC8 was the only open gap and it's closed. (The optional -4.19 dB second case I suggested as non-required is still absent; dev's reasoning for skipping it — no new discriminating power over the hot case — holds, not re-flagging.)

scope issues

none. Delta is exactly it_protocol.rs (new test) + work/rig/rig-verify-queue.md (rig block), both direct responses to the prior review.

verdict

approve
AC8 closed with a test that actually discriminates the claim it names (verified by running it, not just reading it), gate is clean workspace-wide on the new tip, and the unrelated pre-existing clippy issue in handlers/mod.rs is out of this PR's diff.

rig verification required

Still outstanding — unchanged from prior review, not retired by this push (code still depends on unmeasured TAU_SNR_THRESHOLD_DB = 24.0 dB). The new work/rig/rig-verify-queue.md block queues exactly the run I specified last pass: calibrate's own τ path against hot (+3.01 dB) / low-gain (-4.19 dB) / muted (-83.8 dBFS) loopback, recording tau_pre_impulse_snr_db per case, falsified if either real loopback reads below 24 dB or the muted route reads at/above it. Label stays; only a human clears it once that run exists.

[mkovero]

main was merged into issue-368 and pushed (dae1f47..775ac00). This is a housekeeping merge, not a change to the fix under review — but it moves the branch 23 commits forward, so the diff you last read is not the diff that is here now. claude-approved has been removed and the PR is back to in-review.

What came in from main (df9f9f8), all of it repo hygiene:

• Agent-reachable doc surface cut 21.4% (541,259 → 425,461 bytes of greppable markdown). Read(./docs/superseded/**) joins the existing work/ and audit/ deny rules; ac-rs/PLAN.md, ac-rs/PROFILING.md and work/qa/ are deleted.
• Handoffs moved out of tree to $AC_HOME/handoff (default ~/src/ac-wt/handoff), following work/sessions. work/handoff/ is now gitignored. Docs citing them were repointed.
• Codex QA spec consolidated onto .agents/codex-qa.md. .codex/qa-instructions.md and .agents/bin/ are gone; bin/codex-qa.sh is repointed. One rule unique to the deleted file — GitHub holds all workflow state, never write a local PASS/FAIL marker — moved into hard constraints rather than being dropped.
• Dead tooling removed: acteam, bin/ac-task, four .agents/bin stubs.
• Dangling references fixed: attic/ac-ui (11 sites) and handoff.md (14 sites) named paths that do not exist and never did. Pointers dropped, substance kept.
• Clippy fix: useless_format in crates/ac-cli/tests/it_ensure_server.rs.

The only merge conflict was .claude/settings.json, where main's deny list is a strict superset of the branch's — resolved to main's side after verifying the branch carried no deny entries of its own.

Verified on the merged tree: cargo check --workspace --all-targets clean, run with an isolated CARGO_TARGET_DIR so the shared target dir could not report a false-fresh pass. Full cargo test --workspace, clippy -D warnings and fmt --check were green on main at df9f9f8; I did not re-run the full suite on this merged branch, only cargo check.

requires-rig is untouched — that stays a human gate.

[mkovero]

Re-review. Commit range reviewed: 8c36a06051bd21b008514459220e680e33cc347c..cb95c5aaa7b46db709f34d717ddac15e9c913260 (prior review was posted at 8c36a060). This range is a chain of merges bringing in ~80 commits of unrelated main-branch history (module-tree refactors of nearly every file this PR touches) plus a handful of commits authored on this branch (.agents/bin/rig doc refresh, spec-tier docs). I read the branch-authored commits directly and, for the merge-driven refactors, verified the post-merge content of every file this PR's own logic lives in against what my prior review accepted — not the refactor diffs themselves, which belong to their own already-merged PRs.

prior points, one line each

1. AC8 (off-unity "measured" test) — still fixed: calibrate_measures_tau_on_hot_off_unity_fake_loopback survived the it_protocol.rs → tests/it_protocol/calibrate/tau.rs split byte-for-byte (read directly), and ran green in this pass's full-workspace cargo test.
2. requires-rig evidence (the work/rig/rig-verify-queue.md block naming the three-case rig run) — regressed. Commit dae1f47a in this range ("chore: refresh .agents, bin, .claude and rig from main") deleted work/rig/rig-verify-queue.md outright and replaced it with rig/rig-verify-queue.md copied from main, which never had the calibrate's ±2 dB unity gate refuses correct loopbacks, and calls it "loopback not detected" #368 block. git show 8c36a06:work/rig/rig-verify-queue.md has the block; rig/rig-verify-queue.md at the current tip has zero matches for "368", "TAU_SNR", "hot loopback", "muted route", or "24 dB". No later merge commit restored it — a rename-with-edits conflicts with nothing, so git had no reason to flag it (this is the exact shape of the "refresh from main eats branch docs" failure mode). See correctness issue 1 below.
3. Everything else from the first-pass review (AC1–AC7, correctness, scope, standards-n/a) — no branch-authored commit in this range touches that logic; not re-litigated. The module splits (calibrate → handlers/calibrate/tau/{mod,measure}.rs, sweep.rs → sweep/harmonics.rs, report.rs → report/ir_stats.rs, fake.rs → audio/fake/{mod,hooks}.rs) are dedup-preserving moves, verified below.

spec coverage (delta only)

criterion	provenance	covered	notes
AC8	n/a (explicit test requirement)	✓	Unchanged from last pass, confirmed still reachable post-split (see above).
rig-run record backing requires-rig	n/a (QA process requirement, not an issue AC)	✗	Present at 8c36a06, absent at tip. Not an issue acceptance criterion, so it doesn't block AC coverage, but it does undercut the evidence my prior "addressed procedurally" verdict relied on — see correctness issue 1.

standards conformance

standards check: not applicable — no branch-authored commit in this range changes a measurement value, threshold, or unit; TAU_SNR_THRESHOLD_DB (24.0 dB), the SNR formula, and the CLI's rendered wording are all untouched, only relocated. The merge does carry measurement/output changes from other already-merged PRs (transfer_stream frame, loudness gating, report renderers) — those are out of this PR's authorial scope and already gated by their own review; this pass's full cargo test --workspace (below) confirms they don't interact badly with #368's code.

correctness issues

1. rig/rig-verify-queue.md (formerly work/rig/rig-verify-queue.md) — the calibrate's ±2 dB unity gate refuses correct loopbacks, and calls it "loopback not detected" #368 rig-verification block (three-case run: hot +3.01 dB / low-gain -4.19 dB / muted -83.8 dBFS, recording tau_pre_impulse_snr_db, pass/fail condition as stated in the block QA asked for and the dev added in 8c36a06) is gone from the tip. It was deleted by dae1f47a (chore: refresh .agents, bin, .claude and rig from main), a branch-authored commit inside this delta, which replaced the whole file with main's version rather than merging the two. Since I never remove requires-rig and it stays applied, the human who eventually clears it needs this record to know what to run and what falsifies the constant — right now it isn't in the tree. Restore the block (content given in my prior review's "rig verification required" section, repeated below) into whatever rig/rig-verify-queue.md looks like now.

test coverage gaps

none remaining in code. (The rig-doc regression above is a documentation/process gap, not a test gap — filed as a correctness issue since it undoes committed work between reviews.)

scope issues

The bulk of this delta (module splits, transfer_stream/loudness/report refactors) arrived via merges of already-separately-reviewed PRs into main and then into this branch — not authored scope creep by this PR. Flagging only the one branch-authored commit that touched something in this PR's own footprint outside its stated intent: dae1f47a says it only refreshes .agents/bin/.claude/rig-layout, but its rig-layout move dropped file content rather than just relocating it.

mechanical gate — re-run at new tip, full workspace

• cargo fmt --check — clean.
• cargo clippy --workspace -- -D warnings — clean.
• cargo clippy --workspace --all-targets -- -D warnings — clean. (The handlers/mod.rs pre-existing warning I noted last pass as out-of-scope is gone — fixed upstream by 3c287505, pulled in via this merge.)
• cargo clippy -p ac-daemon --features tau-window-override -- -D warnings — clean.
• cargo test --workspace — every suite green: 0 failed across all crates (ac-daemon 559 passed/1 ignored including the it_protocol::calibrate::tau module; ac-core 126 passed; ac-cli, ac-scene, ac-view all green; doc-tests trivial/clean).

verdict

request-changes
The code itself is unchanged in substance and the full workspace gate is clean, but the rig-verification record backing this PR's requires-rig label was silently deleted by a branch-authored commit in this delta (dae1f47a) and never restored by the subsequent merges — restore rig/rig-verify-queue.md's #368 block before this goes back to in-review.

rig verification required

Unchanged in substance from prior passes, restated here since the doc record is currently missing from the tree: run calibrate's own τ path against hot (+3.01 dB) / low-gain (-4.19 dB) / muted (-83.8 dBFS) loopback, recording tau_pre_impulse_snr_db per case. Falsified if either real loopback reads below 24 dB (wrongly refuses a working cable) or the muted route reads at/above 24 dB (wrongly accepts noise as a peak). Label stays; only a human clears it once that run exists and is recorded somewhere a human can find it — which right now is nowhere in the tree.

[mkovero]

Design check: no architect/ux comment on #368 newer than this branch's tip — last design comments are 2026-08-23 (ux revision + architect option-B decision), branch built on that design throughout. No revision needed there.

Addressing the newest QA pass (2026-09-14T19:56:22Z, commit range 8c36a06..cb95c5a):

Correctness issue 1 — rig/rig-verify-queue.md's #368 block missing, deleted by dae1f47a. Agreed, restored verbatim (same content QA accepted at 8c36a06, re-inserted at the file's current path). 9351bf3e.

Everything else in that pass (AC8, mechanical gate, scope) was already ✓/clean and unchanged by this commit — no other action needed.

[mkovero]

rig-2026-09-14-pr384-tau-snr — rig record

Date (UTC): 2026-09-14 · Rig: pupu · Operator: Markus Kovero · Run by: Claude Code session
Verifies PR #384 (closes #368) queue block: calibrate's own τ path against a hot (+3.01 dB), a low-gain
(−4.19 dB) and a muted route; record tau_pre_impulse_snr_db. Pass: both real loopbacks ≥ 24 dB
(TAU_SNR_THRESHOLD_DB) and the muted route below it.

Build under test

rev cb95c5a (branch issue-368, dirty 0), rustflags -C target-cpu=x86-64
-C link-arg=-fuse-ld=mold, staged /home/mui/ac-test/cb95c5aaa7b4-x86_64, sha256 verified on rig (ac, ac-daemon,
ir_probe, transfer_probe, it_loopback_ir: OK). Not installed. Built on dev host.

Pre-flight / wiring / clock

Same session as rig-2026-09-14-pr437-plot-budget: preflight all PASS at 19:44:10Z (JACK 96000/256/-S, analog
capture block 1-8, ALSA baseline, xruns 0). Wiring probed by emission 19:49:24Z: playback_2 → IN2 tone −57.5 dBFS
at −60 drive (+2.5 dB), IN1 mic no tone, IN3 floor. FF400 internal clock, unchanged.

Emission consent

Operator in session ~19:39Z: "you may proceed with emissions too after 10min". Scope here: calibrate's 1 kHz
voltage-step tone (~1 s) and 0.2 s τ ESS ×2 lifecycles, on system:playback_2 (loopback cable) only, ≤ −40 dBFS.
Server-side clamp: drive_max_dbfs −40.0 in the running daemon's config (isolated HOME
/home/mui/ac-test/runs/384/home; output_port system:playback_2 pinned). Speaker output not driven.

Method — how the three cases were realised on this rig (differs from the issue's)

The issue's cases are relative gains of the loopback cable. Here the cable is fixed at +2.5 dB, and the
FF400 mixer was left untouched. The relative levels were set by drive instead (ref_dbfs, which sets both the voltage tone
and the τ sweep amplitude, measure_tau_twice(..., ref_amp)):

• base −43.01 dBFS; hot = −40.00 (+3.01 dB over base); low = −47.20 (−4.19 dB under base).
• muted: output unchanged (playback_2 at −40), input moved to a port that does not carry the loopback:
  IN3 unconnected (captured −104 dBFS) and IN1 measurement mic, room noise only (captured −73/−75 dBFS).
  These bracket the issue's −83.8 dBFS muted route from below and above.
  Voltage prompts skipped (cal_reply vrms null) — τ is not prompt-driven. pyzmq via SSH tunnel to
  ac-daemon --local :15556. Daemon identity (status pid, /proc exe, config) checked each restart.

Runs

case	ref_dbfs	input	captured_dbfs (step 2)	tau_state	tau_pre_impulse_snr_db	τ readings
base-a	−43.01	capture_2	−43.57	measured (2/2)	26.773	17.989583 / 17.989583 ms
hot-a	−40.00	capture_2	−40.56	measured (2/2)	26.774	17.989583 / 17.989583 ms
low-a	−47.20	capture_2	−47.76	measured (2/2)	26.738	17.989583 / 17.989583 ms
base-b	−43.01	capture_2	−43.57	measured (2/2)	26.774	17.989583 / 17.989583 ms
hot-b	−40.00	capture_2	−40.56	measured (2/2)	26.774	17.989583 / 17.989583 ms
low-b	−47.20	capture_2	−47.76	measured (2/2)	26.750	17.989583 / 17.989583 ms
muted-in3-a	−40.00	capture_3 (unconnected)	−104.09	not_measured_low_snr	13.733	—
muted-in3-b	−40.00	capture_3 (unconnected)	−104.04	not_measured_low_snr	10.373	—
muted-in1-a	−40.00	capture_1 (mic, room)	−72.88	not_measured_low_snr	13.317	—
muted-in1-b	−40.00	capture_1 (mic, room)	−75.46	not_measured_low_snr	13.193	—
All tau_snr_threshold_db = 24.0, sample_rate 96000, period 256.

Result — PASS as the queue block defines it, with a margin finding

Pass. Every real-loopback case read ≥ 24 dB and was stored as measured with 2/2 agreement. Every
muted case read < 24 dB and was refused. The old captured-level is_loopback gate's failure mode is not
reproduced: the hot and low cases, 7.2 dB apart, both measured.

Finding — margin is asymmetric, and the real-loopback SNR is level-invariant. Real loopback read
26.74–26.77 dB across a 7.2 dB drive range: a 0.04 dB spread. Pre-impulse SNR that does not move with drive
is not limited by input noise. Something in the method sets it (short-ESS deconvolution artefacts ahead of the
peak, window/leakage), and on this chain that floor sits 2.8 dB above the 24 dB threshold. Noise-only
routes read 10.4–13.7 dB, 10.3 dB below it. The constant's provenance note anchors real loopback at 33.8–83.5 dB
(Babyface session, #350). That anchor does not hold on this FF400 chain at 96 kHz / period 256. Direction
of the risk: false refuse on a working cable, if another interface or rate puts the artefact floor ~3 dB lower.
A spurious accept is not the risk here: noise never came within 10 dB. The midpoint of the measured gap is ~20.2 dB.
Whether to move the constant is a design call. This record measures and does not decide.

Confound

• Relative gains realised by drive level, not cable gain. Because SNR proved drive-invariant, this should not
  change the real-loopback result, but the issue's literal cable-gain cases were not reproduced.
• "Muted" realised as a wrong input port, not an attenuated loopback. A route attenuated to −83.8 dBFS that still
  carries the correlated sweep was not tested. It could deconvolve to the same ~26.8 dB artefact-limited SNR
  if the artefact floor scales with the signal. Given the level invariance above, that is plausible, and it
  would be accepted. This is the untested case that matters most for the gate's meaning.
• One chain, one rate/period (96 kHz/256). Build cb95c5a. PR fix: gate τ on the peak's own pre-impulse SNR, not captured level #384 has since been revised: see the tip note on the PR.

Rig state left behind

Daemon stopped; rig ~/.config/ac/config.json untouched (isolated HOME); ALSA mixer untouched; see end-of-session
preflight in the #437 record / PR comment.

What should happen next

1. Decide TAU_SNR_THRESHOLD_DB against measured 26.74–26.77 (real) vs 10.4–13.7 (noise) on FF400: keep 24
   with the 2.8 dB false-refuse margin recorded, or move toward the ~20 dB midpoint.
2. Test an attenuated-but-correlated loopback (e.g. drive −70/−80 dBFS into capture_2, or a mixer
   attenuation). That is the actual "muted route that still carries signal" case, and it would show whether the
   artefact-limited SNR lets it through.
3. requires-rig stays until the human reads this. Human clears.

[mkovero]

Re-review. Commit range reviewed: cb95c5aaa7b46db709f34d717ddac15e9c913260..9351bf3e64b2d855057e26fe10a3e83e2845a03e (prior review posted at cb95c5a). Delta is one commit, one file: rig/rig-verify-queue.md, +17/-0. git diff cb95c5a..9351bf3 -- . inside ac-rs/ is empty — zero code touched in this range.

prior points, one line each

1. AC8 (off-unity "measured" test) — not touched by this delta; stands from the pass that fixed it (8c36a06), reconfirmed green in this pass's full-workspace run.
2. requires-rig evidence record (rig/rig-verify-queue.md's calibrate's ±2 dB unity gate refuses correct loopbacks, and calls it "loopback not detected" #368 block) — fixed: commit 9351bf3 restores it. Diffed against git show 8c36a06051bd21b008514459220e680e33cc347c:work/rig/rig-verify-queue.md — the re-inserted text (three-case run, tau_pre_impulse_snr_db per case, pass/fail condition) is byte-identical to what my first-pass review accepted, now living at the file's current path (rig/rig-verify-queue.md, post dae1f47a's move).
3. AC1–AC7, correctness, scope, standards-n/a from the first two passes — no commit in this range touches that code; not re-litigated.

spec coverage (delta only)

criterion	provenance	covered	notes
rig-run record backing requires-rig	n/a (QA process requirement, not an issue AC)	✓	Restored, verified byte-identical to the version my prior review accepted.

No issue acceptance criterion is touched by this delta — it is a docs-only restoration commit.

standards conformance

standards check: not applicable — delta is a documentation-only restoration (rig/rig-verify-queue.md), no measurement value, output formatting, or display unit is touched or reachable from it.

correctness issues

none found. The restored block matches the accepted original exactly (diffed above); no drift introduced by the restoration itself.

test coverage gaps

none — no code changed in this delta.

scope issues

none. Single file, exactly the one flagged as regressed last pass.

mechanical gate — re-run at new tip, full workspace

• cargo fmt --check — clean.
• cargo clippy --workspace --all-targets -- -D warnings — clean.
• cargo clippy -p ac-daemon --features tau-window-override -- -D warnings — clean.
• cargo test --workspace — exit 0, all suites green (ac-daemon, ac-core, ac-cli, ac-scene, ac-view, doc-tests); no failures. Ran with a dedicated CARGO_TARGET_DIR (~/src/ac-wt/target-rig-9351bf3e) to avoid a shared-target false-fresh result.

Checked for cross-crate breakage even though the delta is doc-only: confirmed via git diff --stat that no ac-daemon/ac-cli/ac-view file is in this range, so the wire-schema lead (published frame vs. consumers) does not apply here — nothing to check downstream of a doc file.

verdict

approve
The one outstanding correctness gap from the last pass — the deleted rig-verification record — is restored verbatim, the full workspace gate is clean at the new tip, and nothing else in this delta touches reviewable code.

rig verification required

Unchanged in substance, now with its record back in the tree: run calibrate's own τ path against hot (+3.01 dB) / low-gain (-4.19 dB) / muted (-83.8 dBFS) loopback, recording tau_pre_impulse_snr_db per case. Falsified if either real loopback reads below 24 dB or the muted route reads at/above it. Label stays; only a human clears it once that run exists.

[mkovero]

Re-review. Commit range reviewed: 9351bf3e64b2d855057e26fe10a3e83e2845a03e..c092b52c6596bc8b2dc7ade4844b62c656d2fc56 (prior review posted at 9351bf3e, verdict approve).

shape of this delta

One commit: c092b52c = "Merge origin/main into issue-368", parents 9351bf3e (this branch) and 0891cf92 (main tip). git log --first-parent 9351bf3e..c092b52c shows only the merge itself — no commit was authored directly on issue-368 in this range. Everything else (22 commits) is main content the branch is catching up to: PR #440 (THD/THD+N reference-to-total-output rewrite), PR #439 (corrupt-calibration-error propagation), PR #438/#424 (audio-backend fail-closed + provenance), and two rig-queue-restore doc PRs. All of that carries its own already-closed review trail on main (e.g. 0df41bf8 fix: close QA request-changes on PR #440) — not re-audited here as first-pass scope, per the task's own instruction not to re-litigate accepted content. What I did check: whether pulling it in broke anything in this PR's footprint.

prior points, one line each

1. AC8 (off-unity "measured" test, fixed at 8c36a06) — untouched by this delta, still green in this pass's full run.

2. rig/rig-verify-queue.md's calibrate's ±2 dB unity gate refuses correct loopbacks, and calls it "loopback not detected" #368 block, restored verbatim at 9351bf3e — superseded, not regressed: commits 1fb21bb0/3728ccd2 in this delta move the live queue out of tree to $AC_HOME entirely (per this repo's own CLAUDE.md: "the live rig queue … one copy each, never per-branch"), so the in-tree file this point tracked no longer exists by design. Checked the out-of-tree copy directly (~/src/ac-wt/rig-verify-queue.md) — the calibrate's ±2 dB unity gate refuses correct loopbacks, and calls it "loopback not detected" #368 block is present, and is no longer just the restored text: see next point.

3. AC1–AC7, correctness, scope, standards from earlier passes — no commit in this range touches that code (confirmed: sweep.rs, ac-cli/src/commands/calibrate.rs, and the tau integration test file it_protocol/calibrate/tau.rs all show zero diff across 9351bf3e..c092b52c); not re-litigated.

4. requires-rig — the measurement now exists. A real rig run (rig-2026-09-14-pr384-tau-snr, pupu, operator-consented) executed exactly the hot/low/muted matrix this PR's rig verification required field asked for, against build cb95c5aa (which the record notes differs from 9351bf3e only in the doc-restoration file — i.e. this same τ code path). Result: PASS with a margin finding. Real loopback read 26.74–26.77 dB across a 7.2 dB drive range (hot/base/low), all stored measured (2/2); muted routes (wrong input port, both unconnected and room-noise-on-mic) read 10.4–13.7 dB, all not_measured_low_snr. Every case landed on the correct side of the 24 dB TAU_SNR_THRESHOLD_DB gate — the old is_loopback failure mode (hot/low cable wrongly refused) is not reproduced. Record: PR fix: gate τ on the peak's own pre-impulse SNR, not captured level #384 comment, rig-2026-09-14-pr384-tau-snr.

   The record itself flags two things a human needs before clearing the label, not me: (a) the 2.8 dB margin between measured real-loopback SNR and the 24 dB threshold is set by an artefact floor, not noise, and is level-invariant on this FF400/96 kHz/period-256 chain — the constant's original provenance anchor (33.8–83.5 dB, Babyface session) doesn't hold here; (b) the "muted but still correlated" case (attenuated loopback that still carries the sweep, e.g. −70/−80 dBFS into the real capture port) was not tested — the record calls this "the untested case that matters most for the gate's meaning," since a level-invariant artefact floor could plausibly let it through. Neither is a code defect in this PR; both are exactly the kind of thing requires-rig exists to surface to the human clearing it.

cross-cutting integration check (why the delta touches this PR's own files at all)

Two files in this PR's footprint changed: handlers/calibrate/mod.rs and handlers/calibrate/spl.rs. Both changes are the same shape — threading a backend: Option<&str> requirement through to make_engine, whose signature changed upstream from fn(bool) -> Box<dyn AudioEngine> to fn(bool, Option<&str>) -> Result<Box<dyn AudioEngine>> (fail-closed backend selection, PR #438). Traced the one place this matters for #368's own logic: tau/mod.rs::measure_tau_twice now calls make_engine(fake, required)? instead of the old infallible make_engine(fake). Opened tau/mod.rs at the new tip (lines 60–135) — the ? on a make_engine failure propagates into run_once's anyhow::Result and is caught by the existing e.downcast_ref::<LowSnrRefusal>() match, which correctly falls through to None (i.e. TauAttempt::Error, not LowSnr) since a backend-open failure is not a LowSnrRefusal. The SNR-gate/error distinction this PR exists to establish is not disturbed by the new failure mode the merge introduced. calibrate() itself now opens one eng before spawning the worker (for the voltage-cal step and to report backend on the reply) — measure_tau_twice's own two fresh per-lifecycle engines are untouched, so the lifecycle-boundary property the module's own doc comment depends on (make_engine → start → measure_tau → stop, twice, independently) still holds.

Confirmed via the full-workspace gate below that this integration actually compiles and the existing tau integration tests (it_protocol::calibrate::tau, unchanged file, part of ac-daemon's 572-passed run) still pass unmodified.

One unrelated observation while diffing: 9351bf3e's tree had 1,896 tracked files under ac-rs/target-tau/ (cargo build fingerprints/artifacts — dep-*, invoked.timestamp, *.json fingerprints, CACHEDIR.TAG), added at an earlier merge (cb95c5aa) and not present at the merge-base with main. This delta's merge commit drops all 1,896 — main never had them, and a plain three-way merge would have kept a branch-only addition, so this was a deliberate cleanup folded into c092b52c, not a passive inheritance. All are build junk, not source; removal is correct and costs nothing. Flagging only because 1,896 tracked build artifacts sitting in a reviewed branch for two prior passes without either of us noticing is worth naming, not because anything needs fixing now.

spec coverage

No issue-#368 acceptance criterion is touched by this delta — it is a housekeeping merge. Not re-tabulated; see point 3 above.

standards conformance

standard	clause	check	result
IEC 60268-3:2018	§15.12.3.2	docs/architecture/standards.md's clause citation was corrected from §15.12.3 → §15.12.3.2 in this delta (inherited from PR #440); spot-checked against /home/mui/src/ac/stddocs/iec-full/IEC60268-3.pdf (extracted to text, no .txt sibling shipped for this PDF, so this review generated one to search — the PDF itself is the shipped artifact, this is not a missing-document gap). §15.12.3.2 text at "Method of measurement" reads d_tot = (U2'/U2) × 100 % with U2 the measured total output voltage and U2' the notched residual — matches standards.md's restated formula verbatim and matches thd.rs's total_amp = sqrt(f1_amp² + residual_power) denominator.	✓
AES-17-2020	§6.3.1	Same file's citation changed from "referenced to fundamental" to "referenced to total signal level"; checked against aes17_2020…pdf §6.3.1 ("The THD+N ratio shall be the difference between the residual level and the total signal level"). Matches.	✓

Both are inherited via merge from PR #440, which already carries its own request-changes → fix → close QA cycle in the commit trail (70556607, b43f1f4c, 34016254, 68346991, 0df41bf8). This spot-check confirms the citations landing in this delta are accurate against primary text; it is not a re-derivation of the full estimator, which was PR #440's own review's job and is out of this PR's authored scope.

correctness issues

none found.

test coverage gaps

none — no new code path in this delta belongs to this PR; the make_engine/backend threading is exercised by the existing (unchanged) it_protocol suite, which passed.

scope issues

Bulk of the delta (57 files outside target-tau) arrived via the main merge, not branch-authored — same pattern as the 9351bf3e pass. The two files that are this PR's own footprint (calibrate/mod.rs, calibrate/spl.rs) were touched only to adapt to an upstream signature change, not to extend #368's scope.

mechanical gate — re-run at new tip, full workspace

• cargo fmt --check — clean.
• cargo clippy --workspace --all-targets -- -D warnings — clean.
• cargo clippy -p ac-daemon --features tau-window-override -- -D warnings — clean.
• cargo test --workspace — 0 failed across every suite (ac-core 126, ac-daemon 572 passed/1 ignored, ac-cli, ac-scene, ac-view all green, doc-tests trivial). Ran with a dedicated CARGO_TARGET_DIR (~/src/ac-wt/target/pr384-c092b52c) to avoid a shared-target false-fresh result.

verdict

approve
Fresh full-workspace gate is clean at the new tip, the only PR-owned files touched by this merge (calibrate/mod.rs, calibrate/spl.rs) correctly adapt to an upstream API change without disturbing the SNR/error distinction #368 exists to establish, and the rig record this PR was waiting on has since landed and passes.

Note on labels: claude-approved was already set from the 9351bf3e approval but the c092b52c merge push after that approval voids it per the approval-voiding rule — this comment is the fresh gate pass + delta re-review that rule requires before the label can stand again, and it now stands on this tip's own evidence, not the stale one. Separately: requires-rig was never actually applied to this PR despite three prior review passes saying it should stay — applying it now along with the approval, since the correctness of TAU_SNR_THRESHOLD_DB still rests on a physical measurement no code change here can substitute for.

rig verification required

Not no — but the measurement itself is now recorded (see point 4 above), which is new since every prior pass. Open items for the human clearing this, both from the rig record itself, not from this review:

1. The 24 dB threshold's margin on the tested FF400/96 kHz/period-256 chain is 2.8 dB (artefact-floor-limited, level-invariant), well short of the constant's original 33.8–83.5 dB provenance anchor — decide whether to keep 24 dB or move toward the record's suggested ~20 dB midpoint.
2. The attenuated-but-still-correlated loopback case (e.g. −70/−80 dBFS into the real capture port, as opposed to a wrong input port) was not tested and is called out by the record as the case that most tests the gate's actual meaning — belongs in $AC_HOME/rig-verify-queue.md as a follow-up entry if not already queued there.

Neither blocks approval of this PR's code; both are exactly what requires-rig exists to hold open for a human.

[mkovero]

codex qa — PR #384 at c092b52

verdict: fail

findings

[severity: blocker] [confidence: high]

• location: ac-rs/crates/ac-daemon/tests/it_protocol/calibrate/tau.rs:127-160; ac-rs/crates/ac-daemon/src/audio/fake/mod.rs:224-253
• problem: calibrate_measures_tau_on_hot_off_unity_fake_loopback does not drive the off-unity step-2 captured level it claims to test, so AC8 remains uncovered.
• mechanism: AC_FAKE_TAU_GAIN_OVERRIDE is read only by play_and_capture, which runs later for the τ ESS. The captured-level gate that this test is meant to guard reads capture_rms from capture_block; that path synthesizes the tone set by set_tone directly and never applies tau_gain_override. At ref_dbfs = -30, step 2 therefore still sees the fake unity-loopback level near -33.01 dBFS, not the claimed -30.0 dBFS hot level.
• failure scenario: restore the old if is_loopback { tau_result(...) } behavior, or add any equivalent ±2 dB pre-gate keyed on the step-2 flag. The fake step-2 capture still sets is_loopback = true; the later ESS is scaled by 1.4142 and has high SNR; tau_state is measured; this test passes despite the exact regression it says it detects.
• evidence: opened the test, calibrate step-2 call chain (set_tone → capture_rms → capture_block), fake stimulus synthesis, and the complete hook call set. git grep tau_gain_override at the reviewed tip finds one use only, in FakeEngine::play_and_capture.
• disproof attempted: checked whether capture_block, Stimulus::Tones, or the test harness applies AC_FAKE_TAU_GAIN_OVERRIDE indirectly; none does. The hook is passed to the daemon subprocess correctly, but its sole consumer is the later ESS path.
• recommendation: make the fake model an off-unity level on both relevant paths (or add a dedicated step-2 capture-gain hook), then assert the step-2 cal_prompt reports approximately captured_dbfs = -30.0 and loopback = false before asserting the final τ state is measured.

gate

Claude QA workspace gate: inherited at current tip c092b52c6596bc8b2dc7ade4844b62c656d2fc56
Codex targeted tests: not needed; the hook has a single, source-verifiable consumer and cannot reach the field under assertion.

unaddressed open questions

• The rig record found only 2.8 dB of passing margin above the 24 dB threshold on the tested FF400 path; a human still needs to decide whether 24 dB stands or moves toward the measured ~20 dB midpoint.
• An attenuated-but-still-correlated loopback remains untested, so it is not yet known whether the level-invariant deconvolution artefact floor would accept a nearly muted but correlated route.

scope

none

[mkovero]

rig-2026-09-14-pr384-tau-correlated — follow-up rig record (QA open item 2)

Date (UTC): 2026-09-14 ~22:35 · Rig: pupu · Run by: Claude Code session (operator-authorized independent rig work)
Answers the open item both QA passes carried: an attenuated but still correlated loopback, the route the first
record said it had not tested.

Build: cb95c5a (staged, sha256-verified). The τ path is identical to this PR's tip, and the pending revise
touches only the fake engine and test. Route: system:playback_2 → loopback cable → system:capture_2, output
not moved. Level set by ref_dbfs, which drives both the step-1 tone and the τ ESS. Daemon under isolated HOME with
drive_max_dbfs -40.0, identity verified (pid 16749 → staged exe) before the first request.
Rig state: FF400 at forced baseline after a JACK restart (IN2 reads −57.5 dBFS for a −60 dBFS 1 kHz tone);
IN2 idle floor ≈ −104 dBFS.

ref_dbfs	step-2 captured_dbfs	tau_state	tau_pre_impulse_snr_db	τ reading 1 / 2
−40	−40.56	measured (2/2)	26.763	17.822917 / 17.822917 ms
−60	−60.56	measured (2/2)	26.762	17.822917 / 17.822917 ms
−70	−70.56	measured (2/2)	26.762	17.822917 / 17.822917 ms
−80	−80.54	measured (2/2)	26.763	17.822917 / 17.822917 ms
−90	−90.37	measured (2/2)	26.801	17.822917 / 17.822917 ms
−100	−98.94	measured (2/2)	26.914	17.822917 / 17.822917 ms

What this shows

• The gate cannot see level. Over 60 dB of drive, down to a capture ~5 dB above the ADC floor,
  tau_pre_impulse_snr_db moves 0.15 dB. The short ESS's processing gain keeps the pre-impulse region limited by the
  deconvolution's own artefacts (≈ −26.8 dB re peak), not by input noise, until the signal is essentially at the floor.
• So a "nearly muted" route that still carries the correlated sweep is accepted. The first record's uncorrelated
  routes (wrong input port) read 10.4–13.7 dB and were refused. TAU_SNR_THRESHOLD_DB sorts correlated vs
  uncorrelated capture, not hot cable vs attenuated cable.
• The accepted readings are right, not spurious. τ was identical to the sample at every level, so accepting a
  −99 dBFS correlated capture stores the true round trip. This bounds the direction of the gap: the gate does not
  reject a working-but-quiet cable, and it has no way to tell one from a loud one.
  Whether that matches calibrate's ±2 dB unity gate refuses correct loopbacks, and calls it "loopback not detected" #368's intent ("patched" vs "not patched") is a design reading, not a defect finding.
• The margin finding stands. Real loopback sits 2.8 dB above 24 dB at every level tested, so the false-refuse risk
  on another interface does not depend on drive level.

Side readout, not about this PR

τ read 17.989583 ms before a JACK restart and 17.822917 ms after (−16 samples at 96 kHz), stable within each
JACK lifetime. That supports the rule that an absolute τ compares only within one JACK/client lifetime. τ entries
keyed only on (rate, period) would carry a stale value across a JACK restart on this interface.

Confound

• "Attenuation" is digital: the drive level scales the sweep before the DAC. A physical attenuator or mixer fader
  would add its own noise, and was not tested.
• One chain (FF400, 96 kHz, period 256).

Rig state left behind: daemon stopped; rig config untouched; FF400 at baseline.

[mkovero]

Design check: no architect/ux comment on #368 newer than this branch's tip (last: 2026-08-23 ux revision + architect option-B decision). Design unchanged; revised against the same design implemented throughout.

Addressing codex-qa's blocker at c092b52c (2026-09-14T22:18:26Z):

Finding confirmed. calibrate_measures_tau_on_hot_off_unity_fake_loopback asserted only the final tau_state, never the off-unity level it claimed to drive. AC_FAKE_TAU_GAIN_OVERRIDE scaled only play_and_capture (the τ ESS); calibrate's step-2 captured level goes through capture_rms → FakeEngine::capture_block, which never read the override. Step 2 therefore still saw the unity-loopback level, and the test's measured assertion couldn't distinguish "SNR gate genuinely passed at hot level" from "the gate was deleted" — exactly the regression it was written to catch.

Fix, at d52b5fd4:

• FakeEngine::capture_block (audio/fake/mod.rs) now applies tau_gain_override() to its synthesized tone, same as play_and_capture — it models the loopback cable's own gain, which both captures read. Unset (1.0) is a no-op multiply, so every other fake test is unaffected (confirmed: full workspace cargo test unchanged pass counts).
• hooks.rs's doc comment on AC_FAKE_TAU_GAIN_OVERRIDE updated to describe both call sites.
• calibrate_measures_tau_on_hot_off_unity_fake_loopback now captures step 2's prompt and asserts captured_dbfs ≈ -30.0 (the issue's own +3.01 dB hot case: unity loopback at ref_dbfs -30.0 would read -33.01, so -30.0 proves the override landed) and loopback: false (3.01 dB is outside the old ±2 dB is_loopback window) — before asserting the final tau_state == measured. A reintroduced level gate, or a fake model that silently reverts to unity, now fails this test the way codex-qa's finding says it should have all along.

verify

• cargo test -p ac-daemon --test it_protocol -- calibrate::tau — 5/5 pass, including the fixed test.
• cargo test --workspace — 0 failed, same suite/pass counts as the last approved gate (ac-daemon 572 passed/1 ignored, ac-core 126, rest unchanged).
• cargo clippy --workspace --all-targets -- -D warnings — clean.
• cargo clippy -p ac-daemon --features tau-window-override -- -D warnings — clean.
• cargo fmt --check — clean.

The two open items the last agent: qa pass and the rig record flagged (threshold margin vs. the FF400 chain's 2.8 dB artefact floor; the untested attenuated-but-correlated loopback case) are unchanged by this commit — they're human/rig-verify-queue items, not code defects, and nothing here touches TAU_SNR_THRESHOLD_DB or the SNR gate itself.

🤖 Generated with Claude Code

[mkovero]

codex qa — stale review

PR #384 advanced from the reviewed c092b52c6596bc8b2dc7ade4844b62c656d2fc56 to d52b5fd425034cd88cf729c9c0bfca56679e4523 during this review. The latest Claude QA approval comment (2026-09-14T22:07:52Z) predates the new commit (2026-09-14T22:28:32Z), so the claude-approved evidence is stale. A fresh Claude QA gate and review at d52b5fd4 are required before independent Codex QA can review the new tip. No Codex QA labels were changed.

[mkovero]

Re-review. Commit range reviewed: c092b52c6596bc8b2dc7ade4844b62c656d2fc56..d52b5fd425034cd88cf729c9c0bfca56679e4523 (prior qa review posted at c092b52c, verdict approve; codex-qa posted a blocker at the same tip after that review — this pass covers both).

shape of this delta

One commit, three files: audio/fake/hooks.rs (+/-doc comment only), audio/fake/mod.rs (capture_block now multiplies its synthesized tone by tau_gain_override()), tests/it_protocol/calibrate/tau.rs (calibrate_measures_tau_on_hot_off_unity_fake_loopback now asserts step 2's captured_dbfs/loopback before the final tau_state). This is exactly codex-qa's fix, nothing else.

prior qa points (from c092b52c), one line each

1. AC8 off-unity test — was flagged incomplete by codex-qa immediately after my c092b52c approve; fixed here, see verification below.
2. rig/rig-verify-queue.md restoration / out-of-tree move — untouched by this delta, stands.
3. AC1–AC7, correctness, scope, standards from earlier passes — no file in this range overlaps those; not re-litigated.
4. requires-rig record and its two open items (2.8 dB margin on the FF400 chain; the muted-but-correlated case) — untouched by this delta. The muted-but-correlated case was since answered by a separate rig record (rig-2026-09-14-pr384-tau-correlated, posted between my c092b52c review and this commit) — that record is not part of this delta and I have not re-verified it in this pass; noting it exists so the human clearing requires-rig has both records in view.

codex-qa's blocker — independently verified fixed

Confirmed the finding was real before checking the fix: capture_rms (handlers/mod.rs:751) calls eng.capture_block(duration), and calibrate's step-2 captured-level (handlers/calibrate/mod.rs:230-232, captured_rms = capture_rms(&mut *eng, 0.3)) is the only producer of the captured_dbfs/loopback fields the fixed test now asserts. Before this commit, capture_block (audio/fake/mod.rs, pre-delta) called self.synth().block(...) with no gain applied — so AC_FAKE_TAU_GAIN_OVERRIDE, read only by play_and_capture, could never reach step 2. Confirms codex-qa's mechanism exactly.

Post-fix: capture_block now reads tau_gain_override() and multiplies every sample of the synthesized block before returning it (audio/fake/mod.rs, new lines). Traced the arithmetic in the updated test: ref_dbfs -30.0 → unity-gain RMS capture is -33.01 dBFS (peak/RMS factor for a sine, matches the doc comment's own math) → override 1.4142135623730951 (+3.01 dB) lands captured_dbfs at -30.0, which the test asserts to <0.1 dB and separately asserts loopback: false (3.01 dB off unity, outside the ±2 dB is_loopback window at calibrate/mod.rs:244) — both assertions run before the final tau_state == measured check, so a reintroduced level gate or a fake model that silently drops back to unity now fails this test on the field it claims to exercise, not just on the end state. This is the exact gap codex-qa named.

Checked for collateral effect: capture_block is also used by test_hw.rs/test_dut.rs/other calibrate steps via capture_rms; default tau_gain_override() returns 1.0 when the env var is unset, making the multiply a no-op — confirmed by the full-workspace run below showing unchanged pass counts everywhere outside it_protocol::calibrate::tau. Env vars are set per-subprocess (Command::new(...).env(...) in tests/common/mod.rs:203-207, each daemon its own process), so no cross-test contamination between the two off-unity tau tests and any other test that touches capture_block.

spec coverage

No issue-#368 acceptance criterion is newly touched by this delta — it repairs test coverage for AC8, already tabulated in prior passes. Not re-tabulated.

standards conformance

standards check: not applicable — delta touches only the fake/test audio backend (audio/fake/mod.rs, gated behind --fake-audio) and a test file; no production measurement, output-formatting, or display-unit code is touched or reachable from it.

correctness issues

none found.

test coverage gaps

none — this delta's entire purpose is closing the one gap codex-qa found, and it does; verified independently above rather than taken on the fix author's word.

scope issues

none. Three files, all inside the fake-backend/test-hook mechanism the AC8 test already depended on; no production path touched.

mechanical gate — re-run at new tip, full workspace

• cargo fmt --check — clean.
• cargo clippy --workspace --all-targets -- -D warnings — clean (exit 0).
• cargo clippy -p ac-daemon --features tau-window-override -- -D warnings — clean (exit 0).
• cargo test --workspace — first run: 1 failure, it_set_drive::level_changes_take_effect_without_restarting_the_session (a timing-sensitive 900ms-peak-window assertion, quiet -30.0034 → loud -30.0031 dBFS, no file this delta touches is anywhere near that test). Investigated rather than waved off: ran it in isolation 3/3 green, then re-ran the entire cargo test --workspace a second time end to end — 0 failures, same suite/pass counts as my c092b52c gate (ac-daemon 572 passed/1 ignored, ac-core 126, rest unchanged), it_set_drive itself 17/17 green. Conclusion: a load-induced flake in an unrelated real-time-sensitive test under full-workspace parallel contention, not caused by this delta — but recorded here rather than silently discarded, since a flake that recurs under the same conditions on a future PR is worth knowing about. Ran with a dedicated CARGO_TARGET_DIR (~/src/ac-wt/target/pr384-d52b5fd4) to avoid a shared-target false-fresh result.

verdict

approve
codex-qa's blocker is independently confirmed fixed — the test now exercises the exact field the fake model previously failed to update, and the mechanism traced (capture_rms → capture_block → tau_gain_override) matches the finding precisely. Full-workspace gate is clean on a clean re-run; the one observed failure reproduced as a pre-existing timing flake unrelated to any file in this delta. Nothing else in this delta touches reviewable production code.

Design check: no architect/ux comment on #368 newer than this branch's tip. Design unchanged.

Label note: d52b5fd4 was pushed after my c092b52c approval, which per the approval-voiding rule reverts that approval on push — claude-approved should have been removed at that point and was not (process gap on the pusher's side, not something this review can undo after the fact). This comment is the fresh full-workspace gate pass and delta re-review the rule requires before the label can stand again; it now stands on d52b5fd4's own evidence. requires-rig remains untouched — this delta does not touch TAU_SNR_THRESHOLD_DB or the SNR gate, so the two open items it holds open are unchanged and still for a human to clear.

rig verification required

Not no — unchanged from the c092b52c pass, carried forward (this delta doesn't touch the gate or the constant):

1. The 24 dB threshold's margin on the tested FF400/96 kHz/period-256 chain is 2.8 dB (artefact-floor-limited, level-invariant) — decide whether 24 dB stands or moves toward the record's suggested ~20 dB midpoint.
2. The muted-but-correlated loopback case, called out as untested in my c092b52c pass, has since been answered by rig-2026-09-14-pr384-tau-correlated (posted after my last review, before this commit) — not re-verified in this pass since it's outside this delta's scope; flagging for the human clearing the label that the record now exists.

Neither blocks approval of this delta's own code.

[mkovero]

merge of main into this branch (after #388 / #369 merged)

PR #388 (#369, per-lifecycle xrun refusal) merged into main and conflicted with this branch's low-SNR refusal (#368) in six files: ZMQ.md, ac-cli/src/commands/calibrate.rs, audio/fake/hooks.rs, audio/fake/mod.rs, handlers/calibrate/tau/mod.rs (11 hunks), tests/it_protocol/calibrate/tau.rs. A developer session resolved the merge. The host stopped it (memory pressure from parallel pipeline jobs) before it committed or posted this comment. The resolution was committed unchanged, after the full gate (cargo fmt --check, cargo clippy -- -D warnings, cargo test --workspace) passed on it.

Both features kept whole: refused_xrun + tau_reading{1,2}_xruns + AC_FAKE_XRUNS_OVERRIDE from #369. not_measured_low_snr + tau_pre_impulse_snr_db / tau_snr_threshold_db + the gain/noise fake hooks from #368. ZMQ.md carries one tau_state table covering both.

Precedence, a decision for review, not settled design:

• A lifecycle whose capture crossed an xrun skips its own SNR gate (calibrate/tau/measure.rs: if xruns == 0 { check_peak_snr(..)?; }). tau_result then routes the run to refused_xrun before the two readings are compared (calibrate/tau/mod.rs). Rationale: a contaminated capture's SNR figure is meaningless, so the contamination is what gets named.
• A clean lifecycle keeps calibrate's ±2 dB unity gate refuses correct loopbacks, and calls it "loopback not detected" #368's order: SNR gate before the edge-margin check.
• Bound on what this decides: precedence applies per lifecycle. If lifecycle 1 crossed an xrun but lifecycle 2 is clean and truly below threshold (a muted route), lifecycle 2's own gate still reports not_measured_low_snr. That report is true, since the clean capture shows no arrival. Only a capture that itself crossed an xrun is guaranteed never to be called low-SNR.

Test: calibrate_reports_refused_xrun_over_low_snr_when_both_conditions_hold (tests/it_protocol/calibrate/tau.rs) drives AC_FAKE_XRUNS_OVERRIDE="1,1" together with a muted/noise-only route and asserts refused_xrun. Its doc names the swap that turns it red: run check_peak_snr unconditionally, and lifecycle 1 refuses as not_measured_low_snr before its xrun is consulted. The interrupted developer session reported confirming that red run before restoring the fix. That confirmation was not re-run after the interruption.

Rig evidence for this PR's gate is unchanged by the merge. The τ path's SNR logic is only bypassed on xrun-crossed captures.

[mkovero]

Re-review. Commit range reviewed: d52b5fd425034cd88cf729c9c0bfca56679e4523..856725700247caba43a9b564c0831982d9d5c08e (prior qa review posted at d52b5fd4, verdict approve).

shape of this delta

One commit: 85672570 = "Merge origin/main into issue-368". git log --first-parent d52b5fd4..8567257 shows only the merge itself — nothing authored directly on issue-368 in this range. The merge brings in PR #388 (fix: refuse a τ reading that crossed an xrun during either lifecycle, closes a separate issue #369) and PR #445 (fix: real-port loopback_ir daemon config carries the rig's -40 dBFS ceiling, issue #442), both already MERGED on main with their own review trails (checked via gh pr view 388/445 --json state,mergedAt). Unlike prior merge-driven deltas in this PR's history, #388 is not a cosmetic refactor — it adds new production logic (refused_xrun) inside the exact module (handlers/calibrate/tau/{mod,measure}.rs) this PR's own SNR gate lives in, so I read it as a collateral-effect check on this PR's own AC's, not a re-audit of #388's own already-closed review.

prior points, one line each

1. AC8 (off-unity "measured" test, fixed at 8c36a06, codex-qa gap closed at d52b5fd4) — untouched by this delta, still green (calibrate_measures_tau_on_hot_off_unity_fake_loopback, it_protocol/main.rs line 989 of this pass's run).
2. rig/rig-verify-queue.md / $AC_HOME/rig-verify-queue.md record — not touched by this delta (no rig-verify-queue.md in the diffstat); stands.
3. requires-rig's two open items (2.8 dB margin on the FF400 chain; the muted-but-correlated case) — not touched by this delta, unchanged; label stays, only a human clears it.
4. AC1–AC7, correctness, scope, standards from earlier passes — the files those checks covered (calibrate/tau/measure.rs's check_peak_snr/check_peak_within_window, TAU_SNR_THRESHOLD_DB) are touched by this delta only insofar as fix: refuse a τ reading that crossed an xrun during either lifecycle #388 adds an xrun check around them, not inside them — traced below; not re-litigated otherwise.

collateral-effect check: does #369's xrun gate disturb #368's SNR gate?

Read handlers/calibrate/tau/measure.rs::measure_tau at the new tip: the xrun delta is now computed around play_and_capture (xruns_before/eng.xruns() diff), and check_peak_snr is only called if xruns == 0 — a lifecycle that crossed an xrun skips the SNR gate entirely rather than being judged against it. Read handlers/calibrate/tau/mod.rs::tau_result: the TauAttempt::Compared match arm with reading1_xruns > 0 || reading2_xruns > 0 is dispatched before the Agree/Disagree arms, so an xrun-crossed lifecycle always reports refused_xrun regardless of what the comparison would have said — this is documented as "#368/#369 merge precedence" in three places (both files' doc comments and ZMQ.md) and I traced all three against the actual match-arm order, not just the prose. This does not change check_peak_snr's own boundary (still < threshold refuses, >= accepts — check_peak_snr_refuses_below_threshold/_accepts_at_and_above_threshold in this pass's run are byte-identical to the prior tip) or TAU_SNR_THRESHOLD_DB (still 24.0, unchanged in this diff). AC1–AC8's own tests (unity-gain, off-unity-gain, muted-route) all still exercise a zero-xrun path, so none of them changed behavior; confirmed by running them (all green, see gate below).

Traced the new precedence's own test coverage rather than take the doc comment's word for it: tau_result_xrun_takes_priority_over_disagreement (unit, tau/mod.rs) constructs a genuinely disagreeing pair that also carries an xrun and asserts refused_xrun, not disagree_*. calibrate_reports_refused_xrun_over_low_snr_when_both_conditions_hold (integration, it_protocol/calibrate/tau.rs) drives both a muted/noise-only route (would fail check_peak_snr on its own) and an xrun on both lifecycles, and asserts the reported state is refused_xrun, not not_measured_low_snr — its doc comment states the exact revert that would turn it red (restoring an unconditional check_peak_snr call inside run_once), which I checked against the code path above rather than accepting as asserted. Both are reachable (not just present) — the it_protocol run below shows both green among 114 passed.

wire-schema check (ac-daemon's published frame vs. consumers)

cal_done gained tau_reading{1,2}_xruns and the refused_xrun state (ZMQ.md diff, +41/-9). ac-cli: render_tau_xrun_leg added and dispatched from render_tau_leg's match on tau_state, with three unit tests (render_tau_leg_measured_prints_no_xrun_text, render_tau_xrun_leg_names_only_the_dirty_reading, render_tau_xrun_leg_both_dirty_lists_both_lines_not_summed, render_tau_leg_dispatches_refused_xrun_through_render_tau_leg) asserting actual rendered strings, not just that the code runs. Text states the observation ("xrun during reading N — not stored"), not an inferred cause — consistent with AC5's wording rule from the first-pass review. ac-view: grepped the crate for tau_state/tau_reading/refused_xrun/cal_done — one hit, it_live_end_to_end.rs, which is a test asserting ac-scene-derived readout fields unrelated to τ; ac-view does not render cal_done's τ leg at all, so there is nothing for it to miss here. No ac-scene file touched by this delta either (confirmed via git diff --stat).

spec coverage

No issue-#368 acceptance criterion is touched by this delta — it's a housekeeping merge from two independently-reviewed PRs. Not re-tabulated.

standards conformance

standards check: not applicable to this delta. TAU_SNR_THRESHOLD_DB (24.0 dB) and pre_impulse_snr_db's formula are unchanged (confirmed via the diff — measure.rs's only change to that region is the if xruns == 0 guard around the existing check_peak_snr call, not the function itself). Checked docs/architecture/standards.md for any clause naming xruns, round-trip delay, or calibration/τ — no matches (Grep over the file, zero hits). This delta adds an xrun count and a new CLI-rendered state string, neither a dB/frequency/loudness/weighting value nor a display unit a standard governs; tier-1 label is correctly applied to the issue, but no clause in standards.md reaches this delta's content.

correctness issues

none found.

test coverage gaps

none — both the unit-level precedence test (tau/mod.rs) and the end-to-end precedence test (it_protocol/calibrate/tau.rs) exist, are reachable, and assert the specific claim (xrun beats a co-occurring low-SNR refusal), not just that the code executes.

scope issues

none authored by this PR. The bulk of the delta (module content from #388/#445) arrived via merge of already-separately-reviewed PRs; the one file this PR's own scope overlaps (handlers/calibrate/tau/{mod,measure}.rs) is exactly where #388's own stated scope says it would land, and traced above to confirm it doesn't disturb #368's own gate.

mechanical gate — re-run at new tip, full workspace

• cargo fmt --check — clean.
• cargo clippy --workspace --all-targets -- -D warnings — clean (exit 0).
• cargo clippy -p ac-daemon --features tau-window-override -- -D warnings — clean (exit 0).
• cargo test --workspace — exit 0, zero failures across every suite (ac-daemon unit 130 + it_protocol 114 passed/0 failed including the two new refused_xrun integration tests and all four tau/mod.rs xrun unit tests; ac-core 572 passed; ac-cli, ac-scene, ac-view all green; doc-tests trivial/clean). Ran with a dedicated CARGO_TARGET_DIR (~/src/ac-wt/target-qa-pr384-8567257) to avoid a shared-target false-fresh result. No flake reproduced this pass (it_set_drive — the flake noted in my d52b5fd4 review — ran clean).

verdict

approve
The merge brings in real production logic (#388's xrun-refusal gate) into the exact module this PR's SNR gate lives in, not just a refactor — traced the actual match-arm dispatch order in both tau/mod.rs and measure.rs to confirm the xrun-first precedence is real and doesn't disturb check_peak_snr's own boundary or TAU_SNR_THRESHOLD_DB, and confirmed both the unit and end-to-end tests for that precedence are reachable and assert the specific claim. Wire-schema consumers (ac-cli) match the new cal_done fields with tested rendering; ac-view has no τ-leg surface to miss. Full workspace gate is clean on a clean run.

Label note: 85672570 was pushed after the d52b5fd4 approval, which per the approval-voiding rule reverts that approval on push. claude-approved was left on the PR (same process gap noted in my last review). This comment is the fresh full-workspace gate pass and delta re-review the rule requires — it now stands on 85672570's own evidence, so the label can stay as-is rather than being toggled off and back on.

rig verification required

Not no — unchanged from the d52b5fd4 pass, carried forward (this delta doesn't touch the SNR gate or TAU_SNR_THRESHOLD_DB):

1. The 24 dB threshold's margin on the tested FF400/96 kHz/period-256 chain is 2.8 dB (artefact-floor-limited, level-invariant) — decide whether 24 dB stands or moves toward the record's suggested ~20 dB midpoint.
2. The muted-but-correlated loopback case was answered by rig-2026-09-14-pr384-tau-correlated (posted before the d52b5fd4 commit this delta builds on) — already noted as existing in my last review, not re-verified again here since this delta doesn't touch that code path.

Neither blocks approval of this delta's own code. requires-rig stays; only a human clears it.

[mkovero]

codex qa — PR #384 at 8567257

verdict: pass

coverage

All eight issue #368 acceptance criteria are addressed. The DMM pre-fill remains gated by the unchanged ±2 dB unity heuristic, while τ is attempted independently and refused by the shared pre-impulse-SNR calculation. The hot off-unity and muted-route integration tests reach the claimed paths: the hot case first proves step 2 observed captured_dbfs ≈ -30 dBFS with loopback: false, then proves τ measured; the muted case proves a below-threshold deconvolution is refused and not stored. cal_done, ac-cli, and ZMQ.md agree on the renamed state and SNR fields; ac-view has no cal_done consumer.

The prior Codex blocker is fixed at this tip: tau_gain_override() now affects both capture_block and play_and_capture, so the off-unity test can fail a reintroduced captured-level τ gate rather than passing at an accidental unity step-2 level.

gate

Claude QA workspace gate: inherited at current tip 856725700247caba43a9b564c0831982d9d5c08e
Codex targeted tests: not needed

unaddressed open questions

• Human decision retained by requires-rig: the exact-path rig run measured real-loopback SNR at 26.74–26.77 dB, only 2.8 dB above the derived 24 dB threshold, while uncorrelated muted routes measured 10.4–13.7 dB. Decide whether 24 dB stands or moves toward the measured gap midpoint. The follow-up attenuated-but-correlated run is answered: it remained level-invariant and returned the correct τ down to approximately −99 dBFS.

scope

none