v1.8.0 — read-only mode, working policy defaults, declared environments

Family release driven by VMware-AIops#31,
where an operator running Llama 3.3 70B (Goose / OpenShift AI, on-prem H100) had to
hand-write 17 prompt guardrails to make tool calling reliable. A prompt is advisory — a
model can ignore it. Every guardrail that could move into the harness has.

Added

• Read-only mode. Set VMWARE_READ_ONLY=true (or VMWARE_<SKILL>_READ_ONLY, or
  read_only: true in config.yaml) and every write tool is removed from the MCP registry
  at start-up. list_tools() never offers them, so the model cannot call what it cannot
  see. Off by default — nothing changes unless you turn it on. Fail-closed: if the
  mode is requested but cannot be guaranteed, the server refuses to start rather than
  running open.
• environment: on each config target, declaring which environment it is
  (production / staging / lab). Policy rules scope by this value.

Added — list results now state whether they are complete

Every [READ] list tool returns the family envelope instead of a bare array:

{"items": [...], "returned": 50, "limit": 50, "total": 213,
 "truncated": true, "hint": "Showing 50 of 213. Raise limit or narrow the query..."}

This closes the reported failure where long responses were summarised as "no data
returned": a bare list gives a model no way to tell a complete answer from page one, so
it guessed. truncated: false now positively states completeness — including when
items is empty, which means "checked, found none", not "the call failed".

• 10 tool(s) converted across ops, MCP and CLI. Real totals come from suite-api's pageInfo.totalCount. Suppressed on purpose where
  it would mislead: with name_filter set, totalCount counts the unfiltered
  collection, so reporting it beside filtered rows would answer a question nobody asked.
  list_anomalies returns only flagged VMs, so it reports a total only when the scan
  stopped short — a short list is otherwise not evidence of completeness.

Changed — migration, read this

• Approval tiers now actually run. They shipped in v1.6.0 but the engine only ever
  read ~/.vmware/rules.yaml, and a fresh install has no such file — so every deny rule,
  maintenance window and approval tier had been inert on every install that never
  hand-authored one. A packaged baseline now loads when you have written no rules of your
  own. Writes at medium risk and above are stamped with their tier in the audit log;
  irreversible work and guest execution against a target declared production require a
  named approver via VMWARE_AUDIT_APPROVED_BY.

• environment: will become required for writes. Today a state-changing operation
  against a target that declares none still runs and logs a warning. The next major
  release refuses it. Declare it now and that upgrade is a no-op:

  targets:
    prod-vc01:
      host: vc01.corp.local
      environment: production
  

  Read-only operations are never affected, in this release or the next. Check what applies
  to your targets before upgrading: vmware-audit policy --operation vm_delete --env <env>.

Fixed

• Policy glob patterns with a leading wildcard silently matched nothing. A rule written
  operations: ["*_delete"] parsed fine, read correctly, and never fired — only a trailing
  * was honoured. Now full glob matching, for operations and environments alike.
• Config-path overrides (VMWARE_<SKILL>_CONFIG) are honoured when reading read_only
  and environment, so a setting in a custom config file is no longer silently ignored.

Notes

• Requires vmware-policy>=1.8.0; publish that package first.
• vmware-audit policy reports which rules are in force and where they came from —
  including the case where your rules file exists but failed to parse, which previously
  looked identical to "policy is working".

Added

• investigate_alert (27 → 28 tools, 21 read / 7 write). Resolves an alert to
  its affected resource in one call: fetches the alert, reads resourceId, fetches
  that resource, confirms name and kind, and returns both UUIDs explicitly
  labelled plus a ready-to-use handoff naming the exact vmware-monitor tool and
  argument. Replaces the three prompt guardrails the reporter had to hand-write to
  stop a small model swapping the alert UUID for the resource UUID. An unresolvable
  resource degrades to a warning plus explicit nulls rather than losing the alert.
• references/agent-guardrails.md — operating this skill with a local/small model.