Adopt x-FuSa spec v1.13.0/v1.14.0: HARA/FMEA/TARA/safety-case/SAS/SCI schemas + content-quality baseline (attestation, FUSA-STUB detection, coverage metrics)

[SoundMatt]

Context

docs/x-fusa-spec.md (SoundMatt/FuSaOps) went from v1.11.0 → v1.14.0 this week, formalizing real field-level schemas for six evidence artifacts that were previously "tool-defined" (each tool free to pick its own shape):

• §1.2.5 .fusa-hara.json (MUST read/validate) — ISO 26262-3 Clause 6. operationalSituations[]/hazards[]/safetyGoals[] as three cross-referenced collections; safetyGoals[].fssrRefs is now MUST, ≥1 entry (a safety goal must decompose into a real functional safety requirement in .fusa-reqs.json).
• §9.2 hara/fmea/tara/safety-case — real JSON schemas: fmea per IEC 60812 / the AIAG-VDA FMEA Handbook (entries[], ratingScale, actionPriority); tara per ISO/SAE 21434 Clause 15 (threats[], and impact is now an SFOP object — safety/financial/operational/privacy — not one generic severity); safety-case per the GSN Community Standard v3 (nodes/edges/completeness, all six real GSN node types: goal/strategy/solution/context/assumption/justification).
• §9.3 sas/sci — sas: checklist[]/summary per DO-178C §11.20. sci: artifacts[] (file/hash/version) per DO-178C §11.16.
• §1.6 "Evidence artifact content-quality baseline" + §1.6.1 "Detection heuristics" + §1.6.2 "Attestation" — a cross-cutting anti-stub-content baseline, found necessary after a same-day content audit turned up templated FMEA rows, an untouched HARA template, and an artifact with invalid JSON across the tool family. Two concrete, checkable rules:
  • Rule A / FUSA-STUB001 (always ERROR, disposition-suppressible only): a deny-list scan for literal placeholder/template text ("[describe asset]", "replace with", "TBD", etc.) in any qualitative field.
  • Rule B / FUSA-STUB002 (WARNING by default, not gating): a distinct-value-ratio check (<0.1 across ≥10 entries) that flags a single hardcoded qualitative string (e.g. failureMode/effect) applied to every entry regardless of the underlying item. Deliberately advisory — a similarity heuristic can be wrong.
  • Attestation (§1.6.2): a DCO-style mechanism that resolves Rule B's false-positive risk — an artifact can carry an optional attestation object (status, implementationAuthor, independentReviewer, reviewedAt, contentHash) modeled on independent-review concepts already common in these tools (e.g. FuSaOps' own vv package). A non-stale (hash-pinned), genuinely-independent "reviewed" attestation suppresses Rule B. --strict/--require-attestation escalates an unsuppressed Rule B finding to exit 1; without the flag it's advisory only.
• fmea/tara coverage metrics: new summary.coveragePct (+ --min-coverage N, mirroring trace --func-coverage) against a stated denominator (componentsInProject/assetsInProject + a *InventoryMethod string documenting how it was counted) — so an FMEA/TARA can't quietly analyze 5 convenient cases while looking complete by entry count alone.

FuSaOps just did this work against its own hara/fmea/tara/safetycase/sas/sci packages (dogfooding its own spec) — see SoundMatt/FuSaOps PR #84 (schema conformance) for the reference shape of each artifact, and the upcoming PR2 for attestation/detection/coverage. Full spec text: docs/x-fusa-spec.md §1.2.5, §1.6, §1.6.1, §1.6.2, §9.2, §9.3 in that repo.

Scope for this tool

• Bring hara/fmea/tara/safety-case/sas/sci JSON output into conformance with the schemas above (field names, GSN node types, SFOP impact, checklist/artifacts shape).
• Fix any hash-named field that isn't sha256:-prefixed (a real bug FuSaOps found in its own code across every one of these commands — check yours too).
• Implement FUSA-STUB001/FUSA-STUB002 detection (or your tool's own rule IDs following the same two-rule shape) wired into check or the relevant artifact command, plus attestation support and --require-attestation/--strict gating.
• Add summary.coveragePct + --min-coverage N to fmea/tara.

If the spec is ambiguous or doesn't fit your language/tool

File an issue on SoundMatt/FuSaOps describing the ambiguity — do not guess and silently diverge. This is exactly how the six-tool family stays interoperable; a per-tool guess that turns out wrong is more expensive to unwind later than a clarifying issue now. Reference this issue and the specific spec section you're unsure about.

Out of scope

• check --import (§4.3), coverage --proof (§9.2 draft), trace --model-trace (§1.2.4/§5) — separate spec-v1.12.0 RFC, tracked in its own issue(s) where applicable.

[SoundMatt]

Shipped in PR #72, released as v0.5.46 (auto-closed by the merge commit's "Closes #71").

• .fusa-hara.json: three cross-referenced collections (operationalSituations[]/hazards[]/safetyGoals[]), safetyGoals[].fssrRefs now MUST/≥1 entry, cross-checked against .fusa-reqs.json. hara init scaffolds empty collections; hara show/--format json add a completeness block.
• fmea.json: ratingScale, per-function-templated failureMode/effect/cause, actionPriority, summary.componentsInProject/coveragePct.
• tara.json: SFOP impact object (safety/financial/operational/privacy) instead of one generic severity; assets/threats discovered by scanning for network/file/auth/memory-input functions instead of a placeholder template; summary.assetInventoryMethod.
• safety-case --format json is new: nodes[]/edges[]/completeness using the six real GSN node types; solution nodes only cite evidence that actually exists.
• sas --format json: checklist[]/summary, present reflects a real evidence-file check; always also writes the sas.md companion.
• sci --format json: files→artifacts, sha256→hash (sha256:-prefixed per §2.7).
• New qualitybar module: FUSA-STUB001 (always ERROR, disposition-suppressible only) / FUSA-STUB002 (WARNING by default, attestation-suppressible), wired into hara/fmea/tara/safety-case/sas via --strict/--require-attestation/--attest <reviewer>.
• --min-coverage N on fmea/tara, mirroring trace --func-coverage; denominator excludes test files.
• Regenerated this repo's own .fusa-hara.json (migrated off .cfusa-hara.json, corrected ASIL values), fmea.json/fmea.csv, tara.json/tara.md, and added safety-case.json — dogfooding the new schemas.

Along the way: fixed a real invalid-JSON/CSV bug in fmea (unescaped function-name false positive), updated the HARA002/003/004 check engine rules for the new schema, fixed two self-inflicted CFUSA-CY002 false positives, and fixed a Linux-only segfault (fdopen() needs _POSIX_C_SOURCE under strict -std=c99 glibc headers — same class of issue as the existing _POSIX_C_SOURCE guards elsewhere in this codebase).

No spec ambiguities came up that warranted a FuSaOps issue — the spec sections were concrete enough to implement directly.