v2.5.1

v2.5.1 (2026-11-10) — Separate dispatch result interpretation and refusals

Extract dispatch-result classification and execution-refusal helpers, preserving preview-only failures, guest commands with unknown effects, sensitive-placeholder refusal, workflow state and public import aliases. Workflow execution and rollback semantics remain unchanged.

Validation: existing suites, complete CLI/MCP surface comparison, structural guard checks and security scanning; exact results are retained in the private release record. Live 9.1/Supervisor, PAIS, NSX and Horizon validation is not established by synthetic tests.

中文：本轮修复和重构范围见上述说明；保留既有 Policy、审计及确认门。合成测试不代表 9.1/Supervisor、PAIS、NSX 或 Horizon 正向真机验证。

v2.5.0 — Explicit ClusterClass references in VKS deployment workflows

Released 2026-11-09.

• Synchronize the companion-tool contract snapshot with the new optional VKS creation arguments.

• Allow explicit ClusterClass name/namespace in the VKS deployment template, omitting new arguments for legacy callers. Requires the companion VKS skill 3.7.0 or newer; no live 9.1 validation is claimed.

v2.4.3 — Gemini extension packaging

Released 2026-11-09.

Add the root Gemini CLI extension manifest and discovery metadata, using the existing canonical skill and exact MCP package version. No duplicate skill entrypoint is introduced.

Runtime infrastructure operations, permissions, TLS defaults and confirmation behavior are unchanged. No new vSphere/VCF 9.x or live product compatibility is claimed. ClawHub skill and bundle verdicts are checked separately after publication; documentation corrections are not a clean-scan claim.

v2.4.2 — refresh companion tool contracts (2026-11-08)

• Update public author/project contact metadata to zhouwei008@gmail.com.

• Refresh the companion contract for Monitor log selection and the PAIS gallery; no Pilot runtime/tool-count changes.

v2.4.1 — VKS 9.1 upgrade risk in the companion catalog (2026-11-01)

• The companion-tool snapshot now includes VKS 3.5.0's read-only get_supervisor_upgrade_risk tool. The documented VKS and family tool counts match the live registries. Pilot's workflow execution behavior is unchanged.
• Install VMware-VKS 3.5.0 or later to use that tool. Its advisory report does not measure VUMDB schema or establish upgrade clearance.

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.

v2.3.0 — roles for network callers (HLD §18)

• Workflows record their creator (created_by: the network caller token:<name>, or the OS user). Workflows saved
  before this release have none.
• With vmware-policy ≥ 1.24.0 and roles enabled, approve follows the caller's role: approve: none cannot
  approve, approve: others cannot approve a workflow its own token created (nor one with no recorded creator),
  approve: any can. The token also needs a role that allows the approve tool itself. Whoever edits a draft
  (update_draft) or confirms it (confirm_draft) is recorded in authors and counts as its creator for
  others; so is whoever saved a custom template, for workflows made from it (the YAML records authors).
  A refusal is audited as denied with rule=role:<name>.
• Approval is an audited attestation, not a gate on execution: this server does not run other skills' steps, it
  returns them (pending_dispatch) and each skill's server checks the caller's own role there.
• Declares role metadata (no tool takes a target). README and setup guide: one endpoint for several people or roles.

v2.2.0 — serve MCP over HTTPS

vmware-pilot mcp can now serve the network as well as stdio (HLD §16, via vmware-policy 1.21.0):

vmware-audit token create alice          # once per caller; shown once
vmware-pilot mcp --transport https --host 0.0.0.0 --port 8443 \
    --cert server.pem --key server-key.pem --public-name mcp.example.com

Connect a client and manage callers (Claude Code shown; any MCP client with streamable HTTP and custom headers works):

claude mcp add --transport http vmware-pilot https://mcp.example.com:8443/mcp \
    --header "Authorization: Bearer $VMWARE_MCP_TOKEN"
vmware-audit token list                  # names only
vmware-audit token revoke alice          # refused from its next request, no restart

• Every request needs Authorization: Bearer <token>; the server will not start without a token, refuses Host or
  Origin values outside --public-name, and checks itself (unauthenticated requests must get 401) before it
  binds. --transport http binds loopback only, for a TLS-terminating reverse proxy.
• Audit rows record the caller as token:<name> and the surface as mcp-https. Calls naming different targets
  run in parallel; calls naming no target run one at a time.
• Over HTTPS, approve records the authenticated caller as the approver and refuses a different free-text
  name (HLD §16 D-12). stdio and the CLI are unchanged.
• stdio remains the default; the vmware-pilot-mcp console script and python -m are unchanged.
• Everyone who can reach the endpoint acts with this server's account; run one endpoint per privilege level.
• Requires vmware-policy>=1.21.0 and mcp>=1.28.

v2.1.0 — offer only read tools, plus chosen write tools

vmware-pilot mcp can now offer a subset of this server's tools (HLD §17 D-16, via vmware-policy 1.20.0):

vmware-pilot mcp --expose read --allow-write cancel_workflow

• --expose read (or VMWARE_PILOT_MCP_EXPOSE=read) keeps only tools annotated readOnlyHint: true; --allow-write a,b
  (or VMWARE_PILOT_MCP_ALLOW_WRITE) keeps chosen write tools on top. The default is unchanged: every tool.
• A bad value, or a name that is not a write tool of this server, stops the server before it serves (exit 2).
  Flags and environment variables are not mixed; a blank flag counts as not given. Pre-2.0 names are accepted.
• This limits what clients are offered; it is not authorization. See "Limiting which tools are offered" in
  references/setup-guide.md, which also notes that an agent with a shell can bypass MCP, so the account itself
  must be least-privilege.
• Requires vmware-policy>=1.20.0.

v2.0.0 — create_workflow_from_template, and VKS kubeconfig tools at their new names

Breaking: one of Pilot's own MCP tools is renamed. plan_workflow → create_workflow_from_template.
It never produced a dry-run plan: it builds the steps a template (workflow_type + params, built-in or
custom YAML) defines and saves the workflow in state pending, ready for run_workflow — a write.
"plan" read as a look that changes nothing. The new name says what it does and sets it apart from
create_workflow, which saves a step list you write yourself. Parameters, results, risk label and
annotations are unchanged; the MCP instructions and the tool's description now say this.

Old	New
plan_workflow	create_workflow_from_template

• vmware-vks renamed get_supervisor_kubeconfig → issue_supervisor_kubeconfig and
  get_tkc_kubeconfig → issue_tkc_kubeconfig (they hand out a live credential). The skill catalog
  lists them under the new names, still at high (credential access is gated).
• CLI commands are unchanged.
• Saved workflows keep working: a stored workflow, YAML file, draft or undo descriptor whose step names
  pilot.plan_workflow or a VKS get_*_kubeconfig tool is translated to the new name when Pilot builds
  the step, like the other 2.0 renames.
• Deny rules in ~/.vmware/rules.yaml written with the old names keep working (vmware-policy matches
  both names); vmware-audit policy lists any rule that now matches more.
• Requires vmware-policy ≥ 1.19.0, which carries these three pairs in
  vmware_policy.renames.
• Upgrade vmware-vks to 3.0.0 together with this release. Pilot 2.0 calls the kubeconfig tools by
  their new names, which vmware-vks 2.x does not register; Pilot does not depend on vmware-vks, so
  upgrading Pilot alone leaves those steps pointing at tools that do not exist yet.