Finding
detect_radio_on_port_impl in crates/syntonia/src/hardware/detect.rs implements the public detect_radio_on_port API. It calls find_cable_for_port (which enumerates serial ports and constructs a UsbCable) and then invokes the prober. Neither this function nor its not-found fallback path is exercised by any test; all existing tests cover only detect_radios_impl, the multi-cable bulk scan.
Evidence
crates/syntonia/src/hardware/detect.rs:250 — fn detect_radio_on_port_impl( — is the single-port entry point. crates/syntonia/src/hardware/detect.rs:265 — fn find_cable_for_port(port_path: &str) -> Result<UsbCable, DetectError> { — contains a fallback at lines 284-293 that yields an Unknown { vid: 0, pid: 0 } cable when the requested port is absent from the OS-enumerated list. No call to detect_radio_on_port_impl appears in the #[cfg(test)] module.
Why this matters
detect_radio_on_port is the user-facing entry point for targeted detection, used when the operator names a port explicitly — the deliberate, narrowed-scope path counter-surveillance use favors over a broad bus scan. The silent zero-VID fallback means a caller can receive a cable that claims vid: 0, pid: 0 without any signal that the port was never actually found, leading to operations against an unidentified device. With no tests, regressions in either function are invisible.
Desired correction
Add tests that drive detect_radio_on_port_impl with a MockProber: (1) prober returns Some — assert the DetectedRadio fields; (2) prober returns None — assert Ok(None); (3) exercise the not-found path so the fallback UsbCable construction in find_cable_for_port is covered and its Unknown { vid: 0, pid: 0 } result is asserted.
Done when: all three branches are covered by unit tests that do not require a physical serial port.
Finding
detect_radio_on_port_implincrates/syntonia/src/hardware/detect.rsimplements the publicdetect_radio_on_portAPI. It callsfind_cable_for_port(which enumerates serial ports and constructs aUsbCable) and then invokes the prober. Neither this function nor its not-found fallback path is exercised by any test; all existing tests cover onlydetect_radios_impl, the multi-cable bulk scan.Evidence
crates/syntonia/src/hardware/detect.rs:250—fn detect_radio_on_port_impl(— is the single-port entry point.crates/syntonia/src/hardware/detect.rs:265—fn find_cable_for_port(port_path: &str) -> Result<UsbCable, DetectError> {— contains a fallback at lines 284-293 that yields anUnknown { vid: 0, pid: 0 }cable when the requested port is absent from the OS-enumerated list. No call todetect_radio_on_port_implappears in the#[cfg(test)]module.Why this matters
detect_radio_on_portis the user-facing entry point for targeted detection, used when the operator names a port explicitly — the deliberate, narrowed-scope path counter-surveillance use favors over a broad bus scan. The silent zero-VID fallback means a caller can receive a cable that claimsvid: 0, pid: 0without any signal that the port was never actually found, leading to operations against an unidentified device. With no tests, regressions in either function are invisible.Desired correction
Add tests that drive
detect_radio_on_port_implwith aMockProber: (1) prober returnsSome— assert theDetectedRadiofields; (2) prober returnsNone— assertOk(None); (3) exercise the not-found path so the fallbackUsbCableconstruction infind_cable_for_portis covered and itsUnknown { vid: 0, pid: 0 }result is asserted.Done when: all three branches are covered by unit tests that do not require a physical serial port.