vmware-debug 1.13.2__tar.gz → 2.1.0__tar.gz

{vmware_debug-1.13.2 → vmware_debug-2.1.0}/.claude-plugin/plugin.json

@@ -2,7 +2,7 @@
   "$schema": "https://anthropic.com/claude-code/plugin.schema.json",
   "name": "vmware-debug",
   "displayName": "VMware Debug",
-  "version": "1.13.2",
+  "version": "2.1.0",
   "description": "VMware incident timeline, root-cause routing, local case ledger; no vSphere access. 14 MCP tools.",
   "author": {
     "name": "Wei Zhou",

{vmware_debug-1.13.2 → vmware_debug-2.1.0}/.mcp.json

@@ -5,7 +5,7 @@
       "command": "uvx",
       "args": [
         "--from",
-        "vmware-debug==1.13.2",
+        "vmware-debug==2.1.0",
         "vmware-debug-mcp"
       ]
     }

vmware_debug-2.1.0/PKG-INFO

@@ -0,0 +1,150 @@
+Metadata-Version: 2.5
+Name: vmware-debug
+Version: 2.1.0
+Summary: VMware diagnostic brain — offline incident triage, log/event correlation, and root-cause routing across the VMware skill family
+Project-URL: Homepage, https://github.com/vmware-skills/VMware-Debug
+Project-URL: Repository, https://github.com/vmware-skills/VMware-Debug
+Project-URL: Issues, https://github.com/vmware-skills/VMware-Debug/issues
+Project-URL: Changelog, https://github.com/vmware-skills/VMware-Debug/blob/main/RELEASE_NOTES.md
+Author-email: Wei Zhou <wei-wz.zhou@broadcom.com>
+License-Expression: MIT
+Keywords: ai-ops,debug,diagnostics,mcp,rca,troubleshooting,vmware,vsphere
+Classifier: Development Status :: 4 - Beta
+Classifier: License :: OSI Approved :: MIT License
+Classifier: Programming Language :: Python :: 3
+Classifier: Topic :: System :: Monitoring
+Requires-Python: >=3.10
+Requires-Dist: mcp[cli]<2.0,>=1.10
+Requires-Dist: pyyaml<7.0,>=6.0
+Requires-Dist: rich<15.0,>=13.0
+Requires-Dist: typer<1.0,>=0.12
+Requires-Dist: vmware-policy<2.0,>=1.20.0
+Description-Content-Type: text/markdown
+
+<!-- mcp-name: io.github.vmware-skills/vmware-debug -->
+
+# VMware Debug
+
+> **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 **never touches vSphere** — it connects to
+nothing and never executes fixes; its only writes are to a local case ledger
+under `$OPS_HOME`. 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.
+
+## Upgrading to 2.0
+
+2.0 renames 13 of its 14 MCP tools so every name starts with a verb (e.g. `case_close` → `close_case`, `case_get` → `get_case`, `case_grade` → `grade_case`). The full old → new table is in
+[RELEASE_NOTES.md](RELEASE_NOTES.md#v200--mcp-tools-renamed-verb-first). Nothing else changes: same tools, parameters,
+safety gates and CLI commands. If an agent prompt, script or `~/.vmware/rules.yaml` names a tool, update it — though deny
+rules written with the old names keep working with vmware-policy ≥ 1.18.1 (`vmware-audit policy` lists any rule the
+renames widened), and vmware-pilot ≥ 1.13 translates old names in saved workflows.
+If an install older than 2.0 shares that `rules.yaml`, give it vmware-policy ≥ 1.18.2 too: it matches each rule
+against both the old and the new name, so one file serves both.
+
+## Companion Skills
+
+| Need | Skill |
+|---|---|
+| Incident correlation / root cause | **vmware-debug** (this project) |
+| Centralized log search | vmware-log-insight (feed its `search_logs` results here) |
+| vCenter events and alarms | vmware-monitor |
+| Metrics / anomalies | vmware-aria |
+| Executing a fix | vmware-aiops (single op) / vmware-pilot (multi-step, gated) |
+
+## Install
+
+```bash
+uv tool install vmware-debug
+vmware-debug categories          # see which symptom categories it can diagnose
+```
+
+## MCP tools (14 — 7 read, 7 write)
+
+The seven writes go to the local case ledger only; none reaches a VMware system.
+
+**Correlation** — stateless, for a single look:
+
+| Tool | What |
+|---|---|
+| `build_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 |
+
+**Investigation ledger** — for an incident you will reason about over time:
+
+| Tool | What |
+|---|---|
+| `open_case` | [WRITE] Define the event; returns a case id and the grade this environment can reach |
+| `get_case_readiness` | [READ] What grade this environment can reach, per symptom category, **before** you start |
+| `get_case_knowledge` | [READ] Which knowledge formats are accepted, what is mounted, and which entries apply to a case |
+| `plan_case` | [READ] What to fetch next — skill, tool and purpose per step; recomputed from the case's current state |
+| `list_cases` | [READ] Cases, newest first |
+| `get_case` | [READ] One case: scope, ledger sizes, grade history |
+| `record_case_hypothesis` | [WRITE] Register a candidate explanation, or read the ledger of what supports and refutes each |
+| `submit_case_evidence` | [WRITE] Record one retrieved fact, with its source, query and time basis |
+| `record_case_gap` | [WRITE] Record what could **not** be retrieved, and how to close it |
+| `record_case_timeline` | [WRITE] Correlate everything the case has collected into one timeline |
+| `grade_case` | [WRITE] Recompute the conclusion grade from the ledger and record it |
+| `close_case` | [WRITE] Record the final grade, archive, and name what was left open |
+
+**Event envelope**: `{ts, source, severity, entity, text, fields}`. The agent normalizes events from each source
+into this shape before handing them to debug, so debug has zero runtime dependency on the other packages.
+**Keep each event's `event_type` in `fields`** — the classifier matches it as well as the text, and most modern
+vSphere events are `EventEx`: the text is a generic boilerplate sentence, and only `eventTypeId` says what the
+event actually is.
+
+## Security
+
+Offline and credential-free by construction: it connects to no vCenter/NSX/Aria, has no destructive surface on
+VMware, and holds no secret to leak. The only writes are the local case ledger: evidence, gaps, hypotheses and
+grade history are append-only; `timeline.md` is regenerated from the evidence, and `case.json` holds the current
+grade and status. The same holds with several writers: every write to a case first takes that case's lock file
+(`.ledger.lock`, exclusive create), so two processes writing the same case in a shared `$OPS_HOME` are serialized
+instead of dropping each other's entries; every file is written under a temporary name and then moved into place,
+so a reader never sees a half-written file (on a file system without hard links, a new evidence file is instead
+created in place: still never overwritten, but it can be read half-written). A lock left behind by a crashed
+process is reported together with its holder and never deleted automatically; delete it by hand once you have
+confirmed no process is writing that case. Released versions 1.11.3 and earlier do not take this lock, so every
+machine sharing a case directory must upgrade. See [SECURITY.md](SECURITY.md).
+
+## 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-2.1.0/README-CN.md

@@ -0,0 +1,107 @@
+<!-- mcp-name: io.github.vmware-skills/vmware-debug -->
+
+# VMware Debug（中文）
+
+> **声明**：本项目为社区维护的开源项目，**与 VMware, Inc. 或 Broadcom Inc. 无任何隶属、
+> 背书或赞助关系。** "VMware"、"vSphere" 为 Broadcom 商标。源码以 MIT 许可证公开可审计。
+
+VMware skill 家族的**诊断大脑**。你给出症状（报错、日志、变慢的 VM），它来跑系统化排查：
+把其它 skill 取到的事件关联成一条时间线、检测突刺、给根因假设排序，并告诉你下一步该查什么。
+它**从不触碰 vSphere**——不连接任何东西，也从不执行修复；唯一的写入是 `$OPS_HOME` 下的本地案卷。修复一律路由给 vmware-aiops（单步）或
+vmware-pilot（多步、带审批门控），完全复刻 vmware-harden → vmware-pilot 的「顾问/执行」分工。
+
+完整的方法论、事件信封约定和症状路由见 [`skills/vmware-debug/SKILL.md`](skills/vmware-debug/SKILL.md)。
+
+## 升级到 2.0
+
+2.0 把 14 个 MCP 工具中的 13 个改成动词在前（例如 `case_close` → `close_case`, `case_get` → `get_case`, `case_grade` → `grade_case`），完整的新旧名对照表见
+[RELEASE_NOTES.md](RELEASE_NOTES.md#v200--mcp-tools-renamed-verb-first)。其他都不变：工具、参数、安全确认门和 CLI 命令都一样。
+如果 agent 提示词、脚本或 `~/.vmware/rules.yaml` 里写了工具名，请改成新名——不过用旧名写的 deny 规则在
+vmware-policy ≥ 1.18.1 下仍然生效（`vmware-audit policy` 会列出因改名而多匹配的规则），vmware-pilot ≥ 1.13 也会自动转换已保存工作流里的旧名。
+如果还有 2.0 之前的安装共用这个 `rules.yaml`，请把它的 vmware-policy 也升到 ≥ 1.18.2：它会按新旧两个名字匹配每条规则，一份文件两边都管用。
+
+## 配套 Skill
+
+| 需求 | Skill |
+|---|---|
+| 故障关联 / 根因 | **vmware-debug**（本项目） |
+| 集中日志检索 | vmware-log-insight（把 `search_logs` 结果喂给它） |
+| vCenter 事件与告警 | vmware-monitor |
+| 指标 / 异常 | vmware-aria |
+| 执行修复 | vmware-aiops（单步）/ vmware-pilot（多步门控） |
+
+## 安装
+
+```bash
+uv tool install vmware-debug
+vmware-debug categories          # 看它能诊断哪些症状类别
+```
+
+## MCP 工具（14 个：7 读、7 写）
+
+7 个写工具只写本地案卷，没有一个触及任何 VMware 系统。
+
+**关联**——无状态，看一眼用：
+
+- `build_incident_timeline`：[READ] 把已取到的事件关联成 时间线 + 突刺 + 排序后的根因假设 + 下一步检查建议
+- `list_symptom_categories`：[READ] 列出能识别的症状类别 + 每类该查什么
+
+**调查案卷**——需要持续推理的事件：
+
+- `open_case`：[WRITE] 定义事件；返回案卷 id 和本环境能达到的结论等级
+- `get_case_readiness`：[READ] 开始**之前**，按症状类别说明本环境能达到的等级
+- `get_case_knowledge`：[READ] 接受哪些知识格式、挂载了什么、哪些条目适用于某个案卷
+- `plan_case`：[READ] 下一步该取什么——每步给出 skill、工具和目的；按案卷当前状态重算
+- `list_cases`：[READ] 案卷列表，最新的在前
+- `get_case`：[READ] 单个案卷：范围、账本大小、等级历史
+- `record_case_hypothesis`：[WRITE] 登记一个候选解释，或读取各假设的支持/反驳账本
+- `submit_case_evidence`：[WRITE] 记录一条取到的事实，连同来源、查询和时间基准
+- `record_case_gap`：[WRITE] 记录**没能**取到的东西，以及如何补上
+- `record_case_timeline`：[WRITE] 把案卷收集到的一切关联成一条时间线
+- `grade_case`：[WRITE] 从账本重算结论等级并记录
+- `close_case`：[WRITE] 记录最终等级、归档，并写明留下了哪些未决项
+
+**事件信封**：`{ts, source, severity, entity, text, fields}`。agent 把各源事件归一成此形状再交给
+debug；debug 因此与其它包零运行时依赖。**请把每条事件的 `event_type` 保留在 `fields` 里**——
+分类器除了正文之外也匹配它，而现代 vSphere 多数事件是 `EventEx`：正文是一句通用套话，
+真正说明「这是什么事件」的只有 `eventTypeId`。
+
+## 安全
+
+结构上离线、无凭据：不连任何 vCenter/NSX/Aria，对 VMware 没有可破坏面，也没有秘密可泄露。
+唯一的写入是本地案卷：证据、缺口、假设和等级历史只增不改；`timeline.md` 由证据重新生成，
+`case.json` 保存当前等级和状态。多个写入者同样成立：每次写案卷都要先拿该案卷的锁文件（`.ledger.lock`，
+独占创建），所以两个进程在共享的 `$OPS_HOME` 里写同一个案卷会被串行化，而不是互相丢条目；每个文件都先写到
+临时文件名再移到位，读者不会读到写了一半的文件（在不支持硬链接的文件系统上，新的证据文件改为原地创建：
+仍然绝不覆盖，但可能被读到写了一半）。崩溃进程留下的锁会连同持有者一起报告，从不自动删除；
+确认没有进程在写该案卷后再手动删除。已发布的 1.11.3 及更早版本不拿这个锁，共享案卷目录的每台机器都要升级。
+详见 [SECURITY.md](SECURITY.md)。
+
+## 离线 / 隔离网络安装（从源码）
+
+本项目使用现代 PEP 517 构建系统（hatchling），所以**按设计就没有 `setup.py`**——这是预期行为，不是缺文件。
+如果你克隆了源码后遇到 `ERROR: File "setup.py" or "setup.cfg" not found ... editable mode
+currently requires a setuptools-based build`，说明你的 `pip` 低于 21.3，无法对非 setuptools 后端做*可编辑*（`-e`）安装。
+可编辑模式只是开发便利，运行这个工具并不需要——任选其一：
+
+```bash
+# 在源码目录里——普通（非可编辑）安装会构建 wheel：
+pip install .              # 不是  pip install -e .
+
+# ……或者先升级 pip，可编辑安装也能用：
+pip install --upgrade pip && pip install -e .
+```
+
+对于**真正隔离网络的主机**，在联网机器上构建 wheel 再拷过去——目标主机就不需要网络：
+
+```bash
+# 在联网机器上，把本包及其依赖收集成 wheel：
+pip wheel . -w dist        # → dist/*.whl   （或：uv build，只构建本包）
+
+# 把 dist/ 拷到隔离主机，然后离线安装：
+pip install --no-index --find-links dist vmware-debug
+```
+
+## 许可证
+
+MIT。

vmware_debug-2.1.0/README.md

@@ -0,0 +1,127 @@
+<!-- mcp-name: io.github.vmware-skills/vmware-debug -->
+
+# VMware Debug
+
+> **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 **never touches vSphere** — it connects to
+nothing and never executes fixes; its only writes are to a local case ledger
+under `$OPS_HOME`. 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.
+
+## Upgrading to 2.0
+
+2.0 renames 13 of its 14 MCP tools so every name starts with a verb (e.g. `case_close` → `close_case`, `case_get` → `get_case`, `case_grade` → `grade_case`). The full old → new table is in
+[RELEASE_NOTES.md](RELEASE_NOTES.md#v200--mcp-tools-renamed-verb-first). Nothing else changes: same tools, parameters,
+safety gates and CLI commands. If an agent prompt, script or `~/.vmware/rules.yaml` names a tool, update it — though deny
+rules written with the old names keep working with vmware-policy ≥ 1.18.1 (`vmware-audit policy` lists any rule the
+renames widened), and vmware-pilot ≥ 1.13 translates old names in saved workflows.
+If an install older than 2.0 shares that `rules.yaml`, give it vmware-policy ≥ 1.18.2 too: it matches each rule
+against both the old and the new name, so one file serves both.
+
+## Companion Skills
+
+| Need | Skill |
+|---|---|
+| Incident correlation / root cause | **vmware-debug** (this project) |
+| Centralized log search | vmware-log-insight (feed its `search_logs` results here) |
+| vCenter events and alarms | vmware-monitor |
+| Metrics / anomalies | vmware-aria |
+| Executing a fix | vmware-aiops (single op) / vmware-pilot (multi-step, gated) |
+
+## Install
+
+```bash
+uv tool install vmware-debug
+vmware-debug categories          # see which symptom categories it can diagnose
+```
+
+## MCP tools (14 — 7 read, 7 write)
+
+The seven writes go to the local case ledger only; none reaches a VMware system.
+
+**Correlation** — stateless, for a single look:
+
+| Tool | What |
+|---|---|
+| `build_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 |
+
+**Investigation ledger** — for an incident you will reason about over time:
+
+| Tool | What |
+|---|---|
+| `open_case` | [WRITE] Define the event; returns a case id and the grade this environment can reach |
+| `get_case_readiness` | [READ] What grade this environment can reach, per symptom category, **before** you start |
+| `get_case_knowledge` | [READ] Which knowledge formats are accepted, what is mounted, and which entries apply to a case |
+| `plan_case` | [READ] What to fetch next — skill, tool and purpose per step; recomputed from the case's current state |
+| `list_cases` | [READ] Cases, newest first |
+| `get_case` | [READ] One case: scope, ledger sizes, grade history |
+| `record_case_hypothesis` | [WRITE] Register a candidate explanation, or read the ledger of what supports and refutes each |
+| `submit_case_evidence` | [WRITE] Record one retrieved fact, with its source, query and time basis |
+| `record_case_gap` | [WRITE] Record what could **not** be retrieved, and how to close it |
+| `record_case_timeline` | [WRITE] Correlate everything the case has collected into one timeline |
+| `grade_case` | [WRITE] Recompute the conclusion grade from the ledger and record it |
+| `close_case` | [WRITE] Record the final grade, archive, and name what was left open |
+
+**Event envelope**: `{ts, source, severity, entity, text, fields}`. The agent normalizes events from each source
+into this shape before handing them to debug, so debug has zero runtime dependency on the other packages.
+**Keep each event's `event_type` in `fields`** — the classifier matches it as well as the text, and most modern
+vSphere events are `EventEx`: the text is a generic boilerplate sentence, and only `eventTypeId` says what the
+event actually is.
+
+## Security
+
+Offline and credential-free by construction: it connects to no vCenter/NSX/Aria, has no destructive surface on
+VMware, and holds no secret to leak. The only writes are the local case ledger: evidence, gaps, hypotheses and
+grade history are append-only; `timeline.md` is regenerated from the evidence, and `case.json` holds the current
+grade and status. The same holds with several writers: every write to a case first takes that case's lock file
+(`.ledger.lock`, exclusive create), so two processes writing the same case in a shared `$OPS_HOME` are serialized
+instead of dropping each other's entries; every file is written under a temporary name and then moved into place,
+so a reader never sees a half-written file (on a file system without hard links, a new evidence file is instead
+created in place: still never overwritten, but it can be read half-written). A lock left behind by a crashed
+process is reported together with its holder and never deleted automatically; delete it by hand once you have
+confirmed no process is writing that case. Released versions 1.11.3 and earlier do not take this lock, so every
+machine sharing a case directory must upgrade. See [SECURITY.md](SECURITY.md).
+
+## 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.13.2 → vmware_debug-2.1.0}/RELEASE_NOTES.md

@@ -1,3 +1,59 @@
+## v2.1.0 — offer only read tools, plus chosen write tools
+
+`vmware-debug mcp` can now offer a subset of this server's tools (HLD §17 D-16, via vmware-policy 1.20.0):
+
+```bash
+vmware-debug mcp --expose read --allow-write close_case
+```
+
+* `--expose read` (or `VMWARE_DEBUG_MCP_EXPOSE=read`) keeps only tools annotated `readOnlyHint: true`; `--allow-write a,b`
+  (or `VMWARE_DEBUG_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 — MCP tools renamed verb-first
+
+Every MCP tool in the VMware skill family now follows one naming convention: the verb comes first
+(`open_…`, `get_…`, `record_…`, `build_…`), followed by what it acts on. Where two skills would
+otherwise expose the same name, the tool carries a domain word — here `case`, so the ledger tools read
+`open_case`, `grade_case`, `record_case_gap`. 13 of this skill's 14 tools are renamed;
+`list_symptom_categories` already led with its verb. Parameters, annotations, the `sensitive_params` /
+`sensitive_result` declarations and behaviour are unchanged; only the names move.
+`record_case_hypothesis` still reads the hypothesis ledger, writing nothing, when called without a
+`statement` — its description now says so in its first sentence.
+
+| Old name | New name |
+|---|---|
+| `case_close` | `close_case` |
+| `case_get` | `get_case` |
+| `case_grade` | `grade_case` |
+| `case_hypotheses` | `record_case_hypothesis` |
+| `case_knowledge` | `get_case_knowledge` |
+| `case_list` | `list_cases` |
+| `case_open` | `open_case` |
+| `case_plan` | `plan_case` |
+| `case_readiness` | `get_case_readiness` |
+| `case_record_gap` | `record_case_gap` |
+| `case_submit_evidence` | `submit_case_evidence` |
+| `case_timeline` | `record_case_timeline` |
+| `incident_timeline` | `build_incident_timeline` |
+
+**Sibling tools are cited by their 2.0 names.** The evidence-source catalogue
+(`rules/evidence_sources.yaml`), the symptom routing table, `plan_case` steps, teaching errors, and the
+docs now name the other skills' tools by their new names (`get_events` → unchanged, `log_search` →
+`search_logs`, `vsan_health` → `get_vsan_health`, `host_investigation_bundle` → `investigate_host`, …),
+so a plan step is a tool the 2.0 servers actually register.
+
+**CLI commands are unchanged** (`vmware-debug triage`, `vmware-debug categories`). `triage`'s audit row
+records its MCP twin's name, so those rows now carry `build_incident_timeline`.
+
+**Deny rules** in `~/.vmware/rules.yaml` written with old names keep working with vmware-policy ≥ 1.18.1 (1.18.1 carries `case_timeline` → `record_case_timeline`)
+(it matches both names); `vmware-audit policy` lists any rule that now matches more.
+
 ## v1.13.2 — auth diagnosis never reads or records a secret
 
 Docs only; no code change.

{vmware_debug-1.13.2 → vmware_debug-2.1.0}/openclaw.plugin.json

@@ -11,7 +11,7 @@
       "command": "uvx",
       "args": [
         "--from",
-        "vmware-debug==1.13.2",
+        "vmware-debug==2.1.0",
         "vmware-debug-mcp"
       ]
     }

{vmware_debug-1.13.2 → vmware_debug-2.1.0}/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zw008/vmware-debug",
-  "version": "1.13.2",
+  "version": "2.1.0",
   "description": "VMware incident timeline, root-cause routing, local case ledger; no vSphere access. 14 MCP tools.",
   "private": true,
   "license": "MIT",

{vmware_debug-1.13.2 → vmware_debug-2.1.0}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "vmware-debug"
-version = "1.13.2"
+version = "2.1.0"
 description = "VMware diagnostic brain — offline 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.16.0,<2.0",
+    "vmware-policy>=1.20.0,<2.0",
     # Imported directly by ops/cases/grading.py for the rules file. It has
     # always arrived transitively via vmware-policy; a package should
     # declare what it imports rather than rely on a dependency's dependency.

{vmware_debug-1.13.2 → vmware_debug-2.1.0}/server.json

@@ -7,12 +7,12 @@
     "url": "https://github.com/vmware-skills/VMware-Debug",
     "source": "github"
   },
-  "version": "1.13.2",
+  "version": "2.1.0",
   "packages": [
     {
       "registryType": "pypi",
       "identifier": "vmware-debug",
-      "version": "1.13.2",
+      "version": "2.1.0",
       "runtimeHint": "uvx",
       "packageArguments": [
         {