File Deletion Recovery and Workspace Cleanup

What problem it solves

When an agent or script deletes temporary outputs or tidies a workspace, the risky failure mode is not leaving files behind, but deleting files that are still needed and losing a verifiable copy later. delete-recovery is a file-level recovery workflow for that case: back up before deletion, then validate integrity and path safety before restoring, so a substituted, tampered, or path-traversal backup is not written back.

How it works

The core loop has three steps: backup places the target file under delete_backup/YYYYMMDDHHMM/ and records a SHA256 hash plus name, description, and path keywords in manifest.jsonl; search finds candidates by name, description, or path; restore runs SHA256 validation, path cross-validation, and ../ traversal checks before writing the file back. By default, restore targets stay inside the workspace root, reducing the chance of writing files to sensitive locations. After a successful restore, the corresponding backup folder is cleaned by default and can be kept with --keep-backup.

Version 0.8.0 adds workspace_cleaner, a scheduled cleanup utility that scans for temporary files and files older than a default 7-day threshold, supports dry-run, whitelists, and protected core files, and still backs files up before deleting them. It fits agent deletion constraints: delete only after backup, and reject restore with a SECURITY log if validation fails.

Boundaries

This is for workspace file recovery and temp-file governance, not system snapshots, RAID, cloud version history, or cross-machine backup. Recovery depends on the local backup directory and manifest.jsonl; if the backup directory is deleted, the disk fails, or the data is wiped maliciously, the skill cannot reconstruct the files from nothing. --force only skips a SHA256 existence check for legacy backups and cannot bypass integrity validation.