@AetherClaude are we good to merge this one?

@ten9876 I reviewed the diff against src/models/XvtrPolicy.{h,cpp}, RadioSetupDialog.cpp, and the test, plus CI. This looks good to merge — no blockers.

What's solid

• All 5 checks pass on head c00c5e9 (build, check-macos, check-windows, analyze/cpp, CodeQL).
• maxPowerRangeFor / clampMaxPowerDbm cleanly mirror the FlexLib bounds: shared -10 dBm floor, +8 high-IF (>= 80 MHz), +10 legacy low-IF (6400/6400M/6600/6600M), +15 default low-IF. usesLegacyLowIfMaxPower normalizes with .trimmed().toUpper(), so model-string casing is handled.
• m_model->model() is the right accessor, and the test cases match the four ranges named in the summary.
• The IF editingFinished path correctly re-runs updateMaxPowerValidator() then submitMaxPower(false), so tightening the ceiling re-clamps and only re-sends when the value actually changed — that's the XVTR/Transverter: TX-safety & correctness issues — CW AutoTune ignores XVTR (~170 MHz), LO Error unit mismatch, Max Power has no clamp #3246 fix build(deps): Bump actions/checkout from 4 to 6 #3 behavior.

Minor, non-blocking nits (fine to land as-is or fold into a follow-up):

1. Decimal display inconsistency. The field is initialized with one decimal (RadioSetupDialog.cpp:2732, QString::number(x.maxPower, 'f', 1)), but the validator and submitMaxPower both format with two ('f', 2). So an untouched field shows 10.0 and flips to 10.00 after the first edit. Purely cosmetic; aligning the initial render to 'f', 2 would make it consistent.

2. High-IF boundary is inclusive at 80 MHz. ifFreqMhz >= kHighIfThresholdMhz puts exactly 80.0 in the +8 dBm bucket (the test asserts this). Worth a quick confirm that FlexLib treats the 80 MHz edge the same way, since that's the one value where inclusive vs. exclusive changes the ceiling.

3. Empty/non-numeric IF text falls through toDouble() → 0.0 → low-IF branch (default/legacy ceiling). Harmless, just noting the implicit default.

None of these change correctness, so I'd be comfortable merging once you're happy with the cosmetic decimal point.

73, Jeremy KK7GWY & Claude (AI dev partner)

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

@AetherClaude push a fix for the nits on top of the PR

@ten9876 I went back through the three nits against the PR diff. Only nit #1 is an actual code change; #2 and #3 were confirmations/notes. Here's the concrete fix.

Nit #1 — decimal display consistency (the real one)

The field is still initialized with one decimal, while the validator and submitMaxPower both use two. So an untouched field renders 10.0 and snaps to 10.00 on the first edit. The PR didn't touch the init line, so this is the only line that needs to change:

src/gui/RadioSetupDialog.cpp:2732

// before
auto* maxPwrEdit = addField(4, 0, "Max Power (dBm):", QString::number(x.maxPower, 'f', 1));

// after
auto* maxPwrEdit = addField(4, 0, "Max Power (dBm):", QString::number(x.maxPower, 'f', 2));

That's a one-character change (1 → 2) and aligns the initial render with the validator/submitMaxPower formatting.

Nit #2 — 80 MHz inclusive boundary

ifFreqMhz >= kHighIfThresholdMhz puts exactly 80.0 in the +8 dBm bucket, and the test (tests/xvtr_policy_test.cpp) asserts it. This is a behavioral question about whether FlexLib treats the 80 MHz edge inclusively, not a defect — I'd leave the code as-is unless @jensenpat wants to confirm against FlexLib and flip to > if it should be exclusive. No code change recommended without that confirmation.

Nit #3 — empty/non-numeric IF text

Empty IF text falls through toDouble() → 0.0 → the low-IF branch, which is the safe/permissive default. Harmless and arguably the desired fallback, so no change needed. If you want it explicit it'd be a comment rather than logic.

So the only fix to land is the 'f', 1 → 'f', 2 change above. It's a pure-cosmetic, zero-risk edit with no test impact.

The aetherclaude-eligible label isn't on this issue yet — a maintainer can authorize the orchestrator to land this fix by adding the aetherclaude-eligible label, and it'll open the follow-up commit on the next webhook cycle.

73, Jeremy KK7GWY & Claude (AI dev partner)

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