Keep the payments work coherent across sessions

Return to a project after a break and a question appears: the code on disk, the saved conversation, and Git history each remember a different part of the work. In this chapter’s example, the payments service (the small TypeScript service this course uses as its running example) carries two health addresses (/health for existing callers, /healthz for a new monitor) and the reason for keeping both lives in an earlier session’s discussion, not in the files. Before you ask the agent to continue, you need to recover more than a list of changed files. You need to recover the decision those files were meant to express.

If you worked through the opening chapter, its health-check patch is your starting state; if you are entering here, any uncommitted change with a decision behind it works the same way. The chapter does not assume the full suite passed or that you committed the result. Start from your actual state: inspect the files, keep any unresolved failures visible, and leave unfinished work unfinished until the evidence changes.

One starter limitation applies here too: versioned public companion checkpoints are not supplied yet. The following scenarios are teaching examples built around the payments example source prepared for this course, not a captured week of agent runs. For a working copy to follow along in, the getting-started chapter describes where that source comes from; otherwise, use the cases to practice deciding what needs to be preserved.

Three things that can disagree

A session can remember a route you later removed by hand. Your working directory can contain a correct patch that has never been committed. Git can preserve that patch without preserving the discussion that explains why you rejected a different design.

In this chapter, a session is the resumable Claude Code conversation that /resume and --continue select; the two words name the same object.

Each is useful for a different question:

What you need to know	Where to look
What did we discuss or decide?	The relevant conversation and a checked handoff note
What code is present now?	The working files, Git status, and the diff
What version did we deliberately save?	The reviewed commits in Git history

The mistakes in this chapter come from asking one of those places to answer for another. Resuming a conversation will not switch the code back to yesterday. Clearing a conversation will not clean a dirty working tree. Keeping an experimental answer will not preserve its implementation unless you preserve the files too.

Pick up the work without inventing its history

First, resume the health-check session and reconcile its account with the code. Then set that conversation aside to investigate a separate question about duplicate payment keys in the same service.

When you return to the health task, practice choosing a rewind action for a hypothetical wrong turn. Next, compare two implementations without mistaking a conversation branch for a code branch.

Finally, inspect what the session is carrying and prepare a compact handoff. The chapter ends when you can continue from that handoff and distinguish a remembered claim from a checked fact. It does not require pretending that every payment bug is fixed.