Abandon and restore a change

tovio change abandon chg:a3f7b2

Sets a change aside. It disappears from tovio change list, and it will not land or be proposed — either attempt is TVO-OP-012, refused before any ref advances or any Forge call is made. Nothing is deleted: the commits stay in history and the objects stay in the store.

It is reversible

tovio change restore chg:a3f7b2

Brings it back, landable again. Abandoning is a local op-log state change, not a deletion, and garbage collection is op-log-aware: it will not reclaim anything undo could still restore.

An abandoned change is hidden from the human listing but still present in tovio --json change list, flagged "abandoned": true — which is how you find one whose id you have forgotten.

Abandon rather than delete

This is the safe way to shelve work you think you do not want. Compare with tovio restore <file>, which discards uncommitted edits to one file and records no op-log entry — that one genuinely cannot be undone.

Agent lanes

tovio agent abandon agent/<name>/<sub>

Tombstones an agent lane — the usual way to discard a run that went in the wrong direction. Its objects stay reachable in history; none are orphaned. If a bare agent name maps to more than one live lane the command refuses with TVO-CLI-015 and asks for the full lane path.

Actually removing content

tovio obliterate <object-hash> --confirm 'obliterate <object-hash>' --reason '...'

If a payload must genuinely be gone — a leaked secret, a legal obligation — abandoning is not enough. Obliteration is permanent, requires a confirmation string that exactly repeats the object hash, and leaves a signed tombstone with your reason. A generic --yes is deliberately not accepted. See the audit collection.