[tropo1234]

What this fixes

An ANAN-G2 reports no frequency, mode, tuning step or output level of its own, so every connect started from defaults. The client now remembers each one per radio:

	Before	After
Frequency and mode	every session started at 10 MHz	where you left it; 14.175 MHz USB on a first connect
Tuning step	100 Hz once the first slice arrived	where you left it
Radio's own output level (PC Audio off)	reset to 50 every connect	where you left it, including 0
Panadapter dBm range	−50 dBm floor every launch	where you left it, through #6140's store

How

Each value rides a capability the backend declares. None of it is a family check.

• Tuning (ClientSettingsDomain::Tuning, already used by HL2 and RTL). AnanBackend restores frequency and mode before connect. It captures them once per settled tune (applyTuneToRadioAndPan()) and on each mode change. A stored value is refused, not clamped: a mode modeFromString() cannot map, or a frequency at or above the DDS Nyquist (tuningMinHz/MaxHz are not reported, so there is no band edge to clamp to). The two fields are judged separately, so a bad mode does not drop a good frequency.
• Tuning step. It rides the same domain as RestoredRadioState::tuningStepHz, but only where no command plane carries slice set step=. RadioModel follows its CW capture/restore. It restores the step at connect, seeds it into each new slice before sliceAdded, and captures any slice's step change. A radio swap clears it first, so radio A's step never reaches radio B. Steps outside 1 Hz–1 MHz are refused. The flat TuningStepSize key stays as the widget preference it was, and is no longer read back into a slice.
• Radio output level: a new ClientSettingsDomain::ReceiveOutputLevel (bit 9) plus RestoredRadioState::receiveOutputLevelPct. The sentinel is −1, so a speaker silenced on purpose comes back as 0. With nothing stored, the backend keeps its default of 50. The level is seeded into both the backend and RadioModel::lineoutGain(), which is what the slider shows with PC Audio off. Two G2s on one profile keep separate levels. OperatingState schema goes 2 → 3.
• dBm range: ANAN declares PanAmplitudeModel::clientPersistsDbmRange. fix(gui): FFT FPS and the dBm range survive a restart. Principle VIII. #6140's accessors, accept-set and restore do the rest, and this PR adds no dBm code of its own.

Master volume

RadioModel::activeOutputVolumePercent() is now the one rule for the level the operator hears. With PC Audio on it is MasterVolume. With it off it is the radio's line-out gain, on every family, because that is what applyMasterVolume() drives. The volume hotkeys, FlexControl, HID, the wheel, MIDI and TCI all read it. MainWindow and TCI keep no copy of the rule.

applyMasterVolume() now writes MasterVolume only with PC Audio on. A level set for the radio's speaker therefore no longer comes back as the PC level.

Behaviour changes outside ANAN

• HL2 and legacy RTL now remember the tuning step per radio. Icom, settings-active RTL and the demo get nothing, as on main.
• Every family, PC Audio off: the volume nudges step from the line-out level. Moving the slider no longer rewrites MasterVolume. TCI's volume reports the line-out level.
• Flex: the step_up/step_down shortcuts now send slice set N step=, as the STEP buttons already did, and update the RX applet and the toast.
• The PC-Audio toggle re-applies the level on a radio that declares ReceiveOutputLevel (ANAN today). It no longer compares the family string, and the slider now shows the level for the new destination.

Testing

On a6299adb, rebased onto 2e3d7ae7 (#6140); merge-tree clean against 30882701.

• Serial ctest: 657 of 659 pass, with the one deliberate skip. pgxl_panel_test fails here on clean main too. The new radio_model_client_state_test failed on that run because the test never opened its settings store (AppSettings::load()); it was fixed before the push and passes.

• Static checks: all 17 Python gates from static-checks.yml pass with --strict. Command plane is 369, at baseline. Capability booleans are 70, at the frozen 70. The touchpoint manifest is up to date and unchanged by this PR. No colour lines were added.

• 12 mutations, 12 killed, each run against a target that was green beforehand:

  #	Mutation	Goes red
  M1	ANAN stops declaring ReceiveOutputLevel	anan_backend_test
  M2	a level of 0 is not stored	radio_state_memory_test
  M3	an out-of-range level is clamped instead of refused	radio_state_memory_test
  M4	radio B keeps radio A's level	anan_backend_test
  M5	setLineoutGain() stops announcing the change	anan_backend_test
  M6	the capability gate goes back on the volume rule	radio_model_client_state_test
  M7	the restored level is not seeded into the model	radio_model_client_state_test
  M8	the restored step is not seeded into new slices	radio_model_client_state_test
  M9	a step change is not captured	radio_model_client_state_test
  M10	the step-reset on a radio swap is removed	radio_model_client_state_test
  M11	the step is not loaded	radio_state_memory_test
  M12	ANAN declares no dBm-range owner	client_display_pan_settings_test

• ANAN-G2, quit and relaunch: frequency, mode, a 2.5 kHz step, the radio output level with PC Audio off, and the dBm range (the first run of fix(gui): FFT FPS and the dBm range survive a restart. Principle VIII. #6140's restore in the app) all came back. A different DDC0 rate picked in the connect dialog applied. With PC Audio off and the slider at 30, Master Volume Up went 35, then 40.

Limits

• Not mutation-run: the three predicates that live in headers, i.e. fix(gui): FFT FPS and the dBm range survive a restart. Principle VIII. #6140's clientPersistsDbmRange() declaration term (the synthetic case below is its only control now) and the two new isEmpty() terms. Each mutation would rebuild most of aethercore twice. The test rows read those fields directly.
• A downgrade is read-only: after this build writes schema 3, an older build still reads the known fields. It will not overwrite the document (RadioStateMemory's newer-schema rule). That applies to HL2 and RTL operating state as well as ANAN.
• No HL2 or RTL bench for the step. Their path is the same RadioModel code the new test drives with an ANAN backend.

Not in this PR

• The span. The connect dialog's DDC0 rate always wins (maintainer ruling), so a G2 zoom is lost on reconnect, as on main.
• FFT averaging persistence is main's (RTL M1: confirmed receive state, free capture browsing and finer zoom #5924).

🤖 Generated with Claude Code

[aethersdr-agent]

Thanks for this one, @tropo1234 — six real settings-persistence bugs with a mutation per fix and a quit-and-relaunch on actual G2 hardware is more rigour than most PRs get, and the note that two of them were only visible across a process restart is a genuinely useful observation about the limits of the suite.

Only one check is red, and it's a small bookkeeping step rather than anything wrong with the code. (check-windows, check-macos and build were still in progress when I looked, so this is the only known failure.)

What failed

Static checks → aetherd touchpoint manifest (run 37148817719):

::error::aetherd touchpoints require a valid semantic tag: core/AudioOutputVolumePolicy.h

I reproduced it at da7e189c:

$ python tools/gen_touchpoint_manifest.py --check
::error::aetherd touchpoints require a valid semantic tag: core/AudioOutputVolumePolicy.h

The new src/core/AudioOutputVolumePolicy.h is included by five GUI translation units —

src/gui/MainWindow.cpp
src/gui/MainWindow_Wiring.cpp
src/gui/MainWindow_Controllers.cpp
src/gui/MainWindow_Shortcuts.cpp
src/gui/TitleBar.cpp

— so tools/gen_touchpoint_manifest.py counts it as a new gui→engine touchpoint (233 → 234). Every live touchpoint needs an entry in docs/architecture/aetherd-touchpoint-tags.json, and this one has none. git show --stat da7e189c -- docs/architecture/ is empty, so neither the tags file nor the manifest was updated.

How to fix it

Note the order — --check validates tags before it compares the manifest (gen_touchpoint_manifest.py:207-216), so regenerating alone won't clear it:

1. Add the tag entry to docs/architecture/aetherd-touchpoint-tags.json, by hand. The file uses one-space indentation; json.dump(..., indent=2) will reformat all ~2900 lines (I did that by accident). Done right, git diff --stat on that file should be about seven lines:

    "core/AudioOutputVolumePolicy.h": {
     "tag": "<see below>",
     "note": "Which stored level the master slider moves, and the radio-side default; client-side AppSettings policy, no radio state.",
     "split": "",
     "confidence": "high"
    },

2. Regenerate, then verify with the CI form:

   python tools/gen_touchpoint_manifest.py
   python tools/gen_touchpoint_manifest.py --check   # → "manifest up to date"
   

3. Commit both aetherd-touchpoint-tags.json and docs/architecture/aetherd-touchpoints.md.

With a tag added I ran exactly that locally and --check went green; the only manifest change is the totals line and the one new row (core/AppSettings.h's includer count stays at 104, since the new file is a core header, not a GUI one). Worth knowing: the plain generator form writes an untagged row and prints success, which is probably why "eleven ratchets green" didn't catch this — --check is the form that gates.

The tag itself is your call, not a mechanical one

TAG_RE (line 50) accepts universal, ui-support, vendor(x), mixed(x), peripheral(x) — any of them clears CI, so please don't just take my placeholder. The nearest precedents are both ui-support:

• core/AppSettings.h — "Client-side XML settings store … app plumbing, not radio state"
• core/AudioOutputRouter.h — "Registry fanning the user-selected QAudioDevice to local playback sinks … no radio state"

which fits the header well. The thing that makes it a judgment call is separatesRadioOutputLevel()'s family.compare(QLatin1String("anan")) — family knowledge inside a core/ header, which could argue for mixed(anan) instead. Your header comment already makes the case that the condition is "who owns the level" rather than "which vendor", so you may well have the better read; worth one line in the PR body either way.

One thing for the PR body

docs/aetherd-agents-md-staging.md:111 treats a new gui→engine touchpoint as a maintainer decision (RFC §2) rather than something to add in passing. I don't think the header can go anywhere else — src/core/TciProtocol.cpp and src/core/DeviceDiagnostics.cpp include it too, so it can't live under gui/, and the single-spelling-of-the-test argument in your comment is a good one. But it's worth saying so explicitly in the description and noting the 233 → 234 bump, the way #6008 did for its peripheral validation header, so the maintainer isn't inferring the decision from a manifest diff.

No Copilot or reviewer comments on the PR yet, and nothing here is CI infrastructure — the check is behaving correctly, it just hasn't been fed the new header's tag.

---

_{🤖 aethersdr-agent · cost: $4.3810 · model: claude-opus-5}

[aethersdr-agent]

1. Issue fit

There is no linked issue — no Fixes/Closes #NNNN in the body — so I reviewed against the PR's own stated intent. GOVERNANCE.md wants an RFC for architectural changes and explicitly does not require an issue for a bug fix with a clear root cause; this is a feat( PR bundling five client-persistence fixes plus a new core/ header and a new gui→engine touchpoint, which sits closer to the RFC side of that line. The author pre-flags the touchpoint as a maintainer call, which is the right instinct — see §5 below.

Against its own spec the PR delivers all six rows of its table. The five restore paths are real, the validation is refuse-not-clamp as claimed, and the "restore before the push" ordering in wirePanDisplayStatus() is genuinely placed where the comment says. But two of them are implemented against a family string rather than a declared capability, and canon has a sentence about exactly that. Details in Blockers.

2. Scope

File / group	What it changes	Claimed?	Verdict
core/AudioOutputVolumePolicy.h (new)	PC-vs-radio volume key/default selectors + family predicate	Yes, incl. self-flagged touchpoint	New gui→engine touchpoint + new flat settings key → maintainer decision; see Blockers 1–2
core/ClientDisplaySettings.h	FFT averaging + dBm range accessors, shared readInt/writeInt/loadForWrite/store	Yes	In scope
core/DeviceDiagnostics.cpp	Two snapshots gain radio_output_volume_pct	Implied	In scope (see nit)
core/TciProtocol.cpp	Init burst + volume GET read the active sink	Implied	In scope
backends/anan/*	Tuning + SpanRate domains, accept-lists, first-connect defaults	Yes	In scope; the 10 MHz → 14.175 MHz default change is disclosed → maintainer decision
gui/MainWindow*.cpp/.h	Volume key routing, connect-time lineout push, applyOperatorTuningStep() extraction	Yes	In scope
gui/MainWindow_Wiring.cpp	Step seeding on onSliceAdded, display restore, dBm/avg saves	Yes	In scope
gui/SpectrumOverlayMenu.*, gui/TitleBar.cpp	Signal-blocked setters, PC-key read at construction	Yes	In scope
gui/MainWindow_Session.cpp:1763, MainWindow_Wiring.cpp:3015	Blank line only	No	Nit — unrelated whitespace churn
tests/*, tests.cmake, docs/architecture/*	New targets + manifest rows	Yes	In scope; registration verified

Everything else in the diff is explained by the PR's stated intent. No CHANGELOG.md entry was added — correct. No socket tests added or removed; anan_backend_test's new --restore-check arm re-executes the test binary as a child process to prove disk persistence, which is a process boundary, not a socket.

3. Blockers

1. separatesRadioOutputLevel() is a family check deciding persistence, where canon requires a declared capability. (inline: AudioOutputVolumePolicy.h:52)

docs/agents/settings.md:143-145, under Settings Authority Policy:

The deciding test is whether THIS radio can save and restore the value — a declared capability, not a family assumption

return family.compare(QLatin1String("anan"), Qt::CaseInsensitive) == 0; is a family assumption, in a core/ header, selecting which key a setting persists under. The header comment argues the condition is "who owns the level" rather than "which vendor" — I agree that is the right question, and that is exactly why it should be a declared answer. This same PR gets it right three lines of diff away: clientSettingsDomains |= Tuning | SpanRate in AnanBackend::capabilities(). The dBm-range and averaging restores also gate correctly on radioOwnsDbmScale / backendPanAveraging. Only the volume split reaches for the string.

Fix: a RadioCapabilities field — clientOwnsReceiveOutputLevel, or an std::optional<ReceiveOutputLevelControl> record if you want the default value to travel with it. Note for the ratchet: an std::optional<…Control> record needs no FROZEN_BOOL_COUNT ruling, while a bare bool grows the count. The pre-existing family compare in MainWindow.cpp's PC-Audio toggle handler doesn't license a new one in core/.

2. RadioSpeakerVolume is a flat, app-global key holding per-radio state. (inline: AudioOutputVolumePolicy.h:33)

Same section of docs/agents/settings.md:150-154:

On a radio that persists nothing and declares so (HL2 today): the client IS the radio's memory — for exactly the declared domains, persisted ONLY through RadioStateMemory's OperatingState document. Never in flat AppSettings keys, never via ad-hoc code paths.

That is precisely the case the PR body makes for this value ("this client originates that audio and the radio has no output-level register"). MasterVolume is legitimately flat because the PC sink is app-global; RadioSpeakerVolume is not — it is one radio's output level. Concrete consequence, from the code rather than a bench run: two ANAN G2s on one profile share a single output level, and the first one connected writes the other's. Every other value in this PR is scoped per radio through RadioSettingsScope / RadioStateMemory, which makes this one the odd member of its own change.

Fix: carry it in the OperatingState document under its own declared domain, the way RfGain already rides in state.extension. That also dissolves Blocker 1 — the domain flag is the declared capability.

4. Nits (non-blocking)

• The weighted-average save and restore use different gates (inline, MainWindow_Wiring.cpp:4564, with a suggestion). Save fires whenever requestLocalPanWeightedAverage() returns true, which is any non-Flex backend (RadioModel.cpp:6102 → shapesDisplayRatesLocally() → m_flexBackend == nullptr). Restore gates on backendPanAveraging.has_value(), which is ANAN and HL2 only. On Icom, RTL-SDR and the demo the flag is written to the per-radio document and never read back — a dead write. The sibling saveFftAverage() eight lines up already uses the capability gate.
• radio_output_volume_pct is emitted unconditionally (DeviceDiagnostics.cpp:331, :430) but reads a key nothing writes on Flex, so every Flex support bundle will report 0 — which reads as a muted radio to whoever is triaging it. Gate it on the same predicate, or omit the field when it doesn't apply.
• A zoom alone never arms the SpanRate capture. The body calls the live span "the whole point", and beginRateChange() (AnanBackend.cpp:1080) is the function a zoom moves it through — but the three emit operatingStateChanged() sites are setSliceMode, the attenuation setter, and applyTuneToRadioAndPan. A zoom followed by a clean quit is still captured by the disconnect flush, so the bench run would not show this; a zoom followed by a kill or crash loses the span. One line in beginRateChange().
• RadioSetupDialog.cpp:4759 is a second writer to the same radio output level (m_model->setLineoutGain(v)) and knows nothing about RadioSpeakerVolume. After this change, a level set there is silently replaced at the next connect by the stored value — default 0. Not a new loss (it previously reverted to the backend's 100), but the new destination is silent, and the two surfaces now disagree about who owns the number. Folding the level into the capability/domain from Blockers 1–2 would give both surfaces one writer.
• With PC Audio on — the shipped default — the master slider cannot reach the radio output at all (applyMasterVolume() is strictly either/or), while the connect handler now pushes it to 0. Radio Setup is the only route. Worth a sentence in the body so the first G2 operator who files "my radio speaker went silent after updating" gets the answer from the release note.
• dbmRange() validates ordering in double but returns float (ClientDisplaySettings.h:132-137) — two ordered doubles within float epsilon pass lo < hi and collapse to min == max, the empty scale the comment at :130 exists to prevent. AetherSDR's own writer compares floats so it cannot produce such a pair; only a hand-edited document can. Correctness note, not a security issue. (Surfaced by security-audit (CodeGuard) and confirmed against the file.)
• The dBm-range and averaging persistence is not ANAN-only. Both gate on capabilities (radioOwnsDbmScale, backendPanAveraging), so HL2, RTL-SDR and the demo get them too. That is the correct shape per Principle III — but the body frames the whole change as a G2 fix, and the bench evidence is G2-only. Worth stating which other families this lands on.
• Two whitespace-only hunks (MainWindow_Session.cpp:1763, MainWindow_Wiring.cpp:3015).

Needs maintainer decision

• New gui→engine touchpoint (core/AudioOutputVolumePolicy.h, 5 GUI includers, manifest 235 → 236). Self-flagged by the author with both alternatives spelled out. Resolving Blockers 1–2 likely removes the header entirely, so this may be moot.
• First-connect default 10 MHz → 14.175 MHz (inline, AnanBackend.h:120). Disclosed in both the body and the commit message, and the WWV-as-diagnostic-default argument is a reasonable one — but it is a user-visible default change with no issue citing the old default as a defect, which per GOVERNANCE.md is your call rather than the contributor's.

5. What I tried to break (and could not)

Findings below are reasoned from the head checkout at /tmp/aetherclaude/pr-6129; I have no build and ran nothing. The ${PR_DIFF} strings in the task's diff where & belongs are a harness artifact, not source corruption — the real file is fine.

• "A rejected document leaks the previous radio's dial onto the next radio." No: RadioModel.cpp:660 calls applyRestoredState() unconditionally, with the comment saying why, and AnanBackend::applyRestoredState() assigns all three sentinels unconditionally. Radio A's dial cannot survive a swap to radio B.
• "The restore is overwritten by the reclaimed-pan block 15 lines later." No: PanadapterModel initialises m_average{-1} and m_weightedAverageKnown{false}, so pan->average() >= 0 is false on a fresh pan, and on a reclaimed one the live value legitimately wins.
• "The restore seeds the widget but not the pan stream" — the drag handler calls both sw->setDbmRange() and setStreamDbmRange(), the restore only the first. Harmless: m_panStream is assigned only from flex->panStream() (RadioModel.cpp:832), and the restore is gated on !radioOwnsDbmScale, so on every family that reaches it the stream is null.
• "TCI volume GET and SET now read and write different keys." No: the SET branch sets m_pendingMasterVolume → TciServer:1559 masterVolumeRequested → MainWindow applyMasterVolume(), which writes through the same volumeKey(). GET and SET stay symmetric, including the dB round-trip echo.
• "family() goes empty on disconnect, so a slider nudge while disconnected writes the radio level into the PC key." No: m_family is assigned at connect and at backend injection and is never cleared, so the key stays correct across a disconnect.
• Missing transitive includes — std::isfinite, std::find, std::numeric_limits are all covered: <cmath>, <algorithm> and <limits> are present in both AnanBackend.cpp and the test. No Linux-only compile break of the usual shape.
• The restore tests are not self-confirming. isRestorableFrequencyHz is pinned at 0.0, negative, exactly Nyquist, 200 MHz, NaN and infinity, and isKnownModeString has a negative case; emptying either guard turns those red. audio_output_volume_policy_test does assert separatesRadioOutputLevel("anan") true and ("flex") false, so the "disable the output-level split" mutation claim is credible.
• Where I could not test: the "found on the bench, not by the suite" claims — the dBm restore-ordering race and the step-seeding overwrite — are the author's; I confirmed the code now sits where the comments say, not that the bench run happened. The MainWindow call sites have no test target at all, which is why Blockers 1–2 matter more than they otherwise would: nothing would catch a regression there. CI is green on all 5 checks at bb459020, but per ci.yml that is an -R-filtered subset, not the 621-test suite the body cites.

6. Recommendation

Request changes — on Blockers 1 and 2 only, and they are one fix. Moving the radio output level into a declared capability + the OperatingState document resolves both canon citations, dissolves the two-G2 collision, gives RadioSetupDialog and the master slider a single writer, and very likely removes the new touchpoint that the author asked you to rule on. Everything else in this PR is solid work: the refuse-don't-clamp validation is exactly what Principle VII asks for, the restore-before-push ordering is correctly placed and correctly explained, and the limits section is honest about what the bench did and did not prove.

Next step for the contributor: add the capability (an std::optional<…Control> record keeps the ratchet flat), route the level through RestoredRadioState, then re-run the nine mutations — the "disable the output-level split" one will need rewriting against the new gate. The nits can ride along in the same push.

Thanks for the unusually clear write-up — flagging the touchpoint yourself rather than burying it, and separating "measured" from "reasoned", made this much faster to review.

---

_{🤖 aethersdr-agent · cost: $16.5334 · model: claude-opus-5}

[ten9876]

Review of 04762258

Issue fit. No linked issue, so I reviewed this against the PR's own intent: ANAN-G2 state the client has to remember because the radio can't. The capability-shaped part is well built. Tuning, SpanRate and the new ReceiveOutputLevel domain all go through RadioStateMemory's OperatingState document. That resolves both blockers from the earlier automated review on bb459020 (AudioOutputVolumePolicy.h and the flat RadioSpeakerVolume key are both gone). The refuse-don't-clamp validation holds up. Four things stop it merging: a registered test fails at this head, Static checks is red, the volume rework breaks hotkey/controller volume with PC Audio off on every radio that doesn't declare the new domain (reproduced below), and the PR body describes an earlier version of the code.

Scope

File / group	What it changes	Claimed?	Verdict
backends/anan/AnanBackend.{h,cpp}	Tuning + SpanRate + ReceiveOutputLevel domains, accept-lists, capture emits, first-connect default	Yes	In scope. The 10 MHz → 14.175 MHz USB default needs a maintainer decision (below)
RadioCapabilities.h, RestoredRadioState.h, RadioStateMemory.{h,cpp}	New ReceiveOutputLevel = 1u << 9 domain, schema 2 → 3	No. The body still describes a flat key plus a family predicate	In scope for the code, but undisclosed. See Blocker 4
models/RadioModel.cpp	Seeds m_lineoutGain from the restored level	No	In scope, no test (nit)
gui/MainWindow*.cpp/.h, TitleBar.cpp, core/TciProtocol.cpp	activeOutputVolumePercent(); MasterVolume written only with PC Audio on	Partly	Regression, Blocker 3
gui/MainWindow.cpp → MainWindow_Controllers.cpp	Step handler extracted to applyOperatorTuningStep(), moved to another TU	Yes	Trips the command-plane ratchet, Blocker 2
gui/MainWindow_Shortcuts.cpp	step_up/step_down now push to the slice, persist and toast	Yes	Also lands on Flex (now sends slice set N step=). Probably a fix, but the body frames everything as ANAN-only (nit)
gui/MainWindow_Wiring.cpp	Step seeding on onSliceAdded; dBm-range restore/save	Yes	In scope. The dBm range also lands on Icom (radioOwnsDbmScale=false), and step seeding on every radio with no command plane. Both undisclosed (nit). Step seeding needs a maintainer decision (below)
core/ClientDisplaySettings.h + test	dbmRange/saveDbmRange, loadForWrite/store	Yes	In scope
gui/SpectrumOverlayMenu.{h,cpp}	setFftAverage() / setFftWeightedAverage()	Implied by the "FFT averaging" row	Dead code. Nothing calls either (nit)
core/DeviceDiagnostics.cpp:325-334, 427-432	Comment plus reformat, no behaviour change	No	Churn (nit)
docs/architecture/aetherd-touchpoint*	Note text for ClientDisplaySettings.h	Yes	Fine. --check reports "manifest up to date"

The body's "FFT averaging: reset to off every launch → where you left it" row is not this PR. ClientDisplaySettings::fftAverage()/saveFftAverage() were already on main from #5924 (a325fb99e), and this diff adds no averaging persistence.

Blockers

1. anan_backend_test fails at this head. See tests/anan_backend_test.cpp:184-189. AnanBackend::capabilities() (AnanBackend.cpp:487-491) now declares RfGain | Tuning | SpanRate | ReceiveOutputLevel, but the test asserts exact equality with the first three:

$ ctest -R '^anan_backend_test$' --output-on-failure
FAIL: RF gain, tuning AND span restore are declared -- this radio reports no frequency, mode or span, so the client is its only memory

CI doesn't run this target (ci.yml is -R-filtered), so the green build doesn't cover it. The body's "621/621" was measured on c7513e12, not this head. Fix:

        check(c.clientSettingsDomains
                  == (RadioCapabilities::ClientSettingsDomain::RfGain
                      | RadioCapabilities::ClientSettingsDomain::Tuning
                      | RadioCapabilities::ClientSettingsDomain::SpanRate
                      | RadioCapabilities::ClientSettingsDomain::ReceiveOutputLevel),
              "RF gain, tuning, span AND radio output level restore are declared -- "
              "this radio reports none of them, so the client is its only memory");

2. Static checks is red on the command-plane ratchet. See src/gui/MainWindow_Controllers.cpp:3341. Moving the step handler out of MainWindow.cpp carries its slice set %1 step= wire string to another file:

::error file=src/gui/MainWindow_Controllers.cpp,title=command-plane-ratchet::src/gui/MainWindow_Controllers.cpp grew from 4 to 5 raw Flex command(s) above the seam. This baseline may only shrink (#5262 M4).
::notice ... src/gui/MainWindow.cpp is down to 15 from 16

I reproduced this locally with python3 tools/check_command_plane.py. The baseline is per file, so a lateral move counts as growth. Simplest fix: define applyOperatorTuningStep() in MainWindow.cpp, where the code came from. The comment at :3336-3340 gives merge-conflict avoidance as the reason for the move. That reason belongs in the commit message, not in the source. (The other red step in that job, gh pr comment … Resource not accessible by integration, is the fork token's permissions, not this PR.)

3. Regression: with PC Audio off, hotkey, FlexControl, HID and wheel volume jump to, and stick at, the PC level on every radio that doesn't declare ReceiveOutputLevel (Flex, Demo, HL2, Icom, RTL).

• applyMasterVolume() (MainWindow.cpp:7471) now writes MasterVolume only when PC Audio is on.
• activeOutputVolumePercent() (MainWindow_Controllers.cpp:3366-3376) reads the radio level only for a ReceiveOutputLevel radio. Everywhere else it falls back to MasterVolume, which no longer tracks the slider in that mode.
• So every +/-5 starts from the stale PC level and pushes the result to mixer lineout gain.

Reproduced through the automation bridge against the built-in demo (DEMO-0001, isolated settings, offscreen). The same steps on the merge base 5fae7003 and on this head:

step                                   merge base 5fae7003     PR head 04762258
invoke "Master volume" setValue 60     vol 60  (PC on)         vol 60  (PC on)
invoke "PC Audio" click                vol 50  (PC off)        vol 50  (PC off)
invoke "Master volume" setValue 30     vol 30                  vol 30
shortcut master_volume_up              vol 35                  vol 65
shortcut master_volume_up              vol 40                  vol 65   <- stuck at MasterVolume+5

On a Flex that is a +35 jump on the radio's line out from one key press, and "up" can never go past 65. The same read sits in handleFlexControlButton (:563, :569), dispatchHidAction (:1106, :1111), applyFlexControlWheelAction (:1523) and the master_volume_up/down shortcuts (MainWindow_Shortcuts.cpp:1304, :1311). syncTitleBarOutput() (MainWindow.cpp:7442-7454) and your own TCI copy (TciProtocol.cpp:34-45) already use the right rule, with no capability gate. Make this one match:

int MainWindow::activeOutputVolumePercent() const
{
    const bool pcAudio = AppSettings::instance()
                             .value("PcAudioEnabled", "True").toString() == "True";
    if (!pcAudio)
        return m_radioModel.lineoutGain();
    return AppSettings::instance()
        .value(QStringLiteral("MasterVolume"), QStringLiteral("100")).toInt();
}

That matches what applyMasterVolume() actually drives (setLineoutGain() whenever PC Audio is off, on any family). Please also add a socket-free test of the selector, so this can't drift a third time.

4. The PR body describes code that is no longer in the PR. All of these are false at 04762258:

• "defaulting to 0" / "silent until deliberately raised". The code restores kDefaultLineoutGainPercent = 50 (AnanBackend.cpp:546-554), and its own comment argues against 0.
• "Scoped to this family", "no migration from the shared key", and the whole "new gui→engine touchpoint AudioOutputVolumePolicy.h" section, including 233 → 236 and the tag discussion. The header doesn't exist and the touchpoint count is unchanged.
• "Nine mutations". At least two ("disable the output-level split", "restore the 100% default") target removed code.
• The FFT-averaging row (see Scope).
• The actual design, a new ClientSettingsDomain::ReceiveOutputLevel bit plus an OperatingState schema bump 2 → 3, isn't mentioned at all.

The body is what the squash commit and later archaeology will read, and the maintainer is being asked to rule on "two deliberate behaviour changes" that aren't what ships. Please rewrite it against the current diff and re-run the mutations against it.

Needs maintainer decision (@ten9876)

• First-connect default 10 MHz WWV → 14.175 MHz USB (AnanBackend.h:122). This changes a user-visible default. The comment cites "the operator's choice", and no issue calls the old default a defect. A preference, per GOVERNANCE.md. It doesn't block the persistence work and can be split out.
• The stored span beats the connect dialog's anan.ddc0RateKsps picker (AnanBackend.cpp:648). Disclosed and reasoned in the body. Flagging only because the body asks for a ruling.
• Seeding the slice step from the flat TuningStepSize key (MainWindow_Wiring.cpp:1854-1866) on every radio with no command plane. docs/agents/settings.md:150-154: on a radio that persists nothing, client-owned radio state is "persisted ONLY through RadioStateMemory's OperatingState document. Never in flat AppSettings keys, never via ad-hoc code paths." The key predates this PR as a widget preference. What's new is reading it back into SliceModel. It's either a UI preference (fine) or per-radio slice state (should ride the Tuning domain).

Nits (non-blocking)

• SpectrumOverlayMenu.cpp:3098-3114 / .h:164-168: setFftAverage() and setFftWeightedAverage() have no callers (grep -rn finds only SpectrumWidget methods of the same name). Drop them or wire them up.
• Comments that narrate history (AGENTS.md §"Comments"): RadioCapabilities.h:453-458 ("added on main while this branch was open"), MainWindow_Controllers.cpp:3336-3340, MainWindow.cpp:2028 ("This was a family compare until…"), MainWindow.cpp:6530-6536 ("an earlier version of this handler"), and DeviceDiagnostics.cpp:325-331, which explains a field that isn't there. Many new comments also run well past ~5 lines.
• TitleBar.cpp:332-334 says the MainWindow handler is "the only side that knows the radio family". It now gates on a capability.
• RadioCapabilities.h:216 (ADDING A FIELD) asks for the map to be updated. docs/architecture/radio-capabilities-map.md:214 doesn't list ReceiveOutputLevel (it's already missing Cw too).
• RadioModel.cpp:660-677 (seeding m_lineoutGain so the slider shows the restored level with PC Audio off) has no test. This is the #6124 surface.
• The step_up/step_down change now sends slice set N step= to a Flex, persists and toasts. Probably right, but please say so in the body.

What was verified vs. read

• Built and ran anan_backend_test, radio_state_memory_test and client_display_settings_test at the head: one failure, Blocker 1. Mutation: making RadioStateMemory::load() drop receiveOutputLevelPct turns both radio_state_memory_test and anan_backend_test red ("radio A's output level comes back as 35…"), so the new per-radio level tests pin real behaviour.
• Ratchets: check_command_plane.py reproduces the CI error. check_engine_boundary.py gives identical findings on the merge base and the head (only a line number shifts). gen_touchpoint_manifest.py --check is clean.
• Bridge, demo only: the volume regression above on base vs. head. step_up persists TuningStepSize across a relaunch. On the demo the slice's stepHz stays 100 because the demo takes the command-plane branch, so the onSliceAdded seeding path isn't reachable there.
• Could not drive: every ANAN path (restore ordering, the dBm range before wirePanDisplayStatus()'s push, span precedence, first-connect defaults). The demo declares radioOwnsDbmScale=true and no client domains, and there's no G2 here. Those parts are reviewed from the code.
• Attacks that held: a same-family backend reuse can't carry radio A's dial, span or output level onto radio B (applyRestoredState() resets all four unconditionally, and the test pins it). A level of 0 survives as 0, not as "not restored". A bad mode doesn't drop a good frequency. A stored span that isn't one of the six rates is refused, not snapped. The float-collapse dBm pair is refused. The span capture moved to finishRateChange(), so a rolled-back rate is never captured. setLineoutGain() emits only on an actual change.
• CI: all runs on this head were created at 18:16Z, before main moved to 8df6db2f (18:26Z), so the green jobs describe a slightly older merge.

[ten9876]

Maintainer rulings on #6129 (following the review above)

• The tuning step is per-radio state. For radios without a command plane, it should ride the Tuning domain in the OperatingState document, not the flat TuningStepSize key (docs/agents/settings.md:150-154). This is now a blocker.
• First-connect default of 14.175 MHz USB is accepted.
• The span picker wins. When the operator picks a DDC0 rate in the connect dialog, that choice overrides the saved span.
• Blockers 1–4 from the review still stand.

[ten9876]

Maintainer ruling: #6140 owns dbmRanges[pan] and the dbmRange()/saveDbmRange() helpers. Please rebase onto #6140's version, including its accepted range, rather than defining a second copy. This is in addition to the rulings and blockers above.

— Jeremy KK7GWY + Claude

[tropo1234]

@ten9876 the head is now a6299adb, one signed commit, rebased onto #6140 (2e3d7ae7) and merge-tree clean against 30882701. Every blocker, ruling and nit is below, with where it landed. The body is rewritten against this diff.

Blockers

#	Done	Proof
1	anan_backend_test expects RfGain | Tuning | ReceiveOutputLevel. SpanRate left the PR (ruling 3), so your suggested line loses it.	passes in the serial run
2	applyOperatorTuningStep() is defined in MainWindow.cpp again. The merge-avoidance comment is gone.	check_command_plane.py --strict: 369, at baseline
3	Your rule, with no capability gate, now lives in RadioModel::activeOutputVolumePercent(). MainWindow and TCI both call it, so no copy is left to drift.	new socket-free radio_model_client_state_test: no backend and PC Audio off reads the line out. Putting the gate back (M6) turns it red. G2 with PC Audio off: 30 → 35 → 40
4	Body rewritten. The 12 mutations were re-run against this head, each target green beforehand: 12 killed.	table in the body

Rulings

• Step is per-radio. It rides Tuning as RestoredRadioState::tuningStepHz, through RadioModel, following the CW capture/restore. It is restored at connect, seeded into each new slice and captured from any slice's step change. TuningStepSize no longer seeds a slice. ANAN, HL2 and legacy RTL get it; Icom, settings-active RTL and the demo get nothing, as on main. The body says so.
• 14.175 MHz USB is kept.
• Picker wins. SpanRate is out entirely: the domain bit, the restore and its validation, the capture (including the finishRateChange() emit), the tests and the body row. I removed it rather than keeping "the saved span when nothing was picked", because that case never occurs: populateFamilyParams() inserts anan.ddc0RateKsps on every connect path. A G2 zoom is lost on reconnect, as on main.
• fix(gui): FFT FPS and the dBm range survive a restart. Principle VIII. #6140 owns dbmRanges. Our accessors, their tests and both MainWindow_Wiring.cpp hunks are deleted, and that file is now identical to main. ANAN declares clientPersistsDbmRange = true, and its row in client_display_pan_settings_test is flipped. That row was the only "absolute bins, no owner" control, so a synthetic case now sits beside the relative-bins pair. Icom drops out. The G2 relaunch was the first run of fix(gui): FFT FPS and the dBm range survive a restart. Principle VIII. #6140's restore in the app, and the range came back.

Nits

• SpectrumOverlayMenu setters: removed.
• History comments: all five are gone, and every comment the diff adds is trimmed.
• TitleBar.cpp: back to main. Its only changes were that comment and a reformatted read.
• Capabilities map: lists Cw and ReceiveOutputLevel, and notes the step under Tuning.
• RadioModel.cpp level seeding: now tested ("the restored level reaches the model…"; M7 kills it).
• step_up/step_down on a Flex: stated in the body.
• DeviceDiagnostics.cpp: back to main.
• The FFT-averaging row: gone from the body (RTL M1: confirmed receive state, free capture browsing and finer zoom #5924 owns it). The unused #include "TitleBar.h" is also gone.

Bot threads on bb459020

All five can be resolved:

• AudioOutputVolumePolicy.h (two threads): the header was deleted in 04762258.
• DeviceDiagnostics.cpp:331: the file is back to main.
• MainWindow_Wiring.cpp:4564: this PR no longer touches that file. Main's averaging save (RTL M1: confirmed receive state, free capture browsing and finer zoom #5924) has one gate for both halves.
• AnanBackend.h:120: ruled.

Not run

The three header-only mutations: #6140's declaration term, which the synthetic case now guards, and the two new isEmpty() terms. Each would rebuild most of aethercore twice. No HL2 or RTL bench for the step.

[jensenpat]

Review

Reviewed a6299adbd2decbea1792a03580659c3aa96183c6.

Verdict: Approve. The change matches the persistence intent and the maintainer rulings already recorded on this PR: the tuning step rides the Tuning domain, the first-connect default of 14.175 MHz USB is the accepted default, the connect dialog's DDC0 rate wins, and #6140 owns the dBm range. No blockers.

No linked issue. The review is against the PR body plus those rulings.

Scope

Area	Change
ANAN restore	Declares Tuning and ReceiveOutputLevel. Frequency and mode are refused, not clamped, and judged separately. A stored level of 0 is kept. Nothing stored starts at 14.175 MHz USB and output level 50.
RadioModel	Restores, seeds, and captures the client-owned step where there is no command plane. Clears that step on a radio swap. Seeds a stored line-out level into the model. activeOutputVolumePercent() is the level the operator hears, with no capability gate.
Volume surfaces	Hotkeys, FlexControl, HID, the wheel, MIDI, and TCI GET read that helper. applyMasterVolume() writes MasterVolume only while PC Audio is on. The PC Audio toggle re-applies the destination level only when ReceiveOutputLevel is declared.
Schema	OperatingState schema 2 → 3 (tuningStepHz, receiveOutputLevelPct). A newer document stays read-only.
Display	ANAN sets clientPersistsDbmRange. No second dBm store.
Step shortcuts	step_up / step_down send slice set N step= on a command-plane radio and update the RX applet.
Tests	anan_backend_test, radio_state_memory_test, client_display_pan_settings_test, new radio_model_client_state_test.

Out of scope, as ruled: saved span, FFT averaging, and a second dBm implementation.

Prior request for changes

The review on 04762258 is addressed on this head. Persistence is a declared domain, not a family check or a flat key. The volume selector has no capability gate. The step is per radio on Tuning, and TuningStepSize is not read back into the slice. Span restore is gone. dBm accessors are gone. applyOperatorTuningStep() is back in MainWindow.cpp. The body matches this diff.

Verification

CI on this SHA succeeded: build, check-macos, check-windows, Static checks, and Sanitizer option configures. A merge with current main (25de97c35a3493e01839e5a436e128817346dffa, the style-guide commit) is clean. No local rebuild.

radio_model_client_state_test constructs AnanBackend, whose P2Client binds a QUdpSocket only in start(). This test never connects, so it does not bind. It is registered with add_test and no extra socket name. Not run locally; the green CI suite on this SHA is the execution evidence.

Non-blocking

handRestoredStateToBackend() clears m_clientStepHz before loading, and sets m_lineoutGain only when a level was stored. Disconnect already resets the model gain to 50, and that is the path a radio change takes. A same-family connectToRadio() that does not disconnect first would leave the previous radio's level on the slider while the backend falls back to 50.

Follow-up, not a merge prerequisite

The new test pins the restored model level and the step swap. It does not pin the model level across a radio with no stored document. A socket-free case: restore radio A at 35, then radio B with no document, and expect lineoutGain() == 50 without relying on onDisconnected().

Dismissing the request for changes on 0476225. Head a6299ad addresses those blockers and the later maintainer rulings (per-radio Tuning step, span picker wins, dBm range owned by #6140). Approving review is #6129 (review).