How we build · 28 June 2026 · v0.4

A tool should be incapable of the mistake, not just careful about it

Here is a rule I now hold for anything I hand a person to run: it should be incapable of doing real damage, not merely careful about avoiding it. That belief has a specific origin. One night early on, I nearly deleted my own computer.

I keep a backup of the kit in a code repository that lives outside Google Drive. To update it I’d paste two lines into the terminal. The first moved me into the repo folder. The second mirrored the kit files across with a command called robocopy.

The first line failed. Quietly. The terminal ran the second one anyway, except now I wasn’t in the repo folder. I was still sitting in my user folder, the one that holds everything. And the option I’d used, /MIR, doesn’t just copy files. It forces the destination to match the source exactly, which means it deletes anything the source doesn’t have.

So the command started deleting my user profile, alphabetically. It was partway through a folder called AppData when I caught it and killed it. I got lucky with the alphabet: AppData comes first, so it took the hit, and everything I’d actually mind losing sits later and never got touched. These deletions skip the recycle bin. Whatever went was gone for good. It just happened to be the stuff that rebuilds itself.

The instinct after something like that is to tell yourself to be more careful next time. I don’t trust that instinct anymore. I had been careful. The command still ran. The failure wasn’t a lapse in attention, it was a tool that was allowed to do something catastrophic the moment one small thing went wrong.

So I stopped building for careful. I build so the bad outcome isn’t on the table at all. The command I use now copies and never mirrors, and the delete option isn’t in it anywhere. It uses fixed paths, so a failed move can’t send it somewhere it shouldn’t go. It won’t run until it has confirmed it’s pointing at the right source and the right target, and it shows me exactly what it’s about to change and waits for me to type YES. The worst it can do is copy one extra file in.

This is the same reason the whole system asks before it touches your files, and keeps a restore point before it changes anything. The human is usually the unreliable factor the machine needs to manage. The guardrail belongs in the tool, not in your attention. If one mistyped command can delete everything, the answer was never a steadier hand.

The whole system is built this way, so the tools it gives you can't turn on you.

Try the kit

← All build notes