Open multiple manuscripts by stable file ID and editorial role, not by whichever heading happens to be visible. In a 12-chapter project, the useful trio might be C03.md for setup, C07.md for the turning point, and C11.md for payoff. Record that order so the same desk can be rebuilt after the tabs are closed.
Chapter titles are reader-facing and may change during revision. File IDs are working addresses. When two chapters temporarily share a heading, C03 and C07 still identify different sources.
Define the three-tab desk
Keep the manuscript files under chapters/, from C01.md through C12.md. Before opening anything, write a short role map:
C03.md— setup — open first.C07.md— change in the relationship — open second.C11.md— payoff — open third.
This order follows the question being reviewed, not alphabetical browsing. It also gives every tab a reason to remain open. Reference material that does not serve one of the three roles belongs in another pane or should be opened only when needed.
Open and verify the initial state
Expand the chapter folder or search for the IDs. Open C03, C07, and C11 in that order. Then inspect the tab list and read the ID inside each file. A matching heading is not enough when headings are repeated.
Copy the full paths into a revision note:
chapters/C03.md → chapters/C07.md → chapters/C11.md
If the tabs appear in another order, fix the order before beginning the comparison. Otherwise a note such as “the middle tab” will point to a different chapter the next time the desk is built.
Test whether the desk is reproducible
The return test is a separate operation:
- Settle any unsaved changes in the three manuscripts.
- Record each ID, path, role, and current tab order.
- Close all three tabs.
- Locate the files again from the tree using ID or path.
- Reopen C03, C07, and C11 in the recorded order and verify their internal IDs.
Passing the first opening does not pass the return test. The files must have been closed before the second tab list can demonstrate recovery.
What the close-and-reopen test showed
In the recorded 12-chapter workspace, C03, C07, and C11 were opened in that order. All tabs were then closed as C11, C07, C03. After a workspace reload, the files were reopened as C03, C07, C11. The second tab order matched the first, and content readback returned ID-C03, ID-C07, and ID-C11 from the corresponding paths.
Rune Studio's current Mac documentation describes its file tree, opening multiple selected files, tab reordering, and an overflow tab list. Those capabilities fit the initial desk-building part of this method. Current product information is available on the Rune Studio website.
Keep visual state and automatic restoration separate
The measured result is a manual reconstruction by ID and path. Tree clicks and the visual current-tab indicator were not observed. The test also does not show that an application relaunch automatically restores the previous session; automatic restoration is a different promise from reopening known files.
Run the five-step return test once on a copy through the interface you use. Confirm that repeated headings do not hide a path mismatch. If you also expect the arrangement to survive an application relaunch, test relaunch separately and do not treat this manual result as evidence for it.
A decision rule for adding more tabs
Add a fourth tab only if it has a named role in the current question. If the role cannot be written in one phrase, leave the file closed and use tree search when it becomes relevant. This keeps the three manuscript tabs visually stable and makes the recorded order meaningful.
The goal of a file tree is not to display the largest possible hierarchy. It is to let you reconstruct a precise working set. When the initial and reopened lists both read C03, C07, C11—and each file still serves setup, change, and payoff—the tree has preserved the organization that matters.
For current details about opening multiple files from the Mac file tree, visit the Rune Studio product page.
