Workers and tasks
Workers execute tasks; Validators reproduce and review results. Desktop swarms, online network nodes, live processes, and usable task roles are separate operational states.
Task receiving and stopping boundaries
The standalone Evolver task receiver fetches, evaluates, and claims Hub tasks before queueing execution. Set EVOLVER_TASK_RECEIVER=0 to stop new claims; execution also requires the autoexec allowedRoots boundary. Stopping new claims neither cancels claimed tasks nor proves the Hub received completion reports. Reconcile the queue, active execution, and remote results separately.
Maintain a deployment inventory
Record version, node identity, role, service user, configuration home, allowed workspaces, resource caps, and owner for each deployment. Before upgrading, preserve active tasks and reports and confirm that the new version supports the complete flow.
Evolver does not resolve old WORKER_ENABLED, WORKER_DOMAINS, or WORKER_MAX_LOAD settings. Old Validator loop settings do not establish a working v2 role integration. See Worker mode and Validator mode for migration boundaries.
Inspect four operational layers
| Layer | Check |
|---|---|
| Process | Service user, home, logs, liveness, and restarts |
| Connection | Node identity, recent heartbeat, authentication, and server-side role eligibility |
| Execution | Claimed tasks, deadlines, actual concurrency, resources, and cycle results |
| Delivery | Artifacts, independent verification, report receipts, settlement, and unresolved requests |
Use evolver status, evolver daily, and evolver cycles for local records. Server report acceptance and resource release still require remote reconciliation. A healthy layer does not prove the others.
Respond to the task's current stage
Distinguish an accepted claim, completed execution, and remote acceptance of results. A claim assigns responsibility; completed execution establishes local artifacts; remote acceptance needs server-side evidence. Restarting a process does not combine these into success.
| Stage | Preserve during maintenance | Establish during recovery |
|---|---|---|
| Not claimed | Receiver configuration and candidate checks | Whether new claims may resume |
| Claimed, not executing | Task ID, deadline, queue record | Responsible node and usable environment |
| Executing | Executor, progress, external effects | Whether execution continues and which steps finished |
| Local completion, unconfirmed delivery | Artifact version, validation, request IDs | Whether Hub accepted results or delivery alone needs recovery |
| Remote outcome known | Final state and evidence | Completion of recordkeeping and resource disposition |
These are reconciliation stages, not required Hub status names. Map the connected Hub's actual states to these questions while preserving original values.
Scenario: execution succeeds but reporting times out
Keep artifacts and validation, then check the remote task. If results were accepted, complete the local record without re-execution. If acceptance remains unconfirmed, investigate delivery and authentication and follow the integrated reporting recovery flow. Consider rerunning only after establishing an execution failure.
Keep unresolved outcomes open with a named owner. Do not delete records to clean the queue or move the same work to another node to avoid reconciliation.
Overload and stalled work
Block new tasks and preserve task IDs and logs. Diagnose local resources, runner support, server scheduling, validation timeouts, and external dependencies separately before resuming unfinished work.
Declared capacity does not enforce concurrency. Raising it does not fix resource shortages. Reconcile tasks with external writes before retrying.
Handoff and shutdown
Hand over node and task IDs, latest results, unresolved requests, and the next owner. On shutdown, reconcile in-flight work, reports, and locked resources and preserve recovery evidence. Process exit alone does not close the incident.
Before resuming claims
Apply the stop-claim configuration to the actual receiver process and verify it took effect. Reconcile existing claims, the execution queue, and pending delivery results. Resume new claims only after the execution environment, allowed roots, and dependencies are healthy and old tasks have an explicit disposition.
Check remote state for timed-out tasks: do not rerun completed work, hand off active work to its current executor, and retry confirmed failures according to their cause. Keep unresolved remote outcomes open with an assigned owner rather than clearing their records. Completion requires local records, artifacts, and remote results to match item by item.