docs(fusa): [c-RCP-18-tracker Part 1] propagate tc18_master_id for REQ-CAN-*/REQ-GPIO-*/REQ-PWM-*/REQ-SPI-*/REQ-UART-*/REQ-WAKEUP-*

[SoundMatt]

docs(fusa): [c-RCP-18-tracker Part 1] propagate tc18_master_id for REQ-CAN-/REQ-GPIO-/REQ-PWM-/REQ-SPI-/REQ-UART-/REQ-WAKEUP-

Scope note: REQ-CAN-* does not exist in cpp-RCP's .fusa-reqs.json. Unlike
go-RCP (where a REQ-CAN-* client-ergonomics wrapper package canbr still
exists alongside the real endpoint's REQ-CANEP-), cpp-RCP's canbr.hpp/
linbr.hpp bridge stubs — which historically used REQ-CAN-001..004/
REQ-LIN-001..004 (ROADMAP.md, "44 requirement entries that back the
deleted packages") — were already DEPRECATEd and deleted outright in a
prior milestone, and their requirement entries pruned from
.fusa-reqs.json entirely (README.md: "CAN and LIN are native TC18
Endpoint types ... not bridge targets, so this package carries no
canbr.hpp/linbr.hpp"). REQ-CANEP- (the real CAN endpoint) was already
linked in PR #109. So there is nothing to link under REQ-CAN-* here: 0
entries exist under that prefix.

This batch instead covers cpp-RCP's remaining per-endpoint-type packages:
REQ-GPIO-* (9), REQ-PWM-* (7), REQ-SPI-* (5), REQ-UART-* (7),
REQ-WAKEUP-* (5) — 33 entries in scope, 24 linked, 9 deliberately skipped.

Section numbers verified directly against TC18.txt (not assumed from
memory or from go-RCP's citations, which use a different section
layout for at least PWM):

• GPIO: §13.7.4 (NOT §13.7.3 as originally guessed — §13.7.3 is SPI)
• SPI: §13.7.3
• PWM_OUT: §13.7.5, PWM_IN: §13.7.6
• UART: §13.7.8
• WAKEUP: §13.7.2
• Shared evt-field semantics table (GPIO/PWM_OUT write combinators,
  saturation, ep_type enum, compound-wait): §13.2/§13.5/§13.5.1

== Per-prefix verdict ==

REQ-CAN-*: 0 entries exist (see scope note above). N/A.

REQ-GPIO-* (9 total): 6 linked, 3 skipped.
Linked: 001, 002, 003, 004, 005, 009.
Skipped:
- 006 "GPIO functional config block wiring" — the file's own header
comment explicitly disclaims that "the concrete pin-direction bit
convention, functional-config layout... chosen in this file are
this implementation's own." TC18's actual GPIO functional-config
register map (Table 44, §13.7.4.2) has no pin-direction or
per-pin edge-enable fields at all (only debounce/clock/enable/
status) — linking to Table 44 would be a section-proximity match,
not a content match, the exact mistake PR #109's review caught.
- 007 "GpioEndpoint request-dispatch pattern" — an internal API
orchestration claim (apply write + evaluate triggers + report
bitmask "in one call"); its constituent behaviors are already
individually covered by REQ-GPIO-002/003/004/005's own citations.
Same shape as REQ-MDIO-003 ("MDIO register write-then-read
round-trip"), left unlinked in PR #109 for the same reason.
- 008 "GpioEndpoint error propagation and GpioErrc category" —
implementation-only error-category plumbing, consistent with
every other endpoint's *Errc entries (REQ-SPI-005, REQ-I2C-005,
REQ-ADC-006, REQ-MDIO-005, REQ-UART-007, REQ-PWM-007,
REQ-WAKEUP-005 below) being left unlinked throughout this and the
prior batch.

REQ-PWM-* (7 total): 6 linked, 1 skipped.
Linked: 001, 002 (citation corrected), 003 (citation corrected), 004,
005, 006 (citation corrected).
Skipped: 007 (PwmErrc error category — implementation-only, see above).

REQ-SPI-* (5 total): 4 linked, 1 skipped.
Linked: 001 (citation corrected), 002, 003, 004.
Skipped: 005 (SpiErrc error category — implementation-only).

REQ-UART-* (7 total): 4 linked, 3 skipped.
Linked: 001, 002, 003, 005.
Skipped:
- 004 "UART payload-less pure read requests" — TC18 §13.7.8.1 only
says a UART read carrying a byte_msg_payload is rejected
(UNKNOWN_CMD); it does not define a distinct non-blocking
"pure read" request kind for UART the way §13.7.4.3 explicitly
names one for GPIO. handle_pure_read's own doc comment concedes
this is this implementation's own API convenience ("no read_size
is carried at all, so there is nothing to wait on"), not a
TC18-named UART behavior distinct from what REQ-UART-002/003
already cover.
- 006 "UART RX FIFO / read_size single-AVTPDU accepted limitation"
— this requirement documents a deliberate NON-conformance: TC18
§13.7.8.1 mandates fragmenting the response when read_size
exceeds uart_rx_fifo_size (TC18-13.7.8.1-004); this milestone's
accepted limitation (ROADMAP.md milestone 52, fragmentation
no-go) instead rejects such requests outright. Linking it would
misrepresent a documented gap as coverage.
- 007 (UartErrc error category — implementation-only).

REQ-WAKEUP-* (5 total): 4 linked, 1 skipped.
Linked: 001, 002, 003, 004.
Skipped: 005 (WakeupErrc error category — implementation-only).

== Full id -> master-catalog-id mapping (24 entries) ==

REQ-GPIO-001 -> TC18-13.7.4.1-005 "GPIO request length validation": TC18
requires rejecting any GPIO request not exactly 4 bytes
(INVALID_PARAMETER); matches kGpioPayloadLen=4 / short_buffer.
REQ-GPIO-002 -> TC18-13.5-001 "EP-specific usage of evt-field": Table 33's
GPIO/PWM_OUT row defines evt[2:0]=000b/001b/010b/011b as
Replace/OR/AND/XOR against current interface status; matches
apply_bitmask_write's Replace/Or/And/Xor.
REQ-GPIO-003 -> TC18-13.5-003 "Saturation arithmetic for GPIO/PWM_OUT
add/subtract": "neither overflows nor wrap-arounds... saturated at
0x0000/0xFFFF" — matches the saturating (not wrapping) Add/Subtract
rule directly.
REQ-GPIO-004 -> TC18-13.5-001: same Table 33 GPIO/PWM_OUT row,
evt[2:0]=100b (reserved/rejected) and 111b (reconfigure — endpoint
config change, not a value written to the interface); matches
Reserved-rejected / Reconfigure-retargets-directions split.
REQ-GPIO-005 -> TC18-13.7.4.1-011 "Optional GPIO edge/change trigger
generation": "generates triggers for all its mapped IO-pins on the
change, falling and rising edge" — matches per-pin Change/Rising/
Falling signal evaluation.
REQ-GPIO-009 -> TC18-13.7.4.3-004 "Write to input pin is ignored":
"A write request to an input pin is ignored for this input pin" —
direct match, quote already correct pre-existing; only the line
number and master_id were added.

REQ-PWM-001 -> TC18-13.7.5.3-001 "pwmo request format": "The PWM_out
request and response contain two values in the payload. The active
time... as well as the period" — matches the shared two-field
PwmValue{period, active_duration} shape.
REQ-PWM-002 -> TC18-13.5-001: Table 33 GPIO/PWM_OUT row, evt[2:0]=000b
("byte_msg_payload is presented at the interface") — matches Replace
applying period/active_duration directly. CITATION CORRECTED (was
"Table 30", which is TC18's actual "Error codes in responses" table,
not the evt-field table — the real table is Table 33).
REQ-PWM-003 -> TC18-13.5-003: same saturation clause as REQ-GPIO-003,
applied per-field to PwmValue's uint16_t range. CITATION CORRECTED
(was "Table 30" + "TC18.txt L3694-3714", which points at an unrelated
sequencer request-state-machine passage, not Table 33/the saturation
note at all).
REQ-PWM-004 -> TC18-13.5-001: same Table 33 row, evt[2:0]=100b/111b, as
REQ-GPIO-004 — matches Reserved-rejected / Reconfigure-unsupported
(PWM_OUT has no reconfigure target of its own besides its functional
config registers).
REQ-PWM-005 -> TC18-13.7.6.1-001 "PWM_IN max-period exceeded /
source-loss error notification": "if... the external PWM source
stops, the PWM_IN endpoint will detect this and... notify the RC
Client with an error response message" (error code PWM_IN_NO_SIGNAL,
Table 30) — matches no_signal before first measurement / after
clear_signal().
REQ-PWM-006 -> TC18-13.7.6.1-002 "pwmi trigger outputs": Table 47 defines
exactly two PWM_IN trigger signals (0=rising edge, 1=falling edge) —
matches RisingEdge/FallingEdge notification. CITATION CORRECTED (was
"§13.7.5.1 Table 44" — §13.7.5.1 is PWM_OUT's pin-config section and
Table 44 is GPIO's functional-config register map; the real anchor is
§13.7.6.1 Table 47, the actual "pwmi trigger outputs" table).

REQ-SPI-001 -> TC18-13.7.3.2-006 "Parallel SPI: up to 6 CS
configurations, selected via evt[2:0]": "up to 6 CS signals may be
handled by the SPI endpoint... the SPI bus functional configuration
supports up to 6 different configurations in parallel... determined
by evt[2:0]" — matches kMaxChannels=6, evt[2:0] 0-5 valid / 6,7
rejected. CITATION CORRECTED (was "§13.7.3.1" quoting "up to 6
pre-configurable sets of SPI configurations" at L4192 — TC18.txt
L4192 is CRC/Safe-command-mode text, unrelated; and §13.7.3.1's real
text says "up to 16" pre-configurable sets selected via byte_bus_id,
not evt[2:0] — a known, spec-internal, editorially-flagged
inconsistency between the "16" figure in §13.7.3.1 and the "6" figure
in §13.7.3.2, per master-catalog entry TC18-13.7.3.1-002's own notes.
cpp-RCP's kMaxChannels=6 + evt[2:0] selection matches §13.7.3.2's "6"
clause, not §13.7.3.1's "16" one).
REQ-SPI-002 -> TC18-13.5.1-001 "Compound-wait byte-length mismatch
handling": "the interface status shall be capped to the length of
the byte message payload. For SPI this means that e.g. only the
first four out of 20 received bytes will be checked..." — exact
match, including cpp-RCP's own kCompoundWaitCompareLen=4 /
kMaxStatusBytes=20 constants mirroring TC18's own worked example.
REQ-SPI-003 -> TC18-13.7.3.1-003 "Client byte-send request to SPI
endpoint": "The RC Client can request the SPI endpoint to send one or
more bytes that are delivered as byte_msg_payload..." — matches the
raw PICO-out/POCI-in transfer request/response mechanism.
REQ-SPI-004 -> TC18-13.7.3.1-007 "SPI trigger outputs mapping": Table 41
defines signal 0 = SPI execution done, (2+2n) = CSn asserted,
(3+2n) = CSn de-asserted — matches CsAssert/TransferComplete/
CsDeassert and the per-(channel,signal) distinct SignalId scheme (the
specific notification order is this implementation's own choice,
not spec-mandated, consistent with this file's own disclaimer).

REQ-UART-001 -> TC18-13.7.8.1-001 "UART EP dual independent TX/RX
request storages": "these two processes are independent from each
other, thus the UART EP has two EP request storages" — direct match.
REQ-UART-002 -> TC18-13.7.8.1-002 "UART RX FIFO buffering and overflow
flagging": "the UART EP shifts the received data into a
fifo-rx-buffer... emptied by read requests. Overflow is flagged..."
— direct match.
REQ-UART-003 -> TC18-13.7.8.1-004 "UART read request trigger conditions
and fragmentation sizing": "A read request will be started as soon
as the fifo-rx-buffer is filled with as many bytes as requested in
the read_size or when the uart_timeout has expired" — matches the
read-completion rule. (Citation deliberately quotes only the
read_size/timeout portion, not the fragmentation sentence that
follows it in the same TC18 passage — this implementation's
read_size_exceeds_bound rejection is a documented divergence from
that fragmentation behavior, per REQ-UART-006, not an implementation
of it.)
REQ-UART-005 -> TC18-13.7.8.3-004 "UART EP ignores trailing
non-integer-multiple bits when transmitting": "In case uart_nr_bits
is not a multiple integer of 8... the EP ignores the last up to
'uart_nr_bits - 1' bits..." — matches the sub-octet
mask-to-low-bits/zero-pad-high-bits packing rule.

REQ-WAKEUP-001 -> TC18-13.2-002 "ep_type enumerated values": Table 32
lists 0x01 = WakeUp — matches kEndpointTypeWakeup=0x01. Same
master_id as REQ-CANEP-001/REQ-MDIO-001 from PR #109 (same table,
different row). Deliberately NOT linked to TC18-13.7.2.1-001 ("WakeUp
endpoint fixed at EP nr 1") — that clause is about EP_Nr (instance
position), a different field from ep_type (the type-code value this
requirement actually tests); confirmed by reading endpoint.hpp's own
kEndpointType* constant block, which is exactly Table 32's ep_type
enumeration.
REQ-WAKEUP-002 -> TC18-13.7.2.3-004 "SleepCMD fixed code value":
"SleepCMD is coded as 0xA5." — direct, exact match.
REQ-WAKEUP-003 -> TC18-13.7.2.2-002 "WakeUp functional configuration
register map": Table 39's wup_status register — "Indication of
wake-up source, writing '1' clears the flag. Each bit represents a
wake-up source" — matches record_wake_source_event setting a bit /
clear_wake_source_pins() resetting the mask.
REQ-WAKEUP-004 -> TC18-13.7.2.1-002 "Repetitive wake-up messages after
reconnection": "After establishing a network connection, the WakeUp
endpoint sends repetitive messages. The timing interval is
configurable (flush_time)." — matches the repeating WakeUp-message
handshake for hot-start-from-Sleep.

== Citation corrections found (5) ==

1. REQ-SPI-001: wrong section (§13.7.3.1 instead of §13.7.3.2), wrong
   quote (misattributed the "6" figure to §13.7.3.1's text, which
   actually says "16"), and wrong line number (L4192 is CRC/Safe-mode
   text, not SPI channel-count text at all).
2. REQ-PWM-002: "Table 30" corrected to "Table 33" (Table 30 in TC18 is
   "Error codes in responses"; the evt-field table is Table 33).
3. REQ-PWM-003: same Table 30->33 correction, plus the line range
   L3694-3714 (sequencer request-state-machine text) corrected to the
   real Table 33 saturation-note location, L4094-4119.
4. REQ-PWM-006: "§13.7.5.1 Table 44" corrected to "§13.7.6.1 Table 47"
   (§13.7.5.1/Table 44 are PWM_OUT/GPIO material; PWM_IN's actual
   trigger-outputs table is §13.7.6.1 Table 47).
5. REQ-GPIO-009: quote content was already accurate; only the missing
   "TC18.txt L####" line-number suffix was added for consistency with
   every other linked entry's citation format.

Note: REQ-PWM-002/003's own pre-existing text fields also say
"§13.5 Table 30" — left untouched per field-preservation (only tc18/
tc18_master_id are new/corrected fields in this batch); the text
field's wording is a separate, smaller pre-existing inaccuracy not in
this batch's scope to rewrite.

== Deliberately-untouched entries (9) ==
REQ-GPIO-006, REQ-GPIO-007, REQ-GPIO-008, REQ-PWM-007, REQ-SPI-005,
REQ-UART-004, REQ-UART-006, REQ-UART-007, REQ-WAKEUP-005 — reasoning
per-entry above (per-prefix verdict section).

== Verification ==

• 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 rebuild, 0 errors.
• ctest --test-dir build --output-on-failure -j1: 53/53 passing
  (matches PR 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-* #109 baseline).
• cpfusa v0.18.0 check: 0 errors, 2 warnings, 1 info (unchanged from
  baseline).
• cpfusa v0.18.0 trace --format json: 376 total/376 traced/376 tested/
  64 secTested (identical before and after — only citation metadata
  fields were added, no requirement entries or test annotations
  changed).
• git diff --stat: 1 file changed (.fusa-reqs.json only), 67
  insertions(+), 24 deletions(-) — 24 tc18_master_id fields added, 24
  tc18 fields present after (19 new + 5 corrected in place).

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