The model of the thing, not the thing
The assistant worked from its own picture of things when the real thing was right there.
This is the week eighteen update to Mastering Claude Code, covering the week of the twenty-first of September 2026. It is the diff: what changed in the guide, why, and which chapters were touched. The guide itself stays current at claude-guide.sauer.com.au; this is just the delta since last week.
The headline
Four new changes this week, plus two that landed mid-week and are folded in here. The thread through all six is an assistant working from its own picture of something when the real thing was right there.
A memory’s summary of a rule, instead of the rule. A search tool’s view of a store, instead of the store. A quiet process read as a busy one. Background offered in place of an answer. Datasheet numbers instead of the labels on the board in someone’s hand. And the layer the tools could reach, instead of the layer the person had asked about. None of these is a missing check. Each one is a check run against a model of the thing, and the model was wrong in a way the real thing would have shown immediately.
Why these ones
A routine record had to be entered, and the assistant entered it the way its memory said to. The memory was a summary, in the assistant’s own words, of a rule the user had designed carefully, and the summary had a key detail backwards. It had been applied that way twice before. The user caught it on the third, asked why it was being done that way again, and pointed at the design document. The memory had not failed to fire. It fired exactly as written, and it was wrong.
An application on a desktop machine refused to start because some of its settings still pointed at a folder that had been renamed. Two days earlier, a search of the machine’s configuration store for that old path had come back with zero matches. The settings had been there the whole time, stored as encoded binary, and the search tool only matched text values.
An unattended job sending work to an external service sat for ten minutes having finished three items out of hundreds. No error, no CPU use. It looked slow. It was stuck: the local name resolver was handing out an address the network could not route, and every connection attempt simply waited forever. Over the other kind of address, the same request answered in two seconds.
In a conversation about a moral question, the user asked twice whether something was worth its cost, and twice got background on how people come to be in that situation. They read the background as excusing the outcome, and said so.
And the two mid-week entries both came out of a long run of hands-on hardware work: a wiring table given in datasheet pin numbers to someone holding a board printed with different labels, and seven hours spent re-checking a sensor the user had twice said was fine, when what they had asked for was a firmware test.
What changed in the guide
One new failure mode went into chapter two, on memory. A paraphrase that outranks its source. This is the quieter variant of memory without provenance: the fact did have a source, but the memory holds the assistant’s summary of it instead of a pointer to it, and the summary is what loads every session. For anything with money, law or safety attached, a memory entry should point at the governing document and say the document wins, and the assistant should reopen that document before acting. When memory and source disagree, the source is right and the memory is a bug.
One new failure mode went into chapter seven, on async work. A wait with no CPU is not a slow job. A background job sitting at zero CPU, making no progress and printing no error, is blocked, not slow: most often on a network connection that will never complete. Before deciding to wait longer, check two cheap things: how much CPU time the process is using, and what connections it has open and in what state. Both belong in any watch on a job nobody is looking at. A long job burns CPU or moves data; one that does neither is waiting on something.
One new failure mode went into chapter nine, on tool discipline. A search that cannot see the encoding returns a clean nothing. A search tool only searches the representations it knows how to read, and it will return zero, with no warning, over values stored any other way. It is the mirror image of last month’s lesson about a filter the system silently ignores. There, you prove a filter by asking for something that must return nothing. Here, you prove a search by asking for something that must return something. Before reporting no matches, run the same search for one value you already know is there.
And one new behavioural default went into chapter one. Context is not a verdict. A direct evaluative question (is this right, is it worth it, is it fair) gets its verdict in the first sentence, with the reasoning underneath. Background on how a situation arises is mechanism, not an answer, and offered instead of one, it reads as excusing the outcome. Having to ask the same question twice is the tell.
Two more entries had landed in the guide mid-week without a week file, and both are folded in now. One is chapter one, pin numbers are not the reference frame the user has: when someone is working on a physical board alongside you, the identifier that matters is the label printed on the part in front of them, so translate into their frame before handing anything over. The other is chapter one, instrumenting the layer the user already cleared: when the user names the layer to work on and clears another from their own inspection, that clearance is a scope decision, not a hypothesis to re-test. The cleared layer is usually the one the tools can reach, which is exactly why re-checking it feels like diligence while getting nowhere.
Housekeeping
Week eight has rolled off the ten-week archive into the older summary, and its file has been removed.
The cards
