The README still described the project as it was before Phase 03. Several
claims had become actively wrong rather than merely dated, and the last one
is the kind a reviewer would catch:
- "no ASN.1 encoding in the app" - the app hand-encodes and decodes CAM,
DENM and SPATEM bit by bit on the ESP32-C5 path. domain/asn1/ is now the
highest-risk code in the project, and the README denied it existed.
- The phase table listed Phase 03 as Bluetooth BLE. Phase 03 is the
ESP32-C5; Bluetooth is not implemented and the requirements leave it open.
- "communicates with the OBU exclusively via the consider it MQTT API v6"
is true of one of the two hardware paths.
- The feature list claimed MAP and CPM display. There is no MAPEM decoder
and nothing in the tree supports CPM, so both claims are dropped rather
than carried forward.
- DENM transmission was listed as a headline feature with no indication that
it is a manual antenna and range test tool, CiT One only, and deliberately
never triggered by a detected event or a use case alert. That decoupling is
the project's central architectural rule and the README implied the
opposite.
- The architecture tree predated domain/asn1, domain/usecase, domain/cam,
data/cam, the serial transport, obu-firmware/ and asn1/.
Added: the project goal, the two hardware paths and the point where they
converge, a verification section, a documentation index, and a status
section.
The convergence point is worth stating in the README rather than only in the
technical document, because it is what makes the second OBU a drop-in rather
than a fork: both paths normalise into the domain Cam type at
CamUseCaseRepository, and everything above it is shared and
transport-agnostic.
The status section says plainly that requirement 11.6 is not met, that
messages are not signed, and that the detection thresholds are untuned
estimates. Someone arriving at this repository should learn that from the
front page rather than from page forty of a Word document.
Ashin Walpola