Stimulus defaults run up to 0 dBFS: plot ir defaults to -6 dBFS, level ramps end at 0 dBFS

[mkovero]

problem

Every emitting CLI command falls back to a hardcoded level when none is typed, and several of those defaults are far above anything this project runs on real hardware. Operator, 2026-09-15:

"-6dBFS is way too loud default to be anywhere"

For scale: the standing rig ceiling is −40 dBFS, and the speaker path on the dedicated rig is held at −50 dBFS because a −40 dBFS sweep through a Genelec 1083 is already "surprisingly loud".

Defaults on main (read at 298f77dc, PR #352's tip, which carries main):

command	default	where
ac plot ir	−6 dBFS	ac-cli/src/parse/plot.rs:47
ac plot level	−40 → 0 dBFS ramp	ac-cli/src/parse/plot.rs:11,14
ac generate level	−40 → 0 dBFS ramp	ac-cli/src/parse/generate.rs:24,27
ac calibrate	−10 dBFS	ac-cli/src/parse/calibrate.rs:32
ac plot	−20 dBFS	ac-cli/src/parse/plot.rs:87
ac generate frequency	−20 dBFS	ac-cli/src/parse/generate.rs:51

The server-side backstop does not close this. drive_max_dbfs defaults to −10 dBFS (ac-core/src/config.rs:18), so on a machine without a hand-edited config a bare ac plot ir is clamped to −10 dBFS, not refused, and a bare level ramp reaches −10. #360 made plot_ir and calibrate honour the clamp. Whether plot_level / sweep_level ramps do was not verified for this issue.

why it matters

A default is the level a user gets by not deciding. Typing ac plot ir with no arguments is the natural first try, and here it puts a full-band sweep 34 dB above the rig ceiling into whatever is connected — amplifier, loudspeaker, DUT, or someone's headphones. The only thing standing between that and the hardware is a −10 dBFS clamp that is itself louder than any consented run so far.

This is the silent-default shape: nothing warns, the command succeeds, and the level was never chosen by anyone.

acceptance criteria

• No emitting CLI command defaults above a single, named, documented conservative level; the value and its reasoning live in one place, not six unwrap_or literals.
• Level ramps (plot level, generate level) do not default to ending at 0 dBFS.
• drive_max_dbfs's default is reconsidered together with the CLI defaults, so the backstop is not louder than the defaults it backs up.
• Whatever the command prints says the level was defaulted rather than chosen.
• Test: each emitting command parsed with no level token yields a level at or below the named default. A test that checks one command only would pass while another literal stays at −6.

Choosing the actual numbers, and whether some commands should instead require an explicit level, is a design decision — not settled here.

related

#360 (clamp coverage for plot_ir / calibrate), #442 (it_loopback_ir clamping at the −10 dBFS default).

[mkovero]

I would like common default level be something like -40dBFS, I also would expect everything same come from same understanding of set level. (ie. no different states of same thing.)

[mkovero]

spec

Revised 2026-09-15 after the operator's follow-ups: ramp default set, single global ceiling, ceiling visible to the user; ac-view removed from scope.

type: bug

problem statement
Every CLI command that can start emission falls back to its own hardcoded level when none is typed, and those fallbacks disagree with each other and with the ceiling: plot ir −6 dBFS, calibrate −10, plot / generate frequency −20, level ramps −40 → 0 dBFS. The ceiling is a config value, drive_max_dbfs, defaulting to −10 dBFS, and a level above it is clamped rather than refused. A default is the level a user gets by not deciding, so a bare ac plot ir puts a full-band sweep 34 dB above the rig ceiling into whatever is connected, silently, and nothing tells the user what the maximum is. The operator has ruled on direction (2026-09-15): one common default "something like −40 dBFS"; ramps "something like −40 to −30"; "everything same come from same understanding of set level (ie. no different states of same thing)"; and "we need less configurable/settable limits and more singular global ones in general, its important that user understands what is max volume or not". Read as a requirement: the typed-or-defaulted level, the ceiling, the level actually emitted and the level the user is told are one quantity with one definition, bounded by one global maximum the user can see.

acceptance criteria

defaults

• One named, documented set of default stimulus levels exists in one place, and every ac command that can start emission takes its default from it — no per-command level literal remains. The command set is enumerated by the developer; the six rows in the issue body are a floor, not the list.
• Single-level default is −40 dBFS — provenance: assumed (operator-chosen, 2026-09-15)
• Level ramp default (plot level, generate level) runs −40 → −30 dBFS — provenance: assumed (operator-chosen, 2026-09-15)

one global ceiling

• There is exactly one maximum emission level, defined once and enforced by the daemon for every emitting request, level ramps included.
• The ceiling is not per-command settable. Whether any override survives at all is the architect's decision, biased toward none; if one survives, it is one global value, and a user running with it changed is told so by the same means as the criterion under "the user knows the maximum".
• Every default level, ramp end points included, is at or below the ceiling — provenance: derived (the ramp default end of −30 dBFS sets the lowest ceiling that lets a bare plot level run unaltered). The actual ceiling value is the architect's to propose; it is not −10 dBFS by inheritance.
• Test: the defaults and the ceiling are checked against each other in one test, so raising a default or lowering the ceiling past the other fails a build rather than a rig run.

one understanding of level

• "Level" means one thing across all emitting commands: every one interprets a dBFS value by the same definition (AES17-2020 §3.12.3, the one reference_levels.rs cites). A command whose emitted signal differs from another's for the same typed dBFS value fails this criterion.
• No silent second state: a requested level above the ceiling is either refused or reported at the level actually emitted — the architect decides which, the same way for every command. The outcome is never a clamped emission reported at the unclamped level. Level ramps are covered, not only plot_ir / calibrate (drive_max_dbfs governs set_drive alone — plot_ir and calibrate emit unclamped, and calibrate defaults to -10 dBFS #360 did not verify ramps).

the user knows the maximum

• Every emitting command's output states the level used, whether it was defaulted or typed, and the maximum in force.

tests

• Test: every emitting command, parsed with no level token, yields exactly its named default. The test covers each command individually; a single-command test would stay green with one literal left at −6.
• Test: a level above the ceiling on each emitting command produces the chosen refuse-or-report behaviour. Name the case that turns it red: revert one command to clamp silently and the test must fail.

out of scope

• ac-view. It is a visualization module and this issue does not touch it.
• Speaker-path-specific limits. −40 dBFS is still "surprisingly loud" through a Genelec 1083 and the dedicated rig holds its speaker path at −50 dBFS by hand. The operator's direction is one global limit, not per-output ones, so that stays a matter of typing a lower level, not a second ceiling.
• Making a level token mandatory. Commands keep defaulting.
• Rig verification of emitted level or SPL at a transducer.
• The agents' own rig drive rule (−40 dBFS max, per-run consent). The product ramp default ending at −30 dBFS sits above it; agents running ramps on real hardware keep typing levels explicitly. This issue changes product defaults, not that rule.

files likely affected

• ac-rs/crates/ac-cli/src/parse/plot.rs, parse/generate.rs, parse/calibrate.rs — current per-command default literals
• ac-rs/crates/ac-core/src/config.rs — drive_max_dbfs as a config field and its default
• ac-rs/crates/ac-daemon — ceiling enforcement on emitting handlers, level ramp handlers
• wire protocol — flag: if the daemon reports the emitted level, the ceiling, or a "defaulted" marker, that is a reply-shape change for every protocol client

needs architect review
yes — where the single defaults and the single ceiling live, the ceiling value (≥ −30 dBFS), whether any override survives, refuse vs report-actual above the ceiling, how an existing config that sets drive_max_dbfs is treated once the field stops being the source of truth (a value that silently stops doing anything is a defect in its own right), and whether any of it changes the wire reply

estimated complexity
medium: 2–8h

---

Labels: needs-design (decisions above), needs-ux (level / defaulted / maximum wording on ac stdout), tier-1 — the "same understanding of set level" clause is governed by AES17-2020 §3.12.3's dBFS definition, even though most of the diff sits outside measurement/ (the #351 shape).

[mkovero]

design decision

Read against origin/main @ 6537962c, revised 2026-09-15 against c6cc1281 (#352 merged in between). Revision 2 2026-09-15, same base, plus the uncommitted work in the issue-459 worktree. Revision 3 2026-09-15, same base, plus PR #463 @ b72d6349 and the operator ruling of 20:59.

Revision 3 — what changed, and why. Re-entry from the operator ruling on levels (2026-09-15 20:59), which replaces this design's −20 dBFS maximum. PR #463 is open at b72d6349 and implements revision 2 faithfully. Its implementation is the evidence for this revision. Option A's structure still stands: named constants in ac-core, one daemon chokepoint, refuse instead of clamp, the retired key, and the max_dbfs ack field. The numbers change, and one bound is added. PR #463 is revised, not restarted. Changes:

1. MAX_EMISSION_DBFS −20 → 0 dBFS. A typed level runs exactly as typed, up to full scale. The daemon still refuses above 0 dBFS, and still refuses non-finite values.
2. New UNTYPED_LEVEL_MAX_DBFS = −30 dBFS. It bounds every level that plays without being typed. It is a build-time bound, checked by the coupling test. It is never a runtime check and never a wire field (see recommendation).
3. SELF_TEST_LEVEL_DBFS −20 → −30. This covers test_hardware's fixed tones and probe's tone. probe's loopback gate stays 20 dB below the tone, so it moves from −40 to −50 dBFS.
4. Self-test ladders are filtered at UNTYPED_LEVEL_MAX_DBFS, not at the maximum. This answers the ruling's "which points are not run". hw_dmm_tracking's n_pts >= 5 could never pass on a filtered ladder, so it is re-based (implementation notes).
5. gpio stops playing calibrated 0 dBu. A button press is a level nobody typed, so it plays DEFAULT_LEVEL_DBFS.
6. Retired drive_max_dbfs still refuses. The ruling asked whether it should; the reason is under recommendation.
7. Back to ux. Several user-visible texts were built on −20 and are now false or undecided: the maximum row at full scale, the refusal text, the skip note ("above maximum" now means above the untyped bound), probe's zero-headroom paragraph, and the help footer. Hence needs-ux, not ready-to-implement.
8. Manifest unchanged. Every file this revision touches is already listed.

What PR #463 has to become. The full list is under implementation notes → PR #463 revision. In short:

• Comes out: the −20 value and its reasoning in emission_level.rs; the ladder filters against MAX_EMISSION_DBFS; gpio's calibrated branch; the n_pts >= 5 verdict; OVER/AT_MAX = −19.9/−20.0 in level_max.rs; the -19dbfs refusal in it_level_max.rs; every "−20 dBFS maximum" sentence in ZMQ.md, the runbooks, the help and the renderer tests.
• Stays: everything else on the branch, including the fixture levels the −20 maximum forced. They are all at or below −20, so all are accepted under 0, and none emits louder than main did. Only the comments that call −20 the maximum get fixed.

Revision 2 — what changed, and why. This is a re-entry from the developer handback (2026-09-15 20:17): the manifest was short. No PR is open. The evidence for this revision is the uncommitted work in the issue-459 worktree. It stays inside the design everywhere except the three files the handback names, and its edits to those three are correct. Option A, the values, refusal, the retired key and the rev-1 setup field are all unchanged. Nothing in the worktree comes out.

1. Manifest +7.
   • The handback's three: transfer/request/tests.rs, it_protocol/warmup.rs, it_scene_fixture.rs.
   • Four more from a repo-wide sweep (the method is under risks): handlers/transfer/probe.rs, ac-cli/src/commands/probe.rs, tests/test_server_client.py, ac-view/tests/it_stimulus_live.rs.
2. probe is an emitter revision 1 missed. Its worker plays a fixed −10 dBFS tone on every playback port, outside any clamp. Under this revision:
   • it goes through the chokepoint and plays SELF_TEST_LEVEL_DBFS;
   • its loopback gate is defined relative to that tone;
   • its ack gains level_dbfs and max_dbfs (ZMQ impact items 2 and 3).
3. Back to ux, narrowly. The spec requires every emitting command to print its level and the maximum, so ac probe must too. Its level is neither typed nor defaulted: it is fixed in the build, and the ux comment has no marker for that. Only that line waits on ux. Hence needs-ux, not ready-to-implement.
4. .agents/rig.md conflicts with this design, and editing it is a human gate. See risks.

Revision 1 — what changed, and why. This revision answers the question the ux comment left open: ac setup's Emission max: row needs the maximum from the daemon. Everything else in the decision still holds. Option A, the values, refusal and the retired key are all unchanged. The changes:

1. setup ack gains top-level max_dbfs. It is added to ZMQ impact item 3. It goes at the top level of the ack, not inside config, and setup is never refused. See the new bullet under implementation notes.
2. Manifest +2: ac-rs/crates/ac-daemon/src/handlers/admin.rs (the setup handler) and ac-rs/crates/ac-daemon/tests/it_protocol/setup.rs.
3. Settled ux open question 2: the daemon composes the self-test skipped-point count into TestResult.detail. The CLI prints it as it arrives. This was already implied by "report the points that did not run in the TestResult detail". It is now explicit.
4. Stale refs refreshed: it_plot_ir.rs:339 is now :373. fix: onset estimator replaces argmax|h|, then its level crossing (#346, #378) #352 has merged, so the rebase risk now concerns docs(rig): one runbook and scripts for testing binaries on a rig #441 only.

No PR is open on this issue, so nothing on a branch is invalidated.

core question
Where do the one set of default levels and the one maximum live? Is that maximum settable at all? And what does the daemon do with a level above it: refuse, or clamp and report?
(rev 3) The ruling adds a second question. Levels that are typed and levels that are not now have different bounds: full scale for the first, −30 dBFS for the second. Which mechanism enforces each bound?

What main has now, for the record:

• drive_max_dbfs governs set_drive alone — plot_ir and calibrate emit unclamped, and calibrate defaults to -10 dBFS #360 put apply_drive_ceiling(cfg.drive_max_dbfs, …) (ac-daemon/src/handlers/mod.rs:220) on plot, plot_level, plot_ir, generate, generate_pink, sweep_level, sweep_frequency, calibrate, transfer_stream and set_drive. ac-cli: surface the drive_max_dbfs clamp warning on the 8 stimulus commands #380 prints a "level clamped to ceiling" line when the ack differs from the request.
• Four emitters are outside that clamp (rev 2: was "three"; probe was missed):
  • test_dut: level_dbfs, plus internal ladders to −3 and 0 dBFS (test_dut.rs:316,415).
  • test_hardware: fixed −10 dBFS tones and ladders to 0 dBFS (test_hw.rs:238,290,319,360,385,422,461,486).
  • gpio: 0 dBu from calibration, sent through generate.
  • (rev 2) probe: a fixed 1 kHz tone at −10 dBFS on each playback port in turn (transfer/probe.rs:50).
• The daemon has its own copies of the level literals, and they disagree with the CLI: plot −10, plot_ir −6, plot_level −40→0, sweep_level −20→0, generate/generate_pink −10, test_dut −20, transfer_stream −10. calibrate uses the ceiling itself as its default.
• ac generate sine|pink with no level plays 0 dBu when calibrated (commands/generate.rs:116).

option A — fixed constants in ac-core, daemon refuses, config key retired
A new module, ac-core/src/shared/emission_level.rs, holds the whole set: MAX_EMISSION_DBFS, (rev 3) UNTYPED_LEVEL_MAX_DBFS, DEFAULT_LEVEL_DBFS, DEFAULT_RAMP_START_DBFS, DEFAULT_RAMP_STOP_DBFS and SELF_TEST_LEVEL_DBFS. It also holds one pure check, check_emission_level(dbfs) -> Result<f64, _>, which refuses non-finite values and anything above the maximum. The daemon calls it through one chokepoint on every request that can emit. A level above the maximum gets an error reply, never a clamped emission. drive_max_dbfs stops being a setting. If a config still holds it, emitting commands refuse and name the key.
tradeoffs: one number, one enforcement point, one state. A request either runs at exactly the level asked for or does not run. The cost: nothing can reach full scale without a code change (rev 3: no longer true, since the maximum is full scale). The cost: every existing install has to delete one config key, once.

option B — same constants, drive_max_dbfs survives as the one global override
Same as A, except the config value, when set, replaces MAX_EMISSION_DBFS. Every emission line says "(config)" while it is in force.
tradeoffs: keeps full-scale measurement possible without a rebuild (rev 3: A now does that too). It keeps exactly what the operator asked to remove: a settable limit, and two values for "the maximum" (compiled and configured) that the user has to tell apart. The ruling says it again: "no per-command or per-client limit knobs".

option C — constants, keep clamp-and-report (the #360/#380 shape)
tradeoffs: commands never fail on level. But a clamp is the second state the spec forbids, even when it is reported. A clamped plot level −40 0 measures a flat-topped ramp nobody asked for, and its THD-vs-level result carries points whose x-value is not the level typed. Rejected. (rev 3: the ruling repeats it: "no clamping".)

recommendation
Option A. The operator's rule is one visible maximum with no per-anything knob, and only refusal makes the typed level, the emitted level and the printed level the same number by construction. The daemon is the only place that can enforce this for every client (CLI, gpio, ac-view, pyzmq runbooks).

Values (rev 3: operator ruling 2026-09-15 20:59):

• DEFAULT_LEVEL_DBFS = −40 — inherited from triage (assumed, operator-chosen)
• DEFAULT_RAMP_START_DBFS → DEFAULT_RAMP_STOP_DBFS = −40 → −30 — inherited from triage (assumed, operator-chosen)
• MAX_EMISSION_DBFS = −20 0 dBFS (rev 3) — provenance: assumed. It is the operator's ruling: "the daemon's maximum is whatever the daemon can physically produce (0 dBFS), not a safety ceiling". Under the level definition this module already tests, a sine at 0 dBFS has a peak at exactly full scale. The rev-2 reasoning for −20 (10 dB above the ramp top, 10 dB below the old −10 backstop) was an attempt to bound a typo. The ruling moves that job off the maximum and onto the untyped bound below. A typo is now bounded only by full scale; see risks.
• UNTYPED_LEVEL_MAX_DBFS = −30 dBFS (rev 3, new) — provenance: assumed (operator ruling: "levels that play without being typed must be at or below −30 dBFS"). The ramp default stop sits exactly on it.
• SELF_TEST_LEVEL_DBFS = −20 −30 (rev 3) — provenance: assumed. It sits on the untyped bound on purpose: the self-test pass thresholds were tuned at −10, and −30 keeps as much of that SNR as the ruling allows. It replaces test_hw's fixed −10 dBFS tones and probe's −10 dBFS tone.

(rev 3) Two bounds, two mechanisms.

• MAX_EMISSION_DBFS is enforced at runtime by the daemon, exactly as in rev 2. It is the only bound a client can cross, by typing a level or a dBu/Vrms value that converts above full scale.
• UNTYPED_LEVEL_MAX_DBFS is enforced at build time, by the coupling test over the named constants. Every untyped level is one of those constants, so a test over the constants covers every untyped level completely. A runtime check was rejected. The daemon cannot tell typed from defaulted, because the CLI resolves its defaults before sending and the wire carries a plain number. A runtime check would need a client-asserted "defaulted" flag, and the daemon would have to trust it. That flag would enforce nothing a test cannot enforce better, and it would put a second level quantity on the wire.
• The one runtime use of the untyped bound is the self-test ladders. Their levels are chosen inside the daemon, so the daemon filters them itself. It is not a field on any reply.

Refusal is decided once, for every command: refuse. A ramp is refused when either endpoint is above the maximum. A linear ramp never exceeds its larger endpoint, so the endpoints bound every point, and the per-point clamp inside the ramp workers comes out.

Retired key:

• Config keeps reading drive_max_dbfs, but only into a retired, round-tripping field that nothing uses as a limit.
• While the key is present, every emitting request refuses. The error names the key, its value, the config path and the fixed maximum.
• ac setup shows the key too.
• The field is serialized back when present, so no config save drops it quietly.

Silently ignoring the key would be the #225 defect class. Refusing emission is the loud form the #225 precedent (orphaned_sticky) already uses. It is also safe in both directions: a user who had configured a value below the new maximum is never made louder without being told.

(rev 3) It still refuses, now for a stronger reason. A user wrote that key to cap what a typed level could reach. The ruling removes every cap below full scale. Silently ignoring a configured −30 would now let a typed level run up to 30 dB above what that user set, where under rev 2 the gap was at most 10 dB. With no daemon-side cap left, the refusal is the only way that user learns their limit is gone. The cost has not changed: one key deleted, once, per install.

affected modules

• ac-core shared/emission_level.rs (new) — the constants, the check, the coupling test, the level-definition test. config.rs — drive_max_dbfs moves to a retired field.
• ac-daemon handlers:
  • one guard at every emitting entry
  • wire-side level defaults take the named constants
  • refusal replaces the clamp
  • test_hw/test_dut ladders are filtered, never clamped, and the skipped points are reported. (rev 3) The filter is against UNTYPED_LEVEL_MAX_DBFS.
  • max_dbfs added to acks
• ac-daemon handlers/admin.rs — (rev 1) the setup ack carries max_dbfs. No other change to setup.
• ac-daemon handlers/transfer/probe.rs (rev 2) — guarded like every emitter, tone at SELF_TEST_LEVEL_DBFS, loopback gate relative to the tone, ack carries level_dbfs + max_dbfs.
• ac-daemon gpio.rs — its fallback level becomes the named default. A refusal already prints through its existing generate failed: {ack} path. (rev 3) The calibrated 0 dBu branch comes out too: gpio always plays DEFAULT_LEVEL_DBFS.
• ac-cli parse — no level token yields the named constant and a defaulted marker. The help text drops "default: -10dBFS".
• ac-cli commands — one line renderer (level, default-or-typed, maximum from the ack) replaces render_level_clamp / render_level_clamp_range / print_level_clamp*. generate sine|pink stop defaulting to 0 dBu. ac setup shows Emission max: from the setup ack (rev 1), plus the retired key. (rev 2) ac probe prints the level and the maximum from the probe ack. Wording is ux's; (rev 3) ux reopens it for full scale.
• ac-view — compile-forced substitution only: cfg.drive_max_dbfs → MAX_EMISSION_DBFS at its three read sites. No design change to ac-view. The operator scoped it out; this edit exists only because the field it reads stops being the limit. (rev 2) Plus one #[ignore]d test, tests/it_stimulus_live.rs, whose fixed −10 dBFS drive the daemon now refuses. That change is test-only; no src/ change beyond the three read sites. (rev 3) With the maximum at 0, the substitution now bounds the editor at full scale. ac-view's untyped start level is −30 (app.rs:151), which already meets the ruling, so nothing further changes there.
• ac-scene wire.rs — doc comment only.

file manifest

ac-rs/crates/ac-core/src/shared/emission_level.rs
ac-rs/crates/ac-core/src/shared/mod.rs
ac-rs/crates/ac-core/src/config.rs
ac-rs/crates/ac-daemon/src/handlers/mod.rs
ac-rs/crates/ac-daemon/src/handlers/admin.rs
ac-rs/crates/ac-daemon/src/handlers/audio/generate.rs
ac-rs/crates/ac-daemon/src/handlers/audio/plot.rs
ac-rs/crates/ac-daemon/src/handlers/audio/sweep.rs
ac-rs/crates/ac-daemon/src/handlers/calibrate/mod.rs
ac-rs/crates/ac-daemon/src/handlers/test_dut.rs
ac-rs/crates/ac-daemon/src/handlers/test_hw.rs
ac-rs/crates/ac-daemon/src/handlers/transfer/ctrl.rs
ac-rs/crates/ac-daemon/src/handlers/transfer/plan.rs
ac-rs/crates/ac-daemon/src/handlers/transfer/probe.rs
ac-rs/crates/ac-daemon/src/handlers/transfer/request.rs
ac-rs/crates/ac-daemon/src/handlers/transfer/request/tests.rs
ac-rs/crates/ac-daemon/src/handlers/transfer/worker.rs
ac-rs/crates/ac-daemon/src/workers.rs
ac-rs/crates/ac-daemon/src/gpio.rs
ac-rs/crates/ac-daemon/examples/ir_probe.rs
ac-rs/crates/ac-daemon/examples/transfer_probe.rs
ac-rs/crates/ac-daemon/tests/it_protocol/main.rs
ac-rs/crates/ac-daemon/tests/it_protocol/level_clamp.rs
ac-rs/crates/ac-daemon/tests/it_protocol/level_max.rs
ac-rs/crates/ac-daemon/tests/it_protocol/setup.rs
ac-rs/crates/ac-daemon/tests/it_protocol/basics.rs
ac-rs/crates/ac-daemon/tests/it_protocol/plot_ir.rs
ac-rs/crates/ac-daemon/tests/it_protocol/transfer.rs
ac-rs/crates/ac-daemon/tests/it_protocol/warmup.rs
ac-rs/crates/ac-daemon/tests/it_protocol/calibrate/voltage.rs
ac-rs/crates/ac-daemon/tests/it_protocol/calibrate/tau.rs
ac-rs/crates/ac-daemon/tests/it_protocol/calibrate/query.rs
ac-rs/crates/ac-daemon/tests/it_cross_tier_parity.rs
ac-rs/crates/ac-daemon/tests/it_loopback_ir.rs
ac-rs/crates/ac-daemon/tests/it_set_drive.rs
ac-rs/crates/ac-daemon/tests/it_relock.rs
ac-rs/crates/ac-daemon/tests/it_scene_fixture.rs
ac-rs/crates/ac-cli/src/parse/mod.rs
ac-rs/crates/ac-cli/src/parse/plot.rs
ac-rs/crates/ac-cli/src/parse/generate.rs
ac-rs/crates/ac-cli/src/parse/calibrate.rs
ac-rs/crates/ac-cli/src/parse/sweep.rs
ac-rs/crates/ac-cli/src/parse/test.rs
ac-rs/crates/ac-cli/src/commands/mod.rs
ac-rs/crates/ac-cli/src/commands/plot.rs
ac-rs/crates/ac-cli/src/commands/sweep.rs
ac-rs/crates/ac-cli/src/commands/generate.rs
ac-rs/crates/ac-cli/src/commands/calibrate.rs
ac-rs/crates/ac-cli/src/commands/test.rs
ac-rs/crates/ac-cli/src/commands/setup.rs
ac-rs/crates/ac-cli/src/commands/probe.rs
ac-rs/crates/ac-cli/tests/it_level_clamp.rs
ac-rs/crates/ac-cli/tests/it_level_max.rs
ac-rs/crates/ac-cli/tests/it_plot_ir.rs
ac-rs/crates/ac-scene/src/wire.rs
ac-rs/crates/ac-view/src/main.rs
ac-rs/crates/ac-view/src/app.rs
ac-rs/crates/ac-view/src/settings.rs
ac-rs/crates/ac-view/tests/it_stimulus_live.rs
ac-rs/ZMQ.md
ARCHITECTURE.md
docs/runbooks/loopback-ir.md
docs/runbooks/rig-headless.md
tests/test_server_client.py

interface changes

• CLI: no new flags or tokens.
  • Bare defaults change: plot, plot ir, generate frequency, generate sine, generate pink, calibrate and test dut → −40 dBFS; plot level and generate level → −40 → −30 dBFS.
  • A typed level whose dBFS value is above −20 now fails (rev 3) A typed level whose dBFS value is above 0 dBFS fails with the daemon's error instead of running clamped. That includes dBu/Vrms levels converted through calibration, e.g. generate sine 20dbu on a +19 dBu full-scale output. Any typed level from −20 to 0 dBFS runs exactly as typed. On main it ran clamped to the config's drive_max_dbfs, which is −10 by default.
  • Every emitting command prints the level, whether it was defaulted or typed, and the maximum (wording: ux comment, (rev 3) reopened).
  • ac setup prints the maximum too (rev 1).
  • (rev 2) ac probe prints its fixed tone level and the maximum. (rev 3) The tone drops from −10 to −20 −30 dBFS, and the loopback gate moves with it (see implementation notes).
  • calibrate with a dBu/Vrms level and no calibration now errors like every other command, instead of falling back to −10.
  • (rev 3) test hardware fixed tones at −30 dBFS (−10 on main). test hardware / test dut ladder points above −30 dBFS are not run.
• gpio (rev 3): a button press plays DEFAULT_LEVEL_DBFS (−40). On main it played 0 dBu when calibrated, and −20 dBFS otherwise.
• config: drive_max_dbfs is no longer a limit. While present, it makes emitting requests refuse.
• public Rust API: ac_core::shared::emission_level (new). (rev 3) It adds UNTYPED_LEVEL_MAX_DBFS. Config::drive_max_dbfs becomes a retired field, so ac-view's reads move to the constant. apply_drive_ceiling is removed (pub(super), daemon-internal).
• Cargo features: none.

ZMQ protocol impact
yes — for both consumers:

1. Over-maximum request: these commands now reply {"ok": false, "error": "<text>", "max_dbfs": <float>} where they used to reply ok: true with the clamped value: plot, plot_level, plot_ir, generate, generate_pink, sweep_level, sweep_frequency, calibrate, test_dut, transfer_stream (when drive or drivable) and set_drive (when on: true). set_drive with on: false is not checked, so turning drive off is never refused. (rev 3) "Over-maximum" means above 0.0 dBFS, or non-finite.
2. Retired key present: the same commands reply ok: false with an error naming drive_max_dbfs and the config path. (rev 2) So does probe. (rev 3) So does test_hardware, as PR fix: unify emission defaults and ceiling #463 already does.
3. Additive: "max_dbfs": <float> is carried by every successful ack from the commands in (1), by test_hardware, (rev 1) by setup, and (rev 2) by probe. The probe ack also gains "level_dbfs": <float>, the fixed tone level. Echoed level fields keep their names and now always equal the request. (rev 3) In this build max_dbfs is always 0.0 and probe's level_dbfs is -30.0. The field stays even though its value is constant: it is how a client tells a daemon from this build apart from an older one that clamps to a config value. The untyped bound is not added to any reply (see recommendation).
   • On setup the field sits at the top level, beside config, not inside it. config is the config file; the maximum is a build constant, and putting it there would make it look settable.
   • A retired drive_max_dbfs still appears inside config when it is present, because the field round-trips. That is how ac setup finds it for its retired-key row. No second field is needed.
   • setup is never refused, whether because of the retired key or for any level reason. It is the non-emitting command where the user sees the maximum and the key to remove.
   • (rev 2) probe takes no level input, so it is never refused on level; the coupling test keeps SELF_TEST_LEVEL_DBFS at or below the maximum (rev 3) the untyped bound, and so below the maximum.
   • (rev 2) The loopback DATA frame's level_dbfs is a captured level and keeps its meaning. The gate that decides whether that frame is published moves from a fixed −30 dBFS to 20 dB below the tone, which is −40 (rev 3) −50 dBFS in this build. On the same hardware, a real loopback now captures 20 dB lower than on main, and the gate is 20 dB lower too, so the detection budget is unchanged. The DATA-side change is that a port whose idle capture sits between −50 and −30 dBFS can now be published as a pair (risks).
4. Wire defaults: an omitted level_dbfs / start_dbfs / stop_dbfs / ref_dbfs resolves to the named constants. calibrate's omitted ref_dbfs stops meaning "the ceiling".

Consumers:

• ac-cli: updated in this issue. Against an older daemon whose ack has no max_dbfs, it must print the maximum as unknown, never its own compiled constant, because the CLI may be talking to a remote daemon of a different build. (rev 1) This applies to ac setup as well as to emitting commands. (rev 3) Against an older daemon, the level row prints the level the ack echoes, which is the clamped level. It never prints the level the CLI sent.
• ac-view: sends set_drive / transfer_stream levels already clamped client-side to its ceiling. Once that ceiling is the same constant, it never sends an over-maximum level, so it needs no wire handling. With the retired key in config, its transfer drive is refused, and it shows the reply's error through its existing set_drive error path. Nothing is added for that. It never reads the setup ack's new field.
• (rev 2) probe consumers: ac-cli (commands/probe.rs) and tests/test_server_client.py::test_probe_ack. That test asserts only ok, n_playback and n_capture, so the new fields are safe for it. ac-view and gpio never send probe.
• gpio and the pyzmq runbooks: covered by (1) and (4). gpio's own setup read (gpio.rs:392) and commands/generate.rs:134 ignore unknown top-level fields, so (3) is safe for them.

implementation notes for developer

• (rev 3) PR fix: unify emission defaults and ceiling #463 revision. Revise the branch at b72d6349; do not restart. What changes, by file:

  • emission_level.rs:
    • MAX_EMISSION_DBFS → 0.0; add UNTYPED_LEVEL_MAX_DBFS = -30.0; SELF_TEST_LEVEL_DBFS → -30.0.
    • Rewrite the doc comments on all three to the rev-3 provenance above. Replace the −20 reasoning, do not just delete it: say it was a typo bound, and that the ruling moved the typo bound off the maximum.
    • Rebuild the coupling test (tests section below).
  • test_hw.rs: hw_level_linearity, hw_thd_floor and hw_dmm_tracking filter against UNTYPED_LEVEL_MAX_DBFS, not MAX_EMISSION_DBFS.
  • test_dut.rs: dut_thd_vs_level and dut_clipping_point filter against UNTYPED_LEVEL_MAX_DBFS, not MAX_EMISSION_DBFS.
  • Ladder results after the filter, for orientation:
    • linearity: −42, −36, −30 (3 of 7)
    • THD floor: −40, −30 (2 of 5)
    • DMM tracking: −40, −30 (2 of 7)
    • DUT THD vs level: −40, −30 (2 of 6)
    • DUT clipping: −30 only (1 of 11)
  • Keep test_hardware's emission_guard!(…, SELF_TEST_LEVEL_DBFS), which refuses the retired key. test_dut's typed level_dbfs stays guarded against MAX_EMISSION_DBFS. A typed test_dut level does not lift its internal ladders: the ladders are untyped whatever level was typed.
  • Skip-note and clipping-detail text follows ux. Until ux answers, the daemon must not say "above maximum" for a point that is below full scale.
  • hw_dmm_tracking verdict: n_pts >= 5 becomes "every point that ran was read" (n_pts == levels.len()), still together with max_err < 2.0.
    • The 5 was coupled to the 7-point ladder. It tolerated two failed DMM reads.
    • Under any filter at −10 dBFS or lower it can never pass. That was already true at rev 2's −20 (3 points), and PR fix: unify emission defaults and ceiling #463's own comment says so.
    • The new rule is stricter per point: it tolerates no failed read. This is the one pass threshold rev 3 changes on purpose. Every other threshold stays as the rev-2 note says.
  • probe.rs: LOOPBACK_GATE_DBFS and its unit test already follow the tone, so no code change; the gate becomes −50. ZMQ.md's probe section (~2723) changes to −30 tone / −50 gate.
  • gpio.rs resolve_level: delete the get_calibration branch and the clamp(-60.0, -0.5). The function returns DEFAULT_LEVEL_DBFS, or goes away. Its eprintln! lines keep printing the level. Update the doc comment PR fix: unify emission defaults and ceiling #463 wrote, which justifies keeping the calibrated branch.
  • it_protocol/level_max.rs:19–20: OVER → 0.1, AT_MAX → 0.0, and the module doc to match.
  • ac-cli/tests/it_level_max.rs:
    • The refusal case at :170 (-19dbfs) becomes a typed level above full scale, e.g. 1dbfs. parse_level accepts it, but classify tries parse_time first; confirm the token classifies as Level before relying on it.
    • The maximum -20.0 dBFS assertions follow ux.
  • Text still reading −20 as the maximum:
    • ac-rs/ZMQ.md ~1010, 1050, 1118, 1240, 1302, 1477, 1509, 1541, 2004, 2498, 2723, 2890
    • docs/runbooks/loopback-ir.md:45 and rig-headless.md:28
    • commands/mod.rs:354 (renderer test) and parse/mod.rs:725 (help footer); both wordings are ux's
  • Fixture levels stay as PR fix: unify emission defaults and ceiling #463 set them. Every one is at or below −20, so each is accepted under 0. Reverting to main's −6/−12/−10 would emit louder than main did, because main clamped them to −10, and it would move expectations PR fix: unify emission defaults and ceiling #463 already re-derived (calibrate/voltage.rs expected_out). Fix only comments and assert messages that call −20 the maximum, in warmup.rs, it_scene_fixture.rs, transfer.rs, basics.rs, plot_ir.rs, calibrate/{voltage,tau,query}.rs, it_cross_tier_parity.rs, it_relock.rs, ac-cli/tests/it_plot_ir.rs, tests/test_server_client.py.
  • ac-view/tests/it_stimulus_live.rs: CEILING follows the constant to 0. DRIVE_DBFS −35 stays below the −20 fake idle tone, so the flipped peak comparisons remain valid. Fix only the comments that say no accepted level can exceed the idle tone.
  • it_loopback_ir.rs: its RIG_DRIVE_CEILING_DBFS −40 is a harness-side rig limit, independent of the product maximum. No change.

• Chokepoint: replace apply_drive_ceiling in handlers/mod.rs with a guard that takes the config and the level(s) a request will emit, and returns the error Value described under ZMQ impact.

  • Call it right after parsing, before port resolution or spawn_worker, everywhere apply_drive_ceiling is called today, and add it to test_dut.
  • set_drive (transfer/ctrl.rs:48) and transfer_stream (transfer/plan.rs:107) go through the same guard.
  • The pure function in ac-core has no config parameter. Only the daemon wrapper looks at the retired key.

• setup ack (rev 1): in handlers/admin.rs::setup, the final json!({"ok": true, "config": cfg_value}) gains max_dbfs from MAX_EMISSION_DBFS. Do not call the emission guard here. The read path (update: {}) and the write path return the same field.

• probe (rev 2): in transfer/probe.rs:

  • Call the chokepoint before spawn_worker, so a retired key refuses probe like every other emitter.
  • The tone at :50 becomes SELF_TEST_LEVEL_DBFS.
  • The loopback gate at :165 (level_dbfs > -30.0) becomes a named constant defined relative to the tone: 20 dB below its peak dBFS, which is −40 (rev 3) −50 dBFS in this build — provenance: derived (on main, the −10 dBFS tone sits 20 dB above the −30 dBFS gate). The ratio is what counts. A fixed −30 gate with a −30 tone would detect no loopback at all.
  • The DMM threshold at :47 stays absolute. It is coded as 0.010/√2 V (7.07 mVrms), while ZMQ.md says 10 mVrms; that discrepancy is not this issue's. (rev 3) At −30 dBFS it flags any output whose full-scale sine is above −10.8 dBu — provenance: derived (7.07 mV = −40.8 dBu, plus 30 dB).
  • The ack at :199 gains level_dbfs and max_dbfs.
  • Unit test, in probe.rs's existing mod tests: the gate equals tone − 20 dB. Red case: restore the literal -30.0.
  • commands/probe.rs renders the level block through the shared renderer, with the marker ux names for a fixed level.

• Ramps: plot_level (plot.rs:451–) and sweep_level (sweep.rs:25–) check both endpoints up front, and the per-point apply_drive_ceiling calls come out. The start_dbfs_applied/stop_dbfs_applied echoes become the request.

• Self-test ladders (test_hw.rs, test_dut.rs):

  • Filter each ladder by the pure check (rev 3) against UNTYPED_LEVEL_MAX_DBFS. Never move a point down to the bound.
  • The daemon composes the count of points that did not run into TestResult.detail (rev 1: settles ux open question 2 — result text is built daemon-side, the CLI prints it).
  • A clipping search that finds no clip reports that it found none up to the bound, not a bare "no clipping". Wording: ux.
  • The fixed −10 tones become SELF_TEST_LEVEL_DBFS.
  • Do not loosen a pass threshold to make a test green. If one flips on fake, report it on the PR. (rev 3: the one exception is hw_dmm_tracking's count, decided above.)

• Retired key: an Option<f64> field with #[serde(rename = "drive_max_dbfs", default, skip_serializing_if = "Option::is_none")] is the shape that round-trips. Model the error text on orphaned_sticky in handlers/mod.rs, which names the key and the fix.

• CLI parse:

  • Each of parse/plot.rs:11,14,47,87, generate.rs:24,27,51, calibrate.rs:32 and test.rs:36 takes its constant.
  • GenerateSine/GeneratePink's Option<LevelSpec> resolves to DEFAULT_LEVEL_DBFS, not 0 dBu.
  • The parsed command has to carry "defaulted" as well as the value, because the renderer needs it. The representation is your call.
  • Remove the stray literals: unwrap_or(-12.0) in commands/generate.rs, and the -10.0 fallback in commands/calibrate.rs.

• CLI output: one pure render_* function in commands/mod.rs, unit-tested the way render_level_clamp is today (ac-cli: surface the drive_max_dbfs clamp warning on the 8 stimulus commands #380 QA split). It takes the value(s), the defaulted flag and Option<max_dbfs> from the ack. commands/setup.rs reads top-level max_dbfs from the setup ack. When it is absent it prints the ux comment's "not reported by this daemon" form. (rev 3) The renderer never prints UNTYPED_LEVEL_MAX_DBFS as a daemon fact. If ux wants it shown, only ac help may state it, as a statement about this CLI build's defaults.

• Tests the spec requires:

  • Coupling test, in emission_level.rs:
    • (rev 3) Every default, both ramp endpoints and SELF_TEST_LEVEL_DBFS are ≤ UNTYPED_LEVEL_MAX_DBFS.
    • UNTYPED_LEVEL_MAX_DBFS ≤ MAX_EMISSION_DBFS.
    • Ramp start ≤ stop.
    • Red cases: set SELF_TEST_LEVEL_DBFS back to −20, PR fix: unify emission defaults and ceiling #463's current value; or set DEFAULT_RAMP_STOP_DBFS to −29.
  • (rev 3) Check boundary, in emission_level.rs: 0.0 → Ok, 0.1 → Err, NaN → Err.
  • (rev 3) Ladder bound, in test_hw.rs/test_dut.rs #[cfg(test)] modules: hoist each ladder into a named constant plus one shared filter, and assert that every retained point is ≤ UNTYPED_LEVEL_MAX_DBFS and at least one point is retained. Red case: filter against MAX_EMISSION_DBFS again, which retains −20…0.
  • (rev 3) DMM tracking verdict: extract it as a pure fn. Cases: 2 of 2 read with error < 2 % passes; 1 of 2 read fails. Red case: restore n_pts >= 5, which fails the first case.
  • Per-command parse tests, one per command, in the existing parse/*.rs test modules: value == constant and defaulted == true. Red case: restore -6.0 at plot.rs:47.
  • Per-command refusal, in it_protocol/level_max.rs:
    • One test per wire command listed under ZMQ impact, at −19.9 (rev 3) +0.1 dBFS, asserting ok: false and max_dbfs.
    • One test at exactly −20.0 (rev 3) 0.0, asserting ok: true.
    • (rev 3) One test at −10.0 dBFS on generate, between the rejected −20 maximum and the new one, asserting ok: true and an echoed level of exactly −10.0. Red case: MAX_EMISSION_DBFS back at −20.
    • Red case: put .min(MAX) back into any one handler, and that handler's test fails.
    • One retired-key test: spawn_with_config({"drive_max_dbfs": -10.0}) makes generate refuse, naming the key.
    • (rev 2) probe: under the retired key it refuses. Without the key, its ack carries level_dbfs == SELF_TEST_LEVEL_DBFS and max_dbfs. Red case: drop the guard call from probe.
  • (rev 1) setup ack, in it_protocol/setup.rs:
    • setup with update: {} returns ok: true and top-level max_dbfs equal to the constant.
    • Under spawn_with_config({"drive_max_dbfs": -10.0}), it still returns ok: true, config.drive_max_dbfs == -10.0 and max_dbfs equal to the constant.
    • Red cases: drop the field from the handler, or route setup through the emission guard.
  • End-to-end, in ac-cli/tests/it_level_max.rs, modelled on the current it_level_clamp.rs. it_level_clamp.rs is deleted, along with it_protocol/level_clamp.rs.
  • One understanding of level (AES17-2020 §3.12.3, rms), in the emission_level.rs tests: at the same dBFS, generate_sine, generate_pink_noise and log_sweep scaled by dbfs_to_amplitude have rms within 0.05 dB of each other (provenance: assumed) and of 10^(dBFS/20)/√2.
    • These are the buffers JACK and CPAL play (set_pink → generate_pink_noise).
    • The measurement::sweep import sits in a #[cfg(test)] module, so it adds no runtime Tier 0 → Tier 1 dependency.

• Existing tests that send levels above −20 move to at or below it, or become refusal assertions (rev 3: done on PR fix: unify emission defaults and ceiling #463; the levels stay, see PR fix: unify emission defaults and ceiling #463 revision above):

  • basics.rs:206,313
  • plot_ir.rs (−6, 12)
  • transfer.rs:51,158 (−12)
  • calibrate/{voltage,tau,query}.rs and it_cross_tier_parity.rs (ref_dbfs −10)
  • it_loopback_ir.rs:70,754
  • it_set_drive.rs:29
  • it_relock.rs:27
  • ac-cli/tests/it_plot_ir.rs:193,244,373
  • (rev 2) it_protocol/basics.rs:85 (−12; revision 1 missed this line).
  • (rev 2) The three files from the handback: it_protocol/warmup.rs:132,179,269 (−12); it_scene_fixture.rs:104 (ref_dbfs −10); transfer/request/tests.rs:63 (the -10.0 wire-default assertion becomes DEFAULT_LEVEL_DBFS).
  • (rev 2) tests/test_server_client.py:119-120,260-261,334-335,369-370: ramps ending at −16, 0, −16 and −18 dBFS.
  • (rev 2) ac-view/tests/it_stimulus_live.rs (#[ignore], box-only).

  If a numeric expectation shifts because a stimulus is lower, re-derive it. Do not widen a tolerance to absorb it.

• Docs:

  • ZMQ.md: every "clamped to the config's drive_max_dbfs" paragraph becomes refusal plus max_dbfs. (rev 3) The threshold is 0 dBFS; the line list is under PR fix: unify emission defaults and ceiling #463 revision. (rev 1) The setup Reply block (~line 895) gains "max_dbfs": <float> and one sentence saying it is the fixed build maximum, not a config key.
  • ARCHITECTURE.md: the shared/ listing gets emission_level.rs.
  • The runbooks drop the stale "plot_ir does not apply drive_max_dbfs" text.

scope
tier-1 — unchanged from triage.

risks

• (rev 3) No daemon-side cap below full scale. A typed mistake plays as typed: ac generate sine 0 is a full-scale sine, because a bare number is dBFS. This follows directly from the ruling. The untyped bound protects only the run where nothing was typed. Mitigation: none in this issue. The level row shows (typed) and the level, so the output never misstates what played.
• (rev 3) Noise at typed levels near full scale clips at the converter, and nothing refuses it. The maximum is defined on the AES17 sine-equivalent rms, and pink noise has a much higher crest factor than a sine. Its peaks reach full scale from roughly −9 dBFS — provenance: derived (sine-equivalent rms = level − 3 dB re peak; pink crest factor ≈ 12 dB, which is assumed). The error runs one way: output clipped, printed level still the rms that was asked for. A peak-aware refusal needs its own issue.
• Every existing install has the key. ac setup has written "drive_max_dbfs": -10.0 into config.json for as long as the field has existed, so on each install the first emitting command after upgrade refuses. Mitigation: the error names the file and the one-line fix, and ac setup shows the key and still works (rev 1). This is deliberate: quietly ignoring the key is the defect class this repo already treats as a bug, and (rev 3) with no cap below full scale it is the only notice a limit-setting user gets.
• Self-tests lose their loud end. test hardware and test dut lose every point above −20 dBFS (rev 3) test hardware and test dut lose every point above −30 dBFS: the linearity top, THD at −20/−10/−3, DMM tracking above −30, and the whole clipping search except −30.
  • The fixed tones run 20 dB lower than on main. Pass thresholds tuned at −10 may flip, especially SNR-limited ones such as channel match and repeatability.
  • Mitigation: skipped points are reported, and thresholds are not loosened silently. Re-baselining on a rig is a follow-up, not part of this issue.
  • (rev 3) The DUT clipping search is effectively a single point now. It can only say "clipped at −30" or "no clip up to −30".
  • A typed ladder top for self-tests, which the ruling would allow because typed levels are uncapped, is a new CLI token and needs its own issue.
• (rev 2) Manifest completeness. Revision 1 missed seven files: the three in the handback and four the handback did not name.
  • Swept for this revision:
    • drive_max_dbfs, apply_drive_ceiling and level_clamp repo-wide;
    • every JSON level_dbfs / ref_dbfs / start_dbfs / stop_dbfs above −20 in ac-rs/crates, tests/ and docs/runbooks;
    • every runtime set_tone / set_pink / dbfs_to_amplitude site in ac-daemon/src.
  • (rev 3) Re-swept on PR fix: unify emission defaults and ceiling #463 for literal levels still in runtime code (dbfs_to_amplitude(<literal>), set_tone(<literal>), set_pink(<literal>), unwrap_or(<float>)) in ac-daemon/src and ac-cli/src. The hits are frequency/time/test-only literals, plus cpal_backend.rs:620 inside mod tests. The remaining untyped levels are gpio's (fixed above) and ac-view's −30 start level, which already meets the ruling.
  • Checked and deliberately not in the manifest:
    • handlers/audio/monitor/mod.rs: its tones are fake-backend only.
    • audio/contiguity.rs: #[test] fns; the hardware ones already run at −40.
    • audio/cpal_backend.rs:620: inside mod tests.
    • handlers/mic.rs, handlers/test_software.rs: arithmetic only, no emission.
    • it_protocol/monitor.rs:198: fake_tones is input, not emission.
    • ac-view stimulus.rs, view/state.rs, app_tests.rs: drive_max_dbfs survives there only as a parameter name or in a doc comment, and compiles unchanged.
  • If the compiler or a test still forces a file outside the list, that is a handback, same as before.
• (rev 2) Probe loopback floor. The gate follows the tone, so a path with less than 17 dB of loss is still detected, exactly as on main. (rev 3) The gate is now −50 dBFS, and it is compared against a broadband 50 ms rms of each capture port (probe.rs:156–165), not a 1 kHz-selective level. A mic input with preamp gain in an ordinary room can idle above −50 dBFS. On such a port, probe reports false loopback pairs. The error runs one way: extra pairs, never missed ones. The idle floor is not re-measured here; checking it needs a rig.
• (rev 2) .agents/rig.md goes stale, and editing it is a human gate. Its step 2 (~lines 95–96) and hard constraints (~144–151) name drive_max_dbfs as the server-side interlock for a rig exception above −40 dBFS; the worked example is drive_max_dbfs: -30.0. After this issue, that config refuses every emission, and (rev 3) nothing server-side limits a level below full scale. The operator's ruling names this as theirs and out of scope. Runs at or below −40 are unaffected. The agents' rig rule is enforced by typing the level, as it_loopback_ir.rs's harness-side RIG_DRIVE_CEILING_DBFS already does.
• Version skew. An old CLI against a new daemon gets an error where it expected a clamped success, and prints the error, which is correct. A new CLI against an old daemon gets no max_dbfs, from emitting commands or from setup, and prints the maximum as unknown.
• Open PR overlap. (rev 1: fix: onset estimator replaces argmax|h|, then its level crossing (#346, #378) #352 has merged, and this design is re-read against it.) docs(rig): one runbook and scripts for testing binaries on a rig #441 still edits both runbooks. Whichever lands second rebases.
• What this will not fix:
  1. Nothing can emit above −20 dBFS without editing one constant (rev 3: withdrawn — typed levels reach full scale.)
  2. −40 dBFS is still loud through a speaker path; a −40 dBFS sweep through a Genelec 1083 is already "surprisingly loud". (rev 3) The untyped bound protects the first run; it does not make a speaker path safe. The dedicated rig keeps typing −50.
  3. The fake backend's broadband noise does not follow the AES17 level definition, and this issue leaves it alone:
     • It is uniform with peak amp, so its rms is amp/√3, 1.76 dB below the AES17 rms of the pink that JACK and CPAL produce.
     • It substitutes 0.1 for a non-positive amplitude (fake/stimulus.rs:210–235).
     • The mismatch is confined to the fake backend, and the infra: display-truth verification harness (T2/T3), blocking gate for value-display PRs #170 display-truth fixtures depend on it (it_protocol/monitor.rs:268), so the level-definition test runs on the generator instead. It needs its own issue.
  4. gpio.rs:383's clamp(-60.0, -0.5) stays (rev 3: withdrawn — the calibrated branch and its clamp come out.) gpio loses its 0 dBu reference tone. A gpio level other than the default would be a new setting or input, and the ruling argues against settings, so it needs its own issue if it is wanted.
  5. (rev 3) Self-test result rows still never reach ac stdout (ux rev 1 open question). The skip notes exist on the wire only.

[mkovero]

Revision 2 — 2026-09-15, re-entry from architect revision 3 (operator ruling 20:59), against PR #463 @ b72d6349. The maximum is now full scale, and levels that are not typed have their own −30 dBFS bound. Every number in revisions 0–1 was built on −20. The structure stands: one level block, (default)/(typed)/(fixed), refusal with no level block. The wording and alignment around the maximum do not. What changed, and why:

1. maximum row gains (full scale). The CLI prints it only when the ack's max_dbfs is exactly 0.0. On that value it is a definition, not a CLI constant. 0.0 dBFS with no marker reads like a cap someone picked, the way −10 and −20 were. The marker says there is no cap below the converter's limit, and so no typo protection.
2. Values are right-aligned, and dBu carries an explicit sign. PR fix: unify emission defaults and ceiling #463 prints {v:.1} unpadded. At −20 that aligned by accident, because -40.0 and -20.0 are the same width. At 0.0 it breaks (before/after 1). dBu uses {:6.2} with no sign, so full scale on a +19 dBu output prints 19.00 dBu.
3. Refusal text: "above the maximum X" → "above full scale (0.0 dBFS)". A refused dBFS value above zero carries +.
4. Retired-key refusal rewritten. It now says typed levels play as typed up to full scale. That is architect rev 3's reason for keeping the refusal: a user who set the key as a cap is losing it. It is also rewrapped to 80 columns; PR fix: unify emission defaults and ceiling #463's first line is 112 columns.
5. ac setup: Emission max: gets (full scale, fixed). The retired-key row moves under a Retired key: label so its value lines up with the rows above it. Its note now states the consequence (refusal), not "it limits nothing".
6. ac probe: the tone is −30. The rev-1 zero-headroom paragraph comes out, because level and maximum no longer coincide.
7. Skip notes no longer say "maximum". They name the −30.0 dBFS bound, give skipped and total counts, and the DMM tracking detail says how many points were read. That count is what its new pass rule tests.
8. New: ac test hardware and ac test dut need a ladder row. test hardware prints no level at all on PR fix: unify emission defaults and ceiling #463. test dut prints only the typed or default level, while its THD-vs-level and clipping ladders play −40 and −30 whatever was typed. A bare ac test dut therefore prints -40.0 dBFS and plays −30. A typed -50 understates the loudest tone by 20 dB. That is the "printed level ≠ emitted level" state the spec forbids. The rows need the ladder span on the wire. That is an open question for the architect, and it is why this revision hands over with needs-discussion.
9. Help footer rewritten; gpio stderr wording given (rev 3 removed the premise of its "calibration unavailable" line).

What comes out of PR #463 (everything else in its CLI output stays):

• commands/mod.rs render_level_block: the {v:.1} value format and {dbu:6.2}. render_level_range_block: {start:.2} → {stop:.2} dBu. Its level row takes start_dbfs/stop_dbfs from the CLI's own conversion. Architect rev 3 requires the ack echo, so that goes too.
• The renderer unit test's -20.0 expectations.
• emission_level.rs check_emission_level_named: "is above the maximum {MAX:.1} dBFS".
• handlers/mod.rs retired_drive_max_dbfs_error: the whole message, including the unformatted {configured}, which prints -10.
• setup.rs: the (fixed) suffix and the drive_max_dbfs: … (retired — remove it; it limits nothing) row.
• test_hw.rs ×3, test_dut.rs ×2: "points above maximum not run" and "above the {MAX} dBFS maximum not run". hw_dmm_tracking's "over {n_pts} points".
• commands/test.rs: "Hardware test started...".
• parse/mod.rs: the two-line levels footer.
• gpio.rs: "calibration unavailable, using …", and {:.2} on its three level prints.
• it_level_max.rs: the "above the maximum -20.0 dBFS", "level -20.0 dBFS (typed)" and "maximum -20.0 dBFS" asserts. The column count changes too; see proposed output.

Revision 1 — 2026-09-15, re-entry from architect revision 2. Narrow scope: ac probe. Its level is set in the build. No token or config changes it, so neither (default) nor (typed) is true for it. What changed, and why:

1. New marker (fixed). This is the third provenance marker. (typed) means you chose the level. (default) means the build chose it and you could have typed another. (fixed) means the build chose it and nothing can change it. It is the same word, with the same meaning, as the (fixed) already on ac setup's Emission max: row.
2. ac probe proposal added under proposed output, field justifications and before/after.
3. Open questions 1 and 2 are settled by architect revision 1: setup ack gains max_dbfs, and the daemon composes the skipped-point count into TestResult.detail.
4. New bound, not a new requirement: the CLI never renders test_result frames. See open questions.
5. "All ten emitting commands" now reads "every emitting command". probe is the eleventh.

what this output must communicate

1. The level that actually leaves the output on this run, in dBFS, as one number that is the typed level, the emitted level and the printed level at once. Refusal (never clamp) makes those the same quantity by construction. (rev 2) For a self-test, this means every level it plays, ladders included.
2. Who set that level (a human, the build's default, or the build with no way to change it), and the one maximum in force, read from the ack. (rev 2) The maximum is now full scale. The fact the user needs from that row is that nothing below full scale catches a mistyped level.
3. Nothing else. The clamp vocabulary (requested/applied, (flat — …), drive_max_dbfs in successful output) describes a state that no longer exists.

what to remove

• render_level_clamp / render_level_clamp_range and their callers. Done on PR fix: unify emission defaults and ceiling #463.
• The level from every header's pipe chain. Done on PR fix: unify emission defaults and ceiling #463.
• drive_max_dbfs as a string in successful output. It stays only in the retired-key refusal and ac setup's retired-key row, where the user has to find the key by name.
• (default: -10dBFS) in the calibrate help row. Done on PR fix: unify emission defaults and ceiling #463.
• ac plot ir's 95-column header. Done on PR fix: unify emission defaults and ceiling #463.
• (rev 1) ac probe's 50-column rule and its loop over the nonexistent ack["ports"]. Done on PR fix: unify emission defaults and ceiling #463.
• (rev 2) Every "−20 dBFS maximum" sentence, and every use of the word "maximum" for the −30 dBFS untyped bound. There are two bounds, and one word must not name both.
• (rev 2) "it limits nothing" on ac setup's retired-key row. It is true, but the Emission max: 0.0 dBFS (full scale, fixed) row directly above already says it. The note's room goes to the fact that row does not carry: every emission is refused until the key is removed.
• (rev 2) "started..." in Hardware test started.... test dut's header is DUT test, and the trailing ellipsis is hedging.
• (rev 2) gpio's "calibration unavailable" line. Rev 3 makes gpio ignore calibration, so the line would explain a fallback that no longer exists.

proposed output

One renderer, one shape, every emitting command. The label field is 9 columns after a 2-column indent, followed by 2 spaces. (rev 2) The dBFS value is right-aligned in 6 columns, so decimals line up down the block whatever the magnitude (-120.0, -40.0, 0.0). dBu, where shown, is right-aligned in 7 with an explicit sign. A dBFS value above zero, which appears only in refusals and in generate's channel table, carries +. 0.0 prints as 0.0.

ac plot ir — nothing typed, uncalibrated:

  No calibration found — levels in dBFS only.

  IR: 20 → 20000 Hz  |  1.0s
  gate       default harmonics, default window, default tail
  level       -40.0 dBFS  (default)
  maximum       0.0 dBFS  (full scale)

ac plot level — nothing typed:

  Plot level: 1000 Hz  |  26 steps
  level       -40.0 → -30.0 dBFS  (default)
  maximum       0.0 dBFS  (full scale)

ac plot 20 20k -30 — typed, calibrated at +19 dBu full scale:

  Loaded calibration from server.

  Plot: 20 → 20000 Hz  8 pts/decade
  level       -30.0 dBFS  =  -11.00 dBu  (typed)
  maximum       0.0 dBFS  =  +19.00 dBu  (full scale)

ac generate sine -6 — typed, uncalibrated. A level far above the untyped bound gets no warning. It was typed, and the ruling is that it plays as typed; (typed) is the whole statement:

  ch   0  1000 Hz               -  -6.0 dBFS (uncal)
  level        -6.0 dBFS  (typed)
  maximum       0.0 dBFS  (full scale)
  -> system:playback_1

  Playing 1 channel(s)... Ctrl+C or q to stop.

ac generate sine — calibrated. The per-channel table already carries Vrms and dBu, so the level rows stay dBFS-only:

  ch   0  1000 Hz     69.04 mVrms  -21.00 dBu
  level       -40.0 dBFS  (default)
  maximum       0.0 dBFS  (full scale)
  -> system:playback_1

  Playing 1 channel(s)... Ctrl+C or q to stop.

(rev 2) ac generate sine 1dbfs — typed, refused. The level block prints only for emission that happened:

  ch   0  1000 Hz               -  +1.0 dBFS (uncal)
  error: level +1.0 dBFS is above full scale (0.0 dBFS)
         nothing was emitted

(rev 2) ac plot level -40 3 — ramp refused:

  Plot level: 1000 Hz  |  26 steps

  error: stop level +3.0 dBFS is above full scale (0.0 dBFS)
         nothing was emitted

(rev 2) ac probe — level fixed in the build:

  Port probe: 8 playback, 18 capture ports
  level       -30.0 dBFS  (fixed)
  maximum       0.0 dBFS  (full scale)

The row stays dBFS-only even when calibrated. probe plays on every playback port in turn, and one calibration describes one output. (rev 2: the rev-1 zero-headroom paragraph is withdrawn.)

(rev 2) ac test dut — nothing typed. Needs the ladder span on the test_dut ack; see open question 1:

  DUT test
  level       -40.0 dBFS  (default)
  ladder      -40.0 → -30.0 dBFS  (fixed)
  maximum       0.0 dBFS  (full scale)

(rev 2) ac test dut -50 — typed below the ladder. Here the ladder row is the only line that shows the run's loudest tone, 20 dB above what was typed:

  DUT test
  level       -50.0 dBFS  (typed)
  ladder      -40.0 → -30.0 dBFS  (fixed)
  maximum       0.0 dBFS  (full scale)

(rev 2) ac test hardware — needs level_dbfs and the ladder span on the test_hardware ack; see open question 1. Same shape as test dut, so both self-tests read alike:

  Hardware test
  level       -30.0 dBFS  (fixed)
  ladder      -42.0 → -30.0 dBFS  (fixed)
  maximum       0.0 dBFS  (full scale)

Against a daemon whose ack lacks any of these fields, that row prints (not reported by this daemon), exactly as maximum does. The CLI never fills in the ladder from its own build.

Against a daemon whose ack carries no max_dbfs. The CLI must never substitute its own compiled constant, because the daemon may be another build on another host:

  level       -40.0 dBFS  (default)
  maximum    (not reported by this daemon)

(rev 1) The same rule covers a probe ack without level_dbfs. An older daemon plays −10 dBFS.

(rev 2) Retired key present in config, on any emitting command (probe and test hardware included):

  error: drive_max_dbfs -10.0 no longer limits emission
         typed levels play exactly as typed, up to 0.0 dBFS (full scale)
         remove it from /home/mui/.config/ac/config.json
         nothing was emitted

(rev 2) ac setup, retired key present. Values start in column 18, as on every other row at setup.rs:150–207:

  Range:         20 – 20000 Hz
  Emission max:  0.0 dBFS  (full scale, fixed)
  Retired key:   drive_max_dbfs -10.0  (every emission refused until removed)

ac setup with no retired key prints the Emission max: row alone.

(rev 2) Self-test detail text, composed daemon-side. It reaches the wire, not stdout (open question 3):

  [PASS]  Level linearity     [-42→-36:0.02, -36→-30:0.01]  (4 of 7 points not run: above -30.0 dBFS, the limit for untyped levels)
  [PASS]  THD floor (1 kHz)   best 0.0021%  [-40:0.0030%, -30:0.0021%]  (3 of 5 points not run: above -30.0 dBFS, the limit for untyped levels)
  [PASS]  DMM level tracking  max error 0.84% over 2 of 2 points read  (5 of 7 points not run: above -30.0 dBFS, the limit for untyped levels)
  [PASS]  THD vs level        best 0.0021%  [...]  (4 of 6 points not run: above -30.0 dBFS, the limit for untyped levels)
  [PASS]  Clipping point      no clipping up to -11.0 dBu  (10 of 11 points not run: above -30.0 dBFS, the limit for untyped levels)

These rows are wider than 80 columns because the existing bracketed per-point lists already are. They are wire strings, not a terminal layout. If a renderer for them lands (open question 3), it wraps the parenthetical onto its own indented line.

(rev 2) ac help footer:

  levels    dBFS, dBu or Vrms — a typed level plays exactly as typed
            maximum 0 dBFS (full scale); above it is refused, not reduced
            default -40 dBFS, ramps -40 → -30 dBFS

(rev 2) gpio, daemon stderr. Same markers, same one-decimal precision as the CLI:

gpio: level=-40.0 dBFS (default)  out_ch=0
gpio: SINE @ -40.0 dBFS (default) ch 0
gpio: PINK @ -40.0 dBFS (default) ch 0

Worst-case width. The longest level row is a calibrated ramp: level -40.0 → -30.0 dBFS = -21.00 → -11.00 dBu (default), 67 columns. Decimal alignment holds on the first dBFS value, the only column the ramp and scalar rows share. The ramp's stop value and its dBu pair are not aligned with maximum's, and cannot be without padding every scalar row out to ramp width. The longest ladder row is 41 columns. The retired-key error's longest line is 72; its path line is bounded by the config path alone. The ac setup retired-key row is 77. The help footer's longest line is 73.

field justifications

• IR: / Plot: / Plot level: / DUT test / Hardware test header: names the measurement and its per-command signal conditions.
• gate (plot ir only): keeps the gate fields off the header, which had reached 95 columns.
• level: the primary value. One label, one format, for every emitting command.
• → in a ramp value: a ramp is one level quantity with two endpoints. start/stop rows would split the quantity the operator asked to unify.
• (default) / (typed) / (fixed): who set the number. All three are always printed. An unmarked row would be ambiguous with an older build that marks nothing.
• maximum: the one maximum, on every emitting run, decimal-aligned with the level so the headroom is read, not computed. (rev 2) It is kept at full scale. The spec requires it; it is how an old clamping daemon shows up (not reported); and calibrated, it says in dBu how loud full scale actually is.
• (rev 2) (full scale): a full-scale maximum is not a safety cap, and this marker is the only place the run's output says so. A user used to −10 or −20 clamps would otherwise read 0.0 dBFS as a chosen limit and trust it to catch a typo. It is printed only when max_dbfs == 0.0, so the CLI never asserts it about a number where it would be false.
• (rev 2) Right-aligned value, width 6: decimal alignment is the primary typographic tool here, and 0.0 under -40.0 is the first case where the widths differ.
• (rev 2) Signed dBu, width 7: +19.00 is above 0 dBu and must not read as a dropped minus. The width aligns -11.00 over +19.00.
• (rev 2) + on a dBFS value above zero: in a refusal, 1.0 dBFS beside 0.0 dBFS reads as a lost minus sign. The + is what makes it read as "above".
• = -11.00 dBu on both rows: when calibrated, dBFS alone does not say how loud. It is suppressed when uncalibrated, when generate's channel table already prints dBu, and on probe.
• (rev 2) ladder (self-tests only): the ladder plays levels the level row does not show, and no typed token reaches them. Without the row, a bare ac test dut prints −40 while playing −30, and -50 prints −50 while playing −30. (fixed) because no token or config moves it. It is on test hardware too, even though its level sits at the ladder's top: both self-tests then have one shape, and the renderer needs no special case.
• (not reported by this daemon): the honest value under version skew, for every row read from an ack.
• nothing was emitted, on every refusal: the fact the operator needs first.
• stop level / start level in a ramp refusal: names which endpoint failed.
• (rev 2) above full scale (0.0 dBFS): states what the bound is, not only its number. "Maximum" had become a word for a limit someone chose.
• (rev 2) Retired-key line 2, typed levels play exactly as typed, up to 0.0 dBFS (full scale): the reason the key refuses at all. Without it the error reads like a migration nag, and a user who set −10 as a cap deletes the key without learning the cap is gone.
• (rev 2) Emission max: … (full scale, fixed): answers "what is max volume" without emitting. fixed stays: no config reaches it.
• (rev 2) Retired key: drive_max_dbfs -10.0: the key name verbatim, so it can be found in the file, under a label that keeps the register's 17-column indent. (every emission refused until removed) is the one consequence that makes the row urgent.
• (rev 2) N of M points not run: the ladders now keep 1 to 3 points of 5 to 11. A bare skipped count hides how little a PASS now covers. 1 of 11 for clipping says the search is a single point.
• (rev 2) above -30.0 dBFS, the limit for untyped levels: names the number and what it is, without the word "maximum". The detail is read on the wire with no help text beside it, so it defines its own term.
• (rev 2) over 2 of 2 points read: the DMM verdict is now "every point that ran was read". A FAIL from one missed read must show 1 of 2, or the row reads as a pass that failed for no reason.
• (rev 2) Help line 1, a typed level plays exactly as typed: the rule the user most needs before their first typed level. Line 2 states the one maximum and its refusal. Line 3 states the defaults. That is a statement about this CLI build, which architect rev 3 allows in help and nowhere else.
• (rev 2) gpio (default): a button press is a level nobody typed. The marker keeps one word for one meaning, including on stderr.

before / after

(rev 2) Before is PR #463 at b72d6349. It was not captured from a run. The only binaries in reach sit in the target directory shared across worktrees (/home/mui/src/ac-wt/target), and nothing ties them to this commit. Each before is the PR's own format string with its values substituted, and where one exists, the exact substring its green it_level_max.rs asserts. Where a before is marked at rev-3 values, it is the same PR code with only architect rev 3's constants changed, which is what the branch prints if the numbers alone are updated.

1. Alignment at full scale (render_level_block):

before (b72d6349, as asserted by it_level_max.rs):
  level      -40.0 dBFS  (default)
  maximum    -20.0 dBFS

before (b72d6349 code, at rev-3 values):
  level      -40.0 dBFS  (default)
  maximum    0.0 dBFS

after:
  level       -40.0 dBFS  (default)
  maximum       0.0 dBFS  (full scale)

2. Calibrated, +19 dBu full scale:

before (b72d6349 code, at rev-3 values):
  level      -30.0 dBFS  =  -11.00 dBu  (typed)
  maximum    0.0 dBFS  =   19.00 dBu

after:
  level       -30.0 dBFS  =  -11.00 dBu  (typed)
  maximum       0.0 dBFS  =  +19.00 dBu  (full scale)

3. Refusal:

before (b72d6349, it_level_max.rs `generate sine 1000hz -19dbfs`):
  error: level -19.0 dBFS is above the maximum -20.0 dBFS
         nothing was emitted

before (b72d6349 code, at rev-3 values, `1dbfs`):
  error: level 1.0 dBFS is above the maximum 0.0 dBFS
         nothing was emitted

after:
  error: level +1.0 dBFS is above full scale (0.0 dBFS)
         nothing was emitted

4. Retired key (PR #463's first line is 112 columns; it is shown as printed):

before (b72d6349):
  error: drive_max_dbfs no longer sets a limit (-10 in config) — remove it from /home/mui/.config/ac/config.json
         the maximum is -20.0 dBFS, fixed in this build — nothing was emitted

after:
  error: drive_max_dbfs -10.0 no longer limits emission
         typed levels play exactly as typed, up to 0.0 dBFS (full scale)
         remove it from /home/mui/.config/ac/config.json
         nothing was emitted

5. ac setup:

before (b72d6349):
  Range:         20 – 20000 Hz
  Emission max:  -20.0 dBFS  (fixed)
  drive_max_dbfs: -10.0  (retired — remove it; it limits nothing)

after:
  Range:         20 – 20000 Hz
  Emission max:  0.0 dBFS  (full scale, fixed)
  Retired key:   drive_max_dbfs -10.0  (every emission refused until removed)

6. ac probe:

before (b72d6349):
  Port probe: 8 playback, 18 capture ports
  level      -20.0 dBFS  (fixed)
  maximum    -20.0 dBFS

after:
  Port probe: 8 playback, 18 capture ports
  level       -30.0 dBFS  (fixed)
  maximum       0.0 dBFS  (full scale)

7. Self-tests:

before (b72d6349):  ac test dut
  DUT test
  level      -40.0 dBFS  (default)
  maximum    -20.0 dBFS

before (b72d6349):  ac test hardware
  Hardware test started...

after:              ac test dut
  DUT test
  level       -40.0 dBFS  (default)
  ladder      -40.0 → -30.0 dBFS  (fixed)
  maximum       0.0 dBFS  (full scale)

after:              ac test hardware
  Hardware test
  level       -30.0 dBFS  (fixed)
  ladder      -42.0 → -30.0 dBFS  (fixed)
  maximum       0.0 dBFS  (full scale)

8. Help footer:

before (b72d6349):
  levels    dBFS, dBu or Vrms; default -40 dBFS, ramps -40 → -30 dBFS
            maximum -20 dBFS in this build — a level above it is refused, not reduced

after:
  levels    dBFS, dBu or Vrms — a typed level plays exactly as typed
            maximum 0 dBFS (full scale); above it is refused, not reduced
            default -40 dBFS, ramps -40 → -30 dBFS

removed:

• every −20 "maximum", and "maximum" as a name for the untyped bound
• "it limits nothing", which the row above already says
• "started..."
• gpio's calibration-fallback line
• (rev 1, stands) the clamp lines, the header level chains and probe's dead port table

added:

• (full scale) on maximum
• + on positive dBFS and on dBu
• the retired-key "typed levels play exactly as typed" line
• ladder rows on both self-tests, pending the wire fields (open question 1)
• N of M and read counts in the self-test details
• (default) on gpio stderr

changed:

• right-aligned values, so decimals align at any magnitude
• refusal text says "full scale"
• Retired key: label keeps ac setup's value column
• the ramp level row reads the ack's echoed endpoints, not the CLI's conversion

Renderer unit tests (commands/mod.rs), in addition to what PR #463 has:

• max_dbfs = 0.0 renders (full scale), and its . falls in the same column as -40.0's. Red case: PR fix: unify emission defaults and ceiling #463's unpadded {v:.1}.
• max_dbfs = -20.0 renders no marker. Red case: a renderer that prints (full scale) unconditionally.
• Calibrated full scale renders +19.00 dBu. Red case: {dbu:6.2}.
• A ramp whose ack echoes endpoints different from what the CLI sent renders the ack's values. Red case: PR fix: unify emission defaults and ceiling #463's print_level_range(start_db, stop_db, …).
• A self-test ack without the ladder fields renders ladder (not reported by this daemon).

open questions

1. (rev 2, blocking the self-test rows only) The ladder span has to be on the wire. Architect's call. The ladder rows need the lowest and highest retained ladder point from the daemon. The architect already ruled that the CLI never prints its own constants as daemon facts, and the ladders are filtered daemon-side. test_hardware also needs level_dbfs (SELF_TEST_LEVEL_DBFS), the same additive field rev 2 gave probe. Proposed, additive, on the test_hardware and test_dut acks: ladder_start_dbfs, ladder_stop_dbfs; on test_hardware, level_dbfs. The names are the architect's. The span is computed from the retained points of every ladder the run will play. Without the DMM, test hardware still spans −42 → −30, from linearity. The alternative is to rule the rows out. Then ac test dut keeps printing a level 10 to 20 dB below its loudest tone, ac test hardware prints no level at all, and both fail the spec's "every emitting command's output states the level used". Every other part of this revision is final and does not depend on the answer. The PR revision can start on it as soon as the label moves.
2. (rev 2) Not proposed: a warning for pink noise typed near full scale. Architect rev 3 notes that pink peaks reach full scale from roughly −9 dBFS while the printed level is the sine-equivalent rms. A CLI warning would print an assumed crest factor as a fact about the signal, and a line that sometimes appears reads as a verdict. A peak-aware refusal or report belongs in its own issue, and its output wording with it.
3. (rev 1, stands) What Stimulus defaults run up to 0 dBFS: plot ir defaults to -6 dBFS, level ramps end at 0 dBFS #459 will not fix: self-test result rows never reach stdout. commands/test.rs renders only measurement/frequency_response/point frames, and nothing in ac-cli/src handles test_result. The skip notes above exist on the wire only. qa should not read their absence on stdout as a Stimulus defaults run up to 0 dBFS: plot ir defaults to -6 dBFS, level ramps end at 0 dBFS #459 failure, and a green Stimulus defaults run up to 0 dBFS: plot ir defaults to -6 dBFS, level ramps end at 0 dBFS #459 does not prove they are visible.
4. (rev 1, stands) Also out of scope: ac probe prints no results. When a renderer for its frames lands, the loopback frame's level_dbfs is a captured level. Label it captured, never level. (rev 2) Its −50 dBFS gate should not be printed as a level either. It is a detection threshold.
5. Not proposed for ac-view, which the operator scoped out.