Thanks for this, @M7HNF-Ian — nicely scoped and the safety reasoning is sound. The clamp happens receiver-side in startSwrSweep where the custom bounds are intersected with the already-computed safeLow/safeHigh (which themselves fold in the regional band-plan narrowing from #2800), so a manual range can only ever narrow the sweep and the out-of-region transmit guard is preserved. The signal/slot wiring lines up (the function-pointer connect in MainWindow_Wiring.cpp resolves cleanly to the new 4-arg startSwrSweep), the spin boxes and checkbox are parented into the layout so there's no leak, and the null guards (if (!m_slice), m_slice ? … : -1) are all in place. No AppSettings/QSettings concern since nothing here persists.

One substantive thing worth tightening:

Inverted range silently falls back to a full-band sweep. The guard is:

if (customLowMhz > 0.0 && customHighMhz > customLowMhz) {
    ...
}

If the operator enters From above To (e.g. From 14.200, To 14.100), the condition is false and the code drops through to the full-band safeLow/safeHigh range with no warning. For the exact use case this feature targets — rnash2 wanting to confine the sweep to respect operating privileges — that's the wrong-direction surprise: they think they've constrained the sweep but actually get a full-band transmit. The non-overlapping case already warns; an inverted entry should too rather than silently widening. Suggest splitting the validation so a positive-but-inverted range is rejected with the same kind of QMessageBox::warning instead of falling through.

Minor (optional): the From/To fields are seeded once on first tick (value() <= 0.0), so if the user changes band afterward the seeded edges go stale. Not a correctness issue — the receiver-side clamp still keeps it safe — but re-seeding on band change (or whenever the range is empty) would match the "sensible in-band starting point" intent better.

Nothing here blocks; the safety-critical path is correct. Nice work, and thanks for the clear write-up and the live FLEX-6600 test notes.

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

Thanks Ian — nicely scoped, and the safety reasoning checks out.

TX-safety (Principle VI) — clean. The SWR sweep keys the radio, so this is a transmit path, but the custom bounds are clamped inside the already-computed safe range:

sweepLow  = std::max(safeLow,  customLowMhz);
sweepHigh = std::min(safeHigh, customHighMhz);

safeLow/safeHigh already fold in the #2800 regional band-plan narrowing and the out-of-region transmit guard (both untouched), so a manual range can only ever narrow the sweep — never widen it past what the band plan permits. The sub-step-overlap rejection also prevents a zero-width keying. The invariant holds.

🔴 Needs a rebase — merge conflict with #3882. The SWR CSV export (#3882) landed in this same window and added a Save CSV button + swrSweepSaveCsvRequested() signal + m_swrSaveBtn in the exact regions this PR edits. There are real content conflicts in SpectrumOverlayMenu.cpp and SpectrumOverlayMenu.h (the other two files auto-merge clean). It's purely mechanical "keep both" — the CSV button row and the Limit-range row are logically independent, so the resolution keeps the new 4-arg swrSweepStartRequested and the swrSweepSaveCsvRequested signal, plus all members. Please rebase on main and let CI re-run (the current green is from before #3882 merged).

🟡 Worth folding into the same rebase: inverted range silently sweeps full-band. With From > To (both > 0), the guard customHighMhz > customLowMhz is false, so it drops through to the full safeLow/safeHigh. It's not a safety violation — the sweep is still clamped within the safe band — but it's a wrong-direction surprise for the exact use case this targets: an operator confining a sweep to their privileges thinks they've narrowed it but actually gets a full-band sweep. Suggest rejecting a positive-but-inverted range with the same QMessageBox::warning you already use for the non-overlap case.

⚪ Minor (optional): the From/To fields seed once on first tick (value() <= 0.0), so they go stale if the operator changes band afterward. The receiver-side clamp keeps it safe regardless; re-seeding on band change (or whenever the range is empty) would just match the "sensible in-band starting point" intent better.

Clean work and thanks for the live FLEX-6600 test notes. Once it's rebased past #3882 — ideally with the inverted-range warning added — this is a merge.

Verified against the current head (74fac623) — all three prior points resolved and CI green.

TX-safety (Principle VI) holds: the custom bounds are clamped inside the already-computed safe range (std::max(safeLow, customLow) / std::min(safeHigh, customHigh)), which folds in the #2800 regional band-plan narrowing, the edge guard, and the out-of-region TX guard — so a manual range can only ever narrow, never widen. Sub-step overlap check prevents zero-width keying.

• 🔴 Rebase past #3882 — clean 'keep both' (4-arg swrSweepStartRequested + swrSweepSaveCsvRequested + Save CSV button all present and wired).
• 🟡 Inverted range — now rejected with a warning before any keying instead of falling through to full-band.
• ⚪ Stale seeding — re-seeds when empty or out-of-band, preserves a within-band narrowing.

Clean, well-scoped, and nicely tested on a FLEX-6600. Thanks @M7HNF-Ian — merging.