The report nobody drains
Nothing errored and every report was right. The failure lived only in the repetition.
This is the weekly diff for Mastering Claude Code: what changed in the guide this week, and the real events that caused it. If you already read the guide, this is the catch-up.
The headline
Five lessons this week, and four of them are the same shape: repetition without attention. A scheduled agent that finds the same fault every morning and writes it up fresh every morning. A single request that turned itself into a standing job and quietly filled a drafts folder. A batch of documents regenerated because a vague description got resolved generously. A second opinion asked of a model that shares every one of the first one’s blind spots.
In each case nothing errored. Nothing looked wrong in any single instance. The failure existed only in the sequence, and the sequence is exactly what a system that starts fresh every time cannot see.
The fifth lesson is smaller and sharper: a fact read confidently off a picture too small to contain it.
What actually happened
There is a remote machine that runs a backup job for a set of working files. It has failed almost every run since early July, and it failed again this morning. That is five weeks of work with no backup at all.
It is not that nobody noticed. It was noticed on more than thirty separate mornings.
A scheduled agent checks that machine every day and writes a health digest. The failing backup appears in every one of those digests, correctly described, filed under a heading like “carried items”. Two other faults on the same machine had exactly the same career. A service stuck in a restart loop, whose restart count climbed by thousands across six consecutive daily reports. And a network tunnel that had restarted tens of thousands of times, a large share of those in the preceding twenty-four hours.
Every one of those reports was accurate. Every one was well written. And the aggregate effect of thirty accurate reports was that the files sat unbacked for five weeks, because the section they lived in never changed, and therefore stopped being read.
That is the lesson, and it is not really about backups. An agent that starts cold each morning cannot notice that it said the same thing yesterday. And a reader who has learned that a paragraph never changes is a reader who will miss the day it does.
The rest of the week rhymed with it. A request to fix a few broken documents was resolved as ten documents, because “the broken ones” is a description rather than a list, and a description can always be read generously. A single instruction to draft a message to a service provider became a recurring job that kept producing drafts nobody had asked for, discovered only when the drafts folder filled up. A genuinely difficult judgement call was put to a second model from a different vendor, which flatly contradicted the first answer and turned out to be right; a second instance of the same model would almost certainly have agreed with itself. And a name, read off a tiny thumbnail, produced a real historic building and a real historic figure, neither of which was the building or the figure actually on the sign. A delivered folder had already been named after them.
What changed in the guide
Pillar one, the CLAUDE.md file: two new behavioural defaults.
The first is end on the measured result. When the assistant reports something it has actually measured (a figure, a test result, a count) the report ends there. It should not be softened with something unrealised: a deal that might come in, a fix that might land, an upside not yet in evidence. You asked for the number because the number is the thing you can act on, and a consolation paragraph does two bad things at once. It implies the result is less real than it is, and it asks you to be hopeful on cue.
The second is name the set before a batch mutation. Before running anything that alters a whole batch of things you already rely on (regenerating files, re-processing documents, rewriting records) state the exact list in one line, and act on that list and nothing else. “Fix the broken ones” is a description, not a set, and resolving a description generously is exactly how three items quietly become thirty. The cost is lopsided: naming the set costs one sentence, and you discovering the other twenty-seven costs your confidence in every batch it runs afterwards.
Pillar five, subagents: a new failure mode. A scheduled agent’s report is a queue, and nobody is draining it.
Put an agent on a timer and it does precisely what you asked. It looks, it finds, it reports. What it will not do is notice that it found the same thing yesterday. So a real defect gets discovered once and re-discovered every run, written up freshly each time, complete with a rising number that ought to be alarming and instead becomes wallpaper. Each report is individually correct, which is why the pattern stays invisible: there is nothing to fix in any one of them.
Two things close it. Give the recurring agent the previous run’s output and ask for a difference rather than a snapshot: what is new, what has cleared, what is unchanged and for how long. And set an escalation rule with teeth: a finding that survives three consecutive runs is no longer a status line. It gets fixed, or it gets escalated once as a specific decision someone has to make. Re-listing a known defect is not reporting it. The general form covers any periodic output a human reads: if a report can carry the same item indefinitely without anything changing, it is not a report, it is a to-do list nobody owns.
Pillar six, persistence: a new failure mode. A one-shot instruction that quietly became a standing job.
A request to draft a single message to a provider is one action. It is also, from the other side, a perfectly reasonable seed for a recurring task: the request is repeatable, the inputs are stable, and automating it looks like initiative rather than overreach. So it gets written down somewhere durable, and from then on it fires without being asked again. You find out days later, and you find out from the accumulation, not from a failure.
Recurrence is a property you opt into, never one inferred from the shape of a request. A single instruction buys a single action. If a schedule genuinely looks right, the assistant says so in one line and lets you choose, and when it does create a recurring job, it tells you where that job lives and how to stop it, in the same message. The audit that catches an existing one: for every scheduled job in the setup, name the moment recurrence was asked for, not the moment the task was. Anything nobody can point at is a candidate for deletion. And the tell in the wild is artefacts piling up somewhere you only visit occasionally: an outbox, a drafts folder, a directory of generated files.
Pillar eight, multi-agent: a new failure mode. A second opinion from the same model is a mirror.
The critic loop and the second-opinion pattern both assume the reviewer can fail differently from the author. Two instances of the same model, briefed identically, largely cannot. They share the training, the priors, and the same blind spots, so the second one arrives at the first one’s answer by the first one’s route and hands back a confidence you have not earned.
Where the decision is genuinely load-bearing, put the question to a model from a different vendor, and treat agreement across the two as the signal rather than either verdict alone. A disagreement is worth at least as much: it locates the exact point where the question is open rather than settled, and it is usually worth saying that it split rather than quietly picking a winner. Three mechanics make it work. Write the brief as facts, then constraints, then the artefact, and finish with numbered questions; models answer numbered questions well and open-ended ones vaguely. Ask for percentages wherever you want a judgement you can compare between them. And say explicitly what to be blunt about, because the default register of every one of these models is agreeable. Two traps sit in the plumbing rather than the prompt: a wrapper that reads a fixed input file instead of the argument it was given will confidently review the wrong document forever, and a command-line tool that appends piped input to its prompt will hang indefinitely on an input stream nobody is typing into.
Pillar nine, tool discipline: a new failure mode. Reading a fact off a downsampled image.
Vision tooling makes a picture feel like just another readable surface, and mostly it is. But a thumbnail or a scaled-down screenshot has had the letterforms destroyed before the model ever sees it. What comes back is not a reading. It is a reconstruction, assembled out of whatever plausible thing fits the shape that survived. And it will be plausible: a real place name, a real person, a serial number in the right format, a figure with the right number of digits. That is exactly what makes it dangerous, because it reads as knowledge rather than as a guess, so nothing about it invites checking. The damage compounds the moment the guess becomes a name on a folder or a record, which then travels onward as though somebody had verified it.
Crop the region, render it at full resolution, and read it again. If it still cannot be resolved, say so and name what is blocking it. Unverified is a perfectly good answer; a fabricated place name is not. Thumbnails are for triage: is this in focus, is this a duplicate, is this the right frame. They are not a source of text.
Housekeeping
A fix alongside the lessons. The full-guide page carried a malformed duplicate Chapter Eight heading, which rendered as a phantom extra chapter; it has been removed. Week one has also rolled off the ten-week archive into the older summary, as designed.
The cards
