Struct CheckOutcome 

pub struct CheckOutcome {
    pub tool_findings: Vec<Finding>,
    pub llm_findings: Vec<Finding>,
    pub failures: BTreeMap<PathBuf, FailureReason>,
    pub provider_uses: Vec<ProviderUse>,
    pub retry_push: bool,
    pub review_activity: Option<ReviewActivity>,
    pub exit: Exit,
}

Everything one check run produced.

The two layers stay in separate fields all the way to rendering. Their findings are gated differently - deterministic ones always block, LLM ones only under --fail-on - and keeping them apart makes that structural rather than a tag on Finding that a caller could read wrong.

Fields

tool_findings: Vec<Finding>

Findings from the configured deterministic tools. These always block.

llm_findings: Vec<Finding>

Findings from the LLM. These only block under --fail-on.

failures: BTreeMap<PathBuf, FailureReason>

Files that went unanalyzed for any reason. The two layers cover the same files, so the CLI unions them; on a key collision the first reason wins, matching AnalysisResult::merge.

provider_uses: Vec<ProviderUse>

Which providers answered, and for how many files.

Empty when the LLM layer produced nothing at all. Only providers that served at least one file appear, in chain order, so a run that never left the head is one entry - and a run that did fall through says so rather than leaving a silent switch from a local model to a paid one.

retry_push: bool

A cold push review completed successfully and must be retried over a new Git transport. False for ordinary checks and warm push gates.

review_activity: Option<ReviewActivity>

What this invocation did to the bounded semantic-review cycle.

exit: Exit

The gate’s verdict for this run.

On the outcome rather than passed alongside it: render used to take an Exit as a separate argument, which let the two disagree - and they did, because render computed its own and ignored --fail-on. A field set once by run makes the mismatch unrepresentable.