Module markdown_linter 

The executable’s linter for that policy: monochromatic-lint on PATH, bounded, once per candidate. What: The linter the executable gives markdown/autofix: monochromatic-lint, found on the invocation’s PATH and started once per candidate as monochromatic-lint --config=<file> --stdin --stdin-filename=<path> --fix from the repository’s top level, with a time bound and output caps. Why: This is the plan’s stream contract (doc/planning/unified-linter.md, section “Distribution and consumers”; doc/planning/cli-git-rust-implementation.md, lines 181 to 189). The program and its one-rule configuration are found and written once per invocation, when the first candidate needs them, so a command with no Markdown candidate never needs the linter. Every option is written as one --name=value argument, so a pathname that starts with - stays a value.

In TS you’d write (pseudocode):

// const run = await processLinter(env).lint({ topLevel, options, path, source });

Structs

ProcessLinter

What: The linter of one invocation: the environment it runs with, its bounds, where its files go, and, once known, its program and configuration file. Why: The lookup and the file are made at most once; their failures are remembered and reported to every later candidate the same way.

Constants

LINTER_LIMITS

What: The bounds of one linter run in the executable. Why: Measured on the host, one run takes about 11 milliseconds warm and 227 cold; the LFS rule also hashes every image a file links, which for a large image takes seconds, and the host has run at load averages of 40 to 90. A minute leaves room for all of that and still ends a hung linter. Standard output is the fixed source: the cap allows a large file whose every link grows into an object URL. Standard error carries only the findings the fixes leave.

Functions

executable_linter

What: The linter of the running executable: LINTER_LIMITS and the system’s temporary directory, made absolute. std::path::absolute resolves a relative directory against the current one without touching the filesystem. Why: The linter runs from the top level, so a relative configuration path would name another file there.

process_linter

What: The linter for an invocation with this environment, bounds and scratch directory. &[(OsString, OsString)] borrows the environment. Why: The executable passes LINTER_LIMITS and the system’s temporary directory; tests pass small bounds and a fixture.