wxcli 1.2.0__py3-none-any.whl

wxcli/_playbook/.claude/skills/teardown/SKILL.md

@@ -0,0 +1,214 @@
+---
+name: teardown
+description: |
+  Tear down Webex Calling resources in dependency-safe order. Covers single-location
+  teardown, multi-location bulk cleanup, migration test cleanup, and org reset.
+  Use for: delete, remove, clean up, tear down, reset, decommission.
+  NOT for: creating/provisioning resources (use provision-calling skill) or
+  license reclamation without resource deletion (use manage-licensing skill).
+argument-hint: [scope — e.g. "DP-HQ-Phones", "all GlobalTech locations", "entire org"]
+---
+
+# Teardown Skill
+
+Delete Webex Calling resources in the correct dependency order. Use `wxcli cleanup` for automated batch teardown, or follow the manual procedure below.
+
+## Step 1: Load references
+
+1. Read `.claude/rules/cleanup.md` for all cleanup flags, 13-layer deletion order, and known behaviors
+2. For manual teardown (not using `wxcli cleanup`): Read `docs/reference/call-routing.md` (routing delete semantics) and `docs/reference/devices-core.md` (device delete flow)
+
+**Mandatory --help verification:** Before constructing any manual delete command, run `wxcli <group> --help` to verify the delete subcommand name exists, then `wxcli <group> <subcommand> --help` to verify the exact flags. Do NOT guess delete command names — routing deletes use PLURAL names (`delete-route-groups`, not `delete-route-group`). Feature deletes use `--force LOCATION_ID FEATURE_ID` argument order.
+
+---
+
+**Checkpoint — do NOT proceed until you can answer these:**
+1. What resource type must be deleted BEFORE disable-calling can succeed on a location? (Answer: workspaces)
+2. What is the correct argument order for location-scoped feature deletes? (Answer: `--force LOCATION_ID FEATURE_ID` — location comes FIRST)
+3. Do routing delete commands use singular or plural names? (Answer: plural — `delete-route-groups` not `delete-route-group`)
+
+If you cannot answer all three, you skipped reading this skill. Go back and read it.
+
+## Preferred: `wxcli cleanup` (automated)
+
+```bash
+# Dry-run first — shows what would be deleted
+wxcli cleanup run --scope "Location Name" --dry-run
+
+# Delete all resources at specific locations (--include-users deletes users at scoped locations)
+wxcli cleanup run --scope "DP-HQ-Phones,DP-Branch-Phones" --include-users --exclude-user-domains "wbx.ai" --force
+
+# Delete everything in the org
+wxcli cleanup run --all --include-users --include-locations --force
+
+# Delete users but keep admin accounts by domain
+wxcli cleanup run --all --include-users --exclude-user-domains "wbx.ai,corp.com" --force
+
+# Control parallelism
+wxcli cleanup run --scope "GlobalTech*" --max-concurrent 10 --force
+```
+
+`wxcli cleanup` handles the full dependency DAG automatically: inventories all resources, deletes in the correct 13-layer order (including phone number removal before location deletion), and parallelizes within each layer.
+
+**Key behaviors:**
+- **Phone numbers** are removed automatically before location deletion (batched in groups of 5, main numbers skipped). Numbers assigned to a location block location deletion with 409.
+- **Location deletion cannot be completed via API.** The public API cannot disable Webex Calling on a location — the telephony detach endpoint returns 404 in most orgs. `wxcli cleanup --include-locations` will remove all resources AT the location (features, routing, devices, users, numbers) but the location itself will remain calling-enabled and 409 on delete. **The operator must finish location deletion in Control Hub** (Locations → select location → disable Webex Calling → delete). Always tell the user this upfront when `--include-locations` is requested.
+- **`--include-users` is location-scoped when `--scope` is set.** With `--scope`, only users at the specified locations are deleted. With `--all`, all org users are in scope. In both cases, **always use `--exclude-user-domains`** to protect admin and service accounts (e.g., `--exclude-user-domains "wbx.ai,company.com"`).
+
+**Always dry-run first** for any scope larger than a single location.
+
+### What `wxcli cleanup` deletes by default (no flags)
+
+With just `--scope` and `--force`, cleanup deletes: dial plans, route lists, route groups, translation patterns, trunks, call features (HG/CQ/AA/paging/park/pickup), operating modes, schedules, virtual lines, **devices**, **workspaces**, and phone numbers. It does NOT delete users or locations unless `--include-users` / `--include-locations` is passed.
+
+**Selective teardown (features/routing only, keep devices + users + location):**
+Do NOT use `wxcli cleanup` — it has no `--exclude-devices` flag and will delete devices and workspaces. Use the manual procedure (Step 2 below), deleting only Layers 1-2 (features + routing).
+
+---
+
+## Manual Teardown Procedure
+
+Use when `wxcli cleanup` is unavailable or you need fine-grained control.
+
+### Step 1: Enumerate ALL resources upfront
+
+Run ALL of these checks before deleting anything. Collect the full inventory.
+
+```bash
+LOC=<LOCATION_ID>
+
+# Layer 1: Features
+wxcli hunt-group list --location-id $LOC -o json 2>&1
+wxcli call-queue list --location-id $LOC -o json 2>&1
+wxcli call-queue list --location-id $LOC --has-cx-essentials true -o json 2>&1
+wxcli auto-attendant list --location-id $LOC -o json 2>&1
+wxcli paging-group list --location-id $LOC -o json 2>&1
+# Call parks and pickups REQUIRE location as positional arg — org-wide list returns EMPTY
+wxcli call-park list $LOC -o json 2>&1
+wxcli call-pickup list $LOC -o json 2>&1
+wxcli location-voicemail list $LOC -o json 2>&1
+
+# Layer 2: Routing (org-wide — filter by location in output)
+wxcli call-routing list -o json 2>&1               # dial plans
+wxcli call-routing list-route-lists -o json 2>&1   # route lists
+wxcli call-routing list-route-groups -o json 2>&1  # check which reference trunks in this location
+wxcli call-routing list-trunks -o json 2>&1        # filter by location in output
+
+# Layer 3: Supporting resources
+wxcli virtual-extensions list --location-id $LOC -o json 2>&1
+wxcli location-schedules list $LOC -o json 2>&1
+wxcli operating-modes list --location-id $LOC -o json 2>&1
+
+# Layer 4: Users
+wxcli users list --location-id $LOC -o json 2>&1
+
+# Layer 5: Workspaces (no --location-id flag — filter client-side by locationId)
+wxcli workspaces list -o json 2>&1
+```
+
+Present the full inventory to the user before proceeding.
+
+### Step 2: Delete in dependency order
+
+Delete **layer by layer, top to bottom**. Resources within the same layer have no interdependencies and can be deleted in parallel.
+
+#### Layer 1: Features
+```bash
+wxcli hunt-group delete --force $LOC <HG_ID>
+wxcli call-queue delete --force $LOC <CQ_ID>
+wxcli auto-attendant delete --force $LOC <AA_ID>
+wxcli call-park delete --force $LOC <PARK_ID>
+wxcli call-pickup delete --force $LOC <PICKUP_ID>
+wxcli paging-group delete --force $LOC <PG_ID>
+```
+
+#### Layer 2: Routing (reverse creation order)
+```bash
+# Dial plans first, then route lists, then route groups, then trunks
+wxcli call-routing delete --force <DP_ID>
+wxcli call-routing delete-route-lists --force <RL_ID>
+wxcli call-routing delete-route-groups --force <RG_ID>
+wxcli call-routing delete-translation-patterns-call-routing --force <TP_ID>
+wxcli call-routing delete-trunks --force <TRUNK_ID>
+```
+
+#### Layer 3: Supporting resources
+```bash
+wxcli virtual-extensions delete --force <VE_ID>
+wxcli location-schedules delete --force $LOC <TYPE> <SCHEDULE_ID>
+wxcli operating-modes delete --force <OM_ID>
+```
+
+#### Layer 4: Users
+```bash
+wxcli users delete --force <USER_ID>
+```
+
+#### Layer 5: Workspaces
+```bash
+# Must delete workspaces BEFORE disabling calling on the location
+wxcli workspaces delete --force <WORKSPACE_ID>
+```
+
+#### Layer 6: Phone Numbers
+```bash
+# Remove phone numbers BEFORE location deletion — numbers block location delete with 409
+# List numbers for the location
+wxcli numbers list --location-id $LOC -o json
+# Delete numbers (API accepts max 5 per request, main number cannot be removed)
+# Use wxcli numbers delete $LOC or raw API:
+#   DELETE /telephony/config/locations/{LOC}/numbers  body: {"phoneNumbers": ["+1..."]}
+```
+
+#### Layer 7: Locations
+```bash
+# The API CANNOT disable Webex Calling on a location. After clearing all
+# dependencies above, the location will still 409 on delete because it
+# remains calling-enabled. Attempt the delete — it may work in rare cases:
+wxcli location-settings safe-delete-check $LOC
+wxcli locations delete --force $LOC
+# If 409: tell the user to finish in Control Hub (disable calling → delete).
+```
+
+### Step 3: Handle 409 on location delete
+
+If `locations delete` returns 409 "being referenced", check these in order:
+
+1. **Phone numbers still assigned** — `wxcli numbers list --location-id $LOC -o json`. Remove non-main numbers before location delete. `wxcli cleanup` handles this automatically (Layer 12).
+2. **CX Essentials queues** hidden from default `call-queue list` — need `--has-cx-essentials true`
+3. **Call parks / pickups** not found — `call-park list` and `call-pickup list` without `$LOC` as first positional arg return empty
+4. **Virtual lines** — discoverable via `wxcli numbers list -o json` (owner.type == VIRTUAL_LINE), not always via `virtual-extensions list`
+5. **Workspaces** still assigned — workspaces API has no location filter, must filter client-side by `locationId` field
+6. **Operating modes** referencing deleted schedules
+7. **Calling-enabled location (most common cause)** — the public API cannot disable Webex Calling on a location. Even with all visible dependencies gone, the location remains calling-enabled and 409s on delete. The telephony detach endpoint (`DELETE /telephony/config/locations/{id}`) returns 404 in most orgs. **This is not fixable via CLI/API — the operator must disable Webex Calling in Control Hub** (Locations → select → disable calling → delete).
+8. **Ghost/stale locations** — locations returning 404 on sub-resource queries may still be deletable. Attempt deletion regardless.
+
+### Rule: never hand-roll polling loops
+
+When a 409 persists after the built-in 90s wait (or any other "wait and retry" situation in teardown), follow these rules strictly. Violating them causes silent Bash-tool timeouts mid-loop and unrecoverable partial state.
+
+1. **Do NOT** write external Python or bash polling loops with `time.sleep` / `sleep` inside a single Bash tool call. The Bash tool has a ~10-minute hard timeout; long loops die silently with no useful output.
+2. **Do** re-invoke `wxcli cleanup run` (with the same `--scope` / flags). It is **idempotent** — safe to repeat — and resumes cleanup from wherever it left off. This is the preferred recovery path for 409s.
+3. If bespoke per-location retry is truly required, split it into **discrete Bash tool calls** — one call per location per attempt (or per round) — with a short `sleep` **between** tool calls, not inside them. Each call returns control to the parent before the next wait begins.
+4. Cap any necessary hand-written retry script at **≤3 minutes wall time**. Beyond that, exit the script and let the parent re-dispatch — do not stretch a single Bash call toward the 10-minute ceiling.
+5. If `cleanup run` exits with remaining 409s, **report them in the task summary and stop**. Do not loop silently. The operator (or parent agent) decides whether to re-invoke.
+
+### Gotcha: CCP-integrated PSTN backend gate (dCloud / Cisco Calling Plan orgs)
+
+When the target org uses **Cisco Calling Plan** (CCP-integrated PSTN), number deletion fails with `ERR.V.TRM.TMN60004` ("DELETE number is supported only for non-integrated CCP") — these numbers are managed via the PSTN portal, not the API. After trunk/route-group/feature/user teardown, **location delete then 409s with "being referenced"** for hours even though there are no locally visible dependencies. Webex's internal PSTN backend is async-releasing trunk references and typically clears in **1-4 hours** in dCloud/CCP orgs. No API action can speed this up.
+
+`wxcli cleanup run` now detects the explicit number-delete signature and short-circuits those number removals:
+- **Number delete:** skipped with a `[number=<ext/e164>] skipped — CCP-integrated, managed via PSTN portal` log line, not counted as a failure.
+- **Location delete:** do **not** infer CCP solely from a generic `409 "being referenced"` response. Generic 409s can also mean preserved users, voice portal state, or the fact that the location is still calling-enabled and must be finished in Control Hub.
+
+---
+
+## Critical Rules
+
+1. **Always use `--force`** — skip interactive confirmation for programmatic deletes
+2. **Location-scoped feature deletes take LOCATION_ID FIRST** — `wxcli hunt-group delete --force LOCATION_ID HG_ID`, not `HG_ID LOCATION_ID`
+3. **Routing delete commands use PLURAL names** — `delete-route-groups` not `delete-route-group`, `delete-trunks` not `delete-trunk`
+4. **Workspaces block location deletion** — delete all workspaces at a location BEFORE running disable-calling
+5. **Do not promise API disable-calling** — use CLI/API to remove visible blockers, but warn that final delete of a calling-enabled location may still require Control Hub
+6. **Enumerate before deleting** — never start deleting without a full inventory; hidden resources (CX queues, call parks, workspaces) will block location delete
+7. **Multi-location teardown** — repeat the procedure per location, or use `wxcli cleanup run --scope "Loc1,Loc2"` for automation

wxcli/_playbook/.claude/skills/video-mesh/SKILL.md

@@ -0,0 +1,379 @@
+---
+name: video-mesh
+description: |
+  Monitor and configure Webex Video Mesh clusters, nodes, availability,
+  utilization, reachability, and event thresholds using wxcli CLI commands.
+  Guides the user from prerequisites through execution and verification.
+allowed-tools: Read, Grep, Glob, Bash
+argument-hint: [mesh-operation]
+---
+
+<!-- Created by playbook session 2026-03-28 -->
+
+# Video Mesh Workflow
+
+**Checkpoint — do NOT proceed until you can answer these:**
+1. What is the command to list all Video Mesh clusters? (Answer: `wxcli video-mesh list-clusters-video-mesh` — not `wxcli video-mesh list`, which shows client type distribution.)
+2. How do you trigger an on-demand test for a single node? (Answer: `wxcli video-mesh create NODE_ID` — not `create-clusters`, which targets a cluster.)
+
+If you cannot answer both, you skipped reading this skill. Go back and read it.
+
+## Step 1: Load references
+
+1. Read `docs/reference/meetings-infrastructure.md` for Video Mesh clusters, nodes, availability, utilization, reachability, health monitoring, and event thresholds
+
+**Mandatory --help verification:** Before constructing any wxcli command, run `wxcli <group> --help` to verify the subcommand exists, then `wxcli <group> <subcommand> --help` to verify the exact flags (e.g. `wxcli video-mesh --help` to list subcommands, then drill into the specific one). Do NOT rely on examples in this skill or reference docs — the CLI is auto-generated and flag names may differ from what documentation suggests.
+
+---
+
+## Step 2: Verify auth token
+
+Before any API calls, confirm the user has a working auth token:
+
+```bash
+wxcli whoami
+```
+
+If this fails, stop and resolve authentication first (`wxcli configure`).
+
+**Required scopes:**
+- **Read**: `spark-admin:video_mesh_read`
+- **Write**: `spark-admin:video_mesh_write` (for threshold configuration and on-demand tests)
+
+**Token type:** Admin token required. User tokens will return 403.
+
+---
+
+## Step 3: Identify the operation type
+
+Ask the user what they want to accomplish. Present this decision matrix if they are unsure:
+
+| User Wants To | Operation | CLI Commands |
+|--------------|-----------|-------------|
+| List all clusters | Cluster inventory | `video-mesh list-clusters-video-mesh` |
+| Get cluster details | Cluster inspection | `video-mesh show CLUSTER_ID` |
+| Check cluster health/availability | Availability monitoring | `video-mesh list-availability-clusters`, `video-mesh show-availability-clusters CLUSTER_ID` |
+| Check node health/availability | Node monitoring | `video-mesh list-availability-nodes`, `video-mesh show-availability-nodes NODE_ID` |
+| View cluster utilization stats | Utilization analysis | `video-mesh list-utilization-video-mesh`, `video-mesh list-utilization-clusters CLUSTER_ID` |
+| Run reachability tests | Connectivity verification | `video-mesh list-reachability-test`, `video-mesh list-clusters-reachability-test CLUSTER_ID`, `video-mesh list-nodes-reachability-test NODE_ID` |
+| View media health results | Media quality monitoring | `video-mesh list-media-health-monitor-test`, `video-mesh list-clusters-media-health-monitor-test CLUSTER_ID`, `video-mesh list-nodes-media-health-monitor-test NODE_ID` |
+| Run network tests | Network diagnostics | `video-mesh list-network-test`, `video-mesh list-clusters-network-test CLUSTER_ID`, `video-mesh list-nodes-network-test NODE_ID` |
+| Trigger on-demand test (node) | Manual testing | `video-mesh create NODE_ID` |
+| Trigger on-demand test (cluster) | Manual testing | `video-mesh create-clusters CLUSTER_ID` |
+| Check triggered test status/results | Test follow-up | `video-mesh list-test-status`, `video-mesh list-test-results` |
+| View cloud overflow stats | Overflow analysis | `video-mesh list-cloud-overflow` |
+| View call redirect details | Redirect analysis | `video-mesh list-call-redirects-video-mesh`, `video-mesh list-call-redirects-clusters CLUSTER_ID` |
+| View client type distribution | Client analytics | `video-mesh list`, `video-mesh list-clusters-client-type-distribution CLUSTER_ID` |
+| View/update event thresholds | Threshold configuration | `video-mesh list-event-thresholds`, `video-mesh show-event-thresholds THRESHOLD_ID`, `video-mesh update THRESHOLD_ID` |
+| Reset event thresholds to defaults | Threshold reset | `video-mesh create-reset` |
+| Not Video Mesh? | For meetings → `manage-meetings` skill. For call features → `configure-features` skill. | — |
+
+---
+
+## Step 4: Check prerequisites
+
+### 4a. Admin token with Video Mesh scopes
+
+```bash
+wxcli whoami
+```
+
+Verify the output shows admin-level access. If Video Mesh commands return 403, the token is missing `spark-admin:video_mesh_read` or `spark-admin:video_mesh_write` scopes.
+
+### 4b. Video Mesh deployed
+
+Verify the org has Video Mesh clusters registered:
+
+```bash
+wxcli video-mesh list-clusters-video-mesh --output json
+```
+
+If this returns empty, Video Mesh is not deployed in this org. Video Mesh requires on-premises nodes registered to the Webex cloud. This skill cannot deploy Video Mesh — that is a network infrastructure task done via the Video Mesh Node OVA.
+
+### 4c. Cluster and node IDs
+
+For most operations, you need a cluster ID or node ID. Get them from the cluster list:
+
+```bash
+# List clusters (get cluster IDs)
+wxcli video-mesh list-clusters-video-mesh --output json
+
+# Get cluster details (includes node IDs)
+wxcli video-mesh show CLUSTER_ID --output json
+```
+
+---
+
+## Step 5: Gather configuration and present deployment plan — [SHOW BEFORE EXECUTING]
+
+Most Video Mesh operations are read-only queries. For write operations (threshold configuration, on-demand tests), present the plan before executing.
+
+---
+
+### Monitoring Queries (Read-Only)
+
+For read-only operations, present a brief query plan:
+
+```
+QUERY PLAN
+==========
+Operation: [type — e.g., "Check availability for all clusters over last 7 days"]
+Scope: [all clusters / specific cluster / specific node]
+Time Range: [if applicable]
+
+Commands to execute:
+  1. wxcli video-mesh list-availability --from ... --to ... --output json
+
+Proceed? (yes/no)
+```
+
+---
+
+### Cluster Health Check (Comprehensive)
+
+For a comprehensive health check of a cluster:
+
+```bash
+# 1. Cluster details
+wxcli video-mesh show CLUSTER_ID --output json
+
+# 2. Availability
+wxcli video-mesh show CLUSTER_ID --output json
+
+# 3. Utilization
+wxcli video-mesh list-utilization-clusters CLUSTER_ID --output json
+
+# 4. Reachability
+wxcli video-mesh list-clusters-reachability-test CLUSTER_ID --output json
+
+# 5. Media health
+wxcli video-mesh list-clusters-media-health-monitor-test CLUSTER_ID --output json
+
+# 6. Network test results
+wxcli video-mesh list-clusters-network-test CLUSTER_ID --output json
+
+# 7. Call redirects (overflow)
+wxcli video-mesh list-call-redirects-clusters CLUSTER_ID --output json
+
+# 8. Client type distribution
+wxcli video-mesh list-clusters-client-type-distribution CLUSTER_ID --output json
+```
+
+---
+
+### Node Health Check
+
+For a single node:
+
+```bash
+# Node availability
+wxcli video-mesh show-availability NODE_ID --output json
+
+# Node reachability
+wxcli video-mesh list-nodes-reachability-test NODE_ID --output json
+
+# Node media health
+wxcli video-mesh list-nodes-media-health-monitor-test NODE_ID --output json
+
+# Node network test
+wxcli video-mesh list-nodes-network-test NODE_ID --output json
+```
+
+---
+
+### On-Demand Tests
+
+```bash
+# Trigger test for a specific node
+wxcli video-mesh create NODE_ID
+
+# Trigger test for all nodes in a cluster
+wxcli video-mesh create CLUSTER_ID
+
+# Check test status
+wxcli video-mesh list-test-status --output json
+
+# Get test results
+wxcli video-mesh list-test-results --output json
+```
+
+---
+
+### Event Threshold Configuration
+
+Collect from user:
+
+| Parameter | Required | Notes |
+|-----------|:--------:|-------|
+| Threshold ID | Yes | Get from `list-event-thresholds` |
+| New threshold value | Yes | Depends on threshold type |
+
+```bash
+# List current thresholds
+wxcli video-mesh list-event-thresholds --output json
+
+# Get a specific threshold
+wxcli video-mesh show-event-thresholds THRESHOLD_ID --output json
+
+# Update a threshold
+wxcli video-mesh update THRESHOLD_ID --json-body '{"value": 80}'
+
+# Reset all thresholds to defaults
+wxcli video-mesh create-reset
+```
+
+---
+
+### Overflow and Redirect Analysis
+
+```bash
+# List cloud overflow details
+wxcli video-mesh list-cloud-overflow --output json
+
+# List call redirect details (org-wide)
+wxcli video-mesh list-call-redirects-video-mesh --output json
+
+# Get redirect details for a specific cluster
+wxcli video-mesh list-call-redirects-clusters CLUSTER_ID --output json
+```
+
+---
+
+### Deployment Plan Template (Write Operations)
+
+For write operations (threshold updates, on-demand tests):
+
+```
+DEPLOYMENT PLAN
+===============
+Operation: [type — e.g., "Update CPU utilization threshold to 80%"]
+Target: [threshold ID / node ID / cluster ID]
+
+Current State:
+  [Current threshold value / current test status]
+
+Changes:
+  [What will be changed]
+
+Commands to execute:
+  1. wxcli video-mesh update THRESHOLD_ID --json-body '{"value": 80}'
+
+Proceed? (yes/no)
+```
+
+**Wait for user confirmation before executing write operations.**
+
+---
+
+## Step 6: Execute via wxcli
+
+Run the commands in plan order.
+
+Handle errors explicitly:
+
+- **401/403**: Token expired or insufficient scopes — run `wxcli configure` to re-authenticate. Required scope: `spark-admin:video_mesh_read` (read) or `spark-admin:video_mesh_write` (write).
+- **404**: Cluster or node not found — verify the ID with `wxcli video-mesh list-clusters-video-mesh`.
+- **400**: Validation error — read the error message and fix the parameter (e.g., invalid threshold value).
+- **Empty results on availability/utilization queries:** The time range may be too narrow or the cluster may be newly deployed. Try expanding the time range.
+
+---
+
+## Step 7: Verify
+
+After write operations, verify the change took effect:
+
+```bash
+# Verify threshold update
+wxcli video-mesh show-event-thresholds THRESHOLD_ID --output json
+
+# Verify on-demand test was triggered
+wxcli video-mesh list-test-status --output json
+
+# Verify test completed and get results
+wxcli video-mesh list-test-results --output json
+```
+
+For read-only operations, verification is inherent — the query results are the verification.
+
+---
+
+## Step 8: Report results
+
+Present the operation results:
+
+### For monitoring queries:
+
+```
+VIDEO MESH STATUS
+=================
+Clusters: [N]
+Total Nodes: [N]
+
+Cluster: [cluster_name]
+  ID: [cluster_id]
+  Nodes: [N]
+  Availability: [percentage]
+  Utilization: [percentage]
+  Reachability: [pass/fail]
+  Media Health: [pass/fail]
+  Cloud Overflow: [count] calls redirected
+
+[Repeat for each cluster]
+
+Issues Found:
+  - [e.g., "Node X reachability test failed"]
+  - [e.g., "Cluster Y utilization at 92% (above threshold)"]
+
+Recommendations:
+  - [e.g., "Investigate node X network connectivity"]
+  - [e.g., "Consider adding nodes to cluster Y"]
+```
+
+### For write operations:
+
+```
+OPERATION COMPLETE
+==================
+Operation: [type]
+Status: Success
+
+Changes Applied:
+  - [e.g., "CPU threshold updated from 70% to 80%"]
+  - [e.g., "On-demand test triggered for node X"]
+
+Next steps:
+  - [e.g., "Monitor test results: wxcli video-mesh list-test-results"]
+  - [e.g., "Check cluster health in 5 minutes after test completes"]
+```
+
+---
+
+## Critical Rules
+
+1. **Always verify admin token and Video Mesh scopes** before any operation. User tokens return 403 for all Video Mesh endpoints.
+2. **Always show the deployment plan** (Step 5) and wait for user confirmation before executing write operations (threshold changes, on-demand tests).
+3. **`video-mesh list` is NOT the cluster list command.** `list` shows client type distribution. Use `list-clusters-video-mesh` to list clusters.
+4. **On-demand tests are `create` (node) and `create-clusters` (cluster).** The command names follow the generator pattern where POST endpoints become `create`.
+5. **Threshold reset (`create-reset`) resets ALL thresholds** to factory defaults. This is a destructive operation — confirm with the user before executing.
+6. **Video Mesh is read-heavy.** Most operations are monitoring queries. Only threshold configuration and on-demand test triggers are write operations.
+7. **Time-range queries default to recent data.** If availability/utilization commands return empty, the time range may need to be specified with `--from` and `--to` flags (where supported).
+8. **Node IDs come from cluster details.** You cannot list all nodes directly — get them from `wxcli video-mesh show CLUSTER_ID --output json` which includes the node list.
+9. **Cross-skill handoffs:**
+    - Meeting scheduling/management → `manage-meetings` skill
+    - CDR and call quality reports → `reporting` skill
+    - Network infrastructure/PSTN → `configure-routing` skill
+
+---
+
+## Context Compaction Recovery
+
+If context compacts mid-execution, recover by:
+1. List clusters to recover the environment state:
+   ```bash
+   wxcli video-mesh list-clusters-video-mesh --output json
+   ```
+2. Check if any on-demand tests are pending:
+   ```bash
+   wxcli video-mesh list-test-status --output json
+   ```
+3. Resume from the first incomplete step in the plan