Stand Operations

The stand is a singleton live environment shared by the agent fleet. Since 1.3.0, agents coordinate access through a lease-backed state file instead of the old stand_requests/, stand_wip/, and stand_done/ queues.

State File

The source of truth is:

coordination/.stand/state.yaml

greatminds stand status reads that file and prints the current state, active lease, pending FIFO queue, and recent transition history.

The stand has four states:

State	Meaning
free	No active lease. The next lease can be granted immediately.
preparing	STAND-KEEPER is deploying or restarting the stand for the active lease.
ready	The stand is ready for the lease holder to run probes.
down	Stand operation is paused because deploy or infrastructure recovery is needed.

Each active lease carries a lease_id, task id, worktree path, profile, holder role, grant timestamp, optional ready timestamp, and TTL. Pending leases wait in FIFO order in the same state file.

Lease Flow

The role that needs a live stand requests a lease:

greatminds stand lease --task <task-id> --worktree <path> --profile <profile>

If the stand is free, the lease becomes active and the state moves to preparing. If another lease is active, the new lease is appended to the FIFO queue. The command prints the lease_id; the requester must keep that token.

STAND-KEEPER watches coordination/.stand/state.yaml and runs:

greatminds stand status

When state is preparing, STAND-KEEPER deploys from the lease worktree using the lease profile. On success:

greatminds stand ready --lease-id <lease-id>

That moves the state to ready and files an inbox-info message to the holder: stand lease <lease-id> ready; task=<task-id>.

The holder, usually TESTER or EXPLORER, then runs its own probes against the prepared stand and releases the lease:

greatminds stand release --lease-id <lease-id> --result pass|fail|partial

Only the lease holder can release an active lease. Releasing moves the stand back to free; STAND-KEEPER handles the next queued lease on a later tick.

TTL And Recovery

Leases have a default TTL from schema.yaml (stand.resource.lease), currently four hours, with a warning window before automatic release. The TTL is a safety valve for abandoned leases; it is not a substitute for explicitly releasing a lease after probes finish.

If deployment fails or the stand has an infrastructure incident, STAND-KEEPER runs:

greatminds stand down --reason "<operational reason>"

down pauses queue processing. After recovery:

greatminds stand up --reason "<recovery note>"

That returns the stand to free so queued work can resume.

Evidence Boundary

STAND-KEEPER only proves infrastructure readiness: process status, health endpoint availability, remote reachability, GPU availability when requested, and equivalent bring-up checks. It does not run product acceptance tests.

Functional verification belongs to the lease holder. For stand-required tasks, TESTER records the lease evidence in the product task's tests block, including stand_evidence.lease_id, result, commit, worktree fingerprint, and its own functional_probes plus stand_evidence.tester_observations. greatminds gate-check <task-id> reads that tests-block evidence first.

The old queue artifacts are removed from the active workflow. Do not create new stand_requests/, stand_wip/, or stand_done/ tasks for current stand operations.