Reverting changes
On this page
Reverting changes
Roll the whole project back to any earlier version with one click — safely, because your current state is always kept. · Optional
Use this when a regeneration overwrote work you liked, an agent change broke a careful arrangement, or you just want to compare two directions. Reverting is safe to try: it never throws anything away.
The core promise: reverts are non-destructive
Reverting never deletes your current work. It restores an older version's state and keeps your current state in the timeline as a new, separate version. You can always revert forward to where you were.
Because of this, there's zero risk in trying a revert — if you don't like the result, revert to the "captured before revert" version and you're exactly back where you started.
How to revert
- Open the History tab.
- Find the version you want to restore. Use the actor badges, titles, and timestamps to identify it.
- Click Revert on that version's card.
- A confirmation dialog shows the version number and when it was closed.
- Click Revert to vN to confirm (or Cancel to back out).
The revert runs server-side and takes a few seconds. When it finishes, the editor refreshes to the restored state.

What gets restored
Reverting replaces every in-scope asset with the chosen version's state:
- Features, user stories, acceptance criteria (full text, priority, complexity, sprint assignments)
- Personas (all fields)
- Pages, sections, page links
- Schema tables, columns, and access rules
- Business case and financial analysis
- Colour schemes, project context additions, and the project prompt itself
Entities that existed in the target version are restored; entities created only after it are removed; entities whose content changed are rewound to the older content.
What a revert does not touch
- Account and billing — plan, seats, payment method are unchanged.
- Team membership — members and roles stay as they are.
- API keys — personal access tokens are unaffected.
- File structure and pseudocode — currently outside VC scope.
- Uploaded reference files — stored separately.
- Embeddings — semantic-search indexes regenerate automatically after a revert (up to a few minutes); RAG features may be briefly stale but self-heal.
What happens step by step
When you click Revert to vN:
- VibeMap captures the current state as a new closed changeset attributed to you (source = "revert"). This is your safety net.
- It loads the snapshot for
vNand replaces all in-scope content with it. - The timeline now shows your former current state as the version below the newly-restored one at the top.
- Embeddings regenerate in the background.
A typical timeline after a revert:
v14 (you) Revert to v8 — current
v13 (you) Captured before revert ← your old current state, safe
v12 (AI) Generated additional features
...
v8 (you) Stable: pre-schema-rewrite ← what you reverted to
💡 Tip: Rename
v13to something like "Pre-revert: tried v12 features" so you remember why it exists.
Common scenarios
| Situation | What to do |
|---|---|
| The AI rewrote something I liked | Find the version just before the AI regeneration (look for the AI badge), revert to it. |
| I want to compare two approaches | Revert to the old version, review, then revert forward to your new work (waiting in the timeline as "captured before revert"). |
| I deleted something by accident | Revert to any version from before the delete — the entity comes back. |
| I want a clean slate | Revert to v1 (genesis) to wipe back to the first generated state; current work is still preserved. |
Edge cases
- Edits in progress. If you revert while the AI is mid-generation or a teammate is editing, the in-flight work completes first, lands in the "captured before revert" version, then the revert applies. Nothing is lost.
- Team workspaces. Reverting affects the whole project for everyone, not per-user. Coordinate before reverting if a teammate is actively editing — the safety net still applies, but their view will jump.
- "No snapshot" versions. You can't revert directly to a version marked read-only; pick the nearest later version with a Revert button (differences between adjacent versions are usually tiny).
- Reverting a revert. Fully supported — each revert is itself a versioned changeset, so you can roll backward and forward as many times as you like.
When not to revert
Some things are cleaner via the conversational agent than a full revert:
- Undo one specific change in a larger changeset → ask the agent: "Restore the description of the User Registration feature to what it was yesterday." A revert brings back the whole project.
- Merge two versions (schema from v8, personas from v12) → there's no built-in merge; revert to v8, then ask the agent to regenerate just the personas.
⚡ Power-user hints
- Verify after reverting. Spot-check the entities you cared about (Features, Personas, Schema), then confirm the top of the History timeline is a
revertattributed to you with "captured before revert" right beneath it. If anything looks wrong, revert again to that safety version. - Reverts are a free scratchpad. Because nothing is destroyed, treat revert as a way to browse old states, not just restore them.
↔ The traditional way
Rolling back a hand-managed spec means digging through document version history or a backup and manually undoing changes — risky, and often lossy. Here it's one click, the whole project rewinds atomically, and your current state is preserved automatically, so "undo" is never a gamble.
What's next
- Conversational agent → — for targeted, single-entity rollbacks in natural language.
- Team workspaces → — how history behaves across teammates.