The repo you hand over is a deliverable from day one

C² rests on one bet: context lives in git and compounds. Write down what you learned, and the next session starts where the last one finished.

Here is the boundary condition on that bet, and it took a near-miss to find it.

Context that compounds in a repository you intend to hand over is compounding into someone else's hands.

A repo you own is a workspace. A repo you hand over is a deliverable.

That distinction sounds obvious written down. It is not obvious at 11pm with an agent mid-task.

Client work gets its own repository, in a GitHub organisation the client owns, so it can be given to them cleanly. That is the right structure. It also means the repo is a deliverable from the day it is created — not from the day of handover.

Everything that has ever been committed there is part of what you hand over. Not the current state. The history.

That is not a stylistic point. Once something is committed and pushed, GitHub's own guidance is that you should consider the data compromised and rotate it, because removing it from history does not undo who may already have it.

The near-miss

An agent working in a client repo wrote 3 lines into a session brief. The lines described a defect in my own platform — the mechanism, how far it reached, and whether it was fixed yet.

None of that was speculation. All of it was accurate. That was the problem.

It was caught in the working tree and never committed. I verified that three ways, including a search across every commit on every branch, because "I am fairly sure it did not land" is not a finding.

The repository had moved into the client's organisation hours earlier. Both the agent and I knew that. Neither joined that fact to what was being written down.

The briefing was right. Its depth was wrong.

This is the part I keep returning to.

The briefing that caused it was correct and necessary. The agent needed to know that a particular platform capability was unreliable, because that client's plan had 2 features that depended on it. Telling it stopped a build heading somewhere expensive.

What went wrong was how much I said. I explained the defect fully — mechanism, reach, status — the way I would to someone on my own side. A diligent agent writes down what it is told. So the depth of the briefing decided the depth of what landed in the client's repository.

That is the non-obvious half of this rule. It binds conversations, not just documents. You can be careful about every file an agent writes and still leak through what you say to it, because a good agent's whole job is to write down what it learns.

The test I use now

A client repo never holds a platform vulnerability. It gets the constraint and its consequence — never the mechanism, the reach, or the fix status.

In practice that means the difference between these two lines:

Stuart Leo

"Do not build on capability X yet — it is not reliable. Use Y instead."

Stuart Leo

"Capability X leaks data across tenants because of Z, it is unpatched, and here is how far it reaches."

The first is everything the client's build actually needs. The second helps nobody who is building their product.

So the test is a single question, and I ask it of a sentence before it goes into a client repo or into an agent working in one:

Would this sentence help an attacker more than it helps whoever builds this client's product next?

If yes, it belongs in my repository, not theirs. The constraint travels. The mechanism stays home.

The honest cost

This asks you to brief shallower than feels natural, and briefing shallow feels like withholding.

It also asks you to always know which repository you are standing in. That sounds trivial. On a day when an agent has been moved between 2 repos and you are mid-thought, it is not.

The failure here was not carelessness about secrets. I am careful about secrets. It was a fact I held, a consequence I did not draw, and a gap of a few hours in which both were true at once.

That is worth naming plainly, because "do not leak secrets" teaches nobody anything. Everyone already agrees with it. Both parties held the fact and neither drew the consequence is a shape you can recognise in yourself tomorrow.

The rule, restated

Context compounds. That is the whole point of the method, and it is why C² works.

But compounding is not neutral about where it happens. A repository you will hand over is a deliverable from its first commit, and the history goes with it.

So the constraint travels and the mechanism stays home — and you decide which is which before you brief, not after.

Read the method →