HARA risk.asil is never cross-checked against the S×E×C table in check's gate or hara --format json

[SoundMatt]

Spec reference

x-FuSa spec §1.2.5:

ASIL determination (MUST when standard: "iso26262"). A tool MUST derive risk.asil from severity × exposure × controllability per the standard table (ISO 26262-3:2018 Table 4) rather than accept an arbitrary value — this keeps the field auditable, not just plausible-looking.

What actually happens

cmd/cfusa/cmd_hara.c does implement the S×E×C → ASIL table (compute_asil()) and the text-format hara show prints a WARNING: stored ASIL … differs from computed … line when they disagree (confirmed by reading the source around line 652). But:

1. That check never becomes a Finding and never affects the command's exit code — hara show exits 0 either way.
2. hara --format json's completeness block has no field reflecting an ASIL mismatch at all, and its own exit code is unaffected.
3. check's own HARA rule engine (cmd_safety_rules.c, rules HARA002–HARA005) validates presence of S/E/C, presence of a safetyGoals reference, and that ASIL is a well-formed value (not TBD/empty/exceeding project ASIL) — but none of them recompute the table and compare it to the stored value.

Repro

I set hazards[0].risk.asil in this repo's own .fusa-hara.json to "ASIL-A" (the S3/E4/C2 combination in that same hazard actually derives to ASIL-D per Table 4 — confirmed by the tool's own text-mode warning below):

$ cfusa hara --dir .
H-001  [ASIL-A]
  Description: Tool reports no violations on a file that contains real safety violations (false-negative), leading the developer to believe code is safe when it is not
  S3/E4/C2
  WARNING: stored ASIL ASIL-A differs from computed ASIL-D

But:

$ cfusa hara --dir . --format json ; echo $?
0

— exit 0, and the emitted hazards[0].risk.asil is "ASIL-A" with nothing in the document indicating a mismatch.

$ cfusa check --dir . --format json ; echo $?
1

— exits 1, but the sole finding is an unrelated COMP001 complexity warning; grepping the full findings array for asil/ASIL turns up nothing about the hazard.

Why this matters

A hazard can carry a self-consistent-looking but wrong ASIL (a valid enum member, not an obviously-broken placeholder) and it passes every machine-readable gate this tool exposes. The only thing catching it is a human reading stdout text, which defeats the purpose of the MUST in §1.2.5 — "this keeps the field auditable, not just plausible-looking" is exactly the property that's missing from the JSON/gate path.

Suggested fix

Either (a) make hara's JSON completeness block include an asilMismatches (or similar) count derived the same way the text-mode warning already is, and/or (b) add a HARA00N rule to cmd_safety_rules.c that recomputes the S×E×C table for each hazard and emits an ERROR/WARNING Finding (so it gates check like any other finding) when the stored risk.asil disagrees with the derived value.

[SoundMatt]

Fixed in #81 (v0.5.47) — see the PR description for the full per-issue breakdown.

[SoundMatt]

Auto-closed by merging #81 (v0.5.47). Added a new check-gating engine rule (HARA006) that recomputes the ISO 26262-3 Table 4 S×E×C derivation for every hazard and emits an ERROR Finding on a mismatch, plus a completeness.asilMismatches count in hara --format json's output — both now use a shared cfusa_compute_asil() (src/asil.c) so the check-engine rule and hara show's existing text-mode warning can never drift apart. Regression tests: test_hara006_fires_on_asil_mismatch/test_hara006_passes_when_asil_matches in tests/test_safety_rules.c.