A manuscript can be due this week and still be waiting for copyediting. Putting it in two folders would create duplicate sources, but tags can express both workflow states without changing its location. If your query is “organize files with tags text editor,” the safe answer begins with a controlled two-tag test: attach Red and Blue to one chapter, remove only Red, and find the unchanged chapter through Blue. The decisive evidence is the surviving tag, file path, and content hash—not an assumed screen color.
Give Every Tag One Operational Meaning
Start with a small tag dictionary. “This week” describes a deadline; “Copyedit” describes a production stage. Avoid near-synonyms such as “Urgent” and “This week” unless the team has written a rule that distinguishes them. Colors may help recognition, but a handoff should name the tag in text so that its meaning does not depend on a particular display.
Freeze the target before editing metadata. In the controlled copy used here, only chapter.md was in scope. Its relative path and content SHA were recorded at the start. No body edit, rename, or folder move was permitted during the tag test. If reference notes and images also need classification, list each file type separately before expanding the operation.
Attach Two Tags, Then Remove Just One
The test attached Red and Blue to chapter.md and read the stored tag array. It then removed Red and read the array again. The acceptance rule had two independent parts: Blue must remain, and Red must be absent. If both disappear, the removal scope or selected metadata field was wrong.
In production, adding and removing labels may feel like one action, but preserve two checkpoints. The list after addition proves that both labels reached the intended file. The list after removal proves that only the rejected label left. Complete this round trip on one canary file before applying the same decision to a larger selection.
Search Blue and Recover the Same File
A surviving value in the metadata array is useful, but it is not the complete retrieval test. Search by Blue and inspect the returned record. In this run, the query returned one chapter.md; its relative path and content SHA matched the starting values. The measured conclusion is therefore narrow: one tag survived and could retrieve the original, unchanged file.
Zero results suggest that the retained label was removed or the query used a different name. More than one result may be correct, but every extra path needs an explanation. Do not adjust the expected number after seeing the output. Map each result back to the target list and decide whether it was intentionally included.
For a larger project, preserve the query itself as part of the evidence. Record the exact tag name, workspace root, included folders, excluded folders, and execution time. A later query can then be compared with the same boundary. If a new chapter legitimately carries Blue, update the approved target list before rerunning the test instead of treating the larger result as unexplained noise.
Separate Browser Appearance From Stored State
Rune Studio’s public product information describes workspace organization through a tree, tabs, and tags. The controlled command record for this article observed the stored tag array, the tag search result, the relative path, and the content hash. It did not measure which row appeared selected in the independent browser or how Finder rendered a tag color.
That distinction prevents a visible-looking success from becoming unsupported evidence. A later interface test should record the app version, browser opened, query label, selected row, and a screenshot after the action. Pass the saved-state check and the visual-interface check independently; neither result substitutes for the other.
Do Not Treat Tagging as a Folder Move
Tags add another route to a file. They do not relocate the authoritative manuscript. Comparing path and SHA before and after the operation confirms that no rename, move, or body edit was smuggled into the classification task. This is especially important when several views expose the same file under different labels.
If the real job is to reorganize folders, use a separate migration test. Moving a Markdown file or image can require inspection of relative links and image references. Those checks answer a different question and should not be folded into this tag acceptance rule. One operation per test keeps recovery understandable.
Recover From Removing Both Tags
If Blue disappears with Red, identify the intended file by its relative path and starting SHA. Reattach Blue to that single file, read the tag array, and run the Blue query again. Avoid a broad bulk action during recovery; it can attach the label to files that were never part of the approved set.
If the query returns a similarly named file, use the complete relative path rather than the basename to distinguish it. A changed content SHA means that an unrelated edit occurred, so the old tag result should not be approved. Resolve the manuscript difference first, record a new starting value, and repeat the metadata test.
Hand Off Names, Paths, and the Surviving Result
The handoff row should contain the target path, starting SHA, two added tags, one removed tag, one retained tag, and the retrieval count. The fixed result here is concise: after Red was removed, Blue remained; a Blue query returned the same chapter.md; and both path and content SHA stayed unchanged.
When several people maintain the workspace, add the operator and the tag-dictionary revision to that row. This reveals whether an apparent data problem is actually a change in team vocabulary. Retire obsolete labels explicitly; do not silently reuse an old color for a new meaning, because saved files may still carry the earlier label.
Mark the independent browser’s selection appearance and tag colors as unmeasured. The next operator can reproduce the one-file test before widening the selection. Tags are safe when they add classification without silently changing the source’s location or text, and when every remaining result can be explained by name and path.