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 little risk in trying a revert — if you don't like the result, revert to the version sitting directly below the revert entry and you're exactly back where you started.

How to revert

1. Open the History tab.
2. Find the version you want to restore. Use the actor badges, titles, and timestamps to identify it.
3. Click Revert on that version's card.
4. A confirmation dialog — "Revert to vN?" — shows when that version closed and, in red, exactly what was created afterwards and will therefore be removed ("3 features", "12 user stories"). If nothing would be lost it says so.
5. 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.

Figure: Revert confirmation.

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 aren't part of a snapshot, so restored content is re-indexed the next time it's written or regenerated. Search and RAG features can be briefly stale after a revert.

What happens step by step

When you click Revert to vN:

1. Any changeset still open is closed first, which snapshots it. That's what makes work from the last few minutes safe rather than overwritten — and if that close fails, the revert is refused instead of risking it.
2. VibeMap loads the snapshot for vN and replaces all in-scope content with it.
3. A new version appears at the top of the timeline, attributed to you and titled "Reverted to vN", with its own snapshot of the restored state.
4. Your pre-revert state is the version directly beneath it — an ordinary closed changeset with an ordinary snapshot, which is exactly why you can revert forward into it.

A typical timeline after a revert:

v14  (you) Reverted to v8              ← current
v13  (you) Direct edits                ← your pre-revert state, still revertable
v12  (AI)  Generated additional features
...
v8   (you) Stable: pre-schema-rewrite  ← what you reverted to

💡 Tip: Rename the top version before you revert — "Stable: about to try v8" — so the entry you may want to come back to is obvious rather than a generic "Direct edits".

Common scenarios

Edge cases

• Edits in progress. Recent work still sitting in an open changeset is closed and snapshotted before the revert runs, so it keeps its own recovery point rather than being overwritten. If that step fails, VibeMap refuses the revert instead of proceeding.
• 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 reads "Reverted to vN", attributed to you, with your pre-revert version right beneath it. If anything looks wrong, revert to that one.
• 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.