# 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).