A safe bulk replacement does not aim for zero old matches. It aims to change every approved occurrence while preserving every justified exception. This bulk replace preview text editor workflow uses the token Old318 in four files. Five matches are discovered, but only three are authorized edits. The other two are controls: one quotation must stay unchanged, and one archive file is outside the selected folder.
Begin with the Match Outside the Selected Folder
A workspace-wide search found five matches in four files. Restricting the search to the intended folder found four matches in three files. The missing fifth match belongs to archive.md, which is outside the operation and classified ARCHIVE. Its survival proves that the scope boundary held; it is not an unfinished replacement.
The four in-scope matches still require reading. Three express the current product wording and receive the label EDIT. One appears inside a quotation and receives KEEP. The review sheet records file, line, neighboring sentence, classification, reason, and reviewer. A count alone cannot supply those decisions. It can locate candidates, but it cannot decide whether a historical quotation should be modernized.
Use One EDIT Match as a Canary
Preview only the first approved occurrence. Confirm that the path, old text, replacement text, and surrounding sentence match one row in the review sheet. Apply that single change, save it, and search again. The expected movement is exact: the new wording gains one occurrence and the old wording loses one in the selected folder.
The measured run recorded canary=1. Only after that check passed were the other two EDIT rows previewed and applied, producing remaining=2. This staged action catches a bad pattern or bad folder before it affects all candidates. It also leaves a clear recovery point between the first approved edit and the remainder.
Read the Two Remaining Old Matches as Success Signals
After the approved changes, search the selected folder for Old318. Exactly one result should remain: the KEEP quotation. Search the whole workspace and two results should remain: KEEP plus the out-of-scope ARCHIVE. The measured values were therefore old inside=1 and old outside=1.
This is more informative than demanding zero. A zero result would mean that at least one protected occurrence had been changed. Each remainder must be mapped back to its review row and reason. Conversely, a third remainder would be unresolved and would block acceptance even if the replacement command reported success.
Recover by Returning to the Pre-Preview Copy
Suppose the quotation is accidentally replaced. Editing that one sentence back by hand can conceal other damage, so preserve the failed files and return to the read-only copy made before the canary. Verify its digest, rebuild the three EDIT rows, and begin again with one preview. Write the recovery to a new path instead of overwriting the failure.
After the repaired pass, inspect all five original locations. The three authorized rows must contain the new wording, the quotation must contain Old318, and archive.md must still contain Old318. This full-location check is necessary because a narrow repair could leave a second unauthorized change undiscovered.
Keep Search Counts Separate from Editorial Authority
Rune Studio's documented search and replace functions can support candidate discovery and controlled changes. They do not determine meaning. Editorial authority remains in the classification sheet, especially for quotations, proper names, code, and historical records. A regular expression can widen or narrow the set of matches; it cannot decide that every item in the set should change.
The current evidence also does not claim that every regular-expression feature or graphical notification was exercised. It establishes the file set, counts, canary, applied changes, reverse search, failure, and recovery on a fixed synthetic specimen. Any unobserved UI animation or warning stays outside the result.
Acceptance Is Three Changes and Two Explained Remainders
The pass record contains the starting search results, five classifications, the one-item canary, the two-item continuation, saved readback, and reverse-search counts. Another editor should be able to trace every output occurrence to one row. If the file set changes, take a new baseline rather than reusing these counts.
Acceptance is reached when all three EDIT matches use the new text and the KEEP and ARCHIVE matches remain for stated reasons. That result demonstrates a reviewed bulk replacement. It does not promise that the application understands prose; it proves that the human decisions were carried through without crossing the declared folder boundary.
Prove the Literal Workflow Before Introducing a Pattern
The fixed token is intentionally simple. Use it to prove folder scope, review labels, the one-item canary, and reverse search before introducing a regular expression. A pattern adds capture groups, boundaries, and escaping rules; it should not also be the first test of recovery. Preview the complete match and replacement, not merely the number of matches.
When a production pattern is approved, preserve the exact expression and engine options beside the five-column review sheet. If the preview returns the same line twice or widens into an excluded path, reject it before applying any change.
Deliver the Five-Location Diff
The handoff should show before and after text for all five locations. Three rows change, while the quotation and archive rows remain byte-for-byte stable. Include file digests so the table cannot accidentally describe an earlier copy.
A second reviewer then repeats the selected-folder search and the workspace-wide search. Their expected old-text counts are one and two respectively. Matching those nonzero values, with reasons, is a stronger receipt than a generic “replace completed” message.