Task Recovery & Restoration
Task details bring the original request, approved plan, progress evidence, outputs, review findings, usage, and recovery history together. Open them from a Goal, Task Capsule, saved plan in the Plan inspector, or run history. Opening the view does not execute work, retry a check, accept a result, or restore a file.
Read the task state
| State | Meaning |
|---|---|
| Working | The task is executing its saved requirements and plan. |
| Checking | Locus is running declared acceptance checks through the normal permissions. |
| Completed | The task has current passing evidence and settled actions, or separately recorded human acceptance where required. |
| Needs review | A criterion needs judgment, evidence is unavailable, or an action or its usage is uncertain. |
| Paused / interrupted | Saved progress is available; the objective is still incomplete. |
Goals and capsules require recorded checks or explicit human acceptance. Ordinary Work remains direct: it does not create a Goal or require a reviewer automatically. It can show task details and offer explicit result acceptance.
An agent saying “tests passed” is not a check receipt. Verification records actual tool results, relevant file fingerprints, the execution location, and the task revision. Changing requirements or relevant files makes old evidence stale. Missing evidence in older history is shown as unverified.
Checks can verify file existence, required text, a JSON value, or a command's exit status. Criteria such as tone, visual judgment, or an external result that cannot be checked automatically require Accept result after your review. Human acceptance stays distinguishable from machine verification.
Choose the recovery action
| Action | Use it when |
|---|---|
| Resume | Continue the saved attempt and retain compatible verified progress. |
| Retry checks | Inspect existing outputs without repeating implementation. Safe file and JSON checks do not need a model call; shell checks retain their execution permissions. |
| Ask planner for help | A capsule or Duo build needs an explicit, bounded return to its planner. |
| Run again | Deliberately start another execution of the saved plan. |
| Accept result | Record your judgment for criteria that need human review. |
Only actions allowed by the saved state are enabled. Goals and capsules retain their own pause, resume, allowance, and acceptance controls. Recipe settings remain available from a capsule's task details.
Resume checks the actual execution checkout against accumulated file state. Compatible verified steps can be reused. Unexpected changes invalidate affected steps and dependent work; partial files remain available for inspection. Repairs rerun affected checks and require current results from every configured reviewer. Missing or malformed reviews do not approve the result.
Consumed usage and repair attempts survive restarts. Raising an allowance is an explicit edit and does not erase prior consumption. If an external action or model call ended with an unknown outcome, inspect and reconcile it first. Recording what happened does not authorize replaying the same action.
Restore selected file changes
Restoration is available for captured task-owned edits in Git projects and ordinary folders. It is selective file history, not a complete filesystem backup.
- Open the task's captured changes and select the recorded change for each file you want to reverse.
- Request a preview. Review the proposed differences, eligible files, exclusions, and conflicts.
- Select the ready files and apply that preview. If the task or files changed since preview, refresh it before applying.
- Inspect the result and its restoration-history entry. Use Undo restoration if needed.
A uniquely applicable text reversal preserves unrelated later edits. Conflicting files remain untouched. Binary files require an exact match with the recorded post-edit content. Created and deleted files can also be restored when their captured state is eligible.
Another active chat using the same execution location blocks restoration. Opaque shell edits, uncertain ownership, unsafe paths, and content outside capture limits are shown as exclusions. Current limits are 4,096 candidate files, 64 MiB per file, and 128 MiB per restoration batch including recovery copies; captured history is also bounded.
Recovery data is saved before files change. If restoration is interrupted, reopening shows the saved journal and waits for explicit recovery. Undo or recovery changes only files still matching the recorded restoration; later conflicting edits need manual review. External actions and conversation history are outside file restoration.
Requests survive long work
Requests, steering messages, saved plans, unresolved failures, and progress are preserved independently of generated summaries. Context compaction replaces usable context only after successful summarization and persistence. If essential instructions exceed the selected model's window, Locus reports a limitation instead of silently removing them. Private Identity tasks remain outside ordinary task journals.
The release's deterministic recovery checks do not establish live-provider recovery or comparative performance. Those campaigns remain documented validation limits for the upcoming 3.0 release.