Look before you act
Most of this week’s mistakes came from acting before looking at what was already known.
This is the week 08 update to Mastering Claude Code: a short walkthrough of what changed in the guide during the week of the sixth of July, including two additions made later the same week.
The headline
A memory store pays rent only when it’s consulted at the moment of decision. This week’s biggest lesson is the quietest memory failure of all: everything is recorded (the working pipeline, the component that already does ninety percent of the new request) and the assistant builds a parallel system from scratch anyway, because it never read the index before starting. That is a different disease from the memory failures the guide already covered, like bloat or staleness or missing provenance. Nothing in the store was wrong. It simply wasn’t opened. And the cure is different too: not better writing into the store, but a standing habit of reading it, at build time, before the first line of anything new. A filing cabinet nobody opens is indistinguishable from an empty one.
What changed, chapter by chapter
In Chapter 2, on memory, a new failure mode: a rich store the assistant never opens. The fix is a standing default worth writing down. At the start of any build task, read the index, list the pieces that already solve part of the problem, and design the change as the smallest delta on those. The moment the assistant is about to author a new service, protocol, or pipeline that parallels one already in the store is the moment to stop and extend instead.
In Chapter 1, on the CLAUDE.md file, three new behavioural defaults. First, sanity-check results against known context: an implausible number, like a response time far faster than the distance to the server allows, is a signal to investigate, not a result to report. Second, ask why the primary path is out, first: when work is running on a fallback, a backup link or a workaround, establish why the designed path isn’t in use before you engineer around the fallback; the reason usually changes the whole answer. Third, the target is the deliverable: work built for a specific device or surface is done only when it works there. A browser stand-in is at most a temporary aid, never the delivered answer unless you explicitly accept the downgrade.
In Chapter 4, on hooks, a new section on secret hygiene as a pair of hooks rather than a written rule. “Never print credential values” is the rule that keeps being broken as text. So you enforce it: a hook that runs before a command and denies piping a known secret file into a printing tool, and a second hook that scans command output afterward for credential shapes and, on a hit, blocks with an instruction to treat the value as compromised and rotate it. Pair them with a sanctioned redacting reader so inspection stays legitimate. Prevention makes the mistake structurally impossible; detection makes the residual failure loud.
In Chapter 9, on tool discipline, a new failure mode: commissioning a bespoke tool when an adopted one already exists. Tool discipline applies to what you ask the assistant to build, not just what it reaches for. Custom dashboards rot: the hand-maintained list behind them lags reality and they stop being opened. Ask what you would honestly open every day; adopt the maintained tool if one maps; build custom only when nothing covers the need and the result derives its data live from an existing source of truth.
Added later the same week: the Friday addendum
In Chapter 7, on async, a failure mode called waiting on a worker that already died. A delegated agent that stops with “I’ll continue when the build completes” has ended its turn. If the thing it waited on finishes without re-invoking it, or the agent dies partway through its final report, nothing resumes it and no error surfaces. The finished work sits orphaned on disk while the delegating session waits, sometimes for hours. The discipline: past the expected window with no word, poll the work state, not the worker (the output files, the timestamps, the commit log in the target repository). If the work is done and the worker is gone, take over and finish inline. Long-running workers should commit early and often, and keep their final reports terse, because a long closing summary is a known place for a worker to die with everything undelivered. And every delegated deliverable should land somewhere you can see it: a link, a rendered file, a screenshot. Work that exists only inside a repository you never open is indistinguishable from work that didn’t happen.
Added later the same week: the Sunday addendum
Two more, and the first one corrects something the guide already recommended. Chapter 4 tells you to build a Stop guard that refuses an unproven “done” claim: a hook that reads the assistant’s final message and blocks it if it asserts something is finished but shows no evidence. The correction: that guard must not fire only once per session. Blocking the first offence and then going quiet feels tidy, but the offence it catches is rarely a one-off. A session that claims something done without proof once tends to repeat it as it lengthens, and those later claims sail through unseen precisely because the guard already did its job and fell silent. Read the guard’s own log back across several long sessions and the shape is unmistakable: one early block, then a cascade it never stopped. The fix is a small per-session counter in the state file. Re-arm on the first offence and every fifth after it, so the guard keeps its bite through exactly the long sessions where discipline slips the most. A hook that can only interrupt once is a hook that stops working the moment it’s needed twice.
And a new Chapter 1 default: lead with the answer. For a direct question (yes or no, who owes whom, how much) the answer belongs in the first sentence, with the supporting breakdown after it. A correct table the reader still has to extract the headline from hasn’t answered the question at a glance.
The cards
