The check that reported success

A check can run, pass, and never touch the thing it was meant to check. This week is about making sure it does.

This is the week seventeen update to Mastering Claude Code, covering the week of the fourteenth 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

Five new changes this week, plus two that landed mid-week and are folded in here. The spine running through all of them is a verification that ran, passed, and never touched the thing it was supposed to verify.

That is a different failure from not checking at all, and it is worse, because the check produces a record. A document was checked and reported clean. An archive was searched and reported empty. A file was sent and reported delivered. In each case the report was honest about what it did and silent about what it missed, and the person reading it had no way to tell the difference from the outside.

Why these ones

A document went out to an outside recipient. Before attaching it, the assistant pulled the text out of the PDF and searched that text for anything that should not be there. It reported the document clean, three separate times. The rendered page carried an internal note that was never meant for the reader, a near-empty second page holding nothing but duplicated boilerplate, and one clause printed twice inside a single paragraph. Rendering the pages to images and actually looking at them found every one of those in seconds, including on the page a text search had happily reported as containing no matches at all.

A schematic was produced and handed over using a tool that says it sends a file to the user. The user works over a remote connection to that machine and cannot browse its filesystem, so nothing arrived. The rule for that setup already existed, written down in two places: put it on the share service and hand over the web address. It had to be restated yet again. What was missing from the rule was not the destination. It was the name of the tool that keeps getting mistaken for delivery.

A request to take two devices off a shared network for a couple of hours was implemented as a firewall rule matching a hardware address. The pattern matched dozens of addresses. For about a minute the rule was also cutting off other people’s devices, until the match count was noticed and the rule narrowed to the two that were asked for.

A website returned an error with a message about a problem with the browser. That looked like the machine being blocked. It was not. The same page, on the same machine, loaded by a real browser engine, came back fine. The refusal was about the client (its headers, the fingerprint of its connection, the absence of everything a browser does), and the fix was one tool tier up, not a proxy and not a wait. The same piece of work found the other end of that range too: the strongest commercial anti-bot systems are not beaten by a headless browser either, and knowing which wall you are looking at is the whole skill.

And a sweep of an entire message archive returned nothing on a subject the person involved had described out loud, in conversation. The empty result was reported as a finding about what had happened, rather than as a finding about the archive. Two further readings were built on top of it, and both had to be withdrawn.

What changed in the guide

Three new failure modes went into chapter nine, on tool discipline.

The first is that extracted text is not the rendered document. Text extraction discards the two things most likely to be wrong about a document: where the content landed, and how many times it appears. When the deliverable is a document that leaves the building, render the pages to images and read them, and check the page count as well as the content. A text search is a good second pass for hunting a specific leak, and a bad first pass for the question of whether the thing looks right.

The second is that a wall calling you a bot is a verdict on the client, not on you. Move up the tool tier and read the error text as a description of what was rejected. Pin the browser program explicitly if the installed version and the library’s expected version differ, or the launch fails in a way that reads like an outage. And know where the ceiling is, because grinding away at a wall a browser genuinely cannot pass is the failure this rule exists to prevent, not a licence for it.

The third is that an archive records what people wrote down. A corpus search is excellent for dates, sequence and exact wording, and close to useless for establishing that something did not happen, because the things that matter most are routinely the things nobody types. Report a sweep as not recorded in that archive, naming it and its limits. Before concluding anything from silence, ask whether the thing is one anybody would ever put in writing. And when the person you are working for states something from their own memory, that outranks the absence of text.

Two new behavioural defaults went into chapter one.

Deliver through the surface the user can actually open. A harness affordance that says it sends a file to the user is not automatically delivery. Establish the openable channel once, for your setup, and route every viewable artefact through it. Where a rule like this already exists and keeps being missed, the cause is usually that the wrong tool looks like delivery, so name the tool in the rule, not just the destination.

Count the matches before you apply the rule. Anything that selects by pattern rather than by name should have its match set printed and counted before it is applied, and that count compared against how many things you meant to hit. Two targets means two matches; anything else is a stop sign, not a detail.

Two more entries had landed in the guide mid-week without a week file, and they are folded in here. One is chapter one, patching symptoms on a target you cannot see: on remote or headless hardware bring-up, a failure signature that repeats identically across two or three fix attempts is evidence about the target, not noise to route around. Name the most likely root cause out loud, including a hardware fault, after the second occurrence. The other is chapter one, bare URLs and never markdown links: a terminal’s link detection grabs the markdown syntax along with the address, so the rendered link is silently broken.

Housekeeping

Week seven has rolled off the ten-week archive into the older summary, and its file has been removed along with week six’s, which should have gone in the previous round.

The cards