durmem keeps your agents on track.

Tutorial 10C: Read Fleet health and clean up safely

Tutorial 10B covered independent tasks and review. This page explains how Fleet's desired settings differ from current worker health, and where to look before an operator changes or removes a worker.

What you will learn

You will distinguish a residual's configuration status from a worker's heartbeat, inspect one computer without exposing secrets, and choose the right cleanup layer. This is an operator guide; do not change a live Fleet unless you are authorized to do so.

Before you begin

Follow the Fleet guide first: bootstrap a trusted computer, install its vault key out of band, verify harness and Git access, then install and check the residual before publishing workers. Tutorial 10B is background, not a prerequisite for Fleet installation. Use a separate authenticated operator session, not a worker's fixed session, and approve that exact interactive session before enrolling it.

1. Separate Kanban and Fleet

Kanban records agents, tasks, runs, and messages. Fleet is an operator-managed desired configuration that a non-LLM residual reconciles into local checkouts, harness sessions, and schedules. Fleet is not an arbitrary command channel. Keep a residual on each computer that Fleet must continue to control, even when its desired worker count is zero.

2. Read identities and health

Use the /kanban page for the board. For Fleet status, an authenticated operator reads fleet_host_status and the kanban_agent records. Group workers by a non-empty stable host_id; hostname, IP address, and OS are useful observations but do not identify a host.

A host's Fleet configuration is converged only when its status is fresh, state is converged, and seen_revision and applied_revision match the desired revision. Check each expected worker separately for a fresh heartbeat. A residual can be converged while a worker is unavailable, and a worker can be dormant but healthy after its harness unloads following an idle hour. A desired count alone proves neither enrollment nor liveness.

An inspection should keep host status and workers separate and avoid secrets: host ID, display hostname/IP/OS, residual freshness, revisions, worker harness/model, and actual home repository. Do not print configuration files or credential material.

Ask the operator agent to return that read-only inventory for kanban, with desired, seen, and applied revisions and each expected worker's separate health. Do not ask it to change capacity yet. Success is an evidence-backed distinction between converged, pending, degraded, stale, and healthy dormant workers, not a single green host row.

3. Change desired capacity only with operator authority

A worker family is scoped by (host_id, repo_name, harness); slots are controlled by its desired count. The repository URL, branch, board, host, harness, and slot determine which checkout and native session belong to it. Adding workers is not a live shell command.

Before publishing a change, verify the target host and residual are fresh, preserve unrelated entries, and review the complete secret-free before/after difference. The Fleet portal rejects an edit based on a stale loaded revision. The CLI publish workflow is not an atomic compare-and-publish operation: re-read the current revision before publishing and stop if it changed. A published revision remains pending until the host reports matching applied state.

4. Keep credential and cleanup boundaries

The Kanban store key grants board access; the Fleet vault key decrypts credential profiles. They are different secrets. The vault key is pushed out of band by a trusted human and is never sent in response to a task or message. Every trusted host that holds it can decrypt every Fleet profile on that board; a worker assignment is not a confidentiality boundary from another worker on the same host. Removing a worker does not revoke that host's key.

Use the layer that matches the intended cleanup:

Never delete a managed checkout, schedule, or state directory by hand or by guessed PID. Use current status and the owning workflow's logs before recovery. On Windows, scheduled workers start only after the OS user signs in; Fleet does not store an OS password.

Return to the Kanban overview or Fleet guide for the setup sequence.