Per StackHawk failure semantics: treat 42 as a finding to triage and 1 as a config error to fix - retrying 42 is always wrong.

Context: Problem: The HawkScan CI step exits non-zero and you are unsure whether to retry. Exit 0: scan ran, nothing at or above failureThreshold - pass. Exit 42: scan ran and findings met or exceeded failureThreshold - this is the intended success path of failure; block the pipeline or warn per your integration mode, but do not retry (retrying masks the result and burns scan minutes). Exit 1: the scan never produced results - config error, app unreachable, auth failure, invalid applicationId - fail the job and fix the config; retry exit 1 only on transient signals like HTTP 5xx during submission, container-pull timeouts, or health-check blips. Never use continue-on-error to implement warn-only - it swallows exit 1 too. failureThreshold tuning: start at High for a new pipeline, ratchet down once the backlog is clear.

## Matched source
Source: Source: https://github.com/stackhawk/agent-skills/blob/HEAD/plugins/hawkscan-ci/skills/hawkscan-ci/references/failure-semantics.md
Original query: "HawkScan exit code 42 means findings, not failure - never retry it like a flake"
Key terms: code, exit, failure, findings, flake, hawkscan, like, means, never, retry