Clarify SARIF formatter boundaries: framework-generic vs OSPS-specific

[mlieberman85]

Background

The SARIF formatter currently lives in packages/darnit-baseline/src/darnit_baseline/formatters/ and mixes:

• Framework-generic SARIF emission (mapping CheckResult to SARIF result objects, run metadata, rule metadata lookup from TOML).
• OSPS-baseline-specific pieces (control ID conventions, help URL patterns, severity mapping choices).

Problem

Other implementations (darnit-gittuf, darnit-reproducibility) that want SARIF output either reimplement the generic parts or import from darnit-baseline, which would violate the plugin isolation intent.

Proposal

Split the formatter along the boundary:

• Move framework-generic SARIF emission into packages/darnit/src/darnit/formatters/sarif.py.
• Leave OSPS-baseline-specific mapping in darnit-baseline as a thin adapter over the framework formatter.
• Other implementations gain a shared base without cross-plugin imports.

Enforce boundary via test: the framework formatter must not reference OSPS control IDs or baseline-specific constants.

Scope

Refactor, no behavior change. Existing SARIF output for OSPS should be byte-identical (or documented deltas) after the split.

Related

• Architecture review that surfaced this (Aug 2026)
• Rule 1 (framework never imports implementations) in CLAUDE.md

[Marc-cn]

Looked at formatters/sarif.py. Most of it is already framework-generic the OSPS coupling is four constants:

TOOL_INFO_URI (143)
the baseline.openssf.org helpUri/docs_url fallback (107, 300)
"OSPS Control {id}" and the OSPS-Level-{n} tag (268, 282)
the ospsLevel property key (363)

So: move the rest to darnit/formatters/sarif.py, parameterise those four, leave a thin OSPS adapter. Only consumer is tools.py:234, so it's a small change. Two questions first:

ospsLevel is an emitted SARIF property name, renaming it is visible to anyone parsing our output, so it breaks "byte-identical." Keep it in the adapter or accept a documented delta?