[cpp-RCP-parity-C, mirrors c-RCP-18] Requirement schema, tagging & atomicity parity #124

Background

c-RCP's requirement catalog went through two initiatives cpp-RCP hasn't: a schema rollout (status/scope/tc18/tc18_master_id fields, documented in CONTRIBUTING.md's "Writing a requirement" section) and a full requirement-atomicity audit (issue #533, "c-RCP-18-tracker" — split every bundled multi-shall-statement REQ-* id into atomic ids, one per independently-testable behavior, moving tags to sit directly above the exact function/test each covers rather than a file-header block).

This tracker is cpp-RCP's equivalent of both, verified against current main (410 requirement entries in .fusa-reqs.json) on 2026-08-21.

Findings

Schema fields — c-RCP's 1282 entries all have scope and status (100%); tc18/tc18_master_id at 72%/63%. cpp-RCP's 410 entries have zero scope/status fields (0/410 — the fields don't exist in the schema at all) and tc18/tc18_master_id at only 36% (149/410, always paired). The tc18/tc18_master_id linkage is an already-in-flight effort — six merged PRs (#108-113) explicitly branded "[c-RCP-18-tracker] Part 1" — but there's no Part 2 yet for the remaining 261 entries, and status/scope have no initiative at all.

Tag placement — confirmed 100% file-header-block style across every sampled file (51/53 include/*.hpp, 52/54 tests/*.cpp — ~103 files total), 0% per-function, unlike c-RCP's now-canonical per-function convention. cpp-RCP's CONTRIBUTING.md (42 lines) has no "Writing a requirement" section, no tag-placement guidance, no atomicity guidance at all.

Atomicity — no audit has ever run in cpp-RCP (checked all 43 closed + 6 open issues/PRs for "atomicity"/"bundled"/"split" — zero hits; PRs #108-113 are tc18_master_id-only, a different task despite sharing "c-RCP-18-tracker" branding). A same-methodology proxy check (2+ "shall" occurrences) flags 160/410 (39%) of entries as bundled-requirement candidates, e.g. REQ-MOCK-005 bundles an authorization-check behavior with a config-replacement behavior in one shall-statement; the whole REQ-MOCK-007/011/013/.../025 family bundles decode+classify+dispatch+error-path per id.

Conditional-request id-prefix granularity — c-RCP uses 6 fine-grained prefixes (REQ-CMP-*/REQ-CANCEL-*/REQ-SEQ-*/REQ-TIMED-*/REQ-TRIG-*/REQ-CHAIN-*, 96 entries total) for the conditional-request cluster. cpp-RCP's equivalent module (include/rcp/request.hpp, confirmed still the right file) uses one coarse prefix, REQ-SEQ-*, 12 entries — e.g. REQ-SEQ-003 "Compound/compound-wait optional-feature bundling" and REQ-SEQ-007 "Chained-successor propagation" each cover what c-RCP splits into whole separate prefix families. 4 of these 12 are themselves among the 160 atomicity-proxy-flagged ids above.

Checklist

• Add status/scope fields to the .fusa-reqs.json schema and backfill all 410 entries (mirrors c-RCP's original schema rollout)
• Finish the tc18/tc18_master_id propagation "Part 2" for the remaining 261 entries (continuing PRs docs(fusa): [c-RCP-18-tracker Part 1] propagate tc18_master_id for REQ-WIRE-* #108-113's pattern)
• Write a "Writing a requirement" section into CONTRIBUTING.md: per-function tag placement + one-shall-statement-per-id atomicity convention (do this before the retagging/splitting work below, so batches have a documented standard to follow — mirrors c-RCP's CONTRIBUTING.md:65-111)
• Retag ~103 files from file-header-block to per-function placement, batched by subsystem (endpoints / wire-core / request-sequencer / lifecycle-power / mock-server / bridges — mirrors how c-RCP split its own equivalent batches)
• Run the atomicity audit itself: triage the 160 proxy-flagged entries against CONTRIBUTING.md's new convention, split genuinely bundled ones, batched the same way as the retagging pass (can be combined into the same PRs per subsystem, since both touch the same files)
• Re-derive REQ-CMP-*/REQ-TRIG-*/REQ-CHAIN-*/REQ-TIMED-*/REQ-CANCEL-* from the 12 existing REQ-SEQ-* entries, splitting bundled ones per the above at the same time; keep a residual REQ-SEQ-* for what doesn't cleanly fall into the other five (timestamp decode, lifecycle state machine, error category, opcode/priority mechanics)

Not in scope here

Runtime/dispatch behavior changes are out of scope for this tracker — it's schema, documentation, and traceability only. See the sibling ASIL-D tracker for behavior-affecting safety work.