[on8st]

Two HL2 capability declarations were wrong in opposite directions, and a third — the receive-control mode list — was short by three modes the demodulator already serves. All three are read by production, none of them by a menu alone.

1. hasFmRepeaterOffset — silence here is a CLAIM, not neutrality

RadioCapabilities defaults it:

bool hasFmRepeaterOffset = true;

Hl2Backend::capabilities() never assigned it, so the HL2 claimed a repeater duplex. Both GUI readers act on that claim — VfoWidget::configureFmToneControls and RxApplet::configureFmToneControls, identically:

const bool repeaterAvailable = !connected || caps.hasFmRepeaterOffset;
if (m_fmOffsetSpin)  m_fmOffsetSpin->setEnabled(repeaterAvailable);
if (m_fmOffsetDown)  m_fmOffsetDown->setEnabled(repeaterAvailable);
if (m_fmSimplexBtn)  m_fmSimplexBtn->setEnabled(repeaterAvailable);
if (m_fmOffsetUp)    m_fmOffsetUp->setEnabled(repeaterAvailable);

So the offset spin, the ±steps and the simplex button came up enabled. Behind them, Hl2Backend overrides none of setSliceFmRepeaterOffset, setSliceRepeaterOffsetDir, setSliceFmRepeater — all three are Q_UNUSED-only virtuals in IRadioBackend, so every one resolves to a silent no-op. A live-looking control moving a number that reaches nothing is exactly the failure this field exists to prevent, and it is the reason RtlSdrBackend declares it false and IcomCivBackend derives it from the model profile's hasDuplex. The HL2 was the one backend that said nothing.

Note the widgets are setEnabled, not setVisible: the controls stay on screen and go grey. That is the intended shape — the operator sees the radio declining, not the control vanishing.

2. fmTonePresentation — Legacy is an OFFER of CTCSS encode

This one was declared, and declared wrongly:

c.fmTonePresentation = FmTonePresentation::Legacy;

Legacy is the value that fills the tone-mode combo from legacyFmToneModes(), in both widgets:

const QStringList modes = presentation == FmTonePresentation::Ctcss
    ? caps.fmToneModes : legacyFmToneModes();

and legacyFmToneModes() (in RadioCapabilities.h) is {"off", "ctcss_tx"}. ctcss_tx is CTCSS encode. There is no CTCSS encoder on this path: nothing under src/core/backends/hl2/ mentions CTCSS at all — the only case-insensitive match for ctcss|dtcs across all 44 files in that directory is the identifier in c.fmDtcsCodes = {};, an explicit empty — and Hl2Backend overrides none of setSliceFmToneMode, setSliceFmToneValue, setSliceFmToneRxValue, setSliceFmDtcs.

Now Hidden, which is what both widgets read to hide the tone row rather than show a control that does nothing.

Hidden is also the struct's default, and that limits what a value assertion can prove. RadioCapabilities.h initialises FmTonePresentation fmTonePresentation = FmTonePresentation::Hidden;, so a backend that says nothing reports Hidden too. An assertion that the HL2 reports Hidden can therefore fail when the statement is changed and not when it is deleted — it pins the value, not the declaration. M1b below is that mutant, measured. hl2_fm_controls_declaration_test now carries a second, separate assertion that reads the statement out of Hl2Backend.cpp — the AETHER_SOURCE_DIR + QFile shape rf_gain_presentation_test already uses for production wiring — so deletion and reversion both turn it red. hasFmRepeaterOffset never had this problem: its default is the opposite value, which is why the two facts are asserted separately.

3. The justification rests on receiveOnlyModes, NOT on the modulator

Deliberately, because the modulator is a build-time choice and an argument from it would be half wrong in every build. CMakeLists.txt:

option(AETHER_HL2_TX_TXA
       "Hermes-Lite 2 SSB transmit modulator: ON (default) uses WDSP's TXA chain, OFF the in-tree phasing modulator"
       ON)

It defaults ON, and WDSP's TXA chain does carry fmmod. So "the TX chain is a hand-written phasing modulator" is stale and is not used here.

What holds in both configurations is the declaration:

c.receiveOnlyModes = {QStringLiteral("AM"),   QStringLiteral("SAM"),
                      QStringLiteral("DSB"),  QStringLiteral("FM"),
                      QStringLiteral("NFM"),  QStringLiteral("WBFM"),
                      QStringLiteral("WFM"),  QStringLiteral("DRM")};

RadioModel::refuseKeyInReceiveOnlyMode() reads exactly that list, and it sits in the single common entry point RadioModel::beginTxActivity, so it refuses every TxActivity — MOX, TUNE and CW keying alike — while the slice is in FM or NFM. The radio will not key in these modes. A transmit-side control surface for a mode that cannot be keyed is dead by construction, whatever the modulator is.

Receive is untouched. FM and NFM demodulate exactly as before; neither field reaches WDSP's FM demodulator. What is withdrawn is transmit-side control.

4. receiveModeControl — a list that is read TWICE, and the second read latches

On origin/main the HL2 declared seven modes:

c.receiveModeControl = ReceiveModeControl{SliceFrequencyControl::Authority::Engine,
    {QStringLiteral("USB"), QStringLiteral("LSB"), QStringLiteral("DIGU"),
     QStringLiteral("DIGL"), QStringLiteral("AM"), QStringLiteral("SAM"), QStringLiteral("CW")}};

ModelReceiveControlTarget reads it in two places:

// ModelReceiveControlTarget::setMode — the REQUESTED mode
if (!caps.receiveModeControl->modes.contains(mode)) {
    return refusal("request.out_of_range", "mode is not supported by this receive path");
}

// ModelReceiveControlTarget::checkSlice, case ReceiveOperation::Mode — the OBSERVED mode
supported = caps.receiveModeControl && known(caps.receiveModeControl->authority)
    && observed.mode && caps.receiveModeControl->modes.contains(*observed.mode);

→ refusal("capability.unavailable", "receive operation or observation unavailable")

checkSlice is the first statement of setMode. So a slice whose observed mode is absent from the list has slice.setMode refused whatever mode is requested — including a mode that is on the list. It cannot be steered back out over the control plane at all. That is self-latching, and it is much worse than "you cannot reach those modes".

It is reachable today: DSB and CWL are both on publishedModeStrings(), so the mode menu offers them. Pick DSB out of the combo and the slice is stranded. Both are real modes here — modeFromString maps each onto its own WdspChannel::Mode (Dsb, Cwl) and defaultPassbandForMode carries an entry written for each ({-3000, 3000} and {-250, 250}).

CWU was added here in an earlier revision, on the reasoning that Hl2Backend::setSliceMode stored what it was handed verbatim (r->mode = mode;) and could therefore strand a slice in that spelling. §4b reverses that: the right fix was to stop the backend doing it, and once it stops, an alias on this list becomes a permanent request.conflict wedge rather than a harmless extra entry. Read §4b before this paragraph's conclusion; the diagnosis stands and the remedy changed.

The declaration is now pinned by the target that consumes it. A membership assertion — "DSB is in the list I just read back" — cannot tell a consumed declaration from an ignored one. control_receive_test gains hl2DeclaredModesDriveTheControlPlane(), which installs the HL2's own receiveModeControl on the socket-free fixture backend, reports an observed mode, and asks the real ControlService for a mode change. It asserts the response code, never agreement between a list and itself, and it covers both reads: a slice observed in DSB/CWL/FM is steerable out of it, and each of the three can be requested from a slice observed in USB. (After §4b the two alias spellings appear here as the opposite — refusals — for the reason given there.)

Two negative controls are what give it teeth, and they use DRM — one of the modes §5 leaves off, on the least contestable of those grounds. A slice observed in DRM is refused capability.unavailable (the latch); DRM requested is refused request.out_of_range (one declined intent). Strip either term out of ModelReceiveControlTarget and the matching line turns red while every membership assertion in the suite stays green — M5 below is that mutation, measured.

One honest limit on the fix. ModelReceiveControlTarget::available is an any-slice OR over checkSlice, so while one healthy slice exists the slice.setMode verb still advertises as available even when it is refused for a stranded one. Declaring DSB, CWL and FM removes the strandings this backend can actually produce; it does not repair that OR, which is not an HL2 declaration and is not touched here.

4a. RULED: FM joins the list — a mode the MENU offers must never latch the slice shut

An earlier revision of §5 kept FM off this list on demodulator grounds and held the question open. It is now ruled, and the ruling turns on the second read rather than the first.

Hl2Backend::capabilities() publishes d.modeList = hl2::publishedModeStrings(), and that list carries FM. So the mode combo offers it, exactly as it offers DSB and CWL. After the DSB/CWL additions the set difference between the menu and receiveModeControl was exactly {FM} — and §4's own stated harm then reads verbatim with FM substituted: pick FM out of the combo and the slice is stranded, because ModelReceiveControlTarget::checkSlice is the first statement of setMode and a stranded slice cannot be steered back out by any requested mode, including a listed one.

The ground is not "the HL2 serves FM well". Every reservation in §5 is still true and is still written beside the declaration. The ground is: a mode the radio's own menu puts on a slice must not latch the control plane shut. Declaring it does not answer the deviation/squelch/AGC question; it stops the answer being "and the slice is stuck there".

control_receive_test now derives the rule instead of restating it: it walks hl2::publishedModeStrings() and asserts the two lists agree in both directions, printing the difference when they do not. A mode added to the menu later fails there instead of stranding an operator.

WHAT THIS WIDENS ON THE REQUEST SIDE. ModelReceiveControlTarget::setMode shares the list, so slice.setMode mode="FM" is now accepted where it was refused request.out_of_range. That is a real widening of the control-plane request surface and it is asserted explicitly in the test, not left implicit.

KEYING IS UNAFFECTED — checked against the source, not assumed. Re-derived here:

• c.receiveOnlyModes on this backend carries "FM" and "NFM" (unchanged by this commit).
• AetherSDR::modeIsReceiveOnly() in RadioCapabilities.h is !mode.isEmpty() && caps.receiveOnlyModes.contains(mode, Qt::CaseInsensitive) — a membership test on that list and no other.
• RadioModel::refuseKeyInReceiveOnlyMode() runs it on txSlice()->mode() and is called from RadioModel::beginTxActivity() (RadioModel_TxCoordinator.cpp), the common entry for TxActivity::Mox, Tune, Atu and Cwx, plus from RadioModel::forwardNonFlexCwKeying() for the CW-element path.
• receiveModeControl is read in exactly three places tree-wide — ModelReceiveControlTarget::setMode, ModelReceiveControlTarget::checkSlice, and RadioResourceAdapter, which only serialises it into the capability description. Nothing on the transmit side reads it at all.

hl2_fm_controls_declaration_test now pins both halves side by side: FM is on receiveModeControl and on receiveOnlyModes. If a real FM transmit chain ever lands and FM leaves the second list, that assertion fails and the two withdrawals in §1/§2 become re-openable questions rather than settled ones.

4b. RULED: Hl2Backend::setSliceMode canonicalises — and that took CWU back OFF the list

Bad news first, because it changes what this PR does rather than only adding to it. @ten9876 was right that admitting CWU on the observe list also admits it on the requested-mode read. Applying the ruled fix — canonicalise in the backend — then made keeping CWU on the list actively dangerous, so CWU has been removed from receiveModeControl and NFM was never added. That is a reversal of part of this PR's earlier revision and it is explained in full below; if a reviewer prefers the alias entries kept, the alternative is a change to ModelReceiveControlTarget's pending-mode interlock and that is a separate question.

The fix, first. Hl2Backend::setSliceMode stored the string verbatim (r->mode = mode;). Both mode-combo consumers rebuild with clear()/addItems()/findText(currentText) and move the selection only on a findText() hit, and publishedModeStrings() deliberately carries "CW" alone — so the combo fell to index 0, "LSB", with signals blocked, while the receiver really was in CW. setSliceMode now runs the existing hl2::canonicalOfferedMode(), gated by isKnownModeString() exactly the way applyRestoredState() already gates it:

const QString mode = isKnownModeString(requested) ? canonicalOfferedMode(requested) : requested;

so CWU→CW, NFM→FM, WFM→WBFM, and everything else through untouched — not even upper-cased, which is what keeps this from changing anything outside the three alias pairs.

WHY THE ALIAS THEN HAD TO LEAVE THE LIST — a permanent wedge, found while applying the ruling. ModelReceiveControlTarget::setMode records the requested string:

m_pendingModes.insert(slice, mode);
m_radio->backend()->setSliceMode(id, mode);

and releases it only on an observation comparing equal to it:

if (pending != m_pendingModes.constEnd() && slice->receiveObservation().mode == pending.value())
    m_pendingModes.remove(slice);

While that entry stands, checkSlice refuses every further Mode and Filter intent on that slice with request.conflict. The only other things that clear it are RadioModel::backendRebuilt, a disconnect, and the slice's destruction.

So with the canonicalisation in place, slice.setMode mode="CWU" would be accepted, publish back "CW", never match, and wedge the slice's mode and filter control until the radio disconnects — a strictly worse self-latch than the one §4 exists to remove, arriving by the other door. An alias on this list stopped being a harmless extra entry the moment the backend started rewriting one.

And removing it costs no steerability, which is what makes this the right way round. After this change there are exactly two writers of Hl2Backend's Receiver::mode — setSliceMode() and the restore path, whose m_restoredState.mode is the already-canonicalised valid.mode from applyRestoredState(). Both canonicalise, so no slice can be observed holding CWU or NFM at all, and the observe read has nothing to rescue. The request read declines them request.out_of_range, which is honest: refusing one intent beats wedging the slice.

receiveModeControl now equals publishedModeStrings() as a set — and the invariant that actually guards the wedge is asserted rather than the coincidence: every declared mode is its own canonical spelling, canonicalOfferedMode(m) == m. That is exactly the condition under which the requested string and the published one cannot disagree. M8 below is that mutant, measured: put CWU back and the guard goes red.

THE DOCUMENTED TRADE, because it deserved checking before overriding. Hl2ModeVocabulary.h's IT CANNOT WEAKEN A TX REFUSAL block ends:

The duplicate entries stay: CAT, TCI and Hl2Backend::setSliceMode still put either spelling on the slice at run time, and those entries are what refuse the key when they do.

Read in full, that sentence is the justification for listing both spellings in receiveOnlyModes — a description of what setSliceMode did, offered as the reason the duplicate entries are needed. It is not a requirement that setSliceMode keep doing it, and nothing in the header relies on the verbatim store. The header's load-bearing rule is the line immediately above: "Every pair below is therefore listed BOTH WAYS … or on NEITHER … Collapsing one spelling onto the other moves nothing across that boundary" — collapsing is explicitly the safe operation, and hl2_mode_vocabulary_test already proves it for this exact change, walking every accepted spelling and asserting receiveOnlyModes.contains(m) == receiveOnlyModes.contains(canonicalOfferedMode(m)) case-insensitively. FM/NFM are both on that list, WBFM/WFM are both on it, CW/CWU are on neither.

So canonicalising does not contradict the documented decision; it narrows one clause of it, and the header has been updated in place to say so — including that the duplicate receiveOnlyModes entries stay regardless, because that list is a membership test on whatever string a slice happens to hold and must stay correct even if a future change reopens a route this one closes.

The residual set is unchanged: WBFM and DRM still have no offered twin to collapse onto, exactly as the header's TWO ACCEPTED MODES REMAIN UNDISPLAYABLE paragraph says.

4c. Prose this change falsified, corrected in the same commit

Canonicalising made four statements elsewhere in the tree untrue. They are corrected here rather than left to rot, and one of them was not prose at all:

• RadioCertification::stageModeMap() would have MISREPORTED the HL2 — a behaviour consequence, not a comment. The stage sets each mode, reads it back, and flags back.compare(mode, Qt::CaseInsensitive) != 0 as "these modes did not survive a round trip … A mode the backend does not map does not fail — it becomes the default, usually USB". After this change it fires on CWU->CW and NFM->FM with an explanation that is the opposite of the truth: those modes are mapped, they were canonicalised on purpose. Its narrative also opened "READBACK IS NOT PROOF. The slice keeps whatever string it is given", which this PR falsifies outright. Both now name both causes — unmapped fallback and deliberate alias collapse — and point at the passband fingerprint as the only evidence that separates them from outside the backend.
• docs/aetherd-local-receive-control.md, the backend table's HL2 Mode column, read USB/LSB, DSB, DIGU/DIGL, AM/SAM, CW/CWU/CWL. Now USB/LSB, DSB, DIGU/DIGL, AM/SAM, CW/CWL, FM.
• docs/architecture/radio-capabilities-map.md, the receiveOnlyModes row, justified the duplicate alias entries as "because the guard compares the string the slice holds". Still the right conclusion, no longer the right reason on this backend — rewritten to say that both writers canonicalise now and the entries are kept because a list that is only correct while every writer stays canonical is the wrong kind of correct.
• VoiceModeGate.h, PhoneCwApplet.cpp and AetherDspModePolicy.cpp each name the HL2 as a producer of "CWU" on a slice. No code changed in any of them — Icom still produces CWU and all three spellings must stay — only the HL2 half of each justification, which is now historical.

5. What is still deliberately NOT declared

NFM, WBFM, WFM and DRM stay off the list, for two different reasons.

NFM is an alias, and §4b is why it is not here. It is not on publishedModeStrings(), Hl2Backend::setSliceMode collapses it onto FM before a slice holds it, so there is no observation to rescue — and listing it would create the permanent request.conflict wedge described there. receiveOnlyModes is the list that still needs both spellings, for its own reason: that one is a membership test run on whatever string a slice happens to hold.

WBFM, WFM and DRM are the genuine exclusions. None of them is on publishedModeStrings(), so no menu can put one on a slice and none carries the stranding exposure FM had — reaching them at all needs CAT, TCI or a hand-edited document, and the alias half of that (WFM) now collapses onto WBFM before it is stored. WBFM/WFM clear nbp0 and panel in SetRXAMode — the stage carrying the sideband selection and the manual notches — and broadcast FM is outside the 38.4 MHz ceiling this radio can hear; DRM has no decoder here at all.

The FM reservations have not gone away; they have been separated from the stranding. FM/NFM reach WDSP's fmd, but nothing in this tree ever calls SetRXAFMDeviation (so it runs on create_rxa's 5 kHz default whatever the signal is), SetRXAMode(FM) clears the AGC, and this backend has no squelch at all — setSliceSquelch is not overridden here. That is still a real question wanting the deviation, squelch and AGC work behind it. What §4a rules is only that leaving the mode undeclared does not answer it, and does strand a slice an operator can reach from the combo today.

Proved by mutation — my own output, re-run on this tree

Every cycle rebuilds, reads the Building CXX line back to confirm the mutated TU actually recompiled, runs, then restores by rewriting the file (so the mtime moves and ninja cannot skip the restore rebuild) and reruns. The restore run is green in every case below. (The harness rewrites both files it can mutate on every restore, so ModelReceiveControlTarget.cpp.o appears in the rebuild list even in cycles that only touched Hl2Backend.cpp — the line that matters per cycle is the mutated TU's own.)

The FM declarations

M1 — REVERT both to their origin/main state (drop c.hasFmRepeaterOffset = false;, put fmTonePresentation back to Legacy):

[2/9] Building CXX object CMakeFiles/aethercore.dir/src/core/control/ModelReceiveControlTarget.cpp.o
[3/9] Building CXX object CMakeFiles/aethercore.dir/src/core/backends/hl2/Hl2Backend.cpp.o
hl2_fm_controls_declaration_test exit=1
[ OK ] this is the HL2 descriptor (sanity, not the subject)
[ OK ] FM and NFM are RECEIVE-ONLY here — the radio will not key in them
[FAIL] the HL2 declines the repeater offset: there is no verb behind it
[ OK ] hasFmRepeaterOffset still defaults TRUE — silence here is a claim
[FAIL] the tone controls are HIDDEN, not offered under the legacy shape
[ OK ] the production backend source is readable — the next assertion needs it
[FAIL] and Hidden is STATED, not inherited from the struct's identical default
[ OK ] Legacy offers CTCSS ENCODE — that is what the HL2 was claiming
[ OK ] and no tone vocabulary or DTCS codes are published to go with it
/Users/stanclaes/Repos/on8st/wt/bundleA-declares/build/hl2_fm_controls_declaration_test: 3 failure(s)

M1b — DELETE both lines rather than reverting them. An earlier version of this section ran only M1 and concluded "the two facts fail apart". That is true for a reversion and false for a deletion, because Hidden is the struct default:

[2/6] Building CXX object CMakeFiles/aethercore.dir/src/core/control/ModelReceiveControlTarget.cpp.o
[3/6] Building CXX object CMakeFiles/aethercore.dir/src/core/backends/hl2/Hl2Backend.cpp.o
hl2_fm_controls_declaration_test exit=1  failing assertions=2
[ OK ] this is the HL2 descriptor (sanity, not the subject)
[ OK ] FM and NFM are RECEIVE-ONLY here — the radio will not key in them
[FAIL] the HL2 declines the repeater offset: there is no verb behind it
[ OK ] hasFmRepeaterOffset still defaults TRUE — silence here is a claim
[ OK ] the tone controls are HIDDEN, not offered under the legacy shape
[ OK ] the production backend source is readable — the next assertion needs it
[FAIL] and Hidden is STATED, not inherited from the struct's identical default
[ OK ] Legacy offers CTCSS ENCODE — that is what the HL2 was claiming
[ OK ] and no tone vocabulary or DTCS codes are published to go with it
/Users/stanclaes/Repos/on8st/wt/bundleA-declares/build/hl2_fm_controls_declaration_test: 2 failure(s)

M1b-tone — DELETE only the fmTonePresentation statement:

[2/6] Building CXX object CMakeFiles/aethercore.dir/src/core/control/ModelReceiveControlTarget.cpp.o
[3/6] Building CXX object CMakeFiles/aethercore.dir/src/core/backends/hl2/Hl2Backend.cpp.o
hl2_fm_controls_declaration_test exit=1  failing assertions=1
[ OK ] this is the HL2 descriptor (sanity, not the subject)
[ OK ] FM and NFM are RECEIVE-ONLY here — the radio will not key in them
[ OK ] the HL2 declines the repeater offset: there is no verb behind it
[ OK ] hasFmRepeaterOffset still defaults TRUE — silence here is a claim
[ OK ] the tone controls are HIDDEN, not offered under the legacy shape
[ OK ] the production backend source is readable — the next assertion needs it
[FAIL] and Hidden is STATED, not inherited from the struct's identical default
[ OK ] Legacy offers CTCSS ENCODE — that is what the HL2 was claiming
[ OK ] and no tone vocabulary or DTCS codes are published to go with it
/Users/stanclaes/Repos/on8st/wt/bundleA-declares/build/hl2_fm_controls_declaration_test: 1 failure(s)

Read the M1b output again: [ OK ] the tone controls are HIDDEN, not offered under the legacy shape is green under the deletion. Against the assertion set this PR originally carried, M1b would have failed one assertion and M1b-tone would have failed none at all — a mutant that removes the declaration outright, undetected. The source-text assertion is what closes that.

M1b-tone RE-RUN, because that assertion changed. It was a literal substring match and is now a whitespace-tolerant pattern (c\.fmTonePresentation\s*=\s*FmTonePresentation::Hidden\s*;). It still fails on the deletion:

-- M1b-tone - DELETE the c.fmTonePresentation statement
[2/6] Building CXX object CMakeFiles/aethercore.dir/src/core/control/ModelReceiveControlTarget.cpp.o
[3/6] Building CXX object CMakeFiles/aethercore.dir/src/core/backends/hl2/Hl2Backend.cpp.o
hl2_fm_controls_declaration_test exit=1  failing assertions=1
[ OK ] this is the HL2 descriptor (sanity, not the subject)
[ OK ] FM and NFM are RECEIVE-ONLY here — the radio will not key in them
[ OK ] FM is STEERABLE and still unkeyable — receive control and receive-only agree
[ OK ] and the NFM alias is receive-ONLY but not requestable — the two lists differ on purpose
[ OK ] the HL2 declines the repeater offset: there is no verb behind it
[ OK ] hasFmRepeaterOffset still defaults TRUE — silence here is a claim
[ OK ] the tone controls are HIDDEN, not offered under the legacy shape
[ OK ] the production backend source is readable — the next assertion needs it
[FAIL] and Hidden is STATED, not inherited from the struct's identical default
[ OK ] Legacy offers CTCSS ENCODE — that is what the HL2 was claiming
[ OK ] and no tone vocabulary or DTCS codes are published to go with it
/Users/stanclaes/Repos/on8st/wt/bundleA-declares/build/hl2_fm_controls_declaration_test: 1 failure(s)
   restore: build rc=0, hl2_fm_controls_declaration_test exit=0 (0 failing)

M-reformat — THE CONTROL FOR THAT CHANGE, and the point of making it. Wrap the statement the way clang-format would, leaving the declaration entirely intact:

    c.fmTonePresentation =
        FmTonePresentation::Hidden;

It must stay green, and it does:

-- M-reformat - WRAP the c.fmTonePresentation statement as clang-format would (must stay GREEN)
[2/6] Building CXX object CMakeFiles/aethercore.dir/src/core/control/ModelReceiveControlTarget.cpp.o
[3/6] Building CXX object CMakeFiles/aethercore.dir/src/core/backends/hl2/Hl2Backend.cpp.o
hl2_fm_controls_declaration_test exit=0  failing assertions=0
[ OK ] this is the HL2 descriptor (sanity, not the subject)
[ OK ] FM and NFM are RECEIVE-ONLY here — the radio will not key in them
[ OK ] FM is STEERABLE and still unkeyable — receive control and receive-only agree
[ OK ] and the NFM alias is receive-ONLY but not requestable — the two lists differ on purpose
[ OK ] the HL2 declines the repeater offset: there is no verb behind it
[ OK ] hasFmRepeaterOffset still defaults TRUE — silence here is a claim
[ OK ] the tone controls are HIDDEN, not offered under the legacy shape
[ OK ] the production backend source is readable — the next assertion needs it
[ OK ] and Hidden is STATED, not inherited from the struct's identical default
[ OK ] Legacy offers CTCSS ENCODE — that is what the HL2 was claiming
[ OK ] and no tone vocabulary or DTCS codes are published to go with it
/Users/stanclaes/Repos/on8st/wt/bundleA-declares/build/hl2_fm_controls_declaration_test: 0 failure(s)
   restore: build rc=0, hl2_fm_controls_declaration_test exit=0 (0 failing)

The old literal form would have turned red on that reflow while the declaration stood — and a red that means "the file was reformatted" trains a reader to ignore the one that means "the declaration is gone". The two runs together are the deletion coverage kept and the formatting coupling removed.

The mode list, and whether anything consumes it — ALL RE-RUN after the FM ruling

The hl2DeclaredModesDriveTheControlPlane() negative controls use DRM specifically so this PR took no position on FM. FM has now been ruled, so every mutant below was re-measured rather than quoted, and one of them did go toothless — that is reported, not hidden.

M4a / M4b / M4c — drop exactly ONE mode from Hl2Backend::capabilities()'s receiveModeControl. Four assertions die in each case now rather than three: the membership check, the menu/control-plane agreement check, and the two outcome assertions for that mode (the observed read and the requested read fail separately, because they are separate refusals in ModelReceiveControlTarget).

-- M4-DSB - drop DSB from Hl2Backend::capabilities() receiveModeControl
[2/6] Building CXX object CMakeFiles/aethercore.dir/src/core/control/ModelReceiveControlTarget.cpp.o
[3/6] Building CXX object CMakeFiles/aethercore.dir/src/core/backends/hl2/Hl2Backend.cpp.o
control_receive_test exit=1  failing assertions=4
[FAIL] HL2 declares DSB, CWL and FM, which its demodulator has
[FAIL] every mode the HL2 mode MENU offers is steerable -- no menu entry strands a slice
observed DSB, requested LSB: expected result, got capability.unavailable
[FAIL] a slice observed in DSB is steerable out of it -- the HL2 declares DSB
observed USB, requested DSB: expected result, got request.out_of_range
[FAIL] and DSB can be ASKED for, not only sat in
   restore: build rc=0, control_receive_test exit=0 (0 failing)

-- M4-CWL - drop CWL from Hl2Backend::capabilities() receiveModeControl
[2/6] Building CXX object CMakeFiles/aethercore.dir/src/core/control/ModelReceiveControlTarget.cpp.o
[3/6] Building CXX object CMakeFiles/aethercore.dir/src/core/backends/hl2/Hl2Backend.cpp.o
control_receive_test exit=1  failing assertions=4
[FAIL] HL2 declares DSB, CWL and FM, which its demodulator has
[FAIL] every mode the HL2 mode MENU offers is steerable -- no menu entry strands a slice
observed CWL, requested LSB: expected result, got capability.unavailable
[FAIL] a slice observed in CWL is steerable out of it -- the HL2 declares CWL
observed USB, requested CWL: expected result, got request.out_of_range
[FAIL] and CWL can be asked for
   restore: build rc=0, control_receive_test exit=0 (0 failing)

-- M4-FM - drop FM from Hl2Backend::capabilities() receiveModeControl (NEW: the mode this ruling added)
[2/6] Building CXX object CMakeFiles/aethercore.dir/src/core/control/ModelReceiveControlTarget.cpp.o
[3/6] Building CXX object CMakeFiles/aethercore.dir/src/core/backends/hl2/Hl2Backend.cpp.o
control_receive_test exit=1  failing assertions=4
[FAIL] HL2 declares DSB, CWL and FM, which its demodulator has
[FAIL] every mode the HL2 mode MENU offers is steerable -- no menu entry strands a slice
observed FM, requested LSB: expected result, got capability.unavailable
[FAIL] a slice observed in FM is steerable out of it -- the menu can put it there
observed USB, requested FM: expected result, got request.out_of_range
[FAIL] and FM can be ASKED for, not only sat in
   restore: build rc=0, control_receive_test exit=0 (0 failing)

M4-CWU IS NOW TOOTHLESS, AND IT SHOULD BE. Re-running the old M4-CWU mutant — drop CWU from the list — produces zero failures, because §4b took CWU off the list. The mutation is a no-op against this tree. It is reported rather than quietly dropped:

-- M4-CWU - drop CWU from Hl2Backend::capabilities() receiveModeControl
[2/6] Building CXX object CMakeFiles/aethercore.dir/src/core/control/ModelReceiveControlTarget.cpp.o
[3/6] Building CXX object CMakeFiles/aethercore.dir/src/core/backends/hl2/Hl2Backend.cpp.o
control_receive_test exit=0  failing assertions=0
   restore: build rc=0, control_receive_test exit=0 (0 failing)

M8 — its replacement: PUT CWU BACK on the list. This is the mutant that matters now, and it is what gives the wedge invariant teeth:

-- M8-CWU-back - PUT CWU BACK on receiveModeControl - the wedge the canonicalisation forbids (NEW)
[2/6] Building CXX object CMakeFiles/aethercore.dir/src/core/control/ModelReceiveControlTarget.cpp.o
[3/6] Building CXX object CMakeFiles/aethercore.dir/src/core/backends/hl2/Hl2Backend.cpp.o
control_receive_test exit=1  failing assertions=4
[FAIL] and nothing is requestable that the menu cannot display
[FAIL] declared mode CWU is its own canonical spelling -- setSliceMode will publish back exactly what was asked for
observed USB, requested CWU: expected request.out_of_range, got result
[FAIL] the CWU spelling is declined, not silently rewritten under the client
observed CWU, requested LSB: expected capability.unavailable, got result
[FAIL] an alias observation would latch -- unreachable today, and pinned so it stays so
   restore: build rc=0, control_receive_test exit=0 (0 failing)

Four assertions die: the menu/control-plane agreement in the declared-but-unoffered direction, the canonicalOfferedMode(m) == m invariant for CWU, and both refusals that say the alias is declined rather than silently rewritten under the client.

M7 — remove the canonicalisation from Hl2Backend::setSliceMode, leaving the declaration exactly as it is. This is the half a list assertion cannot see at all:

-- M7 - remove the canonicalOfferedMode() collapse from Hl2Backend::setSliceMode (NEW)
[2/6] Building CXX object CMakeFiles/aethercore.dir/src/core/control/ModelReceiveControlTarget.cpp.o
[3/6] Building CXX object CMakeFiles/aethercore.dir/src/core/backends/hl2/Hl2Backend.cpp.o
control_receive_test exit=1  failing assertions=3
[FAIL] HL2 collapses the CWU spelling onto CW -- the alias never reaches a slice
[FAIL] and what a slice ends up holding is a spelling the mode menu can display
[FAIL] and NFM collapses onto FM for the same reason, at the same seam
   restore: build rc=0, control_receive_test exit=0 (0 failing)

M5 — strip the modes.contains(*observed.mode) term out of ModelReceiveControlTarget::checkSlice, leaving every declaration in this PR intact. The list is still declared, still read back, still contains all ten strings — and the refusal the whole of §4 argues about is gone:

-- M5 - strip modes.contains(*observed.mode) from ModelReceiveControlTarget::checkSlice
[2/6] Building CXX object CMakeFiles/aethercore.dir/src/core/control/ModelReceiveControlTarget.cpp.o
[3/6] Building CXX object CMakeFiles/aethercore.dir/src/core/backends/hl2/Hl2Backend.cpp.o
control_receive_test exit=1  failing assertions=3
[FAIL] refusal has expected code and dispatches no backend intent
observed CWU, requested LSB: expected capability.unavailable, got result
[FAIL] an alias observation would latch -- unreachable today, and pinned so it stays so
observed DRM, requested LSB: expected capability.unavailable, got result
[FAIL] negative control: an UNDECLARED observed mode latches the slice shut
   restore: build rc=0, control_receive_test exit=0 (0 failing)

M6 — the other half of the same question: neutralise setMode's own modes.contains(mode) test, leaving checkSlice intact:

-- M6 - neutralise modes.contains(mode) in ModelReceiveControlTarget::setMode
[2/6] Building CXX object CMakeFiles/aethercore.dir/src/core/control/ModelReceiveControlTarget.cpp.o
[3/6] Building CXX object CMakeFiles/aethercore.dir/src/core/backends/hl2/Hl2Backend.cpp.o
control_receive_test exit=1  failing assertions=4
[FAIL] refusal has expected code and dispatches no backend intent
observed USB, requested CWU: expected request.out_of_range, got result
[FAIL] the CWU spelling is declined, not silently rewritten under the client
observed USB, requested NFM: expected request.out_of_range, got result
[FAIL] and the NFM spelling likewise
observed USB, requested DRM: expected request.out_of_range, got result
[FAIL] negative control: an UNDECLARED requested mode is declined, slice unharmed
   restore: build rc=0, control_receive_test exit=0 (0 failing)

Being exact about which assertions die in M5 and M6. refusal has expected code and dispatches no backend intent is pre-existing: modeAndFilterOrdering() already reported a slice in RADE and expected capability.unavailable, and separately requested RADE expecting request.out_of_range, so control_receive_test was not blind to either mutation before. What it lacked was a line phrased about the HL2's own declared list rather than the fixture's synthetic {USB, LSB, AM}. That is the gap closed, and it is smaller than "nothing caught it".

The capability ratchet is UNMOVED at 71

tools/check_capability_records.py freezes the population of direct bool data members of struct RadioCapabilities at FROZEN_BOOL_COUNT = 71 (shrink-only; raising it needs a maintainer ruling on #5262). Re-derived on both sides by running the checker:

tree	result
origin/main 7c8fdf84	capability-records: 71 boolean(s), at the frozen 71 — ok (shrink only) · exit 0
this branch	capability-records: 71 boolean(s), at the frozen 71 — ok (shrink only) · exit 0

It cannot move: the ratchet's only input is RadioCapabilities.h, and git diff --quiet origin/main HEAD -- src/core/backends/RadioCapabilities.h is clean on this tree, so the two runs above read byte-identical input. Both new declarations assign fields that already exist.

The count that does move is a different, unratcheted one — the number of capability fields Hl2Backend::capabilities() declares explicitly: 87 → 88 distinct fields (88 → 89 assignment sites; txPowerBands is assigned twice), the single addition being hasFmRepeaterOffset. An earlier revision of this section said 89 → 90; that was wrong and is corrected here. Re-derived after the rebase by brace-matching the function body on both origin/main 7c8fdf84 and this branch rather than recalled, and unchanged by this revision — the FM/CWU work edits the contents of c.receiveModeControl, not the number of assignment sites. Of the 71 header bools, the HL2 declares 57 and inherits 14, against 56/15 on origin/main. There is no guard on that today.

What these targets do NOT observe

Each test file says this in its own prose; it belongs here too, because the gap between the two is the first thing a reviewer finds.

• The two widgets are never constructed. §1 and §2 quote VfoWidget::configureFmToneControls and RxApplet::configureFmToneControls reading these fields. That coupling is read from source, not exercised — no test in this tree builds either widget, so nothing here proves a consumer honours the declaration. It is four lines a reader can check; it is not a measurement.
• fmTonePresentation's value assertion cannot fail on a deletion, because the struct default is Hidden as well. The source-text assertion covers deletion; what it cannot see is whether the statement it finds is the last one to run — a second assignment further down would beat it unnoticed. That assertion is now a whitespace-tolerant pattern rather than a literal substring (c\.fmTonePresentation\s*=\s*FmTonePresentation::Hidden\s*;), so a clang-format reflow can no longer turn it red while the declaration is intact — a red that means "the file was reformatted" trains a reader to ignore the one that means "the declaration is gone". M-reformat below measures both directions.
• fmToneModes is inherited-empty, not declared. The assertion that no tone vocabulary is published holds on origin/main too; it is a consistency check against Hidden, not evidence of this change.
• The passband assertions reach defaultPassbandForMode(), not modeFromString(). The WDSP mode enumerator goes to a DSP object a pre-connect backend does not have, so it never appears in a SliceDelta. Delete DSB from modeFromString() and it would silently demodulate as USB while every assertion here still passed.
• Nothing distinguishes the CWL and CWU detectors. They share one defaultPassbandForMode() entry by design — the pitch lives in the BFO — so the sideband difference is invisible in a SliceDelta.
• The outcome target's backend records intents; it does not demodulate. hl2DeclaredModesDriveTheControlPlane() shows the declaration is read and obeyed by the production control target. That the radio serves the mode rests on modeFromString() and defaultPassbandForMode(), and on nothing measured on hardware.
• receiveFilterControl stays narrower than receiveModeControl, and this change widens that gap further. The filter list carries USB/DIGU/LSB/DIGL/AM/SAM and is byte-identical to origin/main — CW was already declared for mode control with no filter entry of its own. So a slice observed in DSB, CW, CWL, CWU, FM or NFM can now be steered out of that mode, while slice.setFilter is refused capability.unavailable for it. That refusal is not self-latching — changing the mode is still available and restores filter control — so it is strictly better than the state this PR replaces, but it is a real asymmetry, it is larger after §4a, and it is not repaired here.
• The canonicalisation is asserted at the backend seam, not through a widget. setSliceMode collapsing CWU→CW is observed as a SliceDelta, and the assertion that the result is a spelling publishedModeStrings() carries is what stands in for "the combo can display it". The findText() behaviour that makes that matter is read from VfoWidget::setSlice and RxApplet::connectSlice, not exercised — no test in this tree builds either widget.
• Nothing here was measured on a radio. No transmit behaviour changes.

Build and tests

• Rebased onto current origin/main 7c8fdf84, which had moved seven commits under this branch — including a change to Hl2Backend.cpp itself (feat(gui): make SmartMTR's meter ballistics project canon. Principle XI. #5847/meters). Everything below was measured after that rebase, on this tree.
• -G Ninja, RelWithDebInfo, -DCMAKE_IGNORE_PREFIX_PATH="/opt/homebrew;/opt/local", -DCMAKE_PREFIX_PATH=/Users/.../Qt/6.8.3/macos, -DENABLE_ASR=OFF. Full configure + full build from a clean tree: 0 errors.
• AETHER_HL2_TX_TXA=1 and HAVE_HIDAPI absent from this build's build.ninja — no hidapi reachable under the mandated ignore-prefix on this host, so the optional-off path is what was compiled here. Re-derived on this tree, not recalled: grep -c HAVE_HIDAPI build/build.ninja → 0.
• ctest -R '^(hl2_|control_receive_test)' over the 50-test subset, every target rebuilt on this tree: 100% tests passed, 0 tests failed out of 50 (Total Test time (real) = 200.73 sec). That is the subset built, not the whole suite; I am not quoting a figure I did not measure.
• backend_seam_affinity_test is GREEN now, and that is a correction to this PR's previous claim. An earlier revision reported it red and not ours (51 probed, 52 declared; unprobed: autoRfGainArmSettled). fix(ci): repair main after 03ddf480 — probe autoRfGainArmSettled. Principle XI. #5865 landed on main and fixed it, and the rebase picked that up — re-derived by building and running the target on this tree: 0 failure(s). There is no known-red disclaimer left on this branch.

🤖 Generated with Claude Code

[aethersdr-agent]

Reviewed against the PR head checkout at /tmp/aetherclaude/pr-5879. I went after the two central claims — "these controls reach nothing" and "the declaration is what strands the slice" — and both hold up under reading. Everything below is reasoned from code; I have no build and ran nothing, so no runtime claim here was reproduced.

1. Issue fit

No fixes/closes issue is linked and a search for HL2 + CTCSS/repeater turns up only the Icom repeater/CTCSS work (#5120, #5140, #5149, #5203, #5293) — nothing about the HL2. Reviewed against the PR's own stated intent. GOVERNANCE.md does not want an RFC for this: no new capability field, no protocol verb, no new public surface. It changes two declared values on one backend and widens one already-published list, which is the bug-fix-with-a-clear-root-cause case that is explicitly exempt.

The intent is met, and the premises check out in the tree:

• RadioCapabilities.h:488 — hasFmRepeaterOffset = true by default, so the HL2's silence really was a claim. RadioCapabilities.h:521 — fmTonePresentation defaults to Hidden, which is exactly why the second (source-text) assertion in the new target is needed and not padding.
• legacyFmToneModes() (RadioCapabilities.h:259) is {off, ctcss_tx} — transmit-only vocabulary, so Legacy on the HL2 was offering CTCSS encode and nothing receive-side is withdrawn by going to Hidden. I checked both consumers: RxApplet.cpp:2082/2126 and VfoWidget.cpp:6397 gate purely on the presentation value; no receive control reads either field.
• c.receiveOnlyModes at Hl2Backend.cpp:2108 does carry both FM and NFM, so the argument really does rest on the guard rather than on AETHER_HL2_TX_TXA.
• ModelReceiveControlTarget.cpp reads the list exactly twice, as described: :79 (requested) and :186 (observed, inside checkSlice, which is the first statement of setMode at :75). The self-latch is real.
• defaultPassbandForMode() at Hl2Backend.cpp:264 (DSB {-3000,3000}) and :259-260 (CW/CWU/CWL {-250,250}) match the numbers the test asserts. publishedModeStrings() does offer DSB and CWL from the combo, so the stranding was reachable without CAT or TCI.
• tools/check_capability_records.py --strict on the head tree: 71 boolean(s), at the frozen 71 — ok (shrink only), rc 0. The ratchet is unmoved, as it must be for a value change.
• No existing test asserts HL2 Legacy or pins the HL2 mode list by equality, so nothing in the suite is silently invalidated. All five checks are green on ac69d1a4 (noting that every ctest in ci.yml is -R-filtered, so green covers a subset).

2. Scope

File / group	What it changes	Claimed by the title/body?	Verdict
src/core/backends/hl2/Hl2Backend.cpp	hasFmRepeaterOffset=false, fmTonePresentation=Hidden, +3 modes on receiveModeControl, comment blocks	Yes, both halves	In scope
docs/architecture/radio-capabilities-map.md	HL2 fmTonePresentation cell → Hidden; new hasFmRepeaterOffset bullet; new test paragraph	Yes — AGENTS.md requires the caps-map entry	In scope
docs/aetherd-local-receive-control.md	HL2 mode row gains DSB/CWU/CWL	Yes	In scope. The filter-cut column is correctly left alone — see nit 4
tests/hl2_fm_controls_declaration_test.cpp + tests.cmake	New socket-free declaration target, registered in AETHER_SETTINGS_CONSUMERS	Yes	In scope, correctly registered
tests/control_receive_test.cpp	Membership + passband assertions, and a new control-plane target	Yes	In scope

Everything in the diff is explained by the stated fix. No new capability field, no protocol verb, no config key, no default the operator chose being moved. No - line removes a guard: the only deletion is c.fmTonePresentation = FmTonePresentation::Legacy;, replaced by a stricter value. No CHANGELOG.md entry — correct.

Preference check: this is a fix, not a preference. The authority it points at is in the tree — IRadioBackend::setSliceRepeaterOffsetDir / setSliceFmRepeaterOffset / setSliceFmToneMode are empty virtuals Hl2Backend never overrides, and receiveOnlyModes already refuses keying. Both RtlSdrBackend.cpp:143 and IcomCivBackend.cpp:412 decline the same flag for the same reason, so the HL2 is now consistent with its siblings rather than novel.

Socket-test disclosure: none. Neither test file references QTcpServer/QTcpSocket/QUdpSocket/QLocalServer/bind/listen/connectToHost, no fake peer, no event loop. hl2_fm_controls_declaration_test constructs a backend and reads capabilities(); control_receive_test drives the in-process ControlService. Nothing to record.

3. Blockers

None.

4. Nits (all non-blocking)

1. The withdrawal misses one duplex control: REV. hasFmRepeaterOffset gates the spin and ±/Simplex in both widgets, but not m_revBtn / m_fmRevBtn, which sits in the same row and writes m_slice->setTxOffsetFreq(...) (RxApplet.cpp:879-887). hasTransmitFrequencyCheck is ❌ for the HL2, so configureRepeaterReverseControl() (VfoWidget.cpp:6474-6486) keeps it labelled REV and checkable — i.e. after this PR one repeater-duplex control stays live on a radio the PR has just declared has no duplex verb. Not a regression and arguably a widget change rather than a declaration change, but the title says "withdraw the FM repeater-duplex … controls", and this one survives. Inline.
2. FM is the one menu-offered mode the new list still strands. publishedModeStrings() is {LSB USB DSB CWL CW FM AM SAM DIGU DIGL}; the new receiveModeControl covers all of them except FM. So after this change, exactly one mode an operator can pick from the combo still latches slice.setMode shut over the control plane. The comment's exclusion argument is about whether FM is served, which is a different (and correct) question from whether a slice sitting in it can be steered out. Worth a sentence, or an issue. Inline.
3. The "hide the container outright" sentence is half right. VfoWidget does hide a container (m_fmToneContainer->setVisible(...), VfoWidget.cpp:6398); RxApplet hides individual children and says so itself at RxApplet.cpp:3100. Same visible outcome, so this is wording in a comment that is otherwise unusually precise. Inline.
4. DSB/CWL/CWU have no receiveFilterControl entry, so a slice steered into one over the control plane gets capability.unavailable for slice.setFilter (ModelReceiveControlTarget.cpp:194). Pre-existing for CW, and docs/aetherd-local-receive-control.md's cut column is correctly left narrower, so the docs already say this — just noting the surface got three modes wider.
5. The CWU passband assertion cannot fail the way its label implies. control_receive_test.cpp:510-513 sets CWU immediately after CWL, and both share {-250,250}, so if setSliceMode stopped adopting a passband the values left over from the previous line would satisfy it. Interleaving a non-CW mode (DSB → CWU → DSB → CWL) would give both spellings teeth. Inline.

5. What I tried to break, and couldn't

• "Receive is untouched." Read both configureFmToneControls() in full looking for a receive-side casualty of Hidden — a tone-squelch/CTCSS-decode path, an FM squelch, a deviation control. There is none: legacyFmToneModes() contains only off and ctcss_tx, m_toneRxValueCmb and the DTCS widgets are Ctcss-only and the HL2 publishes empty fmToneModes/fmDtcsCodes, and no demodulator setting reads either field. The claim survives.
• Pre-connect regression. Both widgets compute presentation as connected ? caps.fmTonePresentation : Legacy and repeaterAvailable as !connected || caps.hasFmRepeaterOffset, so the disconnected surface is identical to before — no "controls vanished before I connected" report lurking here.
• A test that passes against the unfixed code. hl2DeclaredModesDriveTheControlPlane() is the part I tried hardest to dismiss, and it holds: it transplants the HL2's own list onto the fixture and compares response codes, and its two negative controls (DRM observed → capability.unavailable, DRM requested → request.out_of_range) are the terms that die if either read is deleted. Its stated limitation is honest — the membership assertions at :480-483 alone would indeed survive stripping modes.contains(*observed.mode). The hasFmRepeaterOffset value assertion fails on deletion (default is the opposite); the fmTonePresentation one does not, which is why the source-text read at :138 is there and not padding.
• Fixture mechanics of the new target. Checked that a post-construction report() then params() re-reads the store revision (so no stale expectedRevision turning a pass into request.conflict), that a fresh Fixture per case keeps m_pendingModes from bleeding across, and that the pattern mirrors the existing modeAndFilterOrdering() at :290-291. It does.
• Alias duplication in a published list. receiveModeControl.modes is republished verbatim to clients by RadioResourceAdapter.cpp:107, so listing CW and CWU shows both to a remote client. Precedent settles it: Flex publishes FM+NFM, RTL publishes FM+FMN and CW+CWR. Consistent, not a finding.
• Collateral in the suite. Grepped every fmTonePresentation / hasFmRepeaterOffset / receiveModeControl reference in tests/; the only existing assertions are Icom's, and nothing pins the HL2 mode list by equality. Ran the capability ratchet for real (rc 0, 71/71).
• What I could not check: that the widgets visually do the right thing — no test in this tree constructs either one, and I cannot drive a GUI. The REV gap in nit 1 is read from the wiring, not observed. Nothing here was measured against an HL2.

6. Recommendation

Approve with nits. Every premise the change rests on is verifiable in the tree, the two declarations move toward the truth rather than toward a preference, the ratchet is unmoved, and the new coverage is unusually honest about its own reach — including where an assertion cannot fail on a deletion, which is the failure mode most declaration tests hide. Nits 1 and 2 are the ones worth a reply: REV is the same class of dead-but-live control the PR exists to remove, and FM is the last menu-offered mode that still latches the control plane shut. Neither needs to land here — a sentence in the comment plus a follow-up issue would close both honestly. Maintainer call on whether to fold nit 1 in now, since it is a widget change rather than a declaration one.

Nice work on the source-text assertion; that is the right answer to a field whose default equals the value you want to pin.

---

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

[aethersdr-agent]

Antares Detector — candidate vulnerable file(s)

• src/core/backends/hl2/Hl2ModeVocabulary.h

modeFromString maps arbitrary strings to concrete demodulator modes and frequency ranges without an explicit validation of allowed values, enabling untrusted input from external sources (e.g., control messages or saved documents) to select FM/NFM/CTCSS tones or other dangerous operations.

_{Localized by Cisco Foundation AI Antares-1B running locally in the AetherClaude sandbox, seeded by the Cartographer security map. Advisory only — please verify before acting.}

---

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

[ten9876]

Issue fit

No linked issue; the PR corrects three HL2 capability declarations and is a bug fix with a clear root cause (GOVERNANCE.md exempts that from an RFC). The three claims — hasFmRepeaterOffset inherited true from the struct with no verb behind it, fmTonePresentation declared Legacy which offers ctcss_tx on a radio that cannot key FM, and receiveModeControl missing DSB/CWL/CWU so that a slice observed in one of them is latched shut by ModelReceiveControlTarget::checkSlice — I verified each against origin/main (list under "What I tried to break"). All three hold, and the fix is the declaration-shaped one canon asks for: fields that already exist, the caps-map doc updated, a gating test per declaration, ratchet untouched at 71.

Built and run here, with the body's mutations replayed. Every one reproduces exactly. Details below.

Scope

File / group	What it changes	Claimed by title/body?	Verdict
src/core/backends/hl2/Hl2Backend.cpp (+122/−3)	hasFmRepeaterOffset = false, fmTonePresentation = Hidden, three modes added to receiveModeControl, with the reasoning inline	Yes	In scope
tests/hl2_fm_controls_declaration_test.cpp (new) + tests.cmake	Pins both FM declarations, the struct default, and — by reading Hl2Backend.cpp — that Hidden is stated rather than inherited; joins AETHER_SETTINGS_CONSUMERS	Yes	In scope
tests/control_receive_test.cpp (+155)	Passband assertions for the three modes, and hl2DeclaredModesDriveTheControlPlane() which asks the real ControlService and asserts response codes with two negative controls	Yes	In scope
docs/architecture/radio-capabilities-map.md, docs/aetherd-local-receive-control.md	Caps-map row and prose for the two FM fields; HL2 mode column in the receive-control table	Yes	In scope — the caps-map update the ADDING-A-FIELD contract expects

Two commits, both authored 2026-09-20, both signed. Socket-free (Hl2Backend constructed bare; control_receive_test's fixture backend records intents). No RadioCapabilities.h change, so the ratchet cannot move (check_capability_records.py --strict: 71/71 on both trees). No CHANGELOG. #5554 notice walked: no new family-string branch, no new raw wire text, no dynamic_cast, and the change withdraws two capabilities with no verb behind them, which is the direction that notice wants. Bias check: every change moves a control toward what the backend can actually do; fix, not preference. Everything in the diff is explained by the title.

Blockers

None.

Findings (non-blocking)

1. Admitting CWU on the list also admits it on the requested-mode read. The body is explicit that CWU is added "for the same second reading, not to offer a third CW button" — the observed-mode latch. But ModelReceiveControlTarget::setMode uses the same list at :79, so a control-plane client can now slice.setMode mode="CWU" and Hl2Backend::setSliceMode stores it verbatim, where before this PR that request was refused request.out_of_range. The mode combo then does not follow: VfoWidget.cpp:4543-4544 does findText(cur) and moves only on a hit, so the combo stays on whatever it showed while the receiver is in CW. That hazard already exists through CAT and TCI (the body says so) — this PR adds a third route where the control plane used to refuse. Cheapest fix that keeps the latch closed: canonicalise the requested mode (canonicalOfferedMode()) before the contains() in setMode, or accept alias spellings only on the checkSlice read. Inline. (Automated pass; verified against the two reads and the combo code.)

Nits (non-blocking)

• The REV (reverse-offset) toggle is not gated on hasFmRepeaterOffset in either widget: configureRepeaterReverseControl reads only usesTransmitFrequencyCheck() and nothing sets the REV button's enabled state from the flag, so on the HL2 (and RTL-SDR, which declares false today) it stays a live control moving an offset nothing consumes. Not this declaration's fault — it is the shared widget's — and it wants its own issue rather than a per-backend fix. (Automated pass; verified.)
• The caps-map rule and the new test disagree. radio-capabilities-map.md:767-768 says of these declaration targets "Every assertion reads a capability — never caps.family, never a backend type", and the new paragraph sits right under it; the new test's first assertion is caps.family == "hl2" (as hl2_pan_limits_declaration_test also does). It is labelled "sanity, not the subject", which is fair — soften the doc sentence to say so, or drop the line. Inline. (Automated pass; verified.)
• The source-text assertion is brittle to formatting. backendText.contains("c.fmTonePresentation = FmTonePresentation::Hidden;") goes red on a clang-format wrap or an added qualifier while the declaration is intact. The body is candid about why it exists (Hidden is also the struct default) and rf_gain_presentation_test set the precedent, so this is a known trade; a regex tolerant of whitespace would keep the deletion coverage without the formatting coupling. Inline.
• Squash title. The first commit is feat(hl2): while the PR title is fix(hl2):; the title is what lands. It also lacks the Principle <N>. suffix AGENTS.md line 97 asks for — Principle VIII is the obvious one. Fixable in the merge dialog.
• The receiveFilterControl asymmetry the body discloses (a slice in DSB/CW/CWL/CWU is steerable but slice.setFilter is refused for it) is real and pre-existing for CW; it wants its own issue so it does not vanish.
• The ModelReceiveControlTarget::available any-slice OR the body names is likewise not this PR's to fix, and likewise worth an issue.

What I tried to break

Built the PR head (ac69d1a4) in a scratch worktree: hl2_fm_controls_declaration_test and control_receive_test. No bridge session — the HL2 backend is not reachable from the demo simulator, and the two widget readers (VfoWidget::configureFmToneControls, RxApplet::configureFmToneControls) are not constructed by any test, exactly as the body says; that coupling is read, not exercised.

• Head: both targets 0 failure(s), exit 0.
• M1b-tone — delete c.fmTonePresentation = Hidden;: exit 1, one failure, and Hidden is STATED, not inherited from the struct's identical default, with the value assertion staying green — the exact gap the body describes and the source-text line closes.
• M4-DSB — drop DSB from receiveModeControl: exit 1, three failures (membership, observed-DSB steerable, DSB requestable). Matches the body.
• M5 — strip modes.contains(*observed.mode) from checkSlice with every declaration intact: exit 1, two failures including negative control: an UNDECLARED observed mode latches the slice shut. So the outcome test sees the consumer, not only the list. Matches the body. Recompiles of the mutated TU confirmed in each ninja log; restored and green.
• Every source claim: RadioCapabilities.h:488 defaults hasFmRepeaterOffset = true and :521 defaults fmTonePresentation = Hidden; legacyFmToneModes() at :259; both widgets read caps.hasFmRepeaterOffset and legacyFmToneModes() (RxApplet.cpp:2044,2069, VfoWidget.cpp:6362,6385); Hl2Backend.h overrides none of the seven FM setters; RtlSdrBackend.cpp:143 and IcomCivBackend.cpp:412 decline the offset as described; publishedModeStrings() offers DSB and CWL; modeFromString maps DSB→Dsb, CWL→Cwl; defaultPassbandForMode has {-3000,3000} and {-250,250}; receiveOnlyModes carries FM/NFM; refuseKeyInReceiveOnlyMode() sits in the TX coordinator; applyRestoredState runs canonicalOfferedMode(); ModelReceiveControlTarget.cpp:79 and :186 are the two reads. All hold.
• CI freshness: runs created 2026-09-20T23:14Z, main moved at 00:56Z next day; nothing in between touches Hl2Backend.cpp, src/core/control/, the caps map or control_receive_test.cpp.
• An automated review pass ran at medium effort; anything it found that I could confirm is folded in with attribution.

Recommendation

Approve with nits. Three wrong declarations corrected in the shape canon wants, each pinned by a test that dies under the mutation that matters, the consumer-side latch pinned through the real control service, and a body that states its own limits accurately. Fix the squash title at merge; the rest are follow-ups. Approval itself is the maintainer's call.

[on8st]

Both open design questions on this PR are now ruled, and both rulings are applied. The branch has also been rebased onto current origin/main (7c8fdf84), which moved under it — including #5865, so the backend_seam_affinity_test red this PR previously reported as "not mine" is gone rather than merely disclaimed.

One decision inside the ruling came out the other way, and it is the first thing to read. Applying the canonicalisation made keeping CWU on receiveModeControl actively unsafe, so it has been removed and NFM was never added — the list is now the ten modes the menu offers and nothing else.

ModelReceiveControlTarget::setMode records the requested string (m_pendingModes.insert(slice, mode)) and releases it only on an observation comparing equal to it. While that entry stands, checkSlice refuses every further Mode and Filter intent on the slice with request.conflict, and the only things that clear it are a disconnect, backendRebuilt, and the slice's destruction. So with the backend canonicalising, slice.setMode mode="CWU" would be accepted, publish back "CW", never match, and wedge that slice's mode and filter control until the radio disconnects — a strictly worse self-latch than the one this PR removes.

Removing the aliases costs no steerability: after this change there are exactly two writers of Receiver::mode (setSliceMode and the restore path, whose m_restoredState.mode is already canonicalOfferedMode()'s output), so no slice can be observed in CWU or NFM at all. The request read declines them request.out_of_range, which is the honest answer — refusing one intent beats wedging the slice. The guard is asserted as an invariant rather than as a list: every declared mode is its own canonical spelling, and M8 in the body is that mutant.

The other route — keeping the alias entries and making the pending-mode interlock tolerant of a backend that rewrites what it was asked for — is a change to generic control-plane code and a genuinely separate question. Happy to open it if reviewers prefer that shape.

Question 1 — should FM (and NFM) join receiveModeControl? Ruled YES, and on the observe ground rather than the demodulator one.

The gap was concrete: Hl2Backend::capabilities() publishes modeList from hl2::publishedModeStrings(), which carries FM, so the mode combo offers it. After the DSB/CWL/CWU additions the set difference between the menu and receiveModeControl was exactly {FM} — and this PR's own stated harm reads verbatim with FM substituted, because ModelReceiveControlTarget::checkSlice is the first statement of setMode and is therefore self-latching. Pick FM out of the combo and the slice could not be steered back out by any requested mode, including a listed one.

The ruling is not that the HL2 serves FM well. Every reservation in §5 is still true and still written beside the declaration. It is that a mode the radio's own menu puts on a slice must never latch the control plane shut — declaring it does not answer the deviation/squelch/AGC question, it stops the answer being "and the slice is stuck there". control_receive_test now derives the rule instead of restating it: it walks publishedModeStrings() and asserts every offered mode is declared, so a mode added to the menu later fails there rather than stranding an operator.

What that widens, said plainly: setMode shares the list, so slice.setMode mode="FM" is now accepted where it was refused request.out_of_range. Keying is unaffected, and that was checked rather than assumed — receiveOnlyModes carries FM and NFM, modeIsReceiveOnly() is a case-insensitive membership test on that list alone, RadioModel::refuseKeyInReceiveOnlyMode() runs inside beginTxActivity() (the common entry for MOX/TUNE/ATU/CWX) and forwardNonFlexCwKeying(), and receiveModeControl is read in only three places tree-wide — the two ModelReceiveControlTarget reads and RadioResourceAdapter's serialisation. Nothing on the transmit side reads it. hl2_fm_controls_declaration_test now pins both halves in one assertion, so if FM ever leaves receiveOnlyModes that line fails and §1/§2 reopen.

Question 2 — @ten9876's point about CWU on the requested-mode read. Ruled YES, fixed in Hl2Backend::setSliceMode.

You were right, and the route was exactly as you described: admitting CWU on the observe list admits it on the request read too, and setSliceMode stored it verbatim, so the combo — which moves only on a findText() hit against publishedModeStrings(), a list carrying "CW" alone — fell to index 0 while the receiver was really in CW. setSliceMode now runs the existing hl2::canonicalOfferedMode(), gated by isKnownModeString() exactly as applyRestoredState() already gates it, so an unknown string passes through untouched and not even upper-cased.

On the documented trade, because it deserved checking before overriding. Hl2ModeVocabulary.h does say "CAT, TCI and Hl2Backend::setSliceMode still put either spelling on the slice at run time" — but read in full that sentence is the justification for listing both spellings in receiveOnlyModes, a description of the behaviour offered as the reason the duplicate entries are needed. Nothing in the header relies on the verbatim store. Its load-bearing rule is the line immediately above: "Collapsing one spelling onto the other moves nothing across that boundary" — and hl2_mode_vocabulary_test already proves it for this exact change, walking every accepted spelling and asserting receiveOnlyModes.contains(m) == receiveOnlyModes.contains(canonicalOfferedMode(m)). So this narrows one clause of the decision rather than contradicting it, and the header has been updated in place to say so instead of leaving a sentence behind that is now false.

The mutants were re-run, not assumed to still hold — that was the other thing worth checking, since hl2DeclaredModesDriveTheControlPlane() chose DRM as its undeclared mode specifically so the PR took no position on FM. Full output is in the body; the short version is below.

The mutants, re-run rather than assumed. The negative controls use DRM specifically so this PR took no position on FM, so every one was re-measured after the ruling. Full output is in the body; the shape of it:

mutant	failing assertions
M4-DSB / M4-CWL / M4-FM — drop one declared mode	4 each (membership, menu agreement, observed read, requested read)
M4-CWU — drop CWU	0 — toothless, and correctly so: CWU is no longer on the list, so the mutation is a no-op
M8 — put CWU back on the list	4 — the replacement, and what gives the wedge invariant teeth
M7 — remove the canonicalisation from setSliceMode	3
M5 — strip modes.contains(*observed.mode) from checkSlice	3
M6 — neutralise modes.contains(mode) in setMode	4
M1b-tone — delete the fmTonePresentation statement	1
M-reformat — wrap that statement as clang-format would	0, and that is the point

M4-CWU going toothless is reported rather than quietly dropped, and M8 is its replacement.

The last pair is the source-text assertion on fmTonePresentation. It was a literal substring match, so a clang-format wrap turned it red while the declaration was intact — and a red that means "the file was reformatted" trains a reader to ignore the one that means "the declaration is gone". It is now the same three tokens with \s* between them: deletion still fails it, a reflow no longer does. Both directions measured.

Also in this push, because the canonicalisation falsified them: RadioCertification::stageModeMap() would have flagged CWU->CW and NFM->FM as "did not survive a round trip … becomes the default, usually USB" — the opposite of the truth — and its narrative opened "the slice keeps whatever string it is given". Both now name both causes. The HL2 rows in docs/aetherd-local-receive-control.md and docs/architecture/radio-capabilities-map.md, and the HL2 half of the CWU justification in VoiceModeGate.h, PhoneCwApplet.cpp and AetherDspModePolicy.cpp — comments only, no code, since Icom still produces CWU and all three spellings must stay.

Rebased onto 7c8fdf84, full clean build, ctest -R '^(hl2_|control_receive_test)' 100% passed, 0 failed out of 50. backend_seam_affinity_test is green now — #5865 fixed it on main and the rebase picked it up, so the known-red disclaimer this PR carried is retracted rather than restated.

🤖 Generated with Claude Code

[aethersdr-agent]

Thanks for this — the red on 2b86b04 is not your code. It is CI infrastructure, and nothing from this branch was ever compiled on the failing lane.

What actually failed

get_check_runs on 2b86b04043cffb85c6f03022465b285ca4bdb1ba gives 5 checks, 4 green:

check	conclusion
build (Linux)	✅ success
check-macos	✅ success
check-windows	❌ failure
Static checks	✅ success
Sanitizer option configures	✅ success

Inside check-windows (run 35618550826) the failed steps are:

• Setup hidapi (HID encoder support) — the one that broke the job
• sccache stats — a downstream consequence, see below

And here is the part that settles the attribution: every step after it is skipped.

Setup MSVC environment                              success
Setup hidapi (HID encoder support)                  FAILURE
Setup PortAudio (CW sidetone callback sink)         skipped
Test sccache health                                 skipped
Configure                                           skipped
Build                                               skipped
Test ThumbDV portability paths                      skipped
Test cross-needle meter geometry                    skipped

Configure never ran. Build never ran. No compiler was invoked against a single line of this PR on Windows, so the diff cannot be the cause. The sccache stats failure is the same story one step further on — Test sccache health was skipped, so the sccache server was never started and sccache --show-stats had nothing to talk to.

Why that step is fragile

.github/workflows/ci.yml:588-595 runs .\scripts\setup\setup-hidapi.ps1, which is a network fetch plus a from-source MSVC build of hidapi 0.14.0:

• scripts/setup/setup-hidapi.ps1:40-44 — Invoke-WebRequest against https://github.com/libusb/hidapi/archive/refs/tags/hidapi-0.14.0.tar.gz, then Confirm-Sha256 against the pin added in Pin + verify SHA256 for all third_party setup-script downloads (supply-chain hardening) #3665
• scripts/setup/setup-hidapi.ps1:76-81 — cmake -G Ninja + cmake --build, with a CMAKE_POLICY_VERSION_MINIMUM=3.5 override that exists only because hidapi 0.14.0's cmake_minimum_required is below CMake 4.x's floor
• scripts/setup/setup-hidapi.ps1:87-93 — a hard Write-Error "Failed to build hidapi.lib" if the artifact isn't found

The script also has no cache restore in front of it, unlike Qt / FFTW3 / DeepFilterNet3, so it hits the network on every Windows run. That makes it the job's most transient-failure-prone step by a distance: a GitHub archive hiccup, a runner-image CMake/MSVC bump, or a Ninja generator change all land here and look identical from the outside.

I deliberately have not quoted an error line — the check-runs API gives me step names and conclusions, not the raw log body, and I would rather say that than invent a plausible-looking message. If you open the job log and expand Setup hidapi, the last few lines will say which of the three it was (download / SHA256 mismatch / CMake or link failure) — worth pasting here if it turns out to be the SHA or the CMake policy, since those two are real and want a follow-up rather than a retry.

What to do

Push an empty commit or ask a maintainer to re-run the failed jobs. That is the whole fix if it was a transient fetch. No change to your branch is warranted on this evidence.

On the review comments

None of the reviewer feedback on this PR can be the cause — the Windows lane never compiled. For completeness, the open review points are all source-level and independent of CI:

• Hl2Backend.cpp:1801 — the REV button (RxApplet.cpp:879-887, VfoWidget::configureRepeaterReverseControl() at VfoWidget.cpp:6474-6486) is not covered by hasFmRepeaterOffset, so it survives the withdrawal. Reviewer explicitly said they would not insist it land here; a line in the comment saying REV is knowingly left, or a follow-up issue, closes it.
• Hl2Backend.cpp — "both widgets hide a container" is wording only; RxApplet.cpp:2082/:2126 hide individual children rather than m_fmContainer.
• Hl2Backend.cpp:2069 — FM remains the one menu-reachable mode this list strands. A sentence or an issue, not a code change.
• tests/control_receive_test.cpp — the CWU assertion can't fail as labelled because CWL precedes it with the same {-250, 250} passband. Re-setting DSB between the two CW legs gives it teeth.
• tests/hl2_fm_controls_declaration_test.cpp — @ten9876's contains() nit; a line-anchored, whitespace-tolerant QRegularExpression keeps the deletion coverage without matching a commented-out copy.

Worth doing on their own merits — just not related to the red.

Thanks again for the careful work here; the declaration-level withdrawal with a test that catches the deletion is exactly the right shape.

---

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

[on8st]

(Same note posted on #5894 — #5894 (comment) — because the fix can only land on whichever of the two merges second, and that is not decided yet.)

#5894 and #5879 collide: six HL2 cells in the feature matrix, and the gate that should catch it cannot

Found in a local integration build of our open PRs. Neither PR is wrong on its own, and neither can carry the fix alone — so this is a note, not a change request.

The interaction

• docs(architecture): radio feature register — where the click ends, per radio. Principle VIII. #5894 adds docs/architecture/radio-feature-matrix.{md,json} and tools/check_radio_feature_matrix.py. The checker derives each cell from the source and fails --strict when the committed record disagrees.
• fix(hl2): withdraw the FM repeater-duplex and CTCSS-encode controls the HL2 has no verb for, and declare the DSB/CWU/CWL its demodulator already serves #5879 assigns c.hasFmRepeaterOffset = false; and c.fmTonePresentation = FmTonePresentation::Hidden; in Hl2Backend::capabilities().

truthy() in the checker lists ::Hidden among NEGATIVE_ENUMERATORS, so once both land, both gating capabilities read false for the HL2, gate_state() returns HIDDEN, and six HL2 cells derive H where #5894's committed record says D or P.

There is no escape hatch in the record — the matrix has no "expected after" field, and the checker has no write mode (--strict / --print only).

What I measured

Four standalone trees, python3 tools/check_radio_feature_matrix.py --strict:

tree	committed HL2 FM cells	exit
origin/main	checker and matrix do not exist	n/a
#5879 alone	checker and matrix do not exist	n/a
#5894 alone	as committed (D D D D P P)	0
#5894 alone, cells changed to H	H x6	1 — 6 disagreements, mirror direction
#5894 + #5879	as committed	1 — 6 disagreements
#5894 + #5879, cells changed to H	H x6	0

The fourth row is the one that settles placement: putting the record update on #5894's branch today turns a currently-green PR red, because on its own base the source still derives D/P and the checker reports the same six cells in the opposite direction.

Summary line, before and after, in the combined tree:

W=143 D=94 P=7 R=22 H=84 U=9 V=7; 6 disagreement(s) with the source
W=143 D=90 P=5 R=22 H=90 U=9 V=7; 0 disagreement(s) with the source

How this surfaces — and the part that is worse than "the second one goes red"

tools/check_radio_feature_matrix.py --strict runs in exactly one place: a step in static-checks.yml. That workflow is pull_request-only — its own concurrency comment says "PR-only workflow ... ref is always refs/pull/N/merge" — and no push: main lane runs the checker (ci.yml, full-suite.yml, system-libs-canary.yml and codeql.yml are the push-to-main workflows; none of them invoke it).

ci.yml's header also records that "we dropped the 'Require branches up to date before merging' branch-protection bit". I could not read branch protection directly to re-confirm that, so both paths are worth stating:

• If branches need not be up to date — the likely case — both PRs are already green on merge refs computed before the other existed. The second one merges on that stale green, nothing re-runs the checker on main, and main goes red silently. The failure then appears on the next unrelated PR, whose merge ref inherits the broken main — a Static checks red attributed to a PR that did not cause it.
• If the second PR gets any new push after the first merges (a rebase, a review fixup), its Static checks re-runs against the new merge ref and goes red there, which is the visible, blocking case.

Either way the record update belongs on whichever PR merges second, applied after its branch carries the other's change:

• docs(architecture): radio feature register — where the click ends, per radio. Principle VIII. #5894 merges first → fix(hl2): withdraw the FM repeater-duplex and CTCSS-encode controls the HL2 has no verb for, and declare the DSB/CWU/CWL its demodulator already serves #5879 carries it.
• fix(hl2): withdraw the FM repeater-duplex and CTCSS-encode controls the HL2 has no verb for, and declare the DSB/CWU/CWL its demodulator already serves #5879 merges first → docs(architecture): radio feature register — where the click ends, per radio. Principle VIII. #5894 carries it.

Applied earlier than that, on either branch, it fails that branch's own --strict. There is no ordering in which it can be staged in advance.

The six cells

feature	HL2 now	HL2 after	gating capability
fm/tone-mode	D	H	fmTonePresentation
fm/tone-tx	D	H	fmTonePresentation
fm/tone-rx	D	H	fmTonePresentation
fm/dtcs	D	H	fmTonePresentation
fm/repeater-dir	P	H	hasFmRepeaterOffset
fm/repeater-offset	P	H	hasFmRepeaterOffset

Note that #5894's own matrix prescribes the change that breaks it: the P-provenance row's repair column reads "One assignment per backend: c.hasFmRepeaterOffset = false;". The code is the honest side here; the record is what goes stale.

H is what the source derives — not a ratified classification

To be explicit, because these are two different claims: H is measured, the output of gate_state() on the combined source. Whether H is the right vocabulary for "the backend declared the control off" on rows that previously read D and P is a judgement, and I am not asserting it. If a reviewer thinks these six should be recorded some other way, that changes the record, not the measurement — say so and I will rework it.

Specifically worth a second opinion: fm/repeater-dir and fm/repeater-offset move P → H, which removes the HL2 from the inherited-default class rather than repairing it in place. That is exactly what the repair column asked for, but it does mean the class the document teaches from loses its worked example (see the prose edits below).

Exact replacement values, so nobody re-derives them

docs/architecture/radio-feature-matrix.json — in each of the six feature objects, cells.hl2:

"fm/tone-mode":       "D" -> "H"
"fm/tone-tx":         "D" -> "H"
"fm/tone-rx":         "D" -> "H"
"fm/dtcs":            "D" -> "H"
"fm/repeater-dir":    "P" -> "H"
"fm/repeater-offset": "P" -> "H"

docs/architecture/radio-feature-matrix.md — the "FM repeater and tone" table (column order Flex | Icom | HL2 | ANAN | RTL | Demo); the HL2 column is the only one that moves:

| `fm/tone-mode` | W* | W | H | H | H | D | CTCSS / DTCS tone mode |
| `fm/tone-tx` | W* | W | H | H | H | D | TX tone frequency |
| `fm/tone-rx` | D | W | H | H | H | D | RX tone frequency |
| `fm/dtcs` | D | W | H | H | H | D | DTCS code and reverse flags |
| `fm/repeater-dir` | W* | W | H | P | H | P | repeater shift direction |
| `fm/repeater-offset` | W* | W | H | P | H | P | repeater offset (Hz) |

The MD/JSON agreement is mechanically enforced (feature-matrix-doc-drift), so both files move together or the gate stays red.

Four prose spots are not mechanically checked and go stale silently. Proposed wording:

1. Heading — change seven to five in:

   ## The seven `P` cells, by provenance
   

   The checker's own split confirms it: P/inherited-default drops from 6 to 4, leaving fm/repeater-dir and fm/repeater-offset on ANAN and Demo; P/cached-readback (rx/filter/rtl) is unchanged at 1.

2. Provenance table, inherited default row, cells column — `fm/repeater-dir` and `fm/repeater-offset` on HL2, ANAN and Demo (6) → ...on ANAN and Demo (4). And in the same row's "what it is" column, replace the HL2 sentence:

   Nobody decided to offer it. On the ANAN it is a repeater duplex control on a radio with no transmitter. The HL2 carried the same two cells until it made the assignment this column prescribes; both are now H.

3. The substantive one. The paragraph under "Reading a field's value as the discriminator..." uses the HL2 as its worked example of the D/P split — Legacy assigned explicitly so the tone verbs are D, hasFmRepeaterOffset never mentioned so the repeater rows are P, "two adjacent rows, opposite verdicts". After fix(hl2): withdraw the FM repeater-duplex and CTCSS-encode controls the HL2 has no verb for, and declare the DSB/CWU/CWL its demodulator already serves #5879 the HL2 has neither half and the example is simply false. It transplants to the Demo backend without any other change: SimBackend::capabilities assigns fmTonePresentation = FmTonePresentation::Legacy explicitly and never mentions hasFmRepeaterOffset, so Demo still reads D on the tone rows and P on the repeater rows. Proposed:

   turns the tone controls on; the Demo backend assigns Legacy explicitly, so it asked, and its unimplemented tone verbs are D. hasFmRepeaterOffset defaults to true and the Demo backend never mentions it, so it never asked, and the repeater rows one line below are P. Two adjacent rows, opposite verdicts, and only provenance separates them. The HL2 held both halves of this example until it declared Hidden and false outright; all six of its FM rows are now H.

4. The unfiled-findings table, row 8 (AnanBackend) — "One line fixes it; the same shape holds on HL2 and Demo." → "One line fixes it; the same shape still holds on Demo."

With all of the above applied to the combined tree, --strict exits 0 and reports 0 disagreement(s) with the source. Verified locally; no build was run, this is Python and docs only.

Separately, and not for this PR: a gate whose only lane is pull_request cannot see a two-PR interaction until a third PR pays for it. If check_radio_feature_matrix.py --strict is worth blocking merges on, it is probably worth a push: main lane too. Happy to open that as its own issue if you want it.

[on8st]

The red check-windows on this head is not this PR — it is a transient CDN failure, and I cannot re-run it myself.

The job died at step 14 of 28, "Setup hidapi", after 1m29s. scripts/setup/setup-hidapi.ps1:42:

Invoke-WebRequest -Uri $HidapiUrl -OutFile $TarFile
     | 504 Gateway Time-out  The server didn't respond in time.
##[error]Process completed with exit code 1.

The URL is https://github.com/libusb/hidapi/archive/refs/tags/hidapi-0.14.0.tar.gz. Configure, Build and every test step were skipped, and sccache logged 0 compile requests — not one line of this branch was compiled.

Two things corroborate that it is transient rather than a property of this head: check-windows passed today on #5900, and the green runs previously cited on this branch were on an older head (dd6c50c8), so this sha had never passed and then failed — it had simply never run to completion.

gh run rerun returns Must have admin rights to Repository, so the remedy is a maintainer re-run, or any subsequent push to the branch. I have deliberately not pushed an empty or cosmetic commit to force it: rewriting a positively-reviewed branch to dodge a 504 is a workaround, not a fix, and it would invalidate the review that is already on it.

---

A fragility worth its own issue, which I am reporting rather than fixing because it is in the shared workflow and nothing to do with this PR:

Qt, FFTW3 and DeepFilterNet3 each have an actions/cache Restore step in the Windows lane. hidapi has neither a cache nor a retry. Every Windows run re-downloads it fresh from the GitHub CDN, so every Windows run on every PR is one hiccup away from red, and the failure surfaces as a red check on whatever PR happened to be running. Adding a cache restore, or a retry with backoff, would remove a whole class of false reds. Happy to file that separately if it would be useful.

---

Unrelated, but it belongs on this PR because this PR is one of the two halves — a cross-PR collision I confirmed by execution rather than by reading.

I ran #5894's checker (tools/check_radio_feature_matrix.py --strict) against this branch's source. It fails, exit 1, on exactly six cells:

fm/tone-mode/hl2        committed D  -> source derives H
fm/tone-tx/hl2          committed D  -> source derives H
fm/tone-rx/hl2          committed D  -> source derives H
fm/dtcs/hl2             committed D  -> source derives H
fm/repeater-dir/hl2     committed P  -> source derives H
fm/repeater-offset/hl2  committed P  -> source derives H

driven by this PR correctly setting c.fmTonePresentation = Hidden and c.hasFmRepeaterOffset = false. That is this PR doing exactly what its title says; the register simply has not been regenerated against it.

The reason it matters: #5894 adds that checker as a step of the required Static checks job, and static-checks.yml's trigger is on: pull_request only — there is no push: — so it never runs on main. Whichever of #5879 and #5894 merges second leaves main red against its own required gate, with no run to notice. Both are green on their own.

The fix is one regeneration and can only be written on the second to land, so I am not pre-empting it here — say which order you want and I will put it on that PR. (Same gap as #5914.)

I have changed nothing on this branch; the head is still 2b86b040.

[jensenpat]

Reviewed 2b86b04043cffb85c6f03022465b285ca4bdb1ba.

No linked issue. The stated intent holds: the HL2 stops claiming an FM repeater offset and CTCSS encode it has no verb for, and the receive-control mode list now includes the modes the menu can already put a slice in (DSB, CWL, FM). CWU is not declared. setSliceMode collapses it onto CW before a slice holds it, which is what keeps a requested alias from wedging request.conflict. That matches the tests and contradicts the PR title, which still says the demodulator's CWU spelling is declared. Fix the title in the squash subject.

Scope

File	What changed
Hl2Backend.cpp / .h	hasFmRepeaterOffset = false, tone presentation Hidden, receiveModeControl adds DSB/CWL/FM, setSliceMode canonicalises known aliases
Hl2ModeVocabulary.h	Comment: setSliceMode is no longer a route that stores an alias
RxApplet.cpp, VfoWidget.cpp	REV stays enabled for XFC, disabled when the button is duplex and the radio declares no offset; disabled styling uses theme tokens
AetherDspModePolicy.cpp, PhoneCwApplet.cpp, VoiceModeGate.h	Comments only: HL2 no longer publishes CWU; the three spellings stay for Icom
RadioCertification.cpp	Mode-map concern names a deliberate alias collapse as well as an unmapped fallback
docs/aetherd-local-receive-control.md, docs/architecture/radio-capabilities-map.md	Matrix and capability rows follow the new declarations
tests/hl2_fm_controls_declaration_test.cpp, tests/control_receive_test.cpp, tests/tests.cmake	Declaration, menu agreement, canonical-spelling invariant, and control-plane outcomes. Both targets are registered and the new one is an AETHER_SETTINGS_CONSUMERS entry

Nothing else is in the diff. Flex, Icom, ANAN, RTL, and Sim capability records are untouched. The shared REV widgets branch on hasTransmitFrequencyCheck before hasFmRepeaterOffset. The IC-7300MK2 profile is hasDuplex = false, hasXfc = true, so that radio's XFC button stays enabled.

Findings

Nits only. The two comments in Hl2Backend.cpp still describe an earlier revision in which CWU was on receiveModeControl and slice.setMode accepted it. The list and control_receive_test say the opposite: CWU and NFM are request.out_of_range. The capabilities-map row still explains HL2 receive-only modes as the phasing SSB modulator, which this PR's own backend comment says is the stale half of a build-time choice (AETHER_HL2_TX_TXA defaults ON).

Verification

• hl2_fm_controls_declaration_test and control_receive_test: 2/2 passed, QT_QPA_PLATFORM=offscreen, build SHA 2b86b040, AppleClang, Qt 6.11.0, AETHER_HL2_TX_TXA=ON. Neither target binds a socket.
• CI on this SHA: build, check-macos, check-windows, Static checks, Sanitizer option configures, all success. The earlier check-windows failure was a hidapi 504 before compile; the re-run completed the build.
• git merge-tree --write-tree against origin/main (b2467cf9) is clean.
• The app was not built and no radio was connected. The VFO and RX widgets are not constructed by these tests.

Non-blocking follow-ups

• receiveFilterControl still has no DSB, CW, CWL, or FM row, so a headless slice.setFilter for those modes stays refused. Pre-existing for CW; this PR extends the mode list without extending the filter list.
• Nothing in the suite builds VfoWidget or RxApplet, so the REV enablement and the tone-row hide are read from the call sites, not exercised.