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

{vmware_debug-1.13.2 → vmware_debug-2.0.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.0.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.0.0}/.mcp.json

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

{vmware_debug-1.13.2 → vmware_debug-2.0.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: vmware-debug
-Version: 1.13.2
+Version: 2.0.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
@@ -18,7 +18,7 @@ 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.16.0
+Requires-Dist: vmware-policy<2.0,>=1.18.1
 Description-Content-Type: text/markdown
 
 <!-- mcp-name: io.github.vmware-skills/vmware-debug -->
@@ -42,6 +42,16 @@ 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.
+
 ## MCP tools (14 — 7 read, 7 write)
 
 The seven writes go to the local case ledger only; none reaches a VMware system.
@@ -50,25 +60,25 @@ The seven writes go to the local case ledger only; none reaches a VMware system.
 
 | Tool | What |
 |---|---|
-| `incident_timeline` | [READ] Correlate pre-fetched events → timeline + spikes + ranked hypotheses + next-check ideas |
+| `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 |
 |---|---|
-| `case_open` | [WRITE] Define the event; returns a case id and the grade this environment can reach |
-| `case_readiness` | [READ] What grade this environment can reach, per symptom category, **before** you start |
-| `case_knowledge` | [READ] Which knowledge formats are accepted, what is mounted, and which entries apply to a case |
-| `case_plan` | [READ] What to fetch next — skill, tool and purpose per step; recomputed from the case's current state |
-| `case_list` | [READ] Cases, newest first |
-| `case_get` | [READ] One case: scope, ledger sizes, grade history |
-| `case_hypotheses` | [WRITE] Register a candidate explanation, or read the ledger of what supports and refutes each |
-| `case_submit_evidence` | [WRITE] Record one retrieved fact, with its source, query and time basis |
-| `case_record_gap` | [WRITE] Record what could **not** be retrieved, and how to close it |
-| `case_timeline` | [WRITE] Correlate everything the case has collected into one timeline |
-| `case_grade` | [WRITE] Recompute the conclusion grade from the ledger and record it |
-| `case_close` | [WRITE] Record the final grade, archive, and name what was left open |
+| `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 |
 
 ## Offline / Air-Gapped Install (from source)
 

{vmware_debug-1.13.2 → vmware_debug-2.0.0}/README-CN.md

@@ -10,12 +10,20 @@ VMware skill 家族的**诊断大脑**。你给出症状（报错、日志、变
 它**从不触碰 vSphere**——不连接任何东西，也从不执行修复；唯一的写入是 `$OPS_HOME` 下的本地案卷。修复一律路由给 vmware-aiops（单步）或
 vmware-pilot（多步、带审批门控），完全复刻 vmware-harden → vmware-pilot 的「顾问/执行」分工。
 
+## 升级到 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（把 `log_search` 结果喂给它） |
+| 集中日志检索 | vmware-log-insight（把 `search_logs` 结果喂给它） |
 | vCenter 事件与告警 | vmware-monitor |
 | 指标 / 异常 | vmware-aria |
 | 执行修复 | vmware-aiops（单步）/ vmware-pilot（多步门控） |
@@ -33,23 +41,23 @@ vmware-debug categories          # 看它能诊断哪些症状类别
 
 **关联**——无状态，看一眼用：
 
-- `incident_timeline`：[READ] 把已取到的事件关联成 时间线 + 突刺 + 排序后的根因假设 + 下一步检查建议
+- `build_incident_timeline`：[READ] 把已取到的事件关联成 时间线 + 突刺 + 排序后的根因假设 + 下一步检查建议
 - `list_symptom_categories`：[READ] 症状类别及对应的排查路由（不知道查什么时用它）
 
 **调查案卷**——需要持续推理的事件：
 
-- `case_open`：[WRITE] 定义事件；返回案卷 id 和本环境能达到的结论等级
-- `case_readiness`：[READ] 开始**之前**，按症状类别说明本环境能达到的等级
-- `case_knowledge`：[READ] 接受哪些知识格式、挂载了什么、哪些条目适用于某个案卷
-- `case_plan`：[READ] 下一步该取什么——每步给出 skill、工具和目的；按案卷当前状态重算
-- `case_list`：[READ] 案卷列表，最新的在前
-- `case_get`：[READ] 单个案卷：范围、账本大小、等级历史
-- `case_hypotheses`：[WRITE] 登记一个候选解释，或读取各假设的支持/反驳账本
-- `case_submit_evidence`：[WRITE] 记录一条取到的事实，连同来源、查询和时间基准
-- `case_record_gap`：[WRITE] 记录**没能**取到的东西，以及如何补上
-- `case_timeline`：[WRITE] 把案卷收集到的一切关联成一条时间线
-- `case_grade`：[WRITE] 从账本重算结论等级并记录
-- `case_close`：[WRITE] 记录最终等级、归档，并写明留下了哪些未决项
+- `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` 里**——

{vmware_debug-1.13.2 → vmware_debug-2.0.0}/README.md

@@ -19,6 +19,16 @@ 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.
+
 ## MCP tools (14 — 7 read, 7 write)
 
 The seven writes go to the local case ledger only; none reaches a VMware system.
@@ -27,25 +37,25 @@ The seven writes go to the local case ledger only; none reaches a VMware system.
 
 | Tool | What |
 |---|---|
-| `incident_timeline` | [READ] Correlate pre-fetched events → timeline + spikes + ranked hypotheses + next-check ideas |
+| `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 |
 |---|---|
-| `case_open` | [WRITE] Define the event; returns a case id and the grade this environment can reach |
-| `case_readiness` | [READ] What grade this environment can reach, per symptom category, **before** you start |
-| `case_knowledge` | [READ] Which knowledge formats are accepted, what is mounted, and which entries apply to a case |
-| `case_plan` | [READ] What to fetch next — skill, tool and purpose per step; recomputed from the case's current state |
-| `case_list` | [READ] Cases, newest first |
-| `case_get` | [READ] One case: scope, ledger sizes, grade history |
-| `case_hypotheses` | [WRITE] Register a candidate explanation, or read the ledger of what supports and refutes each |
-| `case_submit_evidence` | [WRITE] Record one retrieved fact, with its source, query and time basis |
-| `case_record_gap` | [WRITE] Record what could **not** be retrieved, and how to close it |
-| `case_timeline` | [WRITE] Correlate everything the case has collected into one timeline |
-| `case_grade` | [WRITE] Recompute the conclusion grade from the ledger and record it |
-| `case_close` | [WRITE] Record the final grade, archive, and name what was left open |
+| `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 |
 
 ## Offline / Air-Gapped Install (from source)
 

{vmware_debug-1.13.2 → vmware_debug-2.0.0}/RELEASE_NOTES.md

@@ -1,3 +1,42 @@
+## 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.0.0}/openclaw.plugin.json

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

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

@@ -1,6 +1,6 @@
 {
   "name": "@zw008/vmware-debug",
-  "version": "1.13.2",
+  "version": "2.0.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.0.0}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "vmware-debug"
-version = "1.13.2"
+version = "2.0.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.18.1,<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.0.0}/server.json

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

{vmware_debug-1.13.2 → vmware_debug-2.0.0}/skills/vmware-debug/SKILL.md

@@ -51,7 +51,7 @@ write tools touch only the local case ledger.
 ## Quick Install
 
 ```bash
-uv tool install vmware-debug==1.13.2
+uv tool install vmware-debug==2.0.0
 vmware-debug categories          # see what it can diagnose
 ```
 
@@ -82,16 +82,16 @@ a recommended plan.
 ## Common Workflows
 
 ### 1. "Here's a pile of logs / alarms — what broke?"
-1. Collect events with the data-source skills (e.g. `vmware-monitor event_list --vm web01 --since 1h`, `vmware-log-insight log_search ...`, `vmware-aria alert_query ...`).
-2. Pass them all to **`incident_timeline`** (envelope below). Read the top hypothesis + `next_checks`.
-3. Follow `next_checks` to pull more targeted data; re-run `incident_timeline` to confirm.
+1. Collect events with the data-source skills (e.g. MCP tools vmware-monitor `get_events`, vmware-log-insight `search_logs`, vmware-aria `list_alerts`).
+2. Pass them all to **`build_incident_timeline`** (envelope below). Read the top hypothesis + `next_checks`.
+3. Follow `next_checks` to pull more targeted data; re-run `build_incident_timeline` to confirm.
 4. **Failure branch — no events come back:** the affected target may be unreachable. Run the source skill's `doctor`/health first; a 503/timeout is a *signal* (platform not ready), not a dead end.
 5. Produce a diagnosis + recommended fix. Route execution to aiops/pilot. **Do not fix here.**
 
 ### 2. "I don't even know what to check"
 1. Run **`list_symptom_categories`** (or `vmware-debug categories`) to see the catalogue.
 2. Describe the symptom; map it to a category; the `suggested_check` tells you which skill/tool to run first.
-3. Collect → `incident_timeline` → narrow. Loop until one hypothesis dominates.
+3. Collect → `build_incident_timeline` → narrow. Loop until one hypothesis dominates.
 
 ### 3. Hand off the fix (advisor → executor, like vmware-harden)
 1. Debug emits a structured diagnosis + a proposed remediation (steps).
@@ -101,7 +101,7 @@ a recommended plan.
 
 ## Usage Mode
 
-- **MCP** (in an agent): the agent calls the other skills' read tools, then `incident_timeline` to correlate. This is the primary mode — that's where the cross-skill "联动" happens.
+- **MCP** (in an agent): the agent calls the other skills' read tools, then `build_incident_timeline` to correlate. This is the primary mode — that's where the cross-skill "联动" happens.
 - **CLI** (humans): `vmware-debug triage --events events.json` correlates a JSON array you collected yourself.
 
 ## MCP Tools (14 — 7 read, 7 write)
@@ -110,31 +110,31 @@ a recommended plan.
 
 | Tool | What |
 |---|---|
-| `incident_timeline` | [READ] Correlate pre-fetched events → timeline + spikes + ranked hypotheses + next-check ideas |
+| `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 |
 |---|---|
-| `case_open` | [WRITE] Define the event; returns a case id and the grade this environment can reach |
-| `case_readiness` | [READ] What grade this environment can reach, per symptom category, **before** you start |
-| `case_knowledge` | [READ] Which knowledge formats are accepted, what is mounted, and which entries apply to a case |
-| `case_plan` | [READ] What to fetch next — skill, tool and purpose per step; recomputed from the case's current state |
-| `case_list` | [READ] Cases, newest first |
-| `case_get` | [READ] One case: scope, ledger sizes, grade history |
-| `case_hypotheses` | [WRITE] Register a candidate explanation, or read the ledger of what supports and refutes each |
-| `case_submit_evidence` | [WRITE] Record one retrieved fact, with its source, query and time basis |
-| `case_record_gap` | [WRITE] Record what could **not** be retrieved, and how to close it |
-| `case_timeline` | [WRITE] Correlate everything the case has collected into one timeline |
-| `case_grade` | [WRITE] Recompute the conclusion grade from the ledger and record it |
-| `case_close` | [WRITE] Record the final grade, archive, and name what was left open |
+| `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 |
 
 The seven writes go to `$OPS_HOME` (default `~/.vmware/cases/`) and nowhere else.
 
 **List envelope** (output of `list_symptom_categories`): `{items, returned, limit, total, truncated, hint}` — read the rows from `items`. `truncated` is always `false` here, which is the point: it states that the catalogue is complete instead of leaving you to infer it.
 
-**Event envelope** (input to `incident_timeline`): `{ts, source, severity, entity, text, fields}`.
+**Event envelope** (input to `build_incident_timeline`): `{ts, source, severity, entity, text, fields}`.
 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.
 Keep each event's `event_type` in `fields` — the classifier matches it as well as
@@ -160,12 +160,12 @@ how a conclusion was reached with none of this installed:
 └── timeline.md · hypotheses.md · plan.jsonl · case.json
 ```
 
-Hypotheses get ids (H1, H2, …), and those ids are what `case_record_gap(blocks=…)`
-and `case_submit_evidence(falsifies=…)` refer to. **An id that was never
+Hypotheses get ids (H1, H2, …), and those ids are what `record_case_gap(blocks=…)`
+and `submit_case_evidence(falsifies=…)` refer to. **An id that was never
 registered is refused, not ignored** — a dangling reference blocks nothing and
 falsifies nothing, which quietly reports a stronger case than you have.
 
-**You cannot state a conclusion level.** `case_grade` has no parameter for one;
+**You cannot state a conclusion level.** `grade_case` has no parameter for one;
 the grade is recomputed from the ledger on every call. To change it, change the
 ledger — submit the missing evidence, or record the gap that is blocking it.
 
@@ -178,23 +178,23 @@ ledger — submit the missing evidence, or record the gap that is blocking it.
   nothing" is a gap, not an exclusion. Exclusion is per hypothesis: two
   independent sources must falsify *that* hypothesis, and the case is Excluded
   only when every registered hypothesis is ruled out. A hypothesis contradicted
-  by too few sources holds the case at Candidate. Otherwise `case_grade`
+  by too few sources holds the case at Candidate. Otherwise `grade_case`
   grades what remains, counting only evidence that falsifies nothing, and lists
   each hypothesis as `open` or `excluded` in `hypotheses`
 
-`case_plan` is not a checklist: submit evidence and the next plan is shorter,
+`plan_case` is not a checklist: submit evidence and the next plan is shorter,
 lose a source and it routes around it. Its `unavailable` half is the important
 one — a source this install cannot reach is listed there with how to supply it,
 so the gap is visible now rather than when the conclusion refuses to firm up.
 
-`case_readiness` answers this per symptom category rather than as one number —
+`get_case_readiness` answers this per symptom category rather than as one number —
 "storage reaches Probable, hardware reaches Candidate" can be acted on;
 "readiness 78%" cannot. Two classes served by the *same* skill count as one
-source, so it agrees with what `case_grade` will actually award.
+source, so it agrees with what `grade_case` will actually award.
 
 ### Mounting a knowledge library
 
-`case_knowledge` answers "what can I add" without anyone reading this file.
+`get_case_knowledge` answers "what can I add" without anyone reading this file.
 Entries go under `$OPS_HOME/knowledge/{kb,runbook,sr,cases}/`:
 
 | Format | How metadata travels |
@@ -206,7 +206,7 @@ Entries go under `$OPS_HOME/knowledge/{kb,runbook,sr,cases}/`:
 | `.csv` `.tsv` | one entry per row; use dotted columns (`driver.version`) for nested constraints |
 | `.txt` `.log` | a sibling `<name>.yaml` carries the metadata |
 
-PDF, DOCX, PPTX and HTML must be converted to Markdown first — `case_knowledge`
+PDF, DOCX, PPTX and HTML must be converted to Markdown first — `get_case_knowledge`
 names them rather than ignoring them.
 
 **Every entry needs an `applies_to` block to be decisive:**
@@ -224,11 +224,11 @@ applies_to:
 
 `product`, `build`, `driver` and `firmware` are the constraints the checker
 evaluates. **Any other key leaves the entry non-decisive** — including a typo —
-because an unverified constraint is not a satisfied one, and `case_knowledge`
+because an unverified constraint is not a satisfied one, and `get_case_knowledge`
 names the key it could not check.
 
 Knowledge evidence must say **which** entry it is
-(`case_submit_evidence(source_skill="knowledge-kb", knowledge_entry_id="KB-…")`)
+(`submit_case_evidence(source_skill="knowledge-kb", knowledge_entry_id="KB-…")`)
 — "some applicable entry is mounted somewhere" is a different claim from "this
 one applies", and only the second can carry a conclusion.
 
@@ -272,11 +272,11 @@ vmware-debug mcp                                # start stdio MCP server (proxy-
 
 ## Troubleshooting
 
-- **`incident_timeline` raises "event[N] could not be normalised"** — event N is missing a timestamp or has an unparseable one. Every event needs `ts` (ISO-8601, epoch seconds, or millis).
+- **`build_incident_timeline` raises "event[N] could not be normalised"** — event N is missing a timestamp or has an unparseable one. Every event needs `ts` (ISO-8601, epoch seconds, or millis).
 - **Most events come back "uncategorized"** — read `classification` in the result: it says how many, what share, and quotes the texts that matched nothing. Do **not** widen the window; a wider window adds baseline, not signal. The spikes still tell you *when*, which is answerable without a category. If the samples name a subsystem the taxonomy does not know, add a signature (see `references/routing.md`).
 - **No spikes detected on an obvious burst** — check `binning` for the resolution you were given. The width is chosen from event density so that bins average ≥4 events; a burst shorter than one bin can still be flattened by it. Pass `bin_seconds` to narrow. Below three bins there is no baseline at all and nothing is reported.
-- **`case_timeline` says zero events after you submitted results** — check `payload_events` in each `case_submit_evidence` reply. Events are read from a bare list, or from `items`/`events`/`rows`; a *summary* of a tool's result carries none. `note` names which items carried nothing and what keys they held instead.
-- **`case_readiness` says a skill you have is not installed** — both spellings are accepted (`monitor` and `vmware-monitor`). A name it did not recognise comes back in `unrecognised_skills` rather than being read as missing.
+- **`record_case_timeline` says zero events after you submitted results** — check `payload_events` in each `submit_case_evidence` reply. Events are read from a bare list, or from `items`/`events`/`rows`; a *summary* of a tool's result carries none. `note` names which items carried nothing and what keys they held instead.
+- **`get_case_readiness` says a skill you have is not installed** — both spellings are accepted (`monitor` and `vmware-monitor`). A name it did not recognise comes back in `unrecognised_skills` rather than being read as missing.
 - **It won't execute the fix** — by design. Route to vmware-aiops or vmware-pilot.
 
 ## Audit & Safety
@@ -292,8 +292,8 @@ row to `~/.vmware/audit.db` through `@vmware_tool`, as do the `categories` and `
 CLI commands under their MCP tools' names. The row records the tool, time, OS user,
 detected agent, arguments, status (`ok`, `error`, `denied`, `budget_exceeded`,
 `interrupted`) and a result. Two arguments are stored as `***`: evidence `payload` and
-`incident_timeline` `events`. Two results are not stored at all — `incident_timeline` and
-`case_timeline` quote event text (`sample_text`, `unmatched_samples`, `rejected`), which
+`build_incident_timeline` `events`. Two results are not stored at all — `build_incident_timeline` and
+`record_case_timeline` quote event text (`sample_text`, `unmatched_samples`, `rejected`), which
 can carry anything the source logged, so their row says
 `[redacted: return value declared sensitive]`. Every other result (ids, counts, grades,
 your own summaries and statements) is stored after credential scrubbing. The data itself
@@ -315,7 +315,7 @@ See `references/setup-guide.md`.
 **Case data is sensitive and is kept until you delete it.** Each case lives in
 `$OPS_HOME/cases/<case-id>/` (default `~/.vmware/cases/`), created owner-only (`0700`).
 It holds whatever evidence was submitted — host names, addresses, log and event text.
-Nothing is deleted automatically: `case_close` records the grade and marks the case
+Nothing is deleted automatically: `close_case` records the grade and marks the case
 closed but keeps its files. Remove a case by deleting its folder.
 
 ## License

{vmware_debug-1.13.2 → vmware_debug-2.0.0}/skills/vmware-debug/references/agent-guardrails.md

@@ -22,7 +22,7 @@ makes it the safest skill in the family to point a small model at — and the on
 most exposed to the model's reasoning, because its output *is* an
 interpretation.
 
-For a small model the ledger is more than bookkeeping: `case_grade` computes the
+For a small model the ledger is more than bookkeeping: `grade_case` computes the
 conclusion level from recorded evidence rather than accepting one, so a model
 that would happily narrate "root cause confirmed" cannot record that unless the
 evidence for it is actually in the folder.
@@ -43,10 +43,10 @@ These are structural, so it cannot.
 |---|---|
 | "Work read-only and never modify anything" | **The tool surface itself.** No tool reaches a VMware system. The seven [WRITE] tools write only to this skill's own local case ledger, so there is nothing in vSphere to withhold and nothing to switch off. |
 | "Diagnose only — never apply the fix you propose" | **Structural.** This skill has no tool that changes anything outside its own ledger, 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. |
+| "Do not fabricate a timeline — build it from the events I gave you" | **`build_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" | **`~/.vmware/audit.db` and the case ledger.** Every debug tool call, a failed one included, writes one audit row (tool, time, user, agent, arguments, status and result — evidence `payload` and `events` are stored as `***`, and the results of `incident_timeline` and `case_timeline`, which quote event text, are not stored at all). Evidence submitted to a case is also recorded in the ledger with its source skill, tool, query and fetch time — so pass the real fetch time, never a placeholder. |
+| "Log everything you looked at" | **`~/.vmware/audit.db` and the case ledger.** Every debug tool call, a failed one included, writes one audit row (tool, time, user, agent, arguments, status and result — evidence `payload` and `events` are stored as `***`, and the results of `build_incident_timeline` and `record_case_timeline`, which quote event text, are not stored at all). Evidence submitted to a case is also recorded in the ledger with its source skill, tool, query and fetch time — so pass the real fetch time, never a placeholder. |
 
 ---
 
@@ -59,7 +59,7 @@ your agent's instruction block.
 ## Tool use
 
 - Gather real events with the companion skills' read tools before calling
-  incident_timeline. Never answer from memory or assumption, and never
+  build_incident_timeline. Never answer from memory or assumption, and never
   hand-write events to represent what you believe happened.
 - Never describe a tool call, and never output a JSON example, instead of
   executing the tool. If you intend to call a tool, call it.

{vmware_debug-1.13.2 → vmware_debug-2.0.0}/skills/vmware-debug/references/capabilities.md

@@ -1,13 +1,13 @@
 # vmware-debug Capabilities
 
 Offline incident correlation. No network, no credentials, no writes to any VMware
-system. This table covers the two stateless correlation tools; the twelve `case_*`
+system. This table covers the two stateless correlation tools; the twelve case
 investigation-ledger tools (seven of which write, to the local ledger only) are
 listed in `SKILL.md`, and their response sizes are not yet measured here.
 
 | Tool | What it returns | Typical response tokens |
 |---|---|---|
-| `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) |
+| `build_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 |
 
 `list_symptom_categories` returns the family list envelope — read the rows from

{vmware_debug-1.13.2 → vmware_debug-2.0.0}/skills/vmware-debug/references/cli-reference.md

@@ -1,7 +1,7 @@
 # vmware-debug CLI Reference
 
 All commands are offline (no network, no credentials). All but `mcp` are
-read-only; `mcp` starts the MCP server, whose seven `case_*` write tools record
+read-only; `mcp` starts the MCP server, whose seven case write tools record
 into the local case ledger.
 
 ## triage — correlate a set of collected events
@@ -42,9 +42,9 @@ vmware-debug mcp        # start the stdio MCP server (no network at startup)
 
 In an agent, the cross-skill correlation happens at the agent layer:
 
-1. Fetch events with the data-source skills (vmware-monitor `event_list`,
-   vmware-log-insight `log_search`/`log_aggregate`, vmware-aria alerts/anomaly,
+1. Fetch events with the data-source skills (vmware-monitor `get_events`,
+   vmware-log-insight `search_logs`/`aggregate_logs`, vmware-aria alerts/anomaly,
    vmware-nsx).
 2. Normalise each into the event envelope.
-3. Call the `incident_timeline` MCP tool to correlate and rank.
+3. Call the `build_incident_timeline` MCP tool to correlate and rank.
 4. Follow `next_checks`; route any fix to vmware-aiops / vmware-pilot.

{vmware_debug-1.13.2 → vmware_debug-2.0.0}/skills/vmware-debug/references/event-envelope.md

@@ -2,7 +2,7 @@
 
 This is the contract between `vmware-debug` and every data-source skill. The
 orchestrating agent fetches events with each skill's own read tools, normalises
-each into this shape, and passes the list to `incident_timeline`. Debug has **no
+each into this shape, and passes the list to `build_incident_timeline`. Debug has **no
 runtime dependency** on the other packages (no version lockstep, no heavy install).
 
 ## Shape
@@ -22,7 +22,7 @@ runtime dependency** on the other packages (no version lockstep, no heavy instal
 | Field | Type | Notes |
 |---|---|---|
 | `ts` | string \| number | ISO-8601, epoch **seconds**, or epoch **millis** (auto-detected). Required. |
-| `source` | string | `monitor` \| `aria` \| `loginsight` \| `nsx` \| `nsx-security` \| `storage` \| ... The catalogue in `rules/evidence_sources.yaml` spells the same skills `vmware-monitor`, `vmware-aria`, `vmware-log-insight`. Both spellings are understood wherever a skill is named — `case_readiness(available_skills=...)`, and the grader's count of independent sources, which treats two spellings of one skill as one source. |
+| `source` | string | `monitor` \| `aria` \| `loginsight` \| `nsx` \| `nsx-security` \| `storage` \| ... The catalogue in `rules/evidence_sources.yaml` spells the same skills `vmware-monitor`, `vmware-aria`, `vmware-log-insight`. Both spellings are understood wherever a skill is named — `get_case_readiness(available_skills=...)`, and the grader's count of independent sources, which treats two spellings of one skill as one source. |
 | `severity` | string | Free text; normalised to `critical`/`error`/`warning`/`info`/`unknown`. |
 | `entity` | string | The object the event is about (VM/host/datastore). May be empty. |
 | `text` | string | Human-readable message. Matched by the symptom classifier. |
@@ -52,10 +52,10 @@ sources map with little or no adaptation.
 
 | Source tool (example) | ts | severity | entity | text |
 |---|---|---|---|---|
-| vmware-monitor `event_list` | `createdTime` | `severity` | `vm`/`host` | `fullFormattedMessage` |
+| vmware-monitor `get_events` | `createdTime` | `severity` | `vm`/`host` | `fullFormattedMessage` |
 | vmware-aria `alert_query` | `startTimeUTC` | `criticality` | `resourceName` | `alertDefinitionName` |
 | vmware-aria `anomaly` | `timestamp` | (derive) | `resourceName` | stat + value |
-| vmware-log-insight `log_search` | `timestamp` | `severity`/derive | `hostname` | `text` |
+| vmware-log-insight `search_logs` | `timestamp` | `severity`/derive | `hostname` | `text` |
 | vmware-nsx (firewall/traceflow) | `time` | (derive) | src/dst | rule/verdict |
 
 ## Why this design

{vmware_debug-1.13.2 → vmware_debug-2.0.0}/skills/vmware-debug/references/routing.md

@@ -15,7 +15,7 @@ Keep this in sync with `_CATEGORY_SIGNATURES` in `vmware_debug/ops/timeline.py`
 | **auth** | login, authentication, denied, 401, 403, token, certificate, tls, password | the owning skill's `doctor` (reports whether a credential is set and whether login works — never its value), target cert + time sync | config fix (by the user) |
 | **platform** | vpxd, hostd, service restart, crash, 503, not responding, disconnected | vmware-monitor (connection/service), vmware-log-insight (vpxd/hostd) | pilot |
 | **hardware** | tpm, attestation, ipmi, sensor, bmc | vmware-monitor (host sensors and the CIM Server that supplies them, host logs for ipmi/cim), the server's BMC | site / vendor |
-| **licensing** | license | vmware-monitor (license_status — which asset holds which key); an Aria alert on "Unlicensed Group" is Aria's own license | license portal |
+| **licensing** | license | vmware-monitor (get_license_status — which asset holds which key); an Aria alert on "Unlicensed Group" is Aria's own license | license portal |
 | **data_collection** | adapter instance, not receiving data, collector group, cloud proxy | vmware-aria (adapters, collector groups, node health, objects that stopped reporting), vmware-monitor (is the source vCenter reachable) | aria admin |
 
 ## Remediation handoff (advisor → executor)