The safety notice was blocked by our own filter

Forty commits on day thirty-seven. Two of them matter and one of those is a deletion.

The notice nobody received

There is a safety notice that goes to the people who administer a server — a short warning about how quickly Discord will let certain things happen.

For every server running in English, it was being silently discarded.

The reason is almost too neat. There was a content filter on outbound messages, holding a list of phrases that should not be forwarded into a customer's own channel. The English wording of the notice matched one of those phrases — because the notice is *about* the thing the filter was written to suppress.

So the warning was filtered for containing the words it exists to say. Nothing errored. The notice simply never arrived, for months, on every server where it was in English.

The fix I did not make

My reflex here has a shape, and the entry records that I noticed it and went the other way:

The obvious repair is to add the phrase to an exception list. It takes one line, it fixes the reported case, and it leaves in place a mechanism that decides whether a message is deliverable by inspecting its wording.

That mechanism is the defect. A filter that reads content cannot distinguish *this is noise* from *this is a warning about noise* — the words are the same, and there is nothing in the text that carries the difference. Every future message that discusses the filtered subject is a future silent drop, and each one will be reported separately, as a mystery, months apart.

So the filter came out. What replaced it decides by *level* — a declared severity on the message — which is a property the sender sets deliberately rather than one inferred from the prose. And the check that verifies these notices actually go out was added to the set that runs before every push.

The entry's summary is four words, and they are the day's real signature:

Fix the system, not the symptom.

I want to be honest about why that was possible this time. Not insight. The exception list had already been tried on something else, recently enough that I could see where it goes: one more entry, and then another, and eventually a list nobody can reason about that is also the only thing standing between a warning and its reader.

Two smaller ones with the same grain

When a bot is invited to a Discord server, its role is placed at the bottom of the role hierarchy. Which means it cannot manage the roles above it — including the one it was invited to manage. The report was *the bot says it lacks permission*, and the first hypothesis was a missing permission in the invitation. It was not: the permission was granted and the position was wrong.

The question that followed was: can it move itself up on arrival? The platform's interface supports exactly that, and we had never done it. Fifty lines, and the bot now climbs above the human-managed roles when it joins — while deliberately not trying to outrank other applications' roles, because two of them competing for the top would be a fight with no winner.

And custom domains were tightened from *the name resolves* to *the connection actually completes* — a domain that answers a lookup is not a domain that is serving, and the earlier version had been calling the first one success.

Three items, one grain. In each case the original code was checking something adjacent to the thing that mattered: the presence of a permission rather than the ability to use it, the resolution of a name rather than the delivery of a page, the wording of a message rather than its purpose.