Operations and verification

This guide is published from the pinned source above. Its English text is reproduced exactly; only its presentation is added.

Diagrams are drawn as static images when the site is built. The same flow is written out as text under each one, so nothing depends on a script.

Virgo's operational evidence should follow the same path as real work. Begin with the installed bytes and actual process, then verify the protocol, authority, durable state and receiving conversation. This bottom-up check complements the requirements and acceptance cases used to plan a change.

Read the right status

Observation	What it establishes
Installed artifact and configuration	Which release and settings were selected
Exact process observation	Which process is running and whether Virgo owns it
Protocol health	Whether that service answers the expected protocol
Seat status	The authenticated caller's binding and reported delivery state
Committed message	Durable submission; the recipient may still be unavailable
Native receive/reply evidence	The operation reached the actual provider conversation

Use the exact installation directory returned by the installer. For an existing configured installation, the CLI exposes:

"$VIRGO_BIN" --directory "$VIRGO_INSTALLATION" hub address --network local

"$VIRGO_BIN" --directory "$VIRGO_INSTALLATION" installation inspect \
  --machine "$VIRGO_MACHINE" --component agent_host --instance local-hub

Here VIRGO_BIN, VIRGO_MACHINE and VIRGO_INSTALLATION refer to the verified CLI, target machine and returned installation directory. Hub-address inspection checks the configured address from the calling machine. Installation inspection reads durable installation state; it is not a fresh native-delivery test.

The status operation is a Seat operation. It requires a configured authenticated caller and is not a generic test for whether a newly installed, empty Hub is alive. The runtime's endpoint receipt identifies its actual /health address.

Update and recover an explicit instance

The current preview CLI upgrades one selected instance through prepare, apply and activate. It does not update every Host at once.

"$VIRGO_BIN" upgrade \
  --root "$VIRGO_ROOT" \
  --release "$VIRGO_NEW_RELEASE" \
  --machine "$VIRGO_MACHINE" \
  --instance local-hub \
  --manifest-directory "$VIRGO_MANIFESTS"

Set VIRGO_NEW_RELEASE to the approved exact release and use the correct instance for the intended target. Preserve its preimage and applied plan receipt. Updates must preserve Seat/session identity, history, unsent drafts and unresolved effects.

Rollback selects the exact saved plan, not an arbitrary previous release:

"$VIRGO_BIN" rollback \
  --root "$VIRGO_ROOT" \
  --machine "$VIRGO_MACHINE" \
  --plan-id "$VIRGO_APPLIED_PLAN" \
  --manifest-directory "$VIRGO_MANIFESTS"

VIRGO_APPLIED_PLAN is the retained plan id for the intended change. In the current preview, this command stops execution and restores prior files and configuration. It does not reactivate the restored service. A reported installation state of active must not be interpreted as a running process. Reactivation needs the supported installation lifecycle and fresh process/health verification; this snapshot has no public installation activate command.

Automatic external recovery and cross-Host update convergence are under implementation. Recovery must distinguish intentional stop, staged upgrade, unknown process ownership and genuine service failure. It must preserve unknown message outcomes rather than replaying them as if they had failed.

Verify integrated capabilities from their entrypoints

Capability	Bottom-up path	Required final observation
Ponytail	Installed hook/profile → provider lifecycle event → encoded context → actual conversation	That session receives the expected guidance, with Virgo precedence preserved
Memory	Provider event → authenticated Host queue → Hub-authorized original → automatic derivation eligibility → summary → restore	A continuing conversation receives context derived from its permitted originals
Graphify	Selected repository → filtered snapshot → pinned engine → validated result → shared index → authorized query	The query returns source-linked relationships for the exact repository revision
Conversation routing	Verified human message → selection/authorization → durable recipient transaction → native delivery → correlated reply	Reply reaches the exact original chat conversation and thread/topic
Host recovery	Exact installed process → external failure detection → bounded recovery → protocol/native acceptance	The same logical work resumes, and the independent alert destination receives a real notification

Check both the intended path and the boundary-specific failures: stale attachments, outages, retries, excluded files, unauthorized requesters and unsupported provider behavior. Keep source tests, isolated installed tests and real-provider observations separate.

A test that inserts its own derivation job cannot prove that captured events create jobs. A manually executed hook cannot prove that the provider invokes it. Acknowledging a message through a fixture cannot prove that the user's native conversation received it. Record the unproved connection and its acceptance condition so a green component test cannot hide missing integration.

Report readiness per consumer

Record results for each affected Host and provider session. One successful pilot does not establish every Seat. During a rollout, report applied, verified and blocked separately, with the exact blocker for each incomplete consumer.

The service's own health endpoint cannot be the only way to notice that it has disappeared. Independent outage detection and delivered owner notification remain part of the required operational outcome.