TL;DRA setup that works in a demo breaks in a long session. What fixed it: a handoff file so context running out stops costing you the session, a memory index split by topic so it actually gets read, one isolated workspace per task, a rule that nothing gets claimed without being checked, a sweep after every change, and hooks for anything that must happen every single time.
…
Do I need the eight episodes first, or can I start here?
You can read this on its own, but it'll make more sense after the series. Everything here is a fix for a problem you only hit once the basic setup is running on real work — if you haven't built the vault, the rules file, and the memory habit yet, these problems haven't found you yet.
Is this specific to Claude Code?
No. Every one of these six is a pattern, not a feature. A handoff file is a file. An isolated workspace is a git worktree. A verification rule is a line in your rules file. They work with any AI that reads and writes files and runs commands.
What if I only do one of these?
Do the handoff file. It's the cheapest to set up and it's the one that saves whole sessions instead of minutes. Everything else is an improvement; that one is the difference between losing an afternoon's context and not losing it.
Isn't a rule that says 'check before you claim' obvious?
It's obvious and it still gets skipped, by the AI and by me. That's exactly why it has to be written down as a rule instead of assumed as good sense. The value isn't the idea, it's that it's in the file the AI reads before it does anything.
The eight episodes built a system: a vault, a graph, memory, rules, skills, agents, MCPs. All of it works. I've been running it on real production work since — client projects, deploys, things that break at 3am and cost money.
And six things broke. Not the pieces themselves — the pieces are fine. What broke was everything around them once the sessions got long, the work got parallel, and the stakes got real.
Here's what I added.
The session ends and takes everything with it
The first thing that hurt: a long session fills up. You've spent three hours building context — what you tried, what failed, why you chose the approach you chose — and then you're out of room. Start fresh and you've lost all of it. Explain it again and you've spent twenty minutes re-establishing what the AI already knew an hour ago.
The fix is embarrassingly simple: a handoff file that the session keeps current as it works.
One file, at the root of the project, with five sections: the goal, the current state, what's done, what's in progress, what's left. The rule is that it gets updated as you go, not at the end — because "at the end" is exactly the moment you've run out of room to write it.
Then when the session is full, you flush the last few things into it, start fresh, and the new session reads that file first. It picks up mid-thought instead of from zero.
The part people get wrong is treating it as a summary you write when you're done. It isn't. It's a live document that happens to also work as a summary. If you only write it at the end, you'll be writing it in the exact state where you can least afford to.
The memory file got too big to be read
Episode 3 was about giving your AI a memory — save what you learn, keep an index, load it next session. That works right up until the index gets long.
Mine did. And a long index has a failure mode nobody warns you about: it stops being read. Not deliberately — it's just that when the index is enormous, loading it eats the room you needed for the actual work, so it gets skimmed or skipped, and you're back to an AI that doesn't know anything about you.
The fix is to split the index by topic and load only the one that matches the work. A short root index that lists the topics, and separate indexes underneath for each area — one for database and infrastructure, one for deploys, one for frontend, whatever your actual areas are.
Two things I got wrong the first time. First, I made a "miscellaneous" bucket. Don't. You never know you need the miscellaneous file, so it never gets opened — the whole point of a topic index is that its name tells you when to read it. Second, I tried to shrink the root index by cutting descriptions. That doesn't work: the size is mostly the links themselves. You don't fix a too-big index by trimming it, you fix it by splitting it.
Two tasks in one workspace corrupt each other
The moment you're doing more than one thing at a time — and with agents you will be — a single working copy becomes a problem. One task switches branches while another is mid-edit. Config from one bleeds into the other. You commit something you didn't mean to because it was sitting there.
The fix: one isolated workspace per task. Git gives you this directly with worktrees — a separate directory, its own branch, sharing the same repository history. The main checkout stays clean and read-only; nothing is ever committed from it.
The rule that makes it stick is checking which branch you're on before every commit, not after. It sounds paranoid until the first time it saves you from committing to the wrong branch.
Confident and wrong
This is the one that cost me the most, and it isn't really about AI at all.
An instruction describes the world. It is not evidence about the world. If your rules file says a service is retired, that's a claim someone wrote down once — it isn't proof the service is retired now. I learned this by acting on a note like that and disabling tooling that three live sites depended on.
So there's a rule at the top of my rules file, above everything else: before calling anything stale, unused, broken, or wrong — go and look.
In practice that means a few concrete habits. The live response beats the config file: what a server actually returns is the truth, what's written on disk is an intention. Check the whole set before you name an exception — "seven of these eight are wrong" almost always means "all eight follow a pattern I haven't understood yet." And verify your own output, because a command that prints "success" is not proof it succeeded; check independently.
The one that matters most: if you can't verify something, say so, and say what would settle it. "The docs say X, I couldn't reach the server, run this to confirm" is useful. "X is broken" on that same evidence is just a confident guess.
One fix, one place, and the other nine places you forgot
You change the name of a field. The code compiles. Tests pass. You ship it.
And then it breaks, because that field was also in a config file, a CI workflow, a scheduled job, the docs, an example env file, and a sibling project that reads the same database.
The fix is a habit, not a tool: after every change, sweep every identifier you touched across everything — code, configs, CI, scheduled jobs, monitoring, docs, sibling projects. One pass, all the names at once.
The version of this that actually works is stating the result out loud: swept these names across these places, found nothing — or found three, fixed them. If you don't say the result, you didn't do the sweep. It's too easy to intend to check and then not.
There's a bigger version of the same idea: a reported bug is a sample, not the whole defect. Someone reports one broken page. That's one instance of a class. Find the cause, then find every other place the same cause is present, and fix the class in one pass. Otherwise you'll fix the same bug four more times with four different bug reports.
Some things can't be left to memory
The last one: there are things that must happen every single time, and "the AI usually remembers" isn't good enough.
Rules and skills are instructions — very good ones, followed almost always. Almost is the problem when the thing is "never commit a secret" or "always run this check before deploying."
For those, use hooks — automation the tool itself runs, on a trigger, whether or not anyone remembered. It isn't asked to do the thing; it just happens.
The line I'd draw: if forgetting it is annoying, a rule is fine. If forgetting it is expensive or irreversible, it needs to be a hook. And check that your hooks actually run — a hook pointing at a tool that isn't installed fails silently and looks exactly like a hook that's passing. A gate nobody has ever seen fire is not a gate.
What you actually get
None of these six add capability. Every one removes a way the system quietly fails:
Long sessions stop losing their context.
Memory keeps working as it grows instead of quietly going unread.
Parallel work stops corrupting itself.
Claims get checked before they get acted on.
Fixes land everywhere they're needed, not just where the bug was reported.
The things that must always happen, always happen.
That's the actual difference between a setup that demos well and one you can run on work that matters. The eight episodes get you the system. This is what it takes to keep it standing once it's carrying real weight.
How this connects to the rest of the setup
Each of these fixes a specific piece of what the series built. The handoff file is what makes memory survive a session boundary instead of only surviving inside one. Splitting the index is what keeps that same memory usable as it grows. Worktrees are what make agents safe to run in parallel instead of a way to corrupt your own workspace. The verification rule and the sweep habit both belong in your rules file, because that's the thing your AI reads before it does anything. And hooks are the layer underneath skills — for the small set of things too important to leave to instructions at all.
If you haven't built the base yet, start with the setup and come back here when it's running. These are the problems you get after the system works — which is a good place to be.
AI FROM MY POV