Your build starts here
Replace bracketed details with your own goal, context, and checks. Keep the first build small enough to inspect.
Build a local rename tool for files strictly inside [named test directory]. Resolve the allowed root and document the handling of symbolic links, path traversal, recursion, and case-insensitive collisions. Produce a dry-run manifest containing each original path, proposed path, relevant file identity evidence, and validation outcome. Use the same selection rules for the real run. Before applying the reviewed manifest, revalidate the target paths and detect files that changed or disappeared after planning; stop or skip under an explicit policy rather than rediscovering a wider set. Test a normal rename, a destination conflict, a nested path, an out-of-scope link, and interruption after one completed change. Record completed operations and demonstrate a bounded recovery on the fixture. Do not overwrite existing destinations silently or promise filesystem-wide atomicity. Return the manifest and precise execution scope.Make this prompt yours
Use for reversible batch file changes in an owned fixture. Path validation reduces mistakes but does not create a universal race-free filesystem transaction.
You might also hear
- rename manifest
- dry-run apply
- symlink scope
- case collision
- TOCTOU fixture
The docs behind it
These references explain the underlying concepts and APIs. The prompt templates and project plans are original examples to adapt to your own setup.
Research sources reviewed .
Editorial review · October 28, 2026
Limited: Original instructional template; not executed. Reviewed manifest/revalidation bounds mistakes but does not establish a race-free filesystem transaction; rename interruption/recovery is an original fixture exercise.