MS4PI recall and checkpointing

Recall and checkpointing in MS4PI

MS4PI uses layered continuity rather than treating one feature as “memory.” It uses checkpoint and handoff patterns because Pi, like other coding-agent harnesses, may compact or restart context in ways the continuity layer cannot fully control.

The main layers are:

• first-person identity and user context
• append-only LOG checkpoints
• Markdown memory files with MEMORY.md index pointers
• archived Pi session JSONL transcripts
• vector-backed recall when embeddings are available
• rich .handoff.md compaction handoff
• checkpoint-bundle approval discipline

Recall

MS4PI indexes memory files and archived Pi transcripts into a local vector store when embeddings are configured. It can fall back to degraded/text-search behavior where semantic embedding support is unavailable.

Useful commands:

/ms-recall-status
/ms-recall-backfill
/ms-recall-search <query>

Checkpoint bundle discipline

A checkpoint is a governed synthesis step, not just a status note. It captures what should persist from a session: important decisions, lessons, corrections, memory updates, transcript archive/backfill, and recall verification. The point is to keep historical context and durable memory rich enough that a future session can resume without reconstructing everything from scratch.

A checkpoint is not complete just because a LOG entry exists.

When new or updated memory is warranted, checkpoint completion requires:

1. approved memory file writes/updates
2. approved MEMORY.md index updates
3. approved LOG.md append
4. transcript archive/backfill
5. recall/embed verification

For /ms-checkpoint, one checkpoint-bundle approval covers the approved LOG entry plus warranted memory/index writes unless the human explicitly narrows approval.

Handoff and compaction

.handoff.md is a detailed continuity prompt for the next agent state after compaction, role transfer, or session restart. It is not a generic summary. A summary compresses what happened; a handoff tells the next agent what matters, what is unresolved, what has been verified, what has not been tested, and how to resume responsibly.

The handoff should preserve:

• current state
• decisions
• open work
• verified commands
• non-claims
• drift or risk flags
• next-step guidance

MS4PI should not claim compaction parity beyond what has been validated on the target Pi runtime.