Versions and recovery

Mango9 records durable project changes as versions. Versions make completed work recoverable even when a later build needs another pass.

A version is a named point in the development history created from completed durable work. It connects the conversation result with the project state you can inspect later. Versions are not created merely because text appeared in Chat; they represent saved project changes.

Think of versions as safe milestones. You can keep building without treating every experiment as irreversible, while still reviewing a newer result before deciding whether it should replace a known good direction.

Example: Version 6 contains the approved checkout. Version 7 changes the visual style. If the new style is not right, you can return to the exact version 6 state instead of describing the old appearance from memory.

View what changed

A completion card can include a version badge and View changes. Use it to inspect the saved result associated with that build.

The System view provides broader version history and project operations where your role permits them.

Use View changes to answer a simple question: what durable project material did this turn alter? Pair that information with Preview, because a file list proves scope while the running app proves behavior and appearance. Neither view replaces the other.

Version badges also help when discussing a result with a teammate or support. Referring to “v8” is clearer than “the build from earlier,” especially when several prompts were sent on the same day.

Example: “Version 8 added the customer export and changed three files. The exported CSV works, but the button is too wide on mobile.”

Restore deliberately

Restore when:

• a later direction is no longer wanted;
• a broad design change replaced an approved layout;
• a defect was introduced and a known version is the safest baseline;
• you need to compare before rebuilding a feature differently.

Before restoring, note any valuable later work that will be removed. A restore changes the project state; it is not merely a preview.

First use View version when you only want to inspect an older state. Restore only after you are sure that version is the desired baseline. Mango9 creates a new current state from the selected history rather than silently rewriting what the old version meant.

If later work contains one useful feature, consider whether a focused repair is safer than restoring everything. Restore is best when the earlier version as a whole is the state you want.

Example: Restore v4 when v5 was an unwanted full redesign. Do not restore v4 merely because one button in v5 needs a small spacing correction.

Failed or advisory builds

A build may complete useful durable work while also reporting a follow-up issue. Review the actual preview and saved version before deciding to restore. A mechanical advisory does not always mean the running application is unusable.

If a build produced no useful result, retry the focused prompt or restore the last approved version rather than asking for a vague global cleanup.

Read the completion status, saved version, and Preview together. A build may save useful work and still report that one screenshot was unavailable. Conversely, a confident progress sentence does not prove a version was created. Durable evidence prevents both unnecessary rollback and false confidence.

Example: The card says Applied and shows v9, while visual proof reports one mobile advisory. Open v9 in Preview and check mobile before deciding whether any recovery action is needed.

Production rollback is separate

Development versions and production deployments are related but not identical:

• Project versions track development changes.
• Production deployments track releases sent to customers.
• Rollback in Production Cloud restores an earlier production release.

Restoring development does not automatically replace the live production app. Publish the desired development state when you are ready.

This separation protects customers from development experiments. You can restore, compare, and rebuild in Studio while the last approved production deployment remains live. Production rollback is used only when the live release itself must return to an earlier deployment.

Data needs separate care. Rolling code back does not automatically undo records created, edited, or deleted in an external production database. Use the database provider's recovery controls when the incident concerns data rather than application code.

Example: Restore development v12 to continue editing an older layout. Roll back Production Cloud only if customers must immediately return to the previous live deployment.

If you want an earlier known state, use the version or rollback control. Asking the model to “make it how it was” is less exact and may consume additional credits.