v2.4.0 — runs its own steps on request; honest gates and rollback (first real-vSphere run)

Behaviour changes for existing callers

• approve refuses a gate whose earlier steps were handed out (not_executed) until
  acknowledge_not_executed=True — this applies to the default MCP server and to workflows saved by 2.3.0 that are
  already awaiting approval. An automated approve caller must pass the flag after performing the steps.
• clone_and_test requires snapshot_name (it used to clone from a snapshot literally named current).
• Rollback reports a step without an undo as not_reversible (was skipped); approval gates and catalog reads are no
  longer listed. A rollback whose undo failed or whose effect is unknown returns action: "rollback_incomplete" with
  outcome: "failed" and an error naming them (it said rolled_back).
• cancel_workflow keeps handed-out steps not_executed (was rewritten to skipped).
• With vmware-policy 1.24.2, Pilot's own refusals and failed outcomes (run_workflow/approve ending
  outcome: "failed", refusals carrying error, an incomplete rollback) are isError frames; previews,
  awaiting_approval and dispatch_required are not.

Details

• A step result's kubeconfig (a bearer token from VKS issue_*_kubeconfig under --dispatch) is masked in
  workflows.db like a password. With --dispatch, a skill's failed call keeps its own error envelope (hint
  included) instead of a flattened JSON string.

Found running Pilot workflows on vCenter 8.0.3 for the first time, through the MCP server and through an embedder
that dispatched steps to the 2.4.0 skill servers.

• clone_and_test works on real vSphere. It cloned from a snapshot literally named current (almost no VM
  has one) and resized the clone after powering it on, which vCenter refuses (MemoryHotPlugNotSupported) on any
  VM without hot-add. Now snapshot_name is required (no default; the error names list_vm_snapshots), the
  clone is made powered off, staging is resized while off and then powered on, and the check is vmware-monitor
  investigate_vm on the staging VM instead of get_alarms for the whole vCenter. A guest command runs after
  power-on. 7 steps (8 for a guest command). Pilot still does not wait monitor_minutes: the approval message
  asks the approver to, says a running production VM is resized in place (needs hot-add), and that the production
  change is not rolled back. The clone step no longer claims a rollback (powering a clone off does not remove it).
• approve refuses a gate whose earlier steps nobody ran. Through the MCP server (no dispatcher) every step
  before the gate is not_executed, and the gate used to pass under "Staging VM … tested". It now refuses and
  lists them in not_executed_before_gate; acknowledge_not_executed=True records them as reported_done
  (performed outside Pilot) and they are not handed out again. Pilot never saw their results: through MCP a later
  step that references one is handed out with the reference unresolved (fill it from that step's result), and
  an embedder that dispatches it refuses it. An embedder with a dispatcher is unaffected unless it resumes a workflow
  that was first run without one — then the same refusal applies. The acknowledgement is the caller's
  statement, not a check: Pilot records who sent it, not what the steps returned.
  SKILL.md now says plainly who executes steps: through MCP the agent does, and a workflow never reaches
  completed that way.
• Rollback says what it cannot undo. A step with no rollback is reported not_reversible (it was skipped,
  "no rollback defined"); a rollback that does not remove what the step created — a clone powered off — is
  partial with left_behind, and the step is partially_rolled_back. The preview carries the same:
  leaves_behind on such entries and left_in_place_note. Approval gates are no longer listed as skipped.
• Failure is read from the frame, not from prose. Besides isError and a top-level error on a plain
  dict, a top-level error in an MCP result's structured content and a one-row [{"error": ...}] list now fail
  the step, the last step included. A string is never read as failure, even one starting Error: — decided,
  as in vmware-policy, because tools return console text that can start that way. A skill must set isError;
  AIops's linked clone returned its failure as prose in 2.4.0 and is fixed there (it now raises).
• Pilot can run the steps itself: vmware-pilot mcp --dispatch (or VMWARE_PILOT_DISPATCH=stdio), off by
  default (HLD §19, D-26). Each step runs in that skill's own MCP server (vmware-<skill>-mcp), so its policy,
  confirmation gate and audit apply; nothing after an approval gate runs before approve; workflows reach
  completed. stdio only — refused with --transport https/http, and a call with a network caller is refused.
  Only the family's skills (not pilot) are started, without a shell. A step that exceeds
  VMWARE_PILOT_DISPATCH_TIMEOUT (default 1800 s) is recorded interrupted (effect unknown), as is a step whose
  skill server died after the call was sent; a server that never starts fails the step with its reason. Every
  step's skill is resolved before step 0 runs; settings are checked at start (VMWARE_PILOT_DISPATCH must be
  stdio or unset). A step already handed out in pending_dispatch is never run again by a --dispatch Pilot.
  Results are stored as the tool's own data, so __from_step_N__:key works; a reference to a key the step did
  not return is refused (it used to send the whole result in its place). Failure is read from the frame:
  skills' failed calls arrive as isError once they run vmware-policy with vmware_policy.frame (vmware-policy
  1.24.2). With an older Policy, 13 of 14 skills sent failures with isError: false; Pilot catches the
  {"error": ...} envelope itself, but a string-shaped failure (mostly AVI's) reads as success.
  Pilot's tools are synchronous: set the MCP client's tool timeout above the longest step.
• A guest command (run_vm_guest_command, _with_output) that exits non-zero now fails the step (it was recorded
  as success); one that timed out or whose process vanished (exit_code -1) is interrupted — it may still be
  running. A clone left partially_rolled_back is still listed by a second rollback; an undo whose effect is
  unknown marks its step interrupted. The rollback preview lists a rollback attached to a read step.
• investigate_vm added to the design catalog (101 tools).
• Two new step statuses, reported_done and partially_rolled_back. Pilot 2.3.0 does not know them: reading a
  workflow that has them, its rollback / cancel_workflow refuse ("unrecognised status") rather than guess.
• The rollback preview gains not_reversible_outside_pilot (steps handed to the caller with no undo — a clone,
  a production resize; tools the catalog marks read-only left out) with a note; through MCP those used to appear nowhere in the
  preview. The cancel preview gains handed_out_to_caller: steps already in pending_dispatch, which cancel
  can neither stop nor undo — they used to be listed as would_skip, and cancel now keeps them not_executed
  on the record instead of rewriting them to skipped.