Module runner 

Run a project’s own deterministic checkers and turn their output into Findings.

This is the gating half of analysis. Tool findings are precise - they come from the rules the project itself configured - so they block, while the LLM’s semantic findings inform. Keeping the two apart by source rather than by severity is what makes the gate calibratable at all.

Three states, deliberately distinct:

• ToolStatus::Ok the tool ran; its findings are authoritative.
• ToolStatus::Skipped the project has not configured this tool, so it has no opinion here. A pass.
• ToolStatus::Unavailable the tool should have run and could not. Not a pass - reporting it as clean is the same “unanalyzed is not clean” mistake that would let a commit gate rubber-stamp commits.

Re-exports

pub use parsers::parse_output;

Modules

parsers

Turn each tool’s own output shape into Findings.

Structs

ToolOutcome

What happened when one tool was asked to check some files.

ToolOutputError

The tool produced output we could not parse.

Enums

ToolStatus

Whether a tool ran, declined to run, or failed to.

Constants

TOOL_TIMEOUT

A tool that has not produced output by now is hung, not slow.

Functions

is_configured

Whether the project has opted into this tool.

resolve_tool

Find the executable for a tool, preferring the project’s own copy.

run_tool

Run one deterministic tool over some files.

tool_status

Whether this tool will run here, without running it.