Recovery and follow-up
Partial completion does not always require starting over. First distinguish an unacknowledged request, failed execution, and completed work that needs extending.
Consider the release-guide review: feature descriptions are checked, but instruction checking was interrupted. The aim is to preserve valid findings and finish what is missing.
Identify the situation
| Situation | Check first | Next step |
|---|---|---|
| Submission remains unacknowledged | Task records and receipts | Use the existing request's retry action instead of sending repeated new tasks |
| One branch failed | Cause, records, and files already written | Resolve the cause and define the remaining scope |
| Work was stopped | Completed work and any uncertain stop state | Confirm actual state before continuing |
| Reviews finished but synthesis is incomplete | Whether all review records exist | Reconcile the existing records rather than collecting them again |
| A completed goal needs another check | Reusable findings and changes to inputs | Add a separate follow-up task |
Request retry, execution rerun, and synthesis are different operations. “Retry” does not guarantee seamless continuation from the last step.
Preserve valid output
Inspect completed records for the material version, coverage, and findings. If edits were allowed, inspect current files as well.
The feature review may remain useful, but if the release guide has since changed, old findings may no longer apply. Reuse evidence that is still valid, not merely a completed status.
Finish only what remains
Address the cause first: supply missing inputs, clarify permissions, or resolve overlapping file ownership. Sending the same instruction again may reproduce the same failure.
Keep the completed feature review. Check which instruction-review records survived the interruption, then cover only the unreviewed sections. Use the current release guide without editing it. Combine new findings with the existing review and remove duplicates.
Continuing the original task depends on retained runtime state. Use its recovery capability where the original task can be associated. With incomplete state, give a new task the existing records and remaining scope, and confirm what still needs doing before execution.
A task that wrote files, sent messages, or performed external actions may repeat them when rerun. Stopping does not undo those actions. Check their outcomes before proceeding.
Extend existing results
If both reviews finished and you now need terminology checked:
Add a terminology check to this review. Use the same version of the release guide and refer to completed review records. Identify different names for the same feature. Report only new issues, then update the consolidated suggestions without repeating feature or instruction checks.
Related work can reuse existing material. If the goal or inputs have changed materially, describe the change and reassess which old results still apply.
This differs from Continuous swarm: this guide concerns building on existing results; continuous swarm concerns receiving new work while the main AI is busy.
Recover recursive tasks
Recursive tasks have their own tree and snapshots. Before using Inspect and resume, refresh the state and identify which prerequisites need recovery and which downstream nodes are still waiting.
Ordinary reruns, continuous request retries, and recursive snapshot recovery handle different states. Without a recovery action, inventory the existing artifacts and remaining work, then start a smaller, clearly scoped task.
Integrate again
After recovery or follow-up, ask the main AI for an updated deliverable against the original goal, retaining unresolved issues. The final answer should not remain scattered across separate retries and additions.