Rule01
Perfect is the enemy of Good.
At some point you’re no longer improving the solution. You’re just delaying its existence.
Field manual · Volume one
FMS / 2026
The Book
of FMS
Rules for building, fixing, documenting, and knowing when to leave well enough alone.
These rules did not arrive in a walnut-paneled boardroom. They showed up in failed updates, repaired machines, midnight command lines, hard-won second chances, and the quiet satisfaction of a system that finally does what it is supposed to do.
Not because they were profound.
Because they were tested.
Reality gets a vote
The job is not to defend the plan. The job is to improve the result. Start with the system that actually exists, including the strange parts everyone has learned to walk around.
Rule02
Every system is perfectly designed to produce the results it gets.
When the same failure keeps returning, stop blaming the weather. The result is telling you how the system really works.
Rule03
Nothing is more permanent than a temporary fix that works.
Temporary solutions acquire users, dependencies, folklore, and eventually a line item in the budget.
Rule04
The most reliable system is the one you stop touching after it starts working.
A stable system does not need to participate in every new idea. Improvement has a burden of proof.
The discipline of restraint
Competence is not demonstrated by the number of changes made. Sometimes the expert move is to gather evidence, write down what works, and go home.
Rule05
The difference between a stable server and a project is whether you SSH into it after 10 PM.
Late-night curiosity has a remarkable ability to turn tomorrow’s maintenance into tonight’s incident.
Rule06
Run it until it gives you a reason not to.
Age is not a defect. Novelty is not a requirement. If the system remains safe, supportable, and useful, let it earn another day.
Rule07
If everything is working, document it before you forget why.
A quiet system is the ideal time to record the decisions, commands, dependencies, and escape routes that made it quiet.
Rule08
Before changing anything, prove there is actually a problem.
Define the symptom, reproduce it, and establish the desired outcome. Otherwise you are troubleshooting a mood.
Judgment after dark
Tools matter. Judgment matters more. Fatigue changes the odds, pride changes the story, and both become expensive when they are holding root access.
Rule09
One step at a time.
If you change three things, you’ll troubleshoot four. Make the smallest useful change, verify it, and only then take the next step.
Rule10
Trust—but verify.
A green light is encouraging. A tested result is evidence. Believe the system after it proves the thing you actually care about.
Rule11
At 11:31 PM, every problem is either a tomorrow problem or a 3:00 AM problem.
Your next decision determines which. Fatigue changes the odds because judgment suffers under fatigue.
Maintenance interval
Sharpen the saw.
Maintenance is not failure. Rest is not surrender. Documentation, cleanup, learning, and walking away before judgment degrades are all part of the work.
Rule 12
Leave people better off than you found them.
The system should work. The team should understand it. The next person should inherit fewer mysteries, not more.
Everything else is implementation details.
End of volume one. The field work continues.