Module scanner_selection 

Rules-file precedence and which candidates the scanner is given. What: Which rules file the scanner loads, and which candidates it is given. Why: The scanner library filters nothing; the standalone scanner and the TypeScript policy applied these choices around it. They are restated here once, as pure functions: the rules-file precedence (FORBIDDEN_STRINGS_RULES, else forbidden-strings.local.txt in the repository root) and the paths that hold the rules themselves, which would otherwise match their own content.

In TS you’d write (pseudocode):

// const rules = rulesSource(process.env.FORBIDDEN_STRINGS_RULES, repositoryRoot);
// const eligible = candidates.filter(candidate => isScannable(candidate, rulesCandidatePath(rules.path, repositoryRoot)));

Constants

DEFAULT_RULES_FILE

The rules file used when the variable is unset, relative to the repository root.

RULES_VARIABLE

What: The environment variable naming the runtime rules file. &str is a borrowed string compiled into the program. Why: It is the standalone scanner’s own variable, so one setting serves both.

SCANNER_SELF_MATCH_PATHS

What: Repository paths never given to the scanner because they hold rule sources. &[&[u8]] is a borrowed list of borrowed byte strings. Why: These files contain the patterns themselves and would match their own rules. The list is the TypeScript policy’s, unchanged; pathnames are compared as bytes because candidate pathnames are bytes.

Functions

is_scannable

What: Whether a candidate is given to the scanner. Option<&[u8]> is “the rules file’s pathname bytes or nothing”. Why: A deleted path has no content and leaves the tree; the rule-source files and the rules file itself would match their own patterns. Every other candidate is scanned, whatever its mode.

rules_candidate_path

What: The rules file’s pathname as a candidate would carry it, when it lies inside the repository. Option<Vec<u8>> is “pathname bytes or nothing”. Why: A rules file tracked in the repository would match its own patterns, so its candidate is not scanned. A rules file outside the repository can never be a candidate, which is “nothing”.

rules_source

What: Select the rules file: the configured rulesFile, else the variable’s value, else the default file, each relative to the repository root. Option<&str> is “the configured name or nothing”; Option<&OsStr> is “the variable’s value or nothing”. Why: The user decided on 2026-10-05 that configuration names the file first and the variable second. The spawned scanner ran with the repository root as its working directory, so a relative setting meant “relative to the root”. In-process there is no such directory change, so the root is joined explicitly; .join(..) keeps an absolute variable value as it is, and a configured name is relative by construction (config_rules_file.rs). A configured name or a set variable makes a missing file an error; only the default file may be missing.