Module scanner_run 

One scan pass over a candidate version’s exact bytes. What: Scan every eligible candidate of one version through the loaded scanner. Why: This is the whole forbidden-strings check of one policy pass: candidate bytes come from the candidate store (staged or committed, never the worktree), go to the scanner in memory, and the scanner’s own results come back. No temporary file is written and no process is started per file.

In TS you’d write (pseudocode):

// const scans = await scanVersion(scanner, store, version, rulesPath);

Enums

ScanRunError

What: Why a scan pass stopped: the candidate layer failed, or the scanner did. Each variant carries the original typed failure. Why: Either way some file was not checked, so the pass has no result. Keeping the original failure lets the caller report its own cause.

Traits

CandidateBytes

What: Where a scan pass reads candidate bytes. A trait is an interface. Why: The candidate store reads the version’s objects; a direct fix reads the same objects with its in-memory corrections laid over them, and its later passes must scan the corrected bytes.

Functions

scan_version

What: Scan each eligible candidate and return the scanner’s result for every one scanned. &mut dyn CandidateBytes lends any byte reader for changing (it may read objects); Option<&[u8]> is “the rules file’s candidate pathname or nothing”; Result<T, E> is “a value or a failure”. Why: Results are returned for clean candidates too, so the caller can tell “scanned and clean” from “not scanned”. The first failure ends the pass with no partial result, because a partial result would look like a clean pass.