Context
Area
crates/akroasis/src/radio/mod.rs (production dispatch path) + crates/syntonia/src/serial.rs (Baofeng hardware adapter)
Severity
high — README-claimed shipped feature is unreachable from the binary.
Evidence
crates/akroasis/src/radio/mod.rs:148-149 — comment // Stub hardware (returns errors until P1-02..P1-06 are implemented)crates/akroasis/src/radio/mod.rs:154-162 — impl Hardware for StubHardware returns Err(RadioError::HardwareNotAvailable) for every method.crates/akroasis/src/radio/mod.rs:204 — production path dispatch_with(cmd, &StubHardware) hard-codes the stub.crates/syntonia/src/serial.rs:50-53 — HardwareSerialPort is gated #[cfg(feature = "hardware-serial")] and decorated #[expect(dead_code, reason = "...consumers live outside this crate (baofeng::protocol module not yet re-wired, see #80-follow-up)")].crates/syntonia/Cargo.toml:23 — hardware-serial = ["dep:serialport"], off by default.
Conflict
README says syntonia "Programs Baofeng UV-5R family directly." Encode/decode logic and protocol driver exist, but the CLI never opens a real serial port — dispatch always uses StubHardware.
Why it matters
A claimed shipped feature (Baofeng programming) is unreachable from the binary. Standards demand "implemented, wired, exercised"; a dead_code suppression on the production hardware adapter is an explicit admission of an unwired feature.
Done criteria
- Wire
HardwareSerialPort into akroasis radio detect/read/program/export.
- Enable the
hardware-serial feature by default in the binary crate.
- Remove
StubHardware from the production dispatch path; remove the #[expect(dead_code)] suppressions on HardwareSerialPort.
Source
Kimi L1+L2 audit pipeline 2026-04-25 (/home/ck/menos-ops/inbox/kimi-audit-reports/repos-deep/akroasis.md, qa/qa-repos-akroasis.md).
Provenance
Originally filed on the kanon forge as issue #7 on 2026-04-25T20:14:58.129188281-05:00[America/Chicago]. Recovered from 2026-05-09 pre-brick restic backup. Forge URL no longer reachable post firmware brick.
Severity
P2
Context
Area
crates/akroasis/src/radio/mod.rs(production dispatch path) +crates/syntonia/src/serial.rs(Baofeng hardware adapter)Severity
high — README-claimed shipped feature is unreachable from the binary.
Evidence
crates/akroasis/src/radio/mod.rs:148-149— comment// Stub hardware (returns errors until P1-02..P1-06 are implemented)crates/akroasis/src/radio/mod.rs:154-162—impl Hardware for StubHardwarereturnsErr(RadioError::HardwareNotAvailable)for every method.crates/akroasis/src/radio/mod.rs:204— production pathdispatch_with(cmd, &StubHardware)hard-codes the stub.crates/syntonia/src/serial.rs:50-53—HardwareSerialPortis gated#[cfg(feature = "hardware-serial")]and decorated#[expect(dead_code, reason = "...consumers live outside this crate (baofeng::protocol module not yet re-wired, see #80-follow-up)")].crates/syntonia/Cargo.toml:23—hardware-serial = ["dep:serialport"], off by default.Conflict
README says syntonia "Programs Baofeng UV-5R family directly." Encode/decode logic and protocol driver exist, but the CLI never opens a real serial port —
dispatchalways usesStubHardware.Why it matters
A claimed shipped feature (Baofeng programming) is unreachable from the binary. Standards demand "implemented, wired, exercised"; a
dead_codesuppression on the production hardware adapter is an explicit admission of an unwired feature.Done criteria
HardwareSerialPortintoakroasis radio detect/read/program/export.hardware-serialfeature by default in the binary crate.StubHardwarefrom the production dispatch path; remove the#[expect(dead_code)]suppressions onHardwareSerialPort.Source
Kimi L1+L2 audit pipeline 2026-04-25 (
/home/ck/menos-ops/inbox/kimi-audit-reports/repos-deep/akroasis.md,qa/qa-repos-akroasis.md).Provenance
Originally filed on the kanon forge as issue #7 on 2026-04-25T20:14:58.129188281-05:00[America/Chicago]. Recovered from 2026-05-09 pre-brick restic backup. Forge URL no longer reachable post firmware brick.
Severity
P2