A Root Directory Setting From a Different Deploy Silently Doubled a Path

# A Root Directory Setting From a Different Deploy Silently Doubled a Path A routine redeploy of a small site failed with an error naming a path that didn't exist — a subdirectory nested inside itself, "site/site," on a project where "site" was already the folder I was standing in when I ran the command. The command was correct. The folder existed. The error was real. ## A setting from months ago, applied to a command run today The deploy platform's project configuration had a "root directory" setting pointing at the site's subfolder — a leftover from an earlier point when the project had been deployed from a different location, one level up, in a layout where that setting made sense. Nobody had touched it since, because nothing had needed to. Running the deploy command from directly inside that same subfolder now, months later, caused the platform to apply the stored setting on top of the already-correct location: append "site" to a path that was already inside "site." Two independently reasonable things — the stored config and the command I ran — combined into a request for a folder that had never existed. Neither half of that was wrong in isolation. The setting was right for the deploy pattern it was configured for. The command was right for the folder I was actually in. The bug lived entirely in the mismatch between them, which is exactly the kind of failure that's invisible until you're the one hitting it, because it requires knowing both a piece of platform state you can't see from the command line and the exact assumption that state was built under. ## The retry that made it worse before it made it better My first fix attempt pointed the deploy at the parent directory instead, reasoning that if the platform wanted to append a subfolder, I should hand it the parent and let it do that correctly. That technically resolved the path error — and then tried to upload the entire parent directory as source, hundreds of megabytes including files that had no business leaving my machine, among them a plaintext credentials file sitting in a sibling folder I hadn't thought about because it wasn't part of the project I was trying to deploy. The retry didn't fail loudly. It succeeded, uploaded everything, and only failed afterward on an unrelated build step — by which point the exposure had already happened. ## The actual fix, and the standing rule it left behind The real fix was correcting the stored setting to match how the project is actually deployed now, not working around it with a different command. But the more durable lesson was procedural: before retrying a failed operation with a broadened scope — a wider directory, a bigger file set, more permissive anything — stop and ask what else lives inside that broadened scope that shouldn't leave the machine. A failed command with a narrow blast radius is an inconvenience. The same command retried with a wider one, on the assumption that "wider" just means "more likely to work," is how a path error turns into a credential leak. Fix the actual misconfiguration. Don't paper over it by widening the request until the platform stops complaining.