Spec reference
x-FuSa spec §9.2:
fmea (SHOULD). fmea [--dir <path>] [--format text|json|csv|html] [--output <file>] [--min-coverage N]
(and §2.2's shared-flags table only lists --output-dir as applying to release, not fmea.)
What actually happens
cmd/cfusa/cmd_fmea.c never defines a --output long option — only --output-dir <dir>:
$ cfusa fmea --help
Usage: cfusa fmea [--dir <path>] [--output-dir <dir>]
[--format md|json|csv] [--cyber]
...
Because --output-dir is the only long option beginning with --output, GNU getopt_long's unambiguous-prefix matching silently accepts --output <path> as an abbreviation of --output-dir <path> instead of rejecting it — so invoking fmea exactly as the spec's own synopsis documents doesn't error out cleanly, it silently does the wrong thing:
$ cfusa fmea --dir . --format json --output /tmp/out/fmea_direct.json
/tmp/out/fmea_direct.json/fmea.json: No such file or directory
$ echo $?
3
(It treated the given file path as a directory and tried to write <path>/fmea.json underneath it.)
For comparison, cfusa tara implements both --output <file> (writes exactly that path in any format, confirmed working) and --output-dir <dir>, and cfusa hara/cfusa sas/cfusa sci all implement --output <file> correctly per their own §9.2/§9.3 synopses — fmea is the outlier that dropped --output from this PR's schema-conformance pass.
Why this matters
hara/fmea/tara/safety-case are marked "schema-formalized but not yet consumed by FuSaOps" (§9.2 intro) — but the CLI surface is still part of what a conformant tool commits to, and anyone (a script, CI job, or a future FuSaOps version) following the documented synopsis literally (--output <file>) gets a confusing runtime error pointing at a bogus nested path instead of either working or failing with a clear usage error.
Suggested fix
Add a proper --output <file> long option to cmd_fmea.c (mirroring cmd_tara.c's handling, which already supports both flags correctly), so the two are no longer merged by getopt's prefix matching.
Spec reference
x-FuSa spec §9.2:
(and §2.2's shared-flags table only lists
--output-diras applying torelease, notfmea.)What actually happens
cmd/cfusa/cmd_fmea.cnever defines a--outputlong option — only--output-dir <dir>:Because
--output-diris the only long option beginning with--output, GNUgetopt_long's unambiguous-prefix matching silently accepts--output <path>as an abbreviation of--output-dir <path>instead of rejecting it — so invokingfmeaexactly as the spec's own synopsis documents doesn't error out cleanly, it silently does the wrong thing:(It treated the given file path as a directory and tried to write
<path>/fmea.jsonunderneath it.)For comparison,
cfusa taraimplements both--output <file>(writes exactly that path in any format, confirmed working) and--output-dir <dir>, andcfusa hara/cfusa sas/cfusa sciall implement--output <file>correctly per their own §9.2/§9.3 synopses —fmeais the outlier that dropped--outputfrom this PR's schema-conformance pass.Why this matters
hara/fmea/tara/safety-caseare marked "schema-formalized but not yet consumed by FuSaOps" (§9.2 intro) — but the CLI surface is still part of what a conformant tool commits to, and anyone (a script, CI job, or a future FuSaOps version) following the documented synopsis literally (--output <file>) gets a confusing runtime error pointing at a bogus nested path instead of either working or failing with a clear usage error.Suggested fix
Add a proper
--output <file>long option tocmd_fmea.c(mirroringcmd_tara.c's handling, which already supports both flags correctly), so the two are no longer merged by getopt's prefix matching.