docs: v2.25.0 — extract and formally reference every TC18 SHOULD/MAY clause

.fusa-reqs.json

@@ -342,7 +342,8 @@
       "text": "rcp::e2e::endpoint_in_configured_safe_state shall return the caller-supplied force_high_impedance_asserted flag unchanged when RequestStreamConfig::rx_safety_measure is RxSafetyMeasure::ForceHighImpedance, and shall return whether rx_safestate_sequencer's current SequencerTable value equals rx_safe_sequencer_state (false if the index is out of range) when rx_safety_measure is RxSafetyMeasure::RunSafeSequencer.",
       "standard": "iso26262",
       "level": "ASIL-B",
-      "asil": "ASIL-B"
+      "asil": "ASIL-B",
+      "tc18": "§12.7.7 (\"a safe state may be enforced. The safe state to enter can be chosen via the Safety_Measure parameter\"), TC18.txt L2935"
     },
     {
       "id": "REQ-E2E-012",
@@ -502,7 +503,8 @@
       "text": "rcp::powerstate::PowerMode shall define exactly four modes (Normal, StandBy, Sleep, Unpowered), and a freshly constructed PowerManager shall report Normal as its initial mode() value.",
       "standard": "iso26262",
       "level": "ASIL-B",
-      "asil": "ASIL-B"
+      "asil": "ASIL-B",
+      "tc18": "§12.4 (\"The RC Server may support different power modes\"), TC18.txt L2268"
     },
     {
       "id": "REQ-PWR-002",
@@ -2014,7 +2016,8 @@
       "text": "rcp::lifecycle::ServerState shall encode HwUnconfigured as 0x00, HwConfigured as 0x55, and RcpConfigured as 0xAA, and a freshly constructed ServerLifecycle shall report HwUnconfigured as its initial state.",
       "standard": "iso26262",
       "level": "ASIL-B",
-      "asil": "ASIL-B"
+      "asil": "ASIL-B",
+      "tc18": "§12.3 (\"The three lifecycle states the device may be in are...\"), TC18.txt L2063"
     },
     {
       "id": "REQ-LIFECYCLE-002",
@@ -2383,7 +2386,8 @@
       "text": "rcp::spi::kMaxChannels shall be 6; rcp::spi::channel_of shall accept evt[2:0] values 0-5 as channel selectors (masking its input to the low 3 bits first) and return SpiErrc::channel_out_of_range for 6 and 7.",
       "standard": "iso26262",
       "level": "ASIL-B",
-      "asil": "ASIL-B"
+      "asil": "ASIL-B",
+      "tc18": "§13.7.3.1 (\"the SPI endpoint may support up to 6 pre-configurable sets of SPI configurations\"), TC18.txt L4192"
     },
     {
       "id": "REQ-SPI-002",
@@ -2527,7 +2531,8 @@
       "text": "rcp::adc::AdcEndpoint::request_reading shall average adc_avg_intervals_per_request raw samples per averaged-interval value (level 1), shall combine adc_combine_avg_values such averaged-interval values into the reported result (level 2), and shall return AdcErrc::invalid_averaging_config when either configuration field is 0.",
       "standard": "iso26262",
       "level": "ASIL-B",
-      "asil": "ASIL-B"
+      "asil": "ASIL-B",
+      "tc18": "§13.7.9.2 (\"an implementation may decide to fix\" the samples-per-interval field read-only; this implementation instead makes it writable, the more general of the two spec-permitted choices), TC18.txt L5040"
     },
     {
       "id": "REQ-ADC-003",
@@ -3002,7 +3007,8 @@
       "text": "rcp::l2::encode_l2_multi_frame/decode_l2_multi_frame shall round-trip two or more ACF_ABB/ACF_GBB messages packed into a single Ethernet frame's AVTPDU, per extraction \u00a712.9.1.1's multiple-requests-in-one-frame requirement, the same as rcp::udp::MultiFrame's equivalent guarantee.",
       "standard": "iso26262",
       "level": "ASIL-B",
-      "asil": "ASIL-B"
+      "asil": "ASIL-B",
+      "tc18": "\u00a712.9.1.1 (\"An RCP frame may include multiple ACF-types (requests)\"), TC18.txt L3220"
     },
     {
       "id": "REQ-L2-008",

CMakeLists.txt

@@ -1,7 +1,7 @@
 cmake_minimum_required(VERSION 3.21)
 
 project(cpp-rcp
-    VERSION 2.24.0
+    VERSION 2.25.0
     DESCRIPTION "Remote Control Protocol for automotive zonal architecture (C++)"
     HOMEPAGE_URL "https://github.com/SoundMatt/cpp-RCP"
     LANGUAGES CXX

ROADMAP.md

@@ -2386,6 +2386,36 @@ previous (incorrect) behavior — BREAKING. `rcp/pwm.hpp`/`rcp/gpio.hpp`
 are the only files touched; every other endpoint header, `rcp/endpoint.hpp`
 itself, and the shared AVTPDU/ACF framing are unmodified.
 
+### SHOULD/MAY extraction + references pass (v2.25.0)
+
+Mirroring c-RCP's own SHOULD/MAY audit (its ROADMAP milestone 116):
+grepped the full TC18 spec text for every SHOULD (12) and MAY (44)
+occurrence, excluded 6 legal-boilerplate hits, and individually
+classified the remaining 51. Six already-implemented optional
+capabilities got a real `tc18` citation added to their existing
+requirement entry (`REQ-E2E-011`, `REQ-PWR-001`, `REQ-LIFECYCLE-001`,
+`REQ-SPI-001`, `REQ-ADC-002`, `REQ-L2-007`); the non-testable lines are
+recorded with individual citations in new
+`docs/TC18-NON-NORMATIVE-CLAUSES.md`.
+
+This pass also surfaced four MAY-described capabilities this repo does
+not appear to distinctly implement or track yet, honestly flagged rather
+than papered over with a citation: presentation-time-too-far/gPTP
+admission for Timed requests (§11.2.2.5 — `request.hpp` has no
+`presentation_time`/gPTP-domain logic at all), the EP_USED bit (§13.2 —
+no `ep_used` concept found anywhere), Triggered requests' own field-level
+encode/decode (§11.2.2.3 Table 8 — the opcode/priority classification
+exists in `request.hpp` but no distinct requirement cluster the way
+Compound/CompoundWait have one), and the integrated-PHY-via-MDIO
+deployment case (§13.7.13.1 — `mdio.hpp` doesn't discuss it the way
+c-RCP's `ep_mdio.h` does, though it may already work fine by the same
+reasoning). Each is recorded in `docs/TC18-NON-NORMATIVE-CLAUSES.md`
+marked ⚠ for its own follow-up investigation.
+
+No code behavior changed this pass. A fuller MUST-clause citation
+backfill (this repo had only 4/376 requirements citing TC18 before this
+session's work) remains separate, larger, future work.
+
 ---
 ### Appendix A — Legacy Roadmap (v0.1.0–v1.11, superseded)
 ---

docs/TC18-NON-NORMATIVE-CLAUSES.md

@@ -0,0 +1,53 @@
+# TC18 SHOULD/MAY clauses with no corresponding requirement
+
+Companion to `.fusa-reqs.json`'s MUST/SHALL requirement catalog. Every
+SHOULD/MAY occurrence in the OPEN Alliance TC18 Remote Control Protocol
+Specification is accounted for in one of two places: an existing `REQ-*`
+entry's `tc18` citation (search `.fusa-reqs.json` for the citation text
+below), or this document, when the clause is either non-testable prose or
+— honestly flagged below — a capability this repo does not yet distinctly
+track.
+
+No spec text is reproduced verbatim (confidentiality restriction); each
+line is paraphrased and cited by section/`pdftotext`-extraction line
+reference.
+
+**Depth note:** this pass mirrors c-RCP's SHOULD/MAY audit methodology
+(see that repo's own `docs/TC18-NON-NORMATIVE-CLAUSES.md` and ROADMAP.md
+milestone 116) but was done at a lighter verification depth given this
+repo's overall lower existing citation density (4/376 requirements had a
+`tc18` citation before this pass, vs. c-RCP's 212+). Four MAY clauses
+below are flagged as **gaps this pass found but did not fully resolve**
+(marked ⚠) — they need their own dedicated investigation, not a citation,
+because the underlying capability doesn't appear to be distinctly
+implemented in this codebase yet. A fuller MUST-clause citation backfill
+(matching c-RCP's ~975-entry, multi-session "requirements-corpus
+completeness pass") remains separate, larger, future work — see this
+project's master checklist memory.
+
+## SHOULD (10, all non-testable — same disposition as every TC18 implementation, this is about the standard's own text, not this codebase)
+
+| § | Citation | Paraphrase | Why no REQ |
+|---|---|---|---|
+| §2 (intro) | TC18.txt L773, L790, L795, L798, L803, L805 | Six design-goal statements about the standard itself (interchangeability, unambiguous behavior, version compatibility, etc.) | Non-normative prose about the spec's own philosophy, not a testable protocol clause. |
+| §11.2.2.1 | TC18.txt L1213 | Repetitive `cmp_start_state=0` compound requests should be last-sent or use a delay | Client request-composition advice; nothing for an RC Server to enforce. |
+| §11.2.2.2 | TC18.txt L1312 | Same advice for compound-wait | Same. |
+| §12.9.1 | TC18.txt L2988 | Endpoints sharing a `byte_bus_id` in one stream should be the same type | Client/config-authoring guidance, not server-enforceable. |
+| §13.7.12.2 | TC18.txt L5525 | `iseled_clk_divider` should be nominal 2MHz | Hardware calibration guideline for a register value, not a software behavior — this repo does not yet implement an ISELED endpoint at all; N/A either way. |
+
+## MAY — implemented and already cited (10, for reference; see the actual `.fusa-reqs.json` entries for full text)
+
+`REQ-E2E-011` (Safety_Measure, L2935), `REQ-PWR-001` (power modes, L2268), `REQ-LIFECYCLE-001` (three lifecycle states, L2063), `REQ-SPI-001` (SPI 6 channels, L4192), `REQ-ADC-002` (samples-per-interval R/W choice, L5040), `REQ-L2-007` (multi-request-per-frame, L3220).
+
+## MAY — genuinely uncertain / not yet distinctly tracked in this codebase (4, ⚠ needs follow-up, not just a citation)
+
+| § | Citation | Paraphrase | Finding |
+|---|---|---|---|
+| §11.2.2.5 | TC18.txt L1649 | RC Server may reject a request whose `presentation_time` is too far in the future | ⚠ **Not found**: `request.hpp` has no `presentation_time`/gPTP-domain admission logic at all (grepped for `presentation_time`, `Gptp`, `TooFar` — zero hits). c-RCP's equivalent (`rcp_timed_admit()`/`rcp_timed_too_far()`) is a good reference implementation. Needs its own investigation + fix, not a citation. |
+| §13.2 | TC18.txt L3502 | An endpoint may be used or not used in a specific RC Server instantiation (EP_USED bit) | ⚠ **Not found**: no `ep_used`/`EpUsed` concept anywhere in `include/rcp/*.hpp` (grepped, zero hits). Whether this is a real gap or handled implicitly by a different mechanism (e.g. the mock server's endpoint-registration model) wasn't determined this pass. |
+| §11.2.2.3 | TC18.txt L1413 | Each endpoint may be configured to start a request upon a trigger signal | ⚠ **Partially found**: `RequestTypeOpcode::Triggered`/`RequestCategory::Triggered` exist in `request.hpp`'s enums, but there is no distinct `REQ-TRIG-*` requirement cluster the way there is for Compound/CompoundWait — unclear whether Triggered's own field-level encode/decode (trigger_source_ep/trigger_signal_nr/trigger_threshold/trigger_exec_delay/trigger_repetitions, TC18 §11.2.2.3 Table 8) is actually implemented anywhere or just the opcode/priority-classification shell. Needs its own read-through. |
+| §13.7.13.1 | TC18.txt L5631 | An RC Server with an integrated PHY may allow access to it via the MDIO EP | ⚠ **Not addressed**: unlike c-RCP's `ep_mdio.h` (which explicitly documents this deployment mode as in-scope by design, needing no special-case code), cpp-RCP's `mdio.hpp` header has no equivalent discussion. Likely fine by the same reasoning (register-map access doesn't inherently require a physical pin mapping to be validated), but not independently confirmed this pass. |
+
+## MAY — descriptive/out-of-scope (27, same disposition as c-RCP's equivalent audit)
+
+L640 (Edge Node PTP/MACsec, L1/L2 topology concern), L909, L1024, L1025, L1588, L1943 (gPTP sync generally — implemented via this repo's own clock-sync handling but no single citable requirement), L2060, L2062, L2244, L2289, L2355, L2385, L2405, L2565, L2668, L2984, L2986, L2989, L3197, L3206, L3227, L3252, L4323, L5035, L5164, L5358 — each is either descriptive prose restating an architectural fact from a different angle, a client-side or hardware-deployment choice outside library scope, or a non-closed-list permission. See c-RCP's own `docs/TC18-NON-NORMATIVE-CLAUSES.md` for the identical per-line paraphrase and reasoning — the spec text and its non-normative character don't change per implementation.

include/rcp/version.hpp

@@ -6,6 +6,6 @@
 namespace rcp {
 
 // Semantic version of the cpp-RCP implementation (matches the latest git tag).
-constexpr std::string_view kVersion = "2.24.0";
+constexpr std::string_view kVersion = "2.25.0";
 
 } // namespace rcp