A fence opens on a CRLF line, so a Windows checkout, and a file committed with CRLF, read the same as on Linux. No check looks for anything new; one stops being blind. The JSON schema is 9.
A fenced block was invisible in a CRLF file. The check split a file on \n, so in a file with CRLF endings every line kept its \r; the regex that opens a fence ended in (.*)$, and JavaScript's . does not match \r, so no fence ever opened. Every filter that rests on a fence was off: the block read as a command, the block in a programming language left unread, the block that quotes markdown, and prumo-ignore-next-line over a block. The closing regex tolerated the \r, which is how it stayed unnoticed through thirty-one releases: the suite's fixtures are all LF, and the repositories measured were cloned with LF. It surfaced on a Windows clone of a repository of skills, where a skill that teaches how to write skills quotes example SKILL.md files in markdown blocks: six broken links reported, all quotations. drift counted every heading inside a fence as a section, 167 instead of 126 there. budget was already normalising and did not change.
The fix. Lines are split on \r?\n in the check, in the Makefile and configuration readers and in drift, and the fence opener accepts a trailing \r, so classifyLines reads raw CRLF lines too. --fix keeps a file's line endings, as it did. Two tests hold it: the same note in LF and in CRLF gives the same findings on the same lines and keeps CRLF after a fix, and the same sections in drift.
Measurement. Differential, LF against CRLF with the same content. 40,000 generated notes through the classifier line by line, 1.16 million lines, no difference. Two repositories of 2,000 notes each, every note named so no gate holds anything back: 5,185 and 5,160 findings on both sides, none on one side only, 3,432 and 3,435 sections identical. 87 public repositories, 49,649 context files and 111,118 markdown files rewritten to CRLF: 23,416 findings identical and 845,712 sections identical. Of those markdown files 2,299 were CRLF in git already, 800 in one repository, so the fault was live on Linux too. The repository that showed it comes back clean on a Windows clone.
Suite 168 to 170.