vmware-debug 1.8.4__tar.gz → 1.8.7__tar.gz

{vmware_debug-1.8.4 → vmware_debug-1.8.7}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: vmware-debug
-Version: 1.8.4
+Version: 1.8.7
 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
@@ -13,7 +13,7 @@ Requires-Python: >=3.10
 Requires-Dist: mcp[cli]<2.0,>=1.10
 Requires-Dist: rich<15.0,>=13.0
 Requires-Dist: typer<1.0,>=0.12
-Requires-Dist: vmware-policy<2.0,>=1.8.4
+Requires-Dist: vmware-policy<2.0,>=1.8.5
 Description-Content-Type: text/markdown
 
 <!-- mcp-name: io.github.zw008/vmware-debug -->
@@ -40,8 +40,6 @@ advisor/executor split.
 See [`skills/vmware-debug/SKILL.md`](skills/vmware-debug/SKILL.md) for the full
 methodology, the event-envelope contract, and symptom routing.
 
-- **Read-only by design — and provable** (v1.8.0): both MCP tools are read, none write; set `VMWARE_READ_ONLY=true` (or the per-skill `VMWARE_DEBUG_READ_ONLY`) and the family read-only gate verifies that at startup instead of taking the docs' word for it — env vars are the only switch here, this skill has no config file. See [Read-Only Mode](#read-only-mode).
-
 ## MCP tools
 
 | Tool | What |
@@ -49,44 +47,33 @@ methodology, the event-envelope contract, and symptom routing.
 | `incident_timeline` | [READ] Correlate pre-fetched events → timeline + spikes + ranked hypotheses + next-check ideas |
 | `list_symptom_categories` | [READ] List recognised symptom categories + what to check for each |
 
-## Read-Only Mode
-
-vmware-debug is read-only by design — both MCP tools carry the `[READ]` marker, take no
-credentials, and make no network calls at all; they only correlate event dicts the
-calling agent has already fetched with the other skills' read tools. Since v1.8.0 that
-is **provable rather than merely documented**: set `VMWARE_READ_ONLY=true` and the
-family read-only gate enumerates the registry at startup and verifies that zero write
-tools are exposed — structural, not a prompt instruction a model can ignore. **Off by
-default.** Fail-closed: if the mode is requested but cannot be guaranteed, the server
-refuses to start rather than running open.
-
-The same variable is family-wide: one env var also strips every write tool from the
-write-capable siblings (aiops, storage, vks, nsx, ...), so a whole-estate read-only
-posture is a single setting.
-
-```json
-{
-  "mcpServers": {
-    "vmware-debug": {
-      "command": "vmware-debug",
-      "args": ["mcp"],
-      "env": {
-        "VMWARE_READ_ONLY": "true"
-      }
-    }
-  }
-}
+## Offline / Air-Gapped Install (from source)
+
+This project uses the modern PEP 517 build system (hatchling), so there is **no
+`setup.py`** by design — that is expected, not a missing file. If you cloned the
+source and hit `ERROR: File "setup.py" or "setup.cfg" not found ... editable mode
+currently requires a setuptools-based build`, your `pip` is older than 21.3 and
+cannot do an *editable* (`-e`) install with a non-setuptools backend. Editable
+mode is a developer convenience, not needed to run the tool — do one of:
+
+```bash
+# From the source tree — a normal (non-editable) install builds a wheel:
+pip install .              # NOT  pip install -e .
+
+# ...or upgrade pip first, and editable works too:
+pip install --upgrade pip && pip install -e .
 ```
 
-- **Per-skill override**: `VMWARE_DEBUG_READ_ONLY` beats the family-wide
-  `VMWARE_READ_ONLY`. vmware-debug has no `config.yaml`, so the env vars are the only
-  switch. Precedence: per-skill env → family env → off.
-- **Classification**: this skill registers its tools through a `build_server()` factory,
-  so the gate classifies from the `[READ]`/`[WRITE]` docstring marker rather than from
-  MCP annotations. Anything not provably read-only is treated as a write.
-- **Startup log**: nothing is logged as withheld because nothing is — the gate's empty
-  result *is* the assertion (write-capable siblings log
-  `Read-only mode active ... withheld N write tool(s)` instead).
+For a **truly air-gapped host**, build the wheels on a connected machine and copy
+them over — the target then needs no network:
+
+```bash
+# On a connected machine, collect this package + its dependencies as wheels:
+pip wheel . -w dist        # → dist/*.whl   (or: uv build, for just this package)
+
+# Copy dist/ to the air-gapped host, then install offline:
+pip install --no-index --find-links dist vmware-debug
+```
 
 ## License
 

vmware_debug-1.8.7/README-CN.md

@@ -0,0 +1,45 @@
+<!-- mcp-name: io.github.zw008/vmware-debug -->
+
+# VMware Debug（中文）
+
+> **声明**：本项目为社区维护的开源项目，**与 VMware, Inc. 或 Broadcom Inc. 无任何隶属、
+> 背书或赞助关系。** "VMware"、"vSphere" 为 Broadcom 商标。源码以 MIT 许可证公开可审计。
+
+VMware skill 家族的**诊断大脑**。你给出症状（报错、日志、变慢的 VM），它来跑系统化排查：
+把其它 skill 取到的事件关联成一条时间线、检测突刺、给根因假设排序，并告诉你下一步该查什么。
+**只读**——从不修改任何东西，也从不执行修复。修复一律路由给 vmware-aiops（单步）或
+vmware-pilot（多步、带审批门控），完全复刻 vmware-harden → vmware-pilot 的「顾问/执行」分工。
+
+## 配套 Skill
+
+| 需求 | Skill |
+|---|---|
+| 故障关联 / 根因 | **vmware-debug**（本项目） |
+| 集中日志检索 | vmware-log-insight（把 `log_search` 结果喂给它） |
+| vCenter 事件与告警 | vmware-monitor |
+| 指标 / 异常 | vmware-aria |
+| 执行修复 | vmware-aiops（单步）/ vmware-pilot（多步门控） |
+
+## 安装
+
+```bash
+uv tool install vmware-debug
+vmware-debug categories          # 看它能诊断哪些症状类别
+```
+
+## MCP 工具（2 个，全只读）
+
+- `incident_timeline`：把已取到的事件关联成 时间线 + 突刺 + 排序后的根因假设 + 下一步检查建议
+- `list_symptom_categories`：症状类别及对应的排查路由（不知道查什么时用它）
+
+**事件信封**：`{ts, source, severity, entity, text, fields}`。agent 把各源事件归一成此形状再交给
+debug；debug 因此与其它包零运行时依赖。
+
+## 安全
+
+结构上只读、离线、无凭据：不连任何 vCenter/NSX/Aria，没有可破坏面，也没有秘密可泄露。
+详见 [SECURITY.md](SECURITY.md)。
+
+## 许可证
+
+MIT。

vmware_debug-1.8.7/README.md

@@ -0,0 +1,62 @@
+<!-- mcp-name: io.github.zw008/vmware-debug -->
+
+# VMware Debug
+
+> ⚠️ **Work in progress** — the core (event correlation engine, MCP tools, CLI)
+> is built and tested; README, `server.json`, full reference docs, and packaging
+> polish are still landing. Not yet published to PyPI.
+
+> **Disclaimer**: Community-maintained open-source project, **not affiliated with,
+> endorsed by, or sponsored by VMware, Inc. or Broadcom Inc.** "VMware" and
+> "vSphere" are trademarks of Broadcom. Source is publicly auditable under the MIT
+> license.
+
+The diagnostic brain of the VMware skill family. You bring the symptom (an error,
+a log dump, a slow VM); this skill runs a systematic investigation, correlates
+events from the other skills into one timeline, ranks root-cause hypotheses, and
+tells you what to check next. It is **read-only** — it never changes anything and
+never executes fixes. Remediation is routed to `vmware-aiops` (single op) or
+`vmware-pilot` (multi-step, gated), mirroring the `vmware-harden → vmware-pilot`
+advisor/executor split.
+
+See [`skills/vmware-debug/SKILL.md`](skills/vmware-debug/SKILL.md) for the full
+methodology, the event-envelope contract, and symptom routing.
+
+## MCP tools
+
+| Tool | What |
+|---|---|
+| `incident_timeline` | [READ] Correlate pre-fetched events → timeline + spikes + ranked hypotheses + next-check ideas |
+| `list_symptom_categories` | [READ] List recognised symptom categories + what to check for each |
+
+## Offline / Air-Gapped Install (from source)
+
+This project uses the modern PEP 517 build system (hatchling), so there is **no
+`setup.py`** by design — that is expected, not a missing file. If you cloned the
+source and hit `ERROR: File "setup.py" or "setup.cfg" not found ... editable mode
+currently requires a setuptools-based build`, your `pip` is older than 21.3 and
+cannot do an *editable* (`-e`) install with a non-setuptools backend. Editable
+mode is a developer convenience, not needed to run the tool — do one of:
+
+```bash
+# From the source tree — a normal (non-editable) install builds a wheel:
+pip install .              # NOT  pip install -e .
+
+# ...or upgrade pip first, and editable works too:
+pip install --upgrade pip && pip install -e .
+```
+
+For a **truly air-gapped host**, build the wheels on a connected machine and copy
+them over — the target then needs no network:
+
+```bash
+# On a connected machine, collect this package + its dependencies as wheels:
+pip wheel . -w dist        # → dist/*.whl   (or: uv build, for just this package)
+
+# Copy dist/ to the air-gapped host, then install offline:
+pip install --no-index --find-links dist vmware-debug
+```
+
+## License
+
+MIT.

{vmware_debug-1.8.4 → vmware_debug-1.8.7}/RELEASE_NOTES.md

@@ -1,3 +1,122 @@
+## v1.8.7 (2026-07-21) — the skill-level read-only switch is removed; read/write authorization is the vCenter account's job (RBAC)
+
+### Removed: `VMWARE_READ_ONLY` / `read_only:` — give the agent a read-only service account instead
+
+The skill-level read-only switch is gone. It was enforced only on the MCP tool
+registry, and any agent with a shell (every SKILL.md grants `allowed-tools: Bash`)
+could reach the same change one CLI command away — so it withheld the *tool*, not
+the *capability*. It was never a real boundary.
+
+To run an agent read-only, give it a **read-only vCenter/NSX service account
+(RBAC)**. Writes are then refused at the platform, un-bypassably, regardless of
+surface or shell — the one place read/write control cannot be stepped around. A
+config still carrying `read_only: true` is ignored, with a one-time warning that
+names the replacement (no silent behavior change).
+
+### Removed: approval tiers and the declared-environment gate (via vmware-policy)
+
+The graduated-autonomy approval tiers (`confirm`/`dual`/`review`) and the "declare
+an environment or be refused" baseline are removed — they only ever fired on the
+rarest configuration while carrying the family's most complex machinery. Opt-in
+`deny` rules and the maintenance window remain, and apply identically wherever a
+tool runs.
+
+### Added: offline / air-gapped install docs
+
+The README now covers installing from source without editable mode (for older
+`pip`) and building wheels to carry onto an air-gapped host — the modern PEP 517
+layout has no `setup.py` by design, which is expected, not a missing file.
+
+This release also carries the accumulated fixes staged since 1.8.5.
+
+## v1.8.5 (2026-07-20) — the two fixes v1.8.4 announced now actually work
+
+Four adversarial reviews of v1.8.4 found that both of its headline fixes were
+incomplete in ways the release notes did not reflect. This release makes them
+real. If you are on 1.8.4, this is the one to take.
+
+### Fixed — a failure that was *returned* was still audited as a success
+
+vmware-policy 1.8.4 added `report_tool_failure()` for tools that catch an
+exception and return an error payload instead of raising. **No skill called it.**
+
+Every string-returning tool therefore kept doing exactly what 1.8.4 said it had
+stopped doing: writing `status=ok` to `~/.vmware/audit.db` for an operation that
+failed, recording an undo token for a change that never happened, and telling the
+circuit breaker the call succeeded so repeated failures never tripped it.
+
+The surface this covered is not marginal:
+
+| Skill | What was mis-audited |
+|---|---|
+| vmware-aiops | 25 of 49 tools, including **every undo-bearing write** — a failed `vm_power_on` left an undo token saying "power it back off" |
+| vmware-avi | all 28 tools, including `vs_toggle` and `ako_restart` |
+| vmware-storage | all 4 write tools |
+| vmware-nsx | the 5 delete tools |
+
+vmware-avi is worth calling out: before 1.8.4 its exceptions propagated and the
+audit was correct. 1.8.4 caught them and returned a string, so **that release made
+its audit trail worse than it had been.**
+
+Skills whose tools already return dict payloads (vmware-monitor, vmware-vks,
+vmware-aria, vmware-log-insight, vmware-harden, vmware-debug, vmware-pilot) were
+already detected correctly. They gained a test proving it rather than a redundant
+call.
+
+### Fixed — narrowing `OSError` did not close the leak it was meant to close
+
+1.8.4 narrowed the `_safe_error` passthrough because bare `OSError` let TLS and
+DNS failures reach the agent with hostnames and certificate subjects in them.
+That narrowing had no effect on the error it was written for:
+
+```
+ssl.SSLCertVerificationError → ssl.SSLError → OSError, ValueError
+```
+
+`ValueError` has been on every allowlist since long before 1.8.4, so a
+certificate failure kept passing through — the commonest self-signed-certificate
+failure in this family, carrying the hostname it was checked against. An
+allowlist structurally cannot express "not this one".
+
+Where `ssl.SSLError` can actually surface — the pyVmomi skills — it is now
+reduced *ahead* of the allowlist. In the httpx skills TLS arrives wrapped as
+`httpx.ConnectError`, and in vmware-avi as `requests.exceptions.SSLError`, so the
+guard cannot fire there; in those skills the leak was the raw exception
+interpolated into an already-allowlisted `*ApiError`, and that is now authored
+text naming the config target and `verify_ssl` instead of the exception.
+
+The missing-password error — this family's most common first-run failure, whose
+entire remedy is the environment variable name it carries — keeps its message
+through a narrow `ConfigError(OSError)` rather than the base class. Connection
+failures are translated at the connection layer into an authored remedy that
+names the target and the setting to change, with the raw detail left on
+`__cause__` for the server log.
+
+### Also fixed
+
+- **vmware-vks**: the quickstart documented a password variable the code never
+  reads — following `README.md` verbatim produced "Password not found". Five
+  places, plus six references to a `doctor` command this CLI has never had, two
+  descriptions promising fields the tools do not return, and eight teaching
+  messages that `RuntimeError` was masking.
+- **vmware-nsx**: an error cited `--route-advertisement`; the flag is `--advertise`.
+- **vmware-pilot**: `get_workflow_status` told the model to call `approve` — a
+  tool the read-only gate withholds — as the required next step; and a hint
+  pointed at a filename that could never appear in that message.
+- **vmware-aiops**: `vm_task_status` polling a *failed task* returned
+  `{"state": "error", "error": ...}` from a successful read, which the new
+  detection read as the call itself failing. The field is now `task_error`.
+  **This is a breaking change for anything parsing that payload.**
+- Several remedies that were still being cut by the 300-character cap the 1.8.4
+  notes claimed to have addressed.
+
+### Known and not fixed
+
+`ConnectionError` remains one type from two sources in several skills — a
+skill's own authored message and urllib3's `HTTPSConnectionPool(host=..., port=...)`
+share it, and an allowlist cannot separate them. vmware-vks is converted; the
+rest need their own domain type and are deferred rather than half-done.
+
 ## v1.8.4 (2026-07-20) — errors that teach, and tool descriptions a small model can route from
 
 A capability eval was rolled out across the family and asked two open questions:

{vmware_debug-1.8.4 → vmware_debug-1.8.7}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "vmware-debug"
-version = "1.8.4"
+version = "1.8.7"
 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"
@@ -21,7 +21,7 @@ dependencies = [
     "typer>=0.12,<1.0",
     "rich>=13.0,<15.0",
     "mcp[cli]>=1.10,<2.0",
-    "vmware-policy>=1.8.4,<2.0",
+    "vmware-policy>=1.8.5,<2.0",
 ]
 
 [project.scripts]

{vmware_debug-1.8.4 → vmware_debug-1.8.7}/server.json

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

{vmware_debug-1.8.4 → vmware_debug-1.8.7}/skills/vmware-debug/SKILL.md

@@ -19,7 +19,7 @@ installer:
   package: vmware-debug
 allowed-tools:
   - Bash
-metadata: {"openclaw":{"requires":{"bins":["vmware-debug"]},"optional":{"env":["VMWARE_READ_ONLY","VMWARE_DEBUG_READ_ONLY","VMWARE_AUDIT_APPROVED_BY","VMWARE_AUDIT_RATIONALE"],"bins":["vmware-policy"]},"primaryEnv":"NONE","homepage":"https://github.com/zw008/VMware-Debug","os":["macos","linux"]}}
+metadata: {"openclaw":{"requires":{"bins":["vmware-debug"]},"optional":{"env":["VMWARE_AUDIT_APPROVED_BY","VMWARE_AUDIT_RATIONALE"],"bins":["vmware-policy"]},"primaryEnv":"NONE","homepage":"https://github.com/zw008/VMware-Debug","os":["macos","linux"]}}
 ---
 
 # VMware Debug
@@ -113,17 +113,11 @@ 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. Running with local or small models? See [`references/agent-guardrails.md`](references/agent-guardrails.md).
+## Read-Only by Design
+
+Both tools here are reads — zero write tools, zero network access of its own.
+Running with local or small models? See
+[`references/agent-guardrails.md`](references/agent-guardrails.md).
 
 ## CLI Quick Reference
 

{vmware_debug-1.8.4 → vmware_debug-1.8.7}/skills/vmware-debug/references/agent-guardrails.md

@@ -34,50 +34,13 @@ These are structural, so it cannot.
 
 | Guardrail you would otherwise prompt for | Now enforced by |
 |---|---|
-| "Work exclusively in read-only mode and never modify anything" | **The tool surface, and the gate that proves it.** Both tools are reads, so read-only mode withholds nothing here — but setting it makes the guarantee checkable: the gate verifies at start-up that zero write tools are exposed rather than taking this document's word for it. |
+| "Work read-only and never modify anything" | **The tool surface itself.** Both tools are reads — this skill has no write tool at all, so there is nothing to withhold and nothing to switch off. |
 | "Diagnose only — never apply the fix you propose" | **Structural.** This skill has no tool that changes anything, and it holds no connection to vCenter, NSX or anything else. Remediation is routed to vmware-aiops or vmware-pilot by the calling agent. |
 | "Do not fabricate a timeline — build it from the events I gave you" | **`incident_timeline` correlates only its input.** It is source-agnostic and has no way to fetch anything, so the timeline cannot contain an event the agent did not supply. |
 | "Tell me when the symptom is outside what you can recognise" | **`list_symptom_categories`** states the catalogue, and unmatched symptoms come back as `uncategorized` rather than being forced into the nearest signature. |
 | "Use explicit limits for queries that may return large amounts of data" | **The list envelope.** `list_symptom_categories` returns `{items, returned, limit, total, truncated, hint}` with `truncated` always `false` — which is the point: it states that the catalogue is complete instead of leaving you to infer it. |
 | "Log everything you looked at" | **The `@vmware_tool` decorator.** Every call is recorded to `~/.vmware/audit.db`, reads included. |
 
-### Turning read-only mode on
-
-One variable covers every skill in the family:
-
-```json
-{
-  "mcpServers": {
-    "vmware-debug": {
-      "command": "vmware-debug",
-      "args": ["mcp"],
-      "env": { "VMWARE_READ_ONLY": "true" }
-    }
-  }
-}
-```
-
-Per-skill override:
-
-```bash
-VMWARE_READ_ONLY=true          # whole family read-only
-VMWARE_DEBUG_READ_ONLY=false   # …except this skill
-```
-
-**This skill has no `config.yaml`**, so the two environment variables are the
-only switch — there is no `read_only:` configuration setting to fall back on.
-Precedence is per-skill env → family env → off. An unparseable value
-(`VMWARE_READ_ONLY=ture`) enables read-only mode rather than silently ignoring
-the typo.
-
-Setting it here is worth doing even though nothing is withheld: the same
-variable withholds write tools across every companion skill, so a whole-estate
-diagnostic posture is one setting. That matters especially in this skill's
-workflow — you gather signals read-only, correlate, and then route a fix. When
-the fix tool is missing from vmware-aiops's or vmware-pilot's `list_tools()`,
-that is the lockdown working, not a fault: name the blocked operation and stop,
-rather than retrying or hunting for another route.
-
 ---
 
 ## The system prompt

{vmware_debug-1.8.4 → vmware_debug-1.8.7}/skills/vmware-debug/references/capabilities.md

@@ -7,11 +7,6 @@ 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.7/skills/vmware-debug/references/setup-guide.md

@@ -0,0 +1,49 @@
+# vmware-debug Setup Guide
+
+vmware-debug has **no configuration, no credentials, and no network access** — it
+is a pure, offline correlation engine. There is no `config.yaml` and no `.env`.
+
+## Install
+
+```bash
+uv tool install vmware-debug
+vmware-debug categories      # verify it runs
+```
+
+## MCP client configuration
+
+```json
+{
+  "command": "uvx",
+  "args": ["--from", "vmware-debug", "vmware-debug-mcp"]
+}
+```
+
+If installed with `uv tool install`, prefer the entry point `vmware-debug mcp`
+(no PyPI resolution at startup — robust behind corporate TLS proxies, 踩坑 #25).
+
+For full cross-skill diagnosis, also install the data-source skills it correlates
+(vmware-monitor, vmware-log-insight, vmware-aria, vmware-nsx) and the executors it
+routes fixes to (vmware-aiops, vmware-pilot).
+
+## Security
+
+> **Disclaimer**: Community-maintained open-source project, **not affiliated with,
+> endorsed by, or sponsored by VMware, Inc. or Broadcom Inc.**
+
+1. **Source Code** — https://github.com/zw008/VMware-Debug (MIT).
+2. **Credentials** — none. debug holds no secrets and connects to nothing.
+3. **Network** — none. All tools are local pure functions over event data the
+   agent supplies.
+4. **Writes** — none. debug only diagnoses and recommends; remediation is routed
+   to vmware-aiops / vmware-pilot, where confirmation/approval/audit live.
+5. **No cross-skill coupling** — events arrive as plain dicts (the event
+   envelope); debug imports no other skill package at runtime.
+6. **Environment scoping** — policy rules can scope by environment, and skills
+   that connect to a VMware estate may declare `environment:` (`production` /
+   `staging` / `lab`) per target in their own `config.yaml` as an optional label
+   an environment-scoped `deny` rule can match on. debug has no config and no
+   connection to declare one about, so it reports a constant `local`. Since it
+   ships no operation above read risk, nothing here is gated either way.
+7. **Static analysis** — `uvx bandit -r vmware_debug/` (release bar:
+   0 Medium+).