What’s true after the turn ends
This week is about the gap between when the assistant stops looking and when you look.
Orientation
This is the week thirteen update to Mastering Claude Code, covering the week of the tenth of August 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
Eight changes this week, and most of them are about the same gap: the distance between the moment the assistant stops looking and the moment you look.
An unattended run that ended its turn on a promise, and left the last third of its own job undone. A build recipe left in a scratch directory that, a week later, had to be dug out of old transcripts. A profile handed over before the data behind it had started moving. A wall hit early and papered over with a workaround nobody asked for. A hypothetical that kept coming back after it had been closed. A probe that read a stale copy of a database and confidently said “not done”. Plus one hook that solves a purely human problem (finding the answer in a busy terminal) and one Chapter 1 default about answering the question that was actually asked.
What actually happened
The sharpest one is the guide’s own weekly update run, which is a little embarrassing and entirely on point.
Last Sunday’s unattended round did most of its job well. It committed the guide, mirrored it, and started a long render. Then it wrote, and this is a quote, “I’ll wait for the render to finish rather than poll”, and it ended its turn.
In an interactive session that sentence is harmless. Someone types the next thing and the work resumes. In a headless run there is no next thing. The process exited. The long render finished into an empty room. The deploy that needed the rendered output, the memory close-out and the closing section of the report all silently never happened. The report on disk still says “see final section” above nothing. This week’s run found the gap only because it went and looked at last week’s artefacts before trusting last week’s summary, which is the Chapter 5 lesson from week twelve, about scheduled reports nobody reads, landing squarely on its own author.
The others rhyme with it. A small device was set up in one session as a custom appliance. It worked, and it was put aside. A week later a small content change was needed, and it cost twenty minutes of pushing from the wrong network and then an hour of transcript archaeology to find the scripts that had built the thing in the first place. They had lived in a session scratch directory the whole time.
A user account on a self-hosted service was set up carefully over about forty minutes (user record, access policy, password, login probes) and when it was opened the service was empty, because the one genuinely slow step, moving the data, had never been started. The account was finished; the thing the account was for had not begun.
In the same session the assistant hit a real cryptographic wall: an end-to-end encrypted password vault that no server-side call can write into. Instead of saying that in one line, it built and tested a nearby thing nobody had asked for, and the actual answer (“this cannot be done, here is why”) had to be dragged out over two more messages.
A long, deliberately theoretical exploration of a hypothetical scenario, walked at the user’s own direction, kept resurfacing as a premise in later practical answers after it had been explicitly closed.
A device login was declared “not done” six minutes after it was done, because the check read a copy of a write-ahead-mode database without its log. The copy was consistent, and stale.
And a measurement across six days of replies found the decision the user actually needed sitting, on median, two-thirds of the way down the reply (the literal last line sixty-five percent of the time) in a terminal already crowded with agent output, shell output and hook feedback.
What changed in the guide
Chapter one, the CLAUDE.md file, gains four behavioural defaults.
Start the long job first. When a task has one slow step (a bulk copy, an index, a build, a render) start it in the background before anything else, and do the configuration and setup while it runs. Then verify the surface the user will actually open, not the account or the config: a service with the data in it, not a profile that merely exists. And before moving anything, check whether the data is already at the destination.
Impossible in one sentence. When an ask cannot be done (a cryptographic wall, a physical constraint, a capability that simply is not there) say so in one line, immediately, and stop. Never quietly substitute the nearest achievable thing and present it as the deliverable. A workaround nobody asked for is a second task the user now has to evaluate and reject, and activity piled on top of a hard wall reads as hiding it.
An explored scenario is not a pursued one. When the user walks a hypothetical with you, the exploration ends when the subject changes. Do not carry it forward as a premise, a branch or a caveat. Work the position that actually exists; the user will say if something changes.
Answer the question that was asked. A question about how a rule, a policy or a mechanism works is not a proposal to break it. Give the analysis (the user’s argument at its strongest, then the real counter) and if a genuine line is ever reached, decline that specific thing in one sentence at the moment it is asked. An unrequested refusal used as a preamble poisons the one place the user can stress-test their own thinking.
Chapter four, hooks, gains a legibility hook. Not every hook enforces something. There is a display event that fires only while the assistant’s own reply is being drawn on screen, so a few lines of script can stamp a marker on the first line of the answer, and the answer becomes separable at a glance from tool output, subagent chatter and hook feedback. It changes only what is drawn: the transcript and the model’s context are untouched, and a broken hook degrades to the plain reply. Colour schemes cannot do this, because the assistant’s prose renders in the terminal’s default colour and no theme setting reaches it. The event has been added to the event table and the use table, with a short section explaining the why.
Chapter six, persistence, gains a failure mode: the build recipe stayed in the scratchpad. Anything needed to rebuild or re-push an artefact belongs one rung up the ladder before the session closes: a versioned project directory, plus a one-line pointer in memory saying where it is and how to run it. Scratch is for the run; the recipe is for the next run. The tell is the question “where is the script that made this?” being answered by a transcript search.
Chapter seven, async, gains the week’s central failure mode: in a headless run, the end of the turn is the end of the run. An unattended run may not wait by ending its turn. It either blocks in-process (a bounded polling loop, re-issued until the artefact appears) or it hands the remainder to a follow-up it schedules explicitly. And it writes its report so that the text is true if nothing follows: “blocked on this step, at this point”, never a promise about a section that does not exist yet.
Chapter nine, tool discipline, gains a failure mode: reading state off a copy that isn’t the whole state. Some stores are not one file. A database in write-ahead mode keeps its newest writes in a sidecar log until a checkpoint; a replica lags its primary; a cache holds the previous page. A copy can be internally consistent and minutes stale, and a query against it comes back empty. Asserting not-done from a broken probe is the same failure as asserting done from one; it just points the other way, and it is harder to catch because absence looks like the safe answer. Read live state through the thing that owns it, and if you must copy, copy the whole state.
And housekeeping: week two has rolled off the ten-week archive into the older summary.
Closing
That is the week thirteen update. The full guide, the nine pillars, and this update are all at claude-guide.sauer.com.au, no login.
The cards
