Testing saved versions and live switching

Use a disposable world owned by your account. Keep it below the automatic-history limit while checking row counts. Publication checks require the normal review flow, or an account permitted to publish immediately. A review submission is not evidence that the content has gone live.

This version history stores world content, cover, and age rating. Listing details such as the title and tags remain independent. These tests do not roll back application code, ownership, permissions, or existing player conversations.

The editor's Save button persists the working draft. Automatic version rows are created when content is submitted through Publish or the publishing update flow.

One saved version per changed update

1. Save a world containing an opening marked A, a recognizable variable value, and a cover. Open Versions / Version history from the editor's toolbar or ⋮ menu, and note the automatic-history row count.
2. Change the opening and variable to unique B values and save the draft. Submit B through Publish or the publishing update flow. Reopen history. There should be one new Saved version for B, without an extra backup of A or a separate live-copy row.
3. Repeat the update without changing content, cover, or rating. Confirm there is no duplicate automatic row. A title-only or tag-only edit should not create a content version, since those fields are independent listing data.
4. Save a manually named version of B. It should occupy a named-version slot and remain distinct from the automatic B entry. Repeating an automatic save must not convert, rename, or consume that manual entry.

Approval updates the same saved row

1. Edit the world to contain a unique content change and click Save. This persists the draft; a new automatic version is not expected yet.
2. Submit the content for review through Publish or the publishing update flow. While review is pending, note the submitted version's ID from the response to GET /api/worlds/:worldId/versions in the browser's Network panel. It should show Not published.
3. Update the pending review without changing content, cover, or rating. Reopen history and confirm that the same automatic version ID is reused, with no duplicate row.
4. Complete approval through the normal review flow. Reopen history and confirm that same ID now shows Currently live. Approval must not add a separate published row or a backup of the outgoing live content.
5. Publish a newer unique version. The earlier published entry should now show Previously published. Both rows still use the Saved version title; publication is indicated by the status.

For an account that skips review, record the row count before publishing a unique change, then verify that the action creates one automatic row marked Currently live. There is no pending interval in which to inspect its ID before approval; use an account requiring review for the same-ID checks above.

If the cover or rating changes during submission, the submitted material is a different version. Record that new ID before approval and verify that approval marks the same submitted row live. Repeating an identical submission should not add another automatic record.

Restore a draft and switch the live release

1. Publish A, then publish B, completing any required review. Save a newer working draft C. Use fresh play sessions when checking public content; existing sessions continue with their starting world version.
2. Change the listing title and tags to recognizable new values. These values must remain unchanged throughout both recovery operations below.
3. Choose Make live on eligible previously published A. If an update review is pending, withdraw it first. The public world and a fresh play session should use A's content, cover, and rating. Reload the editor: C must still be the working draft. Switching must not add an outgoing B backup row.
4. Choose Restore to draft on B. Leave Save current state as a safety snapshot first checked. The editor should recover B's content, cover, and rating, while the public world remains A. Confirm C remains recoverable from history; a new restore safety copy is titled Backup before restore.
5. Repeat a restore with the safety option unchecked on a disposable draft. Confirm it does not create a restore safety copy. Only disable the option when discarding that current draft is intentional.

Retention and restrictions

• Automatic saved versions and restore backups share a 20-record limit. Check that older automatic entries are pruned as unique versions exceed the limit. Named versions have their separate 10-version limit and remain unaffected by automatic pruning. Existing history is not removed solely to change its wording or merge old duplicate records.
• Named versions and never-published content cannot bypass review using Make live. Restore them to the draft and use the normal publish flow.
• A world must currently be published before switching its live version. A pending review must be withdrawn first. If moderation takes down a world and it is later approved again, versions from before that approval cannot be made live directly.
• After a failed or interrupted save or publication request, the UI must not claim confirmed success. Reconnect and refresh history before retrying when the response is uncertain; the server may already have committed the request.
• Read the history in all five UI languages. Saved-version titles and publication statuses should be distinct, and switching confirmation must not promise a new backup of the outgoing live version.

This guide is an acceptance procedure. Source changes and local tests do not establish that a deployment, moderation action, or actual model session has already been verified.