Reverting changes

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

  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 shows the version number and when it was closed.
  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.

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 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:

  1. VibeMap captures the current state as a new closed changeset attributed to you (source = "revert"). This is your safety net.
  2. It loads the snapshot for vN and replaces all in-scope content with it.
  3. The timeline now shows your former current state as the version below the newly-restored one at the top.
  4. 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 v13 to something like "Pre-revert: tried v12 features" so you remember why it exists.

Common scenarios

SituationWhat to do
The AI rewrote something I likedFind the version just before the AI regeneration (look for the AI badge), revert to it.
I want to compare two approachesRevert to the old version, review, then revert forward to your new work (waiting in the timeline as "captured before revert").
I deleted something by accidentRevert to any version from before the delete — the entity comes back.
I want a clean slateRevert 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 revert attributed 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