> ## Documentation Index > Fetch the complete documentation index at: https://docs.avocadostudio.dev/llms.txt > Use this file to discover all available pages before exploring further. # Review, undo and versions > Four different ways back — undo, revert, version history, and removing a single change from last week — and when each one is the right tool. Nothing in the editor is a one-way door. There are four ways back, and they are genuinely different tools, not four names for the same button. ## The approval gate: before it happens Ordinary edits apply straight away, because undo is one click. **Destructive ones do not.** Deleting a page, removing blocks — those stop and show you the plan with two buttons, **Apply changes** and **Discard**, and nothing happens until you choose. This is the only place in the editor where you are asked to confirm something, which is deliberate: a confirmation on every action trains everyone to click through confirmations. ## Undo: the last thing **Ctrl+Z** (**Cmd+Z** on a Mac), or the undo button above the composer. **Ctrl+Y** redoes. Each message in the chat also carries its own **Undo** on the change it produced, which is what you want when you have made three edits and only the second one was wrong. Undo is recorded on the server. It survives a page reload, a browser restart, and coming back tomorrow — it is not a browser-level undo buffer. Undo history is deep but not infinite: **50 steps per page, per direction.** Each page keeps its own stack, so undoing on `/pricing` never disturbs `/about`. ## Version history: a list of everything The **Version history** panel in the header is the full record: every change, in order, newest first, each one saying which page it touched and how many operations it was. The most recent entry is marked **Current**. Three things you can do from it. ### Revert to this Puts the site back to how it was at that moment. Everything after it is undone. This is the "take me back to before lunch" tool. ### Discard individual changes Select one or more entries — anywhere in the list, not just the recent ones — and press **Discard**. That removes *those* changes and leaves the rest. This is the powerful one, and the one with a catch the panel states before you confirm it: > Rolls back 6 changes across 2 pages — later edits to those pages go too. Removing a change from Tuesday means everything on those same pages since Tuesday is rolled back with it, because the later edits were made on top of it. The panel tells you the totals before you commit. Some entries cannot be discarded at all — *"nothing is recorded before them"* — because there is no earlier state to return those pages to. ### See what a change actually was **Show details** expands an entry into the individual operations it contained, which is how you tell two similar-looking edits apart. The version log keeps the most recent **100 entries** per site. ## Published versions: going back after it went live Publishes appear in the version history too, marked **Live**, **Deploying…** or **Failed**, with a count of how many pages actually changed (*"3 of 9 pages changed"*) and a link to the deployment where your host provides one. Separately, Site settings holds **Version history** for *published snapshots* — a list of what the site looked like at each publish, which you can **Restore**. Use the in-editor version history to undo editing work; use snapshot restore to put the *live site* back to a previous published state. ## Which one do I want? | Situation | Use | | ------------------------------------------------- | ---------------------------------------------- | | It just did something wrong | **Undo** (Ctrl+Z) | | The third message of five was wrong | The **Undo** on that message | | I want the page back to how it was this morning | **Revert to this** in version history | | One change from Tuesday has to go, the rest stays | **Discard** that entry — read the warning | | We published something wrong and it is live | Publish snapshot **Restore**, in Site settings | | It is about to delete something | Just press **Discard** on the plan | ## Feedback on a bad result Every assistant message carries **Good response** and **Bad response** buttons, and the bad one takes an optional note. That is not a support ticket — it is the record the planner's prompts get tuned against, so a specific note (*"kept rewriting the heading I told it to leave alone"*) is worth more than a rating. ## What to read next Choosing what goes live, and restoring a published snapshot when it should not have. Why the live site looks unchanged, and where your work is held.