Patching in the Restrictive Direction Only
A rule I made for myself while hardening Magatama, my own ops agent: every fix has to make the system stricter, never more convenient. It turns out the hardest part is being the only person that rule ever inconveniences.
Magatama is the agent I built to watch my own servers so I don't have to do it manually at midnight. It patches things, flags things, occasionally locks a door before I've noticed it was open. I like it for the same reason it makes me nervous: some mornings it has more opinions about my infrastructure than I do.
At some point I wrote myself a rule and stuck to it hard enough that it now shapes every patch that goes anywhere near it: a security fix is only allowed to move the system toward more restrictive. It can close a gap or tighten a default. It is never allowed to quietly open something up because the looser version would be more convenient this week. Written down like that, it sounds like common sense. Enforcing it turns out to be the hardest habit I've built around this project, because I'm the only person the rule ever inconveniences.
The only person it annoys
There's no ticket queue behind Magatama. No second engineer to raise an eyebrow when a check seems paranoid, no code review where someone asks why a fix is stricter than it needs to be. It's me, alone, at whatever hour I'm looking at the fleet, holding both the restriction and the pen that wrote it. Every rule I've tightened has, at some point, gotten in my own way, usually on a night when I wanted something done in five minutes and the agent wanted three confirmations first. That friction has nobody's name on it but mine. Nobody else will ever feel it, complain about it, or notice if I quietly remove it.
The exception with my name on it
The specific temptation isn't loosening a rule outright, since that would at least announce itself. It's carving out an exception for the one operator who happens to be me. A cooldown period before a fleet-wide change ships, say, with a clause that reads something like "unless the operator is the owner." I control both sides of that boundary: the thing being restricted, and the code that does the restricting. Nothing technical stops me from just editing the file. The only thing stopping me is deciding, every single time, that I won't.
I've started treating that specific urge as close to a red flag as anything I see in this project. A restriction that's only ever been tested against me has basically no evidence behind it. It has never had to survive contact with someone trying to get around it on purpose. If I write myself an exception because I'm both the developer and the sole user, the lock ends up opening for exactly the person it's supposed to stop. The annoyance means the check is doing its job.
So the process, such as it is, comes down to one question before anything ships: does this patch make any path more permissive, for anyone, under any condition. If the answer is yes, it doesn't go in as written. Usually that means finding a stricter version of the same fix. Sometimes it means building a separate, narrower path for the thing I actually needed, with its own logging, instead of widening the general rule to fit my one use case. The second option takes longer. It's also the only one I still trust myself to agree with in six months.
I won't claim I've never caved. I've opened the rule file, stared at a check I wrote for a good reason, and thought seriously about commenting it out for an afternoon. So far I've always closed the file again, mostly out of stubbornness rather than any particular virtue. I keep a plain text note of restrictions I've wanted to loosen, dated, with a one-line reason attached. Most of them are still sitting there unread. That's less a triumph of discipline than a mildly boring habit. It's also the one that's kept the fleet's defaults pointed in one direction for as long as I've been running this thing.