fix: add strict parsers, FailOn zero-value fix, Finding validation, scorecard - #27
Merged
Conversation
ParseSeverity and ParsePhase fail open: unknown input silently maps to SeverityInfo / PhaseUnknown, so a typo like "critcal" is indistinguishable from a legitimate value when the input is untrusted. Add ParseSeverityStrict and ParsePhaseStrict (same matching rules, but a descriptive error for unknown input) and mark the lenient parsers Deprecated so callers handling untrusted input migrate.
Result.Failed treated an unset FailOn (zero value SeverityInfo) as "fail on any finding", so a review result assembled without an explicit threshold failed on informational findings. Add a FailOnSet field plus a SetFailOn method, and make Failed use SeverityCritical as the effective threshold when the threshold was never set — matching the sight and inspect engine defaults. Explicit thresholds (including Info) keep their meaning when set via SetFailOn. BREAKING CHANGE: FailOn assigned by direct field assignment without SetFailOn now falls back to the critical effective threshold.
Add Stats.LLMErrors so providers can report non-fatal errors encountered during analysis; a non-empty list signals that findings may be partial. Additive field, no behavior change — engines populate it in follow-up changes.
Add Finding.Validate to both the types and review packages, enforcing the minimum contract invariants: non-blank Message, non-negative Line, and Confidence within [0, 1]. Returns a descriptive error naming the first violated field so producers can reject malformed findings before they reach consumers.
Weekly OSSF Scorecard analysis publishing SARIF to code scanning, pinned to the same action SHAs as the other hawk-eco repos (yaad, sight, inspect).
Mirror the review.Result fix: Report.Failed now treats a threshold that was never set via SetFailOn as SeverityCritical instead of the SeverityInfo zero value, so a zero-value Report no longer fails on informational findings.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Deep code-quality audit fixes for hawk-core-contracts:
ParseSeverityStrictandParsePhaseStrictreject unknown values with a descriptive error; existingParseSeverity/ParsePhaseare deprecated (fail-open to lowest severity)review.Result.Failed()andverify.Report.Failed()no longer treat an unsetFailOn(zero =SeverityInfo) as "fail on any finding"; the effective default is nowSeverityCritical. AddSetFailOn()/FailOnSetto both structstypes.Finding.Validate()andreview.Finding.Validate()enforce non-blank Message, non-negative Line, Confidence ∈ [0,1]review.Statsfor non-fatal provider errorsAll workspace consumers grep-checked — no caller relied on zero-value fail-on-info semantics.
Test plan
go build ./...go test ./...(59 PASS, 0 FAIL)make boundaries