Summary
`cmd_safety_case.c:91` hardcodes the HARA evidence filename as lowercase `hara.md`, and the markdown evidence-index list at `cmd_safety_case.c:327-329` hardcodes `hara.md`/`safety-plan.md`. `cfusa_file_exists()` (`src/utils.c:113-117`) is a plain `stat()` call -- case-sensitive on the Linux runners CI/release actually use.
Downstream consumer `SoundMatt/c-RCP` names its files `HARA.md`/`SAFETY_PLAN.md` (a defensible, common convention for top-level docs). On a case-sensitive filesystem this causes `cfusa safety-case` to silently mark the HARA-linked GSN goal ("every hazard recorded in .fusa-hara.json is eliminated or controlled to its assigned ASIL, ISO 26262-3 Clause 6") as undeveloped -- even though a real, current, thorough HARA.md and .fusa-hara.json exist.
Repro / evidence
- Cloned c-FuSa @ v0.5.50 (12a30f4), built from source, ran `cfusa safety-case` against a c-RCP checkout on a case-insensitive filesystem (macOS): produces `"undeveloped": 0` -- a false negative that masks the bug locally.
- c-RCP's actual committed `safety-case.md` (generated by the real Linux release job) shows the HARA solution node (`Sn1`) missing entirely, and completeness reads `"1 with cited evidence, 1 undeveloped"`.
Impact
Any downstream project using non-lowercase filenames for HARA/safety-plan evidence gets a silently incomplete safety case on Linux CI/release, with no warning -- the tool believes the evidence category exists and is complete when it can't actually locate the file. This is likely to affect other consumers beyond c-RCP.
Suggested fix
Either do a case-insensitive filename match, or (better) make the expected evidence filenames configurable via `.fusa.json` rather than hardcoded literals in `cmd_safety_case.c`, since project file-naming conventions vary. At minimum, log a warning when a category evaluates to "undeveloped" purely because no candidate filename (of several reasonable casings) was found, versus a genuine absence of any HARA/safety-plan content.
Found via an independent audit of c-RCP's safety-tooling artifacts this session -- happy to provide more detail if useful.
Summary
`cmd_safety_case.c:91` hardcodes the HARA evidence filename as lowercase `hara.md`, and the markdown evidence-index list at `cmd_safety_case.c:327-329` hardcodes `hara.md`/`safety-plan.md`. `cfusa_file_exists()` (`src/utils.c:113-117`) is a plain `stat()` call -- case-sensitive on the Linux runners CI/release actually use.
Downstream consumer `SoundMatt/c-RCP` names its files `HARA.md`/`SAFETY_PLAN.md` (a defensible, common convention for top-level docs). On a case-sensitive filesystem this causes `cfusa safety-case` to silently mark the HARA-linked GSN goal ("every hazard recorded in .fusa-hara.json is eliminated or controlled to its assigned ASIL, ISO 26262-3 Clause 6") as undeveloped -- even though a real, current, thorough HARA.md and .fusa-hara.json exist.
Repro / evidence
Impact
Any downstream project using non-lowercase filenames for HARA/safety-plan evidence gets a silently incomplete safety case on Linux CI/release, with no warning -- the tool believes the evidence category exists and is complete when it can't actually locate the file. This is likely to affect other consumers beyond c-RCP.
Suggested fix
Either do a case-insensitive filename match, or (better) make the expected evidence filenames configurable via `.fusa.json` rather than hardcoded literals in `cmd_safety_case.c`, since project file-naming conventions vary. At minimum, log a warning when a category evaluates to "undeveloped" purely because no candidate filename (of several reasonable casings) was found, versus a genuine absence of any HARA/safety-plan content.
Found via an independent audit of c-RCP's safety-tooling artifacts this session -- happy to provide more detail if useful.