What's wrong
README.md's Architecture diagram (~lines 53-69) shows GPIO/CAN boxes as "device endpoints" hanging directly off EndpointTable, and line 71 states verbatim:
"mock::RcServer is this crate's in-process reference implementation of the RC Server side; udp/tlstransport/shmem compose it over real transports."
Neither claim holds:
- No concrete type implements
Endpoint for any real device (gpio/spi/i2c/uart/can/lin/pwm/adc/iseled/mdio/etc.) — mock.rs's own doc comment says as much, and grep 'impl Endpoint for' src/*.rs confirms only decorator modules and MockEndpoint exist.
udp/tlstransport/shmem do not "compose over real transports" — grep for std::net/TcpStream/mmap/UdpSocket in those files finds only trait definitions and test doubles, and src/bin/rcp.rs's own doc comment admits "This crate has no concrete rcp::udp::UdpSocket implementation over a real OS socket."
Unlike mock.rs's honest internal doc comments about these gaps, the README presents this as already-working, shipped capability.
Why it matters
A reader evaluating this crate for use (e.g. deciding whether it can drive a real GPIO or CAN device over a real network) would reasonably conclude from the README that this already works. It doesn't — see the related tc18-spec-completeness issue filed this session for the underlying gap. Misleading README claims are especially costly for a safety-critical crate where integrators need an accurate picture of what's actually implemented versus scaffolded.
Suggested fix
Update the architecture diagram and description to clearly mark GPIO/CAN/etc. endpoints and udp/tlstransport/shmem real-transport support as not-yet-implemented/planned, matching the honesty already present in mock.rs's doc comments.
Filed from the RELAY ecosystem audit (2026-07-29), category: docs-currency, severity: medium.
What's wrong
README.md's Architecture diagram (~lines 53-69) shows GPIO/CAN boxes as "device endpoints" hanging directly offEndpointTable, and line 71 states verbatim:Neither claim holds:
Endpointfor any real device (gpio/spi/i2c/uart/can/lin/pwm/adc/iseled/mdio/etc.) —mock.rs's own doc comment says as much, andgrep 'impl Endpoint for' src/*.rsconfirms only decorator modules andMockEndpointexist.udp/tlstransport/shmemdo not "compose over real transports" —grepforstd::net/TcpStream/mmap/UdpSocketin those files finds only trait definitions and test doubles, andsrc/bin/rcp.rs's own doc comment admits "This crate has no concretercp::udp::UdpSocketimplementation over a real OS socket."Unlike
mock.rs's honest internal doc comments about these gaps, the README presents this as already-working, shipped capability.Why it matters
A reader evaluating this crate for use (e.g. deciding whether it can drive a real GPIO or CAN device over a real network) would reasonably conclude from the README that this already works. It doesn't — see the related tc18-spec-completeness issue filed this session for the underlying gap. Misleading README claims are especially costly for a safety-critical crate where integrators need an accurate picture of what's actually implemented versus scaffolded.
Suggested fix
Update the architecture diagram and description to clearly mark GPIO/CAN/etc. endpoints and udp/tlstransport/shmem real-transport support as not-yet-implemented/planned, matching the honesty already present in
mock.rs's doc comments.Filed from the RELAY ecosystem audit (2026-07-29), category: docs-currency, severity: medium.