Continuity Under Change: Checkpoints, Handoffs, and Recovery

T3 Code treats continuity as several related problems, not one “resume” switch. A provider can finish a turn while the workspace checkpoint is still being captured; a thread can retain its transcript while the provider’s native session is gone; and a provider switch can preserve selected history without copying the old runtime’s hidden state. This chapter traces those transitions so readers can tell what a checkpoint saves, what a handoff carries, and when a fresh provider session is safer than a misleading attempt at restoration.

A turn can finish before the workspace settles

The visible end of an agent response is not necessarily the end of the system’s work. T3 Code separates the provider turn from follow-up work such as capturing a checkpoint and settling a diff. The provider may report that its turn has ended while the server still has to flush streamed content, record final state, capture the workspace, or compute what changed. Treating the first event as the complete outcome would make the interface appear finished before the state needed for review or rollback exists.

The repository’s architecture describes this as a separation between intent, durable events, projections, and external effects. A command can be accepted and its intent committed before the provider or filesystem work has completed. Clients receive the committed projection, while an effect worker performs the external operation and feeds the result back into the system. The practical consequence is simple: an acknowledgement means that the request was accepted into durable state, not that every provider, checkpoint, or diff operation has finished.

sequenceDiagram participant U as User/client participant O as Orchestrator participant P as Provider participant X as Effect worker participant W as Workspace U->>O: Send a thread message O->>P: Start provider turn P-->>O: Provider turn reaches terminal state O-->>U: Publish turn/projection state O->>X: Schedule checkpoint and diff work X->>W: Capture workspace state W-->>X: Return checkpoint/diff result X-->>O: Record settled effect result U->>O: Continue with another provider O->>P: Resume natively or create handoff context

This sequence protects two kinds of truth. The provider owns the fact that its native turn ended. The environment owns the fact that the workspace and application record have reached a settled state. A late checkpoint should not extend the provider’s recorded duration or keep the client showing provider work as active, but it also should not be ignored when the user asks to inspect or restore the work.

That separation improves recovery as well. If a client disconnects after the turn terminal event but before the checkpoint result arrives, a reconnect can read the committed run state and then receive the later effect result. If the client blindly resubmitted the original command, it could create duplicate work. Durable intent and idempotent command handling let the environment answer the question “did this request exist?” independently from the question “has all follow-up work settled?”

A checkpoint saves workspace state, not a provider’s mind

T3 Code uses hidden Git refs to capture workspace state without adding commits to the user’s branch. This is a useful boundary because it makes file changes attributable and restorable without forcing every intermediate state into the project’s public history. A checkpoint can describe the files associated with a run and support diffs or restoration while leaving the branch’s commit history under the user’s control.