Resident operation and task queues
Before making a verified finite workflow resident, define queue scope, failure handling, monitoring, and shutdown. This page describes the Evolver integration sequence; parameters live in Loops and exploration.
Check execution support
evolver --version
evolver cycle capabilities --json
evolver lifecycle status
Inspect ingestion, injection, execution, verification, and resumption separately. Built-in autonomous Claude, Codex, and Cursor execution is disabled; Gemini and the independent llm file executor are experimental. Session import does not prove background execution support.
Establish a finite loop
In an isolated repository, prepare one material item, a clear objective, and validation commands. Record HEAD and existing edits. Bound the item count and timeout, then inspect cycle results, actual diff, and verification evidence. Success, no material, and failed validation must each produce an understandable outcome.
Cycle processes material; autoexec consumes a task queue and performs resident maintenance; lifecycle manages services. Choose the needed entry instead of treating the old evolver --loop as a universal switch.
Independent LLM file executor
--runner llm needs no coding-agent CLI. It uses a model endpoint with bounded list, read, and write file tools, without model-selected processes or scripts. This executor is experimental; enable it only in an isolated directory and validate each file change.
| Setting | Default or requirement |
|---|---|
EVOLVER_LLM_API_KEY | Required; falls back to OPENAI_API_KEY |
EVOLVER_LLM_BASE_URL | https://api.openai.com/v1; remote endpoints require HTTPS, HTTP only on loopback |
EVOLVER_LLM_MODEL | gpt-4.1; explicitly select an available model |
EVOLVER_LLM_API_BACKEND | chat-completions or explicit responses; not guessed |
EVOLVER_LLM_MAX_TURNS | 12, within 1–64 |
EVOLVER_LLM_MAX_FILE_BYTES | 65536, up to 1 MiB |
The cycle requires --validation-spec <file>: a regular JSON file of at most 64 KiB containing version: 1 and nonempty files, each with relative path and predetermined sha256. Acceptance freezes before material is claimed; model output cannot redefine success. Runs use a private worktree and scrubbed environment. Neither --resume nor combining with --validation-cmd is supported.
Validation checks final bytes against expected digests and detects extra changes. It does not run project tests, prove functional correctness, or claim an OS sandbox. Verify live provider requests and execution from packaged artifacts separately; matching file digests establishes neither outcome. When expected content cannot be predetermined, choose an appropriate verification workflow rather than asking the model to invent its own expected hashes.
Prepare a controlled instance
Use a separate home and isolated repository rather than a production queue. This is a valid <home>/autoexec/config.json structure; replace the repository path before saving:
{
"allowedRoots": ["/absolute/path/to/isolated-repository"],
"pollMs": 30000,
"timeoutMs": 600000,
"runner": "llm",
"workflowValidationProfiles": {
"project-checks": ["npm test", "npm run build"]
}
}
The example selects the experimental llm runner described above; it does not establish support for every task. Validation profiles define named command sets that tasks must actually reference. They do not replace the frozen file-validation specification required by an llm cycle. Use example commands only in projects providing those scripts.
Before startup, set EVOLVER_TASK_RECEIVER=0, EVOLVER_ATP_AUTOBUY=off, and EVOLVER_ATP_AUTODELIVER=off in the service environment, prepare runner credentials, and inspect the existing queue. Observe one explicit task's state and artifacts before widening operation. Retain queue records, runtime logs, and actual diffs separately.
Distinguish task states
| Observation | Establishes | Still requires |
|---|---|---|
| Process alive | Service running | Target task activity |
| Task queued | Pending local intake | Root, runner, and resource eligibility |
| Execution started | Runner accepted the task | Verification and usable artifacts |
| Local validation passed | Corresponding checks passed | Remote submission acceptance |
| New claims stopped | No new intake | Reconciliation of accepted tasks and queued work |
Restart autoexec after configuration changes; SIGHUP does not hot-reload settings. See Evolution strategy and boundaries for selection weights and file limits. This page owns operation, queues, and recovery.
Introduce resident operation
- Configure the selected home’s
autoexec/config.jsonwith approved allowedRoots only. - Check actual runner support, timeout, and workflow validation commands.
- Observe the foreground process for a bounded period, confirming slow cycles do not overlap.
- Enable required Hub and external activity separately before installing a managed service.
- Record the service user, home, logs, restart method, and recovery owner.
An empty allowlist blocks execution. Process liveness does not prove task completion.
Stop and recover
After stopping the process or service, reconcile cycles, queued work, unfinished submissions, and remote state. Keep usable results and retry only unfinished work. Git recovery cannot undo remote effects; reconcile before restarting.
A resident loop grants no extra permission or publication eligibility and does not make another agent application consume terminal output automatically.