UndoLangTransactions & Recovery

Durable protocol

Recovery begins before mutation.

Lifecycle

UndoLang parses the whole source, plans current state, checks recovery, acquires one root lock, replans and rechecks, then enters PREPARED and RUNNING. Every operation follows backup → synced prepared record → mutation → verification → synced applied record.

PLANNED → PREPARED → RUNNING → VERIFYING → COMMITTING → COMMITTED
                         ↘ known failure → ROLLING_BACK → ROLLED_BACK

Journal authority

Frames contain magic, version, type, sequence, bounded JSON payload, and CRC32C. Prepared records contain inverse metadata and before/after descriptors, not whole target contents. Backups remain under the protected state directory.

Rollback

Known failures replay the journal and walk prepared operations in reverse. Each inverse receives its own prepared/applied records. If the filesystem already matches the exact before state, recovery recognizes the completed inverse; if it matches expected forward state, recovery applies the inverse. Anything else is ambiguous and fails closed.

After a crash

undo recover --root /target --yes
undo inspect TXID --root /target --json

An incomplete final frame can be truncated only after the preceding bytes validate. CRC failure, a sequence gap, an unknown record, or semantic contradiction is corruption and is not repaired. Interrupted rollback is safe to invoke again.

Not isolation: filesystem observers may see intermediate entries. The portable promise is durable intent, verification, and recoverability for supported objects—not universal ACID visibility.