Answers and explanations · Recover and replay deliberately

The injected crash occurs after the first actual synthetic read but before its reply is accepted into the snapshot. Expect phase IN_FLIGHT, reservation count 1 and fact absent. A second direct invoke raises TransitionError, so it cannot duplicate that invocation through the normal controller API.

Export the store, construct Checkpoints.restore(payload) and create a new Engine using the same policy and source. Deliberate recover(..., abandon_read=True) keeps the old reservation charged. A new baseline lookup consumes reservation 2, then produces the fact and draft. The original tool object made one actual call; the restored engine's new tool made one. Their combined calls are two, matching the two saved reservations in this controlled example.

With max_tool_calls=1, restoration does not create more allowance. Recovery can return to ACTIVE, but the next lookup proposal yields STOPPED/tool_budget_exhausted. This is appropriate even if the restored tool's local calls counter is zero: that object does not know the earlier process's history, while the checkpoint preserves its reservation.

The default recovery note should say that invocation began but its result was not checkpointed, so the controller stops with uncertainty. Deliberate abandonment is allowed only because this tool is a synthetic read without external side effects. The unknown old outcome is not relabeled as a definite failure, and its allowance is not refunded.

A future real write needs evidence such as a service-supported operation ID with a queryable result, or an actual idempotency contract tying repeated requests to the same effect. It also needs the caller's permission for the specific action. A local timeout does not prove dispatch failed. Neither a new run ID nor a repeated prompt supplies that missing evidence.

The SQLite context commits or rolls back the snapshot update. It does not wrap a remote service transaction. The exported JSON string is an explicit transfer artifact in a simulation, not automatic persistent storage. Restoring a known schema illustrates continuity; it does not establish crash-proof durability, secure upload parsing or cross-worker exactly-once behavior.

Self-review: your failure table should preserve at least four distinctions: not yet invoked, invocation started, known result checkpointed, and outcome uncertain. If all four say “retry,” you have lost the reason this module exists.