What problem does this solve
A cladding gate run produces rich, structured findings (DriftFinding[]), but they only live in cladding's own terminal/JSON output. There is no way to surface them in the place teams already triage code issues — the GitHub Security tab / code-scanning alerts, or any SARIF-aware viewer (VS Code SARIF Viewer, etc.). Today a CI run that fails the gate shows a wall of text in the Actions log; reviewers can't see drift findings inline on the PR diff.
Proposed shape
Add a clad check --format sarif output mode that serializes the gate's findings as SARIF 2.1.0 (OASIS standard, ingested natively by github/codeql-action/upload-sarif).
The internal finding shape already maps almost 1:1:
DriftFinding (src/stages/types.ts) |
SARIF |
detector |
result.ruleId + reportingDescriptor |
severity (error/warn/info) |
result.level (error/warning/note) |
| file / line refs |
result.locations[].physicalLocation |
| stable hash ID |
partialFingerprints (de-dupes alerts across runs) |
So the modeling cost is low. Each detector becomes a SARIF rule; each finding a result.
Versioning scope (GOVERNANCE.md §2)
In-scope check (GOVERNANCE.md §4.1 / §4.2)
Alternatives considered
- GitHub Actions annotations (
::error file=…::) — works without GHAS/code-scanning enabled, but is ephemeral (no Security-tab history, no dedupe). Good as a complementary cheaper mode, but SARIF is the durable, standard one. Could ship annotations as a follow-up.
- GitLab Code Quality JSON — deprecated in GitLab 17.3; lower priority.
Willing to implement?
Context: this is one item from a competitive-gap analysis of cladding vs. the 2025–26 harness field. Happy to share the full write-up if useful for triage.
What problem does this solve
A cladding gate run produces rich, structured findings (
DriftFinding[]), but they only live in cladding's own terminal/JSON output. There is no way to surface them in the place teams already triage code issues — the GitHub Security tab / code-scanning alerts, or any SARIF-aware viewer (VS Code SARIF Viewer, etc.). Today a CI run that fails the gate shows a wall of text in the Actions log; reviewers can't see drift findings inline on the PR diff.Proposed shape
Add a
clad check --format sarifoutput mode that serializes the gate's findings as SARIF 2.1.0 (OASIS standard, ingested natively bygithub/codeql-action/upload-sarif).The internal finding shape already maps almost 1:1:
DriftFinding(src/stages/types.ts)detectorresult.ruleId+reportingDescriptorseverity(error/warn/info)result.level(error/warning/note)result.locations[].physicalLocationpartialFingerprints(de-dupes alerts across runs)So the modeling cost is low. Each detector becomes a SARIF
rule; each finding aresult.Versioning scope (GOVERNANCE.md §2)
In-scope check (GOVERNANCE.md §4.1 / §4.2)
Alternatives considered
::error file=…::) — works without GHAS/code-scanning enabled, but is ephemeral (no Security-tab history, no dedupe). Good as a complementary cheaper mode, but SARIF is the durable, standard one. Could ship annotations as a follow-up.Willing to implement?
CONTRIBUTING.mdfirst)Context: this is one item from a competitive-gap analysis of cladding vs. the 2025–26 harness field. Happy to share the full write-up if useful for triage.