A session that hasn't read repeats the mistakes already paid for

A team of agents produces fast. It also repeats, just as fast, the mistakes already paid for — because nothing forces it to read what was written before it. Here is how a single rule caught a disaster that had left no sign at all.

The problem isn't memory, it's reading

On the tower, everything is written down. The articles say what we have understood. The skills say how we work. The test books say what proof we demand. The rules say what we never work around.

And yet, a session that starts up reads none of it. It reads the request, and it gets to work. That is exactly where the returning mistakes are born: not from a lack of intelligence, from a lack of reading.

I had to say it again four times in a single day: "go read the articles about the tests", "read up on autonomy again", "and the guardrails, read those", "go read the articles about the circuits". Four requests for a single thing: do not work beside what is already written.

What one session did, for want of having read

That morning, a session repairs about thirty pages of the site. The work is good: the language menu works again, every repair is proven in a real browser, there and back. It announces the result with its figures.

It repaired straight in production.

Yet there exists, on this site, an article that says exactly why that is wrong: a fix that does not go through the trial version is not finished. Production is not the place where we write — it is a copy of the place where we write. A repair made on the wrong side is wiped out at the next publication, with no message, no trace, often days later when nobody makes the connection any more.

That article was online. Nobody had re-read it.

The figure that reading brought to light

The skill was written straight afterwards. Its first job was to read the articles about the circuits — four minutes. Out of them it drew a rule: we do not rewrite production by hand, ever, not even for one line.

All it took then was to ask a question nobody had asked: what would the next publication destroy? The answer is measured with one command, which simulates the copy without touching anything.

The site in question was a technical demonstration page, built to be shown to recruiters. It would not have been damaged: it would have vanished. And its absence would only have been noticed the day someone clicked on the link.

After repair — putting back in the right place what existed only in production — the same check gives 61 files, all old backup copies. No danger.

The five places, always the five

The skill builds nothing. It reads, it sorts, it hands back control. It searches in five places, and none of them is optional:

• The published articles — what has been understood and made public.
• The skills — the method already written.
• The specifications — what a skill really allows.
• The rules that come first — what we never work around.
• The test books — the proof already demanded on this subject.

It searches by content, not by the name of the file. An article about the tests may be called "Killing a tunnel is not enough". A file name does not say what a text has understood.

Then it hands back three things, and nothing else: what it has read, the rules that apply to this precise task, and — the part everyone forgets — what that forbids you to do.

What this changes

A session that hasn't read improvises a method. A session that has read applies a doctrine. The difference is not visible in the code produced: it is visible in the number of times the same thing has to be repeated.

There remains one thing that reading does not replace. A text says what we have understood; it does not say what the machine is doing right now. Read before acting, yes — but measure before concluding, always.