The house said it in thirty-five places

A description of my own product stood in 35 places across my house: the home page, the configuration, research files and blog articles. I set out to correct it on 2026-09-11. The correction went too far, and the same day I had to take most of it back. Thirty-five copies, one fix, one retraction. The actual cause was somewhere else entirely.

What I wanted was boring. I wanted one description of the product that reads the same everywhere. It should match on the landing page, in the positioning the writer agent uses, in the articles it produces, and in the head of the second agent that reviews those articles before they go out. If two machines describe the same product differently, sooner or later one of them argues with the other. That is exactly what happened on ticket #490.

I believed a wrong statement lives in one place. You find it, you fix it there, and everything downstream picks up the fix. That is how I think about code: a constant is defined once and imported. I assumed product facts in my content pipeline worked the same way. Somewhere there was a file that said what the product is, and every writer read from it.

Ticket #490 started with a draft article. It told readers that a certain kind of mailbox was no dead end and only needed a workaround. The sign-up code says otherwise: those providers are refused outright. At the same moment, the reviewing agent raised a false objection of its own, this time against Gmail support. That made two agents, one product and two different wrong answers. They had been reading different descriptions of the same thing, and neither description came from the code.

The writer did have a context file. Its loader read a path inside a hidden tooling folder and fell back to a hard-coded line when the file was missing. The file existed on no machine. It was not in my workshop, and it was not in production, because the deploy excludes that folder. So every site got the same fallback: a one-line pitch for an email response system for support teams. Three sites got a description of a product they do not sell. The email product got one without a single mailbox fact.

6cece918 · 2026-09-11

Der Schreiber hatte keinen Produktfakt — seine Kontextdatei gab es auf keiner Maschine

The writer had no product fact — its context file existed on no machine

The first fix gave each site a list of product facts in its configuration, and every fact carries its source. For the email product that meant five mailbox facts taken from the sign-up code: which providers connect at once, which wait for a beta unlock and which are refused. A small formatter turns them into text. It is pure, so the reviewing agent can borrow the same function. A site without facts now gets its name and address, not an invented pitch.

Then I went after the reviewer’s false alarm. It had read “add-in”, pulled up Microsoft’s rules for add-ins, and concluded that Gmail could not work. I counted where the word stood: the home page, six industry pages, 3 positionings in the configuration, 4 research files and 18 articles, 9 live and 9 scheduled. The commit calls that 35 places. It lists them but does not reconcile the sum, and I won’t do that for it here.

b51de517 · 2026-09-11

emailmanager ist kein Outlook-Add-in — das Haus sagte es an 35 Stellen

emailmanager is not an Outlook add-in — the house said it in 35 places

So I banned the word. My own first answer had been that the product is a service you connect to Outlook through a sign-in grant, not an add-in. The fact said exactly that. The claims gate got a hard error for any sentence calling it an add-in, and the three positionings were rewritten. The tests used real sentences: 7 blocked, 4 allowed. Minutes later I corrected myself. You add it, and it answers emails. Calling it an Outlook add-in was never wrong.

33b3813a · 2026-09-11

„Outlook-Add-in” darf bleiben — zurückgenommen, was b51de517 verboten hat

“Outlook add-in” may stay — withdrawn what b51de517 had banned

1. 2026-09-11Found that the writer’s product context file existed on no machine, so every site got the same fallback pitch. Added per-site product facts, each with its source, and a pure formatter both agents can share.
2. 2026-09-11Traced the reviewer’s false alarm to the word add-in, counted the places it appeared, and made the word a hard error in the claims gate. The broad replacement also hit places where the term was right.
3. 2026-09-11Took back the ban and the rewritten positionings. Kept a fact that separates the name from the technology: the name is correct, and the add-in rules do not apply.

The record names no tool I used. Each commit changed a test file, so a test runner like node –test was probably involved. That is an inference from the file type, not something I wrote down. What the commits do record is the method: every test was checked by mutation. With the old writer code put back, the test goes red. With the facts removed, red. With the ban restored after the retraction, red.

Partly solved. The cause is fixed: the writer now has one source of product facts instead of 35 copies, and the reviewing agent can use the same formatter. The ban is gone, and the configuration is back where it stood before the overcorrection. The fact now says two things at once. The name is right. The technical rules for add-ins do not apply, because the product connects through a sign-in grant instead of running inside the mail client.

Most of the 35 are still untouched. The 18 articles, the home page and the industry pages are public or production data, and these commits left them alone. The research positioning files are not versioned and do not travel with the deploy, so the writer in production still reads the old wording there until I decide otherwise. Nothing in the record checks that the reviewing agent actually reads the shared formatter. It says the agent can, not that it does.