fusa-asil-b CI job's cpfusa init --force wipes the real .fusa-reqs.json before traceability runs, so coverage is always reported as 0% #19

What's wrong

.fusa-reqs.json is a real, populated 53KB file containing hundreds of REQ-* entries. But the fusa-asil-b CI job runs cpfusa init ... --force || true (.github/workflows/ci.yml:252) as its first cpfusa step, before the traceability step (ci.yml:264) and the metrics-record step (ci.yml:326). --force overwrites the existing, populated .fusa-reqs.json with an empty scaffold.

As a result, live CI traceability coverage is computed against zero requirements instead of the repo's actual requirement set, and the job still passes.

Evidence

Pulled the live log for a recent fusa-asil-b run/job (run 30401582839, job 90418572950):

• Init step: [OK] Created .fusa-reqs.json
• Trace step: No requirements loaded...
• Metrics step: Metrics recorded: errors=0 warnings=0 reqs=0 coverage=0.0%

The job (and the whole run) is green despite reqs=0.

• .github/workflows/ci.yml:252 — cpfusa init ... --force || true
• .github/workflows/ci.yml:264 — traceability step, runs after the overwrite
• .github/workflows/ci.yml:326 — metrics record step, reads the now-empty state

Why it matters

This makes the ASIL-B traceability gate a no-op: it can never fail regardless of actual requirement/test coverage, and the reqs=0 coverage=0.0% metric that gets recorded is meaningless (and misleading if consumed downstream, e.g. for compliance reporting or badges). The repo's real, hand-maintained .fusa-reqs.json is silently discarded on every CI run.

Suggested fix direction

Remove the cpfusa init --force step from the CI job (it should only be needed for first-time local setup, not CI, where the file already exists and is checked in), or reorder so init never runs when .fusa-reqs.json already exists, or drop --force/|| true so an unexpected overwrite would at least be visible as a failure.