Expand description
§2 module 20 checkpoint (COMPOSABLE-HARNESS-DESIGN.md line 470): file
checkpointing / shadow-git; D4-adjacent revert; D3 turn-diff tracking.
Line 1504: “restores FILES, not context — pairs with, never replaces,
the reduction sidecar.”
Not to be confused with crate::Agent::checkpoint/crate::Agent::rewind_to
(an in-memory CONVERSATION-position marker, an unrelated pre-existing
facility) or crate::session_tree (module 21, tree-addressable
sessions). This module only ever touches files on disk.
§The write-path interception seam (D-5, shared with formatters/P5-11)
crate::tools::WriteObserver (defined in crate::tools, the seam’s
natural owner since crate::tools::ToolContext carries it) is called
by write_file/edit_file/apply_patch around their mutation.
CheckpointObserver is this module’s implementation: before_write
captures a pre-image; after_write is a no-op (reserved for
formatters).
§Storage — never the user’s real git
CheckpointStore is a content-addressed, per-project shadow store at
a caller-supplied root (the same dependency-injection shape as
crate::store::SessionStore::open) — blobs keyed by
crate::reduce::content_hash under <root>/objects/, one JSON
manifest per checkpoint under <root>/checkpoints/<id>.json. This
module never shells out to git and never touches the project’s own
.git — there is no GIT_DIR to get wrong because none is ever used.
§C8 (design line 1819) compliance
A CheckpointId is an opaque String — the ONLY thing a caller
(session record, CLI) ever threads around. It is never the file
contents, and it never reaches the model’s context window: restoring
files is a disk operation, never a conversation-history mutation.
Structs§
- Checkpoint
File Entry - One file’s entry in a
CheckpointManifest— the turn-diff (D3) is simply this manifest’sfileslist. - Checkpoint
Manifest - A checkpoint’s full manifest — one JSON file per checkpoint.
- Checkpoint
Meta - Lightweight listing entry (
CheckpointStore::list) — the manifest without the (potentially long) file list. - Checkpoint
Observer WriteObserverimplementation backing[capabilities.checkpoint]. One instance percrate::Agent(installed on itscrate::tools::ToolContextAND held directly socrate::Agent::run_loopcan callSelf::begin_turnonce per user turn — see that method’s call site’s doc comment).- Checkpoint
Store - A directory-backed, content-addressed shadow store rooted at
root— see the module doc comment. Never touches anything outsiderootexcept (duringSelf::restore) the project files a manifest names, which are re-validated againstproject_rootindependently of how the manifest was produced. - Restore
Report - The outcome of a
CheckpointStore::restorecall.
Constants§
- DEFAULT_
RETAIN - Default number of checkpoints retained per project before the oldest are
pruned (bounded-disk requirement) — overridable via
[capabilities.checkpoint].retain.
Functions§
- observer_
for_ config - Build the
CheckpointObservera freshcrate::Agentshould install, given a resolvedcrate::Config— called once, fromcrate::agent::build_tool_context.Config::checkpoint_enabledis the ONE gate:false(the default) returnsNoneWITHOUT touching the filesystem at all (noCheckpointStore::open, no directory created) — the default-off byte-identity guarantee.trueopens (creating if needed) the shadow store atConfig::checkpoint_dir, ordefault_shadow_rootwhen that’s unset; an I/O failure (unwritable state dir) is reported via a one-timeeprintln!warning and returnsNone— graceful degrade, never a crash, never a blockedAgent::new.
Type Aliases§
- Checkpoint
Id - An opaque, lexically-sortable (ascending = chronological, since it’s zero-padded-millis-prefixed) checkpoint identifier. This is ALL a session record ever carries for C8 — never file contents.