Module policy_markdown 

The markdown/autofix policy over candidates, behind its linter interface. What: The optional markdown/autofix policy: every Markdown candidate the lifecycle offers is passed through monochromatic-lint --fix with the policy’s rules; a changed source is reported, and corrected on git cli-git fix, and each finding the fixes leave is reported as it is. Why: The installed wrapper’s markdownLintPolicy (package/git-policy/markdown-lint/src) decides the behaviour: deleted files, symbolic links and submodules are skipped, and so are excluded paths before any linter starts and contents that are not UTF-8; candidates are linted one at a time, in candidate order; the codes and words of both findings are kept. One thing differs by design: the extension test is the linter’s own (.md and .mdx, exact case), so no file is sent that the linter refuses. The autofix finding keeps the installed wrapper’s words, which name its former linter, so both wrappers report the same file the same way while both are in use.

In TS you’d write (pseudocode):

// const findings = await rewriteCandidates({ rules, exclude, repositoryRoot, canApplyPatches, candidates });

Structs

LintRequest

What: One candidate for the linter. 'a names how long the borrowed parts last. Why: The linter runs from the top level, so .lfsconfig, .gitattributes and linked images resolve as they do for the person, and lints source as the file at path.

MarkdownState

What: The policy’s state for one invocation: its options, its linter and the compiled exclude patterns. Box<dyn MarkdownLinter> owns “any linter”, chosen at run time. Why: The lifecycle sets the options once; the patterns compile on first use, and a failure to compile is remembered, like the scanner’s rules.

Constants

MARKDOWN_AUTOFIX_CODE

The policy-local code of a candidate the fixes rewrite.

MARKDOWN_VIOLATION_CODE

The policy-local code of a finding the fixes left.

UNCHECKED_REMEDY

What the person can do about a candidate the linter could not check.

Traits

MarkdownLinter

What: Whatever lints one candidate. A trait is a named set of methods, like a TS interface; &mut self lends it for writing, because it may remember the program and its configuration across candidates. Why: The executable starts the real linter; tests answer from a script, so every branch of the policy is reached without a child process.

Functions

check_markdown

What: Check every candidate of the lifecycle. <F: RepositoryFacts> accepts any facts provider; &mut MarkdownState lends the policy’s linter and patterns. Why: See the module comment. A policy with no rule selected has nothing to run; the first candidate the linter cannot check ends the policy with that candidate named.

is_markdown_path

What: Whether a pathname ends in .md or .mdx, with exactly that case, by the platform’s rule for a file name’s extension. Why: The linter decides the language with the same rule (run_paths.rs, language_of) and refuses any other name read from standard input; a name such as .md, with no extension under that rule, is therefore not Markdown here.

markdown_state

What: A state over linter with the default options and nothing compiled. Why: Every lifecycle builds its checks the same way and then sets the options.