Reverting Changes

If something gets edited that you wish you hadn't — a regeneration overwrites work, the agent makes a change that broke a careful arrangement, or you simply want to compare two design directions side-by-side — you can roll back the entire project to any earlier version with a single click. This page covers how to do it, what gets restored, and how to be confident reverting is safe.

The Core Promise: Reverts Are Non-Destructive

Before anything else, the rule that makes version control safe to use:

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 back to where you were.

This means there is no risk in trying a revert. If you don't like what you see, revert forward to the version that was current before you rolled back. You will be exactly where you started.

How to Revert

1. Open the History panel (Cmd-H / Ctrl-H).
2. Find the version you want to restore to. Use the actor badges, titles, and timestamps to identify it.
3. Click the Revert button on that version's card.
4. A confirmation dialog appears showing the version number and the timestamp it was closed at.
5. Read the summary, then click Revert to vN to confirm. Or click Cancel to back out.

The revert runs server-side and typically takes a few seconds. When it completes, the editor refreshes and you see the restored state.

What Gets Restored

Reverting replaces every in-scope project asset with the state from the chosen version:

• Features, user stories, acceptance criteria (full text, priority, complexity, sprint assignments, etc.)
• Personas (all fields, including detailed psychographics and journey data)
• Pages, sections, page links
• Schema tables and columns, access rules
• Business case
• Colour schemes
• Project context additions
• The project prompt itself

Entities that existed in the target version are restored. Entities that existed only after the target version (i.e. were created later) are removed. Entities whose content changed are rewound to the older content.

What is NOT Touched by a Revert

Some things sit outside the version-controlled content and are unaffected:

• Your account and billing. Plan, seats, payment method — none of this changes.
• Team membership. Members and roles stay exactly as they are.
• API keys. Personal access tokens are unaffected.
• File structure and pseudocode. Currently outside the VC scope.
• Uploaded reference files. Stored separately.
• Embeddings. Semantic-search indexes are regenerated automatically after a revert — this can take up to a few minutes. During that window, semantic features (RAG-enhanced generations, search) may be slightly stale, but they self-heal.

What Happens Step by Step

Concretely, when you click Revert to vN:

1. VibeMap captures the current state as a new closed changeset, attributed to you, source = "revert". This is your safety net.
2. VibeMap then loads the snapshot for vN and replaces all in-scope content with that snapshot's data.
3. The History timeline now shows your former current state as the previous version, with the newly-restored state at the top.
4. Embeddings are regenerated in the background.

So a typical timeline after a revert looks like:

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

You can rename v13 to something like "Pre-revert: tried v12 features" so you remember why it exists.

Common Revert Scenarios

"The AI rewrote something I liked"

The AI regeneration replaced careful manual edits. Open History, find the version just before the regeneration (look for the AI actor badge on the most recent version), click the version above it, then click Revert.

"I want to compare two approaches"

You spent an hour rebuilding features in a new direction. You want to compare against the old direction. Revert to the old version, screenshot or review, then revert forward to your new work (it will be sitting in the timeline as the "captured before revert" version).

"I deleted something I didn't mean to"

Find any version from before the delete and revert to it. The deleted entity comes back.

"I want a clean slate"

Revert to v1 (genesis) to wipe back to the very first generated state. Your current work is still preserved in the timeline.

Edge Cases and Things to Know

Reverting When Other Edits Are In Progress

If you click Revert while there are in-flight edits — for example the AI is mid-generation, or a teammate on the same project is editing — the in-flight changes complete first, then the revert applies. The freshly-completed work ends up in the "captured before revert" version, so it is still recoverable.

Reverting Across Teammate Edits (Team Workspaces)

In a team workspace, every member's edits show in the same timeline. Reverting affects the whole project for everyone — it is not per-user. The timeline makes it visible which versions are yours and which are teammates'.

Coordinate with your team before reverting if anyone is actively editing. The safety net of "current state captured first" still applies, so no work is lost, but a teammate mid-edit will see their work jump if they don't realise a revert happened.

Reverting to a Version Marked "No Snapshot"

If you see "No snapshot — read only" on a version, you cannot revert directly to that exact point. Pick the nearest later version that has a Revert button instead. For most use cases this is functionally identical — the differences between adjacent versions are typically tiny.

Reverting a Revert

Yes, you can revert a revert. Each revert is itself a versioned changeset in the timeline, so you can roll backward and forward as many times as you want. There is no penalty.

When NOT to Revert

Some situations are better solved with the conversational agent than a revert:

• You want to undo one specific change in a larger changeset (e.g. just one feature edit, not all of them). Reverting brings the whole project back. Instead, ask the agent: "Restore the description of the User Registration feature to what it was yesterday." The agent can read the history and propose a targeted change.
• You want to merge two versions — e.g. keep schema from v8 but personas from v12. There is no built-in merge today. Workaround: revert to v8, then ask the agent to regenerate just the personas based on your current spec.
• You want to undo a feature that has dependent acceptance criteria. A revert handles this correctly, but if you only want to remove one feature, deletion via the UI or agent is cleaner.

Confirming a Revert Was Safe

After a revert:

1. Spot-check the entities you cared about — open Features, Personas, Schema — and verify they look like the older version.
2. Open the History panel. The version at the top should be a revert source attributed to you. The version below it ("captured before revert") preserves what you came from.
3. If anything looks wrong, revert again — to the "captured before revert" version. You are back where you started.

Coming Soon

The team is actively working on these enhancements:

• Partial revert — restore a single entity (e.g. just one feature) from an old version without affecting the rest.
• Field-level diffs — see exactly which fields changed in an update, with before / after side-by-side.
• Side-by-side compare — pick two versions and view a structured diff between them.

If any of these would make a real difference to your workflow, let us know via the in-app feedback form or support@vibemap.ai.

Next Steps

• Conversational agent — for targeted single-entity rollbacks via natural language.
• Team workspaces — how history works across teammates.