Thanks @jensenpat — nice polish pass. The log SWR scale, resonance caret, threshold-band shading, and interpolated bandwidth math are all easy to follow and read cleanly on the diff. Confirmed originalBandName is set/cleared in all the right spots (startSwrSweep, clearSwrSweepPlot, clearSwrSweepForBandChange, completeSwrSweepFinish), and preserveBandSwitchOnFinish correctly skips both the freq and pan-range restoration in finishSwrSweepAfterTuneStopped so cleanup doesn't fight the new band switch.

One concern worth a look:

clearSwrSweepForBandChange(-1, bandName) from wirePanadapter is panadapter-agnostic. The call site at MainWindow.cpp:9205 fires for any applet's band change, but the function is invoked with sliceId=-1, which bypasses the sliceId != m_swrSweep.sliceId guard. In a multi-panadapter setup, switching the band on a panadapter that isn't the swept one will still match newBandName != m_swrSweep.originalBandName and either clear a completed plot or abort a running sweep on the unrelated panadapter. That seems contrary to the PR's stated intent ("Clear completed sweep plots when the swept TX slice changes bands").

Suggested fix — either gate the call on the applet's pan id, e.g.:

if (m_swrSweep.panId.isEmpty() || applet->panId() == m_swrSweep.panId)
    clearSwrSweepForBandChange(-1, bandName);

or pass the panId into clearSwrSweepForBandChange and add a panId == m_swrSweep.panId check alongside the existing slice filter. The TX-slice frequencyChanged path at MainWindow.cpp:7712 is fine since it correctly filters on sliceId.

Minor nit (take or leave): bestSwr is the clamp-to-1.0 value, so the corner readout displays SWR 1.00:1 for any sample below 1.0. That's physically reasonable, but if the underlying meter ever hands you something pathological, the displayed best won't match the raw sample. Probably fine as-is.

Otherwise looks good — no AppSettings/RAII issues, scope is tight to the three files, and the existing TGXL/tune/timer paths are preserved as documented.