Pilot rollout and acceptance

Use this checklist to accept a first deployment or upgrade of standalone Evolver. Acceptance covers one runtime with a fixed version, identity, and data directory.

Use one node as a pilot and verify installation, identity, policy, service lifecycle, and recovery before expanding to a team or long-running environment.

Prepare Node.js ^22.13.0 || >=23.4.0 and Git before installation, then use evolver --help to inspect commands.

Before the pilot

• Assign an owner, environment, Hub, identity home, and data home.
• Pin the sources of Node.js, Evolver, and related application versions.
• Back up node identity, GEP assets, configuration, and events.
• Disable unneeded Worker, Validator, auto-publish, and paid behavior by default.
• Set task-level file caps, line caps, forbidden paths, and validation commands.

Design a pilot that answers operational questions

Choose a task with explicit inputs, expected artifacts, and independent validation. It should be repeatable in a test environment, with initial file state recorded. Startup alone does not validate task boundaries, stopping controls, or recovery.

Cover three cases: permitted work completes, a request outside a configured boundary is denied, and interrupted work can be reconciled and recovered. Test only controls implemented by the target version, in isolated test directories. Do not probe restrictions using production credentials or real purchases.

For a pilot limited to one test repository, check artifacts and validation in the success case, enforcement of the configured execution root in the boundary case, and existing artifacts after a controlled stop in the recovery case. Retain each result separately.

Expand into continuous operation

List differences from the pilot: service user, launch method, directories, platform, networking, and task volume. These determine what must be revalidated. Moving from a terminal to a system service requires checking the configuration and directories read by the service process.

Separate software upgrades from policy expansion. Validate a new version under existing boundaries before enabling additional capabilities. Keep both software version and configuration in the rollout record so failure can be traced to a specific change and recovery has a defined target.

Start and inspect

evolver doctor
evolver status
evolver lifecycle status
evolver lifecycle check

For continuous operation, choose the supported Windows service, systemd, or launchd installation. After startup, verify process identity, latest heartbeat, data home, and the stop path rather than checking only that a process exists.

Legacy scheduled tasks

Check for legacy scheduled tasks and duplicate startup entries before and after an upgrade. Preview cleanup first:

evolver lifecycle cleanup-legacy-tasks --dry-run

Clean only after confirming the targets and preserving the preimage. If cleanup removes the wrong entry, restore from the saved preimage instead of guessing the original task arguments.

Acceptance criteria

1. One bounded task completes with inspectable evidence.
2. Stop, restart, and operating-system restart match policy without duplicate processes.
3. A backup restores into an isolated directory and its events and assets can be read.
4. Network roles, publishing, and budget behavior match the inventory.
5. The owner can locate a failed request without reading clear-text secrets.

Keep any failure within the pilot, restore the old configuration or stop the service, and investigate before expansion.

Produce a handoff-ready acceptance record

For a first deployment, preserve the initial configuration. For an upgrade, retain the previous version, directory inventory, and claimed-task state. Use a verified launch entry and avoid starting a manual process and system service for the same instance. See Evolver CLI for tool installation; use the installed version's evolver lifecycle --help for service installation and launch parameters.

For each acceptance item, record the target, observed result, evidence location, time, and owner, marking it passed, failed, or not run. An unperformed restore drill or stop check does not establish readiness for long-running use. Apply the same checklist to each new instance; an existing node's acceptance does not cover new nodes.

Related pages

• Monitoring
• Incident response

EvoX Docs · Developers · Deployment and policy