Repository navigation
Feature parity: port remaining go-RCP tooling packages (iso21434, certgap, formal, codegen) #23
Description
Background
Feature-equivalence audit against the reference implementation go-RCP (2026-06-19). cpp-RCP matches 39/44 go-RCP packages (+ adds cli/adapt/relay). safety is covered by command_latency_test.cpp. Four go-RCP packages have no cpp-RCP equivalent:
| go-RCP pkg | Purpose | Public API |
|---|---|---|
iso21434 |
Cybersecurity engineering (ISO/SAE 21434) | ComputeRisk, ThreatScenario, TARA, GoalRegistry |
certgap |
ASIL gap analysis | Registry, GapReport, StandardASILDGaps |
formal |
In-library LTL verification helpers | Always/Eventually/Until, Checker |
codegen |
Zone-manifest → controller stub + fusa-req skeleton generator | ParseManifest, Generate |
Decision needed
All four are safety/cyber tooling, not RCP transport features. cpp-RCP currently delegates this role to the external cpp-FuSa (cpfusa) tool (gap reports, TARA, traceability) and to TLA+ specs in tla/. So the question is architectural, not just effort:
- Option A — port them as C++ library modules for strict go-RCP API parity.
- Option B — declare them intentionally out of scope for cpp-RCP (tooling lives in cpp-FuSa) and document the divergence.
iso21434 is the most relevant to cpp-RCP's cyber-requirement story and the most self-contained; codegen is the largest. Tracking for a later decision. See companion issue on SoundMatt/go-RCP.
Activity
SoundMatt commentedon Jul 27, 2026
Leaving this open — it's out of scope for an automated code-fix pass (see PR #35, which addresses every other open issue on this repo).
This issue explicitly frames itself as a decision needed, not a bug or a spec-conformance gap: "Option A — port them as C++ library modules for strict go-RCP API parity" vs. "Option B — declare them intentionally out of scope for cpp-RCP (tooling lives in cpp-FuSa) and document the divergence." Both are legitimate architectural directions with real tradeoffs (API-parity/portability vs. avoiding duplicating what
cpfusa/TLA+ already cover for this repo), and picking one isn't something that should be guessed at in an unattended fix pass — it changes this repo's tooling boundary going forward, not just its current behavior.What would need to happen instead: a maintainer decision on Option A vs. B (informed by the companion issue on
SoundMatt/go-RCP, since the two repos' answers presumably should agree), then a normal implementation PR against whichever option is chosen. Happy to implement either once that call is made.