A save point should prove it works

Most tools that save your work answer one question: what did the files look like at 10:42? Git does this. Cloud sync does this. Your editor's local history does this. They are all good at it.

After an agent session goes wrong, that is not the question you have. The question is: which of these versions still works?

Six save points, one question

Here is the demo that ships with tm. Running tm demo builds a small synthetic tip calculator called Marigold Tips and records six save points:

Save point	Note	Works?
cp-0001	Initial tip calculator	yes
cp-0002	Added split bill	yes
cp-0003	Added dark mode	yes
cp-0004	Agent: fixed lint warnings	no, rounding broke
cp-0005	Changed currency	no
cp-0006	Added a dependency	no

An agent fixed some lint warnings in cp-0004, and tip rounding broke. Then two more changes landed on top. By cp-0006 the tests fail, and the cause is three steps back.

If all you have is a list of six snapshots, you start guessing. Open one, install, run the tests, read the output, try the next. In your real folder, with your current state still in it.

Make the check part of the save point

Time Machine attaches a verdict to each save point. You choose the check once, in timemachine.yml. tm init guesses it for you: npm test, then npm run build, then cargo test, go test ./... or pytest.

To check a save point, tm verify rebuilds it in a separate Git worktree, runs your setup step such as npm ci, then runs your check with a clean environment and a time limit. The result is one of five verdicts, each with a fixed exit code:

• PASS, exit 0. The check passed.
• FAIL, exit 1. The check failed.
• INCOMPLETE, exit 2. Something saved is missing, or setup failed, so the check did not run.
• BLOCKED, exit 3. The check cannot run yet.
• ERROR, exit 4. The check crashed, timed out, or the save point failed its integrity check.

tm find-good walks back from the newest save point and stops at the first PASS:

$ tm find-good
  cp-0006   FAIL       The check failed with exit code 1.
  cp-0005   FAIL       The check failed with exit code 1.
  cp-0004   FAIL       The check failed with exit code 1.
  cp-0003   PASS       The check passed.
PASS  cp-0003 is the newest version that works.
Next: tm recover cp-0003

Then tm recover cp-0003 makes the branch tm/recover/cp-0003. It saves your broken state first, as cp-0007, so nothing you had is lost.

Never show unchecked as working

The most dangerous thing a tool like this could say is "works" when it does not. So the engine has rules:

• A save point that was never checked is shown as not checked. Never as working.
• A verdict is signed and bound to the exact save point it was made for. An old PASS can never stick to a new save point.
• If a save point changed after it was saved, its integrity check fails and the verdict is ERROR, not PASS.
• If you asked for the network to be off and no sandbox can enforce it, the verdict is BLOCKED. The check does not quietly run online.
• Every verdict says how it ran: the isolation mode, network on or off, and how long it took.

Today the isolation mode is host mode: a separate copy on your own machine, not a container. That is weaker isolation, and the verdict says so instead of hiding it.

Proof has limits too

A PASS means your check passed. It does not mean your app is correct. If your tests do not cover tip rounding, a PASS will not catch a rounding bug. The verdict is only as good as the check you give it.

So the first thing worth doing is choosing a check you would trust yourself. Even a weak one beats none. npm run build alone catches a lot of agent damage: a deleted file, a broken import, a dependency that does not install.

Why this matters more with agents

When you write code yourself, you usually know the last moment it worked. With an agent, you often do not. It made forty changes while you read something else, and then it said "All done!"

A verdict on every save point turns "when did it last work?" into one command. Survey data points the same way. InfoWorld reports that only about 7 percent of developers trust AI with important decisions, but about 48 percent trust it when the output is easy to check. A save point with a verdict is easy to check. That is the point.

Sources

1. InfoWorld: AI distrust is GitHub's opportunity
2. Git documentation: git worktree
3. Git documentation: git bundle