Repository navigation
docs(fusa): [c-RCP-18-tracker Part 1] propagate tc18_master_id for REQ-E2E-*/REQ-REGMAP-*/REQ-SEQ-* - #112
Merged
Conversation
…Q-E2E-*/REQ-REGMAP-*/REQ-SEQ-* Links 35 of 41 REQ-E2E-*/REQ-REGMAP-*/REQ-SEQ-* entries in .fusa-reqs.json to the RELAY tc18-master-catalog.json (447 entries), adding "tc18" and "tc18_master_id" fields. cpp-RCP moves from 78/376 to 113/376 linked. Scope verification (all three packages carry an explicit TC18-scope doc comment citing "extraction" section numbers — none of the excluded "integration shell" naming patterns from #109/#110 apply here): - rcp/e2e.hpp (REQ-E2E-*): TC18's end-to-end CRC integrity mechanism (crc32/coverage_buffer/verify_crc) plus the per-request-stream watchdog/safe-state primitives, riding on rcp/acf.hpp, rcp/avtp.hpp, rcp/regmap.hpp and rcp/request.hpp. Confirms the task hypothesis (CRC/E2E protection, cross-cutting into §12.7.7 and §13.6). - rcp/regmap.hpp (REQ-REGMAP-*): the RC Server register-map data model and EP0 pseudo-endpoint (generic/functional config split, root-client arbitration, whole-map read/write). Confirms the §12.6/§12.7.x hypothesis, and additionally reaches into §12.3.1.x (lifecycle-gated locking) and §13.1/§13.2/§13.7.1.2 (EP0/ROOT_CLIENT semantics). - rcp/request.hpp (REQ-SEQ-*, module renamed from rcp/sequencer.hpp per RELAY spec §13.7.2): conditional-request taxonomy (compound, compound-wait, triggered, chained, timed) AND sequencer-state primitives, both living in one file/prefix. Confirms the §12.10 hypothesis but the taxonomy half draws far more heavily on §11.2.2/ §11.2.2.x/§11.2.3.x (conditional-request wire format, cancellation) and §12.9.2/§12.9.3 (priority/lifecycle) than on §12.10 itself, which in this file is used only for REQ-SEQ-004's default/advance rule. Per-prefix verdict: E2E 11/14 linked, REGMAP 13/15 linked, SEQ 11/12 linked — all three fully TC18-scoped (no entries excluded as non-TC18 "integration shell"); the 6 gaps are cases where cpp-RCP's own field/enum granularity goes beyond what TC18's text literally defines, not scope exclusions. == REQ-E2E-* (11/14 linked) == REQ-E2E-001 -> TC18-13.6-003 (CRC32P4 polynomial parameters, Table 34): crc32's poly/init/refin/refout/xorout constants are a verbatim match for Table 34's 0xF4ACFB13/0xFFFFFFFF/TRUE/TRUE/0xFFFFFFFF. REQ-E2E-002 -> TC18-13.6-005 (ACF_GBB under NTSCF header CRC field layout, Figure 21): coverage_buffer's ACF_GBB 16-byte Message-Info form (message_timestamp spliced between the two header quadlets) is exactly Figure 21's byte layout; Figure 20 (ACF_ABB, TC18-13.6-004) covers the other half of the same requirement's text but only one master_id fits the field, so the more heavily-described GBB case was chosen as primary. REQ-E2E-003 -> TC18-13.6-006 (acf_msg_length accounting for appended CRC): "adding the CRC to the byte_msg_payload increases the acf_msg_length by 1" is a direct match for apply_acf_length_adjustment's +1-quadlet rule; the companion +4-octet control_data_length adjustment is this implementation's own derived consequence for wrapping headers, not separately spelled out in TC18 text. REQ-E2E-004 -> TC18-13.6-001 (Safe command mode CRC mismatch handling): "the request is not executed, and an error response is generated with error code: CRC_ERROR" is a verbatim match for verify_crc's crc_error/CRC_ERROR contract. REQ-E2E-005 -> SKIPPED. crc_required checks three independently-toggled booleans keyed by MessageRole (Request/Ack/Response) living in EndpointGenericConfig; TC18's only literal CRC-enable bits are per-request-STREAM (rx_enforce_crc, §12.7.7 Table 24) and per-BBID (CRC_required, §12.7.8 Table 26) — neither is keyed by message role. implemented_options_bit's kOptSafetyRequests also has no literal TC18 bit position: svr_implemented_options (§12.7.5 Table 20) documents only bits a-e (compound&wait/trigger/chained/timed/enhanced-cancellation) of its 8-bit "abcdefgh" pattern; f/g/h are undocumented. Read both Table 20 and Table 26 directly before concluding neither's granularity matches — left unlinked rather than forcing a section-only match. REQ-E2E-006 -> TC18-12.7.7-001 (Request stream configuration register map, Table 24): rx_enforce_crc's documented 0/1 semantics ("stream is not blocked, when CRC check at EP fails" / "stream is blocked until released ... and Safe state will be entered") is exactly RxStreamGuard's drop-vs-latch rule gated on rx_enforce_e2e. REQ-E2E-007 -> TC18-12.7.7-001 (same Table 24): rx_enforce_sequence's 0/1 semantics ("not blocked upon out of order reception" / "blocked ... and Safe state will be entered") is exactly RxSequenceGuard's accept-vs-sequence_violation rule gated on rx_enforce_seq. REQ-E2E-008 -> TC18-12.7.7-001 (same Table 24, reusing REQ-WDG-001's already-merged citation for the identical field pair): rx_wd_timeout_intervall + rx_enforce_watchdog's documented semantics match RxWatchdog::overflowed's rx_wd_enable/rx_wd_timeout_interval gate. REQ-E2E-009 -> TC18-11.2.2-001 (Safety-request retention on MSB-set condition identifiers): "the request is treated as a safety request and will not be deleted when the EP needs to go to safe state" is the general principle apply_watchdog_overflow implements via RequestLedger::cancel_all(true) (purge is_safety=false, retain is_safety=true). The specific *mechanism* reused (cancel_all/non_safestate_only) is separately TC18-cited for REQ-SEQ-012; TC18's own text does not itself connect watchdog overflow to that named cancellation operation, so the general retention principle is the better-grounded citation here. REQ-E2E-010 -> TC18-11.2.2-001 (same clause): apply_queue_overflow implements "the same purge-normal/retain-safety rule via a distinct trigger" per its own title — same underlying TC18 principle, different RequestStreamConfig gate (rx_ovrflw_safestate_enable vs. rx_wd_safestate_enable). REQ-E2E-011 -> TC18-12.7.7-001 (Request stream configuration, Table 24 + prose). CITATION CORRECTION: the pre-existing tc18 field on this entry quoted TC18.txt L2935, but L2935 is mid-Table-20 (svr_implemented_options bit descriptions) and does not contain the quoted text at all — grep confirms "a safe state may be enforced. The safe state to enter can be chosen via the Safety_Measure parameter" appears exactly once in TC18.txt, at L3300 (§12.7.7's paragraph following Table 24). Fixed the line number to L3300 and added the missing tc18_master_id (rx_safestate_ seqencer/rx_safe_sequencer_state are Table 24 fields; the Safety_Measure parameter is this same paragraph, matching endpoint_in_configured_safe_ state's RxSafetyMeasure::ForceHighImpedance/RunSafeSequencer strategies). REQ-E2E-012 -> TC18-11.2.2-001 (same MSB-safety clause as 009/010): may_execute_now's execution-eligibility gate for is_safety=true records is this implementation's behavioral extension of the same "treated as a safety request" principle (TC18 states retention; this requirement adds the complementary "gated execution once eligible" behavior on the same underlying is_safety concept — no separate TC18 clause describes execution-gating specifically, so the root MSB-safety clause is cited). REQ-E2E-013 -> SKIPPED. RxWatchdog::should_emit_info_notification's rx_wd_info_enable field and "repeating info notification while latched" behavior have no TC18 textual basis found — grepped TC18.txt for "notification"/"repeating"/"periodic" near the watchdog sections; no match. This is cpp-RCP's own v2.6.0 field-set extension per regmap.hpp's own disclaimer ("Concrete field widths ... are this implementation's own encoding of that behavior"). REQ-E2E-014 -> SKIPPED, following the established cross-batch precedent (confirmed by grepping the file: every other "-Errc is a distinct category with non-empty ... messages" requirement in this repo — REQ-PWR-014, REQ-REGMAP-014, REQ-DISC-008, REQ-SPI-005, REQ-I2C-005, REQ-UART-007, REQ-ADC-006, REQ-PWM-007, REQ-SEQ-009, REQ-LINEP-004, REQ-CANEP-007, REQ-ISELED-005, REQ-MDIO-005, REQ-WAKEUP-005 — is unlinked). This is a generic C++ std::error_category implementation pattern, not itself a TC18 clause, even where the enum's individual values happen to reuse TC18 error-code names. == REQ-REGMAP-* (13/15 linked) == REQ-REGMAP-001 -> TC18-13.2-001 (ep_generic_config register map): the generic-vs-functional split is §13.2's own title framing ("Generic part of endpoint register map (owned by the RC Server)"), contrasted with "EP_functional configuration" used throughout §13.1/ §13.7. The specific field list in the requirement's text (HW pin indices, queue sizes) doesn't literally match Table 31's own field list (ep_type/ep_used/ep_delay_time/...) — this implementation chose its own contents for the generic block; the structural split itself is what's TC18-grounded. REQ-REGMAP-002 -> TC18-12.3.1.1-004 (EP0 full register-map access in HW_UNCONFIGURED): "Via EP0 the entire register map (i.e. all endpoints) can be accessed (read and write access)" matches read_whole_map's unrestricted-read contract. Note: TC18 states this specifically for HW_UNCONFIGURED state; cpp-RCP generalizes it to be state-independent. Read all three lifecycle-state subsections (§12.3.1.1-.3) directly to confirm nothing elsewhere restricts reads at other states (only writes are gated by W*/W markers) before treating this as a defensible generalization rather than a mismatch. REQ-REGMAP-003 -> TC18-13.7.1.2-002 (svr_root_client_index write-access scope): "Write requests to EP0 via all other streams are limited to EP0 and not beyond (i.e. other EPs)" is the direct textual basis for write_whole_map's unauthorized_access-unless-root-client rule. REQ-REGMAP-004 -> TC18-13.7.1.2-002 (same field): "The svr_root_client_ index is an index that selects the request stream which is in HW_CONFIGURED still allowed to access all registers" is the field claim_root_client operates on. Note: TC18 describes this as a plain register write, not a claim/reject/release transaction protocol — the request_rejected-on-distinct-claimant / no-op-on-self-reclaim / release-then-reclaim state machine is this implementation's own encoding of "how a write to this field gets validated," not literal TC18 text. REQ-REGMAP-005 -> TC18-13.1-004 (ROOT_CLIENT-exclusive write access to server config): matches verbatim — "For other RC Clients than the ROOT_CLIENT write access is only given to EP_functional configuration of endpoints which are allocated to the RC Client" is exactly check_write_access's FUNCTIONAL-block-only rule for non-root clients (the requirement's own text already cited TC18 §13.1/§13.2 by number; confirmed §13.1's own MUST clause is the better single anchor for the write-restriction assertion itself). REQ-REGMAP-006 -> TC18-12.3.1.2-001 (HW config locked in HW_CONFIGURED): "access to the HW configuration ... shall have been concluded and as such all access to the HW_config and EP_generic_config are locked" directly grounds generic_config_locked's LOCKED_MEM_ACCESS behavior. Note: TC18 does not describe a symmetric, independently-settable "functional_config_locked" flag with the same "locked" semantics — §12.3.1.3 (RCP_CONFIGURED) actually leaves functional config *writable* via specific stream/root-client paths rather than locking it the same way. The second half of this requirement (functional_config_locked) is this implementation's own extension into a second independently-lockable block; only the generic-config half has a clean 1:1 TC18 match. REQ-REGMAP-007 -> TC18-12.7.5-001 (RC Server register map, static/ general part, Table 20): direct match — magic/version/vendor_id/ device_id/ep_count and the *_ptr/*_capacity TablePointer fields for each sub-table are exactly Table 20's own field list. REQ-REGMAP-008 -> TC18-12.7.6-003 (HW_config pin-mapping table layout, Table 21): hw_pin_map's HwPinMapEntry(pin_id, function) is this implementation's simplified encoding of Table 21's per-pin hw_ep_nr/hw_ep_pin_nr/hw_pin_type triplet. REQ-REGMAP-009 -> TC18-12.7.7-001 (Request stream configuration, Table 24): direct match for the whole v2.6.0 watchdog/safe-state field set (rx_wd_timeout_interval~rx_wd_timeout_intervall, rx_enforce_e2e~rx_enforce_crc, rx_enforce_seq~rx_enforce_sequence, rx_safestate_sequencer~rx_safestate_seqencer, rx_safe_sequencer_state~rx_safe_sequencer_state verbatim). The rx_wd_safestate_enable/rx_wd_info_enable/rx_seq_safestate_enable/ rx_ovrflw_safestate_enable booleans are this implementation's own decomposition of Table 24's combined enforce-bit + "and Safe state will be entered" semantics into separate enable/safestate-enable pairs — same "own encoding" pattern flagged in e2e.hpp's header comment. REQ-REGMAP-010 -> TC18-12.7.8-006 (Ascending order of Request_Stream_ Index/BBID entries): "This has to be ensured by the instance that is sending the configuration to this table" is a verbatim match for ep_id_mapping's explicit non-re-sorting, non-re-deriving, insertion-order-preserving contract (the server deliberately does NOT enforce the ordering TC18 assigns to the client). REQ-REGMAP-011 -> TC18-12.7.9-007 (Responder QUEUE_config register map, Table 27): response_queue_size/ack_queue_size are this implementation's two named instances of Table 27's generic per-queue "queue_size" field, applied once each to the response queue and the acknowledge queue per §12.7.9's own prose ("For each response stream or acknowledge stream the RC Server needs to reserve a transmit queue ... size is given by ... queue_size"). REQ-REGMAP-012 -> TC18-12.7.10-004 (SEQUENCER_config register map, Table 28): "Seq_state (8bit, current state, default 1 ...)" is a direct match for sequencer_states' one-persistent-8-bit-value-per-slot storage model, predating (per the requirement's own "ahead of the sequencing behavior introduced in v2.5.0" text) the try_advance/kDefaultState *behavior* separately cited for REQ-SEQ-004. REQ-REGMAP-013 -> TC18-12.9.6-004 (Table 30: Error codes in responses): INVALID_PARAMETER(15) "Request parameter out of range" is the specific Table-30 row check_read_access/check_write_access/set_endpoint_owner's invalid_parameter return matches — distinguished from the generic "-Errc is a distinct category" pattern (REQ-REGMAP-014, skipped below) by describing one specific error code's semantic trigger condition rather than the enum-as-a-whole's category-implementation machinery. REQ-REGMAP-014 -> SKIPPED, same "-Errc is a distinct category" precedent as REQ-E2E-014 above (generic error_category C++ idiom, not a TC18 clause, even though its four values happen to be Table 30's own names). REQ-REGMAP-015 -> SKIPPED, same granularity gap as REQ-E2E-005: the three ep_*_crc_enable booleans are keyed per-endpoint-per-message-role, which has no literal TC18 counterpart (see REQ-E2E-005's reasoning above — checked both Table 24's stream-level rx_enforce_crc and Table 26's BBID-level CRC_required; neither is role-keyed). == REQ-SEQ-* (11/12 linked) == REQ-SEQ-001 -> TC18-11.2.2-002 (Conditional request type identifiers, Table 5): the mtv=0 message_timestamp-repurposing scheme and the first-byte-selects-opcode decode this requirement describes is exactly Table 5's "first byte in message_timestamp field" -> "type of condition" mapping, introduced by §11.2.2's own "conditional requests are sent using ACF_GBB having mtv = 0 ... using the bytes of the message_timestamp field to convey the execution condition" paragraph. REQ-SEQ-002 -> TC18-12.9.2-003 (Execution priority order across request types): "In case two or more requests are due for execution then the priorities are as follows: 1. cancellation 2. triggered 3. timed 4. compound 5. compound wait 6. chained 7. standard" is a verbatim 7-level match for category_of's RequestCategory enum values and select_next_due's priority_rank ordering (the same paragraph's next sentence, "starting the execution shall happen in the order ... the requests arrived," independently covers the FIFO tie-break half of this requirement, catalogued separately as TC18-12.9.2-004 but not chosen as primary since the priority list itself is this requirement's dominant assertion). REQ-SEQ-003 -> TC18-12.2-004 (Optional compound requests bundle): verbatim match — "Support of compound requests (0x0F/0x8F) ... Implementation of at least four sequencers (see 12.10) ... Clear all non-safestate requests from an EP request storage" is exactly validate_feature_bundles' compound+compound_wait+clear_non_safestate+ sequencer_count>=kMinCompoundSequencers(4) all-four-required rule. REQ-SEQ-004 -> TC18-12.9.3-002 (Table 29: Execution procedure, compound row): "the state of sequencer cmp_sequencer is set to cmp_next_state if the sequencer state still equals the cmp_start_state, else the sequencer state is not changed" is a verbatim match for try_advance's increment-only-if-current-equals-expected_start / leave-unchanged- otherwise contract. The default-value half (kDefaultState=1) is separately grounded in TC18-12.7.10-002/-004's "default 1" register description (already used for REQ-REGMAP-012); this requirement's more novel/behaviorally-distinctive assertion is the conditional-advance rule, so Table 29 was chosen as the single master_id. REQ-SEQ-005 -> TC18-11.2.3-002 (Chained successor cancellation propagation): "If a request is cancelled to which a request is chained, then the chained successors shall be cancelled by the RC Server as well" is a verbatim match for cancel_single's cascade-to-every- transitive-chained-successor behavior — chosen as the single most distinctive assertion in this requirement's bundled text; the Pending/Started-only cancellable window (TC18-11.2.3-001) and the REQUEST_CANCELED outcome (TC18-11.2.3-003) are the same §11.2.3 paragraph's other two sentences, covering the requirement's remaining clauses but not separately assigned a master_id. REQ-SEQ-006 -> TC18-12.9.3-001 (Request lifecycle states pending/RS/ RE/RF): "it is in the state 'request pending' ... enters the state 'request started' (RS) ... advances to 'request under execution' (RE) ... and then to 'request finalized' (RF)" is a verbatim 4-state match for RequestLedger's Pending->Started->UnderExecution->Finalized single-step-forward-only state machine. REQ-SEQ-007 -> TC18-11.2.2.6-011 (Conditional-start (cs) bit semantics for chained requests): "cs ... 1b: request will not be executed in case the previous request returned an error ... error response with error code = CHAIN_ABORTED" is the direct textual basis for should_execute_chained(successor.cs, errored)'s cascade-cancel-on-error rule driving RequestLedger::finalize's chained-successor propagation. REQ-SEQ-008 -> TC18-11.2.2.3-008 (cs-bit execution-due semantics for compound wait): "If cs = 0, then compound wait request is due for execution, when the sequencer is in the cmpw_start_state. If cs = 1, ... when EP output state has changed after the sequencer reached the cmpw_start_state" is the direct textual basis for compound_wait_check_of's cs->CompoundWaitCheck mapping. ** CONFORMANCE FINDING (not fixed in this docs-only PR, flagging for a follow-up issue): TC18 states cs=0 -> "due immediately" and cs=1 -> "due only after an EP output state change." cpp-RCP's actual mapping (include/rcp/request.hpp:371-372, exercised by tests/test_request.cpp:520-522) is inverted: cs=true (1) -> CompoundWaitCheck::Immediate, cs=false (0) -> AfterChangeOnly — the opposite polarity from the spec text quoted above. This master_id is still the correct citation for *which clause this requirement's subject is drawn from*; the polarity defect is an implementation bug independent of the citation and out of scope for this PR (same practice as PR #162/#163's conformance-defect flags, which likewise documented rather than silently fixed the finding). REQ-SEQ-009 -> SKIPPED, same "-Errc is a distinct category" precedent as REQ-E2E-014/REQ-REGMAP-014 above. REQ-SEQ-010 -> TC18-11.2.2-002 (Table 5, same clause as REQ-SEQ-001): "0x0F, 0x8F Compound ... 0x0B, 0x8B Compound wait ... 0x0E, 0x8E Triggered" is Table 5's own enumeration of exactly the three MSB-set identifier pairs is_valid_request_type/decode_request_type must accept as CompoundSafety/CompoundWaitSafety/TriggeredSafety. REQ-SEQ-011 -> TC18-11.2.2-001 (Safety-request retention on MSB-set condition identifiers, same clause used for REQ-E2E-009/010/012): "the MSB of the identifier (0x8x) is set the request is treated as a safety request" is the direct textual basis for is_safety_variant returning true for exactly the three 0x8x-prefixed opcodes. REQ-SEQ-012 -> TC18-11.2.3.2-001 (Clear-all-non-safestate-requests optional cancellation feature): "Clear all non-safestate requests from an EP request storage ... request_type ... is 0x06" is the named cancellation operation request_record_for's is_safety derivation feeds into cancel_all(non_safestate_only=true) — the more precise mechanistic match versus the general MSB-safety-retention clause used elsewhere, since this requirement's assertion is specifically about exclusion from *this* named operation. == Deliberately untouched (6 of 41) == REQ-E2E-005, REQ-REGMAP-015: per-endpoint-per-message-role CRC-enable granularity has no literal TC18 field; see REQ-E2E-005 reasoning above. REQ-E2E-013: rx_wd_info_enable / repeating info notification has no TC18 textual basis found (grepped for notification/repeating/periodic). REQ-E2E-014, REQ-REGMAP-014, REQ-SEQ-009: generic "-Errc is a distinct category" C++ idiom, consistent with the precedent set across all 14 other such requirements already present in this file (all unlinked). == Verification == - CMake configure (cmake -B build -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_STANDARD=17 -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DRELAY_BUILD_CLI=ON -G Ninja) + build: clean, 0 errors (219/219 targets), only pre-existing benign -Wnonnull warnings from a system <bits/stl_algobase.h> header, unrelated to this change. - ctest --test-dir build --output-on-failure -j1: 53/53 passing (matches PR #111 baseline). - cpfusa v0.18.0 check: 0 errors / 2 warnings / 1 info, byte-identical before and after this change (FUSA004, FUSA005, HARA005 — all pre-existing and unrelated). - cpfusa v0.18.0 trace --format json coverage: totalRequirements=376, tracedRequirements=376, testedRequirements=376, secTestedRequirements=64 before AND after (confirmed identical via git-stash A/B comparison) — this change only adds tc18/tc18_master_id metadata fields, it does not touch any fusa:req annotation, test, or requirement count. - git diff --stat: only .fusa-reqs.json changed, 81 insertions(+), 12 deletions(-) (the 12 deletions are the "severity"/closing-brace lines displaced by each of the 34 new two-line tc18/tc18_master_id insertions plus REQ-E2E-011's 1-line citation correction). Freshness: confirmed via fresh `git clone` at session start (tip 87ba239, matching PR #111 as claimed) and via `git fetch origin` + `git log --oneline -1 origin/main` immediately before this push — no new commits landed on main while this batch was in progress. Signed-off-by: Matt Jones <47545907+SoundMatt@users.noreply.github.com> Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Part 1 of the "wiggly-shimmying-wombat" TC18 catalog propagation for cpp-RCP, covering REQ-E2E-* (14), REQ-REGMAP-* (15), REQ-SEQ-* (12) — 41 entries total, all previously unlinked. Links 35/41 to
docs/tc18-master-catalog.json(RELAY, 447 entries) via newtc18/tc18_master_idfields; 6 are deliberately left unlinked (see commit body). cpp-RCP moves from 78/376 to 113/376 linked.Prior merged batches: #108 (REQ-WIRE-*), #109 (REQ-CANEP-*/I2C-*/ISELED-*/LINEP-*/MDIO-*/ADC-*), #110 (REQ-CAN-*/GPIO-*/PWM-*/SPI-*/UART-*/WAKEUP-*), #111 (REQ-LIFECYCLE-*/PWR-*/WDG-*/ENDPOINT-*).
What each package turned out to be
All three carry an explicit TC18-scope doc comment; none is excluded as non-TC18 "integration shell."
Per-prefix verdict
-ErrcC++ idiom, not a TC18 clause (established precedent).-Errcprecedent. 015: same per-role-CRC granularity gap as E2E-005.-Errcprecedent.Citation correction found
REQ-E2E-011 had a pre-existing
tc18field citingTC18.txt L2935— that line is mid-Table-20 and does not contain the quoted text. The quote ("a safe state may be enforced...") appears exactly once in TC18.txt, at L3300. Fixed the line number and added the missingtc18_master_id(TC18-12.7.7-001).Conformance finding (not fixed here — docs-only PR)
REQ-SEQ-008 /
compound_wait_check_of: TC18 §11.2.2.3 states cs=0 → due immediately, cs=1 → due after an EP output state change. cpp-RCP's implementation (include/rcp/request.hpp:371-372) has this inverted:cs=true → Immediate,cs=false → AfterChangeOnly. Flagged in the commit body for a follow-up issue, consistent with how PR #162/#163 handled prior conformance defects found during citation work — the master_id linked is still the correct citation for the clause this requirement's subject is drawn from.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, 0 errors (219/219 targets).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-LIFECYCLE-*/REQ-PWR-*/REQ-WDG-*/REQ-ENDPOINT-* #111 baseline).cpfusa check(v0.18.0) — 0 errors / 2 warnings / 1 info, byte-identical before/after (verified via git-stash A/B).cpfusa trace --format json— coverage 376/376/376/64 (total/traced/tested/secTested), identical before/after.git diff --stat— only.fusa-reqs.jsonchanged: 81 insertions(+), 12 deletions(-).Freshness
git cloneconfirmed tip87ba239(matches PR docs(fusa): [c-RCP-18-tracker Part 1] propagate tc18_master_id for REQ-LIFECYCLE-*/REQ-PWR-*/REQ-WDG-*/REQ-ENDPOINT-* #111 as claimed).git fetch origin+git log --oneline -1 origin/main— still87ba239, no drift; branched cleanly from the true tip.Full id → master-catalog-id mapping table and per-entry justification (grounded in each cited clause's actual content, not just its section number) is in the commit body.
Not merging this myself — leaving open for independent review per process.