← Contents

Part seven · the last one

Checklists, and all the files.

Copy these. Every line is something that went wrong for me.

Before you turn anything on

  • Scope written down. What it can touch, what it must never touch, how you stop it.
  • Every action undoes itself, recovers on its own, and changes no settings.
  • The never-touch list includes everything the agent needs in order to exist.
  • Every safety check has been made to trigger, and you watched it.
  • The "did it work" check looks for a change, and you tested it against something that never changes.
  • You decided fail-open or fail-closed per check, and wrote down why.
  • The breaker's state survives a restart.
  • There's a way to stop it that isn't deleting things.
  • Something outside it says it's alive, and you've seen that go red.

Every time you change something

  • Run all the tests. Not the ones you think matter.
  • Compare the config on your machine to the one that's running. Check the on/off switches by hand.
  • After it's live: is the running program newer than the change? Compare the times.
  • Did the program say it reloaded? Its word, not the file's.
  • Did the deploy actually build your change, or just report success?

Proving it notices problems

  • Polling: cause a real fault, watch it get noticed.
  • Push: cause an outage longer than the wait. Look for a success logged from the controller's own address.
  • Open the alert rule again afterwards and check its password header survived.
  • Make a fix fail on purpose. You want an escalation, not a false success.

Before changing a password

  • You have a list of every place it's read and every service that restarts.
  • The new one gets checked against the real thing before it's saved anywhere.
  • Every place gets written, and it shouts if it can't reach one.
  • You checked it on the machine that actually uses it.
  • You compared fingerprints instead of reading the thing out.

Once a month

  • Can every safety check still fire? Go read them, don't assume.
  • Do the never-touch lists still match the actual wiring?
  • Are all the heartbeats still registered and arriving?
  • Do the docs match the running thing? Especially anything with an address or a path in it.
  • Break one thing on purpose and watch the whole chain.

Five questions before you believe a "no"

  1. Am I measuring from when the thing happened, or from the last line in the log?
  2. Am I looking at the output this message actually goes to?
  3. Am I on the machine where this would show up?
  4. Is this the real copy of the file, or the one I happened to find?
  5. Could this be the event not happening, rather than the mechanism being broken?

Take it with you

The whole thing, as text files.

Everything above plus the parts I didn't put on the site, written to be handed straight to an AI. Twelve plain text files.

Download it, drop all of the files into one chat, and paste the starter prompt in START-HERE.md. It tells the assistant to read the failure list first and to ask you about your own setup before writing any code. That ordering matters more than it sounds.

It's not a product and it isn't finished. It's one working setup and all the ways it quietly lied to me before I trusted it. Your gear will be different. The shapes probably won't be.

Download the guide (zip, 26KB)

Free, no signup, nothing tracked. If you build something with it I'd genuinely like to hear about it — details are on the trail.

One warning, twice

Don't point something like this at a network you don't own. And keep the list of things it's allowed to do very short. Two is plenty. Everything on that list should undo itself, recover on its own, and change no settings. If it could change a setting, it doesn't belong in something that runs while you're asleep.