The relative-link check reads inside inline code spans, so a regular expression printed in backticks such as [2-9](\.\d+) is reported as a link to a missing file

[HackingGate]

Measured

uphold 1.22.0, rule kind that checks relative links resolve (link_targets in src/scan.rs). The link scanner skips fenced code blocks but not inline code spans. A generated Markdown page that prints a regular expression inside backticks, for example a JSON Schema pattern containing [2-9](\.\d+), is read as a Markdown link whose target is \.\d+, and the rule reports a missing file. Found by a consumer rendering schema pages with json-schema-for-humans 1.5.1; the pages carry no other relative link.

Why it matters

CommonMark gives a code span precedence over link syntax: text inside backticks is literal. A link check that reads inside a code span refuses correct documents, and the only remedy a consumer has is to exclude the files from the rule, which also removes the real links in them from the check. The consumer here had to add a files.exclude for its generated pages.

Done when

• The link scanner skips inline code spans (single and multi-backtick) as it skips fenced blocks, with a CLI test: a page whose only bracket-paren text is inside backticks passes, and the same text outside backticks is still checked.
• REFERENCE.md's description of the rule says what is skipped.
• Wheel named: if the scanner is hand-rolled, consider reading link events from the Markdown parser the engine already depends on, if any; otherwise the smallest change to the existing scanner.