docs(fusa): [c-RCP-18-tracker Part 1] propagate tc18_master_id for REQ-LIFECYCLE-*/REQ-PWR-*/REQ-WDG-*/REQ-ENDPOINT-*

[SoundMatt]

docs(fusa): [c-RCP-18-tracker Part 1] propagate tc18_master_id for REQ-LIFECYCLE-/REQ-PWR-/REQ-WDG-/REQ-ENDPOINT-

Scope: REQ-LIFECYCLE-001..007, REQ-PWR-001..014, REQ-WDG-001..008,
REQ-ENDPOINT-001..006 (35 entries, all previously 0 linked). 25 linked,
10 deliberately left unlinked (implementation-only behavior with no
TC18 textual counterpart, or a claim TC18 does not make). All section
numbers and line numbers verified directly against TC18.txt (6095-line
plaintext extraction), independent of any other repo's citations.

What each package actually is (confirming/correcting the batch hypothesis):

• REQ-LIFECYCLE-* (rcp/lifecycle.hpp): the 3-state HW_UNCONFIGURED /
  HW_CONFIGURED / RCP_CONFIGURED machine of TC18 §12.3/§12.3.1.x, plus
  the byte-encoding table in §13.7.1.2 Table 36 (EP0's own functional
  config register map). Confirmed.
• REQ-PWR-* (rcp/powerstate.hpp): TC18 §12.4/§12.4.1 (power modes,
  cold/hot start) and §12.5 (goto sleep/standby entry-refusal rules).
  Confirmed, with one notable naming discrepancy flagged below.
• REQ-WDG-* (rcp/watchdog.hpp): TC18 §12.7.7's per-request-stream
  watchdog/safe-state register fields (Table 24: rx_wd_timeout_intervall,
  rx_enforce_watchdog, rx_stream_status) plus the general safety-tagged-
  request retention rule of §11.2.2. This is narrower than "12.7.7 area"
  guessed in the task brief -- it also draws on §11.2.2, not just §12.7.7.
• REQ-ENDPOINT-* (rcp/endpoint.hpp): confirmed as the generic
  ep_type/evt-field/write-semantics/trigger-signal layer -- §13.2 Table 32
  (ep_type enum) and §13.5 Table 33 (evt[2:0] usage), the same tables
  already cited by prior batches' REQ-GPIO-/REQ-I2C- entries. All 6
  entries linked.

Pre-existing citations corrected (both had right topic, wrong TC18.txt
line number -- verified by grep for the quoted text itself):

• REQ-PWR-001: was "TC18.txt L2268" (that line is actually mid-Table-17,
  unrelated). Real location of "The RC Server may support different
  power modes." is L2644. Master id TC18-12.4-001 was already correct
  in spirit; added the definitions' line range (L2644-2651) and now also
  the tc18_master_id field.
• REQ-LIFECYCLE-001: was "TC18.txt L2063" citing "The three lifecycle
  states..." (that line is actually mid-Figure-15, unrelated -- the real
  "three lifecycle states" sentence is at L2438, part of the §12.3 intro
  before Figure 17). On closer reading, REQ-LIFECYCLE-001's actual content
  (ServerState encodes HwUnconfigured=0x00/HwConfigured=0x55/
  RcpConfigured=0xAA) is not this generic-enumeration sentence at all --
  it is the literal byte-value table, found only in §13.7.1.2 Table 36
  ("svr_lifecycle_state ... 0x00: HW_UNCONFIGURED / 0x55: HW_CONFIGURED /
  0xAA: RCP_CONFIGURED", TC18.txt L4388-4390). Re-cited to that clause and
  linked to TC18-13.7.1.2-001, a materially better content match than the
  original guess.

Full id -> master-catalog-id mapping (linked entries):

REQ-LIFECYCLE-001 -> TC18-13.7.1.2-001 -- Table 36's svr_lifecycle_state
row gives the exact 0x00/0x55/0xAA byte values the requirement asserts.
REQ-LIFECYCLE-002 -> TC18-12.3.1.1-006 -- "A request to advance the state
directly to RCP_CONFIGURED will be rejected" is TC18's one explicit
skip-rejection rule; the requirement generalizes it (also forbidding
backward moves and no-op repeats), which TC18 does not state as
explicitly for the other two transitions, but this is the only textual
anchor for the family of behavior.
REQ-LIFECYCLE-003 -> TC18-12.3.1.1-007 -- HW_CFG_INCONSITENT plausibility
check, exact match (spec's own spelling "INCONSITENT" reproduced in the
master catalog; code correctly spells INCONSISTENT).
REQ-LIFECYCLE-004 -> TC18-12.3.1.2-006 -- RCP_CFG_INCONSISTENT
plausibility check, exact match.
REQ-LIFECYCLE-005 -> TC18-12.3.1.2-001 -- "access to the HW_config and
EP_generic_config are locked" in HW_CONFIGURED is the direct source for
generic_config_locked; TC18-12.3.1.3-001 (RCP_CONFIGURED write-lock)
additionally informs the functional_config_locked half but only one
master id fits the field, so the more literally name-matching clause
was chosen.
REQ-LIFECYCLE-006 -> TC18-12.3.1.2-007 -- explicit revert-to-
HW_UNCONFIGURED via svr_lifecycle_state write. TC18 states this path
only from HW_CONFIGURED; the code's deconfigure() generalizes it to
work from any state, which is an implementation extension beyond the
literal text.
REQ-LIFECYCLE-007 -> UNLINKED -- callback-firing/ordering is a pure API
contract, no TC18 textual counterpart.

REQ-PWR-001 -> TC18-12.4-001 -- the four power-mode definitions
(Unpowered/Powered/Sleep/StandBy) match exactly; code's "Normal" is
TC18's "Powered".
REQ-PWR-002 -> UNLINKED -- "only from Normal" is a reasonable
precondition but TC18 §12.5 never states it explicitly.
REQ-PWR-003/004/005 -> TC18-12.5-005 (all three) -- the three bullets of
the sleep/standby REQUEST_CANCELED rejection list (wup_status not
cleared / EP not idle / responder queue non-empty) map 1:1 to these
three requirements, matching this catalog's existing precedent of
reusing one Table/list-bearing master id across several decomposed
REQ- entries (e.g. TC18-13.2-002 used 5x by earlier GPIO/I2C batches).
REQ-PWR-006 -> UNLINKED, with a finding: TC18 §12.4.1 explicitly labels
its network-re-enable/WakeUp-handshake procedure as the "Hot-start-up
procedure" (hot start = wake from StandBy, per its own L2663-2664
definition), but cpp-RCP's powerstate.hpp instead drives that identical
handshake from Sleep (calling it "hot-start-from-Sleep" in its own
header comment) and gives StandBy wake-up no handshake at all. This
looks like either a TC18 draft inconsistency (the handshake content --
re-enabling a powered-down network PHY -- fits recovery from Sleep,
where "only part of the network PHY shall be powered" per §12.5, far
better than StandBy, where wake-up control alone is said to stay
active) or a deliberate, unstated divergence in this implementation.
Left unlinked rather than asserting a citation that would misrepresent
the match; flagged here for maintainer attention.
REQ-PWR-007 -> TC18-12.4.1-003 -- the network-interface-reenable/
availability-check mechanics match this clause closely; see the
hot/cold naming caveat under REQ-PWR-006 above.
REQ-PWR-008 -> UNLINKED -- handshake-step guard against being called
outside an active handshake is a defensive-programming detail, not
independently specified in TC18.
REQ-PWR-009 -> UNLINKED -- the WakeUp message repeat limit with a
Failed terminal state is an implementation addition; TC18 L2676
describes unconditional repetition "until a valid AVTPDU ... is
received", with no stated give-up condition.
REQ-PWR-010 -> TC18-12.4.1-003 -- "After reception of valid message from
the sleep request Client all used endpoints and response queues will be
enabled" is an exact match for acknowledge_wakeup's queue-reenable/
Normal-transition behavior.
REQ-PWR-011 -> TC18-12.4-001 -- Unpowered's definition ("no sufficient
power supply is available") is inherently a hardware event outside
protocol-level refusal gating, matching the "unconditionally" claim.
REQ-PWR-012 -> TC18-12.4-001 -- Powered's definition is the basis for
"returns to Normal" on power restoration.
REQ-PWR-013 -> TC18-12.4.1-001 -- "a cold start (after power-on or
wake-up from sleep) and a hot start (=wake-up from StandBy)" is TC18's
own Hot/Cold definition sentence (L2663-2664); the master catalog does
not have its own entry for this specific intro sentence (12.4.1-001/002
both begin one sentence later), so the closest existing TABLE/MUST
entry whose own citation text overlaps this content was used.
REQ-PWR-014 -> UNLINKED -- error_category/message API convention, no
TC18 counterpart.

REQ-WDG-001 -> TC18-12.7.7-001 -- Table 24's rx_wd_timeout_intervall
("WatchDog time out ... 0dec: WD is disabled") and rx_enforce_watchdog
("0b: no watchdog ... 1b: stream is blocked upon WD overflow") fields
are exactly what StreamWatchdog::check reports.
REQ-WDG-002 -> TC18-12.7.7-001 -- the reset-per-request rule ("the
watchdog is reset with each request received from this RC Client",
L3301-3302) is prose immediately following Table 24 in the same
clause/section, not its own separate master-catalog entry; cited via
the section's sole TABLE/MUST id.
REQ-WDG-003 -> TC18-11.2.2-001 -- the general MSB-set (0x8x) safety-
request retention rule ("shall not be deleted when the EP needs to go
to safe state") is the exact generalization apply_watchdog_overflow's
purge-normal/retain-safety logic implements; it is more general than
TC18-11.2.2.2-006/11.2.2.3-007/11.2.2.5-005 (the compound/compound-wait/
triggered-specific instances of the same rule, each explicitly tied to
watchdog overflow) but those are per-request-type, while this
requirement and its RequestLedger are type-generic across exactly the
three MSB-set request kinds §11.2.2 defines is_safety over.
REQ-WDG-004 -> TC18-12.7.7-001 -- Table 24's rx_enforce_watchdog latch
behavior and rx_stream_status "1b: stream is blocked, requests are
rejected" bit (set automatically on overflow, not self-clearing) is the
textual basis for "does not re-fire until explicitly cleared".
REQ-WDG-005 -> UNLINKED -- the repeating "still in safe state" info
notification (rx_wd_info_enable) has no TC18.txt counterpart found;
grepped "notification"/"repeated"/"repetitive" across the whole
document, nothing else in §12.7.7 or elsewhere describes this signal.
REQ-WDG-006/007/008 -> UNLINKED -- Manager multiplexing, unregistered-
stream error codes, and callback-ordering are all pure implementation
API surface with no TC18 textual analog.

REQ-ENDPOINT-001 -> TC18-13.2-002 -- Table 32's ep_type enum: 0x02 GPIO,
0x03 SPI, exact match.
REQ-ENDPOINT-002 -> TC18-13.5-001 -- Table 33's full GPIO/PWM_OUT evt[2:0]
row set (000b write / 001b-011b OR-AND-XOR / 100b reserved / 101b-110b
add-subtract / 111b reconfigure) is exactly the 8-value mapping
write_semantics_of implements.
REQ-ENDPOINT-003 -> TC18-13.5-001 -- the OR/AND/XOR combinator rows
specifically (reused master id, same table, decomposed sub-behavior --
same pattern prior batches used for TC18-13.5-001, already reused 4x by
REQ-GPIO-/REQ-PWM-).
REQ-ENDPOINT-004 -> TC18-13.5-003 -- "neither overflows nor wrap-arounds
shall occur ... saturated at 0x0000 ... 0xFFFF", exact match, same
clause already used by REQ-GPIO-003.
REQ-ENDPOINT-005 -> TC18-13.5-001 -- the 100b-reserved/111b-reconfigure
rows specifically (third decomposed reuse of the same table).
REQ-ENDPOINT-006 -> TC18-11.2.2.5-002 -- "Each endpoint may generate one
or more trigger signals" is the generic, per-endpoint-type-agnostic
trigger-signal-generation clause TriggerRegistry's enable/notify/drain
API implements; distinguished from TC18-11.2.2.5-003 ("configured to
start a request upon receiving a trigger"), which is about consuming a
trigger to start a request elsewhere, not generating/gating one.

Deliberately-untouched entries and reasoning: see per-prefix notes above
(REQ-LIFECYCLE-007, REQ-PWR-002/006/008/009/014, REQ-WDG-005/006/007/008
-- 10 entries total). Each is either a pure implementation/API-surface
detail with no TC18 textual counterpart, or (REQ-PWR-006/009) a claim
TC18's text does not actually make, left unlinked rather than force-fit
per this effort's established discipline.

Verification pipeline (all against origin/main @ 416448e, PR #110's tip):

• cmake configure + build: clean, 0 errors (toolchain-only -Wnonnull
  warnings from libstdc++/Catch2 internals, pre-existing, unrelated).
• ctest --output-on-failure -j1: 53/53 passing (matches PR 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-* #110 baseline).
• cpfusa check (v0.18.0): 0 errors / 2 warnings / 1 info, identical
  before and after this change (confirmed via git stash A/B comparison).
• cpfusa trace --format json coverage: {tracedRequirements: 376,
  testedRequirements: 376, totalRequirements: 376, secTestedRequirements:
  64} both before and after -- byte-identical, confirming this change
  only adds tc18/tc18_master_id fields and touches no trace-relevant
  field.
• git diff --stat: .fusa-reqs.json | 98 ++++++++++++++++++++++++++++++
  ++++++++++++++++++---------------, 1 file changed, 73 insertions(+),
  25 deletions(-) -- only the 35 target-prefix entries touched.

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