Stale rustdoc in lib.rs: "empty in S1 — rules arrive in S2", and "9 lint rules" (there are 10)

[dean0x]

The lint_str rustdoc in crates/mds-core/src/lib.rs carries two stale claims in a single sentence. Trivial comment fix, no behaviour change.

Current text

crates/mds-core/src/lib.rs:1162-1166:

Lint an MDS source string with default options.

Runs the check gate (resolve+validate) first: returns Err(MdsError) when the template does not compile. On a clean gate, applies the 9 lint rules and returns a LintResult (empty in S1 — rules arrive in S2).

Problem 1 — lib.rs:1166, "empty in S1 — rules arrive in S2"

Obsolete. Lint rules have shipped, so LintResult is not empty on a clean gate. "S1" and "S2" refer to a staging scheme that is no longer in use anywhere in the codebase, which makes the parenthetical actively confusing to a reader who has no context for those labels.

Problem 2 — lib.rs:1165, "the 9 lint rules"

Wrong count: there are 10.

run_rules at crates/mds-core/src/lint/mod.rs:111-135 dispatches exactly ten rule checks:

• Local-AST (mod.rs:121-125): empty_block, redundant_else, unreachable_branch, duplicate_import, duplicate_export
• Semantic (mod.rs:128-131): unused_variable, unused_import, unused_function, shadow_variable
• Token-based (mod.rs:134): legacy_interpolation

lib.rs is the lone outlier — every other statement of the count is already correct:

• crates/mds-core/src/lint/mod.rs:5 — "applies the 10 lint rules"
• crates/mds-core/src/lint/mod.rs:106 — "Apply all 10 lint rules"
• README.md:215 — "A 10-rule static analyzer"

Counting note for whoever fixes this: crates/mds-core/src/lint/rules/ contains 11 files besides mod.rs. That does not mean 11 rules — structural_eq.rs is a shared helper, not a rule, and has no check entry point in run_rules. This off-by-one is the likely origin of any miscount. Count the dispatched check calls in run_rules, not the files in the directory.

Fix

Rewrite the sentence at lib.rs:1165-1166 to drop the S1/S2 parenthetical and state the correct rule count — or, better, avoid restating a count that has already drifted once. Something like "applies the lint rules and returns a LintResult" stays correct as rules are added. If the count is kept, it needs to be 10.

Verified against main @ 6d41777.

Why deferred

Found incidentally during unrelated design work; not in scope for that change.

[KiranRajeev-KV]

Hello, I'd like to work on this if it's still available.