From f1dbc505d181264e2ae31fca6608d424ac06d9c2 Mon Sep 17 00:00:00 2001 From: Matt <47545907+SoundMatt@users.noreply.github.com> Date: Fri, 7 Aug 2026 09:51:22 -0700 Subject: [PATCH] docs: stage 2 missing conditional-request field requirements Following the same investigation as cpp-RCP's equivalent pass: checked the Compound/CompoundWait/Triggered cluster's field-level completeness against TC18 sec 11.2.2 directly, given the pattern of gaps already found in the sibling repos' conditional-request layers. This module's design is notably more complete than cpp-RCP's: it already implements cmp_exec_delay/cmpw_exec_delay (resolve_compound_ exec_delay), trigger_exec_delay (resolve_trigger_exec_delay), and trigger_repetitions (TriggerRepeatCount/is_trigger_repeat_exhausted), all real, well-tested code -- not comment-only like cpp-RCP's equivalents. Two genuine field-level gaps remain, confirmed by grep across src/request.rs (the real TC18 field names appear nowhere outside docs): - Compound/CompoundWait: cmp_repetitions/cmpw_repetitions (repeat count) is absent -- only the exec_delay timer exists, no repeat concept at all for these two kinds specifically. - Triggered: trigger_source_ep/trigger_signal_nr/trigger_threshold are absent -- should_count_trigger_occurrence(endpoint_busy) always returns true regardless of which signal or endpoint fired, so there is no mechanism to specify or check which specific trigger a pending request is actually waiting for, nor an occurrence- threshold gate before first execution. Separately (not staged here, since a requirement already exists and is traced+tested -- this is a defect, not an absence): REQ-TIME-002/ 003's TimedExecutionTime composes AvtpTimestamp (32-bit, ~4.3s rollover) for a Timed request's presentation-time gate. The code's own doc comment is explicit that this was an unconfirmed judgment call, not a verified wire fact. TC18's real presentation_time (sec 11.2.2.5) is 48-bit, gPTP-domain, ~3.25-day rollover -- a materially different value. Flagged in memory for its own fix, not included in this staging file. Per this session's discussion: RELAY spec 20.1.2 hard-gates 100% requirement traceability in CI. Staged in a new .fusa-reqs-pending.json (same schema, confirmed not read by rsfusa), to be migrated into .fusa-reqs.json once each gets a real implementation and test. No code change. rsfusa check/trace unaffected (confirmed, 0 errors). Signed-off-by: Matt <47545907+SoundMatt@users.noreply.github.com> --- .fusa-reqs-pending.json | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) create mode 100644 .fusa-reqs-pending.json diff --git a/.fusa-reqs-pending.json b/.fusa-reqs-pending.json new file mode 100644 index 0000000..8ff1be7 --- /dev/null +++ b/.fusa-reqs-pending.json @@ -0,0 +1,28 @@ +{ + "_readme": "Staging area for TC18 MUST/SHOULD/MAY requirements confirmed missing from .fusa-reqs.json (no corresponding requirement AND no implementation found). NOT consumed by rsfusa -- entries here have no //fusa:req/test trace and would fail the repo's 100% traceability CI gate if merged into .fusa-reqs.json directly (RELAY spec section 20.1.2). Migrate an entry into .fusa-reqs.json only once real impl + test tags exist for it. Same schema as .fusa-reqs.json (id/title/text/standard/level/asil/verificationMethod/tc18) plus a 'gap' field describing what's missing. See RELAY's project_xrcp_relay_master_checklist memory record for the cross-repo tracking convention this file follows.", + "schemaVersion": "1.0", + "requirements": [ + { + "id": "REQ-CMP-010", + "title": "Compound/CompoundWait require cmp_repetitions/cmpw_repetitions, not just start-state gating and exec_delay", + "text": "A Compound or CompoundWait request's decoded parameters shall include cmp_repetitions/cmpw_repetitions (the number of times the request shall be repeated once its gate condition and exec_delay are satisfied, 0 meaning indefinitely until the sequencer leaves its start state), in addition to the already-implemented start/next-state gate (check_compound_gate) and cmp_exec_delay/cmpw_exec_delay (resolve_compound_exec_delay).", + "standard": "iso26262", + "level": "HLR", + "asil": "ASIL-B", + "verificationMethod": "test", + "tc18": "§11.2.2.1 Figure 8 / Table 6 (\"cmp_repetitions\"), TC18.txt L1223,L1266; §11.2.2.2 (cmpw_ equivalent)", + "gap": "Confirmed absent (2026-08-07): grepped src/request.rs for repetition/repeat_count/CompoundRepeat/cmp_repeat/cmpw_repeat -- zero hits outside Triggered's own TriggerRepeatCount (which is Triggered-specific, not shared). cmp_exec_delay/cmpw_exec_delay (TimerDelay/resolve_compound_exec_delay) are correctly implemented and well-tested; the analogous repeat-count concept for Compound/CompoundWait simply does not exist anywhere in this module." + }, + { + "id": "REQ-TRIG-010", + "title": "Triggered requires trigger_source_ep/trigger_signal_nr/trigger_threshold, not just repeat_count and exec_delay", + "text": "A Triggered request's decoded parameters shall include trigger_source_ep (the endpoint issuing the trigger), trigger_signal_nr (which of that endpoint's trigger signals this request watches), and trigger_threshold (how many occurrences of that specific signal must be observed before the request first executes) -- not merely count occurrences of trigger events generically via should_count_trigger_occurrence and gate repeat execution via TriggerRepeatCount/is_trigger_repeat_exhausted.", + "standard": "iso26262", + "level": "HLR", + "asil": "ASIL-B", + "verificationMethod": "test", + "tc18": "§11.2.2.3 Figure 10 (\"trigger_source_ep\", \"trigger_signal_nr\", \"trigger_threshold\"), TC18.txt L1420,L1454-1456", + "gap": "Confirmed absent (2026-08-07): grepped src/request.rs (case-insensitive) for threshold/signal_nr/source_ep/SignalNumber/SourceEndpoint -- zero real hits (one unrelated 'threshold' match, about the compound-bundle sequencer-count minimum, not trigger gating). should_count_trigger_occurrence(endpoint_busy) always returns true regardless of which signal or endpoint fired -- there is no mechanism today to specify or check which specific trigger source/signal a pending Triggered request is actually waiting for, nor an occurrence-threshold gate before its first execution. TriggerRepeatCount/is_trigger_repeat_exhausted correctly implement the separate, later post-first-execution repeat-count concept (trigger_repetitions) and are not affected by this gap." + } + ] +}