A replacement can be correctly approved at noon and unsafe at 12:05. The file may have acquired a new heading, a nearby sentence may have changed its meaning, or another match may have arrived elsewhere in the workspace. The decisive question is therefore not merely whether someone reviewed the result once. It is whether the approved context is still the same at the moment the write occurs.
For a text editor search replace review matches workflow, this article treats approval as an expiring execution ticket. The retained STUDIO-324 experiment starts with two matches, approves one manuscript occurrence, changes that manuscript's context, and then adds a third match in a new file. The old approval fails a digest check. Only after the changed manuscript is reread and approved against its new digest does one single-file replacement run. The quotation and new arrival remain open for different reasons.
This is not a bulk-replacement canary. There is no three-item approved batch followed by two protected exceptions. The unit of judgment is one ticket whose authority can expire between search and execution, while newly arriving work receives a separate ticket.
Give Every Search Result an Epoch
The initial query is Draft324. At epoch A, the controlled workspace contains two matches in two files. draft/chapter.md contains REVISE Draft324 in active prose. The reference file contains QUOTE Draft324 must remain. The command output, complete paths, excerpts, and file digests are saved together as the baseline.
An epoch is a named observation time, not a promise that the list will remain complete. If the same query is run later, its results belong to another epoch. This prevents a reviewer from treating a screenshot, exported list, or remembered count as a live queue after the workspace has changed.
The result count has a deliberately narrow role. It describes what the query returned at epoch A. It does not grant authority to replace either match, and it does not tell a later operator whether those same bytes still exist.
Bind the Approval Ticket to One File Version
The manuscript result becomes ticket C-01. Its record contains the relative path, heading Opening, surrounding sentence, query, requested replacement, and approval-time SHA-256. After reading those fields, the editor authorizes changing Draft324 to Final324 in that one sentence. The quotation becomes C-02 and is protected because it preserves cited wording.
Approval belongs to the complete record, not to the token alone. Another file can contain the identical token for a different reason. Even the same file can change meaning while retaining the token. Storing the digest turns that editorial distinction into an executable guard: the ticket is valid only while the current file digest equals the approved digest.
The ticket should also name the approver and the requested transformation in a production workflow. This fixture records the machine-verifiable identity fields and the decision state. A team can add names without weakening the central rule that a later file version requires a later approval.
Expire Approval When Context Drifts
After C-01 was approved, the heading in draft/chapter.md changed from Opening to Revised Context. The replacement sentence itself stayed visible, but the file digest no longer matched the approval-time digest. The freshness check recorded expected_sha != current_sha, set C-01 to STALE, and withheld execution.
This is a successful rejection. It does not say the revised sentence is wrong; it says the earlier reviewer did not approve this version. The operator must reread the new heading and surrounding text, then attach a new approval to the current digest before even the dry run proceeds.
A count-only test would miss this failure because the token can remain present once before and once after the contextual edit. Digest identity exposes the change without pretending that the digest can interpret prose. The human rereads meaning; the digest confirms which bytes received that judgment.
Open a New Ticket for a Newly Arrived Match
While C-01 was stale, inbox/new.md arrived with PENDING Draft324 needs separate review. The epoch B search returned three matches in three files. That new row became C-03 with status PENDING. It did not inherit C-01's approval merely because both rows contained Draft324.
This is the central queue rule. An approval applies to one identified occurrence at one approved file version. A later result has another path and another context, so it enters review at the beginning. Expanding the old ticket would silently turn a one-sentence decision into permission for text nobody had read.
The operator can still continue with C-01 while C-03 remains open. Safety does not require freezing the entire workspace until every match has the same status. It requires every write to identify its own current authority.
Replace Only the Reapproved Occurrence
The changed C-01 file was reread under Revised Context and approved against its new digest. A single-file dry run then proposed one replacement: REVISE Draft324 to REVISE Final324. The proposal matched the refreshed ticket, so the command applied exactly one change and the saved file was reopened.
The terminal searches found one Final324 occurrence and two Draft324 occurrences. The latter were C-02, the protected quotation, and C-03, the pending new arrival. Their survival is not defined by a predetermined exception total. It follows from the fact that neither ticket authorized a write.
This workflow never widens the command to “all current matches.” If C-03 is approved later, it will receive its own current digest and its own execution record. A separate ticket keeps the later decision reviewable even if its replacement text eventually matches C-01's.
Treat Freshness Violations as Failures Even When Counts Look Right
The dangerous failure is applying the old C-01 after the heading changed. The output might still contain one correct-looking Final324, but nobody approved the new context. A numerical result cannot repair that missing authority. Adding or removing another token to make a total match the plan would only hide the governance failure.
Recovery stops further writes and compares the approval-time digest with the current digest. A changed file is reread and receives a new ticket rather than having the old ticket revived. Every newly discovered path becomes a separate pending row. The failed attempt and its stale digest remain in the audit trail so another editor can see why execution was denied.
If the source changed after the dry run but before application, repeat the same gate immediately before the write. A production implementation can make that final comparison atomic. This fixture demonstrates the decision boundary with retained files and hashes; it does not claim that a graphical dialog currently locks a file against concurrent edits.
Keep Graphical Confirmation in a Separate Record
Rune Studio's published materials describe search and confirmation-oriented replacement. The fixed cycle-8 evidence measures command-line searches, file digests, one single-file dry run, one applied write, and saved readback. It does not measure highlighted rows, the exact wording of a confirmation dialog, or a live concurrent-edit warning in the current graphical interface.
A future UI test should record the application version, epoch, displayed path, digest immediately before confirmation, proposed old and new text, and any warning shown after the file changes. A success message is insufficient if it belongs to a stale version. Conversely, correct saved bytes do not establish that the interface communicated the risk clearly.
Unsaved editor buffers also need their own identity. The retained fixture operates saved files on disk. It neither infers nor promises how an unsaved buffer participates in the query. That question remains separate from the digest gate demonstrated here.
Hand Off One Closed Ticket and Two Open Ones
The release receipt preserves epoch A with two results, C-01's stale transition, epoch B with three results, the refreshed digest, the one-item dry run and application, and the final values Final324=1 and Draft324=2. C-01 is APPLIED, C-02 is PROTECTED, and C-03 is PENDING.
Completion does not mean forcing every card closed. It means closing only the ticket authorized by this operation and leaving the quotation and new arrival open for their stated reasons. The next editor can begin with C-03 instead of reconstructing why an unexpected match survived.
Binding approval to an epoch and digest changes the practical meaning of “review before replace.” The review is current authority over a specific file version, not a permanent label attached to a word. That rule blocks a stale decision without turning search into a slow, workspace-wide freeze.