Execution model

The file is the program.

Each named transaction is an independent recoverable boundary. Authors place operations that must roll back together inside one transaction.

Selection

undo run migration.undo
undo run migration.undo --transaction upgrade

The first command executes every transaction in source order. The second executes exactly upgrade, but the entire source must still parse and validate.

Fail-fast behavior

prepare  → COMMITTED
upgrade  → FAILED → ROLLED_BACK
cleanup  → SKIPPED

A later failure never retroactively rolls back an earlier commit. No implicit super-transaction exists across the file.

Planning several transactions

plan FILE --transaction NAME is exact against current state. For a multi-transaction plan FILE, the first transaction is exact while later state-sensitive checks are marked deferred. During run, each transaction is freshly planned immediately before it starts, so it observes prior committed state.

Recovery and reruns

Recovery concerns only the interrupted transaction and does not automatically resume later entries. After recovery, explicitly select remaining work or rerun the program only when its authored preconditions make that safe.