工作节点与任务
Worker 执行任务，Validator 复现并审核结果。桌面蜂群、网络节点在线、后台进程存活与这两种角色可用是不同状态，运维时分别检查。
任务领取与停止边界
独立 Evolver 的任务接收器从 Hub 获取、评估和领取任务，再写入执行队列。设置 EVOLVER_TASK_RECEIVER=0 停止新领取；执行还受 autoexec 的 allowedRoots 约束。停止新领取不撤销已领取任务，也不证明完成报告已经被 Hub 接收。分别核对队列、在途执行和远端结果。
建立运行清单
为每个部署记录工具版本、节点身份、角色、服务用户、配置目录、允许工作区、资源上限与负责人。升级前保存正在处理的任务和报告，确认新版本能完整承接原有流程。
Evolver 不解析旧 WORKER_ENABLED、WORKER_DOMAINS 和 WORKER_MAX_LOAD。旧 Validator 循环配置也不能证明新版已完成角色接入。迁移要求见Worker 模式和Validator 模式。
四层运行检查
| 层次 | 要核对的状态 |
|---|---|
| 进程 | 服务用户、home、日志、存活和重启次数 |
| 连接 | 节点身份、最近心跳、认证和服务器角色资格 |
| 执行 | 已领取任务、期限、实际并发、资源使用与周期结果 |
| 交付 | 产物、独立验证、报告接收、结算和未决请求 |
本地可使用 evolver status、evolver daily 与 evolver cycles 查看相关记录；服务器是否接收报告或释放资源仍需核对远端状态。任一层正常不能替代其他层。
按任务所处阶段选择处理方式
运维需要区分“领取成立”“执行完成”和“远端接受结果”。领取成立意味着节点已经承担任务，不能再把它当成未领取候选；执行完成说明本地产物已生成，仍要核对报告交付；远端接受结果则需要对应的服务端状态作为依据。进程重启不会自动把这些状态合并成成功。
| 当前阶段 | 维护时保留什么 | 恢复时确认什么 |
|---|---|---|
| 尚未领取 | 接收器配置与候选检查结果 | 是否允许恢复新领取 |
| 已领取、尚未执行 | 任务 ID、期限、队列记录 | 当前责任节点和可执行环境 |
| 执行中 | 执行者、进度、已产生的外部结果 | 原执行是否仍在运行，哪些步骤已完成 |
| 本地完成、交付未确认 | 产物版本、验证报告与请求标识 | Hub 是否已接收，是否只需恢复交付 |
| 远端结果明确 | 最终状态与关联证据 | 记录归档和资源处置是否完成 |
表中的阶段用于运维对账，不要求 Hub 使用相同的状态名称。对接具体 Hub 时，应将远端状态映射到这些实际问题，保留原始状态值，避免自行改写任务结果。
场景：本地任务成功，但报告请求超时
先保留现有产物和验证结果，查询该任务的远端状态。如果远端已经接受结果，补齐本地交接记录即可，不重新执行。如果远端仍未确认，继续排查交付请求和认证，按实际接入的恢复流程处理报告。只有确认执行本身失败，才评估重新运行任务。
在远端结果未明时，任务保持未决，由指定负责人继续对账。不能因为本地队列需要“变干净”而删除记录，也不能将相同工作再次领取到另一节点来回避结果核对。
过载或卡住
先阻止新任务，保留当前任务 ID 和日志。按本地资源、执行器支持、服务器调度、验证超时和外部依赖分开排查，再恢复未完成部分。
声明容量不能限制真实并发，也不能通过提高数值解决资源不足。对已经发生外部写入的任务先对账，再决定重试。
交接与停用
交接时提供节点、任务、最近结果、未决请求与下一步负责人。停用时核对在途任务、报告和锁定资源，保留恢复证据，不能仅以进程退出结案。
恢复领取前的检查
将停止领取配置应用到实际任务接收进程并验证生效，再逐项核对已领取任务、执行队列与待交付结果。只有执行环境、允许工作区和依赖恢复正常，且旧任务已有明确处置，才恢复新领取。
超时任务先查远端状态；已完成的不重复执行，仍在执行的交接当前执行者，确认失败的再按失败原因安排重试。无法确认远端结果的任务保留为未决并指定负责人，不能直接清空记录。完成标准是本地记录、产物和远端结果能够逐项对应。