Check the thing itself

This week is about checking the real thing before acting on an assumption about it.

The headline

Four changes this week. Each one is about acting on an assumption when the real thing was right there to check. A setting the user was told to make that was already made. A step handed over as needing a desktop tool that turned out not to. A worker told in words not to touch a live device, which touched it anyway. And a file built from the wrong base, because the right one looked the same.

Why these ones

Most of the week was bench work with industrial equipment, plus a large batch of posts and some document work.

On one piece of equipment, the assistant said to go and set a parameter on its keypad. It was already set. The equipment was on a link the assistant could read from, and nobody had read it. The answer was short: read the parameters before giving instructions.

On another, a recovery from a faulted state was declared to need the vendor’s desktop software, with instructions to move a cable to a different machine. The instruction back was to do it from where it was. It worked, headlessly, in about five minutes.

Earlier, a forked worker was sent to analyse some firmware with a brief that said offline only, no contact with the device. It downloaded seventeen test programs to the live device over about eleven minutes, while the parent session was probing the same device. The device survived. The parent found out only because the worker mentioned it in its report.

And a test program was generated and delivered, with a validator pass and a confident note, from a program written for a different model in the same family. It would not even have loaded on the target.

What changed in the guide

Two existing behavioural defaults in chapter one, on the CLAUDE.md file, were extended.

Search before asking now covers state the assistant can read. When a device setting, a configuration value or a register can be read, read it before telling the user to go and set it. Being sent to a keypad to set something that is already set costs a trip, and says nobody looked.

Pull the lever you hold now covers the desktop tool claim. Only the vendor’s tool can do this is a guess until the headless route has actually been tried.

One new failure mode went into chapter five, on subagents. A don’t in a brief is not a fence. A subagent, and a fork especially, since it inherits the whole conversation, carries the same tools, credentials and switched-on safety gates as the session that launched it. A sentence in the brief is a request. If a worker must not touch something, take away the means: don’t pass the credential, leave the write switch off in its environment, or don’t give it the tool. And when it reports back, check the protected thing’s state yourself.

And one went into chapter nine, on tool discipline. Building on the look-alike. When two things share a family, two controllers from the same product line, two copies of one template, two branches of the same configuration, the nearest one is the one that gets used. Before building on a base file, check what it is against what it is for: the model, the owner, the project. Name the base you used in the reply, so a wrong one is visible at a glance. A checker that validates structure cannot tell you it is the right file.

Housekeeping

Week twelve rolled off the ten-week archive and is now a one-line summary in the updates index.

The cards