> ## Documentation Index > Fetch the complete documentation index at: https://docs.reasonos.com/llms.txt > Use this file to discover all available pages before exploring further. # Recover and resume with your AI assistant > Find what actually completed after an interruption, preserve shared work, and resume without repeating uncertain writes. Start from [Use ReasonOS with your AI assistant](https://docs.reasonos.com/ai.md) and the connection you already authorized. Recovery begins by reading current state. A lost reply is not proof that an operation failed or that nothing changed. ## Start with a request like this > Our connection dropped while you were working. Check the branch and what > actually completed, preserve my drafts and everyone else's changes, and show > me what can safely resume. Do not repeat a write whose outcome is unknown. ## Establish where you are Have the assistant record the connection, organization, project and branch, the last acknowledged operation and any execution ID, request key or commit hash. Use the tools this connection actually offers; a hosted deployment can run an older build than the current documentation describes. On managed ReasonOS MCP, `whoami` identifies the person and organization the connection acts as. `list_projects` and `list_branches` identify accessible projects and branch heads. A managed branch server belongs to its assigned branch. To work elsewhere, connect to that branch's server; never check out a different branch in the current shared server. Local RBS MCP operates on the current workspace files. Record HEAD and dirty state, and preserve the index, working files, drafts and configuration before changing anything. Local `read_file` reads current disk content; managed `read_file` reads committed content at a ref. Neither proves that an editor has no unsaved drafts. A local workspace is not automatically the same state as a managed branch or a clean checkout of its head. ## Read before deciding what to retry * **An execution already has an ID.** Read `branch_execution_status` with the same project, branch and ID. It reports the recorded revision and state; waiting for status does not start another run. Keep passed, failed, cancelled, still running and unknown distinct. * **A managed execution start lost its reply.** If the original request and `request_key` are known, resend that exact `start_branch_execution` request with the same key. This supported retry returns the original attempt and starts nothing new; the same key with different arguments is refused. Do not invent a new key to make the error go away. * **A file write lost its reply.** Read the file and relevant branch history before acting. Compare the observed result with the intended change. If another writer has since changed it, reconcile their work rather than replaying an old whole-file replacement. Do not assume every write tool has the execution-start idempotency contract. * **An execution finished but its log is incomplete.** Status contains only a tail. `get_branch_execution_log` reads the sealed log one page at a time for its requester; follow `next_from` until there is none before claiming the whole log was read. It may be unavailable if the original server or matching retained log is gone. Missing evidence is not a passing result. For choosing checks and reporting cache hits, skipped checks or stale results, follow [Validate a change](https://docs.reasonos.com/workflow/validate-a-change.md). ## Reconcile conflicts without discarding work With local RBS MCP file tools, read an existing file before editing it. An unread or changed-since-read file is refused. After reconnecting, read it again before making a new edit; a restarted stdio process has no earlier read history. Do not assume that reconnecting establishes which version is safe to edit. Reconcile the intended change with the new content, then use the existing write permission. These guards do not turn arbitrary shell commands into safe file edits. For an authorized managed `commit_files` operation, read files at the branch head you recorded and send that hash as `expected_head_sha`. If the branch moves, the commit is refused: reread the new head and files, reconcile the change, and submit only the intended result. If the commit reply was lost, inspect the current head, history and contents first. Matching content alone does not establish who wrote it or that every related operation completed. A commit can also trigger CI and restacking. Treat each related outcome separately; do not call a whole workflow complete just because one commit is visible. A timeout is not permission to create a duplicate commit or run. ## Stop when authority or outcome is missing If access expired or was revoked, report the denied operation and preserve the pending work. Restore the intended connection through the supported sign-in flow; do not borrow another person's token, switch identities or request broader grants as a workaround. Resume only within the permissions and scope that are actually available. Cancellation is a request, not proof that a running process stopped. Follow the record until its outcome is confirmed; an `unknown` result stays unknown until there is evidence to resolve it. Do not replace a managed node, reclone, reset, stash or restore a [checkpoint](https://docs.reasonos.com/workflow/checkpoints.md) merely to clear an error. Those actions can overwrite work and need a reviewed preservation plan and the person's authorization. A useful handoff names the last confirmed step, the uncertain or partial step, the exact branch/revision and safe next observation. Include safe operation IDs and evidence links, not credentials or private configuration. Ask for a decision only when the next step changes scope, spending, access or preserved work beyond what the person already authorized. ## What this workflow establishes Existing local MCP checks cover stale-edit refusal, rereading another writer's change, reading again after reconnect, and reconciling a deliberately discarded write reply by observing the file without repeating the write. They use local operator permissions. They do not establish two-person hosted authorization, recovery after a real managed-node loss, or successful execution after a revoked credential is replaced. The managed execution and commit recovery steps above describe their supported tool contracts. Availability and retained evidence depend on the connected build and server. If current state cannot be established, preserve it, report what remains unknown, and hand off instead of guessing. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.