[on8st]

Update after review, ea2cf144 (2026-10-05): ownership of the flag is now declared, not inferred. Only the Hermes-Lite 2 declares the client its owner (RadioCapabilities::txWaterfallClientFlag, clientPersistsFlag true). The demo, ANAN, Icom and RTL-SDR declare nothing and keep main's behaviour: the toggle sends the wire text, the model stays false, nothing is stored or restored. That is narrower than this PR was. On the demo, txwaterfall on answers with the radio-echo note again. Full suite at this head: 644 of 645; the one failure is peripheral_auth_dialog_test (#6008), which fails on clean main too. Source line numbers below are main at 85f2a124.

Refs #5678 (HL2 parity; "Show TX in Waterfall", row P30 of our status table). No issue exists for this.

Limits, first

• Nothing was keyed. On an HL2 the toggle now sets the flag. What the waterfall draws during an over on an HL2 has not been seen, and what that radio's receive path reads while it transmits has not been measured. A true model flag shows neither the colour law nor real receive IQ while keyed; the demo cannot key at all.
• The fix has not been seen in a running app. The dead toggle was (2026-10-01, bridge verb, 6 of 6 polls false). The fix is tested socket-free on the real models and dialog.
• It reaches the Hermes-Lite 2 only. The request, the store and the restore are gated on one accessor, RadioCapabilities::clientPersistsShowTxInWaterfall(), which reads a declared per-feature record. Flex, Icom, ANAN, RTL-SDR and the demo leave the record absent. On Icom, ANAN, RTL-SDR and the demo the toggle is as dead as on main. Engaging another family is one declaration, for that family's owner or the maintainer to make.
• Yours to move: the keyed rows take the colour law a Flex's keyed rows use (dbmToWaterfallLevel). On an HL2 they are absolute dB (dBFS under a dBm label); whether the law suits them is unknown until someone keys one.
• Persistence is in the radio's settings document, not a flat key: one optional bool, showTxInWaterfall, in the existing per-radio ClientDisplay feature document. No schema bump. Written and read only where the backend declares the client its owner.

What was wrong on main

On a Flex the flag is the radio's: transmit set show_tx_in_waterfall= tells it, and its transmit status echoes it (FlexBackend.cpp:1193). That echo is the only writer of TransmitModel::showTxInWaterfall().

• The Radio Setup button sends the wire text unconditionally (RadioSetupDialog.cpp:2717), and so does the bridge verb (AutomationServer.cpp:3599).
• A radio with no command plane drops it (RadioModel.cpp:9764) and nothing echoes, so the flag can never become true. The demo has a command plane and no handler for the flag, so nothing echoes there either.
• While keyed, the pane holding the TX passband draws rows only when the flag is true (SpectrumWidget.cpp:8488). With it false that pane's waterfall stands still for the whole over.

There is something to draw: the HL2 mutes its demodulator while keyed and the spectrum keeps running on real IQ (Hl2RxDsp::setAudioMuted).

The change

• RadioModel::requestLocalShowTxInWaterfall(bool), the shape of the existing requestLocalPanWeightedAverage: where the backend declares the client the owner of the flag it applies the flag and returns true; everywhere else it returns false and the caller sends the wire text, which only a Flex answers. No raw command is added above the seam (check_command_plane: 400, baseline 400).
• It writes the model through TransmitModel::applyChanges, the path an echo takes.
• It stores the value per radio, on the same declaration. A disconnect clears the transmit model (TransmitModel.cpp:43) and no status puts the flag back, so RadioModel::onConnected() restores it, on the same declaration.
• The Radio Setup button and the txwaterfall verb ask the model first.
• RadioCapabilities::txWaterfallClientFlag: a new optional per-feature record with one field, clientPersistsFlag (no default). Engaged by the HL2 only. No top-level capability boolean is added (check_capability_records: 70 of 70).

SpectrumWidget is not changed. Default unchanged: off.

Tests

show_tx_in_waterfall_client_flag_test (new, socket-free, real backends): on the real Hl2Backend, request, store per radio, restore on connect, and the bridge verb; on the real Icom, ANAN, RTL-SDR and demo backends, each with a ClientDisplay document that already holds the flag, nothing is restored, the request declines and the document is untouched; the same on a real FlexBackend (the echo still works) and on a backend that engages the record with the field false; the bridge verb's radio-echo note on Flex and on the demo; the store's refusals.

radio_setup_show_tx_waterfall_test (new, production dialog, real backends): on an HL2 a click sets the model and sends no wire text; on an Icom, which declares no owner, and on a Flex the click sends the wire text and the model is not set. No source-text pin.

Fail-before, one build and one run per row, failing checks in the two tests:

mutation	client flag test	dialog test
this branch	0	0
main's behaviour (request declines, connect restores nothing)	11	1 slot
the request does not write the model	5	1 slot
the connect edge does not restore	1	0
the request is taken on a Flex too	4	1 slot (Flex)
the request does not store	3	0
the button sends the wire text unguarded	0	1 slot
the bridge verb skips the local route	2	0
the store ignores who owns the flag on read	1	0
the ownership accessor is true for every backend	40	2 slots
the ownership accessor is false for every backend	15	1 slot

The two accessor rows were measured at ea2cf144, one build and one full run each. The other rows were measured at earlier heads, before the opt-out checks existed, and were not re-run.

Full ctest, macOS, Qt 6.12.0, at ea2cf144: 644 of 645 pass. The one failure is not ours; see below.

Static checks (static-checks.yml, stdin from /dev/null): clean. check_a11y on RadioSetupDialog.cpp: 9 warnings, the same 9 as main, none on lines this PR touches. check_capability_records: 70 booleans, frozen at 70. The steps were run from this branch's static-checks.yml; main's newer check_build_options steps are not on this branch and were not run.

With the open PRs

• RTL M1: confirmed receive state, free capture browsing and finer zoom #5924, fix(gui): NB Blank works on a dBm waterfall row. Principle VIII. #6117 and fix(gui): manual Black Level works on a dBm row. Principle VIII. #6115 are merged and in this branch. aetherd: consolidate slice receive-control routing #5919 is merged into main and is not in this branch.
• fix(gui): FFT FPS and the dBm range survive a restart. Principle VIII. #6140 (open, 7a5ca748) adds its own records to RadioCapabilities.h; a trial merge with this head is clean and the merged header still counts 70 booleans. A trial merge with main 85f2a124 is clean. Neither merge result was built.

Not verified

• Anything keyed; see Limits.
• Linux and Windows at this head. ANAN, Icom and RTL-SDR on a radio: they keep main's behaviour by declaration, checked on their real backends, never connected.
• A running app at this head, the demo included.
• That the main window hands a restored flag to the spectrum widget.

Known red on main: peripheral_auth_dialog_test (#6008) fails on this Mac at ea2cf144 with the diagnostic it prints on clean main at 22507580 (pasted on #6134): "Clear code or Status is clipped at the default dialog size", dialog 960x680, viewport 658, page minimum 784, horizontal scroll max 126 (a serial-port name on this host widens the page). Clean main was not re-run at 85f2a124. hl2_pan_create_async_test and vkamp_connection_test passed here.

73, ON8ST

🤖 Generated with Claude Code

[aethersdr-agent]

Thanks for this one — the write-up is unusually easy to review against, and the limits section up front saved me a lot of guessing. The red check is a one-line CMake omission, not a problem with the change itself.

Up front: I could not read the raw build log. My gh token is expired (401) and the log tool returned step names only, so everything below is from the tree at 0ff1da30 plus what the three jobs tell us. I'd rather say that than paraphrase a log I didn't see.

What the jobs say

job	scope	result
check-windows	subset only — --target AetherSDR aether-dv-waveform thumbdv_queue_test dstar_model_test digital_voice_waveform_process_test cross_needle_meter_test (ci.yml)	✅ pass
check-macos	whole tree (cmake --build build -j…)	❌ Build
build (Linux)	whole tree	❌

Windows passing is the useful signal: it builds every production file you touched and never builds either new test target. So RadioModel.cpp, RadioSetupDialog.cpp, AutomationServer.cpp and ClientDisplaySettings.h are fine as written — MSVC compiled all of them. The only things macOS and Linux build that Windows doesn't are your two new test targets.

I also ran clang++ -fsyntax-only over both new test sources and all three changed production sources locally (Homebrew Qt 6.11, not CI's 6.12): clean, with the dialog test stopping only at its .moc include, which is expected without a build tree. So this isn't a compile error.

The cause

show_tx_in_waterfall_client_flag_test constructs the production bridge — AutomationServer bridge; at lines 178 and 196 — but its link line is:

target_link_libraries(show_tx_in_waterfall_client_flag_test PRIVATE
    aethercore Qt6::Core Qt6::Network Qt6::Widgets)

AutomationServer.cpp is not in aethercore. It lives in aetherdesktop_support (CMakeLists.txt:1591-1598), and handleLine is out-of-line (AutomationServer.h:309), as are the ctor/dtor and the moc'd metaobject. So expect the log to end in Undefined symbols for architecture arm64: "AetherSDR::AutomationServer::AutomationServer()" (and handleLine, staticMetaObject) on macOS, and the undefined reference to equivalent on Linux.

The tell is in your own cmake comment: "Qt6::Widgets for AutomationServer." The dependency was spotted — it's just that Qt6::Widgets isn't what carries the bridge; aetherdesktop_support is, and it already brings Qt6::Widgets and aethercore with it (PUBLIC).

The fix

tests/tests.cmake keeps a registry for exactly this, with a comment that reads like it was written for this failure:

AutomationServer is desktop support, not engine code. Keep every test that instantiates the production bridge linked through the same desktop-only library as AetherSDR so moving QtWidgets out of aethercore cannot silently leave these harnesses with unresolved bridge symbols.

Add one line to AETHER_AUTOMATION_SERVER_TESTS:

 set(AETHER_AUTOMATION_SERVER_TESTS
     ...
     reroute_dead_controls_test
+    show_tx_in_waterfall_client_flag_test
 )

That's how automation_persist_diagnostics_test and automation_boundary_core_test work — they also declare only aethercore Qt6::Core Qt6::Network on their own line and pick up aetherdesktop_support from the foreach at the bottom. Appending aetherdesktop_support to your target's own link line also works, but the registry is the convention here and is the thing that survives the next library reshuffle.

radio_setup_show_tx_waterfall_test is already correct — it links aetherdesktop_support directly, and its source list matches radio_setup_recording_mode_dim_test exactly.

To confirm in ten seconds:

cmake --build build --target show_tx_in_waterfall_client_flag_test

One thing I can't reconcile: the PR body reports a full ctest at this head and a mutation table with "one build and one run per row." If that target linked on your Mac I'd be interested in the link line, because by the CMake above it shouldn't. The likeliest story is that the bridge-verb section of the test landed after the last full configure+build, and a stale build dir carried it. Nothing else in the diff looks CI-relevant: Static checks and the sanitizer configures are both green, and the command-plane ratchet held at 400.

No Copilot or reviewer comments on the PR yet, so nothing from that side feeding into this.

---

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

[aethersdr-agent]

Issue fit

Yes. No issue is linked — the body says so plainly ("Refs #5678 … No issue exists for this"), and GOVERNANCE.md explicitly exempts a bug fix with a clear root cause from needing one first. The root cause is stated and checkable: on a radio with no command plane the wire text is dropped (RadioModel.cpp:9735) and the only writer of TransmitModel::showTxInWaterfall() is the Flex transmit-status echo (FlexBackend.cpp:1098), so the flag could never become true and the gate at SpectrumWidget.cpp:8416 (txAffectsPan && m_showTxInWaterfall) could never open. All three surfaces that set the flag — the Radio Setup button, the txwaterfall verb, and now the connect edge — are fixed together; the two that only read it (AutomationServer.cpp:1903 get transmit, RadioModel.cpp:12845 troubleshooting dump) read the model and need no change. No sibling surface is left behind.

Test layer is right: this is model/state-machine and refusal behaviour, so socket-free CTests are the correct layer and that is what was added. No fake radio peer anywhere.

Scope

File(s)	What it changes	Claimed?	Verdict
src/models/RadioModel.{h,cpp}	requestLocalShowTxInWaterfall, restoreClientShowTxInWaterfall, the onConnected() call	yes	in scope
src/core/ClientDisplaySettings.h	read/write of one optional bool in the existing v1 ClientDisplay document	yes	in scope
src/gui/RadioSetupDialog.cpp	the button asks the model first	yes	in scope
src/core/AutomationServer.cpp	the verb asks the model first; comment rewritten	yes	in scope
tests/*_test.cpp, tests/tests.cmake	two new registered targets	yes	in scope
docs/HERMES.md §15.3.1, docs/automation-bridge.md	documents the new client-flag behaviour	yes	in scope

Everything in the diff is explained by the stated fix. Specifically checked and clean:

• No CHANGELOG.md entry — correct; it must not be added in an ordinary PR.
• No new public surface. txwaterfall already existed; only the response note differs on the new branch, and the response keys (ok, txwaterfall, note) are unchanged in shape.
• New persisted key, no new document. showTxInWaterfall goes inside the existing versioned ClientDisplay feature document under RadioModel::settingsScope(), one owner (ClientDisplaySettings), no schema bump — Constitution V satisfied, and the body discloses it. No flat key.
• No deleted guard. The one removed comment (AutomationServer.cpp) named a use for the flag, not a symptom; the #3646/#3804 refs survive.
• Default unchanged (off), and no UI restyle or reorder rides along — this is a fix for a dead control, not a preference. The dead toggle was observed (6 of 6 bridge polls false, 2026-10-01).
• No dead additions. Both targets are add_test-registered and joined AETHER_SETTINGS_CONSUMERS; the dialog block is shape-identical to its sibling radio_setup_recording_mode_dim_test.
• No socket test added or removed. Neither new test touches QTcpSocket/QUdpSocket/QLocalServer/bind/listen/connectToHost; AutomationServer's constructor does not listen (AutomationServer.cpp:2269-2272) and the test drives handleLine() directly. Nothing to surface here.

Security audit (CodeGuard): no findings. I re-checked the two leads that mattered — the Flex fallback formats a bool (.arg(on ? 1 : 0)), so no operator text reaches sendCommand; and the verb is absent from kSafe, so the observe-only gate refuses it by default-deny, which is the right direction for a verb that writes persistent settings.

Blockers

None.

Nits

All non-blocking.

1. The enumeration omits the demo simulator. docs/automation-bridge.md:3005 and the PR body both list "Hermes-Lite 2, ANAN, Icom, RTL-SDR", but the gate is shapesDisplayRatesLocally() = m_backend != nullptr && m_flexBackend == nullptr, and SimBackend : public IRadioBackend with m_flexBackend = nullptr; // no Flex alias in demo mode (RadioModel.cpp:858). So sim takes the local route too. That is almost certainly the behaviour you want — I found no show_tx_in_waterfall handling anywhere in src/core/backends/sim/ or the synthetic connect path, so the toggle was equally dead there and this fixes it — but the demo radio is the surface reviewers and radiocert drive most, and it is the one family in scope with a live command plane. Worth adding to the sentence. Inline on the doc line.

2. The restored flag's path to the renderer is the one link nothing covered. Two paths seed SpectrumWidget: onSliceAdded (MainWindow_Wiring.cpp:1932-1935) and syncShowTxWf on TransmitModel::stateChanged (MainWindow_Session.cpp:1428-1437). On a fresh connect the restore fires stateChanged while m_radioModel.panadapters() is still empty, so onSliceAdded is the actual carrier — which assumes slice-add follows pan-add, and panadapterAdded (MainWindow_Session.cpp:1770) does not seed the flag. This is pre-existing wiring (a Flex echo lands at the same point in the handshake), and the widget's own m_showTxInWaterfall survives a disconnect, so the realistic reconnect case is covered by inertia. I raise it only because your onConnected() comment asserts "before the GUI wires its pans" is the right moment, and that ordering is exactly what neither test nor a running app exercised. Inline on the call.

3. The shapesDisplayRatesLocally() gate has precedent — I'd call the question you raised settled. You offer "a declared capability instead is yours to ask for". For what it's worth from the code: Constitution III's test is whether the radio can save and restore the value, and no local-shaping family has a show_tx_in_waterfall register at all. The clientSettingsDomains enum is scoped to operating-state domains ("RF frequency + demod mode", "filter edges", …) and the Icom's "must never be pushed a restored state" comment (RadioModel.cpp:744-746) is about those pushes, not a client display flag — and nothing here is pushed to any radio. ClientDisplaySettings::waterfallRate already uses the identical predicate on the identical document for the identical kind of state. I don't think a new capability is needed; a maintainer may still prefer one.

4. tools/aether_mcp.py:759 groups txwaterfall under "gated by AETHER_AUTOMATION_ALLOW_TX". It isn't — correctly, since it never keys. Pre-existing and outside this diff.

What I tried to break

Findings and non-findings alike are reasoned from the head checkout at ded1f7d3 (which I confirmed is the PR head — a c29bb2f2 with your commit subject exists in the repo but is off an unrelated base and not in this branch's history). I ran no build and no test; nothing below was observed at runtime.

• Attacked the tests' strength first. The dialog test's negative assertion (!log.contains("transmit set show_tx_in_waterfall=")) looked like it could pass vacuously — it doesn't: RadioModel::sendCommand logs the full command text at lcProtocol debug before every drop path (RadioModel.cpp:9379), so a wire send is visible whether or not a session exists. The Flex positive control is genuine too, not an artifact of a backend-less model: the constructor calls setupBackend("flex") (RadioModel.cpp:2272), so "a bare model is on the Flex backend" is accurate, and the other test additionally exercises a real FlexBackend via rebuildBackendForTest.
• Looked for the fix being a no-op at the renderer — the PR's load-bearing claim that stateChanged "reaches the same consumers". It holds: MainWindow_Session.cpp:1436-1437 connects TransmitModel::stateChanged to a lambda that pushes to every pan's SpectrumWidget, so an operator toggle on a connected radio with pans present does reach the gate. The gap I did find is only on the connect edge (nit 2).
• Checked for provenance laundering — a client write entering through applyChanges(), the echo path, could make get transmit showTxInWaterfall and the troubleshooting dump report a client value as radio-confirmed. It doesn't: the m_haveTransmitStatus / m_rfPowerFromRadio latches fire only on d.rfPower / d.maxPowerLevel (TransmitModel.cpp:112-120), so a showTxInWaterfall-only delta flips no provenance flag and emits exactly one stateChanged, as the test asserts.
• Walked the connect/disconnect/radio-swap lifecycle. resetState() is called from exactly one place, onDisconnected() (RadioModel.cpp:7957), so nothing after onConnected() wipes the restore — and the !hasCommandPlane() early return sits after it. Identity is available at that moment: serial() returns m_lastInfo.serial (RadioModel.cpp:11573) and onConnected() already reads m_lastInfo.serial a few lines earlier. Second-radio isolation is real (hasRadioIdentity() keys the scope) and the test covers serial A → B.
• Attacked the store's failure paths. saveShowTxInWaterfall refuses on version > 1, Corrupt and Unavailable and checks the setFeature result, matching saveWaterfallRate exactly; the reader rejects a non-bool rather than coercing; a model with no radio identity writes nothing (so no family-wide row is poisoned). The two writers do non-atomic read-modify-write on the same document, which I chased — all three call sites are main-thread, so there is no interleaving, and the test pins that neither key disturbs the other.
• Could not check: anything keyed, which is the limit you state yourself — so what the HL2 draws during an over, and whether dbmToWaterfallLevel suits dBFS-under-a-dBm-label rows, remain open by your own admission. Also unchecked: Linux/Windows, and whether the dialog test's global qInstallMessageHandler sink is safe under the sanitizer lane with a QApplication running (the same pattern has produced a reported race elsewhere in the suite).
• CI on this head is 5/5 green, but that gate is -R-filtered and does not run either new target; the real signal is full-suite at merge.

Recommendation

Approve with nits. The root cause is correct and specific, the seam matches the existing requestLocalPanWeightedAverage precedent, no raw command is added above the seam, persistence lands in the right document with the right owner, and the tests survived the two ways I tried to make them vacuous. The limits section is unusually honest and I found nothing it misstates. Next step: add sim to the family list in docs/automation-bridge.md (and the body), and — if a maintainer wants nit 2 closed rather than noted — seed the flag from panadapterAdded as well, so a restored true does not depend on slice-add ordering.

Thanks for the fail-before mutation table; it made checking which assertions actually bite much faster.

---

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

[on8st]

The CI log's first error, both jobs: undefined reference to RadioSetupDialog::buildPeripheralsTab() linking radio_setup_show_tx_waterfall_test. Merge skew: #6027 moved that tab to RadioSetupDialog_Peripherals.cpp after this branch was cut; the new test lacked the file. The bridge test did link (the retrofit adds aetherdesktop_support), so the bot's cause was not it; registered anyway. Head ded1f7d3, main a8cfd990 merged: 622 of 623, only peripheral_auth_dialog_test (#6008) fails.

73, ON8ST

[on8st]

Not closed: the GUI half of nit 2. Nothing shows MainWindow handing a restored flag to a SpectrumWidget. The panadapterAdded seed is not added: no socket-free test can reach it. It is under "Not verified", and yours to ask for.

Head 3c491216, main a798558a merged. #6136 landed since (CI and CMake only) and is not merged in.

• Nit 1: sim is in the doc and the body. By source, the demo, ANAN and RTL-SDR cannot key (canTransmit false), so the flag is stored there and no keyed row is drawn.
• Nit 2, model half: comment reworded. 00740ca3 pins it on production HL2 wiring: the flag is in the model at connectionStateChanged(true), at the first pan and at the first slice. Moving the restore below the emit fails 1 check.
• Nit 3: unchanged; the maintainer's call.
• Nit 4: docs/automation-bridge.md:171 says the same. Not touched.
• Sanitizer lane, message-handler sink: not checked.

622 of 623 pass; peripheral_auth_dialog_test (#6008) fails.

73, ON8ST

[on8st]

Merged main into this branch after RTL M1 made it conflict (merge commit, no force-push). One test is red on this Mac: peripheral_auth_dialog_test, with the same serial-port diagnostic it prints on clean main at 22507580 (pasted on #6134); I did not re-run it on clean a325fb99. Head 98be49a1, main a325fb99 merged: 644 of 645 pass, both tests this PR adds among them.

One conflict, tests/tests.cmake: the RTL M1 merge and this branch added test targets at the same place, and both are kept. radio_setup_show_tx_waterfall_test now also lists RtlReceiverSettingsWidget.cpp and ControlAvailabilityRegistry.cpp, as main's own dialog tests do, since RadioSetupDialog.cpp builds the RTL Receiver page. The touchpoint manifest regenerates unchanged and the static checks pass.

73, ON8ST

[ten9876]

Issue fit: The dead-toggle mechanism is addressed; the persistence-ownership contract still needs correction. At 98be49a116fd25f04aed4a484faab92b5c650da5, both Radio Setup and txwaterfall reach the transmit model locally, and reconnect restores the value before pan/slice announcements. The #5678 parity reference supplies context; there is no dedicated closing issue. No transmit energy or keyed waterfall appearance is claimed as verified here.

Scope

File/group	Claimed?	Verdict
RadioModel.{h,cpp}	Yes: local request and connection-edge restore	Addresses the stated mechanism; ownership issue below
ClientDisplaySettings.h	Yes: per-radio showTxInWaterfall boolean in schema 1	Appropriate disclosed feature document; eligibility must be declared
RadioSetupDialog.cpp, AutomationServer.cpp	Yes: local route before existing Flex fallback	Both writers covered; bridge response semantics are documented
Two new tests and tests/tests.cmake	Yes: model/bridge injection and real dialog	Relevant registered, socket-free coverage
HERMES.md, automation-bridge.md	Yes: behavior, persistence, receive-only families and limits	In scope

Authored commits concern implementation, testing, integration and documentation of this change. No unrelated restyle, new default, transmit operation or changelog entry was found. The new persistent field is disclosed; the existing bridge verb gains immediate local-success semantics, not a new verb.

Blocker

1. Declare persistence ownership rather than inferring it from the concrete backend. src/models/RadioModel.cpp:6157-6190 uses shapesDisplayRatesLocally() to authorize both writing and restoring the new setting. Its implementation in src/models/RadioModel.h:1346 is m_backend != nullptr && m_flexBackend == nullptr: every non-Flex backend is implicitly opted in. That establishes implementation identity, not whether this setting belongs to the client. The exact rule in docs/agents/settings.md, Settings Authority Policy, is: “The deciding test is whether THIS radio can save and restore the value — a declared capability, not a family assumption.” The existing waterfall-rate exception does not authorize extending it to another persistent field; the body acknowledges the gap but does not cite a maintainer waiver.

   Keep the disclosed ClientDisplay owner/document, but gate the request/store/restore using explicitly declared ownership for this field, following the per-feature capability-record contract rather than adding a new frozen boolean. Pin declared opt-in and opt-out backends with socket-free tests. This is a source-verified contract defect, not a claim that I observed today's HL2/Icom/ANAN/RTL state being overwritten.

Non-blocking notes

• src/gui/MainWindow_Wiring.cpp:1947 and src/gui/MainWindow_Session.cpp:1429: the existing first-slice initialization and state-change fanout do carry the flag into spectrum widgets. The simulator cannot establish the color law or actual receive IQ while an HL2 is keyed. Retain that hardware limitation in the body; don't infer it from a true model flag.
• docs/automation-bridge.md:3005: the documented receive-only/demo cases help distinguish successful storage from actual keyed rendering. Jeremy should explicitly accept the field's intended ownership across those backends when selecting the capability declaration.

Verification and attacks

• Built the exact-head app and both new targets on Linux / Qt 6.12.0. The model/bridge test exited 0 and the production-dialog test passed 4/4. Both passed again after restoring the mutation.
• Mutation: made requestLocalShowTxInWaterfall() immediately decline. The model test exited 1 with 11 failed checks (including request, notification, store, restore and bridge result); the dialog test failed its host-made-rows case (3 passed / 1 failed). This is meaningful regression coverage, not a restatement of the implementation.
• In the exact-head app, explicit socket /tmp/aethersdr-codex-batch-6139, isolated settings and AETHER_AUTOMATION_NO_TX=1, connected only DEMO-0001. The bridge returned:

  {"ok":true,"txwaterfall":true,"note":"client-side flag on this radio, applied now; get transmit showTxInWaterfall reads it"}

  get transmit then showed showTxInWaterfall: true and transmitting: false. Opened Radio Setup → Transmit; the actual visible button read Enabled and checked: true. Coordinate clicks on that confirmed button produced model false, then true.
• Quit/relaunched the app against the same private profile and reconnected the demo: showTxInWaterfall restored to true across the process boundary. Invalid txwaterfall banana returned ok: false / txwaterfall requires on|off; switching off remained functional. Both owned processes (2199043, 2200956) exited after disconnect/Quit.
• A separate earlier control build (51bad5ff, not this PR's merge base) retained the pre-change route: txwaterfall on returned success but the demo model remained false. Treat that as corroborating old-behavior evidence, not an exact merge-base build. No radio hardware or operator instance was driven. Rendering actual keyed rows cannot be tested on the RX-only demo; the model-to-widget assignment was source-inspected.

All four architecture gates passed on the merge base and the head; per-file findings were unchanged apart from line movement. Reviewed schema/version refusal, unknown identity, same-family radio swap, false-value restore, preservation of other document fields, Flex echo ownership, and the existing spectrum consumers. New tests instantiate transports without opening them and inject bridge requests directly; no socket-owning changed test was executed. No model-invocable code-review skill was available; findings were checked manually and with local probes.

Required CI checks succeeded, but earliest head-run creation 2026-10-04 06:54:01 UTC predates current main 85f2a124 (2026-10-04T22:40:53Z). These pull_request checks describe an older merge result and branch protection is strict: false; they do not prove today's integration or the complete suite.

Recommendation: Request changes for the explicit persistence-ownership declaration. The local flag route is otherwise a focused fix; live keyed behavior remains outside this review and does not require a synthetic firmware peer.

— Jeremy KK7GWY + Codex

[ten9876]

Issue fit: the dead toggle is fixed; persistence ownership is not yet declared. No issue is linked (Refs #5678, row P30). At 98be49a1, on a radio whose waterfall rows are made on this host:

• Radio Setup's Show TX in Waterfall button and the txwaterfall verb write TransmitModel through RadioModel::requestLocalShowTxInWaterfall() (via applyChanges, the echo path);
• the value is stored per radio in ClientDisplay and restored in onConnected() before connectionStateChanged(true);
• a Flex still gets the transmit set show_tx_in_waterfall= wire text.

I reproduced the fix and its persistence on the demo (below).

Scope

File / group	Change	Claimed?	Verdict
src/models/RadioModel.{h,cpp}:6157-6190, 6945-6950	local request, connect-edge restore	Yes	In scope; ownership gate, Blocker 1
src/core/ClientDisplaySettings.h:84-123	showTxInWaterfall bool in schema-1 ClientDisplay	Yes	In scope; new persisted field
src/gui/RadioSetupDialog.cpp:2714-2720, src/core/AutomationServer.cpp:3585-3605	ask the model first, Flex fallback unchanged	Yes	In scope
2 new tests, tests/tests.cmake	model/bridge injection; production dialog	Yes	In scope
docs/HERMES.md, docs/automation-bridge.md	behaviour, persistence, families	Yes	In scope
8 merge: origin/main commits	conflict resolutions	Yes (comments)	Fine

No CHANGELOG.md, no new verb (only a different note on the local branch), no default change (off). Socket preflight: neither test opens a socket; the bridge test calls handleLine() without listening. The PR merges cleanly against main (85f2a124) and, textually, against #6140's current head.

Blockers

1. Ownership is inferred from "not a Flex", not declared.
   • Where: RadioModel.cpp:6157-6190. Both the request (the write and the store) and restoreClientShowTxInWaterfall() gate on shapesDisplayRatesLocally(), which is m_backend != nullptr && m_flexBackend == nullptr.
   • Canon: docs/agents/settings.md:143 says "The deciding test is whether THIS radio can save and restore the value — a declared capability, not a family assumption."
   • Bridge evidence, demo only: txwaterfall on while connected to DEMO-0001 stores sim|DEMO-0001|ClientDisplay|1|{"showTxInWaterfall":true}. After kill -TERM, a relaunch and a reconnect, get transmit reads "showTxInWaterfall": true. So every non-Flex family, the demo included, persists this field without declaring anything.
   • What changed since the earlier review: #6140 (same author, same document) resolved this exact finding an hour ago in 7a5ca748. FFT FPS and the dBm range now sit behind declared owners in capability records (PanFrameRateShaping::clientPersistsFrameRate, PanAmplitudeModel::clientPersistsDbmRange), and only the HL2 opts in.
   • Why that matters here: if both land as they stand, the demo, ANAN and RTL keep a persisted Show-TX flag but not their FFT FPS. Two fields in one document would follow two different ownership rules.
   • Fix: declare an owner for this field the same way (a record field, not a new frozen bool), opt in the families that should have it, and gate the request, store and restore on that one accessor. Pin an opt-in and an opt-out backend in show_tx_in_waterfall_client_flag_test. @ten9876, if you would rather waive this on precedent, one ruling now covers both PRs differently, so please say which.

Nits (non-blocking)

• txwaterfall while disconnected reports success for a no-op. AutomationServer.cpp:3598-3610: with no radio connected, txwaterfall on returns {"ok": true, "note": "radio echoes status…"}, and get transmit stays showTxInWaterfall: false, because the default backend is Flex and the wire text is dropped. This predates the PR, but the verb now has two success notes and this one is the misleading one. Worth an ok: false when !isConnected().
• The restored flag's last hop to SpectrumWidget is untested (onSliceAdded at MainWindow_Wiring.cpp:1947). It is already in Limits; it stays a Limit.

What I tried to break / verified

• Built and ran this head's tests (Linux, Qt 6.12.0, offscreen): show_tx_in_waterfall_client_flag_test exits 0, and radio_setup_show_tx_waterfall_test passes 4/4.

• Mutation, connect-edge restore removed from onConnected(): the flag test exits 1 with "FAIL: the next connect puts the stored value back", "restored before connectionStateChanged(true) is emitted", "and held when the first pan is announced". The file was restored (sha256 matches git show HEAD:) and touched. The earlier review's "request declines" mutation (11 failures) covers the other direction.

• Bridge, demo only: socket /tmp/aethersdr-pr6139, isolated settings and HOME, AETHER_AUTOMATION_NO_TX=1. Connected with connect local serial DEMO-0001, which reported "serial": "DEMO-0001", "transmitting": false.

  Step	get transmit
  before	"showTxInWaterfall": false
  txwaterfall on → "note": "client-side flag on this radio, applied now…"	true
  disconnect	false (resetState)
  relaunch, reconnect	true (the persistence in Blocker 1)

  Both instances were closed.

• Provenance: checked whether a client write through applyChanges() gets reported as radio-confirmed. It doesn't: the provenance latches in TransmitModel fire only on rfPower/maxPowerLevel.

• Not verified: anything keyed, which is impossible on the demo (it cannot transmit) and needs an HL2 on a dummy load, as the body says. Also unverified: the colour law for dBFS rows, and Windows/macOS.

Recommendation: Request changes for Blocker 1. It is the same change #6140 has just made, so the template is in-tree. Everything else is ready.

— Jeremy KK7GWY + Claude

[on8st]

Bad news first: this is narrower than what you reviewed. The demo, ANAN, Icom and RTL-SDR are back to main's dead toggle. On DEMO-0001, txwaterfall on now answers with the radio-echo note, get transmit stays false, and nothing is stored or restored: the case both reviews drove gives a different answer at this head. And one test is red on this Mac: peripheral_auth_dialog_test (#6008), with the diagnostic it prints on clean main.

Head ea2cf144, one new commit on 98be49a1. main is not merged in; a trial merge with 85f2a124 is clean and was not built.

Blocker (both reviews): ownership is declared.

• New optional record RadioCapabilities::txWaterfallClientFlag, field clientPersistsFlag with no default. No new top-level bool: check_capability_records reads 70 of 70.
• One accessor, RadioCapabilities::clientPersistsShowTxInWaterfall(), gates the request, its store, and the connect-time restore. shapesDisplayRatesLocally() no longer decides anything for this flag.
• I read "request/store/restore" as including the local apply, so an undeclared backend takes the wire route as on main.
• Only the Hermes-Lite 2 engages it. Flex, Icom, ANAN, RTL-SDR and the demo declare it absent. Another family is one declaration, for its owner or you to make.
• The ClientDisplay document and its schema are unchanged. Flex is unchanged on the wire.

Tests, socket-free, on the real backends.

• Opt-in: real Hl2Backend stores, restores, and answers the bridge verb locally.
• Opt-out: real Icom, ANAN, RTL-SDR and demo backends, each with a ClientDisplay document that already holds the flag: nothing restored, the request declines, the document is untouched. Same on Flex, and on a backend that engages the record with the field false.
• Dialog test: a new slot on a real Icom backend (the click sends the wire text, the model is not set).
• Accessor forced true for every backend: 40 checks fail in the flag test, 2 slots in the dialog test. Forced false: 15 checks and 1 slot.
• Full suite at ea2cf144, macOS, Qt 6.12.0: 644 of 645 pass. Static checks pass (stdin from /dev/null); a11y 9 warnings, the same 9 as main.

Notes.

• Docs: docs/HERMES.md, docs/automation-bridge.md and the capabilities map now name the HL2 as the owner. The bridge doc's demo and receive-only cases describe the wire route.
• The hardware limit stays in the body: nothing was keyed, and a true model flag shows neither the colour law nor real receive IQ while keyed.
• txwaterfall answering ok for a no-op while disconnected is not changed. The same note is now what the demo, ANAN, Icom and RTL-SDR return while connected. Refusing there is a change to the verb's contract: yours to ask for.
• If you want the flag applied for the session on other host-rendering families without storing it, that is a second field in this record: say so.
• With fix(gui): FFT FPS and the dBm range survive a restart. Principle VIII. #6140 at 7a5ca748: a trial merge is clean in either order, and the merged capability header still counts 70.

Not verified: anything keyed; a running app at this head (the demo included); Linux and Windows; the merge result with main; that the main window hands a restored flag to the spectrum widget.

73, ON8ST

[ten9876]

Maintainer ruling: persisting Show TX in Waterfall must be gated by a capability each backend declares, following the pattern #6140 adopted for FFT FPS and the dBm range, not by shapesDisplayRatesLocally(). The blocker in the review above stands. Flex behaviour is unchanged either way: the radio stores and echoes the flag.

— Jeremy KK7GWY + Claude

[on8st]

The red check-windows on ea2cf144 is not from this change: the job stopped in "Setup sccache", where the download of sccache-v0.18.0-x86_64-pc-windows-msvc.tar.gz returned HTTP 500 twice, before anything was compiled. build, check-macos, Static checks and Sanitizer option configures pass on this head. I cannot re-run the job; a re-run should clear it.

73, ON8ST

[Ozy311]

Re-review of ea2cf144, the one commit since @ten9876's two request-changes reviews at 98be49a1.

The blocker is resolved the way it was asked. Both reviews asked for the request, the store and the restore to be gated on a declared owner in a per-feature capability record, through one accessor, in the shape #6140 used. That is what this commit does:

• RadioCapabilities::TxWaterfallClientFlag { bool clientPersistsFlag; } (no default, so an engaging backend must state its value), with a single accessor clientPersistsShowTxInWaterfall() (RadioCapabilities.h:343-361). It has the same shape as PanFrameRateShaping::clientPersistsFrameRate on main.
• requestLocalShowTxInWaterfall(), saveShowTxInWaterfall() and restoreClientShowTxInWaterfall() all read that one accessor (RadioModel.cpp:6157-6185). shapesDisplayRatesLocally() is no longer consulted for this field.
• Only Hl2Backend opts in, with true. Flex, Icom, ANAN, RTL and Sim each state std::nullopt explicitly in their capabilities().
• No new top-level bool: check_capability_records is at 70 of 70.

The tests moved with it. The opt-in checks now run on a real Hl2Backend, and the new opt-out checks use the real Icom, ANAN, RTL and demo backends with a document that already holds the flag, plus a backend that engages the record with the field false. That last case is the one that pins "declared false" apart from "absent".

Verified

On the PR merged into current main (0156894f; the branch is 84 commits behind, and the merge is clean):

• check_capability_records: 70 booleans, at the frozen 70.
• check_command_plane: 368 against a baseline of 368, 0 strict.
• check_engine_boundary: 0 would block under --strict.
• check_test_registration and gen_touchpoint_manifest.py --check: OK.

Not run: the two C++ tests, which need the core build, and the app.

Nits (non-blocking)

1. ANAN goes back to a dead toggle. Before this commit ANAN took the local route, as every non-Flex backend did. Now it states no owner, so the button sends transmit set show_tx_in_waterfall=, and that is dropped because ANAN has no command plane. ANAN can transmit and makes its waterfall rows on this host, the same position as the HL2. The commit message says this is "main's behaviour", which is true, and it is the conservative reading of the review. But it means the defect this PR fixes is still there on ANAN. Opting ANAN in is one line in AnanBackend::capabilities() if a maintainer wants it, here or in a follow-up. The same applies to Icom only if its waterfall is client-made and it can transmit. RTL and the demo are receive-only, so leaving them out is clearly right.
2. CI is from 2026-10-05. The merge is clean, and the static gates above pass on the merged tree, but the green checks describe an older merge base.

Nothing else from either earlier review is outstanding as far as I can see. The txwaterfall-while-disconnected nit and the untested onSliceAdded hop were both left as Limits, which is where the reviews put them.

73, K6OZY

---

Generated by Claude Code

[on8st]

Merged main (b3e0302e) into the branch as 9badd2de, because the PR had gone CONFLICTING. No rebase; the reviewed commits are unchanged.

Seven files conflicted, all for one reason: #6260 added a lineoutControl line exactly where this PR adds txWaterfallClientFlag (the six capabilities() functions and the capabilities map). Both lines are kept in each. Nothing else in the diff changed: it is still 18 files.

After the merge: check_capability_records at 70 of 70, check_command_plane 368 of 368, the touchpoint manifest up to date. Full ctest: 758 of 760; both tests of this PR pass. The two that fail are the clean-main failures on this Mac, #6008 and #6224, each with only its known lines.

73, ON8ST

[on8st]

Merged main (46943eb3) into the branch as cf0006c5, because the PR had gone CONFLICTING again. No rebase; the reviewed commits are unchanged.

One file conflicted, tests/tests.cmake, in two places: #6353 registered its Radio Setup test at the spot this PR uses. Both registrations are kept. Main also added a capability record with #6083 (receiveAudioExport); all six backends state it and this PR's txWaterfallClientFlag.

After the merge: check_capability_records at 70 of 70, the touchpoint manifest up to date. Full ctest on macOS: 771 of 772; both tests of this PR pass. The one that fails is the clean-main failure #6008 on this Mac, with the dialog page minimum still 784.

73, ON8ST

[rfoust]

Issue fit

This fixes the dead Show TX in Waterfall toggle for the Hermes-Lite 2. The HL2 declares client ownership, so Radio Setup and txwaterfall update the transmit model without waiting for an echo, and the choice is saved per radio and restored on connect. Flex retains its radio-owned echo path. The prior maintainer request for an explicit capability declaration is addressed at this head.

Scope

Files	Purpose	Verdict
RadioModel, ClientDisplaySettings, capabilities and backends	Local apply, exact per-radio storage, connect restore, and explicit owner	In scope
Radio Setup dialog and automation bridge	Route both controls through the model	In scope
Two registered tests and tests.cmake	Cover opt-in, opt-out, persistence, bridge and dialog	In scope; socket-free
docs/HERMES.md, capability map, bridge guide, user guide and MCP description	Explain the behavior and correct the display-only classification	In scope

No unrelated default, UI restyle, new keying route, or CHANGELOG entry is included.

Verification

I built the PR merged with then-current main on macOS ARM64 and ran both new focused tests: 2/2 passed. Removing the connect-time restore made the model test fail on four specific assertions; restoring it returned both tests to passing. The full ARM64 app built. The new user-guide pages passed npm ci and npm run build; the MCP description passed python3 -m py_compile, and the final diff passes git diff --check. Both follow-up commits have valid SSH signatures. CI for this final head is still running, so branch protection should hold the merge until it passes.

Remaining verification boundary

The demo cannot key, and the keyed HL2 waterfall image and receive IQ have not been measured on hardware. The PR states this limit. The model test covers the restore before the production HL2's connect, pan and slice announcements; the final GUI handoff is not shown in a running HL2 session. The optional ANAN/Icom support question stays outside this HL2-only fix.

I approve this head after the documented ownership fix and the user documentation update.

Outdated review of 98be49a: the requested explicit txWaterfallClientFlag capability and one ownership accessor landed in ea2cf14; the current head also includes the user documentation and has a fresh approving review.

[rfoust]

Reapproving head 93fea1c after the signed CI fix. Linux and macOS failures on the previous head both came from the radio_setup_show_tx_waterfall_test link omitting CanonWindow.cpp after the current main dialog change. The test target now compiles and links that source; local ARM64 CMake generation confirms it is on the target link line. The earlier review covered the HL2 client-owned flag, UI path, documentation, and focused tests. Required CI is rerunning on this head; squash auto-merge remains enabled.