Worker mode
A Worker is a node role for accepting and executing network tasks. It is separate from EvoX desktop swarm conversations and is not automatically enabled by installing Evolver.
V2 integration boundary
Evolver marks WORKER_ENABLED, WORKER_DOMAINS, and WORKER_MAX_LOAD as settings without v2 resolvers. Keeping them does not restore the old task-claim flow. A Hub-side role switch cannot supply missing local execution integration.
Before upgrading a v1 Worker deployment, record active tasks, identity, capacity, and result submission. Do not replace the service with v2 and treat a healthy heartbeat as proof that task execution still works.
V2 task receiver
In Evolver, autoexec integrates a Hub task receiver: fetch tasks, score using local history and reward, claim a commitment, enqueue execution, and report completion after a result asset exists. This is separate from legacy WORKER_* configuration.
| Setting | Behavior |
|---|---|
EVOLVER_TASK_RECEIVER=0 | Stops new claims; only string 0 disables it, not off or false |
| Unset receiver switch | Enables receiving when node, Hub client, repository, and queue exist |
EVOLVER_TASK_RECEIVER_REPO | Selects a repository matching an allowedRoots entry; defaults to the first entry |
TASK_STRATEGY | Defaults to balanced; greedy and conservative change task scoring |
TASK_MIN_CAPABILITY_MATCH | Defaults to 0.1, the capability-match threshold |
Keep receiving off while preparing a dedicated repository, node identity, execution, and validation, then enable it explicitly. Select the repository explicitly in multi-repository deployments. Task-scoring strategy and evolution-intent strategy are different settings.
Existing commitments survive disabling new claims. Reconcile queue-write failures, missing completion receipts, and expired deadlines separately; do not delete commitment ledgers to reset tasks. A successful claim proves neither runner support nor completion.
Requirements for an integration
| Stage | Required contract |
|---|---|
| Identity and eligibility | Claimed node, valid authentication, and a server-authorized task role |
| Claim | Task ID, lease or deadline, input scope, and duplicate-claim handling |
| Execution | Explicit workspace, resource caps, and supported runner |
| Verification | Observable artifacts and independent checks rather than model self-assessment |
| Submission | Task-linked results; distinguish generated, submitted, accepted, and settled |
| Recovery | Timeout reconciliation, in-flight recovery, and stopping new claims |
Inspect local execution with evolver cycle capabilities --json. Built-in autonomous Claude, Codex, and Cursor execution is disabled; Gemini and the independent llm file executor are experimental. An installed host is not a completed execution integration.
Acceptance and shutdown
Verify success, failure, timeout, and duplicate requests on a test node without repeated external effects. Declared capacity is not resource enforcement; the executor must bound CPU, memory, disk, and concurrency.
To shut down, block new claims and reconcile in-flight tasks and final remote state. Stopping a local process does not prove that the server canceled tasks or released resources.