Location
src/frame.rs: the Frame struct doc comment (annotated with REQ-LIN-001/002/003), protect_id (annotated with REQ-LIN-004/005/018), and validate_frame (also annotated with REQ-LIN-001/002/003) — compared against requirements.json's actual text for those IDs.
(Note: issue #18 already tracks the separate, related problem of //fusa:req tags referencing requirement IDs — REQ-MASTER-006..013, REQ-VIRT-013..019 — that don't exist in requirements.json at all. This issue is about a different defect: tags that DO point at real requirement IDs, but the wrong ones.)
Problem
requirements.json defines REQ-LIN-001 as the PID parity-bit P0 computation rule and REQ-LIN-002 as the P1 rule — i.e., both are specifically about protect_id's parity math. But in the code, the protect_id function itself is tagged with REQ-LIN-004, REQ-LIN-005, and REQ-LIN-018 (the checksum carry-around rule and a bus-close-idempotency requirement — neither of which has anything to do with parity bits), while REQ-LIN-001/REQ-LIN-002/REQ-LIN-003 are instead attached to the Frame struct definition and to validate_frame.
This means a requirements-traceability tool reading these tags would report REQ-LIN-001/REQ-LIN-002 (the parity-bit rules) as satisfied by code and tests that have nothing to do with parity computation, while the function that actually implements parity (protect_id) is tagged with unrelated requirements. The trace matrix is a false positive for these IDs — it says "traced and tested" while pointing at the wrong code.
Suggested fix
Re-derive the //fusa:req tags in src/frame.rs (and audit the rest of the codebase for the same pattern) so each tag actually corresponds to the requirement text in requirements.json. Consider a CI check that samples requirement descriptions against the function they're attached to, or at minimum a documented convention/reviewer checklist so tag-drift like this doesn't recur.
Filed from the 2026-07-29 ecosystem audit register; independently re-verified against current HEAD before filing.
Location
src/frame.rs: theFramestruct doc comment (annotated withREQ-LIN-001/002/003),protect_id(annotated withREQ-LIN-004/005/018), andvalidate_frame(also annotated withREQ-LIN-001/002/003) — compared againstrequirements.json's actual text for those IDs.(Note: issue #18 already tracks the separate, related problem of
//fusa:reqtags referencing requirement IDs —REQ-MASTER-006..013,REQ-VIRT-013..019— that don't exist inrequirements.jsonat all. This issue is about a different defect: tags that DO point at real requirement IDs, but the wrong ones.)Problem
requirements.jsondefinesREQ-LIN-001as the PID parity-bit P0 computation rule andREQ-LIN-002as the P1 rule — i.e., both are specifically aboutprotect_id's parity math. But in the code, theprotect_idfunction itself is tagged withREQ-LIN-004,REQ-LIN-005, andREQ-LIN-018(the checksum carry-around rule and a bus-close-idempotency requirement — neither of which has anything to do with parity bits), whileREQ-LIN-001/REQ-LIN-002/REQ-LIN-003are instead attached to theFramestruct definition and tovalidate_frame.This means a requirements-traceability tool reading these tags would report
REQ-LIN-001/REQ-LIN-002(the parity-bit rules) as satisfied by code and tests that have nothing to do with parity computation, while the function that actually implements parity (protect_id) is tagged with unrelated requirements. The trace matrix is a false positive for these IDs — it says "traced and tested" while pointing at the wrong code.Suggested fix
Re-derive the
//fusa:reqtags insrc/frame.rs(and audit the rest of the codebase for the same pattern) so each tag actually corresponds to the requirement text inrequirements.json. Consider a CI check that samples requirement descriptions against the function they're attached to, or at minimum a documented convention/reviewer checklist so tag-drift like this doesn't recur.Filed from the 2026-07-29 ecosystem audit register; independently re-verified against current HEAD before filing.