cpfusa HLR/LLR two-tier traceability gate: no requirement has ever had a parent_id populated

[SoundMatt]

Background

Discovered while fixing the cpp-RCP v3.0.0 deep-audit's .fusa.json ASIL contradiction finding (PR #178): .fusa.json's project.asil was incorrectly declared ASIL-B when .fusa-hara.json's own hazard analysis (H-001 → SG-001/SG-003/SG-007) genuinely requires ASIL-C. Correcting the declaration to ASIL-C (the honest, HARA-derived value) causes the pinned cpfusa binary's trace command to newly hard-fail — not because of anything wrong with the correction itself, but because of a separate, pre-existing gap this correction exposes.

The gap

cpfusa trace's exit code has exactly one hard-failure path: result.hlr_gate_failed, driven by an HLR/LLR two-tier requirement-decomposition check (src/trace/trace.cpp, ~line 421-471). Every requirement in .fusa-reqs.json without a parent_id is treated as a top-level "HLR" that must have at least one "LLR" child (another requirement whose parent_id points back at it) — and this rule is promoted from warn-only to a hard gate whenever the declared project ASIL is C or D (REQ-HLR004/REQ-HLR005 in cpfusa's own internal req numbering).

cpp-RCP's .fusa-reqs.json has never populated parent_id on any of its 1141 requirement entries. Every single one is therefore an "HLR" with zero LLR children, and cpfusa trace prints WARN: HLR <id> has no LLR children for essentially the entire catalog. Under the previous (incorrect) ASIL-B declaration this was warn-only and non-blocking; under the correct ASIL-C declaration it's a hard CI failure.

This is documented as a known, pre-existing gap in this repo's own ARCHITECTURE.md:

.fusa-reqs.json schema (tc18/tc18_master_id/status) | partial — no citation or status fields exist yet; the tool (cpfusa) also expects an HLR/LLR two-tier hierarchy this repo's schema doesn't populate (WARN: HLR ... has no LLR children on every entry today) — needs its own investigation before schema unification lands here

i.e. this predates the deep audit and predates PR #178 entirely — the ASIL-C correction didn't create the gap, it just changed the gap from a warning to a hard gate, which is arguably more correct behavior for ISO 26262 given the project's real safety-integrity level.

What's needed

A real, dedicated pass to retrofit the HLR/LLR two-tier decomposition across the full requirement catalog:

• Decide what actually constitutes an "HLR" vs "LLR" in this project's own requirement shape (likely: per-module top-level safety goals / TC18 clause-level requirements as HLRs, with per-function/per-branch requirement entries as their LLR children — needs real design work, not a mechanical script).
• Populate parent_id across (currently) 1141 entries accordingly.
• Re-verify cpfusa trace's HLR-coverage output reaches 0 violations at the project's real ASIL-C target.

This is out of scope for a documentation/ASIL-correction fix (PR #178) — tracked here as its own effort.

How PR #178 was handled

Per explicit user decision: PR #178 was merged via --admin with the cpfusa trace (100% coverage) check red (this exact gate) and every other check green, since:

1. The ASIL-C correction itself is factually correct (independently verified against .fusa-hara.json).
2. The four dangling //fusa:test references that were also newly gated by the ASIL bump were genuinely fixed in the same PR (see PR fix(safety-docs): correct ASIL declaration + RxSequenceGuard/Zone-model staleness #178's second commit).
3. The one remaining red check is this pre-existing, already-documented structural gap, not a regression introduced by PR fix(safety-docs): correct ASIL declaration + RxSequenceGuard/Zone-model staleness #178.