hara --format json is not a verbatim passthrough of .fusa-hara.json — drops cross-references and attestation

[SoundMatt]

Spec reference

x-FuSa spec §9.2 hara:

--format json writes a document with the §3 envelope plus the .fusa-hara.json content verbatim (so hara's JSON output and the input file share one schema) plus a completeness block

and §1.2.5's schema shows hazards[].source (SHOULD), hazards[].situations (MUST), hazards[].safetyGoals (MUST), safetyGoals[].hazards (MUST), safetyGoals[].safeState (SHOULD), and a document-level attestation (§1.6.2, MAY, passthrough).

What actually happens

do_show_json() in cmd/cfusa/cmd_hara.c (~line 719) hand-writes each hazard/safety-goal object field-by-field instead of re-emitting the parsed document, and it omits every cross-reference field plus the attestation object entirely.

Repro against this repo's own .fusa-hara.json (which does carry source/situations/safetyGoals/safeState on every entry, verified by reading the input file directly):

$ cfusa hara --dir . --format json

produced (real output, hazards[0]):

{"id": "H-001", "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", "risk": {"severity": "S3", "exposure": "E4", "controllability": "C2", "asil": "ASIL-D"}}

— source, situations, and safetyGoals are silently dropped, even though the input file has:

{
  "id": "H-001",
  ...
  "source": "c-FuSa self-analysis",
  "situations": ["OS-001"],
  ...
  "safetyGoals": ["SG-001"]
}

Same drop for safetyGoals[].hazards/safeState. I also hand-added a valid attestation object to a copy of .fusa-hara.json and re-ran hara --format json: the output has no "attestation" key at all (confirmed via 'attestation' in json.load(...) → False), even though §9.2's own schema example shows it passed through.

Why this matters

A consumer reading only hara --format json output (the machine contract) cannot audit referential integrity (hazards[].safetyGoals / safetyGoals[].hazards) or the attestation status at all — despite completeness.danglingReferences/hazardsWithSafetyGoal being computed correctly internally, none of the underlying data needed to independently verify those counts is exposed. This also means test_hara_show_json_reports_fssr_gap in tests/test_xfusa_v114.c never actually asserts anything about the JSON body content (it only checks the return code), so the gap went untested.

Suggested fix

Serialize hazards[].source/situations/safetyGoals and safetyGoals[].hazards/safeState in do_show_json(), and pass through doc->attestation as a top-level "attestation" object when present (mirroring how fmea/tara/safety-case/sas already read-and-revalidate attestation via cfusa_qb_attestation_read/cfusa_qb_attestation_valid).

[SoundMatt]

Auto-closed by merging #81 (v0.5.47). hara --format json now passes through hazards[].source/situations/safetyGoals, safetyGoals[].hazards/safeState, and the document attestation verbatim from .fusa-hara.json, matching x-FuSa spec §9.2's schema. Regression test: test_hara_show_json_passes_through_cross_refs_and_attestation in tests/test_xfusa_v114.c.