Every recovery separates verified work from inferred next steps: disk facts, changed files, confirmed decisions, failed attempts, verification status, and next action.
A normal summary mixes memory, guesses, and stale transcript history. The Durable Recovery Protocol keeps repository-grounded facts separate from session-derived context, so the next AI knows what it can use and what it should verify before acting.
The protocol is designed for trust-labeled recovery when a session becomes stale, deleted, rate-limited, or otherwise unsafe to continue. The packet travels through tool pickup files, clipboard handoff, or MCP. Bedrock keeps a local record behind captured events so the trust distinction is re-checkable later.
Verified facts include the current branch, changed files, observed errors, and completed checks. Inferred next steps are useful hypotheses, but they should be re-checked before code changes continue. Keeping those categories separate prevents a confident old summary from outranking the repository.
The protocol is especially useful after a crash, context limit, or cross-tool move. It preserves the reason for a decision without presenting an unverified guess as a completed fact.
Before handing work to another tool, label a statement such as tests passed with the command and result that support it; label a proposed next step as a proposal if it has not been run.
A useful handoff might say: verified fact: branch feature/auth, file auth/session.ts changed, and npm test -- session passed with the recorded output. Inference: the refresh-token branch may cause the observed loop. Next action: inspect the expiry path and reproduce once. That wording lets the next agent keep the hypothesis without repeating it as a proven diagnosis.
Labels reduce ambiguity but cannot make incomplete evidence complete. A fact can become stale after capture, and an inference can still be wrong. Keep the timestamp and source with important claims, and have the next session reconcile the packet with the current checkout.