Adopt x-FuSa spec v1.15.0: attestation carry-forward MUST + coveragePct clamp

[SoundMatt]

x-FuSa spec v1.15.0 — attestation carry-forward MUST + two implementer-guidance additions

docs/x-fusa-spec.md in FuSaOps was updated to v1.15.0 (from v1.14.1) after a same-day deep audit of four already-"conformant" x-FuSa tools turned up recurring gaps. Three changes:

1. §1.6.2 — Attestation carry-forward is now a MUST

Before an artifact-producing command rebuilds its output, it MUST load any existing attestation from the prior saved copy of that output file and carry it forward onto the freshly-built result, rather than discarding it. Staleness then falls out automatically: a carried-forward contentHash that no longer matches the freshly-computed content hash means the attestation is stale (per the existing AttestationValid-style check), and a tool MUST treat a stale attestation as absent for §1.6.1 Rule B suppression purposes.

Why: in the initial rollout, at least one tool's otherwise-correct "always rebuild the artifact" implementation was silently wiping every human review (attestation.status: "reviewed") on the very next run, because nothing in the spec actually forbade that — "regenerate the artifact" and "preserve any existing attestation" were never stated as compatible requirements until now.

What to check: does your fmea/tara/hara/safety-case/sas (whichever your tool implements) command, when re-run against a project that already has a saved output file with a "reviewed" attestation, preserve that attestation in the new output (assuming the underlying content hasn't changed)? If it currently always emits a fresh/empty attestation field (or omits it) regardless of what was there before, that's the gap this MUST closes.

2. §1.6 rule 4 — implementer guidance (SHOULD, non-binding)

New guidance paragraph recommending that a coverage-denominator scanner (e.g. componentsInProject/assetsInProject) reuse the same test-tree and stdlib/builtin-call exclusion logic already used elsewhere (e.g. §1.4.1's trace --func-coverage), rather than maintaining a second, independently-drifting exclusion list. This is advisory, not a MUST — flagged because 3 of 4 audited tools had independently reinvented (and under-scoped) this logic.

3. §9.2 — coveragePct MUST NOT exceed 100

Both fmea's and tara's summary.coveragePct bullets now explicitly state the value must not exceed 100. Two of the four audited tools were producing values above 100 — in every case traced back to rule 4 above being silently violated (a test fixture or excluded file scanned as if it were a real project component). If your tool implements coveragePct for either artifact, worth adding a defensive clamp plus a regression test with a fixture that has a non-trivial test-source tree (a fixture with no src/test-equivalent directory cannot exercise this bug).

---

Action requested: review your tool's current implementation against the three points above and adopt what applies. If you find the spec text itself is ambiguous or contradicts something already shipped, please file a new issue on SoundMatt/FuSaOps describing the specific ambiguity — don't guess at intent. Full spec: docs/x-fusa-spec.md in SoundMatt/FuSaOps, changelog §14 entry "1.15.0" has the complete rationale.

[SoundMatt]

Adopted in #81 (v0.5.47): coveragePct clamp (§9.2 MUST) and the §1.6 rule 4 test-tree/stdlib exclusion-reuse guidance are both in. Attestation carry-forward (§1.6.2) was audited and found already correctly implemented — no change needed there.

[SoundMatt]

Resolved in #81 (v0.5.47), against all three points:

1. §1.6.2 attestation carry-forward MUST — audited every artifact-producing command: fmea/tara/safety-case/sas were already conformant (each reads back the prior saved copy's attestation via cfusa_qb_attestation_read() before rebuilding). The one real gap was hara --format json, which built its output field-by-field and silently dropped the input file's attestation object entirely — fixed as part of hara --format json is not a verbatim passthrough of .fusa-hara.json — drops cross-references and attestation #73 (now a verbatim passthrough).
2. §1.6 rule 4 test-tree/stdlib exclusion reuse (SHOULD) — cmd_fmea.c/cmd_tara.c previously each carried their own near-identical is_test_file() copy and independent (under-guarded) call-site scanner. Consolidated into shared cfusa_is_test_source_file(), cfusa_extract_call_name(), and cfusa_is_stdlib_call() in src/utils.c, used by both commands (and cmd_trace.c's existing is_test_file() already matched this convention).
3. §9.2 coveragePct MUST NOT exceed 100 — added a defensive clamp to both fmea/tara, plus regression tests (test_fmea_coveragepct_never_exceeds_100_with_test_tree, test_tara_coveragepct_never_exceeds_100_with_test_tree) using a fixture with a non-trivial test_*.c test-source tree alongside real project source, per the spec's own implementation note.

No spec ambiguity was found while implementing any of the three points — the spec text was clear enough to act on directly, so no new FuSaOps issue was filed.