A checkpoint is not a verified code change
Review session history, recovery state, project changes and actual tests as four different kinds of evidence.
Ouros editorial team
A checkpoint can help you find an earlier point in your work. It does not prove that a code change is correct. Conversation history, saved recovery state, the files on disk and test results answer different questions.
Make four separate records
History answers “what did we discuss?” A checkpoint answers “what state did this tool record?” A diff answers “what changed relative to this comparison?” A test answers “what happened when this check ran on these files?” None is a substitute for all the others.
Imagine an agent changes a parser and then records a checkpoint. The checkpoint might be useful for continuing the session. The parser can still reject an input it should accept. Conversely, a successful test result from before the edit says nothing about the edited parser. The order matters.
Write a short review record with four lines: task and session, recovery point, files changed, and check with its actual result. Leave a line unknown rather than borrowing confidence from the others. This makes a resumed task easier to understand than a vague “all saved.”
Look at the project before changing recovery state
Start by recording the current work. In a Git project, these commands give a compact view:
git status --short
git diff --stat
git diff -- path/to/changed-file
Replace path/to/changed-file with the file you intend to review. The short status lists changed and untracked paths. The summary shows the size of tracked changes, not their meaning. The last command shows unstaged changes in the chosen path. It will not show the contents of a new untracked file, and staged changes need a separate comparison such as git diff --cached.
Read the full relevant file as well. A small patch can depend on surrounding code that did not change. Preserve other people's edits and your own unrelated work before considering any restore operation. Do not treat a recovery control as a safe way to discard changes you have not identified.
Use session controls for their own purpose
The Agent RX command reference describes these in-session commands. Enter them separately inside RX, not as shell commands:
/help
/models
/tools
/sessions
/checkpoint
Use help to understand the controls offered by your installed application. A command name alone does not tell you which files or external effects a recovery action can undo. In particular, restoring local state cannot be assumed to unsend a message or reverse work already performed by another service.
After a correction, run the check that exercises the reported fault. Record its command and actual result beside the reviewed change. If a check could not run, keep that fact separate from whether the files were saved.
A useful stopping point is not merely “checkpoint created.” It is “I know what changed, which work remains untouched, and what evidence supports accepting this change.”