A line-ending conversion has two independent promises: the prose and logical lines stay the same, while the bytes that mark those boundaries change. LF and CRLF usually look identical in an editor window. A changed setting therefore cannot prove that the saved file uses the requested format.
The STUDIO-175 specimen stored the same four logical lines with physical LF, CRLF, and CR boundaries. It also preserved a failed candidate that was requested as CRLF but still contained LF, then recovered and repeated the conversion. The evidence separates the setting response, saved bytes, and normalized text identity.
Treat line endings as boundaries, not prose replacements
LF represents a line boundary with one control byte; CRLF uses two. Neither sequence is an ordinary phrase that should be edited with a visible word replacement. Use the editor's line-ending operation and verify the resulting bytes.
Preserve the received file and record the recipient's requirement. If no requirement exists, consult the repository, build system, or collaboration policy. Converting an entire project by habit can create noisy diffs and can break a consumer that expected the original convention.
The output must keep its characters, punctuation, blank-line positions, and intended final newline. Those content properties belong in the acceptance ticket before any conversion begins.
Freeze logical-line and text baselines
The controlled input is a four-line UTF-8 file with four logical boundaries, including the final newline. Physical counterparts were created for LF, CRLF, and CR so the test could distinguish the formats by bytes rather than appearance. The LF copy became the conversion source.
Record an opening checkpoint, a middle checkpoint, an ending marker, the logical line count, and whether the source ends with a newline. To compare prose after conversion, normalize both line-ending styles temporarily and compare the resulting text. A whole-file hash must change when boundary bytes change, so it is not an appropriate proof of unchanged normalized content.
Keep the format check separate: count CRLF pairs and lone LF bytes in the physical output. Together, normalized comparison and byte counting prove different parts of the requirement.
Blank lines are part of the manuscript structure. Record their positions and compare runs of boundaries after normalization. Leading and trailing spaces can be difficult to see, so use a whitespace-aware diff as supporting evidence and do not let an automatic formatter alter them during this operation.
Set the open tab to CR+LF
The source was opened in a dedicated workspace with rune tab open, and the tab identifier was retrieved. The run previewed rune tab set-line-ending --line-ending CR+LF --dry-run, then applied the same setting. The response showed CR+LF for the open tab.
That response describes the buffer configuration. It does not establish that a particular disk path has been persisted with CRLF. Name the destination, save from that exact tab, close it, and inspect the closed file. Do not copy a dry-run response into the delivery record.
This distinction also catches a common path error: an operator can change one tab while later handing off a similarly named file from another directory.
Recover the failed physical candidate and repeat the test
The failed state is physically preserved at failed-lf-preserved.txt; recovery never overwrote that path. It is 23 bytes, contains zero CRLF pairs and four lone LF delimiters, and has SHA-256 ffaff327ee4236568d751698436fccbc8a654a2b2d058170d90d2804d14f01ef. A CR+LF tab response does not change this closed artifact, so it remains the rejected LF evidence.
The same four logical lines were serialized to the separate path recovered-crlf.txt. That accepted file is 27 bytes, contains four CRLF pairs and zero lone LF delimiters, and has SHA-256 90e766165ae3981678ae48f2d98e2e46b1ce2e81f5da334dc1ef697db6831353. Rune's independent closed-file inspection returned CR+LF, and newline-normalized text matched the preserved failure source.
An independent repeat wrote recovered-crlf-repeat.txt and produced the same digest as the first recovery. All three paths are distinct. The failure digest differs from both recovery artifacts, and the failure still contains LF. The evidence can therefore display failure, recovery, and repeat side by side without reconstructing or overwriting the rejected state.
Investigate final-newline policy before rewriting prose
When a comparison appears to show every line changed, first determine whether the diff tool treats CRLF and LF as visible differences. Normalize the boundaries and compare again. Then examine only the remaining content differences.
A missing or added final newline can also change the reported line count. State the recipient's final-newline policy explicitly. Do not insert a blank paragraph merely to make counts match.
If garbled characters appear at the same time, separate encoding repair from boundary conversion. Return to a correctly decoded source, produce an accepted encoding result, and use that file as the input for the line-ending-only operation. One variable per pass makes the responsible step identifiable.
Choose the format from the recipient's entry condition
CRLF is correct when the consuming workflow requires it; LF is correct when that is the agreed standard. There is no universal winner among text file line endings. The recipient's toolchain supplies the exit value.
A production ticket should name the input and output paths, character encoding, requested boundary style, logical line count, normalized-content comparison, final-newline state, and byte counts. The first candidate failed with four lone LF boundaries. The recovered candidate passed with four CRLF pairs and zero lone boundaries.
The physical control matrix also passed: LF contained four lone LF boundaries, CRLF contained four pairs, and CR contained four lone CR boundaries; Rune inspection returned LF, CR+LF, and CR respectively. The practical rule is to accept the bytes at the named destination, not the setting that was requested.
When a retest finally produces CRLF, add it as a new dated result instead of overwriting the failed evidence. Preserve which observation came from the tab and which came from the physical file. A recipient can then distinguish a corrected artifact from the earlier rejected candidate and verify the named path independently.