Reviewed as a pure code-motion follow-up to #3407. Looks good — happy to see this land. ✅

Verification

• Verbatim relocation confirmed. Diffing the block removed from MainWindow.cpp against the one added to MainWindow_DigitalModes.cpp, the three methods (activateWFM / deactivateWFM / reflectWfmButtons) are character-identical. No behavioural edits crept in under cover of the move — exactly what a "pure code motion" PR should look like.
• Include hygiene is right. MainWindow.cpp drops the three now-unused WFM headers; the sibling TU picks them up plus RxApplet.h, which is genuinely required here (reflectWfmButtons dereferences the full RxApplet type via rx->setWfmActive()). Carrying it explicitly rather than leaning on a transitive include is the correct call for the Qt 6.4.2 floor.
• CI green across the board — build (the Linux/Qt 6.4.2 floor), check-macos, check-windows, CodeQL, analyze (cpp), and accessibility all pass. That compile pass is the proof the includes dropped from MainWindow.cpp weren't load-bearing for anything else in the TU.

Conventions / scope — no MainWindow.h change (consistent with how activateRADE/deactivateRADE already live in this TU), no new AppSettings keys, RAII/ownership semantics preserved exactly, and both files are within the stated scope. The placement beside the DAX IQ lifecycle that WFM actually consumes is a sensible home, and keeping the wfmActivated connect handlers in MainWindow.cpp next to the RADE ones is the right consistency choice.

Nothing blocking and nothing to nitpick. Thanks for the tidy follow-up, @ten9876.

_{🤖 aethersdr-agent · cost: $2.0937 · model: claude-opus-4-8}

Reviewed as a pure code-motion follow-up to #3407. Looks good to merge. ✅

Verification

• The three relocated methods (activateWFM / deactivateWFM / reflectWfmButtons) are byte-for-byte identical between the removed and added blocks — genuinely verbatim, no behavioural drift.
• Include accounting is correct on both sides: MainWindow.cpp drops the three now-unused WFM headers (keeping the unrelated PanadapterStream.h), and the remaining wfmActivated connect handlers only touch members declared in MainWindow.h, so nothing is orphaned. MainWindow_DigitalModes.cpp carries all four headers the moved code needs (RxApplet.h, WfmDeviceDialog.h, WfmDemodulator.h, WfmSettings.h) explicitly — no transitive-include reliance, the right move for the Qt 6.4.2 floor.
• All six CI checks (build / check-macos / check-windows / CodeQL / analyze / accessibility) are green, which is the decisive signal for a code-motion change — it compiles and links on every platform.

The new home is well-chosen: WFM reads the same DAX IQ stream that startDax/wireDaxSlice manage in this TU, and it now sits beside the analogous RADE/FreeDV per-slice lifecycles. Keeping the toggle connects in MainWindow.cpp next to the RADE ones is consistent.

Nothing outside the stated scope; no AppSettings/RAII/null-safety concerns introduced by a relocation. Thanks @ten9876 — nice continuation of the #3351 decomposition.

_{🤖 aethersdr-agent · cost: $1.5555 · model: claude-opus-4-8}

Reviewed as a pure code-motion follow-up to #3407 — and it checks out as exactly that. Thanks for the clean, well-scoped relocation, @ten9876.

Verification I ran:

• Methods moved verbatim. activateWFM / deactivateWFM / reflectWfmButtons are byte-identical between the removed and added hunks — no behavioural drift.
• MainWindow.cpp include removals are safe. The only references to WfmSettings, WfmDemodulator, and WfmDeviceDialog in that TU lived entirely inside the moved methods. The surviving WFM references (the wfmActivated connect handlers and the m_wfmSliceId guard in the pan-follow path) touch only plain members and SliceModel, so dropping the three includes can't break the translation unit.
• Destination TU has what it needs. MainWindow_DigitalModes.cpp already pulled in AppletPanel.h, VfoWidget.h, SpectrumWidget.h, <QTimer>, and already uses spectrumForSlice(). The four explicit adds (RxApplet.h, WfmDeviceDialog.h, WfmDemodulator.h, WfmSettings.h) cover the rest, and QDialog::Accepted resolves transitively via WfmDeviceDialog.h — good call not relying on transitive includes given the Qt 6.4.2 floor.
• CI green across the board — Linux build, Windows, macOS, CodeQL, and accessibility all pass on 3dec333.

One minor nit (non-blocking): the relocated section-divider comment picked up a UTF-8 corruption — // ─��─ WFM software demodulator — where the original in MainWindow.cpp had clean box-drawing chars (// ─── WFM software demodulator ───). Worth fixing the two mangled bytes on your next push so the divider matches the surrounding activateRADE section, but it's cosmetic and doesn't affect the build.

Nice continuation of the #3351 decomposition direction — sitting WFM beside the DAX IQ lifecycle it reads from is the right home.

_{🤖 aethersdr-agent · cost: $3.8841 · model: claude-opus-4-8}