docs(fusa): [c-RCP-18-tracker Part 1] propagate tc18_master_id for REQ-CANEP-*/REQ-I2C-*/REQ-ISELED-*/REQ-LINEP-*/REQ-MDIO-*/REQ-ADC-*

[SoundMatt]

docs(fusa): [c-RCP-18-tracker Part 1] propagate tc18_master_id for REQ-CANEP-/REQ-I2C-/REQ-ISELED-/REQ-LINEP-/REQ-MDIO-/REQ-ADC-

This batch links 21 of the 32 requirements across REQ-CANEP-* (7),
REQ-I2C-* (5), REQ-ISELED-* (5), REQ-LINEP-* (4), REQ-MDIO-* (5), and
REQ-ADC-* (6) to their TC18 master-catalog clauses (RELAY's
docs/tc18-master-catalog.json), verified directly against TC18.txt
(the line-numbered plaintext extraction) and cpp-RCP's own
include/rcp/{can,i2c,iseled,lin,mdio,adc}.hpp headers and their
tests/test_*.cpp files — not copied from go-RCP's already-merged
equivalent batches, per the task's instruction to verify independently
since cpp-RCP's own wording/implementation choices can differ even
where the underlying TC18 clause is identical.

All six prefixes are the genuine per-endpoint-type TC18 packages (same
role as go-RCP's already-confirmed CAN/I2C/ISELED/LIN/MDIO/ADC
equivalents), not part of cpp-RCP's non-TC18 integration-shell set —
confirmed by reading each header's own doc comment, none of which
carries a TC18-scope disclaimer.

Linked (21):

REQ-LINEP-001 -> TC18-13.2-002 ep_type=0x06, Table 32 "ep_type values"
REQ-LINEP-002 -> TC18-13.7.10.3-001 Figure 39 raw "Lin payload" wire region, no PID/checksum/schedule sub-fields
REQ-LINEP-003 -> TC18-13.7.10.1-001 match-based reply behavior underlying responded/no-responded branching

REQ-CANEP-001 -> TC18-13.2-002 ep_type=0x0B, Table 32 "ep_type values"
REQ-CANEP-003 -> TC18-13.7.11.3-004 "Sending remote frames is not supported."
REQ-CANEP-004 -> TC18-13.7.11.3-002 CAN XL 2054-byte ceiling + segmentation requirement
REQ-CANEP-005 -> TC18-13.7.11.2-002 Table 56 CAN bit time registers 1/2/3 (Classical/FD/XL)
REQ-CANEP-006 -> TC18-13.7.11.2-002 Table 56 acceptance/receive filter register fields

REQ-ISELED-001 -> TC18-13.2-002 ep_type=0x0C, Table 32 "ep_type values"
REQ-ISELED-002 -> TC18-13.7.12.3-001 Figure 41 request shape (+ Figure 42 response shape cited in-text)
REQ-ISELED-003 -> TC18-13.7.12.3-004 "A response always contains the 12 bit address and 12 bit data plus the optional 4 bit CRC."
REQ-ISELED-004 -> TC18-13.7.12.1-002 "single trigger event ... when transmission ... has been completed"

REQ-MDIO-001 -> TC18-13.2-002 ep_type=0x0D, Table 32 "ep_type values"
REQ-MDIO-002 -> TC18-13.7.13.3-002 Table 60 mdio_payload width rules per mdio_mode

REQ-I2C-002 -> TC18-13.7.7.1-003 optional wait-for-bit-sequence request
REQ-I2C-003 -> TC18-13.7.7.3-001 transparent raw payload incl. address (Figure 30)
REQ-I2C-004 -> TC18-13.7.7.4-001 optional HW trigger event generation (Table 50's own Event column is blank in the extraction, so specific signal names are this implementation's own)

REQ-ADC-001 -> TC18-13.7.9.3-003 "A measured value may contain the average of multiple ADC samples..."
REQ-ADC-002 -> TC18-13.7.9.1-006 averaging-interval + COMBINE_NR_VAL clause (also corrects this entry's PRE-EXISTING tc18 citation, added before this batch: it quoted this exact text but misattributed it to §13.7.9.2 L5040 — verified against TC18.txt, the quote only occurs at §13.7.9.1 L5455-5457)
REQ-ADC-003 -> TC18-13.7.9.1-010 "The ADC only samples the input, when a request is executed..."
REQ-ADC-004 -> TC18-13.7.9.1-002 PWM-triggered ADC read concept

Deliberately skipped (11), with reasoning:

REQ-I2C-001 i2c_mode's coarse hs-bit decode is an explicitly
documented open item (header comment: "pending a
future spec errata pass") — no single TC18 clause
cleanly covers an intentionally-unresolved ambiguity.
REQ-I2C-005 boilerplate error-category/non-empty-message test,
no distinct TC18 clause.
REQ-CANEP-002 11-bit/29-bit CAN identifier numeric range boundaries
(0x7FF / 0x1FFFFFFF) are standard CAN-protocol facts;
TC18's own CAN section text only states "In case the
CAN ID is 11bits, then it shall be right aligned..."
(right-alignment, not range validation) and never
states the 29-bit extended range numerically anywhere
in the extraction — grepped TC18.txt to confirm no
"29-bit"/"29 bit"/"0x1FFFFFFF" text exists.
REQ-CANEP-007 Combines two things, neither independently citable:
(a) "CAN has no TriggerRegistry" is a structural
absence (TC18's CAN section genuinely has no trigger-
signal subsection, unlike I2C/ADC/UART/PWM), which
cannot be supported by a positive spec quote; (b) the
CanErrc-category half is the same boilerplate pattern
skipped everywhere else in this batch.
REQ-ISELED-005 boilerplate error-category test, no distinct TC18
clause.
REQ-MDIO-003 register write-then-read round-trip and "unwritten
register reads 0" are this implementation's own
internal-fidelity choices; TC18's MDIO section has no
register-persistence-semantics text to cite.
REQ-MDIO-004 (mdio_mode, mdio_address) register-space distinctness
is implementation-internal; MDIO's TC18 section
(13.7.13.1-.3) has no trigger-signal subsection at
all (unlike I2C/ADC/UART/PWM), so "notify
TransferComplete on every request" also has no TC18
basis to cite.
REQ-ADC-005 AdcErrc::no_signal is explicitly documented in
adc.hpp's own header comment as "an internal
condition... not a TC18 error code" (TC18's Table 27
error-code list has no ADC-specific no-signal entry)
— the missing-triggered-capture behavior this
requirement tests is this implementation's own choice,
not a spec clause.
REQ-ADC-006 boilerplate error-category test, no distinct TC18
clause.
REQ-LINEP-004 boilerplate error-category test, no distinct TC18
clause.

Citation correction found: REQ-ADC-002's tc18 field (added before this
batch, likely from an earlier ADC-focused pass — this batch found it
already present but WITHOUT a tc18_master_id) cited "§13.7.9.2 ...
TC18.txt L5040" for the "an implementation may decide to fix" quote.
Verified against TC18.txt directly: that quote exists exactly once, at
§13.7.9.1 L5455-5457, not §13.7.9.2, and not at L5040. Corrected in
this commit alongside adding the missing tc18_master_id.

Drift finding (not corrected, out of this pass's metadata-only scope):
REQ-ISELED-004's title/text still describe a NativeCrcError trigger
signal and IseledErrc::native_crc_mismatch error that
include/rcp/iseled.hpp's own header comment documents were removed by
the issue #71/cpp-RCP-02 wire-format fix (the invented CRC-8 was
removed because this repo has no verified copy of the real ISELED CRC
algorithm). tests/test_iseled.cpp's REQ-ISELED-004 case now only
exercises the single surviving TransferComplete signal. This entry is
still linkable (TC18-13.7.12.1-002, "single trigger event ... when
transmission ... has been completed" matches the current, narrower
tested behavior), but its title/text predate that fix and should be
updated by a future pass; flagged here rather than silently
correcting content outside this PR's stated scope.

Verification (branch tc18-533-propagate-canep-i2c-iseled-linep-mdio-adc-master-id,
based on origin/main @ 0bbe7dd, re-confirmed fresh immediately before push):

• cmake -B build -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_STANDARD=17
  -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DRELAY_BUILD_CLI=ON -G Ninja
  && cmake --build build --parallel: 219/219 targets, 0 errors
  (pre-existing toolchain -Wnonnull notes in unrelated
  test_l2.cpp/test_udp.cpp translation units only, not from this
  change).
• ctest --test-dir build --output-on-failure -j1: 53/53 suites
  passed (100%), 47.51s.
• cpp-FuSa v0.18.0 (built from source, matching
  .github/workflows/ci.yml's pin) cpfusa check: 0 errors, 2
  warnings, 1 info — identical before and after this change
  (pre-existing FUSA004/FUSA005/HARA005 findings, unrelated to
  .fusa-reqs.json).
• cpfusa trace --format json coverage: totalRequirements=376,
  tracedRequirements=376, testedRequirements=376,
  secTestedRequirements=64 — identical before and after (confirmed
  via git stash A/B comparison), consistent with PR docs(fusa): [c-RCP-18-tracker Part 1] propagate tc18_master_id for REQ-WIRE-* #108's own
  stated 376/376/376/64 baseline. Metadata-only change, no coverage
  impact.
• git diff --stat: .fusa-reqs.json | 83 ++++++++++++++++++++--------
  (62 insertions, 21 deletions) across exactly 21 requirement
  entries (20 newly linked + REQ-ADC-002's pre-existing tc18 field
  corrected and given its tc18_master_id).

Signed-off-by: Matt Jones 47545907+SoundMatt@users.noreply.github.com
Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com

[SoundMatt]

Independent review follow-up: found and fixed one citation-accuracy defect. REQ-ISELED-004 (whose own text is entirely about NativeCrcError/native_crc_mismatch CRC verification) was linked to TC18-13.7.12.1-002, the adjacent trigger-event clause ("The ISELED endpoint creates a single trigger event..."), not the CRC-related clause the requirement is actually about. Corrected to TC18-13.7.12.1-001 ("The optional CRC generation as specified in the ISLED standard can be enabled. If so, the CRC will be generated and attached to the write messages to the ISELED network. For read data accordingly the CRC will be also calculated and checked.", TC18.txt L5910-5912) — verified directly against TC18.txt. The original batch's own flagged finding (this entry's stale title/text referencing a removed NativeCrcError signal, issue #71/cpp-RCP-02) is preserved as still correct and out of scope here.

Spot-checked 7 other citations directly against TC18.txt (I2C-002/003/004, ADC-002 correction, all 4 §13.2 Table 32 ep_type entries) — all verified byte-exact. Merge-base confirmed fresh against origin/main both before I started and just now before push (no rebase needed this time).

Re-verified after the fix: cmake+ninja build 219/219 targets clean, ctest 53/53 passing, cpfusa v0.18.0 check 0 errors (2 warnings/1 info, matches baseline), trace coverage unchanged at 376/376/376/64. Watching CI, will merge once green.