---
name: include-str-fixture-inherits-checkout-eol
description: "include_str! reads WORKING-TREE bytes — under core.autocrlf=true a fresh checkout hands the test CRLF while the author's never-re-smudged tree stays LF, so the builder is green and every fresh rig/CI checkout is red"
metadata: 
  node_type: memory
  type: project
  originSessionId: 13a8c939-6527-4247-88c0-63d34aaec0c5
  modified: 2026-08-19T09:12:15.194Z
---

`include_str!` of a repo doc inherits the CHECKOUT's line-ending normalization, not the repo's
canonical bytes. Measured at W3 gate 2026-08-19 (@9193d40): `core.autocrlf=true` on hfenduleam +
no `.gitattributes` eol attr ⇒ fresh worktree materializes `docs/ER-SKELETON.md` with CRLF;
`split_once("\n\n")` cannot match `\r\n\r\n`, panic cli.rs:33600; two cells red. Builder's own
tree was green 637/637 because git normalizes at COMMIT but never re-smudges an existing
working-tree file — the as-authored LF bytes persist only for the author.

**Why:** a green in the author's tree + red in every fresh checkout is the exact inversion that
burns a golden run (the golden checks out fresh on the same box). Linux stays green (autocrlf
off) ⇒ reads as a Windows-only flake when it is deterministic environment skew.

**How to apply:** any cell doing `include_str!`/`fs::read` of a repo text artifact and comparing
against composed strings must either normalize `\r\n`→`\n` at the fixture edge or pin the file's
eol in `.gitattributes` — and the gate must run from a FRESH checkout precisely because the
builder's tree structurally cannot show this class. Kin: [[rig-inherits-the-defect-it-studies]],
[[verify-the-subject-not-just-the-measurement]].