Module scanner_adapter 

The linked forbidden-strings scanner: one load per invocation, typed redacted findings. What: The repository’s forbidden-strings scanner, linked in and loaded once per invocation. Why: The TypeScript wrapper wrote each candidate to a temporary file, started the scanner as a child process and parsed its standard error. Here candidate bytes go straight to the scanner library, and its own typed findings come back. Nothing is re-derived: rule loading, the rule cache, matching, redaction and the fail-closed findings all stay the scanner’s.

What the linking executable owes the scanner (package/cli/forbidden-strings/README.md, “In-process candidate scans”): an unwinding panic strategy, which this file checks at build time, and a panic hook that prints no payload, installed before the first scan. The scanner catches its own loader and matcher panics; this module adds no catch of its own.

In TS you’d write (pseudocode):

// const scanner = CandidateScanner.load(rules, true); const scan = scanner.scan(candidate, bytes);

Structs

CandidateScanner

What: The loaded scanner. The field is private: the only way to obtain a value is load. Why: Holding the loaded rules in one value is what makes “load once, scan many” a property of the type: scanning borrows it and cannot reload.

RulesSource

What: Which rules file to load and whether its absence is an error. PathBuf owns the path (sibling &Path would borrow the caller’s). Why: The standalone scanner tolerates a missing default rules file when the built-in baseline is on, and never a missing file that was named explicitly. The same two facts are passed to the library.

ScannerError

What: One scanner failure: its cause and a complete explanation. String owns the text (sibling &str would borrow a temporary). Why: The explanation of a load failure is the scanner’s own redacted message, which names a path or an opaque rule index and never rule text.

Enums

ScannerFailure

What: Why a scan could not be set up or carried out. #[derive(...)] generates copying, debug printing and ==. Why: Both causes stop policy evaluation: no rules means nothing was checked, and a pathname that cannot be handed to the scanner was not checked.