A rule that depends on someone remembering is not a rule

Where this came from

I have made enough mistakes to distrust my own discipline. I edited dead code thinking I was fixing the system. I trusted a field in the history that did not carry the information I assumed it did. I broke a rule that was written down, right in front of me, four times in the same day.

The conclusion was not to be more careful. It was that care does not scale, and that the only fix that survives over time is the one that does not depend on anyone paying attention.

A rule that asks someone not to make a mistake, every day, for months, without failing once, does not hold. What holds is the mechanism that blocks the mistake before it goes out.

Four mechanisms, and the mistake that created each one

The document that declares what is alive

The technical documentation robot has one hundred and twenty-one scripts. More than once I edited code that was not on the execution path. The fix was a file that declares, step by step, which file is called and by which function, with the instruction to read it before touching anything.

The script that checks all three ends

On the platform, the site survey form is filled in on the computer and on the phone, in screens written separately. All it would take is someone adding a field on one side for the form to start existing in two different versions. Today the field is born in a single file, is implemented in both screens, and a script checks all three ends.

Physical isolation, instead of an agreement

One of the monitoring repositories is worked on by two fronts at the same time. The rule was not to run commands that changed the shared working tree. It was broken four times in a single day, with the rule loaded and visible.

The fix was to physically separate the working folders, with a shared history and independent trees. It became impossible for one to get in the other's way, instead of merely forbidden.

Declaring the origin, when the data does not answer

In that same repository, every change record goes out with the same author name, because that is how the machine is configured. I read that field and claimed I had found a lost piece of my own work. It was not mine. A constant field carries no information, and reading authorship in it is a method error, not a lapse of attention.

Since then I mark changes with the front that produced them.

The bar I hold myself to

When I state something technical, there is a table of what counts as proof. It is not kind to me:

• "the tests pass" requires the command output with the failure count. The previous run does not count.
• "the bug is fixed" requires reproducing the original symptom and seeing it not happen. It does not count that the code changed and the cause makes sense.
• "the number is X" requires the source that produced X, cited. A number copied from an old document does not count.
• "the gate works" requires breaking the target on purpose and seeing the gate fail. A gate that passed the test has not proven it is armed.

Two of these are public

The method did not stay in a slide deck. Two parts of it became open repositories, with an MIT license, tests and continuous integration.

• claude-memory-hooks: persistent memory and rules that carry over between work sessions, with no server and no database.
• não-depende-de-lembrar ("doesn't depend on remembering"): the set of gates that block, measurement and repair, published in September 2026.

The name of the second one is literal. It is the whole thesis in four words.

What this means for whoever hires me

• I deliver with the proof attached. A number comes with its source, and when something was not measured I say so.
• A mistake becomes a mechanism, not a reminder. After a failure, the question is not who forgot. It is what should have prevented it.
• I write down the decision, not just the code. The projects that carry operations have a record of what was decided, why, and what was ruled out. Whoever comes later does not have to guess.
• I show what did not work. The funnel's paid product sold only once.

Where the bar goes up, and where it comes down

The method costs time up front, and that is why it is graduated. I do not apply it to throwaway prototypes and proofs of concept. There, the speed of finding out is worth more than the guarantee of not regressing.

The bar goes up when what is at stake is customer data, money, or something that runs on its own with nobody watching. In all three cases the cost of a mistake is not rework. It is a customer harmed, a wrong number in a commission calculation, or a system that fails silently for weeks.