Batch Texture Renamer

NOthe brief

Write a command-line tool that renames every file in a folder to a naming convention. It should be safe enough that a teammate could run it on a live asset library without you hovering nervously behind them. That last part is the whole point - anyone can write a rename loop; a TA writes one that doesn't eat someone's afternoon.

This is the truest first pipeline problem there is: messy real-world inputs, a convention to enforce, files you must not destroy, and a payoff you can feel the second it works. Every concept it needs - walking folders, string surgery, dry runs - shows up in every tool you'll ever build after it.

NOconstraints

Constraints are what make a brief interesting instead of a tutorial. Hold yourself to these:

• Standard library only. No pip install. If it doesn't ship with Python, you don't get it. (This keeps the tool droppable into any DCC's Python too.)
• The default mode must change nothing. Running the tool with no flags prints what it would do and touches zero files. Renaming only happens with an explicit --apply.
• No data loss, ever. If two files would end up with the same name, the tool refuses and explains - it does not silently overwrite.
• Cross-platform paths. Use pathlib. No hand-built "\\" strings.

NOacceptance criteria

You're done when all of these are true. Copy this into your README and tick them off:

• Running with just a folder path prints a before -> after plan and renames nothing.
• Adding --apply performs the rename and writes a log file recording every change.
• Two files that would collide on the same target name cause a clear error, and no files are renamed in that run.
• Files already matching the convention are skipped, not needlessly rewritten.
• --help produces usage text someone else could follow without reading your code.
• Running it twice in a row is safe - the second run reports "nothing to do".

NOsuggested approach

Don't build it all at once. Build it in the order that keeps you safe:

1. See the files first. A for loop over Path.iterdir() that just prints names. That loop is the skeleton of every batch tool ever written.
2. Write the convention function. One function that converts one name to the target format. Test it on hostile inputs in the same file before it ever meets a real file.
3. Build the plan, don't act. Produce a list of (old, new) pairs and print them. Read the output. There's always a surprise - find it here, where it's free.
4. Add the safety rails. Collision detection, then the undo log.
5. Make it a tool. Wrap it in argparse so it has flags and help text. Now it's something a teammate can run.

NOstretch goals

Once the core works, these are where a Starter piece grows into something you're proud of:

• Suffix detection: files containing "normal"/"nrm" get a _N suffix, "roughness" gets _R, and so on. Now it understands texture types, not just names.
• A companion undo script that reads the log and reverses a rename. This is a genuine job-interview-grade addition - it proves you think about recovery, not just the happy path.
• Recursion with --recursive (mind the log file - don't rename your own log).
• A dry-run diff view that highlights only the part of each name that changed.

NObreakdown template

The tool is half the deliverable. The breakdown is the other half - it's what turns "I made a thing" into evidence a lead can evaluate in ninety seconds. Structure yours like a postmortem:

## Batch Texture Renamer

**The problem** (one sentence): artists were spending ~10 min per drop
hand-renaming textures to our convention.

**Constraints:** stdlib only, must be safe to run on a live library.

**What it does:** [screenshot or a 20-second GIF of the dry-run + apply]

**The approach - including the dead end:**
- First version renamed on the first pass. Then I fed it two files that
  collided and it ate one. That's why the plan/apply split exists now.

**Result:** ~10 min/drop -> ~5 seconds, and nobody has lost a file.

**What I'd do next:** [suffix detection / the undo script / ...]

Notice the "dead end" line. The path that didn't work is often the strongest part of a breakdown - it proves the final design was chosen, not stumbled into. Leads read that and see judgment.