docs(fusa): [c-RCP-18-tracker Part 1] propagate tc18_master_id for REQ-WIRE-*

[SoundMatt]

Pilot batch of the cross-repo TC18-master-catalog-propagation effort on cpp-RCP (RELAY's docs/tc18-master-catalog.json, 447 entries), following the pattern already established across four merged go-RCP batches (#161-#164). Links the TC18-scoped REQ-WIRE-* requirements (the AVTP-header/ACF-message wire-encoding layer, cpp-RCP's equivalent of go-RCP's REQ-AVTP-* prefix) to their master catalog entry via a new tc18_master_id field, matching the field convention already used in go-RCP's and c-RCP's own .fusa-reqs.json. None of the 15 REQ-WIRE-* entries previously carried a tc18 citation at all (confirmed before starting: only 10 of 376 requirements repo-wide have one, none of them REQ-WIRE-*), so this batch is pure addition, not correction.

Every citation below was verified directly against TC18.txt (the plaintext extraction already used elsewhere in this repo's own tc18 citations), not copied from go-RCP's analogous mapping — several diverge from go-RCP's REQ-AVTP-* choices where cpp-RCP's wording pointed at a different, more precise clause.

8 requirements linked

id	->	master catalog id	why
REQ-WIRE-001	->	TC18-11.1-004	Figure 6 "NTSCF-Header Version 0"; stream_id/sequence_num_lsb/ntscf_data_length fields, cross-confirmed via the field-labelled Figure 21 ACF_GBB/NTSCF worked example in §13.6 (Figure 5/6 themselves render as blank diagrams in the plaintext extraction, so Figure 20/21's worked examples are what make the field layout independently text-verifiable).
REQ-WIRE-002	->	TC18-11.1-002	Figure 5 "TSCF-Header Version 0", same cross-confirmation via Figure 20.
REQ-WIRE-004	->	TC18-11.3-003	Table 17's explicit, format-wide rule: "acf_msg_type 0x0E - ABB message without message_timestamp / 0x0D - GBB message, with message_timestamp" / "message_timestamp Present in ACF_GBB, omitted in ACF_ABB". Chose Table 17 (§11.3, responses) over Table 4 (§11.2.1, standard requests) because Table 17 states the ABB/GBB timestamp-presence rule as a protocol-wide invariant while Table 4 only fixes mtv=0b for the standard-request case specifically; cpp-RCP's encode_acf_abb/decode_acf_abb are generic codecs used for both directions. go-RCP's analogous REQ-AVTP-011 used TC18-11.2.1-004 instead — not reused here since REQ-WIRE-004's claim ("since it defines no timestamp slot") is the more general one Table 17 makes explicitly.
REQ-WIRE-005	->	TC18-11.3-003	Same Table 17, whose field order (acf_msg_type/acf_msg_length/pad/mtv/rsv/byte_bus_id, then message_timestamp, then evt/hs/cs/transaction_num/op/rsp/err/ms/read_size-or-segment_num) matches the exact octet ranges the requirement specifies, for the genuine-timestamp GBB case (as opposed to the conditional-request GBB tables in §11.2.2.x, which repurpose those same bytes to encode a condition rather than a real timestamp — confirmed by reading Tables 6/7/8/9/12, all of which set mtv=0 and use non-timestamp field names in that byte range).
REQ-WIRE-006	->	TC18-11.2.1-005	Table 4's full field-by-field list matches every field the requirement names, and unlike Table 17 does not contradict the "evt ack flag + 3-bit sub-opcode" claim: Table 17's evt semantics are response-specific (0x0=simple/data/error, 0x1-0x8=counter, 0xF=ack) and would have been a wrong-linking, whereas Table 4's evt entry ("Endpoint specific usage, see section 13.5") and §13.5's own text ("evt[3] is used to request an acknowledge. I.e. evt[3] = 1 requests acknowledge.") are exactly the ack-flag/sub-opcode split cpp-RCP tests.
REQ-WIRE-009	->	TC18-11.2.1-002	"A request that is meant for best effort execution shall be sent in ACF_ABB format."
REQ-WIRE-010	->	TC18-11.3.1-001	Anchors the §11.3.1-§11.3.4 sequence (Acknowledge/Write/Read/Error identification by evt/op/err) that response_kind_of implements in full; matches go-RCP's REQ-AVTP-021 choice, independently re-derived here.
REQ-WIRE-011	->	TC18-11.1-002	Figure 5's tv bit is a validity marker held separately from the avtp_timestamp value field itself, cross-confirmed via Figure 20's rendered field labels ("...mr rsv tv sequence_num_lsb reserved tu...AVTP Time avtp_timestamp").

7 requirements deliberately left untouched

• REQ-WIRE-003 (subtype-mismatch decode rejection, AvtpErrc::bad_subtype) — defensive input-validation coding; TC18 defines what subtype value each header uses but has no MUST clause requiring a decoder to reject a mismatched one. Same category go-RCP left untouched for its analogous REQ-AVTP-003/004 (short-buffer / version-mismatch checks).
• REQ-WIRE-007 (StreamId MAC/suffix round-trip) — IEEE 1722 baseline concept (stream_id = MAC + unique_id), not a TC18-specific clause and outside the master catalog's §11-13 scope. Matches go-RCP's REQ-AVTP-006 reasoning exactly.
• REQ-WIRE-008 (byte_bus_id echoed unchanged on responses) — the precise textual match ("The endpoint will create responses and (if requested) acknowledges using the byte_bus_id that was included in the request") lives in TC18 §10.1/10.2, which the master catalog does not cover (catalog is scoped to §11-13 only). §13.1's "byte_bus_id is only unique in the context of a STREAM_ID" and Table 17's generic field list don't state the echo-on-response rule explicitly enough to cite with confidence; left unlinked rather than force a lower-confidence match.
• REQ-WIRE-012 (effective_timestamp: TSCF-preferred, then ACF_GBB, then none) — no single TC18 clause states this combined fallback rule. TC18 keeps TSCF avtp_timestamp (request execution time, §11.1/§11.4.3) and ACF_GBB message_timestamp (response capture time, §11.3/§11.4.2) as semantically distinct concepts tied to different message directions; this reads as a cpp-RCP-internal utility abstraction over both, not a spec-mandated behavior.
• REQ-WIRE-013 (decoders reject short buffers, AvtpErrc::short_buffer) — defensive bounds-checking, no distinct TC18 MUST clause. Same category as REQ-WIRE-003 and go-RCP's REQ-AVTP-003.
• REQ-WIRE-014 (ACF message-type mismatch rejected, AcfErrc::bad_acf_msg_type) — defensive input-validation coding, same category as REQ-WIRE-003/013; TC18 defines the acf_msg_type constant values (Table 4/17) but not a MUST to reject a decoder-observed mismatch.
• REQ-WIRE-015 (RELAY spec §15.5 canonical ControlFlags/Message conversion) — out of TC18 scope entirely. Its own standard field is already "relay" (not "iso26262"), and its text governs conversion to RELAY's own internal Go Message shape per RELAY spec §15.5, not any TC18 clause.

Verification

(commands and results — see also this repo's own .github/workflows/ci.yml)

• 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: clean build, 219/219 targets.
• ctest --test-dir build --output-on-failure -j1: 53/53 tests passing (100%), identical to pre-change.
• Pinned cpfusa v0.18.0 (git clone --depth=1 --branch v0.18.0 https://github.com/SoundMatt/cpp-FuSa): cpfusa check 0 errors (2 pre-existing warnings / 1 info, unrelated to this change, identical before/after).
• cpfusa trace --format json: totalRequirements/tracedRequirements/testedRequirements/secTestedRequirements = 376/376/376/64, byte-for-byte identical before and after this change (verified via git stash) — this batch adds citation metadata only, never adds/removes/re-tests a requirement.
• git status --short / git clean -ndx: only .fusa-reqs.json modified; build/ is gitignored; no stray artifacts.

This is the pilot batch establishing the propagation pattern for cpp-RCP's remaining prefixes.

Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com