Summary
cfusa check on main now fails with 20 errors (10× HARA002, 10× HARA003) because .fusa-hara.json does not conform to the HARA schema c-FuSa v0.5.46 started enforcing as part of x-FuSa spec v1.13.0/v1.14.0 conformance (SoundMatt/c-FuSa#72, merged 2026-07-28T19:55:27Z):
- HARA002: each hazard needs a nested
risk.severity/risk.exposure/risk.controllability object (ISO 26262-3 Clause 6.4). This repo's .fusa-hara.json currently has severity/exposure/controllability as flat top-level fields on each hazard instead.
- HARA003: each hazard needs a
safetyGoals reference array (ISO 26262-3 §6.4.9). This repo's .fusa-hara.json currently has a single free-text safety_goal string field instead.
How this was found
While verifying PR #88 (module-naming reconciliation, issue #87), its cfusa check job failed with these 20 errors. .fusa-hara.json is untouched by that PR (git diff main pr88 -- .fusa-hara.json is empty), so I checked whether this reproduces on main independently: building c-FuSa fresh from its current HEAD and running cfusa check . against main (unmodified) reproduces the identical 20 errors. The most recent main CI run (2026-07-28T19:28:07Z, before c-FuSa#72 merged) still shows cfusa check passing with 0 errors, confirming the regression is entirely from the upstream c-FuSa schema change, not from any c-RCP change.
Because this repo's CI workflow builds c-FuSa from HEAD on every run (git clone --depth=1 https://github.com/SoundMatt/c-FuSa in .github/workflows/ci.yml, no pinned ref/tag), main's next CI run will fail cfusa check too, and every open/future PR will inherit the same failure until .fusa-hara.json is migrated to the new schema.
Suggested fix
- Migrate
.fusa-hara.json's 10 hazards (H-001..H-010) to the new schema: nest severity/exposure/controllability under a risk object, and add a safetyGoals array (referencing safety-goal ids, e.g. ["SG-001"]) alongside or replacing the current free-text safety_goal string. This needs a safety-domain judgment call on how safety_goal free text maps to formal safetyGoals ids, not a mechanical rename.
- Separately, consider pinning c-FuSa to a released tag/SHA in
.github/workflows/ci.yml's cfusa-build job instead of cloning HEAD, so upstream c-FuSa changes land here as a deliberate version bump rather than silently breaking CI on unrelated PRs.
Flagging as its own issue since it's orthogonal to #87/PR #88's module-naming scope and blocks a clean CI signal repo-wide, not just on that PR.
Summary
cfusa checkonmainnow fails with 20 errors (10× HARA002, 10× HARA003) because.fusa-hara.jsondoes not conform to the HARA schema c-FuSa v0.5.46 started enforcing as part of x-FuSa spec v1.13.0/v1.14.0 conformance (SoundMatt/c-FuSa#72, merged 2026-07-28T19:55:27Z):risk.severity/risk.exposure/risk.controllabilityobject (ISO 26262-3 Clause 6.4). This repo's.fusa-hara.jsoncurrently hasseverity/exposure/controllabilityas flat top-level fields on each hazard instead.safetyGoalsreference array (ISO 26262-3 §6.4.9). This repo's.fusa-hara.jsoncurrently has a single free-textsafety_goalstring field instead.How this was found
While verifying PR #88 (module-naming reconciliation, issue #87), its
cfusa checkjob failed with these 20 errors..fusa-hara.jsonis untouched by that PR (git diff main pr88 -- .fusa-hara.jsonis empty), so I checked whether this reproduces onmainindependently: building c-FuSa fresh from its current HEAD and runningcfusa check .againstmain(unmodified) reproduces the identical 20 errors. The most recentmainCI run (2026-07-28T19:28:07Z, before c-FuSa#72 merged) still showscfusa checkpassing with 0 errors, confirming the regression is entirely from the upstream c-FuSa schema change, not from any c-RCP change.Because this repo's CI workflow builds c-FuSa from HEAD on every run (
git clone --depth=1 https://github.com/SoundMatt/c-FuSain.github/workflows/ci.yml, no pinned ref/tag),main's next CI run will failcfusa checktoo, and every open/future PR will inherit the same failure until.fusa-hara.jsonis migrated to the new schema.Suggested fix
.fusa-hara.json's 10 hazards (H-001..H-010) to the new schema: nestseverity/exposure/controllabilityunder ariskobject, and add asafetyGoalsarray (referencing safety-goal ids, e.g.["SG-001"]) alongside or replacing the current free-textsafety_goalstring. This needs a safety-domain judgment call on howsafety_goalfree text maps to formalsafetyGoalsids, not a mechanical rename..github/workflows/ci.yml'scfusa-buildjob instead of cloning HEAD, so upstream c-FuSa changes land here as a deliberate version bump rather than silently breaking CI on unrelated PRs.Flagging as its own issue since it's orthogonal to #87/PR #88's module-naming scope and blocks a clean CI signal repo-wide, not just on that PR.