Changelog 2026-07-09 -- repo_lint.py CRLF write_text bug (DOCFIX-143)

Item

1. DOCFIX-143 -- --record-clientdocs-sweep/--record-guide-skill-coupling no longer emit CRLF

FILE: scripts/repo_lint.py (2 sites: the receipt writer, the coupling writer)

WHY: flagged during the 2026-07-09 commit-and-push of the repo-agnostic sweep (DOCFIX-141) -- receipt.write_text(...) on Windows translates \n to the platform newline (\r\n) before writing, so clientdocs/sweep-receipt.txt came out CRLF on disk every time --record-clientdocs-sweep ran in this session. .gitattributes' eol=lf normalizes it away at git add time, so no CRLF ever reached a commit -- but the script was silently depending on git to clean up after its own sloppy output, the same class of "works here only because something downstream bails us out" issue as the DOCFIX-140 L1 path-separator bug.

FIX: both writers now build the exact string, .encode("ascii") it, and write_bytes() it -- no platform-dependent newline translation happens at all. .encode("ascii") (not "utf-8") deliberately: this repo's own L1 rule is ASCII-only, so a future path/hash that somehow isn't ASCII now raises loudly here instead of writing content L1 would fail on anyway.

VERIFIED: re-ran --record-clientdocs-sweep after the fix; sweep-receipt.txt byte-inspected directly (0 CR, 41 LF, was 41/41 before). tests/repo-lint harness 34/34 (unchanged -- the fix doesn't change any file's logical content, only its byte-level newline encoding). Full repo-lint.sh still 0 fail / 1 documented legacy warn.

REVERT: git checkout HEAD~ -- scripts/repo_lint.py (re-arms the CRLF-then-git-cleans-it-up dependency; not recommended).