Keep an undo ledger for file operations

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

Organize 40 invoices by vendor with name collisions/unknown owners. Bulk moving/renaming loses origins unless undo evidence is retained.

Mechanism

Prepare source→destination mappings and resolve collisions within authorized scope; prefer copying to preserve originals here. Record planned/completed/failed status, paths, hashes and required timestamps per item, checking no overwrite. Hold ambiguous files. Before undo, ensure targets still match recorded identity; later edits create conflicts. Deletion requires actual authority.

Bad example

Move/rename everything, overwrite collisions and rely on memory without originals/mappings.

Good example

Copy agreed invoices under approved mappings, preserving originals and deterministic noncolliding names. Record paths/digests/completion and hold unknown vendors. Undo only matching recorded artifacts, preserving later edits.

Why the change matters

Mappings/results make reorganization inspectable. Originals or complete undo records protect recovery, while statuses separate plans from completed actions.

Observable expectation

Teaching ledger totals 40 across completed/pending/failed. Each completed target matches its source hash. Mid-run failure undo handles completed items only; changed destinations cause conflicts rather than overwrite.

Limits

Copying does not establish metadata/backup reliability. Concurrent changes/symlinks require resolved-path checks and undo can fail. Organization permission is not deletion permission; frozen examples are not current commands.