cms undo: destroys the entry instead of reverting the last commit — data loss on main

[JonasJesus42]

What happened

Authoring the Cuida home on a live account. After a push I wanted to go back one commit, so I used the command push itself advertises for exactly that:

✓ commit 04b5905e-457d-4afe-b110-f68741cf2e5d on main
  rollback: parity cms undo --entry 96c92d7c-… --branch main

Dry run was reassuring:

dry run — would drop 96c92d7c-… changes on main. Pass --yes.

With --yes --allow-main:

✓ 96c92d7c-fd02-44fd-b17d-9ad47625a13b reverted on main

The next read:

GET …/landingPage/entries/96c92d7c-…/last-version?branchId=main
-> 404 {"error":{"code":"ENTRY_VERSIONS_NOT_FOUND"}}

The entry was gone — not reverted. It disappeared from parity cms ls and from GET /manage/{account}/entries (44 entries where there had been 45). A live page went from rendering to empty and there is no CLI path back.

Why it is worse than it sounds

• The wording promises a revert. undo's own help says "Drop an entry's changes on a branch — the platform's own rollback", and push prints it as rollback:. Nothing suggests "delete every version of this entry".
• The dry run says "would drop … changes", which reads as the changes, not the entry.
• On an entry whose history is a single commit — which is every entry parity cms create has made — "drop the changes" and "destroy the entry" are the same operation. That is precisely when someone reaches for it.
• --allow-main is the only guardrail, and it is the same flag push needs, so it is already in the caller's muscle memory.
• push writes a backup before committing; undo writes none. The pre-push backup happens to hold the content, but only if a push preceded it.

Suggested fix

1. Rename or re-scope. If the platform endpoint (.../entries/{id}/undo) really deletes, then this is parity cms delete, not undo, and push should not advertise it as rollback:.
2. Make the real rollback the real rollback. push already saves parity-output/cms-backups/<entry>-<hash>.json. The advertised rollback should be "re-push that file", which is non-destructive and idempotent.
3. Refuse when it would destroy. If the entry has one version, undo is a delete — require --allow-delete on top of --allow-main, and say so in the dry run: "this entry has 1 version; undo will remove the entry itself".
4. Back up before undoing, same as push does.

Repro

export PARITY_CMS_ACCOUNT=<acct> PARITY_CMS_STORE=<store>
parity cms create --content-type landingPage --slug /scratch --branch main --allow-main --yes
parity cms undo --entry <new-id> --branch main --allow-main --yes
parity cms ls | grep <new-id>   # gone

[JonasJesus42]

Contexto: o undo aqui foi acionado para reverter um push cuja página tinha ficado vazia — causa raiz agora identificada na #349 (formato {values} vs array, não o conteúdo). Ou seja, o undo destruiu a entry num cenário em que o push estava recuperável por um simples re-push no formato certo. Reforça a proposta 2: o rollback anunciado devia ser "re-empurre o backup", nunca este comando.