Operation Guinea Pig: The Day I Put Drive File Renamer Through the Wringer

The app's been live for a while now. Deployment @28, OAuth fully verified, real Paddle billing wired up, the whole thing. But "live" and "actually tested since the last redesign" are two different things, and I hadn't put them next to each other in a while. A couple of sessions back I tore apart and rebuilt the entire "Rename pattern" section — six numbered boxes, real typography, per-rule accent colors, the works — and after all that visual surgery, the honest truth was: it looked right, but I hadn't actually clicked through it end to end since. So that's what today was. Not a coding session. Sit down and actually use the thing like a stranger would, front to back.

I'm writing this up in more detail than anyone will probably ever want, on purpose. If something breaks in three weeks, I want to come back to this and know exactly what I clicked, in what order, with what values, and what came out the other side — not a vague "yeah I tested it, seemed fine."

Step zero: figuring out where I even was

Before touching anything I went back through my own notes on this project — I keep a running log of every decision and gotcha right next to the code, specifically so I never lose context on why something is built the way it is. Skimming through it reminded me of the shape of the thing: Google Apps Script, not a hosted backend, only ever touches files through the Picker with the narrow drive.file scope, undo/history baked in, a free 50-file cap, paid unlimited tier through Paddle. And there was one specific loose thread nagging at me — a CSS fix for the Undo/✕ buttons looking visually detached from each other, which I'd deployed but never actually confirmed with my own eyes, because my browser session dropped mid-test last time before I got to the screenshot. Good. Now I had a target for today.

Step one: opening the actual live app

I went straight to the real production URL — not the test-deployment link, the actual one a real user would land on. First thing that loads is the standard Apps Script banner ("This application was created by a Google Apps Script user," with a Report Abuse link and a dismiss button) sitting above the app itself. Then the app: "Drive File Renamer" as the heading, a little moon emoji "🌙 Theme" button next to it, a reassuring line underneath — "Only accesses files (or folders) you pick below — never your whole Drive" — and a green banner: "Paid plan — unlimited files per run," with "Refresh status" and "Manage subscription" links. Below that, the numbered sections: "1. Select files or folders" with a "Choose from Drive" button and "No files selected yet." text, then "2. Rename pattern" with the six boxes, a History section saying "No renames yet," and a Feedback section at the bottom with a rating dropdown and a textarea.

Popped open the browser console out of habit before doing anything else: zero errors, one warning, and it was just a generic Google Apps Script sandboxing notice that fires on basically every page Google serves this way — nothing to do with my own code. Fine, moving on.

Step two: finding files to abuse without wrecking my own life

Here's where I had to slow down. I clicked "Choose from Drive" and the picker opened into my actual My Drive root. Not a sandbox, not a dummy account — my real personal Drive. Real files sitting right there in the listing: a PDF of placement data, a payment screenshot, a certificate of completion, a pile of old WhatsApp photos. Renaming any of that in the name of "testing" would've been a genuinely bad move — that's real stuff with real meaning, and "oops I bulk-renamed your certificate while testing case-transform" is not a sentence I want to have to say to myself later.

Luckily, sitting right there in the same listing was a folder I'd left over from an earlier test round: "Chunking Test - Drive File Renamer," containing exactly three small.txt files — zip-report.txt,draft-notes.txt, draft-summary.txt. Disposable, already used for testing before, zero sentimental or practical value. I double-clicked into it, selected all three with Ctrl+A (the app's own UI tells you to do exactly this — there's a line under the button that says "For shared folders: open the folder above, then select the files you want, or press Ctrl+A to select all"), and hit Select. Back in the app, the text under "1. Select files or folders" updated to "3 file(s) selected."

Step three: the six-rule gauntlet

This was the main event. The redesigned "Rename pattern" section has six numbered boxes: Find & replace, Case transform, Insert file metadata, Prefix/suffix, Insert today's date, and Add sequential number. The order is fixed and always runs 1 through 6 no matter which ones you turn on — that's deliberate, so whatever the preview table shows you is guaranteed to be exactly what happens when you hit apply. I decided not to test these one at a time. I turned on all six at once, because that's the scenario most likely to expose an ordering bug, and it's exactly the kind of thing a visual redesign could quietly break without me noticing — six boxes that now look independent and separately styled could tempt someone (future me) into reordering them visually someday without realizing theexecution order still has to stay 1 through 6 underneath.

Here's exactly what I typed into each box:

Box 1, Find & replace: ticked the checkbox on, typeddraft into "Find text or regex," typedTEST into "Replace with." Left "Use regex" and "Case sensitive" both off.

Box 2, Case transform: no checkbox here, just a dropdown. Picked "Title Case" out of the five options (No change, UPPERCASE, lowercase, Title Case, Sentence case).

Box 3, Insert file metadata: ticked the checkbox on, left the field dropdown on "File size" (the other options are Date created, Date modified, Camera make/model, Date taken, Dimensions — the last three only really apply to images), and switched the position dropdown from "At start" to "At end."

Box 4, Prefix/suffix: no checkbox, just two plain text fields. TypedQA_ into Prefix and _v1 into Suffix.

Box 5, Insert today's date: ticked the checkbox on, left the position on "At start." Inserts as yyyy-MM-dd.

Box 6, Add sequential number: ticked the checkbox on, typed1 into "Start at," typed 2 into "Zero padding" (so numbers get padded to two digits — 01,02, 03 instead of1, 2, 3), left position on "At start."

Hit "Preview changes." Here's what came back, current name on the left, new name on the right:

• zip-report.txt → 01_2026-08-13_QA_Zip-report_11B_v1.txt
• draft-notes.txt → 02_2026-08-13_QA_Test-notes_11B_v1.txt
• draft-summary.txt → 03_2026-08-13_QA_Test-summary_11B_v1.txt

I wanted to actually hand-trace at least one of these instead of just glancing and moving on. Take draft-notes.txt. The extension gets split off first and reattached at the very end — it never gets mangled by a case transform or anything else — so the working name starts as draft-notes.

1. Find & replace (step 1): draft becomes TEST → TEST-notes.
2. Case transform (step 2), Title Case: TEST-notes → Test-notes. Interesting — Title Case only capitalized the very first letter, not "Notes" after the hyphen. So my Title Case treats the string as one word unless there's a space, not hyphen-aware. Worth knowing, not a bug, just how I built it.
3. Insert file metadata (step 3), File size, at end: tiny file, so it appended _11B (11 bytes) → Test-notes_11B.
4. Prefix/suffix (step 4): prefix on the front, suffix on the back → QA_Test-notes_11B_v1.
5. Insert today's date (step 5), at start: today is 2026-08-13, goes on the very front → 2026-08-13_QA_Test-notes_11B_v1.
6. Sequential number (step 6), start 1, padded to 2, at start: this file lands second in the batch, so it gets 02 on the very front → 02_2026-08-13_QA_Test-notes_11B_v1.

Reattach .txt and you land exactly on02_2026-08-13_QA_Test-notes_11B_v1.txt — precisely what the preview showed. The other two check out the same way. This mattered because it's not something you can confirm just by staring at a CSS diff and calling it done — you actually have to run the numbers by hand once. And it held: the redesign — new fonts, new colors, numbered badges, bordered boxes — really did leave the underlying pipeline order completely untouched.

I clicked "Apply rename." A new entry landed in History: "8/13/2026, 7:26:17 PM — 3 file(s): zip-report.txt → 01_2026-08-13_QA_Zip-report_11B_v1.txt, draft-notes.txt → 02_2026-08-13_QA_Test-notes_11B_v1.txt (+1 more)" — with an "Undo" button and a small "✕" sitting right next to each other on the right.

I grabbed a screenshot here specifically to check on that loose thread from earlier: the Undo button used to look visually detached from the ✕, because both were direct children of a row using justify-content: space-between, so with three children — filename text, Undo, ✕ — the spacing got spread evenly instead of grouping the two buttons. I'd fixed it by wrapping Undo and ✕ in their own little container, but never actually looked at the result live. This time I did, and it held: Undo (solid red) and ✕ (small blue X) sit right next to each other on the far right, clearly grouped, clearly separated from the filename text. Confirmed, finally, for real.

Step four: undoing it, and not just taking the app's word for it

Clicked Undo. Got a confirm dialog: "Undo this batch? This renames 3 file(s) back to their previous name(s)." Accepted it. The app said "Reverted 3 file(s)." and History went back to "No renames yet."

Normally I'd stop there, but I wanted independent proof, not just my own app's self-report — an app can tell you it succeeded while quietly having done nothing. So I reopened the picker, navigated back into the Chunking Test folder, and looked at the raw listing. And there they were: zip-report.txt,draft-notes.txt, draft-summary.txt — plain original names, no 01_, no QA_, no _v1. Genuinely reverted, checked through a completely separate path from the renamer's own status message.

Step five: presets, saved and reloaded and deleted

Presets exist so I don't have to rebuild a pattern from scratch every time I run a recurring job. With the six-rule combo still sitting in the form, I clicked "Save as…," got a prompt asking "Preset name?", typed QA Test Preset.

To actually prove it persisted rather than just living in some in-memory JS variable that'd vanish the second I refreshed, I did a full hard reload — not a soft one, a genuine reopen of the page. And there it was: the preset dropdown, which had only ever said "— Load a saved preset —," now also listed "QA Test Preset." I selected it, hit "Load," and every field snapped back exactly — draft andTEST in find/replace, QA_ and_v1 in prefix/suffix, all six checkboxes in the right states. Then I hit "Delete" to clean up, and confirmed through the dropdown that it was gone.

Step six: deliberately breaking it with an empty selection

After the reload the form still had the preset's rules loaded but no files selected — selection doesn't survive a reload, which makes sense, file IDs from a picker session shouldn't be assumed valid forever. I clicked "Preview changes" anyway, on purpose, with zero files chosen. This mattered because of a real bug I'd found and fixed a while back: the status message div used to live inside the preview section, which only becomes visible after a successful preview — so any error, including exactly this "no files selected" case, rendered into a box the user literally couldn't see. Clicking Preview used to just appear to do nothing at all. The fix moved the status text outside that box so it's always visible. And sure enough — "Select at least one file or folder first." showed up right under the button, immediately, clearly readable. Bug stayed fixed.

Step seven: the theme toggle, in both directions

Clicked the "🌙 Theme" button. The whole page flipped to a dark palette — near-black background, each of the six rule boxes keeping its own distinct left-border accent color, the green "Paid plan" banner still legible against the dark background, text staying properly high-contrast instead of that washed-out gray-on-dark look you get when dark mode is bolted on as an afterthought. Grabbed a screenshot to actually look at it instead of just trusting the toggle fired. It looked genuinely good — like I'd designed it that way on purpose.

Then I did another full reload, specifically to check persistence — I deliberately made this app not follow the OS/browser's dark-mode preference automatically anymore, because I found it confusing the one time it just showed up dark purely because my Windows theme happened to be dark, with no action from me. Now it always starts light and only ever switches through this explicit button, remembered inlocalStorage. After the reload the button read "☀️ Theme" and the page was still dark — persistence confirmed, not just the in-session toggle. Flipped it back to light before moving on, so I'd leave things the way I found them.

Step eight: a regex test with an actual capture group, not just a plain string

The Find & Replace box has a "Use regex" checkbox, and I realized I'd never actually exercised it live with something nontrivial — a plain literal-string replace doesn't prove the regex engine or capture-group substitution genuinely works end to end. So I picked just zip-report.txt, ticked "Use regex," typed^zip-(\w+) into Find and archive-$1into Replace. That pattern anchors to the start, matches the literalzip-, captures one or more word characters into group 1, and the replacement re-inserts whatever got captured. Hit Preview:zip-report.txt → archive-report.txt. Exactly right — report got captured and correctly substituted back in through $1. Applied it, confirmed the history entry read "zip-report.txt → archive-report.txt."

Step nine: actually clicking the little delete button, both ways

With that fresh history entry sitting there, I clicked the ✕ next to it. Got a confirm dialog with genuinely clear wording: "Delete this history entry? You won't be able to undo this batch afterward — the files themselves won't change." First I clicked Cancel on purpose, specifically to check the negative case — does canceling actually leave the entry alone, or is there some sloppy code path where the deletion happens regardless of what the dialog says? Checked History again and the entry was still sitting there exactly as before, Undo and ✕ both intact. Good — cancel genuinely cancels. Rather than actually delete it and lose the ability to undo, I just clicked Undo instead, confirmed that dialog too ("Undo this batch? This renames 1 file(s) back to their previous name(s)."), gotarchive-report.txt back tozip-report.txt, and the history entry cleared itself out naturally as a side effect.

Step ten: the one weird thing that turned out to be nothing

At one point, reopening the picker on the same Chunking Test folder a second time in the same session, the listing only showed two files — draft-notes.txtand zip-report.txt — withdraft-summary.txt nowhere in sight. That's the kind of thing that could genuinely be a real bug — a file silently deleted, or accidentally renamed into oblivion by an earlier step — so I didn't just shrug it off. Opened a second tab, went straight to Google Drive's own search, searched draft-summary.txtby name, and there it was — correctly named, sitting in the correct folder, last modified right around the time of my earlier undo. So the file was never actually missing; the picker's own listing just didn't show it on that particular reopen, for reasons that live entirely inside Google's own widget, not my code. Worth writing down so I don't chase this as a phantom data-loss bug later, but not worth losing sleep over.

Somewhere in the middle of all this I also fat-fingered a click meant for the theme button and hit "Refresh status" instead — the button that manually re-checks Paddle subscription status. Not what I meant to click, but since it happened: no error, no glitch, it just quietly did its job. Free bonus coverage of a path I hadn't planned on testing directly.

Wrapping up

By the end, every file in the test folder was back to its exact original name, History read "No renames yet," and there were no leftover presets sitting around. Checked the console log for the whole session start to finish: zero real errors the entire time — the only thing logged at all was that one generic Apps Script sandboxing warning that fires on basically every page Google Apps Script serves, unrelated to anything I actually built.

Nothing here needed a code fix. This was purely a "does the thing that's already live actually work the way I think it does" pass, and as far as I could push it in one sitting — six rules combined at once, undo checked independently instead of trusting the app's own word for it, presets round-tripped through an actual reload, a real regex with a capture group, both outcomes of a confirm dialog, dark mode checked in both directions across a reload — it held up. The one loose thread going in, that CSS button-grouping fix I'd never actually looked at, is closed now. The rest was just making sure nothing quietly broke underneath a redesign that, on paper, was only ever supposed to touch colors and fonts.