Grepping the module directory before proposing new work

This is a small lesson, but it is cheap to repeat and easy to avoid, which is why it was written down as a standing rule rather than handled as a one-off correction.

Any operator, human or AI, working in a codebase or an infrastructure that is growing faster than any one person’s mental model of it will eventually propose rebuilding something that was already built. The reasoning that gets you there is reasonable at every step: a gap seems to exist, nothing in recent memory closed it, and the work to close it is well understood. The flaw is at the start. Not remembering that something exists is not evidence that it does not.

The duplicate would also have been worse than the original, which is the part worth dwelling on. An older safety mechanism has fifteen days of operating history behind it: it has fired or not fired, been tuned, been believed. A fresh duplicate has none of that, so when the two disagree, nobody knows which to trust, and in practice both end up half-trusted.

The fix costs one search. Before scoping new work to close a perceived gap, search the current state for the thing you are about to build, by the name you would give it and by the names someone else might have given it. It belongs in the onboarding document of any fast-moving system, and especially any system where the operators change often enough that nobody has the whole picture.