vmware-debug 1.8.0__tar.gz → 1.8.1__tar.gz

{vmware_debug-1.8.0 → vmware_debug-1.8.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: vmware-debug
-Version: 1.8.0
+Version: 1.8.1
 Summary: VMware diagnostic brain — read-only incident triage, log/event correlation, and root-cause routing across the VMware skill family
 Author-email: Wei Zhou <wei-wz.zhou@broadcom.com>
 License-Expression: MIT

{vmware_debug-1.8.0 → vmware_debug-1.8.1}/RELEASE_NOTES.md

@@ -1,3 +1,24 @@
+## v1.8.1 (2026-07-19) — read-only mode reaches the surfaces that teach it
+
+v1.8.0 put read-only mode in the code and documented it in the README only.
+Every other layer was empty, and each serves a different reader: SKILL.md is what
+the agent loads, setup-guide is what an operator reads while configuring, `doctor`
+is where they verify it took. The gap had two concrete costs.
+
+An agent read SKILL.md, called a write tool the gate had withheld, and got nothing
+back — with no way to learn that the absence was a deliberate lockdown rather than
+a fault. It reads as a broken tool, so the model retries or hunts for a workaround.
+
+An operator who set the switch had no way to confirm it. The only signal was a line
+in the MCP server's start-up log.
+
+### Added — the feature is now documented where each reader looks
+
+SKILL.md, setup-guide and capabilities now cover read-only mode. Both tools here
+are reads, so nothing is withheld — the gate instead verifies that at start-up
+rather than taking this documentation's word for it. Env vars are the only switch;
+this package has no config file.
+
 ## v1.8.0 (2026-07-18) — read-only mode, working policy defaults, declared environments
 
 Family release driven by [VMware-AIops#31](https://github.com/zw008/VMware-AIops/issues/31),

{vmware_debug-1.8.0 → vmware_debug-1.8.1}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "vmware-debug"
-version = "1.8.0"
+version = "1.8.1"
 description = "VMware diagnostic brain — read-only incident triage, log/event correlation, and root-cause routing across the VMware skill family"
 readme = "README.md"
 license = "MIT"

{vmware_debug-1.8.0 → vmware_debug-1.8.1}/server.json

@@ -7,12 +7,12 @@
     "url": "https://github.com/zw008/VMware-Debug",
     "source": "github"
   },
-  "version": "1.8.0",
+  "version": "1.8.1",
   "packages": [
     {
       "registryType": "pypi",
       "identifier": "vmware-debug",
-      "version": "1.8.0",
+      "version": "1.8.1",
       "transport": {
         "type": "stdio"
       }

{vmware_debug-1.8.0 → vmware_debug-1.8.1}/skills/vmware-debug/SKILL.md

@@ -113,6 +113,18 @@ a recommended plan.
 See `references/event-envelope.md`. The agent normalises each source's events into this
 shape; debug stays source-agnostic and has no dependency on the other packages.
 
+## Read-Only Mode
+
+Both tools here are reads, so read-only mode withholds nothing — but
+`VMWARE_DEBUG_READ_ONLY=true` or the family-wide `VMWARE_READ_ONLY=true` still applies, and
+the gate verifies at start-up that zero write tools are exposed rather than taking this
+document's word for it. Debug has no config file, so the env vars are the only switch. The
+same family variable withholds write tools across every companion skill, so a whole-estate
+audit posture is one setting — and when you route a fix to vmware-aiops or vmware-pilot and
+the tool is missing from *their* `list_tools()`, that is the lockdown, not a fault. Do not
+retry or hunt for another route: name the blocked operation and say an operator must clear
+the switch and restart that server.
+
 ## CLI Quick Reference
 
 ```bash

{vmware_debug-1.8.0 → vmware_debug-1.8.1}/skills/vmware-debug/references/capabilities.md

@@ -7,6 +7,11 @@ Read-only, offline incident correlation. No network, no credentials, no writes.
 | `incident_timeline` | `{event_count, window, spikes:[{start,end,count,zscore}], hypotheses:[{category, score, summary, evidence_count, first_seen, last_seen, sample_text, suggested_check}], next_checks:[...]}` | 300–2000 (scales with hypotheses) |
 | `list_symptom_categories` | `{items: [{category, example_keywords, suggested_check}], returned, limit, total, truncated, hint}` | ~400 |
 
+> Read-only mode (`VMWARE_DEBUG_READ_ONLY=true` or the family-wide `VMWARE_READ_ONLY=true`;
+> debug has no config file) removes nothing from this table — both tools are `[READ]`, and
+> the gate proves that at start-up rather than trusting the marker. Classification comes
+> from the `[READ]`/`[WRITE]` docstring marker — see README.
+
 `list_symptom_categories` returns the family list envelope — read the rows from
 `items`. It has no `limit` parameter, which is exactly why the envelope matters:
 `truncated: false` states that this is every category there is, rather than

{vmware_debug-1.8.0 → vmware_debug-1.8.1}/skills/vmware-debug/references/setup-guide.md

@@ -26,6 +26,46 @@ For full cross-skill diagnosis, also install the data-source skills it correlate
 (vmware-monitor, vmware-log-insight, vmware-aria, vmware-nsx) and the executors it
 routes fixes to (vmware-aiops, vmware-pilot).
 
+## Read-Only Mode
+
+Off by default. Both of debug's tools are reads, so turning it on withholds nothing here —
+the value is that the gate *verifies* at start-up that no write tool is exposed, instead of
+trusting this document, and that the same family variable locks down every other installed
+skill in one setting.
+
+**Debug has no config file, so the environment is the only switch.** There is no
+`read_only:` setting to write. Precedence:
+
+| Priority | Signal | Scope |
+|---|---|---|
+| 1 | `VMWARE_DEBUG_READ_ONLY` | This skill only |
+| 2 | `VMWARE_READ_ONLY` | Every installed VMware skill |
+| 3 | (nothing set) | Off |
+
+```json
+{
+  "mcpServers": {
+    "vmware-debug": {
+      "command": "vmware-debug",
+      "args": ["mcp"],
+      "env": { "VMWARE_READ_ONLY": "true" }
+    }
+  }
+}
+```
+
+**Fail-closed.** If the mode is requested but cannot be *proven*, the server refuses to
+start with `ReadOnlyGateError`: the FastMCP tool registry cannot be enumerated (usually an
+incompatible `mcp` version), or a removal did not take effect. One case does *not* abort —
+an unparseable value (`VMWARE_DEBUG_READ_ONLY=ture`) resolves to **on** with a warning
+naming the accepted values, so a typo locks the deployment down rather than leaving it
+open.
+
+**Verifying.** Debug ships no `doctor` command; the start-up log is the record — the server
+logs every withheld tool when the mode engages, and logs nothing to withhold here. Skills
+that do ship one (e.g. `vmware-log-insight doctor`) report their resolved state and where it
+came from.
+
 ## Security
 
 > **Disclaimer**: Community-maintained open-source project, **not affiliated with,

{vmware_debug-1.8.0 → vmware_debug-1.8.1}/vmware_debug/__init__.py

@@ -5,4 +5,4 @@ into a unified timeline, detect spikes, rank root-cause hypotheses, and route
 remediation to vmware-aiops / vmware-pilot. Never writes; never executes fixes.
 """
 
-__version__ = "1.8.0"
+__version__ = "1.8.1"