The Handoff a Cold Session Can Verify
Explore how to create effective checkpoints and handoffs between coding sessions that preserve critical state and diagnosis beyond code changes. Understand the Resume Protocol to verify repository evidence and avoid redundant work. Learn to bridge session boundaries so fresh sessions can confirm, reconcile, and continue development reliably.
Session 1 stopped halfway through Wrenfold’s waitlist ticket, CLIN-547. Its closing message said:
Waitlist promotion is mostly implemented. One test still needs fixing. Continue in the cancellation route.
Session 2 opened src/routes/appointments.ts, saw a failed assertion, and rewrote the waitlist selection query. Forty minutes later, the same end-to-end test failed for the same reason. The query had already selected the correct patient. The previous session had learned that promotion ran on a separate database connection before the cancellation committed, so the supposedly freed 3:00 PM slot still appeared occupied.
That diagnosis existed in the old conversation. It did not exist in the repository. The new session inherited a conclusion without the observation that supported it, then edited the wrong boundary.
The model could understand the transaction once it saw the trace. Nothing in the repository carried that understanding across the session boundary. The missing layer was Carry, and that is a reliability problem.
Why can’t the next session read the old conversation?
A conversation is an execution history: abandoned ideas, repeated tool output, partial conclusions, and corrections. Replaying it makes a fresh session spend context rediscovering the current state.
A generated summary is smaller, but it is still an interpretation. “Mostly implemented” and “one test needs fixing” describe the state of the work, but they do not include the facts needed to act on it.
A checkpoint answers with repository-verifiable claims. The new session checks them against the working tree before trusting them.
Use each artifact for its own job:
Artifact | What It Preserves | How Session 2 Uses It |
Transcript | Chronological interaction | Consult only when a missing detail truly requires it |
Summary | Compressed narrative | Orientation, never completion authority |
Commit | Exact saved repository state | Establish the code baseline and inspect changes |
Checkpoint | Verified state and restart instructions | Reconcile, reproduce, and resume |
The checkpoint is the bridge. Git stores what changed; the Feature Ledger stores eligible work and its gates. The checkpoint connects ...