Chapter Forking
Authors don’t experiment with their prose as often as they should, and the reason is almost always the same: they’re afraid of losing work they care about. If you have a chapter you like and you want to try a radically different version — say, rewrite the climax from a completely different POV, or cut the subplot entirely and see how the chapter reads without it, or try the scene with the twist revealed early instead of late — the safe path is to copy the whole document somewhere, make your changes to the copy, compare the results, and throw one away. That’s annoying enough that most authors just don’t do it. The experiment doesn’t happen, the alternate version never gets drafted, and the manuscript stays whatever it happened to be in the first draft. Chapter forking is Ishvana’s answer. You fork any document, name the branch, edit the branch independently, compare it against the main version at any time, and promote whichever one you decide is better. No copy-paste, no manual version management, no fear of losing the original. Experimentation becomes cheap, which means it actually happens.
This page walks through how forks work, what operations are available, and the safety guarantees that make the whole thing trustworthy enough to use on real work.
Creating a fork
Section titled “Creating a fork”Two ways to fork:
- Fork button in the editor toolbar.
- Ctrl+Alt+F from anywhere in the editor.
Either one opens the Create Fork modal. Enter a branch label — something descriptive like “Version where the villain wins” or “POV switch to Kent” or “Cut subplot experiment.” The label is how you’ll identify this branch later, so be specific. “Version 2” is bad. “Third-person limited rewrite” is good.
Ishvana creates a full copy of the current document as a new branch. The original stays intact as the Main version. You can fork from Main, from any existing branch, or from a branch of a branch — the system supports arbitrarily deep nesting. Forks of forks of forks. It’s rare to need more than two or three levels in practice, but the system doesn’t limit you.
The fork tree panel
Section titled “The fork tree panel”The Forks panel lives in the right sidebar under the Branching tab. It shows the full tree for the current document:
- Virtual Main node at the top — your original document, with title and word count.
- Branch tree below — each branch displayed with its label, word count, creation date (relative, like “3 days ago”), and a status dot (green for active, gray for archived).
- Active indicator — the branch currently loaded in the editor is highlighted.
- Show archived toggle — reveal or hide archived branches in the tree view.
When a document has no forks, the panel shows a message suggesting you fork it to explore alternatives. This is deliberate — the panel is a gentle nudge toward experimentation without being in your face about it.
Switching between branches
Section titled “Switching between branches”Click any branch node (or the Main node) to load that version into the editor. Your current document is auto-saved before the switch — if the save fails for any reason, the switch is aborted so you never lose unsaved work.
A branch indicator chip in the editor toolbar shows which branch you’re currently on. Clicking the chip opens the Forks panel directly. You always know which version you’re editing, and you can see it at a glance without navigating to the panel.
Branch operations
Section titled “Branch operations”Right-click any branch in the tree for the operations menu:
Promote to Main
Section titled “Promote to Main”Copies the branch’s content into the root document, effectively saying “this version is better, use it as the real one.” The original Main content is automatically snapshotted first — so if you change your mind later, you can always go back. The promoted branch is archived after promotion (not deleted) so its history is preserved.
Archive / Unarchive
Section titled “Archive / Unarchive”Hide a branch from the default view without deleting it. Archived branches stay in position in the tree (dimmed) and can still have active children. Useful for preserving directions you’ve decided against but don’t want to delete — maybe you rejected an idea for this book but it might work for a future book, or you just don’t want the mental clutter of seeing abandoned branches every time you open the Forks panel.
Unarchive restores the branch to active state. The operation is always reversible.
Spin off as document
Section titled “Spin off as document”Detach a branch into a standalone document that appears in your main document list. The new document is titled {original title} — {branch label}. Any child branches of the detached branch are moved up one level in the tree (they don’t get orphaned).
This is the operation you use when a branch becomes its own thing — maybe your “alternate POV” experiment grew into a full companion story that deserves its own document rather than staying as a branch on the original.
Delete
Section titled “Delete”Permanently remove a branch and its content. Child branches are moved to the deleted branch’s parent — they’re never cascade-deleted. Confirmation required.
Delete is for branches you’re genuinely done with and don’t want in your history. If you might want to come back to it later, archive instead.
Rename
Section titled “Rename”Double-click a branch label to edit it inline. Enter to confirm, Escape to cancel. Useful when a branch you thought was an experiment turns into something real and needs a better name.
Compare with Main
Section titled “Compare with Main”Opens a comparison modal showing a unified diff between the branch and the Main version:
- Statistics header — additions (green), deletions (red), net word count change.
- Colored diff lines — green for additions, red for deletions, neutral for unchanged context.
- Truncation indicator when the diff is very large (above a certain length, the full diff gets clipped with an indicator).
Compare is how you decide whether to promote a branch. You see exactly what changed between the branch and Main, and you can make the call based on the diff rather than on vibes. The compare view is read-only — it’s a diagnostic view, not an edit surface.
Search integration
Section titled “Search integration”By default, fork branches are excluded from document search results. This is deliberate — if every search returned the Main version plus three branches plus two sub-branches for every fork in your project, the results would be unusable.
Toggle the Forks button in the search bar to include branches when you specifically want to find something across all versions. Useful when you remember writing a specific line but you’re not sure which version it was in.
How forking works under the hood
Section titled “How forking works under the hood”Each branch is a complete, independent document. It has its own content, its own version history, its own word count, its own entity detection, and its own entry in the search index. Editing one branch never affects another.
When you promote a branch, the content is copied into the root document’s existing ID — no IDs change, so all references from your outline, entity mentions, and other features stay valid. Your outline node that pointed to “chapter-8” still points to “chapter-8” after promotion, it just now contains the promoted content.
When forking actually helps
Section titled “When forking actually helps”A few real use cases, ordered by how common each is:
- POV experiments. You wrote a scene in third limited and you want to see what it feels like in first person. Fork, rewrite, compare, decide.
- Tonal experiments. A dark scene that might play better with a lighter tone. Fork, rewrite for tone, compare.
- Structural experiments. A chapter with three scenes — what if you reorder them? Fork, reorder, compare.
- Subplot cut experiments. A subplot you’re not sure about. Fork, cut it from the chapter, see how the chapter reads without it.
- Cliffhanger placement. The cliffhanger is in the middle of the chapter and you want to try moving it to the end. Fork, move, compare.
- Agent-heavy revision. You want to run Hawken’s edit pipeline on the whole chapter with a specific prompt, but you don’t want to apply the suggestions to the canonical version yet. Fork, run the revision on the branch, compare against the original, and keep whichever reads better.