Finding
The test module in crates/syntonia/src/baofeng/variant.rs is guarded by #[cfg(all(test, feature = "hardware-serial"))]. The module logic itself compiles without the feature, but its tests — covering identify_variant, uv5r_config, bf_f8hp_config, power_from_bits, and bits_from_power — never execute under a normal cargo test. Unlike the protocol tests, these are correct and hardware-free; they are simply gated behind the wrong feature.
Evidence
crates/syntonia/src/baofeng/variant.rs:317 — #[cfg(all(test, feature = "hardware-serial"))] — annotates the entire mod tests block. cargo test -p syntonia output contains no baofeng::variant::tests::* entries. The variant module is compiled without the feature via the pub(crate) mod variant branch at mod.rs:14-16, so the logic runs in default builds while none of its correctness properties are exercised.
Why this matters
identify_variant decides whether a responding radio is a UV-5R (no aux EEPROM, 2 power levels) or a BF-F8HP (aux EEPROM, 3 power levels). A regression that swaps configs — treating a BF-F8HP as a UV-5R — would make download_image skip the aux block and lose calibration data, or mishandle power levels. The tests that would catch this exist and pass, but are disabled in every standard test run, so the guard is effectively absent from CI on the operator's primary device-profiling path.
Desired correction
Remove the feature = "hardware-serial" constraint from the variant.rs test module, leaving it as #[cfg(test)]. The tests use only RadioIdent, identify_variant, and the config constructors, none of which touch hardware; the hardware-serial gate belongs solely on the protocol module that calls serialport.
Done when: cargo test -p syntonia (no feature flags) includes baofeng::variant::tests::* in its output and all pass.
Finding
The test module in
crates/syntonia/src/baofeng/variant.rsis guarded by#[cfg(all(test, feature = "hardware-serial"))]. The module logic itself compiles without the feature, but its tests — coveringidentify_variant,uv5r_config,bf_f8hp_config,power_from_bits, andbits_from_power— never execute under a normalcargo test. Unlike the protocol tests, these are correct and hardware-free; they are simply gated behind the wrong feature.Evidence
crates/syntonia/src/baofeng/variant.rs:317—#[cfg(all(test, feature = "hardware-serial"))]— annotates the entiremod testsblock.cargo test -p syntoniaoutput contains nobaofeng::variant::tests::*entries. Thevariantmodule is compiled without the feature via thepub(crate) mod variantbranch atmod.rs:14-16, so the logic runs in default builds while none of its correctness properties are exercised.Why this matters
identify_variantdecides whether a responding radio is a UV-5R (no aux EEPROM, 2 power levels) or a BF-F8HP (aux EEPROM, 3 power levels). A regression that swaps configs — treating a BF-F8HP as a UV-5R — would makedownload_imageskip the aux block and lose calibration data, or mishandle power levels. The tests that would catch this exist and pass, but are disabled in every standard test run, so the guard is effectively absent from CI on the operator's primary device-profiling path.Desired correction
Remove the
feature = "hardware-serial"constraint from thevariant.rstest module, leaving it as#[cfg(test)]. The tests use onlyRadioIdent,identify_variant, and the config constructors, none of which touch hardware; thehardware-serialgate belongs solely on theprotocolmodule that callsserialport.Done when:
cargo test -p syntonia(no feature flags) includesbaofeng::variant::tests::*in its output and all pass.