Every project has a graveyard. A branch you stopped touching in March. A session where the agent spent an hour on an approach that turned out to be wrong, and you said so, and it started over. The shipped code remembers none of it. It looks like the answer was obvious all along.
We think that's a loss. The dead ends are the only record of what you tried, what you believed at the time, and why you changed your mind. Here's how we've come to read them, and what the documentation says about keeping them around.
Abandoning something is cheap. Remembering why isn't.
Git makes it easy to try things. The Pro Git book describes a branch as simply a lightweight movable pointer to one of these commits.1 Starting one is a small act, and so is walking away from one. That's a good thing. It means you can follow a hunch without much ceremony.
The cost shows up later. A branch name like try-new-parser tells you that you tried. It doesn't tell you what went wrong, what you'd hoped for, or what you learned. Six months on, you might try the same thing again for the same reasons and hit the same wall.
Rewinding is a kind of abandoning too
Working with an agent adds a second way to leave something behind. You don't have to branch. You can just back up. Anthropic's documentation for Claude Code lists exploring alternatives, to try different implementation approaches without losing your starting point, as one of the situations checkpoints are meant for.2 That page is a vendor document, so we're citing it only for what it says about that tool.
The same page is also plain about how long that safety net lasts. It says Claude Code deletes a session's file snapshots by default about 30 days after the session last saved one, and that checkpoints are for quick, session-level recovery, not a replacement for version control.2 Whatever you think of that design, the lesson for the reader is a quiet one. The undo button is a short-term safety net. It isn't an archive of what you tried.
Read them without blame
There's a reason people skip their own dead ends. They feel like evidence against us. Looking back at an hour spent on the wrong approach can bring on a small flinch, and so we don't.
Software operations has an old answer to that. Google's Site Reliability Engineering book says that for a postmortem to be truly blameless, it must focus on identifying the contributing causes of the incident without indicting any individual or team for bad or inappropriate behavior.3 The same chapter works from the assumption that everyone involved had good intentions and did the right thing with the information they had.
An abandoned branch isn't an incident, and your afternoon isn't an outage. But the stance carries over nicely. When you read an old dead end, assume you did the sensible thing with what you knew then. Then ask what you didn't know, and when you found it out. That question is useful. "What was wrong with me?" isn't.
What a dead end can tell you
When we read our own, a few questions come up again and again:
- What did we think was true when we started? A dead end usually begins with an assumption, and the assumption is the interesting part.
- What was the first sign it wasn't working? It's rarely the moment we stopped. It's usually earlier, and easy to spot afterwards.
- What did the correction change? If we told the agent "no, not like that", what had it assumed, and what had we left unsaid?
- Was it really wrong, or just early? Some abandoned ideas come back a month later and work.
None of these need special tools. They need the record to still exist, and a few minutes of looking at it.
Where Cartographer fits
Cartographer reads the session history your coding agent already keeps and turns it into a map of how a project was built. Its replay marks decisions, questions, dead ends, fixes, artifacts, pivots and insights, and it flags turn-initial repairs like "no, I meant..." because they usually mark a dead end. It reads what's already on your machine, with no cloud.
A small habit
The next time you abandon a branch or rewind a session, write one line before you move on. What you tried, and what stopped you. Put it in the commit message, the branch description or a note file. It takes thirty seconds, and it's the cheapest way we know to keep a dead end useful.
Sources
- Pro Git, Branches in a Nutshell. git-scm.com.
- Anthropic. Checkpointing. Claude Code documentation, code.claude.com.
- Postmortem Culture: Learning from Failure, Chapter 15 of Site Reliability Engineering. sre.google.