Finder tags can classify manuscript files without moving them, but only when each tag answers one question. The controlled set contains twelve files: six for each of two works. It uses one work tag, one stage tag, and one review-state tag per file. When a stage changes, the old stage tag is removed before the new one is added. Tag retrieval never changes the file’s original project folder.
Fix the three axes as work, stage, and review state
The work axis uses Work A and Work B. The stage axis uses Drafting, Proofreading, and Submission. The review axis uses Needs Review and Reviewed. Include the axis in every tag name so one color never carries two meanings.
Each file normally has one tag from each axis. The goal is to answer which work, current stage, and review state—not merely to accumulate three colors.
Classify twelve files without moving them
Each project folder contains four manuscripts, one reference file, and one cover candidate. Apply Work_A to six and Work_B to six while the files remain in their original folders.
Moving everything into one tag-oriented folder could disrupt existing paths and organization. Tags are an additional classification surface, not a replacement tree in this article.
Keep only the current stage tag
The specimen distributes files across Drafting, Proofreading, and Submission. Do not preserve old stage tags as history. A file carrying both Drafting and Proofreading appears in two active queues and stops answering its current state.
Keep history in a separate record if needed.
Treat Needs Review as a temporary instruction
Apply Needs_Review to the file awaiting a name check, the file awaiting a figure replacement, and the colophon-date file. When each question is resolved, remove Needs_Review and apply Reviewed.
A file with both states is contradictory and must be repaired before tag retrieval can be trusted.
Remove the old stage before applying the new one
For Work A chapter 2, remove Stage_Drafting, then apply Stage_Proofreading. Confirm that Work_A and its review-state tag remain while exactly one stage tag exists.
The order avoids a visible intermediate state with two active stages. In multi-selection, change only the intended axis.
Use multi-selection only for a shared meaning
When four Work B manuscripts all enter proofreading, select the four, remove Drafting, and apply Proofreading. Preserve Work_B. Do not bulk-change review state because it can differ per file.
Batch tagging is useful only when every selected file receives the same semantic value.
Return from a tag view to the original path
A Work_A tag should retrieve six files; Proofreading can retrieve files across projects; Needs_Review retrieves three candidates. After opening one, confirm its original project path and save it there.
A tag view is not a copied folder and does not change file ownership.
State Rune Studio Finder-tag support concretely
Rune Studio documentation describes Finder-tag display and operations in the file tree, a tag sidebar in the independent browser, and attaching or detaching multiple tags.
A hands-on check with a disposable copy attached two Finder tags to one file and confirmed the same pair in the file information and the tree’s tag display. Both assignment and a second readback succeeded.
The tag sidebar, keep-the-menu-open interface, Finder screen, and twelve-file three-axis specimen were not observed. The application does not decide whether the classification policy is correct.
Respect the independent-browser operation boundary
Documentation also says the main lightweight tree is dimmed and disabled while the independent browser is open, reducing simultaneous file operations from two surfaces. Concentrate tag changes in the browser and check the main tree after closing it.
Treat tag name as identity and color as assistance
A blue dot alone loses meaning outside the current memory. Include axis and value in the tag name, then use color as a secondary cue. Distinguish same-color tags by name.
Do not confuse tag removal with file deletion
Removing Stage_Drafting changes metadata; it should not move the command into Trash or delete the file. After removal, confirm the original path opens and the work and review tags remain.
Check one tag-sidebar axis at a time
View Work_A, Proofreading, and Needs_Review separately, then compare candidates with the three-axis table. Documentation supports a Finder-tag sidebar; do not invent a Rune Studio guarantee for complex saved AND searches.
Confirm the same tag name in Finder when needed
Because these are Finder tags, open the original file in Finder to verify the same tag name. This checks attached metadata, not identical sorting or every search result between applications.
Use six files per work as the first baseline
Fix the six Work_A and six Work_B file names. A tag-sidebar result of five or seven reveals a missing or cross-project assignment. Work tags remain stable when stage changes.
Move stage counts by equal subtraction and addition
Moving chapter 2 from Drafting to Proofreading decreases one stage count and increases the other while the twelve-file total stays constant. A missing new tag produces an eleven-file stage total.
Resolve Needs Review before Submission
Check that Needs_Review is absent before applying Submission. Resolve the named question, switch to Reviewed, and only then apply the stage. This is a human workflow rule, not an automatic application gate.
Keep one row of remove-and-apply history
Record the date, file, removed stage, and applied stage for chapter 2. Tags continue to show current state while the row explains how to reverse an accidental change without implying that other axes changed.
Audit twelve rows for contradictions
Read file name, work tag, stage tag, and review tag. Repair a missing work tag, two stage tags, or simultaneous Needs_Review and Reviewed. Completion means all twelve files answer one value per axis.
Try remove-then-apply on the controlled set and review the documented Finder-tag and browser scope on the Rune Studio product page. Move folders or redesign the tree only in the folder-tree organization guide.
