Changing a file’s boundary format is not the same operation as finding and replacing visible words. The manuscript lines should retain their content and order while CRLF or LF bytes change. A reliable workflow joins the editor setting, named destination, closed-file readback, and byte counts.
The STUDIO-195 specimen used three short logical lines in UTF-8. Its accepted result was six bytes, three LF boundaries, zero CRLF pairs, and independent rediscovery as UTF-8/LF.
Separate boundary conversion from word replacement
Replacing a token such as Old195 with New195 changes manuscript content. Switching line ending formats changes the representation between lines. Search result counts cannot establish whether the physical file is LF or CRLF.
The work ticket should name the input encoding, detected starting style, requested style, logical line count, and final-newline policy. Limit the operation to one explicit path. A project-wide normalization needs its own approved file list because it can create broad diffs or affect a consumer that expects the previous convention.
Preserve the source before changing it. The backup supplies a recovery point if a boundary operation also changes text.
Freeze the CRLF specimen’s logical text
The input line-endings.txt contained three short logical lines. Before conversion, the run preserved a copy and recorded the normalized text. Because the specimen is small, every line can be inspected directly.
A whole-file hash is expected to change after a successful boundary conversion. Prove content identity by normalizing both CRLF and LF to a common separator and comparing the resulting text. Prove physical format separately by counting boundary bytes.
Record the content and order of all three control lines. In a production source, treat intentional blank lines and trailing spaces as content unless the project says otherwise. Disable automatic formatting so a boundary-only change does not also rewrite indentation or punctuation.
Also record whether the file ends with a newline. Some inspectors report an additional empty line when that final boundary exists, so an unexplained line count is not a safe acceptance measure.
Configure the open tab for LF
The specimen was opened in its dedicated workspace with rune tab open. After retrieving the tab identifier, the run previewed rune tab set-line-ending --line-ending LF --dry-run and then applied it. The open tab reported LF.
The dry run protects against selecting the wrong tab or direction, but it does not persist bytes. Name the intended destination, save that exact buffer, and close it. A setting value without a saved-path result remains an intermediate observation.
If the tab response names a different path, stop before saving. Correcting the target is safer than converting a similarly named file and trying to reconcile the outputs later.
Persist the six-byte controlled output
The LF form was written to the target path inside the STUDIO-195 workspace. The write response reported six bytes. For this intentionally tiny ASCII control, file size is a useful supporting value because the line structure is known.
Do not generalize six bytes to a Japanese manuscript. UTF-8 characters can occupy multiple bytes, so size cannot prove prose identity in normal production. Use normalized comparison for content and retain byte size only as an artifact identity check.
The destination in the write response must match the path inspected next. If delivery uses a new filename, put that exact filename in the ticket before the operation.
Rediscover LF after closing the tab
After the buffer was closed, rune inspect text --path <line-endings.txt> reported UTF-8, LF, six characters, and four lines. The four-line report corresponds to three content lines plus the final newline under this inspector’s counting behavior.
An independent byte check found three LF bytes and zero CRLF pairs. Those are the physical acceptance values. Combined with equal normalized text, they establish that the boundary representation changed while the intended lines remained.
This closed-file result is stronger than a status label because it tests the artifact another tool or recipient will actually open.
Diagnose the apparent extra line at the end
If the line count is one higher than the number of visible content lines, inspect final-newline policy before deleting anything. In this specimen, the count of four was recorded with three content lines and a final LF. It is accepted only when that terminal boundary is required.
Remaining CRLF pairs suggest that another path was saved or that the conversion was incomplete. Too few LF bytes suggest joined lines or a removed final boundary. Changed characters require a return to the preserved source and a text comparison; repeatedly toggling the boundary format will not repair prose.
Hand off format and content as separate fields
Acceptance for this control requires the named saved path, UTF-8, LF, six bytes, three LF bytes, zero CRLF pairs, equal normalized text, and an intentional final newline. These values describe the artifact instead of merely reporting that an LF option was clicked.
If the recipient requires CRLF, reverse the requested and byte-level conditions. The objective is not to make LF universal; it is to make the closed file match the stated entry rule. By linking configuration, persistence, readback, and byte inspection on one path, line ending formats become a measurable file property rather than a confusing search-and-replace exercise.
For a batch, finish the ticket on one representative file first, then retain path and byte results for every file. Do not let one passing specimen stand in for files with different encodings or final-newline policies. Separate those files into groups before applying the setting.