Checkpoint

The /checkpoint command is the MindStone for Claude Code implementation of a consolidation cycle. It was created for closed coding harnesses where MindStone cannot fully control context pruning, but still needs rich continuity across compaction and new sessions.

A checkpoint is not just a summary. It is a governed synthesis step: the orchestrator reviews what happened, decides what should become durable memory, updates LOG/memory/identity artifacts where warranted, archives and indexes transcripts, and verifies that recall can find the preserved material later. It turns temporary session context into continuity the next session can actually use.

When to run /checkpoint

Run /checkpoint:

• At the end of a meaningful work session
• When you’ve made an important decision you want to remember
• When you’ve corrected a mistake that should inform future behavior
• Periodically during long sessions (the PreCompact hook preserves continuity across a compaction mechanically, but only /checkpoint embeds the accumulated transcripts and synthesizes durable memory)

The more regularly you checkpoint, the more the memory system accumulates accurate signal. Irregular checkpointing means session transcripts pile up on disk (archived per turn by the Stop hook) without being embedded or distilled into the synthesized judgment about what mattered.

What happens during /checkpoint

1. Session synthesis

   The orchestrator reviews the current session and synthesizes:

   • Key decisions made and the reasoning behind them
   • Patterns observed that should inform future behavior
   • Mistakes made and their corrections
   • Novel situations and how they were handled

2. Memory file updates

   Based on the synthesis:

   • Existing memory files with relevant content have their hits incremented
   • New memory files are created for genuinely new learnings
   • Memory files that were active during the session have last_applied updated
   • prevented increments if a memory clearly prevented a mistake

3. IDENTITY.md review

   The orchestrator reviews IDENTITY.md for sections that should be updated:

   • New expertise developed during the session
   • Changed working relationships
   • Updated understanding of the project or domain
   • Corrections to prior self-description

4. LOG.md entry

   A session summary is appended to LOG.md — the append-only session log that provides continuity context in future sessions.

5. Vector index update

   The indexer runs with CAIRN_CHECKPOINT_MODE=1 to embed the transcripts archived since the last checkpoint and reindex any modified memory files into the SQLite-vec store. This is the embedding step that the Stop hook deliberately defers (per-turn embedding pegged the local embedder).

The synthesized vs. auto-archived distinction

The Stop hook auto-archives every turn’s transcript to orchestrator/transcripts/ on disk. This ensures no session content is completely lost. Those archived transcripts are chunked and embedded into the vector store at /checkpoint (not per turn).

The /checkpoint command adds a different layer on top of that raw capture: synthesized judgment. The orchestrator actively decides:

• Which learnings deserve to be explicit memory files (high signal)
• Which existing memories should have their weights updated (hit confirmation)
• How IDENTITY.md should evolve to reflect accumulated expertise

Auto-archiving captures texture. Checkpointing captures judgment.

Both are necessary. Raw texture in the vector store gives Auto Recall access to experiential details. Synthesized memory files give the SessionStart hook access to stable, weighted knowledge that should always be available. Together with handoffs, this is how MS4CC keeps historical context rich across compacted sessions and even completely new sessions.

Option D flow

The “Option D” checkpoint flow (from the CAIRN_DESIGN docs) is the full cycle:

1. Review the session
2. For each memory file that was injected:
   • Did it help? Increment hits
   • Did it prevent a mistake? Increment prevented
   • Is it no longer relevant? Update frontmatter
3. Create new memory files for learnings
4. Update IDENTITY.md
5. Write LOG.md entry
6. Run indexer

This is the highest-quality checkpoint — it produces the most accurate weighted recall signals over time. The abbreviated flow (just create new memories + LOG entry) is faster but produces less precise weighting.

Running /checkpoint

/checkpoint

The /checkpoint slash command is defined in .claude/commands/checkpoint.md. When you type /checkpoint in Claude Code, it loads the command’s instructions and the orchestrator executes the checkpoint/consolidation protocol.

Tip

Don’t wait until you’re about to lose the context window before checkpointing. The best time to checkpoint is while the session is still fresh — you can synthesize the learnings accurately, and the memory weights will reflect the actual value of what you learned.