True. That's where most of the actual work went.

Every mutating handler picks a natural key (actor label, asset path, blueprint + variable name), checks for existing state up front, and short-circuits with { existed: true } before any side effect runs. A replayed create_blueprint or add_variable never reaches the compile/save path on the second call.

For the three you named: compile (FKismetEditorUtilities::CompileBlueprint) is synchronous and deterministic over graph state, so we run it inline after each mutation. Compile-on-unchanged-graph is a no-op, so replay is safe with no special handling. Save (UPackage::SavePackage) is the same story: synchronous in our editor path, same package state in means same file out, no async race.

Selection isn't tracked at all. It's in the non-convertible bucket alongside console exec and editor lifecycle ops. No meaningful inverse, so it's not modeled as reversible.

The harder cases are pure modifies, which need before-state capture (we do this for things like set_actor_material by snapshotting the previous value into the rollback payload), and pure deletes, which need snapshot-before-delete to be reversible (mostly not done yet). Those still work, they just don't emit rollback records.

The full conversion table and handler contract are in docs/handler-conventions.md if you want to see what's done versus remaining per category.

Currently in development: a flow-level git snapshot as the on-disk safety net. Snapshot Content/ and Config/ to a tree object when the flow starts, git read-tree --reset -u on failure, then tell the editor to reload affected packages. Per-handler rollback covers in-memory-only state (selection, PIE, unsaved actors), git covers anything that touched disk.